多 Agent 我最怕的是把工作流节点当成 Agent:拆完没有状态归属、没有终止条件,系统一跑就互相甩锅。
Q1: 什么是 Multi-Agent?和单 Agent 有什么区别?
2023年: 单 Agent 的能力边界
致命痛点: 上下文窗口溢出和角色混乱
Multi-Agent 的引入: 专业化分工
核心机制: 任务分解 + 通信协调 + 错误处理
关键权衡: 并行加速 vs 通信开销
没有 Multi-Agent
引入 Multi-Agent
Q2: Multi-Agent 的常见协作模式有哪些?
Multi-Agent 的本质是任务分解 + 通信协调,核心模式有 5 种:编排模式的选择决策树
选择协作模式的决策树:Multi-Agent 架构的五大模式详解
Q3: Multi-Agent 之间怎么通信?
基础梳理
专家视角深度剖析
通信协议的选择标准
Agent 间通信的 Token 开销
Agent 之间传递信息需要消耗 tokens。如果 Agent A 的输出有 1000 tokens,传给 Agent B 作为输入,这 1000 tokens 就是额外的成本。Multi-Agent 系统的 token 消耗通常是单 Agent 的 N 倍。Q4: Multi-Agent 的核心挑战是什么?
Q5: Hierarchical 和 Collaborative 模式是什么?
Supervisor 的局限性
Hierarchical: 分层管理
Collaborative: 对等协作
模式选择的关键权衡
模式混合使用的实际案例
实际项目中,单一模式很少能满足需求,通常需要混合使用:Q6: Multi-Agent 的错误处理和容错机制有哪些?
单 Agent 失败的影响
三种容错策略
重试和降级机制
Human-in-the-Loop
重试机制的退避策略
重试不是简单地”再来一次”,需要合理的退避策略防止雪崩:幂等性设计
在 Multi-Agent 系统中,重试可能导致同一个操作被执行多次。幂等性设计确保”执行一次和执行多次的结果相同”。Q7: 长时间运行智能体(Long-running Agent)怎么设计?
长时间运行的困境
异步执行(Asynchronous Execution)
interrupt() 实现暂停,用 Command(resume=...) 实现恢复。状态快照与恢复(Checkpointing & Recovery)
长期记忆(Long-term Memory)
进度追踪与断点续传
没有长时间运行设计
引入长时间运行设计
异步执行的实现模式
进度追踪与断点续传
Q8: 企业级 Agent(Enterprise-grade Agent)怎么设计?
玩具级 vs 企业级的差距
权限收敛(最小权限原则)
审计日志(Audit Logging)
容错降级(Fallback)与确定性边界
确定性边界的分层架构
Q9: LangGraph 的编排模式有哪些?
LangGraph 提供了四种核心编排模式,适用于不同的 Multi-Agent 场景:Supervisor 模式详解
Supervisor 模式是最常用的编排模式。一个 Supervisor Agent 根据当前状态决定下一步调用哪个 Worker Agent。Worker 完成后返回 Supervisor,Supervisor 决定是继续调用其他 Worker 还是结束。Hierarchical 模式详解
Hierarchical 模式把 Supervisor 拆成多层。顶层 Supervisor 做宏观决策(分配到哪个领域),中层 Supervisor 做具体分配(分配给哪个 Agent),底层 Agent 执行具体任务。每层的 prompt 简短精准,避免单层 Supervisor 的 prompt 过长问题。Network 模式详解
Network 模式没有固定的主管,所有 Agent 地位平等,可以直接互相调用。适合需要多轮协商的场景(如技术方案评审、辩论式决策)。缺点是控制流不明确,容易出现死循环。自定义拓扑
对于复杂业务流程,可以组合多种模式,构建自定义拓扑。例如:顶层用 Supervisor 做路由,中层用 Collaborative 做多视角分析,底层用 Pipeline 做串行处理。编排模式的选择标准
Q10: Supervisor、Orchestrator-Workers、Handoff、GroupChat、Evaluator-Optimizer 到底差在哪?
背定义没有意义。这五种模式的真正差别只有三个问题:谁决定下一步、状态放在哪、失败怎么传播。 答不出这三点,就等于只会背名词。
一张表看穿五种模式
状态归属决定”能不能恢复”
这是最容易被忽略、但工程上最关键的一点:- 共享图状态(Supervisor):状态集中,checkpoint 好做,但所有 Worker 争用同一份状态,必须用 reducer 定义合并规则。
- 会话移交(Handoff):状态跟着对话走,实现简单,但没有全局视图,超时和预算难以统一收口。
- 消息记录(GroupChat):状态就是聊天记录,可回放,但 token 随轮次增长很快。
- 草稿 + 反馈(Evaluator-Optimizer):状态最小,适合可自动判分的任务,不适合开放式任务。
每个模式都要能回答”机制 / 替代 / 代价 / 失败 / 验证”
Q11: 动态拆解 vs 固定工作流路由,什么时候该让模型决定?
这是多 Agent 设计里最常被问、也最容易答错的判断题。机制差异
判断标准:能否”预先枚举”
Q12: 多 Agent 为什么会放大错误?三层防线怎么建?
错误会被结构放大
三层防线
Q13: 底层源码——LangGraph 的 Multi-Agent 实现
Q14: 及格回答 vs 满分回答
问题:“说说 Multi-Agent 的架构模式”
及格回答(60-70分):“有 Pipeline、Fan-out/Fan-in、Supervisor、Debate 等模式。Pipeline 是串行,Fan-out 是并行,Supervisor 有主管调度。”问题出在:知道模式但不理解挑战。 满分回答(90-100分):
“Multi-Agent 的核心问题是任务分解、通信协调、错误处理。任务分解:Pipeline 适合有依赖关系的任务(A 的输出是 B 的输入),Fan-out 适合独立任务(并行执行后汇总),Supervisor 适合动态任务(主管根据中间结果决定下一步)。[1]”
“通信协调有四种方式:共享 State(LangGraph 的方式,所有节点读写同一个状态对象,通过 Annotation + Reducer 定义合并规则)、消息传递(Agent 之间直接发消息)、黑板模式(所有 Agent 读写同一个’黑板’)、事件总线(发布/订阅模式)。LangGraph 的 Reducer 是关键——它解决了并行节点的状态冲突问题。[2]”
“错误处理有三种策略:容错继续(A 失败不影响 B 和 C,用Promise.allSettled)、快速失败(A 失败立即终止,用Promise.all)、条件传播(A 失败则 B 不执行)。选择取决于业务场景——实时系统选容错优先,批处理选完整性优先。成本控制是另一个核心挑战:用弱模型处理简单任务、限制 token 预算、缓存重复查询。[3]“
常见追问
Multi-Agent 的成本怎么控制?
Multi-Agent 的成本怎么控制?
- 弱模型分级:80% 的简单任务用 gpt-4o-mini(便宜 10 倍),20% 的决策用 gpt-4o。在 LangGraph 中,不同节点可以用不同的模型。
- token 预算:限制每个 Agent 的单次调用 token 数(maxTokens),限制整个工作流的总 token 消耗(budget.total)。超出预算时降级到更简单的处理方式。
- Prompt Cache:Anthropic 的 Prompt Cache 可以节省 90% 的输入 token 费用。优化方法:把稳定的 System Prompt 放在前面,变化的用户输入放在后面。相同前缀的请求直接复用缓存的 KV Cache。”
怎么防止 Agent 之间的死循环?
怎么防止 Agent 之间的死循环?
- 最大循环次数:设置 Supervisor 的最大轮转次数(如
maxIterations: 10)。超过次数强制终止,返回当前最佳结果。 - 状态变化检测:如果连续两轮的状态没有变化(Agent 的输出和上一轮相同),说明陷入了死循环,强制终止。
- Supervisor 决策:Supervisor 的 prompt 中明确写’如果 Agent A 和 Agent B 互相推诿,直接交给人工处理’。LLM 会理解这个指令,避免无限循环。”
怎么调试 Multi-Agent 系统?
怎么调试 Multi-Agent 系统?
- 日志聚合:每个 Agent 的输入输出记录到同一个日志流,用
run_id关联同一轮执行的所有 Agent 调用。LangSmith 自动做这件事。 - 可视化执行流:LangGraph Studio 可以看到图的执行过程——哪个节点执行了、状态怎么变化的、走了哪条边。这是最直观的调试方式。
- 断点调试:在某个节点加
interrupt,暂停执行等待人类检查。发现问题可以修改 State 后重试。 - 成本追踪:记录每个 Agent 的 token 消耗和执行时间,找出性能瓶颈。LangSmith 的 Dashboard 可以看到每个节点的耗时和 token 消耗。”
Hierarchical 和 Collaborative 模式该怎么选?
Hierarchical 和 Collaborative 模式该怎么选?
- Hierarchical(层级模式):适合有明确组织结构的大型任务。例如企业级代码审查——顶层 Supervisor 分配到’前端团队’和’后端团队’,中层 Supervisor 分配到具体的审查 Agent。优点是职责清晰、易于扩展;缺点是层级越深,通信开销越大。
- Collaborative(协作模式):适合需要多视角输入的场景。例如技术方案评审——多个 Agent(安全专家、性能专家、可维护性专家)各自给出意见,最后汇总达成共识。优点是没有单点故障、多视角覆盖;缺点是需要共识机制(投票、加权平均)。
Multi-Agent 的错误处理怎么设计?
Multi-Agent 的错误处理怎么设计?
-
容错继续(Fire and Forget):用
Promise.allSettled实现。Agent A 失败了,B 和 C 继续执行,最后由 Supervisor 汇总成功和失败的结果。适合实时系统——不能因为一个 Agent 失败就阻塞整个流程。 -
快速失败(Fail Fast):用
Promise.all实现。任何一个 Agent 失败,立即终止整个流程。适合批处理——数据完整性比速度更重要。 -
条件传播(Conditional Propagation):在 LangGraph 中用
addConditionalEdges实现。Agent A 失败时,根据错误状态决定下一步——重试、降级、或跳过后续节点。
interrupt 节点暂停执行,等待人类审批。重试时区分临时性错误(网络超时,可重试)和永久性错误(参数错误,不可重试)。”Multi-Agent 和单 Agent + 工具链的区别?
Multi-Agent 和单 Agent + 工具链的区别?
- 并行加速:Fan-out 模式可以把一个大任务拆成 N 个子任务并行执行,时间从 O(N) 降到 O(1)。
- 专业化分工:每个 Agent 专注一个领域,prompt 简短精准,输出质量更高。
- 容错隔离:一个 Agent 失败不影响其他 Agent,系统整体更健壮。
- 通信开销:Agent 之间传递信息需要 tokens,成本是单 Agent 的 N 倍。
- 状态同步复杂度:需要 Reducer 处理并行节点的状态冲突。
- 调试难度:多 Agent 系统的行为难以预测和复现。
Multi-Agent 的幂等性怎么设计?
Multi-Agent 的幂等性怎么设计?
-
请求去重:用唯一 ID 标识每次调用。
callId = agentId + hash(input),已处理的 callId 直接返回缓存结果。LangGraph 的 Checkpoint 天然支持——从 checkpoint 恢复时不会重复执行已完成的节点。 - 结果缓存:相同输入的结果缓存起来,后续调用直接返回缓存。适合确定性任务(如代码格式化、文档生成)。不适合非确定性任务(如创意写作)。
- 状态机:用状态机管理任务的状态流转(pending → running → completed → failed)。重试时检查当前状态,避免重复执行已完成的步骤。
长时间运行的 Agent 怎么保证不丢状态?
长时间运行的 Agent 怎么保证不丢状态?
- Checkpoint(状态快照):LangGraph 每个节点执行完后自动保存状态快照到 PostgreSQL。中断后从最近的 checkpoint 恢复,不需要从头开始。这是最基本的状态保证。
- Session 分段 + 交接笔记:把长任务拆成多个 session,每个 session 结束时保存交接笔记(Brief),包含已完成的任务、关键决策、当前约束。下一个 session 开始时自动加载 Brief,实现无缝接续。
- 长期记忆(Long-term Memory):用 4 层记忆模型(working → episodic → semantic → procedural)管理记忆。定期用小模型压缩历史对话,100K tokens 压缩为 5K tokens。频繁访问的记忆强化,陈旧记忆自动淘汰(遗忘曲线)。”
企业级 Agent 的权限怎么设计?
企业级 Agent 的权限怎么设计?
Agent 的 LLM 输出不可控怎么办?
Agent 的 LLM 输出不可控怎么办?
- 理解层(LLM,不确定性):LLM 只负责理解用户意图、提取结构化信息。这是不确定性的来源,但影响范围被限制在理解层。
- 验证层(Schema,半确定性):LLM 的输出经过 JSON Schema 校验。如果输出不符合预期格式,触发降级策略(重试或用规则引擎)。
- 执行层(规则引擎,确定性):具体的工具调用、数据操作、业务逻辑由规则引擎执行,不依赖 LLM 的输出。
LangGraph 的四种编排模式怎么选?
LangGraph 的四种编排模式怎么选?
- Supervisor 模式:一个主管路由 + N 个 Worker 执行。控制流清晰,死循环风险低。90% 的场景用这个就够了。
- Hierarchical 模式:多层 Supervisor 逐级分配。适合大型复杂任务(有明确的组织结构),但层级越深,通信开销越大。
- Network 模式:所有 Agent 地位平等,直接互相调用。适合需要多轮协商的场景(如技术方案评审),但死循环风险高,必须加最大轮次限制。
- 自定义拓扑:组合多种模式,构建任意图结构。适合复杂业务流程(顶层 Supervisor + 中层 Collaborative + 底层 Pipeline)。
Multi-Agent 在生产环境的可观测性怎么设计?
Multi-Agent 在生产环境的可观测性怎么设计?
-
日志聚合:每个 Agent 的输入输出记录到同一个日志流,用
run_id关联同一轮执行的所有 Agent 调用。LangSmith 自动做这件事——可以看到每个节点的输入、输出、耗时、token 消耗。 - 分布式追踪:用 OpenTelemetry 做分布式追踪,记录每个 Agent 调用的 span(开始时间、结束时间、状态)。在 Jaeger 或 Zipkin 中可以看到完整的调用链路和瓶颈。
- 关键指标:监控三个核心指标——成功率(Agent 调用的成功/失败比例)、延迟分布(P50/P95/P99 延迟)、token 消耗(每个 Agent 的 token 成本)。设置告警阈值,成功率低于 95% 或 P99 延迟超过 30 秒时触发告警。
- 成本追踪:记录每个 Agent 的 token 消耗和执行时间,找出成本最高的 Agent。LangSmith 的 Dashboard 可以看到每个节点的耗时和 token 消耗,方便优化。“
Q15: 八道深度追问:及格 vs 满分
以下八题覆盖”机制差异、状态归属、失败模式、动态 vs 固定、错误放大”,每题给出及格与满分对照。面试时按”结论 → 机制 → 代价 → 验证”的顺序讲。
追问 1:五种编排模式的状态分别放在哪?
及格回答: 都放在共享的 State 里,节点读写同一个状态对象。 满分回答: 不同模式的状态归属不同,直接决定能不能做断点恢复。Supervisor 是共享图状态,集中但需要 reducer 合并;Handoff 是会话移交,状态跟着对话走,简单但没有全局视图;GroupChat 状态就是消息记录,可回放但 token 增长快;Evaluator-Optimizer 状态只有草稿和反馈,最小但只适合可判分任务。选型时我会先问”这个状态需不需要跨 Agent 共享、需不需要恢复”,再决定模式。追问 2:什么时候必须用动态拆解,什么时候固定路由更好?
及格回答: 任务复杂就用动态拆解,简单就用固定路由。 满分回答: 判断标准是”分支能否预先枚举”。分支可穷举、步骤稳定,就用固定工作流,因为可测试、可观测、可回滚;只有任务规模随输入剧烈变化、无法预先拆好时,才交给模型动态拆解。生产里我优先选”固定骨架 + 动态内核”:外层确定性工作流保证收口,只在拆几个子任务这种不确定点上用模型。动态拆解的真实代价是把不确定性搬到编排层,必须配套 trace、预算和回归评测。追问 3:Supervisor 路由震荡怎么治?
及格回答: 加最大轮次限制,超过就停。 满分回答: 先定位震荡原因:通常是 Router 的 prompt 缺少”当前已完成什么”的摘要,导致它反复改判。治法分三层:一是在 Router 输入里加入已完成任务和剩余目标的结构化摘要,减少信息缺失;二是给每个任务记 owner,禁止把同一任务交回上一个 Agent;三是设最大轮次和重复决策检测,连续两轮路由相同就强制收敛或升级人工。单纯加轮次上限只是兜底,不解决根因。追问 4:Handoff 模式怎么避免”击鼓传花、无人负责”?
及格回答: 让最后一个 Agent 负责汇总。 满分回答: Handoff 的根本风险是责任随控制权一起被移交出去。工程上要做三件事:第一,任务始终有唯一 owner 字段,移交只是换执行者,不换责任人;第二,全局预算和超时挂在任务上而不是某个 Agent 上,避免每换一次手就重置;第三,设终止条件——谁收到”最终交付”指令谁负责收口,禁止无 owner 的悬空移交。没有这三条,Handoff 在复杂任务里几乎必然失控。追问 5:Orchestrator-Workers 的拆解粒度怎么定?
及格回答: 拆到每个子任务能独立完成为止。 满分回答: 粒度由”产物边界”决定,不由”步骤多少”决定。一个子任务应该对应一个明确产物和一组相关工具调用,经验上控制在 5 到 15 次工具调用;太小则调度和汇总开销超过执行成本,太大则单点失败重试代价高、上下文膨胀。还要设最大树深和最大叶子数,防止 Orchestrator 无限拆解。验证方式是固定任务集对比不同粒度下的成功率与总成本,而不是凭感觉。追问 6:GroupChat 怎么防无限闲聊和上下文爆炸?
及格回答: 限制最大轮数,到点就结束。 满分回答: GroupChat 要同时管住”发言”和”上下文”两件事。发言侧:用明确的发言选择策略(轮询或 LLM 选择),设最大轮次和”连续无新增信息”检测,检测到重复观点就终止。上下文侧:不是把全部历史塞给每个 Agent,而是维护一份共享摘要加各自私有上下文,避免 token 随轮次平方增长。另外要有裁决者,否则多人 Agent 容易形成共识偏差——大家共享同一份错误上下文还互相确认。追问 7:Evaluator-Optimizer 怎么保证收敛,评估器放水怎么办?
及格回答: 设个最大迭代次数就行。 满分回答: 收敛要靠”明确的验收标准 + 分数阈值 + 最大轮次”三者共同约束。评估标准必须是可逐条检查的,而不是”写得好不好”;每轮要输出差在哪里,让生成器有明确改进方向,否则会来回震荡。评估器放水是常见问题:同源模型容易给自己人打高分,所以评估器要么换模型、要么用规则校验兜底、要么定期用人工标注校准。上线前我会对比评估分和人工分的一致性,一致性低就说明评估器不可信。追问 8:多 Agent 的错误放大怎么量化、怎么防?
及格回答: 多加校验,出错就重试。 满分回答: 先量化:串行链路整体成功率约等于单步成功率的 N 次方,所以单步 95% 在 10 步后只剩六成左右;并行扇出则是任一失败概率随分支数上升。放大机制有三类:上下文污染、共识偏差、重试风暴。防线也分三层:契约层用 Schema 和验收标准挡住脏数据;隔离层用上下文隔离和独立评估器阻断横向扩散;收口层用预算、熔断、死信队列和升级人工兜住底线。关键认知是——多 Agent 的可靠性来自边界和出口,不来自 Agent 数量。延伸阅读与引用参考
- LangGraph Multi-Agent 文档:LangGraph 官方对 Multi-Agent 模式的详细说明。[1]
- LangGraph 源码:LangGraph 的完整源码,理解 Supervisor、Send、Reducer 的底层实现。[2]
- Anthropic: Building Effective Agents:Orchestrator-Workers、Evaluator-Optimizer 等模式的原始出处,并明确区分”工作流”与”Agent”。[3]
- LangGraph Persistence 文档:LangGraph 的 Checkpoint 机制详解,长时间运行 Agent 的状态保存基础。
- Andrew Ng: Agentic Design Patterns:Andrew Ng 对 Agentic Workflow 和多 Agent 协作模式的总结。
- OpenAI Agents SDK: Handoffs:Handoff 模式把控制权与上下文交给另一个 Agent 的官方实现与语义。
- AutoGen: Group Chat:GroupChat 的发言选择与共享消息模型。
- LangGraph Streaming & Human-in-the-Loop:异步执行、进度追踪、Human-in-the-Loop 的官方实现指南。
