多 Agent 系统如何保证路由准确和消息正确传递？

核心回答

我会分别控制**“选对执行者”和“正确交接、回收当前任务”**。路由准确靠能力边界、信息完整性和评测；消息正确靠可校验的任务契约与运行时状态管理。

• 先判断任务需要什么能力。 按数据来源、操作目标和必要输入匹配 Agent；模型可以做语义分类，程序再校验目标是否存在、能力和权限是否满足。缺少时间范围、对象或统计口径时先澄清；多个角色都可能接手时，补足信息或退回主 Agent 决定，不让它们反复转交。
• 把交接内容说清并绑定身份。 消息携带会话与任务 ID、接收者、输入版本、目标、必要上下文和依赖；返回结果也带任务 ID、状态、数据或产物及依据。只把属于当前任务、满足约定的结果交给汇总者。
• 由运行时处理失败。 设置截止时间和有限重试，识别重复与过期结果；有外部副作用的操作还要实现业务幂等。最后分别检查路由选得对不对，以及消息是否漏收、串任务或重复合并。

例如“统计内部药品销量并结合内部说明解释变化”，销量应交给数据库助手，说明交给知识库助手。仅因出现“药品”就派给网络搜索，即使消息送达也仍是路由错误。

展开说明

1. 先把“匹配”写成可以核对的标准

以研搜助手为参考场景，三个业务专家的边界是：网络助手查询互联网公开信息；数据库助手获取内部结构化业务数据；知识库助手检索内部非结构化文档。主 Agent 根据每个专家的 description 选择委派对象，专家的 system_prompt 再说明如何执行。

设计路由时，可以为每个角色登记支持的任务、所需输入、可用数据源、工具和不能处理的范围。先检查明确条件，再由模型处理自然语言的语义差异。例如“我们上个月卖了多少”包含内部数据和时间指代，不能按“销售”关键词直接送到网络助手。对象和时间可从可信会话状态补齐；仍不明确，就询问用户。

混合请求应拆成针对不同来源的子问题。已经明确的销量统计与内部说明检索可以分别派发；若第二步需要第一步得到的商品名单，就记录依赖，等名单确定后再执行。并行派发只是执行方式，不能解决输入缺失，也不能让不相关来源变得相关。

歧义回退也要有固定去处：允许专家返回“能力不匹配”或“缺少字段”，由主 Agent 澄清或重新规划，并限制重复转交次数。参考项目的主提示词含有“边界不明确则全部使用”的策略；若重点是减少误路由和无效调用，可以把这部分改成上述澄清与回退规则，并用样例比较效果。

2. 交接的是一项任务，不能只发一句“你处理一下”

可以约定一份任务信封，核心字段各有用途：

• run_id、task_id、parent_task_id：区分本次执行、子任务及所属父任务；会话 ID 用来关联持续对话，未必能唯一标识每次执行。
• recipient、goal、input、input_version：明确交给谁、完成什么、采用哪版输入。例如数据库子任务应收到商品范围、起止日期、销量定义，而不只是原始的一句用户问题。
• dependencies、deadline、attempt：说明等待哪些结果、何时超时、当前第几次尝试。只有前置结果满足约定，调度器才启动依赖任务。

这些标识和允许的接收者由程序生成或校验，不能只让模型自由填写。发给专家的上下文应包括原始目标、已确认条件、相关上游结果及来源；其他专家的无关对话不必一起传递。

结果约定则包括原任务标识、输入版本、执行状态、结构化结果、证据或产物引用，以及可识别的错误原因。比如数据库任务超时，应返回失败或超时状态；“没有查到数据”应是一次正常查询的结果，二者不能都压成空字符串。汇总者据此决定能否回答、是否补查或说明缺失项。

若用 LangChain 的工具消息传递结果，还要保持调用与响应的 tool_call_id 匹配。子图交接时，工具调用消息与相应响应要成对保留，否则可能形成无效消息历史。这个 ID 负责模型工具交互，与业务 task_id 分工不同。

3. 按任务归并结果，处理迟到、重复和未知状态

假设用户先查“上个月销量”，随后改为“今年累计销量”。旧请求即使晚到，也不能覆盖新请求。汇总时应核对执行 ID、任务 ID 和输入版本，把旧结果保留在原执行记录中；不同专家写入各自任务的结果位置，再由一个明确的汇总者生成最终答案，避免同时覆盖同一个答案字段。

超时后的处理取决于任务性质。只读查询可以在剩余预算内重试，但仍需去重，避免同一结果被合并两次；创建工单、写数据库等操作超时后，不能直接认定执行失败，因为远端可能已完成。应使用稳定的业务幂等键、查询操作状态或唯一约束，确认同一逻辑操作不会重复生效。重新执行节点或启用检查点本身，不等于外部操作恰好执行一次。

研搜参考代码已经使用会话标识关联 thread_id、输出目录和 WebSocket 推送，主 Agent 通过框架的 task 工具委派专家。这能说明实际的调用和事件流；独立执行 ID、完整任务信封、输入版本和业务幂等则是上面提出的进一步设计，不能仅由这些会话机制推断已经实现。

4. 用两组检查定位问题

路由评测需要标注预期角色或允许的角色集合，覆盖单一来源、混合来源、缺字段、相近措辞和无法处理的请求。除了整体选对比例，还要看各类任务的漏派、误派、无效调用及应澄清却直接执行的情况。模型自报的“置信度”可以作为信号，不能未经校准就当成可靠概率。

消息链路则检查发出、开始、完成、超时、取消和归并记录能否按 ID 串起来，并故意验证重复返回、乱序到达、迟到结果及部分失败。发生错误时，就能区分是目标选错、上下文缺失、工具执行失败，还是正确结果被错误归并，再决定修改路由规则、任务契约或运行时逻辑。

常见追问

接入消息队列就能保证正确传递吗？

队列可以帮助跨进程缓冲、投递和重试，但业务任务的身份、版本、幂等和结果归属仍要实现。单进程中可以直接调用子图或异步函数；需要独立部署、削峰或跨服务协作时，再选择队列或 RPC。传输方式不能替代任务契约。

Router 和主 Agent 调度有什么区别？

专用 Router 通常先做一次分类，选择一个或多个目标；主 Agent 则可以根据对话和返回结果持续决定下一步。两者都需要校验目标与输入，区别主要在决策发生的位置、是否持续编排，而不是名字里有没有 Agent。

上下文应该完整传递还是只传摘要？

传完成子任务所需的最小充分信息。关键约束、已确认口径和必要证据应保留，长材料可以给摘要与可读取的引用。若接收方无法读取引用，就需要传入相关内容；若采用工具调用历史，还要保留合法的消息配对，不能为了压缩 Token 删掉必要响应。

对应教程

参考资料