“你负责的项目里为什么要把任务拆给多个 Agent 来做当时是怎么设计的”这是我在面试一家做 AI 应用的公司时被面试官追问的第一个问题。我当时把项目里的多 Agent 协作流程复述了一遍面试官点了点头又补了一句“如果换一种场景你会用哪种架构”那一刻我才意识到面试官真正想听的不是“我用了什么”而是“我为什么这么选”。多 Agent 系统的方案设计本质上是一次系统设计考察任务怎么拆、角色怎么分、消息怎么传、失败怎么处理、成本怎么控。如果你只背过一份架构图很容易在追问环节露馅。这篇文章我想从面试答题的角度把多 Agent 系统中出现频率最高的 4 种经典架构完整拆一遍每种架构的核心思路、适用场景、优缺点以及面试时怎么说才显得“有系统设计功底”。不管你是准备面试还是自己正在搭多 Agent 项目应该都能用得上。1. 面试官问多 Agent考的不是架构图是系统设计思维先聊一个很多人忽略的问题为什么面试官偏爱问多 Agent 系统因为多 Agent 系统不只是一个技术名词它天然覆盖了一道系统设计题的所有环节。面试官可以从一个 Agent 的内部设计问到多个 Agent 之间如何协作从任务拆分问到结果合并从串行执行问到并行调度甚至从 token 成本问到故障恢复。这不就是一个微服务架构的 LLM 版本吗所以这个问题非常能考察候选人的全局设计能力。我在准备过程中把面试官的考察点归纳成三个维度1.1 第一问你真的需要多 Agent 吗很多人一上来就说“用多 Agent 更智能”这是最大的扣分点。面试官心里多半在等你说一句“其实很多场景根本不需要多 Agent。” 单 Agent 就能解决的问题强行拆成多 Agent只会带来更高的延迟、更贵的 token、更多的失败点。什么场景才真正需要多 Agent任务本身有明确的子任务边界比如“先做需求分析再写代码再跑测试”每个阶段需要不同的工具和知识。子任务之间存在并行关系比如同时搜索三个方向的资料再汇总。单个 Agent 的能力边界不够比如一个 Agent 既要懂代码又要懂运维又要懂产品提示词会被撑爆。需要对过程做可观测、可干预的控制比如某些子任务需要人工审核。面试时把这个判断讲清楚你已经在起跑线上领先了。1.2 第二问多 Agent 之间的“关系”是什么多 Agent 系统的本质是划分子任务 定义协作关系。这个关系可以是一对多、多对多、父子、平级、串行、并行、动态协商……每种关系都对应一种架构。面试官考察的就是你能不能根据任务的依赖关系选择正确的协作拓扑。所以你需要掌握的不是“4 个架构名词”而是“4 种任务协作模式”。弄懂这一点后面讲什么架构都通了。1.3 第三问系统的稳定性、成本、可观测性如何保障多 Agent 系统最难的不是跑通 Demo而是让它稳定地跑在生产环境。Agent 的输出天然带有不确定性多个 Agent 之间的不确定性会被累积放大。面试官会追问Agent 之间怎么通信共享上下文还是消息传递任务失败怎么办重试还是降级谁来负责兜底多 Agent 的 token 成本怎么控制系统的一整条执行链路怎么追踪这些问题没有标准答案但你必须有一套完整的回答思路。带着这三个考察维度去准备会比死记硬背架构定义有效得多。2. 架构一Supervisor-Worker最稳妥的“领导拍板”模式第一个要讲的架构也是我实际项目里用得最多的架构叫Supervisor-Worker主管-工人模式。你可以直接把它理解为职场里的“一个 Leader 带一群执行者”。Supervisor 是唯一的决策中心负责理解用户请求、拆解任务、给 Worker 分派任务、收集结果、决定是否重试或结束。Worker 不自己做决策只负责执行被分配的子任务把结果交回给 Supervisor。2.1 这个架构的核心工作机制用伪代码表达一下核心逻辑# 伪代码展示 Supervisor-Worker 的核心循环 def run_supervisor(user_request): supervisor create_agent(Supervisor) tasks supervisor.plan(user_request) # 任务拆解 results [] for task in tasks: worker create_agent(task.role) # 可以并行也可以串行 result worker.execute(task) results.append(result) supervisor.collect(task, result) # 汇报阶段 final_answer supervisor.aggregate(results) return final_answer关键点在于所有的控制流都收拢在 Supervisor 里。Worker 不需要知道全局任务是什么只需要知道自己当前这一步要干什么。这样做的好处非常明显下一跳可控Supervisor 可以根据前一个 Worker 的输出动态决定下一步派什么任务而不是提前定死整个流程。失败处理集中某个 Worker 超时或出错Supervisor 可以自己决定重试、换 Agent、或换一种任务描述。上下文可控每个 Worker 只接收它需要的最小上下文不会被整个对话历史污染。2.2 面试时怎么把这个架构讲出彩我建议按“机制 - 场景 - 取舍”三步讲。先说机制Supervisor 是控制中心Worker 是执行单元控制流和数据流分离。再说场景适合“任务边界清晰、需要动态规划”的场景。比如某跨境电商客服系统用户说“帮我查一下订单并申请退款”Supervisor 规划出“查订单 - 校验退款资格 - 生成退款申请”三个任务分别交给三个 Worker每一步都依赖上一步的结果。这里最容易出彩的是讲取舍。不要只说“这个架构很稳定”要主动说出它的代价单点瓶颈Supervisor 要做所有决策是整个系统的性能和可靠性瓶颈。一旦它输出错误整个链条都会歪。上下文逐层传回的放大效应每个 Worker 的结果都要交给 Supervisor 再加工会导致最终汇总时需要处理的信息量很大token 消耗呈线性甚至指数增长。决策质量受限于 Supervisor 本身的能力本质上 Supervisor 也是一个人工智能模型规划能力能到 80 分整个系统就到不了 85 分。你可以说“所以我在实际落地时会对 Supervisor 的规划结果做一次结构化校验比如要求它输出 JSON 格式的 task list不符合格式就重试一次。”这种细节非常加分。2.3 一个小提醒Supervisor 不等于“只会串行派活”很多人误以为 Supervisor-Worker 就一定是串行执行。其实 Supervisor 完全可以并行调度多个 Worker——它把任务拆成互不依赖的两份同时交给两个 Worker 执行等两边结果都回来再汇总。这也是多 Agent 相对单 Agent 最大的优势之一。我在设计一个多源资料调研 Agent时就这么干过Supervisor 把“查行业报告”“查用户评价”“查竞品动态”三个任务并行派给三个 Worker极大地缩短了整体耗时。面试时提到这个细节能让面试官看到你真正理解了这个架构的调度潜力。3. 架构二Hierarchical把大问题拆成树的层层分包第二种是Hierarchical层级式架构。你可以把它理解为 Supervisors 一层套一层顶层 Supervisor 拆出几个子任务每个子任务又由一个中层 Supervisor 继续拆再往下分配给更具体的 Worker。整张图是一棵任务树控制流从根节点往叶子节点流动结果从叶子节点一层层往上汇总。3.1 为什么需要这种“二次拆解”因为当任务规模变大之后一个 Supervisor 管太多 Worker 会很快失控。我见过最典型的问题是顶部只有一个 Supervisor直接面对 20 个 Worker它要在同一轮决策里协调十几个子任务输出质量明显下降而且每轮决策要读回的上下文越来越多很快就把上下文窗口撑爆。Hierarchical 架构解决的就是这个“管理幅度”问题。顶层主管只面向 3 到 5 个中层主管中层主管只面向自己的 3 到 5 个执行者每层的上下文压力都被控制住了。用伪代码表达class AgentNode: def __init__(self, role, subtasksNone): self.role role # 顶层主管 / 中层主管 / 执行者 self.subtasks subtasks # 子节点可选 def execute(self, objective, context): if not self.subtasks: return run_llm_with_tools(self.role, objective, context) sub_results [] for st in self.subtasks: result st.execute(objective, context) sub_results.append(result) return aggregate_and_report(self.role, sub_results)3.2 什么场景下你会用到层级式当任务本身是多层嵌套结构时Hierarchical 模式几乎是自然映射。举个例子我要做一个企业年度经营分析报告 Agent顶层 Supervisor 拆成“财务分析”“市场分析”“组织效能分析”三个子任务。财务分析这个子任务下面再由中层 Supervisor 拆成“收入结构分析”“成本结构分析”“现金流分析”三个叶子任务。每个叶子任务再调用对应的数据查询工具或 Expert Agent 完成执行。每一层只处理自己视野内的信息不会一上来就把全公司的数据全部塞给一个 Agent。再比如代码仓库重构 Agent顶层拆成“前端代码分析”“后端代码分析”“数据库迁移评估”后端分析再拆成“接口梳理”“服务拆分”“依赖分析”接口梳理还可以继续往叶子节点拆。树有多深任务就有多细。3.3 面试回答的加分点讲清“深度由什么决定”面试官大概率会追问“层级拆到多深合适”这里我有一个很实用的回答框架决定拆分深度的关键是单层任务之间的耦合度和单个节点的上下文需求。如果叶子任务只需要很少的上下文就能执行说明它已经足够独立不用继续拆。如果拆到某个层级后子任务之间频繁需要交叉核对数据说明拆得太细了。数据依赖比任务个数更能反映拆分粒度。我一般用一句话判断每个叶子 Agent 接收到的上下文应该不超过它完成本步任务所需信息量的 1.2 倍。控制每层节点数在 3 到 5 个可以降低上一层的规划压力。这些话一出口面试官基本就能确认你不是只背过概念而是真做过深度设计。3.4 层级式架构的代价要说代价最大的就是延迟和成本。一个任务从根节点一路执行到叶子节点再一路返回中间要经过多轮 LLM 调用每一次调用都要花钱花时间。如果某一条分支失败重试还会倍增成本。另一个坑是层级多了之后底层信息在逐层汇总过程中很容易被浓缩丢失。叶子节点执行完成后返回的如果只是一个结论摘要上层主管就看不到过程细节一旦结论有误排查链路会非常痛苦。我的对策是让每个节点的返回结果带上“结构化日志”包括执行过程、关键中间结果、置信度评分而不只是最终答案。4. 架构三Collaborative-Debate让 Agent 互相挑错第三种架构和前两种完全不同它不再强调“上下级”而是让多个 Agent平级协作互相挑战、互相审查。这就是Collaborative-Debate协作-辩论模式。你想象一个场景三个专家围着一张桌子对同一个问题给出各自的答案然后互相质疑最后达成共识或给出多数意见。多 Agent 系统也可以这样做——多个 Agent 扮演不同视角的角色通过多轮辩论逼近更高质量的回答。4.1 这个架构的核心机制多视角对抗在 Collaborative-Debate 里每个 Agent 都有自己独立的视角、知识侧重点和“人设”。比如做一个内容审核 Agent 集群Agent A 负责从“事实准确性”角度审查。Agent B 负责从“安全合规”角度审查。Agent C 负责从“技术深度”角度审查。它们分别阅读同一篇文章输出自己的意见。然后进入辩论环节每个 Agent 能看到另外两个 Agent 的审查意见再给出自己的反驳、补充或让步。几轮之后由一个汇总器或者让三个 Agent 投票产出最终结论。这个模式很契合一个场景答案质量要求高没有唯一标准答案且需要多角度校验。典型如复杂逻辑推理题验证。医疗/法律等领域的知识问答强调多方交叉验证。代码走查一个 Agent 写代码另一个 Agent 负责找 bug。内容安全审核不同 Agent 负责不同维度的风险识别。4.2 你不需要让 Agent 真的“吵起来”很多文章会把这种模式描述成“让 AI 互相吵架”但在实际落地时你完全不需要真让它们自由对话。更可控的做法是结构化辩论# 结构化辩论轮次示意 def debate(rounds, context, agents): opinions [agent.initial_analysis(context) for agent in agents] for r in range(rounds): for i, agent in enumerate(agents): others [op for j, op in enumerate(opinions) if j ! i] opinions[i] agent.review(opinions[i], others, round_numr) return final_vote(opinions)每一轮Agent 都会拿到其他人的观点摘要然后输出自己是否坚持原判断、如果调整则说明原因、对别人的哪个观点最不认同。你可以限制每一轮输出长度比如 200 token 内防止出现毫无意义的车轱辘话。4.3 面试怎么讲这个架构的取舍这个架构最大的优势是能显著降低单模型盲区导致的错误率。尤其是当任务涉及“生成之后要自我评审”的情况单 Agent 自我纠错经常失灵——因为同一个模型用同样的思维模式很难发现自己的漏洞。多 Agent 用不同角色视角去审效果会好很多。但它也有非常明显的代价你面试时一定要主动提成本高N 个 Agent × M 轮辩论每一轮都是完整 LLM 调用。成本呈倍数膨胀。共识可能不收敛如果几个 Agent 各执一词、互不退让系统可能在所有轮次结束后仍无法达成一致。你必须设计一个最终的投票或裁决机制。角色设计难度大如果几个 Agent 的角色区分度不够高辩论效果趋近于同一个模型自我重复基本没有增益。我自己的经验是辩论轮数控制在 2 到 3 轮就已经足够再多轮边际收益急剧下降而成本线性上升。4.4 一个细节什么时候用“投票”什么时候用“裁判”有一种变体会用一个独立的Judge Agent来听取各方辩论并输出最终结论而不是让参与者自己投票。我在实际项目中通常这么选如果参与辩论的 Agent 角色相对客观比如“事实核查类”投票就够用。如果参与辩论的角色本身有立场偏移比如“市场增长看好方 vs 保守方”一定要用独立 Judge 做裁决否则结果会被某一方的论证气势带偏。这个细节很小但面试时讲出来很能体现设计的完整性。5. 架构四Pipeline一条生产线上干到底第四种架构叫Pipeline流水线模式。和多 Agent 的“商量着来”不同Pipeline 强调任务顺序执行前一个 Agent 的输出直接作为后一个 Agent 的输入像工厂里的流水线一样每一站只干一件事。如果你处理的任务有明确的先后依赖关系而且中间不需要回流和协商那 Pipeline 就是最简单高效的架构。5.1 Pipeline 模式的经典结构一个非常典型的三级流水线# 代码生成流水线示意 code code_gen_agent(requirement_text) review_report code_review_agent(code, requirement_text) fixed_code code_fix_agent(code, review_report)每一步都是单向传递没有回环。这在“规范化、流程化”的任务里特别好用。比如新闻稿件生产流水线选题 Agent - 信息采集 Agent - 初稿撰写 Agent - 编辑润色 Agent - 标题提炼 Agent - 排版校对 Agent。数据处理流水线数据清洗 Agent - 特征提取 Agent - 分析报告生成 Agent - 可视化 Agent。客服工单处理流水线意图识别 Agent - 信息核对 Agent - 解决方案生成 Agent - 人工复核辅助 Agent。Pipeline 的要点是每一步的输入输出协议必须定义得非常干净。前一步给后一步的是结构化数据还是自由文本决定了整条流水线的稳定性。5.2 Pipeline 和 Supervisor-Worker 有什么区别这是面试中最容易混淆的两组概念我专门对比一下Supervisor-Worker 的控制流在 Supervisor 手里。Supervisor 可以看完第一步结果后再决定下一步做什么任务序列是动态生成的。Pipeline 一旦启动每一步做什么、谁执行、按什么顺序都是提前定义好的静态流程没有中央决策者。用大白话说Supervisor 模式像一个项目经理当天看情况给下面派活Pipeline 模式像一条传送带零件放上去就按固定顺序加工到底。所以面试你要记住如果任务的执行路径固定写死流程的 Pipeline 更稳定如果任务的执行路径不确定需要根据中间结果动态调整Supervisor 模式更合适。5.3 Pipeline 模式下隐藏的巨型难点错误如何回滚很多人觉得 Pipeline 最简单没什么好聊的但实际上它有个非常难处理的问题错误会在流水线里向后传导。假设第一站的 Agent 输出了一份有严重缺陷的中间结果第二站、第三站的 Agent 不会察觉它们只会拿这个错误结果继续加工最终生成一份“看起来很完整但根上是错的”结果。单 Agent 或多 Agent 动态调度至少还有机会在中间发现问题Pipeline 每个节点都默认“上游是对的”所以污染会一路蔓延下去。我处理这个问题的方案是在关键节点之间加一个质量闸门Quality Gate比如用一个校验 Agent 或一套规则对中间产物做格式、完整性、合规性检查不通过就触发重跑或回退。给每个节点限定输出字段的结构化格式让非法输出更容易被机器自动发现。对流水线的每个中间产物都做版本快照一旦最终输出有问题可以定位到具体是哪一站的哪个版本出了问题。这些内容面试时说出来会显得你对 Pipeline 的理解远超“按顺序调几个 Agent”。6. 四种架构的选型对比与面试答题框架讲完四种架构现在用一个更直观的方式对比一下顺便把选型思路也讲清楚。维度Supervisor-WorkerHierarchicalCollaborative-DebatePipeline核心控制方式中央决策者动态派活多层决策者逐层拆解平级互相审查、对抗静态流程顺序传递适用场景任务边界清晰、路径需动态调整任务规模大、可自然分层答案需多视角验证、质量要求高流程固定、前后依赖明确并行能力支持多个 Worker 并行支持分支并行多 Agent 同时分析、多轮交互各节点通常串行可异步解耦主要风险单点决策瓶颈层级过深导致信息损耗与成本膨胀成本高、可能不收敛错误单向传导、难以回退成本水平中等较高高相对低但重试可能推高成本6.1 我的选型决策四步法面试如果遇到“请设计一个多 Agent 系统”的大题千万不要上来就画架构图。按下面四步走逻辑会非常清楚第一步画出任务的依赖关系图。用方框和箭头把子任务之间的依赖关系画出来。哪个任务必须在前哪个可以并行哪个需要反复校验——这张图决定了后面的所有选择。第二步判断控制流是静态还是动态。如果依赖关系基本固定优先考虑 Pipeline 或分层固定的层级式如果中间需要不断根据结果调整后续计划用 Supervisor 模式。第三步判断是否需要多视角对抗。如果任务对错误率极其敏感且存在评审、审查、校验环节考虑在关键节点加入 Debate 机制而不是整条流程都用辩论。第四步明确兜底和观测方案。无论选哪种架构都要交代清楚失败怎么重试上下文怎么传递成本怎么控制链路怎么追踪。这一部分往往是面试官最想听你展开的。6.2 高频追问的答题模板这里整理四个我在准备时总结的高频追问和我的应对思路追问一Agent 之间怎么通信不要只说“用消息传递”。要补一句“在 LLM 层面消息本质上就是结构化文本。我会给每条消息定义统一的 schema比如{sender, receiver, task_id, content_type, content, timestamp}。同时区分控制消息和数据消息控制消息走轻量级协议数据消息可以直接引用上游中间产物的文件路径避免把大段内容反复塞进上下文。”追问二状态和数据放在哪里经典回答“每个 Agent 保持无状态共享状态放在外部存储比如内存数据库或向量库。每个子任务的输入输出都持久化记录方便断点续跑和审计。” 这其实借鉴了微服务设计的思路面试官会很受用。追问三多 Agent 带来的额外成本如何控制“我会做三层控制第一层是入口控制能单 Agent 解决的任务绝不启用多 Agent第二层是执行控制限制每个 Agent 的 max token 和最大调用次数第三层是出口控制设置超时和总成本上限超过阈值直接降级为单 Agent 兜底。”追问四如何评估多 Agent 系统效果不要只盯着准确率。要说综合指标任务完成率、端到端延迟、token 成本、重试率、人工干预率、以及端到端输出质量。可以采用“先小样本人工评估 再大样本自动化指标验证”的两阶段评估避免依赖单一指标。6.3 一个“先给结论、再展开”的万能开场如果是开放式的设计题我的答题开场固定是这样的“如果让我设计这个多 Agent 系统我会先做一个判断这个任务的依赖关系是偏静态还是偏动态。从目前的需求看它包含 A、B 两个固定阶段其中 B 阶段又依赖 A 的多种输出结果同时 B 本身质量要求很高。所以我会选择 Supervisor-Worker 作为整体骨架把 A 阶段作为 Worker 并行执行B 阶段引入一个审查 Agent 形成小范围 Debate。整体成本预估在每任务 XX 元左右后续可以用淘汰机制验证效果。”先给架构再给理由再给成本和验证方案。这个顺序本身就体现了系统设计思维。7. 实战踩坑记录状态、成本、死锁与评估最后分享几个我在自己搭多 Agent 项目时真实踩过的坑。这些不一定写在教科书里但遇到的时候真的很要命。7.1 上下文污染问题比预想中严重早期我做过一个多 Agent 内容分析系统为了让每个 Agent 都“理解全局”我把对话历史直接传给所有 Agent。结果项目上线后发现上游 Agent 随口提的一句“用户好像不太满意”传到下游后竟然被当成事实引用进了最终报告。后来我规定Agent 之间的上下文传递必须经过两次过滤第一次是结构化摘取第二次是相关性校验。每个 Agent 只接收当前任务必须的信息其余信息一律不外传。系统的准确性一下子就上来了。7.2 “死锁”真的会发生不要笑多 Agent 系统里有一种类似死锁的状态两个 Agent 互相等待对方先给结论又没有哪个 Agent 有权限主动推进整个任务就卡住了。尤其是你用 Collaboration 模式时A 说“还需要 B 的确认”B 说“必须等 A 给出最终方案”两边谁都不让步。我的解决办法是任何多 Agent 系统都要有一个总超时机制到时间后由固定的一方仲裁或降级。不要相信 Agent 自己能协商出结果你就当它们是一群初级工程师必须有人拍板。7.3 token 成本失控算账要提前我曾经做过一个带辩论机制的 Agent 系统原本心里预计每轮辩论消耗 5000 token结果上线后发现实际每轮要 8000 多 token。因为 Agent 会在复述对方观点时把整段原文都带上导致一轮辩论的信息放大好几倍。后来我在系统里加了两个约束一是要求 Agent 在引用他人观点时只能引用编号二是限制每轮辩论输出不超过 150 字。成本立刻降回预期范围。多 Agent 系统的成本不是靠预估出来的是靠结构约束出来的。7.4 评估链路不能只看“最终答案”多 Agent 系统的另一个隐蔽坑是最终答案对了但你根本不知道是哪个环节起的作用出了问题也没法定位。我给这类系统做评估时会同时记录三个层面的数据每个 Agent 的独立输出、Agent 之间传递的中间消息、最终汇总结果。线下抽测时如果最终结果错误我会溯源到具体是哪一层出了问题。如果是某个 Worker 的信息有误我会回头修它的提示词如果是汇总层把信息浓缩坏了我会调整汇总策略。没有中间过程记录的多 Agent 系统出了问题就是黑盒只能推倒重来。7.5 一点个人体会如果你正在准备面试我最想跟你说的是不要只背架构图一定要亲自动手搭一个小 Demo哪怕只是用现成框架跑通一个最简单的主管-工人流程。因为在跑通的过程中你会自己发现上下文怎么传、超时怎么设、结果怎么汇总、失败怎么兜底——这些真实体验才是面试时最宝贵的谈资。多 Agent 系统的本质不是“Agent 很多”而是“解决一个复杂问题的组织方式”。把组织逻辑讲清楚你的答案就已经超过大多数背稿选手了。