AI Agent 工具调用人工审批：确认什么，何时需要重新批准
人工点击批准不等于工具已经执行。围绕审批对象、关键参数、有效期和执行前校验，设计企业智能体高风险操作的人工确认流程。
智能体已经准备好一张业务单据，界面也弹出了“是否执行”。人点下批准后，系统到底获准做什么：提交眼前这份草稿，还是在同一段对话里继续修改其他记录？如果这个边界没有定义，确认按钮可能只是多了一次点击，并没有形成可检查的控制。
AI Agent 工具调用的人工审批，需要把人的决定与具体操作连接起来。本站系统集成说明公开了写操作授权清单、参数校验和人工确认方向；本文进一步讨论通用设计方法，不表示本站已经采用下文的固定字段、时限或实现，也不替代企业现有审批制度。
先分清工具确认与业务审批
工具确认回答“是否允许智能体发起这次操作”，业务审批回答“这件事是否满足组织的办理条件”。允许智能体提交一份采购申请，不等于采购已经获得批准；允许创建工单，也不等于允许关闭工单或执行设备控制。接入 OA、ERP 或 MES 时，应明确操作落在哪个环节，不能用聊天中的一句“可以”越过原系统的审批链。
也不要只按工具名称判断风险。同一个接口，查询本人可见的状态与批量导出资料，影响范围可能不同；看似读取的操作，如果把结果发往外部，也可能需要额外确认。可从写入对象、数据去向、影响数量与可撤销性出发分类，再按项目规则确定哪些操作必须人工参与。
OWASP 的 Excessive Agency 风险说明建议限制工具功能和权限，并对高影响操作设置人工批准，同时在下游系统执行授权校验。人工确认因此是一层控制，不是把一个高权限账号交给模型后再补一个弹窗。
让批准对应一份明确的操作
确认界面要让人看懂将发生的变化，而不是只显示“调用工具 A”。例如，下面是一个假设的仓库调拨申请：将物料 A 的 100 件库存从甲仓调至乙仓，并创建待审批的调拨申请。确认内容应保留仓库、物料、数量和单据状态，明确本次只创建申请，不直接完成出库。
- 操作与对象：将创建、修改、删除或发送什么，影响哪条记录、哪一批对象，处于哪个企业或工作空间。
- 关键参数：让人能核对决定业务后果的字段；修改已有记录时，可展示修改前后的差异。
- 数据去向与执行身份：涉及哪个系统、是否对外发送、以谁的权限执行。不要展示密钥或认证令牌。
- 结果与边界：会生成草稿、发起流程还是直接生效，哪些后续步骤不在本次批准范围内。
工程上可为待审批操作保存一个服务端记录，关联任务、操作内容、审批人和决定。前端提交批准时引用该记录，而不是仅传回一个脱离上下文的布尔值。字段如何组织由现有业务系统决定，不必为了人工确认另外建设一套审批平台。
若一次展示多项操作，应逐项列明，或给出足以核对的批次范围与差异明细。执行范围扩大、对象发生变化时，不能继续使用原来针对较小范围的批准。
等待期间发生变化怎么办
人在会议后才处理确认消息时，草稿、权限或业务状态可能已经改变。继续使用旧批准之前，需要区分哪些变化只是显示格式，哪些变化会改变实际业务含义。后者应使原批准失效，并重新展示待执行内容。
沿用调拨申请的假设场景：数量从 100 件变成 120 件、目标仓库改变，或动作从“创建待审批申请”变为“直接执行调拨”，都不是同一份授权。系统应清晰说明变化，而不是让模型自行判断“差不多”后继续。
OWASP 交易授权指南提出保护授权数据、限制有效时间，并在执行处设置最终检查。这里借鉴的是批准与操作绑定的原则，并不是要求所有智能体操作采用银行交易的认证方式。
审批有效期应按业务变化速度与人的处理时间约定，不存在适合所有项目的固定分钟数。过期后重新核对当前内容；账号被撤权、单据已由他人处理，或者规则版本不再兼容时，也应停止使用旧批准。重启后恢复任务，应恢复同一条待审批记录，而不是从历史聊天里寻找某次“同意”。
执行前仍要检查当前条件
人工批准与服务端授权是两个问题。审批人同意业务动作，不会自动扩大执行账号的权限；输入看起来合理，也不证明目标记录仍可修改。执行端应使用当前身份和业务规则重新校验，并核对准备执行的内容是否仍对应已批准的操作。
- 读取待执行操作及其审批记录，确认决定属于这项任务和正确的业务范围。
- 确认操作没有过期、撤销或被替换，实际参数与获批内容一致。
- 检查当前账号、资源权限、输入格式和业务前置条件；不满足时返回明确原因。
- 通过受控执行入口发起操作，记录真实回执，再向用户说明完成、失败或待确认状态。
这些检查应位于实际执行链路，不能只写在模型提示词中。涉及并发修改时，还需要利用业务系统支持的版本检查或其他一致性机制，避免检查之后记录又被他人修改；缺少这种能力时，应说明边界并缩小自动执行范围。
现有框架可以帮助暂停和恢复运行，但应用仍要负责业务含义。Microsoft Agent Framework 的工具审批文档展示了取得函数名称及参数、向用户收集批准或拒绝决定、再继续会话的模式。框架提供中断入口，不代表它已经理解你的单据状态或岗位职责。
取消、拒绝与结果未知分别处理
“已批准”不能立即显示为“业务已完成”。确认只是执行的前置条件，结果仍应以业务回执为准。建议在界面上区分等待审批、已拒绝、已过期、执行中、执行成功、执行失败与结果待确认，并让人知道当前还能做什么。
拒绝后不应换一个工具继续做同一件事；待执行阶段取消后，也不应被旧队列消息重新激活。但操作已经提交到业务系统时，取消等待不一定能撤回业务动作，应查询真实状态，必要时走原系统的撤销流程，而不是承诺“关闭对话就全部取消”。
重复点击批准、消息重复投递或接口超时，需要与业务动作的去重和结果查询一起处理。不要因为没有拿到响应就要求用户再批准一次，并制造第二笔操作。相关技术边界可继续阅读ERP 写接口的超时、重试与重复单据处理；审批记录如何与调用结果连接，可参照智能体审计日志的事件关联方法。
用异常用例验收审批链路
验收时不只演示“点同意后成功”。以下是一组可按项目裁剪的检查用例，不是本站实测结果，也不是任何认证清单：
- 拒绝操作：明确拒绝后，目标系统不应收到对应写入；换个说法继续对话也不能沿用被拒绝的决定。
- 修改关键参数：审批后改变数量、对象或接收方，应重新确认，且原记录可用于解释变化。
- 权限或状态变化：撤销执行权限、由他人处理目标单据后，恢复任务应按当前规则停止或重新评估。
- 审批过期与重启：过期批准不能直接执行；未过期任务重启后仍关联原记录，不混入其他会话。
- 重复批准与超时：重复消息不得被当成新的业务授权；响应丢失时展示待确认，并查询原动作结果。
- 跨范围引用：将其他用户或其他业务空间的审批编号放入请求，应被拒绝，而不是因为编号存在就放行。
每条用例记录准备条件、操作步骤、预期结果、实际回执及观察到的业务状态。检查重点不是弹窗有没有出现，而是未经正确批准的动作有没有被阻止，获批动作有没有保持原本的范围，执行结果能否被解释。
人工审批的价值，是让人的决定真正约束后续动作。把确认内容写清楚，把变化和过期处理好，再把检查放到执行入口，比反复询问一句“确定吗”更接近可用的控制。
参考资料
- OWASP：LLM06:2025 Excessive Agency，高影响操作的人工批准、最小权限与下游授权。
- OWASP：Transaction Authorization Cheat Sheet，授权内容、有效时间与执行检查的设计原则。
- Microsoft Learn：将函数工具与人工干预审批流程结合使用，工具审批的暂停、决定与恢复模式。
资料查阅日期：2026 年 9 月 12 日。具体工具版本、接口语义和审批制度应以项目采用的实现为准。
