當 AI 也能使用你的帳戶，「人工批准」還代表甚麼？

简介： 本文探讨AI深度融入工作流后审批记录的语义危机：当“张经理已批准”可能源于人工决策、预设规则或AI越权操作，系统需区分“谁决定”与“谁执行”。文章以金融科技案例切入，提出需明确授权范围、记录决策依据、跨系统保留委托关系，倡导用可验证的契约（如ACC）与开源实践（百灵中枢）重建可信审批证据链。

想象你在公司的业务后台看到一条记录：

“审批人：张经理。审批结果：同意。”

大多数人会自然地理解为：张经理看过这件事，并且决定让它继续。

但如果张经理的账号也交给了 AI 助手使用，这条记录的含义就需要再问一步：张经理作出了决定，让 AI 代为执行；还是 AI 自己作出了判断，再通过张经理的账号提交？

页面上的名字可以完全相同，背后的委托关系却可能不同。

这正是 AI 开始进入真实工作流程后，一个容易被忽略的变化：系统仍然记得谁的账号做了操作，却未必记得谁决定要这样做。

2026 年 10 月 19 日，一篇名为《Who Approved This?》的预印本报告了一家金融科技初创公司的开发实践。在保护规则持续执行阶段，排除依赖更新机器人后，共有 263 次主分支合并。其中 71 次的唯一有效批准，是 Agent 通过技术负责人账号提交的。平台将它们记作该账号的普通批准。

作者指出，这些记录无法确定谁作出了决定。这不证明 71 次都没有人的判断。研究属于单家公司自述的观察，不能当作行业事故率，却提出了一个值得讨论的问题：一条看起来属于人的批准记录，究竟能证明什么？

一个账号，开始容纳多种行动关系。

在很多企业软件里，“操作人”是一个很方便的字段。它把登录身份、权限持有者、实际操作的人和作决定的人，压缩成了一个名字。

这种简化过去就有局限。共享账号、代办、批处理程序，都可能让账号与操作者分开。AI 让这个问题变得更突出，因为它能接收目标、理解材料、选择下一步，再使用工具完成操作。人与机器之间的分工，可以在同一项任务里连续变化。

一个人可能只说了“整理一下需要我处理的退款”，也可能说了“这三笔我看过了，同意退”，还可能提前规定“符合这些条件的小额退款，可以自动办理”。

这三种委托的范围并不相同。尤其是整理待办，本身并不包含批准退款的权限；最终出现了退款请求，也不能反过来证明它获得过授权。

如果系统只留下“张经理操作成功”，事后就很难还原：他授权的是整理材料、执行已经确认的决定，还是在一定范围内自动判断？

这里有一个容易混淆的地方：人没有亲自点击按钮，不等于没有授权。反过来，请求使用了某个人的账号，也不足以证明这个人批准了当前这件事。

企业需要知道的，是这次行动依靠哪一种被认可的决定机制发生。

同样显示“已同意”，背后可能是三种关系。

我们用一个假设的售后场景，把区别说清楚。

第一种，AI 整理了一笔退款的订单、金额和原因，张经理确认“这笔退 200 元”，再由 AI 调用系统执行。这里的决定来自人，机器负责落实。记录应当能关联到他确认的那笔订单、金额和条件，而不只是表示某个有权限的账号调用过接口。

第二种，公司已经制定规则：满足指定条件、处于限定金额和业务范围内的申请，可以自动退款。AI 或规则程序据此处理。这种流程可以有充分授权，甚至比每笔都等人点击更稳定。相应记录应说明由哪套规则作出了自动决定、规则由谁授权生效、这次为什么符合条件。

第三种，AI 只是被要求整理待办，却自行认为某笔退款“应该没有问题”，使用负责人账号提交了批准。即使业务接口成功，这次行动也仍然缺少从整理任务到批准退款的授权依据。

这三种情形不能只靠最后一个“已同意”来区分。它们涉及不同的决定来源，也对应不同的复核和改进方式。

当自动规则出了问题，企业需要检查规则及其适用条件；当人的决定被执行错了，需要检查执行过程；当任务范围被擅自扩大，需要检查委托如何传递。把这些情况混在一起，修复也容易修错地方。

自动化走得越远，越需要诚实地说明哪些决定已经被委托。

讨论人工审批，很容易走到一个看似稳妥的结论：所有动作前面都加一个确认按钮。

这会带来新的成本。员工需要在大量重复提示中重新判断，企业需要等待，人也可能逐渐只剩下机械确认。真正重要的例外，反而混进了一长串相似的“是否继续”。

有价值的治理，应当让组织能放心地把一部分决定提前交出去。

例如，明确哪些业务可以按规则自动办理，授权能持续多久，范围在哪里，什么变化会使原来的授权失效，什么例外需要回到人那里。

这样，人参与的是规则、范围与例外的判断，机器承担的是被授权范围内的重复工作。企业得到效率，也能解释效率从哪里来。

因此，自动决定完全可以作为一种正常的业务状态存在。它不需要被包装成人逐笔看过的样子。公司可以坦然地说：“这项业务由我们批准生效的规则自动处理。”这比留下一条含义模糊的“张经理已批准”更有助于管理。

一次批准，还需要说明它覆盖的是哪件事。

即使已经确认是人作的决定，问题也没有全部结束。

还是前面的假设：张经理看到的是一笔 200 元退款，确认后，AI 继续补充资料、更新订单或重试请求。到真正执行时，金额变成了 800 元，收款对象发生变化，或者同一笔退款其实已经处理过。

此时，“张经理曾经同意过”仍然是一条真实记录。但这条同意是否覆盖现在的操作，需要重新判断。

审批可以针对具体一笔业务，也可以针对一类有明确范围的动作。无论采用哪种方式，系统都需要保留批准对象和适用条件，并在执行时检查它们是否仍然成立。

并非每一处无关变化都要打断用户。关键在于事先讲清哪些变化会改变这项决定的含义，让系统据此处理，而不是让模型临时猜测“领导应该也会同意”。

这也是长任务里的真实难点：一次人的确认，如何在多次工具调用、等待、重试和状态变化之后，仍然只作用于它原本授权的事情。

记录的可信程度，取决于它从哪里来。

如果解决方案只是要求 AI 在结果里补一句“已经人工批准”，那我们只是增加了一段文字。

真正的批准信息，应当能关联到组织认可的确认入口或规则来源。Agent 可以引用决定，系统还需要能够核验这项引用是否成立，是否适用于当前请求。

如果流程要求本人逐笔确认，这个入口就应能区分本人确认与代理提交，不能让 Agent 仅凭日常执行凭据代替本人作出确认。预先授权的自动决定，则应另行记录规则来源。

同样，给 AI 换一个独立账号，有助于区分实际执行者，但授权关系仍然需要另外说明：它代表谁，依据哪项委托，这次动作是否在范围内。换了账号名称，并不会自动补出这些事实。

这里也需要承认一个限度：软件无法通过一次登录或点击，直接证明一个人的全部理解和心理活动。即使确实由本人确认，也不能保证他已经发现所有风险。

我们能够改善的，是可观察的过程：当时向谁展示了什么事项，经由什么入口收到了哪项决定，这项决定如何约束执行，以及最终发生了什么。

这些记录应当足以核对，同时控制必要范围，不必因此无限保存员工的全部对话与私人信息。完整性应当围绕业务决定来定义。

批准记录也不能替代结果。人同意了一项动作，工具发出了请求，业务系统真正完成了处理，是需要分别确认的阶段。最后一个阶段仍应依据业务系统掌握的事实核对。

更清楚的记录，也是在保护愿意使用 AI 的人。

如果一个账号名承包了所有解释，员工使用 AI 越多，名下就可能出现越多无法还原的操作。事后讨论容易退回到一句话：“系统里就是你的名字。”

这既不利于查明原因，也不利于推广自动化。人会担心交出工具使用权后，自己无法说明每一步究竟发生了什么；管理者则可能因为看不清过程，收紧原本可以合理开放的能力。

清楚的委托与记录，让各方更容易讨论实际问题：人给出的范围是否明确，机器是否遵守范围，系统是否在条件变化时及时阻止，规则是否应该调整。

它还能把一次异常转化为组织经验。团队知道当时依据了什么、哪里发生了偏差，就有机会调整流程，让下一次决定建立在更充分的信息上。

这使治理有机会成为自动化继续扩大的条件。企业敢于让机器承担更多工作，是因为它越来越能够理解和控制这种委托。

这样的区别，需要在不同系统之间被保留下来。

在一个后台里分清上述关系，只是开始。

当 AI 助手跨越工单、订单、财务和办公系统时，一处产生的批准可能被另一处读取。如果上游表达的是“同意调查”，下游却把它理解为“同意执行”，各自完整的日志仍然无法拼成一个正确的业务过程。

所以，企业除了需要各系统自己的权限和审计，也需要让系统之间对“授权”“决定”“执行”“完成”有可以对照的理解。哪些是人的具体决定，哪些是预先授权的自动判断，哪些仅仅是建议，应当在传递时保持清楚。

我们用 A2B 描述智能体接受人或组织委托、进入已有业务系统并产生业务后果的这类场景。这里发生的变化，涉及软件如何承接人的目标，也涉及组织怎样安排决定权。

ACC 是我们围绕这些问题整理的一份契约范本，希望给能力范围、主体要求、审批意图和记录要求提供可检查的共同表达。声明还需要由实际系统落实；业务系统保留对实时权限和业务条件的最终判断。

百灵中枢则是一种开源实现。我们希望通过真实业务中的接入、失败和修订，把可以复用的经验贡献出来，让后来者少走一些重复的弯路。本文讨论的审批证据设计，是行业共同需要完善的问题，不能靠一份契约或一个工具自动完成。

未来采用什么名称、使用哪一套实现，都可以继续发展。只要机器仍在代表人行动，这些区别就值得被认真保留。

当一条记录写下“已批准”时，我们希望从中读懂：谁作出了决定，依据什么授权，批准覆盖了什么，后来又真正发生了什么。

让 AI 替人办事，也让系统记清人究竟把什么交给了它。