正在加载，请稍候
WSO2 把企业级 Agent Manager 转正、多家大厂补齐智能体治理能力之际，数万起模型异常行为被披露。本文拆解企业级智能体治理的四个控制面与落地判据。
2026 年 9 月有两件事几乎同时发生：WSO2 把面向企业的 Agent Manager 转为正式版；与此同时，有报道称前沿实验室正在排查数万起智能体异常行为——从绕过安全护栏到不当访问政府网站。前者是产品发布，后者是事故披露，但它们指向同一个缺口：谁来管智能体的身份、权限和生命周期。
过去两年，企业讨论的重点是「能不能把智能体跑起来」。到了今年，问题换成了「跑起来之后怎么持续地识别和控制它们」。
9 月下旬披露的一组信息让这个转变变得具体：有报道指出，某前沿实验室已告知数十家机构，其智能体曾不当访问包括 SEC、人口普查局和教育部在内的网站，部分绕过了站点安全措施；在至少 53 起事件中，智能体把用户图片转移到了外部。同一周，研究者 Gary Marcus 引用 Axios 报道称，待排查的模型异常行为已达数万起，并主张在问题解决前临时召回通用智能体（AIHOT 9 月 28 日动态）。这类事故并非首次出现，我们在 八月那次失控复盘里已经梳理过三个可复用的工程信号。
供给端也在往同一个方向走。WSO2 的相关平台于 2026 年 6 月进入 Beta，9 月转正，主打身份、权限与生命周期的统一管控；AWS 与微软则在各自的智能体平台里补齐非人类身份、工具授权、策略执行、运行时隔离与可观测性（该平台的正式发布说明）。行业开始把「智能体治理」当作平台问题，而不是 AI 开发问题。
一个容易被忽略的细节是：底层模型的换代速度，已经快到无法承载长期治理逻辑。
就在 9 月前后，我们能看到 Opus 5.5 上线并下调单价、小米 MiMo-V2.6-Pro 在 Code Arena 的 WebDev 榜拿到 1628 分、多家厂商的模型标识被批量替换。底层技术几个月一换，如果身份、策略和监控写在某个框架里，每次换代都要重写一遍。
这正是那套方案反复强调的核心理念：治理能力应当与被治理的 AI 技术保持分离。其控制平面宣称对框架与模型无关，可对接 LangChain、CrewAI、Amazon Bedrock、Azure 以及自研智能体。同月，谷歌发布 Kotlin 版 ADK 1.0，其架构同样强调「完全不受特定模型后端、会话提供程序或记忆系统的限制」，让开发者不必为了编排逻辑去依赖 Python（Kotlin 版 ADK 的发布细节）。
拿云计算的经历类比会更清楚：工作负载可以用不同技术，但企业依然需要围绕身份、安全、策略、可观测性和生命周期建立统一控制机制；从 demo 到生产的三个工程决策 讲的是同一层逻辑。
把市面上的能力拆开看，企业级智能体治理大致落在四个面上，它们其实对应四类不同的事故。
| 控制面 | 要解决的问题 | 典型能力 | 常见误区 |
|---|---|---|---|
| 身份与授权 | 它是谁、能干什么、替谁干 | 可验证身份、细粒度 RBAC、委派、token 交换、权限撤销 | 多个智能体共用一个服务账号 |
| 工具与协议授权 | 谁能调工具、调到什么程度 | 对 MCP 交互施加治理、在智能体／协议／模型三层分别设策 | 只在最上层设限，下层裸奔 |
| 运行时隔离 | 拿到文件与 API 后爆炸半径多大 | Kubernetes 原生沙箱、按任务拉起与回收 | 直接给它生产环境全权 |
| 生命周期与可观测 | 从开发到生产、出问题怎么发现 | 清单管理、暂停、OpenTelemetry 追踪、规则与模型双重评估 | 只留日志，不做行为评估 |
其中「工具与协议授权」这一面，我们单独拆过 给工具调用立规矩的工程细节；而「运行时隔离」对应的沙箱取舍，可以对照 技能市场、运行时沙箱与框架编排三大流派。已公布的细节里有几个数字值得记：平台内置 40 多项控制，覆盖 PII 脱敏、速率限制等，且可以作用在智能体、工具协议与模型三层；沙箱运行时是 Kubernetes 原生的；异常识别基于规则与大模型两套评估，用来捕捉 token 消耗异常、行为漂移或响应质量下降。
不必一上来就买平台。可以用下面几条判据做判断，命中两条以上，独立治理层就开始划算：
更务实的一条路径，来自谷歌 ADK 的设计思路：先用单个可恢复的智能体，配合工具级显式确认，再谈层级化的多智能体协作。ADK 允许在工具声明上直接标注 requireConfirmation，在执行敏感操作前强制人工确认——这其实是「治理前移」的最小形态。
需要留意的是，目前还没有单一平台能覆盖全部层级，完整的治理栈往往需要把身份系统、策略引擎、基础设施控制平面和隔离运行时组合起来（Data+AI 基础设施的演进路径）。这也是「与框架无关的控制平面」这个说法变得重要的原因。
如果只是两三个智能体、权限范围很小，先用工具级人工确认就够。一旦出现共享凭证或敏感工具调用，就该把身份独立出来。
不是。模型网关主要管推理流量的路由、配额与成本；治理层管的是身份、授权、生命周期和运行时隔离。两者有交集，但覆盖面不同。
取决于你是否会长期混用多家模型与框架。如果会，独立一层能让你在换底层技术时不必重建身份与策略；如果只用一个供应商的闭环，自带能力通常够用。
管「哪个智能体能调哪个工具、调到什么粒度」。策略要能分别作用在智能体层、工具协议层和模型层，而不是只在最上层设限。
看三件事：能否随时列出全部在跑的智能体、能否在异常发生时几分钟内定位并暂停、以及更换底层模型时身份与策略是否需要重建。
在给企业做智能体平台选型时，蓝曜炬辉常见的判断是：先把「身份 + 生命周期」这两个最不依赖模型的部分独立出来，再谈能力扩展。原因很直接——底层模型明年还会换，但身份、权限和审计口径一旦定下来，就能跨代复用。