深入学LangChain官方文档-Router与Handoffs多智能体如何路由和交接控制权本篇对应的官方文档Multi-agent说明多智能体的上下文管理与模式边界。Router定义一次性分类、单跳Command与并行Send。Handoffs说明状态驱动的跨轮控制权交接、ToolMessage配对和两种实现方式。本篇讲解范围本篇区分一次请求的分发和连续对话中的控制权转移说明状态与消息怎样保持完整主 Agent 如何委派子任务、按需加载 Skill 或构建自定义工作流留给下一篇。第 17 篇让系统能从企业资料中取回证据但用户的问题不一定都该由同一个 Agent 处理。制度问答、退款办理和人工审批需要的工具、提示词与权限都不同。把全部能力堆进一个 Agent模型会在过长的上下文和过多工具之间犹豫过早拆成一群 Agent又会制造无意义的跳转。先判断一件事这次是一次性把问题分给专家还是要让专家在后续对话中持续接手多智能体最常见的价值是控制上下文每个专业 Agent 只看完成当前职责需要的知识和工具。它也可以让不同团队独立维护能力或并行处理多个资料源。但如果一个 Agent 加上动态工具和明确提示词已经稳定继续拆分只会增加状态同步和排错成本。Router把一次请求送到合适的处理者Router 先分类输入再把它送给一个或多个专业 Agent最后把结果合成。它适合“问题类型清楚、这次请求可以独立结束”的场景例如用户同时询问知识库政策和订单状态系统可以并行查询两个领域后汇总。Router 本身通常不承担多轮编排。无状态 Router 把每次请求都重新分类需要保留对话历史时可以让分类器读取状态但它仍然是一个前置分发步骤。不要把“Router 会调用多个 Agent”误解为“它天然适合持续客服对话”。单跳和并行扇出分别对应不同问题当一次请求只属于一个领域Command(gotoactive_agent)表达单跳路由最直接当同一个问题需要多个独立证据源Send可以并行扇出再由汇总节点合并结果。并行不意味着一定更快它仍受外部服务延迟、限流和结果合成质量影响。下面两段分别把“只去一个专家”和“同时请求多个专家”的下一跳写成返回值它们不负责生成答案。fromlanggraph.typesimportCommand,Senddefroute_one(state)-Command:active_agentclassify_query(state[query])returnCommand(gotoactive_agent)defroute_many(state):classificationsclassify_many(state[query])return[Send(item[agent],{query:item[query]})foriteminclassifications]这段代码的结果不是最终回答而是下一步的执行位置。active_agent必须来自可审计的分类逻辑若分类错误后续专家再擅长也只会在错误的领域里工作。对高风险路由可把规则、置信度阈值或人工确认放在路由前而不是把“猜对类别”交给结果阶段补救。Handoff状态改变后后续对话也换人退款不是一次问答就能结束用户先问规则随后提供订单号、补充原因、确认金额最后可能进入人工审批。这种跨轮次、按阶段解锁能力的流程需要 Handoff。它的核心是一个持久状态字段例如active_agent或current_step。工具更新字段后下一轮模型调用读取新状态换用对应的提示词、工具或独立 Agent。Handoff 的“交接”既可以发生在多个 Agent 之间也可以发生在一个 Agent 的不同配置之间。重点不在对象数量而在用户是否需要持续和当前处理者直接对话、状态是否必须跨轮保存、能力是否只能在前置条件满足后才开放。改状态时消息链也必须完整工具调用不是只改一个字段。模型发出transfer_to_refund后消息历史还期待一个与tool_call_id对应的ToolMessage。若只写active_agentrefund而没有工具结果下一轮的消息序列会缺少请求—响应配对模型或运行时无法可靠解释刚才发生了什么。这个工具同时写回消息和状态前者收完整个 tool call后者才把后续对话切到退款处理阶段。fromlangchain.messagesimportToolMessagefromlangchain.toolsimporttoolfromlanggraph.typesimportCommandtooldeftransfer_to_refund(runtime)-Command:returnCommand(update{messages:[ToolMessage(content已转交退款专员。,tool_call_idruntime.tool_call_id,)],active_agent:refund,})这里ToolMessage的职责是完成本次工具调用active_agent的职责是决定后续行为两者不能互相替代。若退款专家还需要订单号就应在新状态里直接向用户追问不要让总控 Agent 假装仍在处理再把每一句话隐式转发给专家。两种实现按能力差异选第一种做法是一个 Agent 加 Middleware每次模型调用前Middleware 根据active_agent动态更换系统提示词和可用工具。它适合角色差异主要是流程阶段和工具集合不同的情况部署和共享状态都较简单。第二种做法是多个 Agent 子图。每个专家是独立节点拥有自己的工具、提示词和可测试边界状态机负责下一跳。它适合领域上下文、权限模型或维护团队确实不同的场景。无论选哪种messages、用户身份和审批状态都需要明确哪些共享、哪些隔离。不要把四种模式混成一个概念Router 解决“这次请求去哪里”Handoff 解决“后续对话现在由谁继续”。Subagent 是主 Agent 在持续任务中按需委派Custom Workflow 则把确定性步骤和 Agent 行为显式编排。它们可以组合但每个模式应先回答自己的控制权问题。工程上可按一个简单顺序决策输入类别明确、一次回答即可完成时用 Router需要用户跨轮与不同阶段直接交互时用 Handoff主 Agent 要反复分解和汇总复杂工作时才进入 Subagent需要可预测的流程节点、重试和分支时再下探 Custom Workflow。任何模式都不能越过权限、审批和业务系统的权威边界。结论分发与交接的区别在“下一轮”Router 把本次请求分类、分发并合成结果Handoff 通过持久化状态把后续消息也交给新的处理者。前者追求清晰和轻量后者解决连续对话中的控制权、能力解锁和消息完整性。做到这一步多智能体就不再只是“多个提示词”而是有明确状态与责任边界的协作系统。下一篇会继续讨论总控 Agent 需要委派长任务、按需装载知识或组合自定义流程时怎样避免主上下文再次膨胀。