current_step 或 active_agent),系统读取此变量以调整行为——要么应用不同的配置(系统提示词、工具),要么路由到不同的智能体。此模式既支持不同智能体之间的交接,也支持单个智能体内部的动态配置变更。
核心特性
- 状态驱动行为:行为基于状态变量(例如
current_step或active_agent)变化 - 基于工具的转移:工具更新状态变量以在不同状态间移动
- 直接用户交互:每个状态的配置直接处理用户消息
- 持久化状态:状态在对话轮次间持续存在
适用场景
当您需要强制执行顺序约束(仅在满足前提条件后解锁功能)、智能体需要在不同状态下直接与用户对话,或者您正在构建多阶段对话流程时,请使用交接模式。此模式对于需要按特定顺序收集信息的客户支持场景尤其有价值——例如,在处理退款前先收集保修ID。基础实现
核心机制是一个返回Command 来更新状态的工具,从而触发向新步骤或智能体的转移:
为什么包含
ToolMessage? 当LLM调用工具时,它期望得到响应。带有匹配 tool_call_id 的 ToolMessage 完成了这个请求-响应循环——没有它,对话历史将变得格式错误。每当您的交接工具更新消息时,这都是必需的。教程:使用交接模式构建客户支持
学习如何使用交接模式构建客户支持智能体,其中单个智能体在不同配置之间转换。
实现方法
有两种实现交接的方式:带中间件的单智能体(一个具有动态配置的智能体)或**多智能体子图**(作为图节点的不同智能体)。带中间件的单智能体
单个智能体根据状态改变其行为。中间件拦截每个模型调用,并动态调整系统提示词和可用工具。工具更新状态变量以触发转移:完整示例:使用中间件的客户支持
完整示例:使用中间件的客户支持
多智能体子图
多个不同的智能体作为单独的节点存在于图中。交接工具使用Command.PARENT 指定接下来要执行的节点,从而在智能体节点之间导航。
完整示例:带交接的销售与支持
完整示例:带交接的销售与支持
此示例展示了一个包含独立销售和支持智能体的多智能体系统。每个智能体都是一个独立的图节点,交接工具允许智能体将会话转移给对方。
上下文工程
使用子图交接时,您可以精确控制哪些消息在智能体之间流动。这种精确性对于维护有效的对话历史和避免可能混淆下游智能体的上下文膨胀至关重要。有关此主题的更多信息,请参见上下文工程。 交接期间处理上下文 在智能体之间交接时,您需要确保对话历史保持有效。LLM期望工具调用与其响应配对,因此当使用Command.PARENT 将控制权移交给另一个智能体时,必须同时包含:
- 包含工具调用的
AIMessage(触发交接的消息) - 确认交接的
ToolMessage(对该工具调用的人工响应)
为什么不传递所有子智能体消息? 虽然您可以在交接中包含完整的子智能体对话,但这通常会产生问题。接收智能体可能会因不相关的内部推理而困惑,并且令牌成本会不必要地增加。通过仅传递交接配对,您可以将父图的上下文集中在高级协调上。如果接收智能体需要额外的上下文,请考虑在 ToolMessage 内容中总结子智能体的工作,而不是传递原始消息历史。
AIMessage。这可以维护有效的对话历史,并向用户界面发出智能体已完成其工作的信号。
实现注意事项
在设计多智能体系统时,请考虑:- 上下文过滤策略:每个智能体将接收完整的对话历史、过滤部分还是摘要?根据其角色,不同的智能体可能需要不同的上下文。
- 工具语义:明确交接工具是仅更新路由状态,还是也执行副作用。例如,
transfer_to_sales()是否也应该创建支持工单,或者这应该是一个单独的操作? - 令牌效率:平衡上下文完整性与令牌成本。随着对话变长,摘要和选择性上下文传递变得更加重要。
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

