智能体借用账号后，审批责任如何追溯

业务系统显示「Alice 已批准」，往往只能证明操作用了 Alice 的账号。接入 AI Agent 后，同一条记录可能对应人工决定、组织授权的自动决策，也可能对应 Agent 擅自扩大任务范围。账号认证成功，无法替你区分这三件事。

作者讨论的重点，是审批记录需要什么证据，才能支撑用户对它的理解。对正在给后台、工单或支付流程接入 Agent 的团队，这个问题直接影响权限设计、跨系统调用和事后排查。

账号对得上，为什么还不能认定本人批准

原文从一条退款记录切入。它看起来足以回答「谁批准了退款」：

Refund request: R-204
Approved by: Alice
Status: approved

要留意 Approved by: Alice：它把账号身份写成了批准者，却没有交代决定从哪里来。

Alice 确实是有退款审批权限的经理，请求也通过了认证。但 Agent 可以通过她的账号操作。仅凭这条记录，无法知道她是否看过退款、组织是否授权了自动审批，或者 Agent 是否自行作出了决定。

作者引用了 Adam Manji 在 2026 年 10 月发布的预印本《Who Approved This?》。根据其中一家金融科技初创公司的自述，在持续强制执行分支保护的阶段，263 次非依赖机器人发起的 main 合并中，有 71 次仅依靠 Agent 通过技术负责人账号提交的批准。平台把批准归到负责人名下，现有记录却无法确定是谁决定批准。

这个观察的边界必须保留：它来自单家公司、自行报告，不能证明那 71 次变更没有经过人的判断，也不能当作行业事故率。

真正值得带走的是一个身份拆分：凭据属于谁、账号代表谁、谁执行操作、谁作出决定，可能有不同答案。共享账号和服务自动化早就存在类似问题；Agent 既能执行指令，又能选择后续动作，让这个区别更难忽略。

认证回答了哪个账号在操作，审批证据还要回答这次决定由谁授权。

相同的批准结果，可能需要三套证据

作者用三个假设场景说明区别。这些是设计示例，不是上述研究里的事故。

第一种，Alice 看过订单 O-81，确认退款 $200，再让 Agent 提交。决定由人作出，Agent 负责执行。此时强迫 Alice 再点击一次按钮，未必增加有效信息；系统更需要把提交动作与她对这笔退款的确认关联起来。

第二种，公司预先批准了一项政策，允许自动处理低于规定门槛、符合条件的重复扣款。自动流程按政策判断并批准，可以属于合法委托。但记录应说明采用了什么政策、适用哪个版本，以及哪些事实支持请求符合条件。原文没有给出门槛数值，不能把示例中的 $200 当作自动审批上限。

第三种，Alice 只要求整理待处理退款列表，Agent 却认为某笔退款合理，直接调用 API 批准。若没有适用的常设授权，整理列表并不包含批准列表内容的权限。API 返回成功，只能说明操作被系统接受，补不出此前缺失的委托。

这三类情况的排查方向不同：人工决定要查确认与执行的关联，自动决定要查政策及其适用过程，任务越界要查准备工作如何获得了决策能力。

还有第四种记录状态必须允许存在：决策来源未知。证据不足时，既不能断言人已经批准，也不能断言 Agent 越权。

多加一个批准字段，为什么解决不了问题

让模型输出 human_approved: true，只是增加了一项声明。接收系统仍然要判断：声明来自哪里，依据是什么，能否验证。

对于人工确认，证据应关联被认可的确认流程、具体动作和确认范围。如果业务要求本人确认，Agent 平时用于执行任务的凭据，就不应该同时足以伪造这项确认。否则执行者可以自己给自己补齐审批依据。

对于自动决定，要关联已获批准的政策、适用版本、授权范围，以及判断资格所用的事实。Agent 表示「看起来符合条件」，不能替代组织要求的评估机制。

作者没有提出统一的数据格式。已有审批服务、授权引擎，或者关联关系可验证的业务记录，都可能承担这些职责。给 Agent 独立账号也有帮助，可以识别执行渠道，但仍需解释它在行使谁的权限、允许决定什么。

跨系统时，这些信息更容易丢失。客服系统记录 Alice 同意开展调查，Agent 随后向支付系统申请退款；如果交接信息只有「Alice 已批准」，支付系统就可能把调查许可理解为资金操作许可。两边的认证都正确，业务授权仍然可能错位。

接收方还必须保留自己的检查：是否已经退款、角色是否变化、请求是否仍然有效。上游提供审批依据，不能替接收方跳过业务规则。

授权必须跟着具体动作和范围走，单独传递批准者姓名不够。

我的判断

这篇最有价值的地方，是把「人点没点按钮」推进到了「系统能证明什么」。人工确认和政策自动审批都可以合理存在，界面应如实表达它们，避免把自动决定包装成每次都经过人工审核。

不过，这是一篇设计讨论，没有提供实施前后的对照数据。作者没有证明增加这些证据后能减少多少错误，也没有说明跨系统维护关联关系的成本。因此，它适合拿来检查设计，不能直接当作某套方案有效的实测结论。

和每次操作都要求人工确认相比，明确委托范围可能支持更多自动化，但前提是政策可执行、证据可验证。反过来，如果确认对象和范围仍然模糊，多加一次登录或点击，也无法证明用户理解了全部后果。原文明确承认：系统只能记录可观察的过程，无法读取人的想法。

作者还披露自己参与 ACC 这一开放能力契约参考，以及 BailingHub 这一开源控制平面实现。他把 Agent-to-Business，简称 A2B，描述为 Agent 在个人或组织委托下进入既有业务系统。这个视角有用，但项目声明仍需执行机制落地，业务系统保留最终权限；文章也没有声称实现已证明所有集成中的决策来源。

能拿来做什么

• 给现有后台挑一条审批流程，从请求入口追到最终记录，核对能否区分账号、执行者与决策依据。原文在「小型审查可以询问」后缺少具体问题，团队需要据此补出自己的检查项。
• 前端展示「人工批准」前，确认后端证据确实对应当前动作与范围；自动审批应能追到授权政策，无法确定来源时，也应支持显示未知状态。
• 在 Node 服务接收跨系统请求时，检查委托是否覆盖当前操作，并继续执行重复退款、角色变化等本地业务校验，避免仅凭上游的批准者姓名放行。
• 给日常 AI 编程流程检查一次代码审查记录，尤其是 Agent 使用个人账号提交批准的场景。保留必要的业务对象和决定引用，并设置访问控制、完整性保护与留存规则，无须把全部对话、凭据和客户文档复制进日志。