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()是否还应创建支持票证,或者这应该是单独的操作? - 令牌效率:在上下文完整性和令牌成本之间取得平衡。随着对话变长,摘要和选择性上下文传递变得更加重要。
通过 MCP 将这些文档连接到 Claude、VSCode
等,以获取实时答案。

