AI Agent 出错谁负责：从日志、审批到责任链

AI Agent 出错，不能回答成「AI 负责」或「最后点确认的人负责」。企业要把责任拆到四类角色：设计者决定它怎样工作，运营者维护版本与资料，审批者放行高影响动作，使用者提供真实目标并按规则使用。日志再把这些决定串成证据链。没有这条链，事故发生后只能靠聊天记录和记忆互相猜测。

这里讨论的是工程与运营治理，不是对具体事件给出法律结论。实际法律责任会受到适用地区、合同、行业规则、事实经过和损害类型影响，需要由具备资质的专业人士结合材料判断。企业能提前做的，是让系统边界、授权、审批和证据足够清楚，既减少错误，也让后续判断有事实基础。

先还原一次错发报价，不急着找一个人背锅

设想一个销售辅助 Agent：它收到客户询价，从知识库取产品价格，在客户关系管理系统里生成报价邮件，销售确认后发送。某天客户收到低于现行价格的报价。表面看，是 Agent 选错价格，也是销售点了确认；如果只停在这两句，真正能防止复发的原因一个都找不到。

继续还原会看到更多决定：需求文档没有规定价格冲突时必须停机；知识库里旧价目表没有到期标记；运营人员更新了新品资料，却没有下线旧版本；Agent 取到了两个价格后按较低值继续；审批页面只显示邮件正文，没有展示价格来源和版本；销售看到熟悉模板就通过。事故是这条链共同产出的，不是模型孤立生成的一句话。

因此，复盘应该问「哪个控制点本应阻止错误，却没有工作」，而不是先问「谁最后碰了鼠标」。浏览器 Agent 的企业场景与边界里区分了准备与生效：如果系统把生成草稿、核对依据和正式发送混成一个动作，责任本来就会被界面压扁。

四类角色分别对不同的控制点负责

责任链的目标不是把所有人都写成「共同负责」，而是让每个控制点有唯一的主要责任人、明确的配合者和升级对象。项目上线前，至少把以下四类责任落到具体岗位，而不是只写部门名称：

• 设计者负责把业务目标变成可执行边界：输入输出、允许工具、禁止动作、冲突处理、停止条件、审批点和验收标准。设计者不对每次业务决定代签，但要对系统是否提供了正确控制负责。
• 运营者负责生产中的版本、知识源、账号权限、告警、回归测试和变更记录。运营者要知道当前跑的是哪一版、资料由谁维护，并在异常指标出现时暂停或降级。
• 审批者负责在获得足够信息后，对某个具体高影响动作作出业务授权。审批不是替模型检查所有技术细节，而是核对对象、关键参数、依据、风险提示和自身授权范围。
• 使用者负责提供真实完整的任务信息、在授权范围内使用系统、阅读警示，不诱导系统绕过规则，并及时报告异常。使用者不应被迫承担界面未展示、系统也没有记录的隐藏风险。

供应商和模型服务方也可能承担合同约定的交付、支持、安全或故障通报职责，但购买产品不会自动替企业完成场景设计和内部授权。企业仍需决定哪些资料可进入系统、哪些账号可用、哪些结果必须复核。责任可以跨组织分配，控制点不能处于无人认领状态。

有效日志要记录决定与副作用，不只是保存聊天

聊天文本只能说明说过什么，不能完整说明系统做了什么。可审计日志至少要串起任务编号、发起人与执行身份、Agent 和提示词版本、知识源与数据快照标识、可用工具及权限、每次工具调用的参数摘要和返回状态、生成结果、策略拒绝、审批记录、实际写入或发送的对象，以及人工接管和回滚。凭证和密钥不得入日志。邮箱、手机号等低熵敏感值不要用普通哈希关联，应改用随机事件编号；确需跨系统对照时，使用受控令牌或带密钥的 HMAC，并限制谁能还原。

时间顺序尤其重要。系统要能回答：Agent 在读取哪一版资料后作出判断，审批者当时看到了什么，批准的是哪个对象和哪些参数，执行前后外部系统状态有什么变化。如果只能看到最终邮件和一句「用户已确认」，就无法分辨审批界面遗漏信息、批准内容被后续替换，还是执行工具把正确参数写错。

日志本身也需要治理。限定谁能读取、保存多久、怎样防止普通运营人员修改，时间戳和任务标识如何跨系统对齐；同时避免为了审计把完整密码、访问令牌或不必要的个人资料写进日志。证据链的质量不在于记录得最多，而在于足以重建关键决定，又没有制造新的敏感数据风险。

人工审批必须绑定具体动作，不能成为装饰按钮

有效审批发生在副作用之前，并让审批者看到决定所需的信息。报价发送应展示客户、产品、数量、币种、价格、价格来源与版本、偏离标准价的提示以及最终邮件；权限变更应展示账号、原权限、新权限、有效期和申请依据。批准记录要绑定这些参数，任何关键字段在批准后变化，都应使原批准失效并重新确认。

不要把每一步都塞给人审批。低风险、可撤回动作可以自动执行并抽检；高影响动作才升级确认。过多、重复、没有差异提示的弹窗会训练使用者机械点击。更好的界面突出变化、异常和证据，让审批者知道这一次为什么需要自己判断，并允许退回、修改或请求补充信息，而不只有「同意」。

审批者必须真实拥有相应业务权限，也需要替补与升级路径。系统不能在负责人离开后悄悄改成自动放行，也不能让低权限使用者通过多轮对话诱导 Agent 自批自做。审批服务、执行工具和 Agent 的身份应适当分离，避免一个被攻破的会话同时获得提议、批准和执行全部能力。

事故发生后先止住副作用，再保全证据和恢复业务

面对错误，团队需要按既定顺序行动，而不是一边争论责任一边让同一版本继续运行：

1. 控制影响：暂停相关任务、撤销可撤回动作、收紧权限，必要时切回人工或旧流程。
2. 保全证据：固定日志、版本、输入、知识源快照、审批页面和外部系统状态，避免排查时覆盖现场。
3. 确认范围：找出受影响的任务、对象和时间段，区分已执行、待执行与仅生成草稿的情况。
4. 修复与验证：同时修数据、规则、界面或权限控制，用可复现案例证明控制点已经生效。
5. 受控恢复：先在影子或小范围运行，持续观察，再逐步恢复权限和任务量。

对外沟通、客户补救和是否上报要依据具体事实、合同、适用规则和专业意见决定，不能从一篇通用文章推导统一结论。工程团队的职责是及时提供可信的影响范围和证据，而不是用「模型不可解释」作为无法调查的理由。

复盘修复要进入测试集。错价案例应增加价格冲突、过期文档、来源缺失、审批参数变化等测试，并在每次版本变更时重跑。AI Agent 怎么评测给出了结果、过程、工具、安全与恢复的分层方法；只有把事故变成回归案例，经验才不会停留在会议纪要里。

责任矩阵要跟模型、资料、工具和权限一起变更

Agent 不是上线后静止的软件。模型可能更换，提示词会调整，知识源不断更新，工具和页面也会改版。每类变化都可能移动责任边界：新增发送工具意味着新的审批点；把只读账号换成可写账号意味着风险级别变化；引入新的数据源意味着资料责任人和保留规则要补齐。变更单里应同时更新测试、日志字段、审批界面和责任矩阵。

运营指标也要有人认领，包括失败、人工接管、异常拒绝、重复动作、审批退回和单位任务成本。指标越界时，谁有权停机、谁调查、谁决定恢复，都要事先写明。若系统上线后只有技术团队看服务是否在线，却没人看业务结果是否在悄悄变差，责任链仍然是断的。

从试点进入生产时尤其要完成这次交接。AI 项目从试点到正式上线强调运营责任人与回退方案；对 Agent 还要再加一层：把自主动作逐项列出，确认每项的负责人、证据、审批与停止条件。试点期间由项目组随手兜底的工作，必须变成生产中的正式职责。

真正可执行的责任链，最后落在三份文件里

企业不需要先写一部厚重制度，可以从三份能运行的文件开始。第一份是场景责任矩阵，列出每个关键动作的设计、运营、批准、执行、复核与升级角色；第二份是日志规范，定义任务、版本、输入、工具、审批和副作用怎样关联；第三份是审批与事故手册，写明哪些动作必须确认、确认看什么、怎样暂停、取证、回退和恢复。三份文件要用一次演练验证，而不是只在评审会上通过。

回到开头的错价事故，可靠的责任链不会简单宣布「销售负责」或「模型负责」。它会指出旧资料为何仍可检索、冲突为何没有触发停机、审批为何看不到来源、谁批准了发送，以及每个控制点如何修复。责任治理的价值不是在出错后更快找到一个人，而是在出错前让每个重要决定都有主人，出错后让事实能够被重建。