Apollo
全部栏目

人工确认

人工确认让有权限的人决定是否执行具体动作，有效批准需要对应明确的对象、内容和条件。

返回概念图谱 →

理解与应用

人工确认是在关键动作前，把决定交给有权限的人。它可以用于发送消息、提交付款、改变权限或不可逆操作。确认的价值不是多弹一个“继续吗”，而是让人看清系统准备对谁做什么，以及这个决定会产生什么后果。

以给财务发送补充发票为例，待确认信息应包含收件人、邮件正文和附件版本。用户批准的是这组具体内容。若系统随后换了收件地址，或者把 invoice-v2 替换成另一张发票，就已经不是原来的动作；若是同一动作因网络问题需要恢复，则应依据原批准和执行状态处理，而不是盲目重复发送或把所有重试都当成新批准。

系统实现中，待执行动作可以保存为固定版本，把批准者、批准时间、有效期和动作标识关联起来。恢复执行时重新核对这些信息，能防止旧确认被套到新内容上。拒绝、取消和等待也应成为明确状态，不能默认超时就算同意。低风险读取没有必要反复打断用户，确认应集中在真正需要决策的变化上。最后，批准只说明“允许做”，工具回执和结果核验才说明“做成了”；两者不能用同一个成功标记代替。

关系速览
人工确认约束 →工具（Tools）

有副作用的工具调用在提交前需要按风险政策判断是否等待确认。

人工确认约束 →A2A 智能体通信协议

远端任务请求涉及重要行动时，委托方必须保留确认与取消边界。

人工确认约束 →旅行助手

旅程建议与真实订单是不同状态，付款和提交前需要确认具体条件。

人工确认约束 →失败恢复与幂等

重试不得绕过过期或范围变化后的确认，需要重新核验待执行动作。

看一次交互：批准发票邮件后，附件发生了变化

地址与文件均为虚构，示例没有发送邮件。批准需要对应最终动作；实现中可用内容摘要绑定版本，但摘要本身不能证明批准者身份，也不能替代实际发送幂等。

以下为教学示意，未连接真实业务系统。

交互示意

待确认动作：向 finance@example.com 发送报销单 R-204 的补充材料，附件 invoice-v2.pdf。
用户：可以发送。
执行前发现：附件被更新为 invoice-v3.pdf，金额字段发生变化。
系统状态：原批准对应 v2，当前待发送内容对应 v3。

示意结果

暂停当前发送，展示 v3 的实质变化并重新确认。
若附件和其余关键参数都未变，则按原批准继续检查执行状态，无需仅因流程恢复重复提问。

常见误区

  • 只问“继续吗”而不展示对象和重要内容，用户无法做出有意义的决定。
  • 旧批准不能静默覆盖收件人、金额或附件内容的实质变化。
  • 审批通过与执行完成是两个状态，仍需核对实际结果。

前置与延伸

建议先读

相关概念

参考与版本

Apollo 原创讲解与教学示例。参考资料用于核对技术定义；核验日不代表资料的发布日期。