最近两轮模拟面试里，至少有三位候选人被问到同一道题：多 Excel 系统怎么做设计？很多人张口就是“让多个大模型互相对话”，结果被追问到卡壳；也有人把“编排器、层级、流水线”这些词挨个报一遍，却讲不出任何一个架构的适用条件。这道题真正想检验的，不是你会不会念概念，而是你有没有让多个 Agent 协作落地过。 多 Agent 系统面试 里最值钱的答案，往往是你做出的取舍和踩过的坑。这篇内容我直接把平时做系统设计时默认使用最多的 4 种经典架构拆开讲：流水线、编排器—工人、层级、辩论协作。每个都给你讲清楚适用场景、关键设计细节和面试官最想听到的追问点。
1. 先看穿出题人的意图：面试官到底想考什么
1.1 表面在问架构，实际在问三种底层能力
多 Agent 系统听起来像是一种“姿势”，但它并不是大模型版本的多人聊天室。面试官问这类题，目标基本可以压缩成三件事：任务拆解能力、架构选择能力和失败管理能力。
任务拆解能力，看你能不能把一个模糊目标分解成多个可执行、可验证的子任务。架构选择能力，看你能不能为不同场景匹配不同的协作模式，而不是一套框架打天下。失败管理能力，看你能不能回答出“如果其中一个智能体挂了会怎样、输出不合格会怎样、上下文爆了会怎样”。很多候选人挂在第三点，因为离开文档后，他们对异常流程没有直觉。
所以你在回答里要多出现“边界”和“兜底”这类词。比如讲到流水线时，主动说“我会在上游节点加超时控制，下游节点做格式校验；如果某个节点连续失败，把它标记为高危节点并走回退策略”。面试官一听就知道你不只是看过教程。
1.2 先反问再答题，把开放性题目变成情境题
优质回答不是立刻开始背架构，而是先反问两句来缩小题目范围。这样做不是取巧，因为多 Agent 本来就有很强的场景依赖，面试官也想看你怎么定义问题。
开场可以这样问：“您这个问题是偏业务场景落地，还是偏框架原理设计？如果偏落地，我更关心任务是偏固定流程还是开放探索，因为这会直接影响我选流水线还是会选编排器–工人。”一般情况下面试官会给你一个方向。有了方向之后，你再往下说，内容会精准很多。
我见过不少候选人把四种架构全部讲一遍，讲到第三分钟面试官已经开始眼神涣散。更好的讲法是只讲一个主架构，再补充一个备选。覆盖“为什么选它”和“它牺牲了什么”，远比覆盖面更重要。
2. 四种经典架构，按这个顺序讲不容易丢分
2.1 流水线/链式架构：最适合先讲的基础款
流水线架构很好理解，你调用一个 Agent 处理完某个环节之后，把结果交给下一个 Agent，环节之间是严格的先后关系。它很像工厂里的装配线：采购做一遍、加工做一遍、质检做一遍，物料不能越过上一道工序。
面试里提到这种架构时，不要只描述“依次调用”，要立刻深入到三件事：节点协议、校验位、重试回退。
第一，每个节点必须有统一输入输出协议。我在模拟项目X里设计过一个内容生产流程，分为“资料检索 → 观点提炼 → 初稿撰写 → 质量复核 → 终稿输出”五个节点。我不允许上游把一大段原始文本直接甩给下游，而是要求输出一个固定字段的结构体，包括摘要、来源列表、待确认问题等。这样下游逻辑很干净，不会因为上游换了 Agent 而崩掉。
第二，关键节点之间要加校验环节。比如质量复核节点输出不合格时，我给流程设计了一个“打回”逻辑：初稿节点保留最近三次生成结果，复核节点可以指定最差问题再让初稿重跑。这个过程严格说已经从纯流水线变成了带循环的链式流程，但它仍然是固定角色、固定顺序。
第三，节点失败要有超时和重试。单个 Agent 返回超时太常见，不能让它拖死整条链路。我一般会给每个节点设最大重试次数，超限就把当前任务进入人工处理队列，而不是无限循环。
这套架构的优点是好解释、好调试。你把链路图画出来，每个节点都可以单独跑、单独测，也方便定位哪个环节糟糕。所以面试开场先讲它，能快速建立“我有工程感”的印象。
不合适的地方也很明显，它扛不住任务路径不确定的场景。如果一个用户的请求需要灵活分支，今天要查 A 资料，明天要调 B 接口，流水线就很笨重。另外单点故障也比较棘手，上游输出越差，下游越吃亏。
2.2 编排器/主管—工人架构：最常用，也最容易讲得像模板
编排器—工人架构是现在各类框架里默认最多的模式。一个中心化 Agent 充当主管，接收任务后负责拆解、调度、汇总；旁边挂一批专业 Agent，各自只负责一类子任务。它的职责很像开项目会，产品经理排需求和分活儿，程序员只处理自己负责的模块，最后产品经理再把结果收回来。
很多人会把编排器和流水线搞混。它们最大的区别是：流水线下一环节是固定的，编排器的下一步是动态决定的。主管 Agent 看完当前情况后，可能决定先调用资料分析 Agent，再调用代码生成 Agent，也可能发现资料不够又回头调用数据采集 Agent。链路不固定，甚至支持回溯。
面试里这么讲会显得更专业：“我会给 Worker 设计统一的接口，所有 Worker 都只接收任务描述和所需上下文，不直接共享内部状态。”理由是降低耦合度。如果每个 Agent 都能随便读写全局变量，你根本没法定位是谁污染了上下文。
编排器还有一个关键槽点：它自己是最大的单点瓶颈。所有转述和交流都经过它，它会越变越长，而且它的拆解能力直接决定系统上限。所以我在设计时会把编排器的 prompt 写得“短而精悍”，只让它做计划、调度和结果合并，不追求让它亲自回答专业问题。专业问题交给 Worker，编排器只做“取舍”。
这个架构的好处是适配面广。任务清晰的小场景可以用，任务模糊的大场景也可以作为中间层接入到更大的编排里。面试时如果你想给一个万能答案，编排器–工人就是那个最稳妥的默认选择。
但它也有代价：调试成本更高。主管 Agent 情绪一波动，整个协作模式就跟着乱。因此你需要额外记录调度轨迹，比如每次分派给哪个 Worker、用了什么输入、产出什么结果，这些都落到日志里，才能复盘。
2.3 层级架构：应对团队规模变大的必然选择
当 Worker 数量增多到二十个以上，让一个主管同时管理所有 Worker 很快就失控。这时候可以引入层级架构，让它更像公司里的组织架构：顶层一个总管理者只负责战略拆分，把任务分配给中间层；中间层管理者再把任务继续拆分给底层的专用 Worker，任务完成后再逐层汇总。
面试讲到层级架构，重点要说清楚“为什么要减少管理半径”。任何 Agent 能承载的信息量都有限，顶层 Agent 如果直接面对底层几十个 Worker，它很快会陷入细节焦虑，根本顾不上整体规划。加一层管理者，本质是在做信息过滤和局部决策。
层级设计很容易踩坑。最典型的错误是把层级做得过深，一个任务从顶层到真正的执行层要走五层“传话”，每层都有损耗，最终把能力和效果都稀释掉了。我一般建议最多三层到四层，超过这个深度就直接拆成多个独立子团队。
面试官如果追问“一层和两层有什么区别”，可以用这个框架回答：如果任务之间必须共享大量状态，不要分层；如果任务可以被划分成几个互不干扰的子领域，可以分层。层级架构的真正用途不是解决状态共享问题，而是减少中心角色的上下文压力。
这里还有个容易显得老道的细节：让上层 Agent 对下层 Agent 尽量用“目标描述”而非“步骤命令”。上层只告诉中间层“我要什么结果”，至于中间层怎么调度自己手里的 Worker，由它自己决定。这样上层上下文里不需要真实细节，写进日志的都是目标、进度和结果，系统可扩展性会好很多。
2.4 辩论/评审协作架构：用多视角对抗不确定性
最后一种是多 Agent 之间的辩论协作，或者叫评审协作。它不是上下级关系，而是几个平级 Agent 在同一个议题上相互制约。最经典的组合是三个角色：一个方案提出者、一个反对评审者、一个最终决策者。提出者出方案，反对者专门找它的问题，决策者看完正反两面再给结论。
这种模式的本质是用多视角降低单 Agent 的盲区。单个模型的输出受限于它的偏好和上下文，它可能对明显的问题视而不见；但当你让一个 Agent 专门扮演挑刺者，它的“挑刺”是被允许的，它就会更积极地发现漏洞。这在内容质量要求高的任务里非常有效，比如合同风险点审查、代码安全评审、策划案复核。
使用这个架构需要注意“不要用同一套偏好互相演”。如果所有 Agent 都由同一套大模型 API 驱动，它们很容易互相成全而不是互相质疑。写入你训练集里的题目要体现这是为什么：语言生成任务、审查任务、角色分离 prompt 的差异要足够大，否则看到的“批评”只是一场表演。
成本问题是这类架构最脏的一笔账。一个任务跑三轮，token 消耗可能就是单 Agent 的十倍。我在设计时通常会给辩论设置两个锁：一轮数上限，最多跑三到四个来回；二超时自动收敛，超过时限就由决策者直接定稿，避免系统卡在无限讨论里。
面试里提到这种架构时，要主动说“它提高的是可解释性和质量兜底，但它不解决效率”。如果你把它吹成全场景最优，面试官反而会怀疑你没跑过真实数据。
3. 面试回答的表达框架：从“会架构”到“会讲架构”
3.1 万能三步法：定义边界、选型取舍、闭环验证
多 Agent 系统面试的回答不只是选架构，还得有一套叙事结构。你可以把三步法当成“满分作文骨架”来用。
第一步，定义边界。先讲你面前任务的核心难点是什么。如果难点是流程太多，那就适合流水线；如果难点是需求多变，那就适合编排器；如果难点是单个模型判断不可信，那就适合辩论评审。这个动作看起来简单，但大部分候选人会跳过它，直接开始讲连接方式。没有问题定义的架构是不值钱的。
第二步，选型取舍。不要只说“我用了什么”，要说出你为此放弃了什么。例如“我选择编排器–工人，是因为任务之间有共享上下文，但我知道这么做会带来编排 Agent 的上下文膨胀，所以我设计了摘要机制来做控制”。这里出现了“代价”，面试官就会相信你做过真正的技术判断。
第三步，闭环验证。你要讲怎么证明系统可用。我会在答完架构后追加一段：“我会先构建一个包含二十个典型场景的回归集，跑通后再逐步替换不同模型版本，对比成功率、平均耗时和 token 成本。”这段话一出来，整道题的档次立刻就和你只背概念完全不同。
3.2 没有场景时，默认选编排器—工人架构
很多面试题目不会给你明确业务背景，只会说“请设计一个多 Agent 系统”。这时候我会直接抛出默认答案：先谈单 Agent 够不够，再谈多 Agent 怎么引入一个主管和一组 Worker。
选择这个架构有三个理由：它是主流框架默认支持的，推进阻力最小；它可以兼容很多分支场景，比如把某个 Worker 替换成一个 mini 流水线；它可以通过扩展逐步变成层级架构，不会走死胡同。面试的本质不是选“正确”架构，而是选“能用且好解释”的架构。
遇到“如果给你一个跨平台数据报表类的任务，你会怎么做？”这种题时，用三步法来回答会非常顺。我会先说这个任务偏向固定流程，首选用流水线；然后定义五个节点，分别是数据接入、字段清洗、报表生成、异常检查、结果推送；最后补充“异常时重试三次，仍失败就进入人工队列”。这个回答既具体又有场景感，比背一百个智能体连接方式要好看得多。
3.3 控制时长：用“主干 + 彩蛋”的方式作结构
面试里最令人窒息的情况，是候选人把每个概念都讲得很长。针对多 Agent 系统，控制讲述节奏其实比内容量更关键。
我建议用“主干 + 彩蛋”方式。主干部分只讲一个主架构和一个备选架构，再配上你的验证方法。剩余时间留一个彩蛋，比如“我其实还拆过一个辩论Agent做最终评审，但从成本角度它不一定值得，所以主流程没用它”。这句话透露出你掌握更多知识，但不用花时间展开。面试官若感兴趣就会自己追问，你刚好接得住。
这样答还有一个好处：你不容易被人认为是在背稿。面试官会觉得你心里有一套逻辑，遇到新问题也能临场变通。
4. 高频追问与真实项目中的翻车点
4.1 追问一：为什么不用一个大模型 Agent 直接搞定？
这个问题几乎必问。核心是测试你对“单 Agent 能力边界”是否理解。你要给出一个看似简单但严谨的回答：单 Agent 适合单次推理、少量工具调用、目标清晰的线性任务；一旦任务需要多个专业角色、多轮状态管理、不同上下文隔离，单 Agent 会陷入上下文混乱。
我习惯用一个阈值来记忆：如果任务超过 5 个工具调用，或需要并行处理互不相关的数据源，单 Agent 的 prompt 就很容易写得越来越大，难以维护和调试。多 Agent 的核心收益不是“更聪明”，而是“更好的问题隔离”。每个 Agent 只需要做好自己的事，不需要理解全流程。这句话建议原样记住，面试时会很加分。
另外你也得说一句反向思考：能单跑就别多跑。多 Agent 会放大歧义、延迟和成本。如果面试官追问“什么情况不要用多 Agent”，你要顺势列出几个不适合场景，例如任务很快、不需要角色隔离、不能接受额外 token 开销等。
4.2 追问二：上下文会不会被撑爆？成本怎么控制？
这道追问是想检查你是否真的构建过生产系统。我的回答里通常会包含四个手段，组合使用。
一是摘要化中间结果。每个 Agent 输出不要直接丢给下一个环节，先让专门角色生成结构化摘要，保留关键字段和结论，剔除原始长文本。这能很大程度延迟整体上下文膨胀。
二是外部化状态。不要让 Agent 在系统内无限带对话历史，而是把中间数据写入外部存储，Agent 只读它需要的字段。这样即使某一步需要回滚，也不至于把整段历史塞回模型里。
三是并行化短链路。如果有多个互不依赖的子任务，可以让 Worker 并行运行，再由编排器汇总。虽然 token 总量不变，但能明显缩短耗时，面试时这也叫“并行度设计”。
四是为每轮设置任务上限。我会明确“一个主流程最多调用 N 个子任务”，超过之后立即进入收敛模式，开始汇总。如果还不满足，就转人工兜底，而不是无限消耗。
4.3 追问三：你怎么证明系统比单 Agent 更可靠？
这条问题的关键，在于你不能只表达“我觉得”。要拿出一套可执行的质量评估方案。
第一步是建立回归集。从真实历史任务里抽二十到五十条样本，每条包含输入、期望输出和判定标准。第二步是跑自动化对比：同样的任务分别跑单 Agent 系统和多 Agent 系统，统计成功率、失败重试次数、平均耗时、token 消耗。第三步是记录样例差异。比如多 Agent 系统在“需要多领域知识”的任务上提升明显，但在“简短问答”上反而变慢，用结果说话。第四步是给系统设置“熔断开关”，当观测到某一评分快速下滑时，自动回退到单 Agent 或低配流程。
这个方案当场说出来，面试官基本难再追问。因为你不是在背概念，而是给了一个可迭代的工程闭环。
5. 只有踩过坑才懂的执行要点
我把这些年的实践教训压成五条。虽然不是直接的面经，但每一条都能在面试追问里转化成你自己的案例。
第一条，能用单个 Agent 解决的，绝对不要为了“高级”而上多 Agent。单个 Agent 出问题只需要修一个环节；多 Agent 系统出错，你要在多个节点里大海捞针。很多项目失败并不是模型能力不足，而是架构复杂度提前爆炸。面试谈架构时，你要表现出“我很克制”的态度，这反而更可信。
第二条，每个 Agent 的职责要写“边界”而不是“目标”。目标写得太宽，角色就容易越权。比如让一个资料检索 Agent 负责“找到 2024 年行业趋势，并做趋势分析”，它可能顺手把写报告的活也干了；你应该限定它为“输出结构化事实清单，不带观点和结论”。边界清晰的 Agent，联合调优才可控。
第三条，不要只靠模型记忆状态。真正落地的项目都会把中间状态放到外部。每个 Agent 开始执行前读取它在任务中的阶段和约束，结束后把最新状态写回去。这样即使某次调用结果异常，系统也能从上次稳定状态继续。面试把这条讲出来，会显得你不是在写 demo。
第四条，把失败处理当成一等公民。我见过太多设计文档把“如果某步骤失败”写成一句“重试”，但实际重试 5 次可能都是同一个错。更有效的方式是让每个关键节点同时准备两套策略：重试一次同一 Agent，然后立刻切换到一个结构完全不同的备选策略，比如换一种 prompt 模板或改用外部规则校验。这样才会打掉模型自己的“偏执”。
第五条，先写评估，再写系统。我在模拟项目X里做多 Agent 改造时，一开始没有回归集，全靠人工判断效果，改一个参数就要花半天去感受。后来我花了半天整理三十条测试样本，每次改动都跑一遍，效率变得非常高。这道面试题也一样，面试官真正欣赏的，是那个能把“效果好不好”这个问题变成一个量化判断的人。
多 Agent 系统面试的底层逻辑并不复杂：把任务拆清楚，把角色边界画清楚，把失败路径补齐，把成本账算明白。你把这四点做到位，哪怕你没提全四个架构名称，面试官也已经能看到你的系统设计能力。
