不是又一个框架，而是框架上面那层

WSO2 Agent Manager 已正式 GA。它把自己定位成控制面：不改你的智能体逻辑，而是提供身份、策略与可观测性这些安全与合规团队反复索要的能力。官方明确它兼容 LangChain、CrewAI、Amazon Bedrock Strands 与 Microsoft Agent Framework 等既有框架，换成自定义实现也能通过 OpenTelemetry、OpenAPI 与 MCP 接入。

这个定位解决的是一个具体问题：企业的智能体往往分散在不同团队、不同框架、不同模型上，每个框架有自己的权限模型与日志格式，结果就是没有人能回答「生产里到底跑着多少个智能体、它们各自在调什么工具、用的是谁的凭据」。

GA 版补的三块

  • 智能体身份：通过 OAuth 2 扩展给每个智能体一个可验证的机器身份，并覆盖 MCP 交互的治理；
  • 运行时隔离：Kubernetes 原生的沙箱运行时；
  • 护栏与评测：内置 40 多条映射到 OWASP LLM Top 10 的护栏，另有 24 项内置评测用于生产监控。

可观测性这一块值得单独看：它由 amp-instrumentation Python 包与一个 Kubernetes init 容器实现，无需修改代码就能给存量智能体自动埋点，输出 OpenTelemetry 的 traces、metrics 与日志。对已经在 Kubernetes 上跑智能体的团队，官方给出的起步方式是一条 Docker 命令。

把「不生成文本」换成「不改存量代码」：能不能自动埋点，决定了治理层能否真正铺开。

自托管的代价与判断标准

Apache 2.0 意味着可以自托管、数据留在自己这边；代价是控制面本身成为需要运维、升级与排障的系统，也会进入你的故障域。托管 SaaS 省掉这部分，但要把身份与审计数据托管出去，这在受监管行业往往需要单独评估。

是否值得引入，可以用三个问题判断：生产环境中跨框架的智能体是否超过两个；是否需要在发布前统一拦截高风险工具调用；审计与合规是否要求给出「谁在什么时候以什么身份调用了什么」。三个里有两个为是，这类控制面的收益通常大于它的运维成本。