凌晨两点，有个东西在往一个对象存储桶里写东西，写的速度是每分钟几十万个文件。没有人知道那是哪个 Agent，没有人知道它用的是谁的身份，也没有人知道怎么让它停下来。值班的人翻了一圈控制台，发现它根本不在任何人的 Agent 清单里。它是在某个周五下午被一个工程师用个人云账号部署的，用的是硬编码在代码里的长期密钥。这个场景把企业 Agent 常见的失控链条压缩在一起，不对应某一家公司的事故报道。读完这篇文章，你能带走两样东西：搞清楚为什么企业 Agent 的治理必须从一个独立于模型和框架的控制面入手，以及一份能真正跑起来的最小权限与审计思路，而不是一堆写在 PPT 上的原则。
WSO2 在 2026 年 9 月 15 日宣布 Agent Manager 达到通用可用状态，距离它 6 月进入 beta 只过去了三个月。这个产品的定位非常明确：它不是又一个让企业用来构建 Agent 的开发框架，而是一个把治理从 Agent 代码里硬生生剥离出来的控制面。WSO2 首席 AI 官 Rania Khalaf 在发布时说了一句很实在的话，AI Agent 的自主性和概率性行为让它们既强大又难以控制，而 Agent Manager 要做的是把 Agent 变成企业系统里被识别、被治理、被问责的一等参与者，而不是看不见的进程。这句话翻译成工程语言就是：你的 Agent 可以在任何框架里写，在任何云上跑，但它的身份、权限、生命周期和审计记录必须归到一个独立的平面上管。
InfoQ 对这次发布的解读抓住了核心矛盾：企业构建 Agent 的速度在加快，但管理 Agent 身份、权限、行为和生命周期的底层设施仍然碎片化。WSO2 在五月的发布材料引用 Gartner 预测，超过 40% 的 Agentic AI 项目可能在 2027 年被取消，原因包括成本上升、价值不清晰和风险控制不足。企业不是不想用 Agent，而是用了之后必须回答怎么管住。
WSO2 把 Agent 治理单独拎了出来
WSO2 Agent Manager 的架构选择值得拆开看。它没有把自己做成一个 Agent 运行时框架，而是把治理叠在 API、身份和工程平台之上：API 平台提供 AI 网关和工具访问控制，身份平台提供 Agent 身份和委托链，工程平台 OpenChoreo 提供生命周期管理与可观测性。已经在用 WSO2 基础设施的企业，不必从零搭一套新栈，而是在原有管道上加一个治理平面。
WSO2 把 Agent 拆成了两个概念：Agent Kind 和 Agent。Kind 是一个蓝图，里面装着代码、工具、技能和配置模式，是版本化的。Agent 是从 Kind 里生出来的运行实例，有自己的身份、自己的记忆、自己配置好的工具。一个 Kind 可以生出很多个 Agent，身份是绑在 Agent 上的，不是绑在 Kind 上的。目录是作者和运维人员碰头的地方，作者发布 Kind，运维人员浏览、选版本、配置、部署。这个模型解决了一个很实际的问题：当你有几十个 Agent 在跑的时候，你不需要为每一个 Agent 单独写一套身份和策略逻辑，你只需要确保从同一个 Kind 生出来的实例各自拿到正确的身份，然后由控制面统一注入。
Agent Manager 提供了四种交互面：控制台、命令行、MCP 服务器和 Agent 技能。MCP 服务器这个面尤其关键，它意味着 Agent Manager 自己的运维操作被暴露成了 MCP 工具，任何 MCP 感知的客户端或 AI 助手都可以驱动这个控制面。你让一个 AI 助手去暂停某个正在失控的 Agent，这件事在架构上是通的。这个设计把控制面本身也变成了一个可以被 Agent 操作的东西，但这个操作受 OAuth2 作用域约束，不是随便什么客户端都能调。
Agent Manager 以 Apache 2.0 开源，并强调框架中立和云中立。Agent 可以用 LangChain、CrewAI 或 Ballerina 构建，也可以运行在不同云环境中；控制面提供相同的身份、策略与可观测性接口。治理层的价值因此不在锁定某个模型，而在统一规则。
企业为什么会先失去对 Agent 的控制
失控不是一夜之间发生的，是一连串小决策的累积。第一个决策是身份借用。企业里大多数 Agent 在早期跑起来的时候，用的不是自己的身份，而是某个服务账号的密钥，或者更糟，是某个工程师的个人凭证。原因很简单：在 Agent 还不被当作正式工作负载的时候，没有人想过要给一个"会自己做决定的东西"发一张工牌。WSO2 的博客里点得很透：Agent 运行在借来的凭证上，是因为从来没有人给它们建过合适的身份类型。Agent Manager 做的事情是把每个 Agent 当作一等主体来处理，给它可附加的权限、可归因的行为、可撤销的访问。
身份借用会直接切断审计。当 Agent 用服务账号密钥改了一条客户记录，日志只能显示服务账号，无法回答哪个 Agent 在替谁做事。治理层要把 Agent 身份和委托用户绑定起来，让每一次出站调用都携带可验证、可撤销的凭证，而不是一段写在文档里的归属说明。
第二个决策是控制面的缺失。企业里几乎每一个技术领域都有自己的控制面：网络有网络控制面，Kubernetes 有控制面，API 有 API 网关作为控制面。但 Agent 在很长一段时间里没有。一个团队写了一个 Agent，它调用哪个模型、用哪个密钥、能访问哪些工具、什么时候停，全部写死在代码或环境变量里。等安全团队反应过来要加策略的时候，发现策略只能加在每个 Agent 的代码里，而代码分散在几十个仓库里，改一遍要几个星期。WSO2 的 AI 网关设计逻辑就是针对这个的：每一个 Agent 都会调用大模型和工具，这两类调用都会离开 Agent 进程，网关是唯一一个你能在调用落地之前统一看见、统一加策略、统一计量成本的地方。它的原话是，Agent 级别的代码无法强制执行组织级别的策略，网关可以。
Agent 蔓延的另一个维度是生命周期。一个 Agent 从开发环境到测试环境到生产环境，中间要经过什么检查？上线之后如果行为漂移了，谁来发现？如果发现它在乱花钱，怎么立刻让它停下来？WSO2 博客里提到了一个真实的场景：企业报告过 Agent 陷入循环，一晚上烧掉几万美元。这个数字不是危言耸听，它是无上限工具调用加上无速率限制的必然结果。Agent Manager 在授权参考里有一个专门的权限叫 amp:agent:suspend，拥有这个权限的角色可以立即挂起一个正在运行的 Agent 部署。这个权限的存在本身就是治理层和开发层的分离：能写 Agent 的人不一定能暂停 Agent，能暂停 Agent 的人不一定能改 Agent 的代码。
身份、权限与 MCP 的边界怎么划
MCP 是这次发布里被反复提到的一个词。它标准化了模型发现和调用工具的接口，却不替组织决定谁可以调用哪个工具、替谁调用、结果里哪些内容可以返回。治理层要夹在编排器和后端之间，消费已验证的身份与属性，做出收窄权限和返回内容的决定，并把决定写入审计流。WSO2 Agent Manager 在 MCP 层面的控制，正是把这件事做成产品。
Agent Manager 的治理边界分三层：Agent 层、MCP 层和大模型层。策略可以分别施加在这三层上。举个例子，一个组织级别的策略可以规定所有经过某个大模型提供商的调用都要做敏感信息掩码，这个策略在 Agent 层不需要任何改动就自动生效。这就是把治理从 Agent 代码里抽出来的价值：改策略不用改 Agent。WSO2 的幻灯片里把这个原则说得更直接：管理员设策略，开发者发 Agent，策略变但 Agent 不变，这让安全平面和创新平面可以各自独立伸缩。
Agent 身份在 Agent Manager 里有三个投影：人类可读的部分（名字、拥有者、团队）、工作负载的部分（Agent 在平台里跑在哪里，比如 pod 标识）、密码学的部分（密钥和令牌，用来在网络上证明它就是那个 Agent）。三个投影必须一致地存在一起。身份被签发和注入到运行 Agent 的具体工作负载里，然后用来决定这个 Agent 在它的身份下能触达哪些大模型、MCP 和工具，每一个动作都会被记录并映射到 Agent 的唯一身份上。这里有一个很关键的设计选择：身份不是绑在代码仓库上的，是绑在运行实例上的。同一个 Kind 生出来的不同 Agent 实例拿到的是不同的身份，各有各的权限边界。
委托链是 Agent 身份里最难做对的部分。一个 Agent 替用户做事，最终权限应是用户与 Agent 权限的交集，而且在调用链上传递时只能收窄。WSO2 把委托和 token exchange 放进 Agent Manager，企业选治理平台时，必须问清楚这个收窄语义能否在每次调用和审计记录里保留下来。
Agent Manager 的授权模型把动作映射为 OAuth 2.0 作用域，例如 amp:project:read 和 amp:agent:suspend。无论从控制台、REST API 还是 MCP 服务器进入，同一个作用域控制的都是同一个能力。预置角色把项目、Agent、模型和工具的权限拆开，管模型的人不必拥有改 Agent 代码的权力，管 Agent 的人也不必拥有改模型接入策略的权力。
沙盒运行时和可观测性如何接上生产
Agent 的沙盒问题和普通容器隔离有一个根本区别：Agent 生成的代码是不可信的。一个 Agent 可能会在你看不到的地方生成并执行一段代码，这段代码可能会删文件、改配置、往外发数据。Kubernetes 社区在 2026 年 3 月正式讨论了 Agent Sandbox 这个项目，它的定位很清晰：当 AI Agent 自主生成并执行代码的时候，安全是首要的，Sandbox 自定义资源原生支持 gVisor 或 Kata Containers 这样的运行时，提供多租户、不可信执行所需的内核和网络隔离。
普通微服务通常持续运行，而 Agent 可能空闲数小时后突然执行任务，执行完又回到空闲状态。因此沙盒不能只解决进程隔离，还要和暂停、恢复、吊销身份放在同一条生命周期链里。空闲时可以回收资源，任务开始时重新挂载受控的网络和文件权限；发生异常时，运维人员应能暂停实例并保留完整追踪，这才是生产门槛。
WSO2 Agent Manager 的通用可用版本引入了一个 Kubernetes 原生的沙盒运行时。它的设计目标和 Kubernetes 社区的方向一致：给 Agent 一个受控的执行环境，同时让它的活动可以被监控和管理。WSO2 在介绍里强调了这个运行时是零信任的，有隔离和生命周期控制，包括实时干预。把沙盒和生命周期控制放在一起看，治理的闭环才成立：隔离解决的是 Agent 不能乱动，生命周期控制解决的是你能在它乱动的时候把它按住。
可观测性是治理的另一个支柱。WSO2 Agent Manager 的可观测性建立在 OpenTelemetry 的 GenAI 语义约定上。它的做法是提供一个 Python 库 amp-instrument，平台托管的 Agent 由平台预先接好，外部托管的 Agent 由开发者自己加进去。所有 Agent 的可观测性走同一个标准，不因为框架不同而不同。追踪的粒度是 span 级别的，你在控制台里能看到 Agent 实际做了什么，而不只是一个汇总仪表盘。WSO2 的幻灯片里描述了可观测性的一个具体用途：用过去追踪的数据来跑评估，规则可以基于正则、结构化检查或确定性门禁，也可以让大模型根据评分标准来评估一个 span，评分结果以标签形式挂在 span 上。
评估这件事在 Agent 场景里比在传统软件里更必要，因为 Agent 的行为是概率性的，同样的输入不一定产生同样的输出。微软在 Azure 上的多 Agent 学习路径里专门讨论了对话级评估和轮次级评估的区别：轮次级评估只看最后一个回答，对话级评估看整个交互过程。它举了一个客服 Agent 的例子，用户三次说没收到重置密码的邮件，Agent 三次都说已经发了，轮次级评估给最后一次回答打了高分因为它礼貌且有动作，但对话级评估会标记这个 Agent 重复同一个失败动作而没有尝试替代方案，用户的问题始终没解决。WSO2 Agent Manager 的评估框架同时支持基于规则和基于大模型裁判的评估器，可以用来发现意外的 token 消耗、行为变化或响应质量下降。这些能力放在一起才构成生产级的可观测性：你不只知道 Agent 调用了什么，你还知道它做得对不对。
用一段代码看懂治理层的最小闭环
把上面这些概念落成一个能理解的最小闭环，不需要真的去装一套 Agent Manager，但需要理解治理层在代码层面到底管什么。下面这段可以直接运行的 Python 小程序，展示治理层在 Agent 的一次出站调用里应当做什么。它不依赖任何特定框架，重点是把控制点写成可执行的检查。
from dataclasses import dataclass, field
from typing import Any
@dataclass
class Policy:
allowed_tools: set[str]
max_calls: int
calls: int = 0
@dataclass
class GovernedAgentCall:
agent_id: str
user_id: str
policy: Policy
audit: list[dict[str, Any]] = field(default_factory=list)
def execute(self, tool: str, params: dict[str, Any]) -> dict[str, Any]:
if tool not in self.policy.allowed_tools:
return self._record("denied", tool, "tool is outside the agent scope")
if self.policy.calls >= self.policy.max_calls:
return self._record("denied", tool, "rate limit reached")
self.policy.calls += 1
result = {"tool": tool, "accepted": True, "params": params}
self.audit.append({"agent": self.agent_id, "on_behalf_of": self.user_id,
"action": "allowed", "result": result})
return result
def _record(self, action: str, tool: str, reason: str) -> dict[str, Any]:
item = {"agent": self.agent_id, "on_behalf_of": self.user_id,
"action": action, "tool": tool, "reason": reason}
self.audit.append(item)
return item
if __name__ == "__main__":
policy = Policy(allowed_tools={"ticket.read"}, max_calls=2)
call = GovernedAgentCall("agent-warehouse", "user-chen", policy)
print(call.execute("ticket.read", {"ticket_id": "T-100"}))
print(call.execute("ticket.delete", {"ticket_id": "T-100"}))
print(call.audit)这个闭环的核心不在代码本身，在几个设计选择。权限检查发生在调用发起之前，不在调用返回之后。委托收窄是取交集，不是取并集。实际调用通过网关走，Agent 进程里没有工具的长期密钥。审计记录里同时有 Agent 身份和委托用户身份。这四件事各自看起来都很简单，但把它们同时做对的 Agent 实现，在 2026 年并不多见。WSO2 Agent Manager 的授权参考里，Agent 相关的权限包括 amp:agent:build、amp:agent:env-production、amp:agent:suspend 和 amp:agent:rollback，这些权限的存在意味着治理层把 Agent 的整个生命周期都纳入了同一个权限模型里。
从单个平台到多模型组织的迁移账
迁移时要算一笔实际的账。一个企业如果现在已经有几十个 Agent 在跑，分散在不同团队的不同框架里，迁移到 Agent Manager 这类控制面上要付什么代价。WSO2 的设计里有一个降低迁移摩擦的选择：它支持外部托管的 Agent，也就是 Agent 可以跑在别的地方，云上或本地，Agent Manager 只负责可观测性、访问控制和治理。这意味着迁移不是"把所有 Agent 搬到 WSO2 的运行时里"，而是"让所有 Agent 在控制面上注册，然后把出站调用导到网关后面"。已经在跑的东西可以不动，治理层接上就行。
迁移的第一笔账是身份迁移。现有的 Agent 里有多少在用工单上的服务账号密钥或工程师的个人凭证？这些凭证需要被替换成 Agent 自己的身份。WSO2 Agent Manager 的 Agent 身份有三个投影，其中密码学投影就是用来替换长期密钥的。每一条出站调用携带的是 Agent 自己的令牌，这个令牌由治理层签发，可以随时吊销。Agent Passport System 的草案里提到的级联吊销是一个值得关注的特性：吊销一个委托，所有下游的派生委托全部失效。对于企业来说，这意味着你不需要去追踪每一个 Agent 用了什么密钥，你只需要吊销一个委托节点，后面的链条自动断掉。
迁移的第二笔账是策略迁移。现在有多少策略是硬编码在 Agent 代码里的？速率限制、敏感信息过滤、允许调用的工具列表。这些策略要从代码里搬到治理层。WSO2 Agent Manager 提供了超过 40 个内置策略，覆盖敏感信息掩码和速率限制，可以施加在 Agent、MCP 和大模型三个层面。组织的策略和大模型提供商级别的策略是继承关系，改了提供商级别的策略，所有用这个提供商的 Agent 自动生效。策略迁移的代价不在于写新策略，在于找出旧策略然后确保搬过去之后行为一致。
迁移的第三笔账是评估和审计的基线。在迁移之前，你大概率没有 Agent 的行为基线，你不知道它的正常表现是什么样，所以你也无法判断它什么时候异常。WSO2 Agent Manager 的做法是从 Agent 加入的第一天就开始做仪表化和追踪，用历史追踪数据跑评估，建立一个分数基线，然后同一个监测器在发布后转为连续模式，持续用同一个标准来检查。这个思路的迁移含义是：你不需要等所有 Agent 都迁移完才建基线，你可以先接一个 Agent，建它的基线，再接下一个。
多模型组织的现实是，不同的团队会用不同的模型，因为不同的任务需要不同的成本和质量平衡点。WSO2 Agent Manager 把模型选择从 Agent 代码里抽到了平台层：开发者请求"一个模型"，平台决定出站调用路由到哪个模型、用哪个凭证。这个抽离带来的迁移价值是，当企业决定从某个模型提供商换到另一个的时候，改的是平台配置，不是每一个 Agent 的代码。WSO2 博客里说得很清楚：通过平台的模型提供商配置换掉一个 Agent 的模型，改的是模型，不碰 Agent 的身份、凭证或追踪历史。对于多模型组织来说，这是控制面最实际的回报：模型会变，框架会变，但身份、权限和暂停按钮留在原地。
回到开头那个凌晨两点的场景。如果那个写数据的 Agent 在治理层里有身份，它的出站调用会经过网关，审计记录里会有它的 Agent 标识和委托用户。如果它有速率策略，写到一定量的时候会被拦住。如果拥有暂停权限的人看到了告警，一个命令就能让它停下来。这四个"如果"对应的是治理层的四个能力：身份、策略、可观测性和生命周期控制。WSO2 Agent Manager 的发布给了企业一个现成的选择，但选择本身不重要，重要的是企业要意识到控制面必须独立于 Agent 本身存在。Agent 的框架会换，模型会换，云会换，但如果身份、权限和暂停按钮绑在 Agent 的代码里，每一次换都是一次治理的重建。企业真正要买的不是更多 Agent，而是一个能在模型和框架变化时仍然保留身份、权限和暂停按钮的控制面。