让智能体查库存，结果错了还能重查。让它发邮件、删记录或执行 SQL，错误会立刻进入真实系统。人在回路给这类动作加一个暂停点。模型提出工具调用以后，程序先保存当前状态，把待执行动作交给人看，人决定以后再继续。
我查了 LangChain 和 OpenAI Agents SDK 当前的人工审批文档。两套实现都把审批放在工具调用前，并允许暂停后恢复原来的运行。一个能点的批准按钮只是界面。系统还要明确哪些动作必须停、审批人看见什么，以及等待期间怎样保存状态。
审批人要看到具体参数
LangChain 的 HITL 中间件会按工具策略判断是否中断。写文件和执行 SQL 可以要求审批，只读查询可以直接通过。暂停信息里会带工具名称和参数，审批人可以原样批准、修改后执行、拒绝并给出反馈。它还有一种 respond 决定，用于人直接回答 ask-user 一类工具。文档特别提醒，respond 不能用来拒绝有副作用的工具，因为程序会把它当成一次成功的工具结果。
审批卡片若只写“是否继续”，人很难判断风险。发送邮件至少要显示收件人、主题和正文，删除记录要显示筛选条件与预计数量，退款要显示订单、金额和账户。参数被编辑以后，系统应把最终执行值写入记录。多个动作同时暂停时，每个动作都要单独决定，并按原请求顺序提交结果。
暂停以后还要接得回来
LangGraph 依靠持久化层保存运行状态，生产环境需要持久化的 checkpointer。恢复时继续使用同一个 thread ID，程序才知道该从哪次暂停接着跑。只把审批消息发到群里，却没有保存状态，服务重启后就可能找不到原任务，或者重复执行已经做过的步骤。
OpenAI Agents SDK 也会把暂停结果转成可序列化的 RunState。人批准或拒绝后，程序用这份状态继续原来的顶层运行。审批通常绑定具体的 tool call ID，避免一次批准被后来的另一笔调用沿用。它还支持按参数决定是否需要审批，参数无法安全解析时会停止自动判断，转为人工审批。
全部动作都要求人点一下，会让审批很快变成例行点击。可以把只读、可撤销的小动作自动放行，把发送、删除、付款和改权限留给人。审批记录至少保留申请动作、最终参数、决定人、时间和执行结果。拒绝以后也要告诉智能体原因，让它停止、改参数或换一条安全路线。
试点时先选一个高风险工具，故意制造批准、修改、拒绝和服务重启四种情况。四条路径都能恢复，执行记录也能对上，人工确认才真的进入流程。按钮放在动作完成以后，只能算事后通知。