16. 如何设计多 Agent 的协作与动态切换机制面试官多 Agent 系统里各个 Agent 之间怎么协作‍♂️我一个 Agent 做完之后把结果传给下一个 Agent就像流水线一样一步步往下走。面试官你说的是流水线但「传结果」具体怎么传消息传递和共享状态是两种不同的方案适用场景也不一样你区分得开吗‍♂️我消息传递就是 Agent 之间直接发消息共享状态就是大家都能读写同一个变量……应该都差不多吧面试官差很远。消息传递的核心优势是解耦发送方不需要知道谁在接收共享状态的优势是直接前一步写进去后一步直接读。这两种选哪个取决于 Agent 之间的依赖关系强不强。那动态切换呢你是怎么做的‍♂️我动态切换就是让 LLM 判断下一步该调用哪个 Agent每次根据当前情况动态决策这样最灵活。面试官全靠 LLM 动态决策的问题是什么每次路由都要多一次 LLM 调用而且 LLM 偶尔会路由错系统行为的可预测性就没了。你有没有想过静态路由和动态路由应该怎么配合用被问到这里才意识到协作和切换都是有设计取舍的不是「传结果」和「LLM 决策」几个字就能概括的。-简要回答协作靠两件事消息传递和共享状态。消息传递是 Agent 完成自己的工作后把结果发出去下一个 Agent 取用共享状态是所有 Agent 共同读写一个状态对象记录任务进展和中间结果。动态切换靠 Orchestrator 来做有两种方式一种是静态路由提前写好规则「任务类型 A 就找 Agent X」另一种是让 LLM 动态决策根据当前情况实时判断该把任务交给谁。我的实践是两种混用主流程用静态路由保证稳定边缘情况才交给 LLM 动态判断。-详细解析多 Agent 系统里分工解决了「谁来做什么」的问题但还有另一个问题没解决各个 Agent 做完自己的事之后怎么把结果传给下一个 Agent下一步该叫哪个 Agent 来接棒这就是协作机制和切换机制要解决的事。在展开细节之前先从全局视角理解一下多 Agent 协作的几种主要模式。工程实践中常见的协作模式大致分为三类第一类是流水线模式Agent 之间按固定顺序依次执行前一个完成后交给下一个像工厂的装配线第二类是层级模式有一个 Orchestrator指挥者负责分配任务、收集结果其他 Agent 各自执行分配到的子任务第三类是协商模式多个 Agent 之间没有严格的上下级关系通过互相沟通、辩论来达成一致。这三种模式不是互斥的一个复杂系统里经常会混合使用。理解了这个大分类之后再来看具体的通信方式和路由策略就很清晰了。先说协作-agent-之间怎么传递信息你可以把多 Agent 系统想象成一个公司里的多个部门研究部、开发部、测试部各司其职。部门之间传递信息有两种方式。第一种方式像发邮件。研究部完成了资料整理就把报告「发」出去开发部收到邮件后再开始工作。这就是「消息传递」的思路Agent 完成自己的工作后把结果发送到一个消息队列下游的 Agent 订阅自己感兴趣的消息取到了再开始处理。这种方式最大的优点是解耦研究 Agent 不需要知道谁在等它的结果只管发接收方也不需要知道消息是谁发的只管处理。缺点是需要一个「邮件服务器」也就是消息中间件来维护这套机制部署成本稍高一些。第二种方式像共享白板。公司里所有部门都盯着同一块白板上面写着「当前任务是什么、进展到哪一步了、各部门完成了什么」。研究部写上「资料整理完成」开发部一看知道可以开始了于是接手并写上「代码开发中」。这就是「共享状态」的思路所有 Agent 都读写同一个状态对象。LangGraph 就是用这个思路来设计的它有一个贯穿所有 Agent 的 State每个 Agent 执行完就往 State 里写入自己的结果下一个 Agent 直接从 State 里读取前面的产出。这两种方式怎么选如果各 Agent 之间的依赖关系比较强前一步的结果要直接传给后一步用共享状态更直接。如果你希望 Agent 之间尽量解耦互相不知道对方的存在用消息传递更合适。状态管理多 Agent 共享状态的设计要点既然提到了共享状态这里有必要展开聊一下状态管理的设计因为这是多 Agent 系统里最容易出 bug 的地方之一。为什么状态管理这么重要你想多个 Agent 都在读写同一个状态对象如果设计不好很容易出现一个 Agent 写入的结果被另一个 Agent 意外覆盖或者读到了一半更新的脏数据。这就像公司那块共享白板如果没有任何规则两个人同时往白板上写东西写完之后谁也看不懂。工程上设计共享状态时有几个关键点需要考虑。首先是状态结构要分层通常会把状态分成「全局状态」和「局部状态」两层。全局状态存放所有 Agent 都需要读取的信息比如用户的原始请求、当前任务进展、最终输出这些是共享的。局部状态存放每个 Agent 自己的中间结果比如搜索 Agent 找到的候选文档列表、代码 Agent 生成的草稿代码这些在 Agent 内部使用不会直接暴露给其他 Agent避免信息污染。其次是写入规则要明确。最简单也最可靠的做法是「只追加不覆盖」每个 Agent 完成工作后把结果追加到状态里而不是修改已有的字段。LangGraph 的 State 更新机制就是这个思路你定义好 State 的 schema每个节点返回的是一个「增量更新」框架帮你合并到全局状态里这样就不会出现互相覆盖的问题。最后是错误状态的处理。如果某个 Agent 执行失败了它的错误信息也应该写入状态而不是悄悄吞掉。后续的 Agent 或者 Orchestrator 读到这个错误状态后才能做出正确的决策比如跳过这一步、换一个 Agent 重试、或者直接终止任务。再说切换Orchestrator 怎么决定叫谁「切换」就是决定下一步把任务交给哪个 Agent这个决策动作在系统里叫做「路由」。Orchestrator 就是那个负责做路由决策的角色。路由有两种策略。静态路由就是提前把规则写死。比如任务描述里包含「搜索」就找 Researcher Agent当前步骤已经是「代码写完了」就找 Reviewer Agent找不到匹配规则就回到 Orchestrator 兜底。这就像工厂流水线每道工序完成后下一步去哪个工位是固定的效率高、可预测、好调试。但它覆盖不了你没预料到的情况如果任务走了一条你没定义规则的路径系统就不知道该怎么办了。动态路由则是把「下一步找谁」的决策权交给 LLM 来做。Orchestrator 把当前任务描述、已经完成了什么、还有哪些 Agent 可以调用全部告诉 LLM让它判断「现在应该叫哪个 Agent 来做下一步」。这种方式的优点是灵活能处理任何你没预先设计的路径任务走到一个边缘情况时LLM 也能做出合理判断。缺点是每次路由都要多一次 LLM 调用增加了延迟和成本而且 LLM 偶尔也会路由错系统行为的可预测性就降低了。两种路由策略的对比可以用一张图来理解动态路由在代码层面是怎么实现的其实核心就是让 LLM 做一次分类决策把可用的 Agent 列表和当前上下文传给它让它返回应该调用哪个 Agent。下面是一个简化的示例def dynamic_route(task_context: str, available_agents: list[str]) - str: 让 LLM 根据当前上下文决定下一步调用哪个 Agent prompt f当前任务状态 {task_context} 可用的 Agent {chr(10).join(f- {agent} for agent in available_agents)} 请根据当前进展判断下一步应该交给哪个 Agent 来执行。 只返回 Agent 名称不需要解释。 response client.chat.completions.create( modelgpt-4, messages[{role: user, content: prompt}] ) selected response.choices[0].message.content.strip() return selected # 返回选中的 Agent 名称实际项目里通常还会加一些保护措施比如校验返回的 Agent 名称是否在可用列表中、设置默认的 fallback Agent、记录路由决策的日志以便后续分析等。handoff-模式-agent-之间的「接力棒」除了由 Orchestrator 集中做路由决策还有一种更去中心化的切换方式叫 Handoff交接这个模式在 OpenAI 的 Swarm 框架里被用来演示和推广。需要注意的是Swarm 是一个教育性/实验性框架OpenAI 官方明确说它不是生产级工具但它对 Handoff 模式的展示非常直观很适合理解这个概念。Handoff 的思路是不需要一个中央的 Orchestrator 来决定「下一步找谁」而是让当前正在执行的 Agent 自己决定「我做完了接下来应该把任务交给谁」。你可以理解成接力赛跑每个运动员跑完自己那一棒之后直接把接力棒递给下一个人不需要裁判在旁边喊「下一个是谁」。这种模式的好处是每个 Agent 对自己的任务边界最清楚它知道自己做完了什么、还缺什么由它来决定下一步找谁往往比一个外部的 Orchestrator 判断得更准确。而且没有中央节点的瓶颈系统的扩展性更好。缺点也很明显没有全局视角。如果 Agent A 把任务交给了 Agent B但 Agent B 又觉得这不是自己的活儿再交给 Agent C甚至 Agent C 又交回给 Agent A就形成了死循环。所以用 Handoff 模式时必须设计好每个 Agent 的职责边界并且加上防循环的机制比如记录任务已经经过了哪些 Agent如果发现重复经过同一个 Agent 就强制终止。工程上怎么用实践中最稳健的做法是两种路由组合用主流程用静态路由把确定性的节点切换都写成规则保证绝大多数情况下系统行为稳定可预测只在遇到没有匹配规则的边缘情况时才交给 LLM 动态决策。这样静态路由负责「保底」动态路由负责「兜住异常」两者互补。至于 Handoff 模式它适合那种每个 Agent 职责边界非常清晰、任务流向相对确定的场景。如果你的系统里 Agent 数量不多、每个 Agent 的输入输出接口定义得很明确用 Handoff 比用中央 Orchestrator 更简洁。但如果 Agent 数量多、任务流向复杂还是建议用 Orchestrator 来统一调度避免 Agent 之间的交接变成一团乱麻。通信方式的选择同理如果你的多 Agent 流程是一条相对清晰的流水线各步骤之间有明确的前后依赖就用共享状态简单直接如果你的系统需要让多个 Agent 独立并行、互相不感知对方的存在就用消息传递解耦清晰。-面试总结回顾开头踩的雷把协作说成「流水线传结果」把切换说成「全靠 LLM 动态决策」都是停留在表面没有说到设计取舍。答好这道题有几个层次。首先协作机制要说出两种通信方式的本质区别消息传递的核心是解耦发送方不需要知道接收方是谁适合 Agent 之间需要独立运行的场景共享状态的核心是直接所有 Agent 读写同一个对象LangGraph 就是这个思路适合各步骤依赖关系明确的流水线型任务。这两种选哪个取决于 Agent 之间的依赖有多强。其次动态切换要说出静态路由和动态路由各自的优缺点静态路由稳定可预测但覆盖不了没预料到的边缘情况动态路由灵活但每次多一次 LLM 调用且行为不可预测。最容易被忽略的点也是最能体现工程经验的答法就是说出「主流程静态路由保底边缘情况才交给 LLM 动态决策」的混合策略。这个答法面试官一听就知道你真的做过多 Agent 系统。