温和交接模式：设计智能体与人类之间的流畅控制权转移

大多数智能体升级流程都是披着善意外衣的冷转接。智能体决定无法继续推进，丢下一句"正在为你转接人工客服"，然后将会话路由给一个对此前发生的一切一无所知的坐席——不知道智能体尝试了什么、哪里失败了、用户究竟需要什么。人工客服从零开始，用户不得不重复自己。信任就此侵蚀——不是因为 AI 出了错，而是因为没有人设计好那个边界。

温和交接模式是一套架构规范，专门针对智能体让渡控制权的那个关键时刻。它将这个边界视为系统的一等关注点，而非事后诸葛。做好了，接收方——无论是人类还是另一个智能体——都能进入一个已经被充分告知、结构清晰的场景。做差了，那个边界就是用户信任的坟场。

冷转接的失效模式

在生产环境的客服系统中，这个经典失效模式随处可见。AI 完成了初始接待，收集了问题描述，验证了账户数据，尝试了三种解决路径，然后失败了。接着它将用户转接给人工客服——只传递了一个电话号码。

人工客服接听电话，用户重新描述问题。客服询问 AI 已经获取的账户号码，用户在挫败感中解释自己已经和 AI 尝试过什么。

这通电话本来没必要持续这么久，而用户此时的情绪比刚开始时更糟。

这种模式在代码辅助智能体、文档处理流水线和任务自动化系统中反复出现。"升级"被实现成了一次退出，而非一次交接。接手工作的人完全没有携带任何先前状态。

结构性问题在于，大多数团队将智能体交接视为路由问题（"由哪一方来处理？"），而非状态转移问题（"接收方需要了解什么？"）。路由是一个二元决策，而状态转移是一个需要精心设计的打包问题。

温和交接真正需要什么

温和交接包含三个层次，三者都需要穿越那个边界：

操作历史是审计层——智能体做了什么、按什么顺序、得到了什么结果。这包括完整的工具调用日志（含输入输出）、每个决策背后的推理过程、每个步骤检索到的数据，以及可获取时的置信度。目的不是总结，而是保全：人类可能需要理解的不仅是发生了什么，还有智能体为何做出特定选择。

当前上下文是让人类在不阅读完整对话记录的情况下，能够理解当前局面的最小可行简报。这意味着用 2—3 句话综合描述问题、用通俗语言表达用户意图、已提取的实体（姓名、ID、金额、日期）、适用的约束条件，以及用户的情绪状态。一名人工客服应该能在 30 秒内读完这份简报并真正了解情况——而不仅仅是知道"有什么事发生了"。

结构化问题陈述是委托本身。智能体不是简单地说"请处理这个"，而是明确指出需要人类判断的具体问题，列出可选方案及智能体评估后的利弊，并对每个选项的风险进行分类。一个带有明确 reason、priority、summary 和 options 字段的 Pydantic 类型化交接载荷，能迫使智能体精确说明无法解决的问题所在，而不是把模糊的不确定性继续传递下去。

投资于结构化交接载荷的团队，可以将人工准备时间从 15 分钟（阅读原始对话记录所需）压缩到不足一分钟。相同的信息，只是为接收方重新打包了一遍。

混合主动：超越二元控制

一旦任务跨越几分钟的时长，"智能体模式"与"人类模式"的二元划分就会失效。真正的协作工作要求双方随时都能主动发起和让渡控制权——这不是通过升级来实现的，而是正常任务流程的一部分。

Eric Horvitz 在 1999 年将其阐述为"混合主动交互"：有效的人机协作要求动态的控制权分配，而非静态的角色分配。他的框架将主动性视为二维的——人类和智能体在任意时刻都可以独立地拥有高或低的主动性，系统必须支持任意方向的切换。

到了 2025 年，这一框架已经映射到了生产级智能体系统中。相关模式包括：

• 执行多步骤任务的智能体在进行破坏性操作前暂停，请求人类确认——不是因为失败了，而是因为该操作值得监督。这是智能体主动发起澄清，而非升级。
• 人类在审查智能体计划时修改了某个步骤，然后将控制权还给智能体。智能体必须在继续之前将这个修改与其余计划协调一致——不能丢弃所有先前工作，也不能无视这次编辑。
• 长时运行的智能体在某个分支处发现置信度不足，无法在没有更多自身无法获取的信息的情况下选择路径。它将该分支作为决策点呈现给人类，等待回应，然后恢复执行。

混合主动与简单升级的区别在于：控制权转移是被预期的、可恢复的，而非异常情况。系统被设计为在双向、多个时间点、多轮交互周期中进行交接。

序列化状态以支持恢复

温和交接模式的技术核心是状态序列化——在中断点捕获足够的信息，以便后续能够正确恢复。

在开源工具链中，LangGraph 的 interrupt() 函数是这一模式的标准实现。智能体图中的任意节点都可以调用 interrupt()，携带一个结构化载荷；框架随即暂停执行，将完整的图状态检查点保存到持久化存储，并将中断事件暴露给外部系统。当外部调用 graph.invoke(Command(resume=value)) 时，恢复就此开始，框架从检查点向前重放，在中断点注入人类的输入。

这产生了一个关键的架构选择：有状态快照还是无状态检查点。

有状态快照将完整的执行上下文保存在内存中，恢复速度快——智能体立即接续执行。但它与特定进程绑定；如果该进程崩溃（由于宕机、缩容或维护），快照就会丢失。这适用于在数分钟内能解决的短时间中断。

无状态检查点只将数据层状态序列化到持久化存储。它可以跨进程和时间移植——人类可以在数小时后响应，智能体可以在任何实例上恢复。代价是恢复时需要重放部分计算。对于异步审批流程，这是正确的默认选择。

实践建议：对于智能体等待人类秒级响应的同步澄清流程，使用快照；对于人类可能在第二个工作日才响应的异步审批工作流，使用检查点。

三种恢复失效模式

当人类归还控制权时，大多数实现只处理了顺利路径——人类批准，智能体继续。在生产中真正出现的失效模式是：

恢复时的上下文丢失。 智能体恢复时没有正确整合人类的决定。这种情况在人类输入作为新消息传入（而非注入到推理链的中断点）时很常见。智能体读取了批准信息，却沿着原有轨迹继续，把人类的输入当作背景上下文而非更新后的约束条件。

依赖冻结。 当一个步骤在等待人工审查时，任务图中不相关的分支也被一并阻塞。范围不当的中断会停止不需要监督的工作。正确的模型是细粒度中断：只暂停依赖于待定决策的分支，其余继续运行。

会话超时无后备方案。 人类没有在预期窗口内响应。智能体没有定义好的行为：它可能无限期等待、让任务失败，或反复重试被阻塞的步骤。生产系统在每个中断点都需要明确的超时处理：超过时限后，智能体进一步升级、将任务标记为需人工处理，或执行安全的默认路径。

这三种失效都源于将恢复视为事后补丁。设计恢复路径——即人类修改与智能体计划之间的协调——需要与交接本身同等程度的刻意关注。

触发交接而不依赖自信心

启动交接最显而易见的触发条件是智能体的置信度分数低于某个阈值。问题在于，LLM 的自信心存在系统性偏差。实证数据显示，智能体预测某类任务成功率为 70—75%，而实际完成率仅为 20—35%。基于置信度的阈值要么产生过多中断（智能体升级琐碎决策），要么产生过少（智能体带着错误信心一路推进，直到它看不到的错误发生）。

更可靠的触发条件分为两类：

确定性触发器在不需要模型判断的结构性条件下触发：工具输出相互矛盾、缺少必填字段、命中合规关键词、操作超过爆炸半径分类。读操作自由运行；修改状态的操作需要验证；不可逆操作始终触发中断。这些条件在代码中明确指定，而非由模型推断。

行为触发器在执行图中的模式上触发：当智能体对同一查询重新表述并重试超过两次时触发循环检测；超出原始任务边界时触发范围蔓延；超过可靠性阈值的链长；以及智能体反复检索又丢弃信息时触发上下文抖动。这些需要对执行轨迹进行运行时观察，而非模型自省。

实践目标是 10—15% 的中断率。超过 20%，审核者会停止认真阅读——橡皮图章问题随之而来。低于 5%，系统很可能在真正需要监督的边缘案例上存在升级不足的情况。

让交接感觉自然的 UX 模式

在面向人类的层面，交接的工程质量是不可见的。人类感受到的，是这个过渡是连续流畅的还是突兀中断的。

有几个因素能可靠地区分自然与突兀的交接：

交接前的上下文告知。 接收方人类应该在与用户交互之前就已经被告知情况。在语音系统中，这意味着 10—15 秒的等待，让 AI 在接通通话前对人工客服进行简报。在异步系统中，这意味着在任务队列通知审核者之前，操作卡片就已经可见。人类绝不应该在响应用户的同时才去了解情况。

用户界面中的连续性信号。 用户不应该看到模式切换。对话线程继续；改变的只是谁在其中行动。在人工接管可见的场合，"我已经查阅了你与我们助手的对话"这样的确认措辞，能在不隐藏切换的前提下减少重复说明的负担。

向用户开放的自主权级别控制。 最有效的交接设计让用户在工作开始前就能设定自己的监督级别。"建议"、"草稿"和"执行"这样的模式，让用户自己划定边界，而不是强迫团队猜测正确的默认值。研究始终表明这能提升信任感和满意度——不是因为用户总是选择高监督，而是因为这是他们自己的选择。

回滚作为标准选项。 当智能体已执行了用户可以在审计轨迹中看到的操作时，撤销已完成步骤的功能应该是可见且可用的。对不可逆操作不在交接中明确说明其不可逆性的智能体，会破坏的不只是那次交互的信任，而是对整个系统的信任。

恢复路径是双向的

大多数交接设计在从智能体到人类的方向上精心设计，而将人类返还控制权给智能体这一过程视为微不足道。其实不然。

当人类解决中断并将控制权还给智能体时，智能体有三种可能的状态：人类批准了计划中的操作、人类修改了它，或者人类提供了应该改变计划的新信息。

每种情况都需要不同的恢复协议。只有批准这种情况是直接继续执行的正确选择。修改需要智能体验证编辑后的参数是否与已完成的先前工作一致——而不是盲目采纳编辑然后继续。新信息可能会使智能体已经遍历过的任务图中的某些部分失效；智能体需要识别哪些步骤需要重新执行，哪些输出仍然有效。

实际的工程含义是：智能体执行图中的每个中断点都应该在恢复时包含一个协调步骤。不是"从这里继续"，而是"考虑到人类刚告诉我的，我需要重新审视什么？"

这个协调步骤正是当前大多数框架最薄弱的环节。将它作为一个具有明确语义的命名组件来显式构建，是区分能够支持真正混合主动工作的交接基础设施与仅支持简单审批流程的交接基础设施的关键所在。

从何开始构建

如果你正在为现有智能体系统添加交接支持：

结构化交接载荷是杠杆率最高的第一投入。在构建恢复协议、会话状态管理或自定义 UX 之前，先定义跨越边界的数据模型。一个包含 reason、priority、summary、actions_taken、pending_question 和 options 的 Pydantic 模型，给了你一个可以验证的具体标准、一个可以在审核界面中展示的具体内容，以及一个可以在恢复时注入到智能体上下文的具体对象。

在载荷模型之后，优先实现确定性触发器而非基于置信度的触发器。为你的工具集定义爆炸半径分类——哪些工具是只读的、哪些会修改状态、哪些是不可逆的——并基于这个分类构建中断逻辑，而非依赖模型置信度分数。

会话超时处理优先于大多数 UX 打磨。一个无限期等待人类响应的智能体，即使交接载荷完美无缺，也是一个可靠性失效。在将异步审批流程发布到生产之前，先在每个中断点定义好超时行为。

温和交接模式并不是复杂的工程。它是将智能体与人类的边界视为刻意设计的架构，而非出问题时才去处理的边缘案例，这种规范本身。

---

混合主动系统的学术文献将 Eric Horvitz 1999 年 CHI 论文《混合主动用户界面的原则》奉为本文所引用基础框架的源头。