Agent规模化治理与持续运营：从“几十个智能体”迈向企业级控制平面

当企业只运行一两个 Agent，Prompt、模型和工具配置尚可由开发者记住，异常也能靠人工追踪；当 Agent 数量增长到几十甚至上百，治理对象便从"模型输出"变成了一组持续获得授权、调用工具、改变业务状态并消耗预算的数字执行单元。此时，版本、Owner、身份权限、运行状态、反馈、成本和退役必须被统一进一个可执行的控制平面。

本文基于 2025---2026 年公开的最新标准、工程实践与监管进展，提出"一个清单、两条链、三类责任、四级自治、五个运行回路"的规模化治理方法，并给出 90 天实施路线。

一、规模拐点：从管理功能，转向管理被委托的行动权

（一）Agent 的危险在于"能行动"

单个聊天机器人出现错误，通常意味着一段文本需要纠正；一个具备工具调用、长期记忆和工作流编排能力的 Agent 出现错误，则可能意味着一封邮件已经发送、一笔退款已经执行、一条客户记录已经修改，或者一个子 Agent 已经带着继承而来的权限继续扩散任务。二者都使用大模型，但风险结构完全不同。

因此，Agent 的治理边界不能停留在模型名称、Prompt 内容或输出审核上。治理对象应当是"被委托的行动权"：谁授权它在什么情境下，为谁读取哪些数据、调用哪些工具、执行哪些动作、花费多少资源，以及当条件变化时如何撤回权限。世界经济论坛在 2026 年提出的 Agent Capability and Authorization Profile（ACAP）同样把关注点放在部署级的能力与授权画像上，强调委托政策、系统设计和运行监督必须结合，才能让 Agent 的行动可审计、可执行约束并且有人承担责任。 $1$

这带来一个关键判断：规模化治理的最小单元不是 Agent 的名字，而是一次可复现、可授权、可回滚的 Agent Release（发布单元）。同一个"销售助理"换了模型、Prompt、工具版本或知识库快照，行为边界就可能发生实质变化；如果注册表仍把它视为同一个静态对象，组织看到的将是一个名称没变、能力却悄然漂移的"忒修斯之船"。

当 Agent 数量增加、自治程度和工具范围扩大时，管理重心会从单点 Prompt 调优转向企业级控制平面。

1、三个同时发生的放大效应

1.1 组合放大

一个 Agent 往往由模型、系统指令、工具、连接器、知识源、记忆、运行时和安全策略组合而成。每个组件单独升级都可能"看起来兼容"，组合后却产生新的行为。传统应用发布关注代码依赖，Agent 发布还必须关注语义依赖：提示词对新模型的解释是否变化，工具描述是否诱导了另一条路径，知识源更新是否改变事实依据，记忆压缩是否丢失了约束。

1.2 权限放大

人类员工通常通过岗位、组织和审批链获得权限；Agent 则可能同时使用服务身份、代表用户的委托令牌和工具自身的密钥。如果这三类身份没有被拆分，所谓"最小权限"往往只是把某位高权限用户的全部能力交给了一段非确定性执行逻辑。AWS 的最新 Agentic AI 安全指南将 act layer 视为最高操作风险区域，因为合法工具能力一旦被误用，影响会直接落到生产系统与敏感数据上。 $2$

1.3 速度放大

人类操作有注意力、工作时间和审批摩擦，Agent 可以在数秒内连续发起多次调用、创建子任务并重试。错误因此不仅是"发生概率"，还乘上了执行频率、并发度和传播深度。一个 0.1% 的单步异常，在数万次工具调用中不再罕见；一个可递归派生子 Agent 的设计，还会把局部错误变成级联故障。

2、规模化之后最常见的七类失控

第一类是幽灵 Agent：创建者已经离职、团队已重组，Agent 仍在运行，没人知道谁能决定停机。微软 2026 年更新的企业 Agent Registry 已把"无 Owner""未纳管 Agent"和"影子 Agent"列为需要单独识别的对象，这说明所有权空洞已从管理问题变成产品必须直接支持的风险信号。 $3$

第二类是版本漂移：界面上仍显示 v1，但底层模型被供应商更新，知识库每日变化，工具端点也已换版。事故发生后，团队无法还原"当时究竟运行了什么"。

第三类是权限累积：Agent 为解决一个临时需求获得额外数据源和工具，却没有到期时间；几个月后，它的实际权限远超最初声明的业务目的。

第四类是反馈失真：满意度按钮只覆盖愿意反馈的少数用户，自动评测又只覆盖合成样本，团队用一个平均分掩盖了高风险场景的尾部失败。

第五类是成本失速：推理循环、工具调用风暴、记忆不断增长，月度账单只能事后告诉管理者发生了什么。AWS 的 Agentic AI Lens 因此建议在单次循环、单任务和单日多个层级设置预算与自动截断，并把成本异常与 Agent 特有的行为信号关联。 $4$

第六类是运行盲区：传统 APM 能看到接口慢，却解释不了 Agent 为什么选择了错误工具、为什么重试十次、哪一次检索把它带离目标。

第七类是退役不完整：前端入口关闭了，但服务身份、定时任务、向量索引、缓存、记忆和下游订阅仍然存在，留下成本、数据保留和安全隐患。

（二）传统软件治理为何不够用

传统软件治理仍然重要，但它默认"相同输入和相同代码大体产生相同路径"。Agent 的路径会受模型采样、上下文、工具返回、外部状态和长程记忆共同影响，即使起点相同，也可能沿不同轨迹到达同一结果，或者在中途改变任务计划。Anthropic 在多 Agent 研究系统的工程复盘中指出，Agent 是有状态的，错误会沿长流程累积；生产部署不能一次性切换所有运行中的 Agent，而需要让新旧版本并存并渐进迁移流量。 $5$

这并不意味着放弃软件工程，而是要把软件工程从"代码版本"扩展为"行为发布工程"：

代码审查扩展为 Prompt、工具描述、策略和评测集审查；
单元测试扩展为结果、轨迹、状态变化和安全边界的组合评测；
应用监控扩展为模型调用、工具调用、决策节点、成本和业务结果的全链路追踪；
账号权限扩展为 Agent 身份、用户委托、动态条件和短期凭证；
灰度发布扩展为按风险等级、业务场景和自治级别分流；
下线服务扩展为撤销身份、清理记忆、停止触发器和保存审计证据。

换言之，企业不是另起炉灶建设"AI 特区"，而是在 SDLC、IAM、SRE、FinOps、数据治理和模型风险管理之间增加一个 Agent 原生的协调层。

二、统一治理对象：建立 Agent Release 与企业注册表

（一）先回答"企业到底有多少 Agent"

很多企业无法准确回答这个问题。原因不是没有资产台账，而是不同团队对 Agent 的计数单位不同：业务把一个用途算一个，平台把一个部署算一个，安全把一个身份算一个，财务把一个调用项目算一个。结果是各张表都"正确"，合起来却无法行动。建议采用三层对象模型：

1、Agent Product：稳定的业务承诺

Agent Product 代表用户认知中的长期能力，例如"采购询价助手"或"客户退款处理 Agent"。它拥有业务 Sponsor、产品 Owner、目标用户、价值指标和风险等级。Product 不应因换模型或改 Prompt 就新建，但业务目的改变时必须新建。

2、Agent Release：可复现的发布单元

Agent Release 是治理、批准和回滚的最小单位。每个 Release 至少冻结以下指纹：

agent_id 与 release_id；
Prompt／系统指令的内容哈希与版本；
模型提供方、模型版本、关键参数和路由规则；
工具清单、工具 schema、连接器和端点版本；
知识源集合、索引版本与数据新鲜度策略；
记忆类型、作用域、保留期和清理规则；
身份、授权策略、可执行动作与审批条件；
评测集、通过阈值、已知限制与适用范围；
运行时镜像、编排代码、依赖清单和区域；
Owner、值班组、成本中心、SLO 和退役日期。

AWS 对"Prompt as code"的建议很有启发：Prompt 应与具体模型、参数和评测结果一同进入版本控制，生产变更接受与代码相同的评审和审批。 $2$ 但企业还应再向前一步，把 Prompt 只是当作 Release Manifest 的一个组成部分，而不是把"提示词仓库"误认为完整治理。

3、Agent Instance／Run：运行中的实例与一次执行

Instance 是某个 Release 在特定租户、区域或业务单元的部署；Run 是一次具体任务。事故响应需要从 Run 追溯到 Instance，再定位到 Release 和 Product。没有这条链，团队只能从零散日志猜测责任归属。

Agent Release 不是一个 Prompt，而是模型、指令、工具、知识、记忆、策略、评测和运行时的不可分割组合。

（二）注册表不是目录，而是控制平面的事实源

一个成熟的 Agent Registry 至少承担发现、准入、授权、运行和退役五类职责。它既面向人，也面向自动化系统：开发门户从中查询模板，网关从中加载策略，监控平台从中关联 Owner，财务系统从中归集成本，事件平台从中找到值班组。

1、最小可用字段模型

注册表第一版不必追求一百个字段，但以下字段不可缺少：

|------|----------------------------------|------------|
| 维度 | 必填信息 | 自动控制用途 |
| 身份 | Product ID、Release ID、实例 ID、非人身份 | 认证、追踪、撤销 |
| 责任 | 业务 Sponsor、产品 Owner、技术 Owner、值班组 | 审批、告警路由、升级 |
| 目的 | 业务目标、目标用户、禁止用途 | 适用性检查、审计 |
| 能力 | 模型、工具、数据源、记忆、子 Agent | 攻击面与依赖分析 |
| 授权 | 可读、可建议、可执行动作、条件和上限 | 策略执行、审批 |
| 风险 | 自治级别、影响范围、数据级别、法规标签 | 分级控制 |
| 质量 | 评测集、阈值、SLO、已知限制 | 发布门禁、健康评分 |
| 经济性 | 成本中心、预算、单位成本目标 | 限额、归集、优化 |
| 生命周期 | 状态、发布日期、复审日、到期日 | 自动复审、退役 |

微软的 Agent Registry 公开文档已经支持按状态、发布者类型、渠道、平台和数据源过滤，并显式展示无 Owner、未纳管和高风险 Agent。 $3$ 这说明注册表的价值不在于"有一个列表"，而在于列表中的字段能触发控制动作。

2、用状态机代替"上线／下线"二元标签

建议采用八态生命周期：草拟、开发、沙箱、受控试点、生产、受限、隔离、退役。每次状态迁移都应有机器可验证的门槛。

状态迁移必须伴随证据与控制变化；"受限"和"隔离"让组织在全停与全放之间拥有可操作的中间态。

从沙箱到试点，应要求明确 Owner、完成威胁建模、通过基础评测并设置预算；从试点到生产，应增加真实流量评估、应急预案和业务 Sponsor 签字；从生产到受限，可自动禁用写操作、降低并发或切换只读模式；进入隔离态则撤销运行身份、保全证据并停止触发器；退役前必须完成数据与密钥清理。

状态机的意义是让治理成为运行时能力。发现异常时，系统不必等待委员会开会才能做出唯一选择"关或不关"，而可以把 Agent 降级为建议模式、限制到小流量、暂停高风险工具，给调查争取时间。

三、权限治理：把"能做什么"收缩为可执行的授权包络

（一）以自治级别和影响半径决定控制强度

Agent 治理最常见的错误，是对所有 Agent 使用同一套审批。低风险知识问答被层层阻塞，促使业务绕开平台；高自治 Agent 又因为"已通过 AI 审核"而获得过宽权限。更合理的方法是同时考虑自治程度与影响半径。

1、四级自治模型

一级"观察"：只读取已批准数据，不生成对外建议，不改变状态。二级"建议"：可以分析和提出行动，但由人类决定是否执行。三级"经批准执行"：Agent 生成具体动作，满足条件或获得逐次批准后执行。四级"自主执行"：在预先定义的边界内自行计划和行动，人类进行事后监督。

自治级别不是能力荣誉，而是控制变量。模型更强不意味着应该自动升级自治；只有当业务价值、评测证据、运行可观测性和故障恢复能力同时成熟，自治才可以提高。

2、影响半径模型

影响半径至少由五个因素组成：数据敏感度、动作可逆性、单次金额或资源上限、影响对象数量、传播能力。一个只能修改自己草稿的 Agent 与一个能向全部客户发信的 Agent，即便调用同一个模型，也应属于不同风险等级。

控制强度应随自治级别和影响半径共同上升，高自治且影响广的 Agent 必须采用短时授权、强门禁与实时终止能力。

可以把风险分数写成简单而透明的函数：

风险暴露 = 自治系数 × 影响半径 × 不确定性 × 暴露频率 ÷ 可恢复性

它不必成为精确数学真理，但能迫使团队讨论真实变量。尤其要把"可恢复性"放入分母：同样是错误写入，有事务回滚和人工复核的系统，与不可撤回的外部转账或公开发布，风险完全不同。

（二）每个 Agent 都需要独立、可撤销的非人身份

共享服务账号是规模化治理的天敌。它让审计无法区分哪个 Agent 做了什么，也使撤销某个 Agent 权限时只能影响整组应用。NIST 在 2026 年启动 AI Agent Standards Initiative，把 Agent 认证、身份基础设施与安全评测列为战略研究方向；微软 Entra Agent ID 则已提供专门的 Agent 身份及其父子蓝图关系，并将自适应访问、风险检测、生命周期和审计扩展到非人身份。 $6$ $7$

1、身份要分三层

第一层是Agent 身份，证明"哪个 Release 的哪个实例在行动"；第二层是用户委托身份，证明"代表谁行动、委托范围是什么"；第三层是工具会话身份，证明"本次调用在什么条件下获得短时能力"。三层凭证不能被一个长期密钥替代。

1.1 运行时授权上下文

每次高风险调用都应携带最小上下文：主体、Agent Release、用户委托、目的、资源、动作、金额或数量上限、地理与设备条件、有效期、审批证据和追踪 ID。策略引擎依据上下文作出允许、拒绝、降级或要求二次批准的决定。

1.2 权限必须有"预算"和"时间"

传统 RBAC 只表达"能不能"，Agent 还需要表达"能多少、能多久、能在什么条件下"。例如，退款 Agent 可在已验证身份且订单状态满足条件时，自主执行单笔 100 元以内、单日总额 5000 元以内的退款；超过阈值进入人工批准。这样的授权包络比"拥有退款 API 权限"更接近真实业务责任。

2、工具治理要从接入审批走向调用时策略

工具目录需要记录维护者、数据域、动作类型、幂等性、回滚方式、速率限制、输入输出分类、依赖与健康状态。任何能够改变外部状态的工具，都应支持 dry-run、幂等键、限额和审计回执。对不可逆动作，应优先把"自然语言决定"与"确定性执行"分开：模型负责提议，策略和代码负责验证与提交。AWS 的指南也建议，在确定性逻辑足以完成的地方不使用 AI，以缩小攻击面、降低成本并提高可测试性。 $2$

连接器和 MCP 服务器不能因为"支持标准协议"就自动可信。标准化提高互操作性，也会扩大供应链传播面。每个外部工具都应进入供应商评估、网络隔离、数据出境、版本兼容和应急停用流程。

（三）运行时防护应当是多层、可降级的

一条有效的控制链包含：输入分类与注入检测、上下文最小化、模型前策略、工具选择策略、参数验证、执行前审批、输出过滤、状态核验和事后审计。OWASP 2026 Agentic Top 10 将面向自治系统的关键风险集中呈现，提醒团队不能只做 Prompt Injection 过滤，还要覆盖过度代理、工具滥用、身份与权限、记忆和供应链等更广的攻击面。 $8$

更重要的是，每层防护都应定义失败时的降级模式：

策略服务不可用时，写操作默认拒绝，读操作按数据等级决定是否降级；
评测信号异常时，自动降低自治级别而不是继续全量运行；
工具健康下降时，Agent 应停止重试风暴，切换替代工具或请求人工；
成本接近上限时，先减少并发、缩短上下文、切换较小模型，再触发硬停止；
无法验证用户委托时，退回"建议但不执行"。

"可降级"让安全、可靠性和业务连续性不再互相排斥。

四、质量治理：把反馈变成持续可执行的评测资产

（一）Agent 质量不是一个平均准确率

Agent 的成功至少包括五个维度：结果正确、过程合规、状态正确、资源合理、体验可接受。只看最终文本，会漏掉它是否调用了未经批准的数据；只看工具轨迹，又可能把一条不同但合理的路径误判为失败。

1、建立分层评测金字塔

底层是确定性检查：schema、权限、参数范围、状态变化、单元测试和安全扫描，速度快且可复现。中层是模型评分：根据清晰 rubric 评估事实、完整性、引用、语气和策略遵循。上层是专家与真实用户：处理主观质量、高风险判断和模型评分校准。

Anthropic 2026 年的 Agent 评测实践建议组合代码、模型和人工三类 grader，并区分 capability eval 与 regression eval：前者寻找能力边界，后者保护已具备的能力不倒退；已经成熟的能力测试应进入持续回归套件。 $9$ 这正是 Agent 发布门禁需要的结构。

2、从"测试样例"升级为"风险覆盖矩阵"

测试集不能只按业务意图分类，还应覆盖权限边界、数据级别、工具故障、上下文污染、并发冲突、长程任务、成本上限和对抗输入。每个高风险动作都要有正向、拒绝、降级和恢复用例。

建议把评测结果拆成四类指标：

结果指标：任务完成率、最终状态正确率、事实准确率、引用支持率；
过程指标：必要验证是否完成、禁用工具是否被调用、审批是否绕过、无效循环次数；
安全指标：越权率、敏感数据泄露率、注入成功率、策略拒绝准确率；
效率指标：每成功任务 Token、工具调用数、时延、成本和人工接管时间。

不要把所有指标压成一个总分。总分可用于排序，但发布门禁应保留硬性红线：例如高风险越权必须为零，关键状态正确率必须达到 99.9%，即使平均体验分很高也不能抵消。

生产信号经过分诊和脱敏后进入评测资产；每次修复必须形成可复现样例，并通过灰度验证回到生产。

（二）让生产失败自动进入"学习队列"

真正有价值的反馈闭环不是收集更多差评，而是把真实失败转化为工程资产。每个事件都应完成五步：关联对应 Release 与 Run；判断是模型、Prompt、工具、数据、策略还是环境问题；对敏感内容脱敏；生成最小可复现任务；加入回归集并指定 Owner。

1、信号来源要互相校准

自动评测速度快但可能偏离真实使用；生产监控覆盖真实分布但缺少标准答案；用户反馈真实却稀疏且自选择；人工复核质量高却昂贵。Anthropic 的实践明确指出，没有单一评测层能捕获全部问题，成熟团队会组合自动评测、生产监控、A/B 测试、用户反馈、抽样阅读和周期性专家研究。 $9$

因此，企业应规定"哪个信号负责发现、哪个信号负责确认、哪个信号可以阻断发布"。例如，用户投诉触发调查，但不能仅凭一个差评自动回滚；高置信越权检测可以立即隔离；模型评分下降需要抽样人工校准后再决定。

2、反馈数据本身也需要治理

生产轨迹可能包含个人信息、商业秘密和凭证。不能为了改进 Agent，把全部 Prompt、工具参数和结果无限期写入评测平台。应分别配置内容捕获、脱敏、采样、保留期和访问权限；高敏场景只保留结构化元数据与经过批准的重放样本。

（三）把发布门禁嵌入 Agent CI/CD

一次 Agent 变更应触发影响分析：改 Prompt 需要重跑语义与安全回归；换模型需要重跑能力、拒答、工具选择和成本基线；新增工具需要重做威胁模型与权限审批；知识源变化需要验证权限继承、事实新鲜度和删除同步。

发布策略建议采用"影子---金丝雀---分层扩量---稳定"四步。影子阶段只观察不执行；金丝雀阶段选择低影响用户与可回滚动作；分层扩量按场景和风险而非简单按百分比分流；稳定后仍保留旧 Release 一段时间，以便正在执行的长程任务完成或安全迁移。Anthropic 的生产经验显示，多 Agent 系统中的运行状态分散在提示词、工具和执行逻辑中，渐进式并行部署比全量切换更能保护在途任务。 $5$

五、运行治理：用 Agent SRE 连接可观测性、SLO 与事故响应

（一）从"调用日志"升级为决策链追踪

每次 Run 都应有贯穿模型、检索、策略、工具、子 Agent 和业务系统的 Trace ID。最小事件模型应记录：谁发起、使用哪个 Release、输入属于哪类任务、模型调用耗时和 Token、工具名称与结果码、策略决策、审批节点、状态变化、最终结果、成本与用户反馈。

OpenTelemetry 在 2026 年发布的 GenAI 可观测性实践已经标准化模型名称、输入输出 Token、完成原因等语义属性，并能用 invoke_agent、chat、execute_tool 这样的 span 结构呈现 Agent 调用树。 $10$ 企业应利用这类开放语义约定减少平台锁定，但需要增加业务字段：订单 ID 不必明文记录，却要有可关联的业务对象哈希；工具成功不等于任务成功，还要记录最终状态核验。

基础设施、模型、工具、策略和业务结果共用同一条 Trace，才能区分"系统成功但业务失败"。

1、内容可观测性与隐私最小化必须分开设计

完整 Prompt 和工具参数有助于调试，却可能包含敏感信息。OpenTelemetry 的相关实践默认只记录模型、Token 和时延等元数据，只有显式启用才捕获完整内容，这个默认值得沿用。 $10$ 推荐将遥测分为三档：

L0 元数据：全量保留，用于性能、成本与依赖分析；
L1 脱敏摘要：按风险采样，用于质量与决策模式分析；
L2 完整内容：仅在用户授权、事故取证或受控评测中短期保留。

2、关注"决策模式"，而不只是内容

高价值信号包括：计划重写次数、无进展循环、工具切换频率、同一参数重复调用、子 Agent 数量、人工接管点和策略拒绝后行为。Anthropic 在多 Agent 系统中发现，即使不检查个人对话内容，监控决策模式和交互结构也能帮助定位根因。 $5$ 这为隐私敏感企业提供了折中方案。

（二）为 Agent 定义多维 SLO

传统服务常以可用性和时延为核心，Agent 还需要"正确完成"和"安全行动"。建议建立五类 SLO：

1、可靠性与质量 SLO

包括任务成功率、最终状态正确率、关键事实支持率、工具调用成功率、长任务恢复率。对不同场景分别定义，不用一个全局平均值掩盖差异。

2、安全与合规 SLO

包括越权执行为零、审批绕过为零、敏感数据泄露率、策略判定时延、审计事件完整率、撤销传播时间。法律或内部政策要求应转化为机器可验证控制和证据，而不是只留在制度文档。

3、体验 SLO

包括端到端时延、首次有用响应时间、人工接管率、重复询问率和用户纠错成本。Agent "最终做对但让用户等十分钟"未必符合业务需要。

4、效率 SLO

包括每成功任务成本、Token／成功任务、工具调用／成功任务、无效循环率和模型路由命中率。

5、可运营性 SLO

包括 Owner 覆盖率、版本可追溯率、告警可路由率、回滚时间、孤儿 Agent 数量和逾期复审率。这些指标直接衡量治理系统是否真的运转。

（三）事故响应要预设"终止、降级、回滚、恢复"

Agent 事故不能只靠"修 Prompt"。应建立独立 Runbook：越权、数据泄露、错误批量操作、提示注入、工具供应链、循环与成本风暴、模型质量漂移、记忆污染、无 Owner 运行。每个 Runbook 指定检测信号、第一响应者、立即动作、证据保全、用户沟通、恢复门槛和复盘 Owner。

先停止损害，再缩小能力，随后回滚到已知良好版本，最后以新增回归样例完成恢复。

"Kill switch"也不能只是一个按钮。它必须能在身份、网关、调度器、工具和消息队列多个位置生效，并验证所有在途任务已经停止。恢复时同样要逐步放量，确认记忆、缓存和外部状态没有残留污染。

六、成本治理：从 Token 账单转向每个业务结果的单位经济性

（一）成本必须归因到 Agent、任务和结果

多 Agent 架构可能用性能换取大量 Token。Anthropic 的公开数据表明，其 Agent 交互约使用聊天交互的 4 倍 Token，多 Agent 系统约使用 15 倍；因此只有高价值、可并行、复杂度足够的任务才值得采用这种结构。 $5$ 这揭示了一个常见误区：团队展示任务成功率提高，却不展示达到该成功率所需的资源增幅。

成本台账至少要拆到成本中心 → Agent Product → Release → Instance → Run → 模型／工具／检索／存储。只有这样，财务才能知道钱花在哪里，工程才能知道哪个环节需要优化，业务 Owner 才能判断是否值得。

1、定义结果型单位成本

"每百万 Token 价格"是供应商指标，不是企业价值指标。更有意义的是：每成功解决工单成本、每合格线索成本、每完成对账成本、每份被采用报告成本、每次人工节省小时成本。成本必须与质量共同报告，因为便宜但失败的执行并不经济。

FinOps Foundation 建议同时管理成本效率、技术性能和业务影响，并向工程与产品 Owner 提供足够细的行动指标。 $11$ 企业可采用下式作为统一讨论语言：

单位有效成本 = 总运行成本 ÷（成功任务数 × 质量权重 × 业务采纳率）

质量权重和采纳率能防止团队用大量低价值自动完成"做大分母"。

2、把人工成本和风险成本算进去

如果 Agent 每次节省五分钟，却增加十分钟复核；或者事故概率虽低，但一次损失巨大，那么只比较 API 费用会得出错误结论。成本模型应包含人工复核、异常处理、评测、平台、合规和预期风险损失。

（二）用层级预算约束自主循环

预算要在运行前、运行中和运行后三个阶段生效。运行前为不同任务类别设置默认模型、最大步骤、最大子 Agent 数和工具范围；运行中监测 Token 斜率、重复调用、记忆增长和剩余预算；运行后进行成本---质量分析和模型路由优化。

预算从单步、单 Run、单 Agent 到组合层层约束，并以降级优先、硬停兜底。

层级预算可以包括：单次模型调用、单轮推理、单个 Run、单用户每日、单 Agent 每日、业务组合每月。接近阈值时先压缩上下文、切换小模型、降低并发、减少子 Agent 或转为异步；超过硬上限才停止。AWS 的 Agentic AI Lens 也强调渐进节流与审批，而不是在"无限自治"和"一刀切关闭"之间二选一。 $4$

（三）组合治理要敢于合并和退役

当企业拥有几十个 Agent，最大浪费往往不是某个 Prompt 多用了 10% Token，而是多个团队重复建设相同能力，或者无人使用的 Agent 仍在维护。组合评审每季度至少做四类决策：扩大、优化、合并、退役。

评审不要只看月活，还要看任务价值、质量稳定性、边际成本、风险暴露、替代重叠和 Owner 投入。低使用但承担关键应急流程的 Agent 可能必须保留；高使用但只是把工作转嫁给下游人工的 Agent 反而需要重构。

七、组织治理：中央定底座，业务对结果负责

（一）最有效的不是集中或分散，而是联邦式运营

完全中央化会让平台团队成为瓶颈，也不了解业务语境；完全分散会产生重复平台、影子 Agent 和不一致控制。更可行的是联邦模式：中央团队提供控制平面、身份、注册表、策略模板、评测工具、遥测标准和高风险审查；领域团队拥有业务目标、场景评测、知识质量和日常运营。

ISO/IEC 42001 将 AI 管理系统定义为围绕政策、目标和实现过程的一组相互作用要素，并采用 Plan---Do---Check---Act 持续改进逻辑。 $12$ 对 Agent 而言，这种管理体系必须进一步落到技术控制和运行节奏上：政策不仅"发布"，还要变成策略即代码；检查不仅"审计"，还要接收生产信号；改进不仅"更新制度"，还要生成新评测和新 Release。

中央平台拥有共性控制，领域团队拥有业务结果，第二道风险职能设定边界，第三道审计验证证据。

（二）三类 Owner 缺一不可

每个 Agent Product 至少指定三类责任人：

对业务目的、价值、风险接受和继续投资负责。Sponsor 不是签字人，而是决定"这个 Agent 是否仍值得存在"的人。

2、产品／运营 Owner

对场景、用户、反馈、质量目标、知识内容、操作手册和复审节奏负责。运营 Owner 应有权把 Agent 降级或暂停。

3、技术 Owner

对架构、Release、SLO、可观测性、值班、漏洞、依赖和恢复负责。技术 Owner 不能代替业务承担结果责任，但必须保证系统状态可知、可控、可恢复。

安全、隐私、法务、模型风险与审计是横向控制职能，不应被登记成一个模糊的"联合 Owner"。多人共同负责通常等于无人负责。注册表应记录唯一主责人和清晰的升级链。

（三）把委员会改造成有节奏的运营系统

规模化治理不能依赖每个变更都开大会。建议建立四种固定节奏：

每日自动运营：健康评分、预算、权限异常、SLO 和证书到期自动检查；
每周 Agent Review：评审高风险事件、失败样本、逾期 Owner 和待发布 Release；
每月服务评审：业务价值、质量、成本、用户反馈和技术债联合复盘；
每季度组合评审：扩大、合并、降级或退役，并更新风险偏好和策略模板。

OpenAI 的企业领导指南强调，良好治理应提供清楚、实用、可持续更新的规则，而不是增加新的阻塞；同时建议以轻量周期审查判断规则是否仍能兼顾速度和风险。 $13$ 这与 Agent 运营的核心一致：高频、低摩擦、证据驱动的自动控制，替代低频、全人工、只在上线前发生的审批。

八、落地路线：用 90 天建立最小可行控制平面

（一）0---30 天：先让资产、责任和风险可见

第一阶段目标不是采购"大而全平台"，而是建立统一语言和底线。

1、完成一次全域盘点

从模型网关、云账号、应用目录、MCP／连接器、服务身份、API 密钥、代码仓和采购合同反向发现 Agent。不要只发问卷，因为影子 Agent 的创建者未必认为自己在"构建 Agent"。

2、建立最小注册表与三类 Owner

优先填充 Product、Release、身份、Owner、目的、工具、数据、风险、预算、状态和到期日。对没有 Owner 的生产 Agent，设定明确整改期限；到期仍无人认领则降级或隔离。

3、定义四级自治与红线动作

全公司统一"观察、建议、经批准执行、自主执行"的含义，并列出禁止自动执行、必须二次验证和允许预授权的动作类别。

4、上线最小遥测

至少打通 Release ID、Run ID、模型 Token、工具调用、策略决策、最终状态、成本和错误。内容日志默认关闭或脱敏。

（二）31---60 天：把控制嵌入发布和运行

第二阶段把制度转换成机器门禁。

1、建立 Release Manifest 与评测门禁

选取 3---5 个高价值 Agent，把模型、Prompt、工具、知识、策略、评测与运行时一起版本化。每种变更定义必须重跑的测试集和审批级别。

2、拆分身份并实施短时授权

为生产 Agent 创建独立非人身份，禁止共享长期密钥；高风险动作通过工具会话获得短期、带条件的能力。部署权限异常和无 Owner 检测。

3、建立预算和降级策略

对单 Run、单日和单 Agent 设置软硬阈值；实现只读模式、小模型模式、降低并发和人工接管。

4、演练两类事故

至少演练一次越权动作和一次成本风暴，验证 Kill switch、身份撤销、在途任务终止、证据保全和恢复。

（三）61---90 天：形成反馈闭环与组合决策

第三阶段让系统可以持续改进。

1、建立失败样本到回归集的流水线

将投诉、人工接管、策略拒绝、异常循环和事故复盘转成脱敏可复现用例，指定修复 Owner 和纳入日期。

2、上线 Agent SLO 与健康评分

健康评分不要只显示绿灯，要能下钻到质量、安全、成本、体验、Owner 和版本状态。任何红线指标触发预定义动作。

3、运行第一次组合评审

挑选"扩大、优化、合并、退役"各一个候选，验证组织是否真的能作出资源取舍，而不是只会批准新项目。

4、把证据对接合规体系

将注册表、Release 审批、策略决策、评测报告、SLO、事件和复审记录映射到现有 AI 管理体系、信息安全和监管义务。欧盟 2026 年 AI Omnibus 调整了部分高风险系统实施时间表，但并未改变企业需要保留风险、监督和合规证据的方向；企业应维护可更新的法规标签和适用性判断，而不是把某个日期硬编码在流程里。 $14$

（四）衡量成熟度：五级台阶而不是一次性认证

一级"可见"：知道有哪些 Agent、谁负责。二级"可控"：身份、权限、预算和状态可机器执行。三级"可证"：每个 Release 有评测、审批与审计证据。四级"可运营"：SLO、事件、成本和反馈形成固定节奏。五级"可优化"：组合层自动识别重复、漂移和低价值 Agent，并通过实验持续调整质量---成本---风险边界。

成熟度的最终标志不是"零事故"，而是组织能够快速发现偏差、限制影响、恢复服务、形成回归资产，并对是否继续授权作出明确决定。

九、结语：治理的目标不是减少 Agent，而是让授权能够被持续证明

几十个 Agent 不是几十个软件功能，而是几十个被委托的行动主体。每个主体都在变化：模型升级、数据更新、工具扩展、Owner 调动、业务边界和法规要求也会变化。因此，治理不能是一张上线前签完就归档的表，而必须是与运行状态同步的系统。

本文提出的框架可以浓缩为：

一个清单：以企业 Agent Registry 作为事实源；

两条链：Release 可追溯链与 Run 可观测链；

三类责任：业务 Sponsor、产品／运营 Owner、技术 Owner；

四级自治：观察、建议、经批准执行、自主执行；

五个回路：发布、授权、评测、运行、成本持续闭环。

真正成熟的企业不会问"我们是否信任这个 Agent"，而会问：在这个 Release、这个用户委托、这个任务、这个数据范围、这个预算和这个时间窗口内，我们是否有足够证据授权它采取这类行动？当这个问题可以被注册表描述、被策略引擎执行、被遥测验证、被 Owner 解释、被事故机制撤回时，Agent 才从令人兴奋的原型变成可持续的企业生产力。

可参考的文章与标准

World Economic Forum：AI Agents in Action---A Playbook for Trusted Adoption, Authorization and Scaling（2026）

AWS Prescriptive Guidance：Security for agentic AI on AWS（2026）

Microsoft Learn：Manage agent registry in Microsoft 365 admin center（更新于 2026-07-06）

AWS Well-Architected Agentic AI Lens：Agent cost governance and continuous optimization

Anthropic Engineering：How we built our multi-agent research system（2025）

NIST：AI Agent Standards Initiative（2026）

Microsoft Learn：What is Microsoft Entra Agent ID?（更新于 2026-06-24）

OWASP GenAI Security Project：Top 10 for Agentic Applications 2026

Anthropic Engineering：Demystifying evals for AI agents（2026）

OpenTelemetry：Inside the LLM Call---GenAI Observability with OpenTelemetry（2026）

FinOps Foundation：Optimizing GenAI Usage---A FinOps Perspective on Cost, Performance, and Efficiency（2025）

ISO：ISO/IEC 42001:2023 AI Management Systems

OpenAI：Staying ahead in the age of AI---A leadership guide（2025）

European Commission：AI Omnibus enters into force（2026）

NIST IR 8596 初步草案：Cybersecurity Framework Profile for Artificial Intelligence（2025）