上周一个真实案例：某电商公司的 AI Agent 自动调整了 2000 个 SKU 的定价策略，导致部分商品以成本价以下售出，一天亏了 80 万。复盘会上，所有人面面相觑——
运营说：“我没动过，是 AI 自动调的。” 技术说：“模型输出没问题，是数据源有异常。” 数据团队说：“数据是实时抓取的，跟我们无关。”
没有一个人为这 80 万负责。
这不是个例。当 AI 从"辅助工具"升级为"执行主体"，一个被企业严重低估的问题出现了：出了事，找谁？
“AI 做的"不是答案
在传统软件系统中，每个操作都有明确的执行者。运营点了"发布”，就是运营的责任；审批人签了字，就是审批人的责任。责任链条清晰，追溯简单。
但 AI Agent 打破了这条链。
一个 Agent 的一次执行，背后可能涉及：
- 提出需求的业务方——“帮我自动优化定价”
- 配置策略的运营——设定了调价幅度和频率
- 开发 Agent 的技术团队——写了 Prompt 和工具调用逻辑
- 提供数据的数据团队——对接了商品和竞品数据源
- 部署和运维的平台团队——负责 Agent 运行环境和权限
当 Agent 做了一个错误决策，这五个角色都可以说"不是我的问题"。责任被分散在整条链路上，最后没有人承担。
这就是 AI 治理中最危险的状态：系统有能力做决策，但组织中没有人为这些决策负责。
可追责不是事后日志，是设计原则
很多团队以为"可追责"就是多打点日志、保存 Prompt 和模型输出。这只是最表层的一步。
真正的可追责系统，需要在架构层面回答四个问题：
1. 谁授权了这个行为？（Authorization Chain）
每一次 Agent 的高风险操作，必须能追溯到一个具体的人类授权者。这不是指用户登录的那个人，而是指谁决定了 Agent 可以做这件事。
# 定价 Agent 的授权链
action: adjust_price
agent: pricing-optimizer
authorized_by: "张三 (运营总监)" # 谁批准了这个 Agent 的上线
policy_set_by: "李四 (品类运营)" # 谁设定了调价策略参数
boundary_approved_by: "王五 (财务总监)" # 谁批准了调价幅度上限
last_policy_review: "2026-03-15" # 上次策略复审时间
# generated by hugo's coding agent
关键设计：不是记录"AI 做了什么"，而是记录"谁让 AI 可以这么做"。
当出了问题，追责路径清晰：
- 如果 Agent 做了超出策略范围的事 → 技术团队的问题（Agent 实现有 bug）
- 如果策略范围本身设得不合理 → 设定策略的运营的责任
- 如果策略合理但业务场景变了没更新 → 审批策略的管理层需要解释为什么没有定期复审
2. 谁定义了边界？（Boundary Ownership）
每个 Agent 都必须有明确的行为边界，而每个边界都必须有一个人类 owner。
class AgentBoundary:
"""Agent 行为边界定义 —— 每条规则绑定一个责任人"""
def __init__(self):
self.rules = [
{
"rule": "单次调价幅度不超过 15%",
"owner": "李四", # 谁定的这条规则
"owner_role": "品类运营负责人",
"approved_date": "2026-03-01",
"next_review": "2026-04-01", # 强制复审日期
"rationale": "历史数据显示超过15%的调价导致退货率飙升"
},
{
"rule": "单日累计影响 SKU 不超过 500",
"owner": "王五",
"owner_role": "财务总监",
"approved_date": "2026-03-01",
"next_review": "2026-04-01",
"rationale": "控制单日最大潜在损失在可接受范围"
}
]
# generated by hugo's coding agent
核心原则：没有 owner 的边界等于没有边界。 如果一条规则没人愿意签字负责，那这条规则就不应该存在——要么它不重要（删掉），要么它太重要以至于没人敢负责（那就不应该让 Agent 做这件事）。
3. 谁在监控运行时？（Runtime Accountability）
Agent 运行过程中，必须有明确的"值班人"概念——不是系统运维的值班，而是业务结果的值班。
┌─────────────────────────────────────────┐
│ Agent 运行时责任体系 │
├─────────────────────────────────────────┤
│ │
│ 触发操作 ──→ 风险评估 ──→ 执行 │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 记录触发源 判定风险等级 记录结果 │
│ (谁/什么 (低/中/高) (成功/ │
│ 触发的) │ 异常) │
│ │ │
│ ┌────────┼────────┐ │
│ ▼ ▼ ▼ │
│ 低风险 中风险 高风险 │
│ 自动执行 通知值班人 值班人审批 │
│ 事后可查 15分钟响应 实时阻断 │
│ │
│ 值班人：有明确排班，轮转记录在案 │
│ 不响应 = 自动拦截 + 升级 │
└─────────────────────────────────────────┘
这里的关键不是技术实现，而是组织设计：必须有一个具体的人，在 Agent 运行的每一刻，为它的行为承担最终责任。就像自动驾驶汽车——不管自动化程度多高，方向盘后面必须坐着一个人。
4. 出了问题谁来定责？（Incident Attribution）
事故发生后，追责流程必须能在 30 分钟内回答：这是谁的责任？
设计一套标准化的归因框架：
| 故障类型 | 归因逻辑 | 典型责任方 |
|---|---|---|
| Agent 执行了边界外的操作 | 技术实现问题 | Agent 开发团队 |
| Agent 在边界内执行但结果不好 | 策略/边界设定问题 | 边界 Owner |
| 边界合理但场景已变化 | 复审机制失效 | 审批管理层 |
| 外部数据异常导致错误判断 | 数据质量/监控问题 | 数据团队 |
| 值班人未响应告警 | 运营流程问题 | 值班人及其管理者 |
每一类故障都有且仅有一个首要责任方。 不允许"多方共同承担"这种模糊表述——共同承担 = 没人承担。
实际落地的三个层次
第一层：操作审计（大多数企业在这里）
记录 Agent 的每一次操作，包括输入、输出、调用的工具、影响的数据。这是基础，但远远不够——它只能告诉你"发生了什么"，不能告诉你"这是谁的责任"。
第二层：决策溯源（少数企业在探索）
不仅记录操作，还记录决策链路：这个操作是基于什么策略、什么数据、什么上下文做出的？策略是谁设定的？数据是从哪来的？上下文是否完整？
class DecisionTrace:
"""每一次 Agent 决策的完整溯源记录"""
def record(self, decision):
return {
"decision_id": generate_id(),
"timestamp": now(),
"agent_id": decision.agent_id,
# 决策依据
"input_data": decision.input_snapshot, # 输入数据快照
"policy_version": decision.policy_ref, # 使用的策略版本
"model_version": decision.model_ref, # 模型版本
"prompt_hash": decision.prompt_hash, # Prompt 指纹
# 责任链
"triggered_by": decision.trigger_source, # 谁/什么触发的
"policy_owner": decision.policy_owner, # 策略责任人
"boundary_owner": decision.boundary_owner, # 边界责任人
"on_duty": decision.current_on_duty, # 当时的值班人
# 执行结果
"action_taken": decision.action,
"affected_scope": decision.impact_summary,
"risk_score": decision.risk_assessment,
}
# generated by hugo's coding agent
第三层：责任架构（目标状态）
将追责能力设计到组织架构中：
- 每个 Agent 有一个业务 Owner，对 Agent 的业务结果负责——不是技术负责人，是业务负责人
- 每个策略有 Review 周期，到期未 Review 自动降级 Agent 权限
- 每次高风险操作有审批人，审批记录不可篡改
- 事故归因有标准流程，30 分钟内可定位首要责任人
为什么"让 AI 更准"不能替代"追责到人"
有人会说：与其花精力搞追责，不如把 AI 做得更准，错误率降到足够低不就行了？
这是一个危险的错觉。
第一，AI 的错误率永远不会是零。即使 99.9% 的准确率，在每天执行 10 万次操作的场景下，每天仍然有 100 次错误。
第二，AI 的错误模式跟人类不同。人类犯错是渐进的、分散的，容易被同事发现和纠正。AI 犯错是瞬间的、批量的、高度一致的——在你反应过来之前，错误已经扩散到整个系统。
第三，也是最根本的：追责的目的不是惩罚，而是闭环。 当没有人为 Agent 的行为负责时，就没有人有动力去改进策略、更新边界、完善监控。系统会在一个看似正常实则脆弱的状态下运行，直到某一天突然崩溃。
可追责性不是对 AI 的约束，是对组织的保护。
给正在落地 Agent 的团队的建议
先定责任，再写代码。 在开发任何 Agent 之前，先确定：这个 Agent 出了错，谁来负责？如果这个问题回答不了，就不应该开发。
每个 Agent 必须有且仅有一个业务 Owner。 不是"团队负责"，是某个具体的人。这个人有权随时关闭 Agent。
“AI 做的"在组织里不应该是一个合法的答案。 要建立文化：AI 做的每一件事，都有一个人在为它背书。
设计降级机制。 当追责链路断裂时（比如值班人未响应、策略过期未审批），Agent 必须自动降级到安全模式，而不是继续全速运行。
定期做"追责演练”。 就像消防演习，定期模拟 Agent 事故，看是否能在 30 分钟内定位到责任人。如果不能，说明追责体系有漏洞。
结语
AI 的能力在飞速进步，但企业治理的进化速度远远跟不上。
今天大多数企业在 Agent 落地时的思路还是：先跑起来，出了事再说。 但历史反复证明，“出了事再说"的系统在出事后，往往找不到人来"说”。
可追责性不是 Agent 做好了之后的锦上添花，而是 Agent 能不能上线的前提条件。
你不会允许一个不知道向谁汇报的员工上岗。同样，你也不应该允许一个出了问题找不到责任人的 AI Agent 上线。
设计系统时请记住：技术越强大，追责越重要。不是因为你不信任 AI，而是因为你必须保护用好 AI 的人。