企业里的 AI Agent 正从零星试验变成一组分散运行的数字化执行者：它们可能使用不同模型和框架，部署在本地、云端或多个业务系统中，还拥有调用数据库、工单平台和内部 API 的能力。WSO2 宣布 WSO2 Agent Manager 正式可用，试图用一个开源平台统一处理 Agent 的治理、身份、安全控制和运行监督。
这类产品要解决的核心问题，不是“如何再造一个 Agent”，而是“谁能创建、发布、调用和停用 Agent，以及出了问题之后能否追溯”。
Agent 蔓延为何比普通微服务更难控制
微服务通常拥有相对明确的 API、部署版本和调用关系。Agent 则多了几层动态性：
- 模型会变化：同一个 Agent 可能切换不同供应商或不同版本的模型。
- 行为由上下文决定：提示词、检索结果和工具返回值都会影响最终动作。
- 工具权限容易过大：读取知识库与修改订单，属于完全不同的风险等级。
- 部署位置分散：Agent 可能由不同团队使用不同框架开发，并运行在不同环境中。
- 责任边界模糊：当 Agent 调用了错误工具，需要区分模型判断、权限配置、提示词设计和业务数据等原因。
因此，集中治理不能只维护一张 Agent 名单。它至少需要关联 Agent 身份、负责人、模型、工具权限、环境、版本和运行记录。WSO2 Agent Manager 的定位正是跨模型、框架和部署环境提供这类统一控制面，而不是要求企业把所有 Agent 重写成同一种技术栈。
控制面应该管住四件事
1. 每个 Agent 都有独立身份
不要让多个 Agent 共用一个长期有效的服务账号。更稳妥的做法是为每个 Agent 建立独立身份，并让凭证具有明确的环境、权限范围和生命周期。这样才能回答“哪个 Agent 在什么时候调用了哪个系统”。
2. 工具访问遵循最小权限
Agent 能调用某个工具，并不意味着它可以执行该工具的全部操作。例如，客服 Agent 可以读取订单状态，但退款操作应要求更高权限，甚至加入人工确认。
3. 发布前执行策略检查
治理不能只发生在生产事故之后。Agent 清单和策略应进入 CI/CD：缺少负责人、使用未批准模型、申请高风险工具或没有生产身份时，流水线直接拒绝发布。
4. 运行记录能够关联
至少应把一次执行中的 Agent、用户或调用方、模型、工具、策略决策和最终结果关联起来。记录敏感数据时还要做脱敏与保留期限控制，不能为了可观测性把提示词中的个人信息永久保存。
一个可运行的 Agent 上线门禁
下面是一个厂商无关的最小示例，用来演示如何在流水线中检查 Agent 清单。这里的 JSON 字段不是 WSO2 Agent Manager 的官方 API 或配置格式，而是一套可以先运行、再根据实际集成接口改造的治理骨架。
创建 agent-manifest.json：
{
"name": "order-support-agent",
"owner": "commerce-platform@example.com",
"environment": "production",
"identity": "agent:order-support:prod",
"model": "approved-general-model",
"tools": [
"orders.read",
"knowledge.search"
]
}
创建 policy.json：
{
"approved_models": [
"approved-general-model",
"approved-private-model"
],
"allowed_tools": {
"production": [
"orders.read",
"knowledge.search"
],
"development": [
"orders.read",
"orders.refund",
"knowledge.search"
]
}
}
再创建 gate.py：
#!/usr/bin/env python3
import json
import sys
from pathlib import Path
manifest = json.loads(Path("agent-manifest.json").read_text())
policy = json.loads(Path("policy.json").read_text())
errors = []
for field in ("name", "owner", "environment", "identity", "model", "tools"):
if not manifest.get(field):
errors.append(f"missing required field: {field}")
if manifest.get("model") not in policy["approved_models"]:
errors.append(f"unapproved model: {manifest.get('model')}")
environment = manifest.get("environment")
allowed = set(policy["allowed_tools"].get(environment, []))
requested = set(manifest.get("tools", []))
for tool in sorted(requested - allowed):
errors.append(f"tool not allowed in {environment}: {tool}")
if environment == "production" and not manifest.get("identity", "").endswith(":prod"):
errors.append("production agents must use a production-scoped identity")
if errors:
print("Agent governance check failed:")
for error in errors:
print(f"- {error}")
sys.exit(1)
print(f"Agent {manifest['name']} passed governance checks")
运行检查：
python3 gate.py
把 orders.refund 加入生产 Agent 的 tools 后再次运行，脚本会以非零状态退出，因此可以直接接入 GitHub Actions、GitLab CI 或 Jenkins。接入真实平台时，可把本地 policy.json 替换为治理平台返回的策略结果，并在部署完成后登记版本与运行环境。
落地时不要一开始追求全量接管
更实际的采用路径是先建立资产清单，再逐步强化控制：
- 找出生产环境中真实运行的 Agent，登记负责人、模型、工具和数据范围。
- 优先为能修改业务数据的 Agent 分配独立身份，清理共享密钥。
- 先对高风险工具设置发布门禁，再扩展到模型白名单和版本策略。
- 将 Agent 执行记录接入现有审计体系，但对提示词、响应和工具参数做脱敏。
- 定期停用无人负责、长期未调用或仍使用过期凭证的 Agent。
集中式 Agent 管理平台能降低跨团队治理成本，但它不是自动消除风险的魔法层。策略过严会阻碍实验，策略过松则只会得到一份漂亮的资产目录。WSO2 Agent Manager 是否适合某个组织，最终取决于它能否接入现有身份、发布和审计流程，并让治理规则真正成为 Agent 生命周期的一部分。