Agent 里的人工介入怎么设计：不是加个确认按钮
数据截至 2026-07，价格与限额以各官网为准。
人工介入的难点从来不是”弹不弹确认框”，而是 Agent 被打断之后，它的状态能不能原样存下来、几小时后能不能从断点继续跑。确认按钮是最后一小步，绝大部分工作量在状态持久化、动作分级和审批信息的组织上。 只把介入当成 UI 问题的团队，通常会在上线两周后发现：人点了同意，Agent 却重头跑了一遍，或者干脆丢了上下文重新问一遍用户。
先承认一个很普遍的误解：不少人以为 human-in-the-loop 就是”高危操作前面加一道人工确认”，把它归到前端交互的活儿里。真正做过一轮就知道，这个需求会一路穿透到执行引擎——你得能在任意一个工具调用之前把整个执行现场冻住，能把冻住的现场序列化落库，能在人类几小时甚至第二天上班后回来时把它解冻，还得处理”人改了参数再继续""人直接替 Agent 干完这一步”这些分叉。这不是加个按钮能解决的。
一、先问一句：这个动作真的需要人来点头吗
设计介入点之前，最该做的是砍掉不必要的介入。每加一道人工确认，都在给使用者增加负担，加到一定程度人就开始无脑点”同意”——那时候这道关卡已经形同虚设，还给团队制造了”我们有人工审核”的错觉，比没有更危险。
给动作分级是个笨但有效的办法，按”做错了以后能不能撤回”来分：
- 可逆且低影响：读文件、查数据库、搜索、生成草稿。这类不该拦。
- 可逆但有痕迹：发内部消息、创建工单、写入测试环境。这类做事后通知，不做事前拦截。
- 不可逆或对外：给客户发邮件、调支付接口、删数据、改生产配置、提交代码到主干。这类必须停。
- 成本敏感：批量调用大模型、跑长任务、触发计费型第三方服务。这类按阈值停——单次小额放行，累计超过预算才拦。
分完级你会发现，真正需要人点头的动作没几个，剩下的都能靠日志和事后回溯兜住。把介入点控制在个位数，比铺一堆确认框有用得多。
一个实操建议：不要在代码里散落判断，把”哪些工具需要审批”做成一张配置表，工具注册的时候带上风险等级字段。这样调整策略不用改执行逻辑，也方便让业务方直接参与定级。
二、介入不止”同意/拒绝”，实际有四种形态
真跑起来会发现，人想干的事比二选一多。按我们见过的场景，可以归成四种（这四种建议都留出接口，哪怕先只实现前两种）：
- 审批放行：Agent 提出要做某个动作，人看完点同意或拒绝。最基础的一种。
- 修改后继续：人不否定这个动作，但要改参数——邮件正文改两句、金额调一下、把收件人换掉，然后让 Agent 拿改后的参数继续执行。
- 补充信息：Agent 卡住了，缺一个它拿不到的输入，比如客户的内部编号、某份合同的具体条款。人把信息塞进去，Agent 继续往下走。
- 接管这一步：人干脆自己把这步做了，然后把结果告诉 Agent，让它从后面接着跑。适合那些 Agent 本来就做不好的环节。
这四种的实现难度是递增的。第一种只需要一个布尔返回值；第二种要求你的状态结构允许外部写入并覆盖；第三、四种意味着人类的输入要以跟工具返回值一样的形式进入执行流。如果一开始的状态设计只支持”通过/不通过”，后面想加后两种就得动骨头。
三、中断点必须落在状态上，不能落在进程上
这是整篇最要紧的一条。
很多第一版实现是这样的：Agent 跑到危险动作，程序阻塞住等一个 HTTP 回调，人点了就往下走。开发环境里这套跑得挺好，上线就出事——审批的人下班了，第二天才看消息；服务重启了；容器被调度走了；请求超时被网关掐了。阻塞式的等待假设”人会在几十秒内回应”，而现实中人工审批的等待时间以小时计。
正确的做法是把中断做成一次有终点的暂停：Agent 执行到中断点，把当前的完整状态（已经走过哪些节点、中间变量、待执行的动作和参数、对话历史指针）序列化写进存储，然后这次执行就正常结束、进程释放。人做完决定之后，是一次新的执行从存储里把状态读回来，接上决定继续跑。
这套机制通常叫 checkpointing（检查点）。第三方实战对比里提到，LangGraph 对执行流的控制更精细，支持持久化的长时运行工作流与 human-in-the-loop，自带 checkpointing、streaming、human-in-the-loop 这几类原语——这是它在这个场景里被反复提到的主要原因。具体这些原语当前叫什么名字、怎么配置，以各项目官方文档当前版本为准，本文不复述 API。
自己实现也不是不行，关键是想清楚三件事：
- 状态要能完整序列化。状态里不能塞数据库连接、文件句柄、闭包这种存不下来的东西。有人踩的坑是把一个 client 对象放进了状态，序列化直接报错，或者反序列化回来是个失效的连接。
- 每个检查点要有唯一 ID，并且可寻址。人回来点同意的时候，系统得知道”接哪一个”。用会话 ID 加节点序号是常见做法。
- 恢复必须幂等。同一个检查点被恢复两次（用户点了两下、消息重投），不能把那个动作执行两遍。给待执行动作发个一次性令牌，执行前先原子地标记消费掉。
只要中断能落到存储上，等多久都不怕；落在进程上，等超过一个心跳周期就开始出玄学问题。
四、框架现在能帮到哪一步
这块的信息半年就变一次，下面只说结构性的差异，全部以各项目官方文档当前版本为准。
LangGraph 的模型是有向图：节点是函数或 LLM 调用，边定义控制流，状态以带类型的字典在其中传递。这个模型天然适合做中断——图的执行本来就是一步步推进的，在某条边前面停下来把状态存了，语义上很干净。第三方对比里给它的评价是控制力最强、生产成熟度最高、生态规模最大，代价是学习曲线也最陡。带反馈环的循环任务上它被认为胜出，而人工介入往往就是一个循环：提议 → 人否掉 → 改 → 再提议。
CrewAI 的模型是一队有明确角色的 agent（研究员 → 写手 → 审稿），可以串行也可以并行。学习曲线在三者里最平缓，一天内要出个能用的原型它很合适。这里要更新一个旧印象：CrewAI 在 2025 年加了 Flows，一种事件驱动的 pipeline 模式，面向更可预测的生产型负载，多数较早的对比文章没有涵盖这一点——所以”CrewAI 只能做原型”这个结论现在不该再直接照搬。不过循环这块，第三方口径是它技术上支持，但调试起来比较痛苦，而人工介入恰恰会引入循环，选型时值得掂量。
AutoGen / AG2 走的是对话式路线，agent 之间互相交谈，对话模式最丰富，多方辩论、达成共识这类场景是它的强项。但有一条选型时必须知道的信息：微软把重心转到了更大的 Agent Framework，AutoGen 的主要新功能开发已经停止，进入维护模式，仍有 bug 修复和安全补丁。有实践者据此直言，2026 年不建议把它作为新项目的起点。这不意味着存量项目要恐慌迁移——它还在维护——但如果你正在为一个要跑三年的系统选底座，这条信息应该进决策表。
还有一条容易被忽略的提醒，值得放在选型之前：单个 agent 只调一两个工具的时候，OpenAI Agents SDK 或 Anthropic Claude Agent SDK 往往是 2026 年更快的路径，你可能根本不需要多智能体框架。 人工介入这个需求本身不构成上多智能体框架的理由——一个单 agent 加一张审批表 + 一个状态存储，很多时候就够了。想清楚再上，别为了一个确认环节引入一整套编排系统。
互操作方面顺带一提：CrewAI 已加入 A2A 支持；OpenAgents 声称自己是唯一原生同时支持 MCP 与 A2A 的框架（这是该项目自己的说法，本文未做独立核实）。协议这条线更细的展开可以看 Agent 协议生态对比，框架整体选型看 主流 AI Agent 框架对比。
五、给审批者看什么，比让他点什么更重要
做到这一步，剩下的问题变成：人凭什么做这个判断？
见过最糟糕的审批界面，是把工具调用的原始 JSON 直接甩出来让人看。参数名是英文缩写，值是一串 ID，人根本没法判断这封邮件会发给谁、这笔钱会扣在哪。人只能点同意。
一个能用的审批卡片，至少要包含这几项：
- Agent 打算做什么，用一句人话说清楚，不是函数名。
- 关键参数的人类可读形式：客户 ID 要翻译成客户名称，金额要带币种，收件人要显示邮箱和姓名。
- 它为什么要这么做：把这一步之前的推理链或者触发条件摘出来，一两句。
- 做错了会怎样：可不可逆，影响范围多大。这条最容易漏，但对判断最有帮助。
- 拒绝之后会发生什么：是整个任务终止，还是走备选分支。人得知道点”否”的后果。
另外，把”修改后继续”的入口放在卡片上，比只有同意/拒绝好用得多——大部分被拒绝的动作其实只是某个参数不合适，人愿意顺手改掉，而不是让整条流程重来。
六、没人点怎么办：超时与降级
人工环节最大的运行风险是”人不在”。这块要在设计阶段就定策略，而不是等它卡住了再补：
- 给每个审批设超时，超时后的默认行为必须显式声明。不可逆动作的默认应该是拒绝（fail-safe），不是通过。这条没有商量余地。
- 升级路径：一级审批人超时未处理，转给二级或者值班组，而不是无限期挂着。
- 批量场景要能一次处理多条，否则积压几十条时人会开始盲点。
- 可撤销窗口：有些动作可以先执行、留一段可撤回的时间（比如邮件延迟几分钟发出）。这种”软介入”体验比硬拦截好，前提是那个动作真的能撤。
- 降级路线：审批系统本身挂了怎么办？Agent 应该停在检查点上等待，而不是因为拿不到审批就当作通过继续跑。
七、介入记录本身是有价值的数据
人每一次点同意、拒绝、改参数，都是在给你的系统打标注。这些记录别只当审计日志存着：
- 某个动作长期通过率极高，说明这道关卡可以考虑放宽，甚至改成事后通知，把人从重复劳动里放出来。
- 某个动作经常被改参数，说明 Agent 生成这个参数的提示词或工具描述有问题，改上游比一直靠人补救划算。
- 某个动作拒绝率高，说明这一步的触发条件定得不对，Agent 在不该做的时候提议做。
再往前一步，这些人工修正是很好的评测集来源——用它们来回归测试提示词改动，比自己编几条测试用例贴近真实。至于要不要拿来做微调，取决于数据量和合规要求，这里不下断言。
顺带提醒：审批记录里往往含客户信息、金额、合同片段，存储和访问权限要按敏感数据对待，保留期限也要跟公司的数据策略对齐。
八、几个反复见到的坑
- 确认框加得太多，人开始无脑点同意。宁可少设几道，把每一道都做成真的会被认真看的。
- 状态里塞了不可序列化的对象，恢复时直接炸。状态只放纯数据。
- 恢复不幂等，用户点两下，邮件发两遍。一次性令牌是必须的。
- 审批卡片只放原始参数，人无从判断，关卡形同虚设。
- 超时默认通过，等于把最危险的路径设成了默认路径。
- 为了一个确认环节上一整套多智能体框架，复杂度涨了一个量级，收益没有。先看单 agent 方案够不够。
- 只做了”同意/拒绝”，后来发现业务真正需要的是”改一下再继续”，状态结构改不动。
小结
人工介入的设计重心在执行引擎，不在界面。先按可逆性给动作分级，把介入点压到个位数；把中断做成能落库、能恢复、能幂等重放的检查点，而不是让进程阻塞等回调；至少留出审批、修改、补充、接管这四种介入形态的接口；给审批者看人话和后果，而不是原始参数；超时默认走拒绝，并想好谁来兜底。框架选择上，LangGraph 在持久化长时工作流和带反馈环的循环上被第三方对比反复提到，CrewAI 用 Flows 补上了生产型负载的短板，AutoGen 进入维护模式这条要进选型表；但在动手之前，先诚实评估一下你是不是真的需要多智能体框架——很多人工介入需求，一个单 agent 加一张审批表就够了。