当智能体有了"自主权"，谁为它的行为负责？
前几篇文章讨论的问题——幻觉、工具调用失败、崩溃、协调混乱——都是技术可解的。但有一类问题超越了技术范畴：当智能体越来越多地代替人做决策和行动时，谁来为后果负责？
McKinsey 2026 年 AI 信任成熟度调研覆盖了数千家企业，核心发现是：企业对 AI 的信任没有跟上 AI 能力的增长。随着 Agent 从"辅助工具"走向"自主行动者"，治理和问责缺位成了最紧迫的系统性风险。
这不是"以后再考虑"的问题。2025 年已经有多起因 AI Agent 自主行动导致的业务事故：
- 客服 Agent 自作主张给用户全额退款
- 营销 Agent 向错误人群发送敏感促销
- 数据处理 Agent 把内部数据写入了外部系统
每一件事的直接原因都是技术层面的（幻觉、工具错误），但根本原因是治理框架缺失——没有人为 Agent 的行动设定边界。
四大治理挑战
挑战一：权限边界模糊
核心问题
智能体能干什么？哪些决策它可以自己做？哪些必须请示？
大多数 Agent 系统根本没有清晰定义权限边界。系统 prompt 里写了"帮用户处理订单"，但没有写：
- 你可以取消订单吗？
- 你可以修改价格吗？
- 你可以给超过 100 元的订单退款吗？
- 你可以查看其他用户的数据吗？
为什么重要
权限不清时，Agent 的两种倾向都会出问题：
- 过度谨慎：什么都问用户，失去自动化的意义
- 过度激进：什么都自己做，出了事不可控
现实中的 Agent 往往走向后者——因为"帮用户解决问题"的指令天然偏向行动，而非克制。
类别
权限至少需要从三个维度定义：
- 数据维度：能访问什么数据？能读哪些？能写哪些？
- 操作维度：能执行哪些操作？取消订单 vs 修改地址 vs 查看物流？
- 金额维度：操作有财务影响时，上限在哪里？
挑战二：审计追踪缺失
核心问题
Agent 做了一个决策，事后能否完整回溯"它为什么这样做"？
目前多数 Agent 系统的回答是：不能。
- 推理过程只存在于 LLM 的上下文中，运行结束后消失
- 工具调用的参数和返回值可能记录了，但"为什么选择调这个工具"没有记录
- 多步推理中，前面步骤的中间结论影响了后面决策，但这些因果链没有被显式记录
后果
没有审计追踪 = 没有问责基础。
当 Agent 出了问题，你做不到：
- 回溯到具体哪步决策导致了错误
- 理解当时的信息条件（Agent 看到了什么才做这个决策）
- 评估决策是否合理（在给定信息条件下，这是否是合理选择）
- 防止再次发生（不知道原因就无从修复）
挑战三：数据隐私暴露
核心问题
智能体为了完成任务需要访问数据——但它需要的数据是不是超出了必要范围？
典型场景
用户：帮我查一下我的订单状态
Agent：调用 get_all_orders() 而不是 get_order(order_id)
→ 拿到了该用户全部订单历史
→ 只是展示了一个订单的状态，但已经过度获取了数据
更严重的场景：
- Agent 为了"更全面地分析问题"主动检索用户隐私数据
- Agent 把用户数据作为参数传给了第三方 API（意图是获取更多上下文）
- 多 Agent 系统中，数据在 Agent 间流转时被过度传播
规模问题
单个 Agent 的隐私暴露风险相对可控。多 Agent 系统中，数据流转路径复杂，每个 Agent 都可能成为数据泄露的节点。而且 Agent 不像人类员工——它们没有"这不该看"的直觉。
挑战四：责任归属——Agent、开发者、还是用户？
核心问题
当 Agent 的行为造成损害，谁负责？
| 场景 | Agent 行为 | 责任归谁？ |
|---|---|---|
| Agent 幻觉后给客户发了错误报价 | 自主决策 | 开发者？使用者？模型提供商？ |
| Agent 按用户明确指令执行，但违反了公司政策 | 执行用户指令 | 用户？管理者？系统设计者？ |
| Agent 调用第三方服务时数据泄露 | 信息流转 | 平台方？第三方？Agent 开发者？ |
法律和监管还没跟上。现有框架（EU AI Act、中国深度合成规定等）更多关注"模型"层面，对"智能体自主行为"的责任划分尚无明确指引。
治理框架设计
原则一：最小权限原则
Agent 只获得完成当前任务所需的最小权限集：
# 而非给 Agent 一个万能 key
agent.get_permissions()
# → ["read:own_orders", "write:own_address"] # 只能看自己的订单、改自己的地址
# 而不是
# → ["read:all_orders", "write:all_data", "admin:full"]
动态权限：权限随任务上下文变化。查询物流只需要 read，退货申请需要 write，但限额在 500 元内——超过 500 元的退款需要人工审批。
原则二：决策审计日志
对每次决策记录完整的上下文快照：
{
"decision_id": "D-20260701-042",
"timestamp": "2026-07-01T14:32:00Z",
"agent_id": "customer-service-v2",
"action": "issue_refund",
"action_params": {"order_id": "ORD-12345", "amount": 89.50},
"triggering_context": "用户投诉商品损坏，上传了照片",
"information_basis": {
"retrieved": ["用户历史记录：3 次购买、0 次退款",
"商品政策：损坏7日内可全额退款"],
"model_reasoning": "用户描述+照片符合退款条件..."
},
"confidence": 0.92,
"override_available": true
}
这不是技术难题，是工程纪律——每步决策都留痕，让系统可审计、可回溯、可追责。
原则三：分级审批机制
不是所有决策都由 Agent 自主完成，按风险等级分级：
低风险（查看信息、计算推荐）→ Agent 自主
中风险（修改设置、发送通知）→ Agent 执行 + 事后人工抽检
高风险（资金操作、数据导出）→ Agent 提议 + 事前人工审批
关键设计参数：
- 风险分类标准：如何判定一个操作属于哪个风险等级
- 审批超时策略：人工审批如果超时（人不在），是自动通过、自动拒绝、还是升级？
- 审批粒度：逐笔审批 vs 批量审批 vs 阈值审批
原则四：数据访问控制
在工具层实施数据最小化：
# 工具层面限制数据范围
@restrict_data_access(scope="own_data")
def get_orders(user_id, order_id=None):
if order_id:
return db.query(Order, id=order_id, owner=user_id)
# 不允许无条件拉全量 —— 即使 Agent 请求了
工具层是实施数据控制的最佳位置——Agent 可能"想"看更多数据，但工具本身限制返回范围。就像数据库的行级安全策略，由基础设施保证，而非依赖应用层的自律。
原则五：行为边界声明
在系统设计中显式声明 Agent 的行为边界：
agent_permissions:
can:
- read_customer_basic_info
- query_order_status
- send_notification_email
cannot:
- access_payment_info
- modify_order_amount
- export_customer_data
needs_approval:
- refund_over_100_cny
- cancel_subscription
- access_other_user_data
这个声明应该：
- 对开发者可见（代码审查时检查）
- 对用户可见（让用户知道 Agent 能干什么）
- 对审计可见（合规检查的依据）
- 在运行时强制执行（不是"软约束"，而是硬限制）
迈向成熟治理
McKinsey 的调研提出了 AI 信任的三个阶段：
- 被动响应阶段（当前大多数企业）：出事后才制定规则
- 主动治理阶段：在部署前建立框架，预防风险
- 嵌入式治理阶段：治理机制成为系统的一部分，不是外挂而是内建
大多数企业还在阶段一。智能体技术的快速发展倒逼我们必须加速走向阶段三——治理不是一个"上线后再补"的功能，而是从一开始就要内建在系统架构中的非功能性需求。
小结
治理不是阻碍创新的枷锁，是让智能体得以在真实世界中可持续运行的基础设施。
核心原则：
- 最小权限：只给完成任务所需的最小权限
- 全面审计：每步决策留痕，可回溯、可追责
- 分级审批：不同风险等级对应不同的审批流程
- 数据最小化：工具层限制数据访问范围
- 边界声明：行为边界显式化、可审查、可执行
最后一篇，我们讨论智能体最本质的挑战：不确定性与规划失效——当未来不可预测时，智能体的"计划"还能走多远？