人在回路

本页是 Agent 核心 里“可靠性与 HITL”的展开。在 主线 的报销案里，人工确认出现在第 4 站和第 5 站交界的地方：Agent 已经判断“可以报”，但真正建单之前，必须让员工看到并确认要提交的内容。

哪些地方值得交还给人

问题范围不清、来源冲突、重要数据要更新、要对外发送或者操作不可逆，这些情况都可能需要人明确点头。

一个好操作的办法是按动作的风险分级，由代码来定，别让模型自己评估：

动作	例子	是否确认
只读查询	查制度、查发票	不需要
可撤回的写	生成报销单草稿	视影响而定，通常展示即可
不可逆或对外	提交工单、付款、发邮件	需要
超出授权	替别人提单、改审批人	拒绝或转有权限的人
判断类	制度没覆盖、两份文件冲突	交给人决定

落到代码里可以很简单（示意）：工具注册时就标好等级，query_invoices 标 read，create_reimbursement_ticket 标 irreversible；运行时看到 irreversible 就暂停等确认，不管模型在回复里说了什么。

还有一类事必须留给人：目标和验收。做什么、做到什么程度算完，不能让 Agent 自己定。比如员工只说了“帮我报一下上周的打车”，Agent 不能自作主张把上上周漏报的两张也一起报了。

确认界面应该给什么

确认界面要说清楚：要做什么，依据是什么，可能有什么影响，还要让人能拒绝或修改。后台重试也不能绕过一个已经被拒绝的动作。

拿报销来说，确认卡片至少要有这些内容（示意）：

即将提交：市内交通报销单
金额：118.5 元（标准 80 元，超标 38.5 元，超标部分需审批）
依据：《差旅费管理办法》2026 版 第 4.2 条
关联发票：INV-102
事由：（员工填写）客户临时改了会面地点，夜间打车
提交后：发给部门负责人审批
[同意]  [修改]  [拒绝]

只写一句“是否继续？”的确认，跟没确认差不多，员工根本不知道自己同意了什么。

暂停、恢复与超时

• 暂停：把完整的任务状态写进持久化存储，生成一条待确认记录，然后释放资源。等人的时候别做成同步阻塞。员工可能下午才看到消息，一个进程不该干等几个小时。
• 恢复：人回应以后，带着他的决定恢复任务。人要是改了参数，就得重新校验，还要看这个修改会不会影响后面的步骤。比如金额改了，审批级别可能也跟着变。
• 冻结：确认过的参数，执行时模型不能再改。可以给参数算一个摘要（比如 a91f…），执行前比一下，对不上就停。
• 拒绝：被拒绝的动作要写进状态，之后不管是重试还是重新规划，都不能绕过去。
• 超时：默认不执行。可以提醒，可以升级给其他有权限的人，也可以让任务过期并通知发起人。

常见失败

• 确认疲劳：每一步都弹确认，人很快就开始闭着眼点同意，最要紧的那次确认也跟着没了意义。确认点要少，要准。如果查制度、查发票、生成草稿、提交各弹一次，员工到第四次多半已经不看内容了。
• 假确认：确认时给人看的是摘要，执行的却是另一组参数。比如卡片上写 118.5 元，模型在执行前又把金额改成了 120 元。
• 把一次同意当成永久授权：员工同意了这张单，不等于同意之后所有的建单动作。
• 让模型判断要不要问人：模型对自己的把握常常估得过高。风险等级应该由动作类型和参数来决定。

怎么检验确认点设计得对不对

确认点也要评测，别等上线后再凭感觉调：

• 该问的都问了：评测集里放一批高风险动作（提交、付款、替别人操作），检查每一条都停在了确认环节，未经确认的写操作必须是零。
• 不该问的没问：只读查询、可撤回的草稿不该弹确认。统计每个任务平均弹几次确认，太多说明设计有问题。
• 拒绝真的生效：拒绝之后再注入一次工具超时或重新规划，检查 Agent 不会换个方式把同一个动作再执行一遍。
• 超时走了预期分支：模拟没人响应，看任务是取消、升级还是过期，而不是被默认执行了。
• 人的修改被尊重：人把金额改了以后，最终执行的参数要和确认的一致。

线上可以盯两个信号。一个是确认的通过率：要是接近百分之百、而且每次从弹出到点同意只用一两秒，多半说明人在盲点。另一个是被拒绝动作的类型分布：拒绝集中在某一类动作上，说明 Agent 在那里的判断有系统性偏差。

先在知识维护中实践

以后让 Agent 给 知识花园 提新节点和新关系时，先把它的提议存成候选，由作者检查后再发布。模型生成的内容不能直接当成确认过的知识。

这跟报销案是同一个结构：Agent 负责准备和说明，人负责对有外部影响的那一步拍板。工具层怎么保证确认后的执行不重复、不越权，见 可靠执行 和 安全边界。