在交接架构中,行为会根据状态动态变化。核心机制是:工具更新一个跨轮次保持的状态变量(例如 current_step 或 active_agent),系统读取该变量以调整行为——要么应用不同的配置(系统提示、工具),要么路由到不同的智能体。此模式既支持不同智能体之间的交接,也支持单个智能体内部的动态配置更改。
交接这一术语由 OpenAI 提出,用于指代使用工具调用(例如 transfer_to_sales_agent)在智能体或状态之间转移控制权。

主要特性

  • 状态驱动行为:行为根据状态变量(例如 current_step 或 active_agent)而变化。
  • 基于工具的过渡:工具更新状态变量以在状态之间转移。
  • 直接用户交互:每个状态的配置直接处理用户消息。
  • 持久状态:状态在多个对话轮次之间保持。

适用场景

当需要强制执行顺序约束(仅在满足先决条件后解锁功能)、智能体需要在不同状态下直接与用户对话,或者你正在构建多阶段对话流时,请使用交接模式。此模式特别适用于客户支持场景,例如你需要按特定顺序收集信息——比如在处理退款之前先收集保修ID。

基本实现

核心机制是一个工具,它返回一个 Command 来更新状态,触发向新步骤或智能体的过渡:
为什么要包含 ToolMessage? 当大语言模型调用一个工具时期望得到响应。带有匹配 tool_call_id 的 ToolMessage 完成了这个请求-响应周期——没有它,对话历史会变得格式错误。只要你的交接工具更新了消息,就需要这样做。
完整实现请参见下面的教程。

教程:使用交接机制构建客户支持

了解如何使用交接模式构建一个客户支持智能体,其中单个智能体在不同配置之间切换。

实现方法

实现交接有两种方式:带中间件的单智能体(一个具有动态配置的智能体)或**多智能体子图**(作为图节点的不同智能体)。

带中间件的单智能体

单个智能体根据状态改变其行为。中间件拦截每次模型调用,并动态调整系统提示和可用工具。工具更新状态变量以触发过渡:

多智能体子图

多个不同的智能体作为图中的独立节点存在。交接工具使用 Command.PARENT 在智能体节点之间导航,以指定接下来执行哪个节点。
子图交接需要仔细进行 上下文工程。与单智能体中间件(消息历史自然流动)不同,您必须显式决定在智能体之间传递哪些消息。如果处理不当,智能体会接收到格式错误的对话历史或臃肿的上下文。请参阅下面的上下文工程。
此示例展示了一个具有独立销售和支持智能体的多智能体系统。每个智能体是一个独立的图节点,交接工具允许智能体相互转移对话。
对于大多数交接用例,请使用带中间件的单智能体——它更简单。仅当您需要定制的智能体实现(例如,一个本身是包含反思或检索步骤的复杂图的节点)时,才使用多智能体子图。

上下文工程

使用子图交接时,您可以精确控制在智能体之间流动的消息。这种精确性对于维护有效的对话历史和避免可能混淆下游智能体的上下文臃肿至关重要。有关此主题的更多信息,请参阅上下文工程。 交接过程中的上下文处理 在智能体之间进行交接时,您需要确保对话历史保持有效。大语言模型期望工具调用与其配对响应,因此当使用 Command.PARENT 交接给另一个智能体时,您必须同时包含两者:
  1. 包含工具调用的 AIMessage(触发交接的消息)
  2. 确认交接的 ToolMessage(对该工具调用的人工响应)
没有这种配对接收智能体将看到不完整的对话,并可能产生错误或意外行为。 下面的示例假设只调用了交接工具(没有并行工具调用):
为什么不传递所有子智能体消息? 虽然您可以在交接中包含完整的子智能体对话,但这通常会产生问题。接收智能体可能会被不相关的内部推理搞糊涂,并且令牌成本会不必要地增加。通过只传递交接配对,您可以保持父图的上下文专注于高级协调。如果接收智能体需要额外的上下文,请考虑在 ToolMessage 内容中总结子智能体的工作,而不是传递原始消息历史。
将控制权返回给用户 当将控制权返回给用户(结束智能体回合)时,请确保最后一条消息是 AIMessage。这可以维护有效的对话历史,并向用户界面发出智能体已完成工作的信号。

实现注意事项

在设计多智能体系统时,请考虑:
  • 上下文过滤策略:每个智能体会收到完整的对话历史、过滤的部分还是摘要?不同的智能体根据其角色可能需要不同的上下文。
  • 工具语义:明确交接工具是只更新路由状态还是同时执行副作用。例如,transfer_to_sales() 是否还应创建支持工单,还是这应是一个单独的操作?
  • 令牌效率:平衡上下文完整性与令牌成本。随着对话变长,摘要和选择性上下文传递变得更加重要。