AI Agent 如何治理？权限、上下文、工具与人工接管
直接回答：AI Agent 治理不是事后审核，而是把“能做什么、不能做什么”变成可执行的控制面。核心手段是运行合约、最小权限、上下文白名单、预算熔断和人工接管，而不是依赖模型临场表现。
很多团队部署 Agent 时只关注“它能不能完成任务”，等出问题才讨论责任。正确顺序相反：先设计控制面，再允许 Agent 运行。因为自主系统的错误会沿链路传播，无法指望它自我纠正。
一、治理的最小单元：Agent 运行合约
每个进入试运行的 Agent 都应有一份独立的运行合约，至少包含：
| 合约要素 | 必须写清楚的内容 |
|---|---|
| 业务目标与边界 | 完成什么；不承担什么决策；不可接受的结果 |
| 自主等级 | L1–L5；哪些动作必须人工批准 |
| 可调用 Skill | 名称、版本、输入输出契约、适用状态 |
| 上下文包与来源 | 允许来源、排除来源、优先级、预算、版本与失效条件 |
| 工具与连接器 | 白名单、允许参数、读写权限、返回量、超时 |
| 持久记忆 | 可读/可写类别、事实与假设标记、保留期、隔离与删除 |
| 状态与路径 | 合法状态、允许转移、终止状态、重试条件 |
| 预算与熔断 | 最大步骤数、工具调用数、时间、成本、并发 |
| 验证与审批 | 哪些事实独立检查；哪些动作必须批准 |
| 人工接管与回退 | 触发条件、接管人、降级方式、恢复所需证据 |
| 责任与审计 | Owner、日志保留与复盘责任 |
二、四个关键控制原则
1. 最小权限：先只读，后写入
优先级：只读查询优先于写入操作；沙箱优先于生产；限定资源范围优先于全库访问；短期凭证优先于长期高权限密钥。即使允许写入，也采用“生成建议 → 人工确认 → 受控执行”的两阶段设计。
2. 信息面同样需要最小权限
Agent 能看到什么与能执行什么同样重要。上下文包设定允许来源、排除来源、选择逻辑和返回量；工具描述、参数和返回内容本身会进入模型上下文，字段模糊或默认返回过量的工具会降低可预测性、增加成本与错误风险。
3. 人工看守关键动作，而非机械点击
系统应向审核者展示：Agent 的目标、依据的上下文来源与版本、已调用的 Skill 与工具、工具结果摘要、拟执行动作、风险提示和可修改选项。审核者能拒绝、修改、转人工或终止，而不是“一键通过”。
4. 状态机与动作白名单：限制轨道
不要让 Agent 完全自由决定下一步。预先定义合法状态、状态转换和终止条件；模型只负责在当前状态下选择允许的下一步。遇到信息缺失、工具超时、置信不足或异常输入，进入“转人工”或“终止”状态，而不是无限重试。
三、上线前检查表（精简版）
- 业务价值明确，动态编排有可验证的额外价值；
- 已完成用例级风险初筛，高风险用例完成 AI 影响评估；
- 每个关键任务已封装为有验证、回退、Owner 的 Skill；
- 自主等级已定义并在系统上实现，而不只是写在文档里；
- 上下文最小必要且可追溯，工具与数据最小权限；
- 状态、预算与熔断已配置硬限制；
- 人工确认节点可用，接管与回退经过真实演练；
- 审计日志可追溯（任务目标、状态转移、版本、审批、异常、熔断、结果）。
四、不建议采用全自主的场景
资金划拨、定价或折扣最终决定、对外正式承诺、医疗或法律结论、直接修改核心数据库、敏感个人信息外发、重大人事决策。这些场景即使允许辅助，也应保留与风险相称的人工审批。
五、从哪开始练手
如果团队尚未运行过 Agent，不要从“自动处理客户请求”开始。建议先做一个只读、只输出建议的异常工单调查助手：只编排已验证 Skill、只读取批准来源、无写入权限、异常时停止并转人工。先在已关闭的历史工单上测试，再考虑扩大。
下一步
- 阅读第 9 章 Agent 与自动化治理获取决策树、分级策略与完整检查表。
- 使用Agent 运行合约模板和上下文包模板开始设计。
- 评测方法见AI 效果怎么评测。
- 返回企业 AI Agent 落地指南查看全部专题。