1. 面试官问多 Agent 架构时，到底在考察什么

这两年大模型应用面试里，多 Agent 系统的出现频率高得吓人。很多候选人一听到"多 Agent"就两眼放光，开始背 LangChain、AutoGen、CrewAI 的概念，结果面试官一句"那你给我讲讲你设计的系统为什么用这种架构"，当场卡壳。

我平时帮朋友做模拟面试，也带过不少人梳理项目，发现一个共性：大家不是不会写代码，而是说不清楚为什么这么设计。多 Agent 系统的面试题，表面问的是"你用过什么框架""你写过几个 Agent"，实际上考察的是三件事：

第一，你有没有把单轮 Prompt 调用升级成"系统设计"的思维方式。第二，你能不能根据任务约束（成本、延迟、准确性、可扩展性）选择合理的 Agent 协作拓扑。第三，你踩过多少真实的坑，能不能讲出取舍逻辑。

面试官真正想看到的不是一张漂亮的架构图，而是你脑子里有没有一套"从任务出发推导架构"的方法。所以我总结了 4 种在面试里最常被讨论的经典架构：Supervisor 主管调度型、Pipeline 流水线型、Graph 图协作型、Debate 对抗辩论型。这 4 种架构能覆盖绝大多数面试场景，而且每个都可以对应到实际项目中。

我在后面会挨个拆解，每种都讲清楚：核心思路、适合什么场景、怎么用自己的项目去包装、面试官喜欢从哪个角度追问。最后还会给一套从场景约束推导架构选型的通用框架，以及我踩过坑之后总结的面试表达技巧。

顺便说一句，如果你是刚开始接触多 Agent，不要急着堆框架。先把 4 种架构的拓扑关系、数据流向、失败模式搞明白，再去套工具，效率会高很多。面试官也是人，他们想听到的是"你真正想清楚了，而不是背了一堆名词"。

2. 架构一：Supervisor 主管调度型架构，面试的标准答案

2.1 核心思路与适用场景

Supervisor 架构是最容易讲清楚、也最容易获得面试官认可的一种。它的核心结构是：一个主管 Agent 负责任务拆解、分配、汇总和决策，多个工作 Agent 分别执行具体子任务。听起来像经理和员工的关系，主管不直接干活，但知道谁适合干什么，干完了结果如何合并。

这种架构非常适合两类场景。一类是任务边界清晰、子任务之间几乎没有依赖关系的场景，比如同时做市场调研、竞品分析和用户画像，三个 Agent 可以并行跑，最后统一汇总。另一类是任务需要动态决策下一步调用哪个专业模块的场景，比如一个客服系统，先判断用户意图，再决定调售后、技术支持还是产品咨询。

在面试里，我建议把 Supervisor 架构作为"安全牌"。不是因为它简单，而是因为它的职责划分最符合人类组织协作的直觉，面试官容易理解，你也容易把话题引向自己熟悉的技术细节。

我记得有一次模拟面试，候选人讲他做的报表生成系统，用了 Supervisor 架构：主管 Agent 先解析用户输入，判断需要哪些数据源，然后分发给"数据查询 Agent""图表生成 Agent""文案撰写 Agent"。这个思路本身没什么问题，但他被追问"如果数据查询 Agent 超时了怎么办"就答不上来。

2.2 如何用自己的项目经验包装这个架构

如果你自己做过 Agent 项目，哪怕是课程设计或 Demo，都可以往 Supervisor 架构上靠。关键不是照搬，而是找出你项目里的"主管逻辑"到底做了什么决策。

举个例子，假设你做过一个"智能简历筛选系统"。你可以这样描述：我设计了一个主控 Agent，它先对简历做初步分类，判断岗位匹配度，然后分发给"技能评估 Agent""项目经验 Agent""文化匹配 Agent"三个子 Agent。子 Agent 返回结构化评分，主控 Agent 再基于权重融合分数，输出推荐排序。这样讲，面试官听到的就不是"我调用了好几个模型"，而是一套有分工、有决策、有汇总的完整设计。

当然，你不能漏掉背后的实现细节。你需要说清楚：子 Agent 之间如何通信？是用消息队列、函数调用，还是共享上下文？主管 Agent 怎么知道子 Agent 完成的信号？如果子 Agent 给出的结果格式不一致，谁来负责标准化？

这些细节才是面试官打分的依据。哪怕你的项目很小，只要你能把"通信协议""超时处理""重试机制""结果校验"讲出来，就已经超过一大批只会画流程图的人了。

2.3 面试中容易被挑战的边界

Supervisor 架构有一个最常见的槽点：主管 Agent 本身可能成为瓶颈。所有子任务都要经过它调度，一旦主管 Agent 的上下文过长、决策逻辑复杂，它的响应速度和准确率都会下降，整个系统就卡住了。

面试官大概率会问："如果并发任务很多，Supervisor 忙不过来怎么办？"这时候千万不要说"加个并发就行"，那等于白说。合理的应对思路是：分级路由。也就是先用一个轻量级分类器（不一定是大模型）做粗粒度分流，把任务划分成几条固定流程，每个流程有自己的 Supervisor，避免单点集中。

还有一类追问是："如果子 Agent 返回了错误信息，主管 Agent 能发现吗？"你可以回答：我在主管 Agent 的汇总阶段加了一步校验，让它对比多个子 Agent 的结果一致性，或者用规则引擎检查数值范围。这种"容错设计"是面试官非常看重的加分项。

不要觉得 Supervisor 架构"太简单"就看不上。恰恰相反，在绝大多数真实业务里，一个清晰可控的主管调度模式，远比后面讲的图协作架构更落地、更容易维护。面试里，先把 Supervisor 讲透，比炫技讲十个 Agent 乱斗有用得多。

3. 架构二：Pipeline 流水线架构，简单但要说清数据流

3.1 为什么流水线是最容易讲清楚的架构

Pipeline 架构的核心是：把任务拆成固定顺序的多个阶段，每个阶段由一个专门的 Agent 负责，前一个 Agent 的输出直接成为后一个 Agent 的输入。典型例子是内容生成流程：选题 Agent -> 大纲 Agent -> 初稿 Agent -> 审核 Agent -> 润色 Agent，一个环节接一个环节，像工厂流水线。

这种架构在面试里特别容易获得共鸣，因为它的控制流简单直观：没有复杂的回路，没有动态分派，数据流向一眼就能看穿。面试官不需要你反复解释，他也容易顺着你的思路去追问细节。我见过很多候选人把复杂项目硬说成复杂架构，结果越描越黑，反而是那些老老实实讲"我这条流水线分五步"的人，得分更高。

但注意，流水线架构的难点不在于"画出顺序"，而在于阶段间数据的传递与协议设计。你必须想清楚每个 Agent 的输入输出 schema，否则到下一阶段一定会出现解析错误。面试官特别喜欢问："你的审核 Agent 如果发现初稿不合格，怎么返工？"

这个问题一旦抛出，很多候选人就懵了，因为严格的流水线是单向的，没有回头路。如果审核不通过，要么丢弃重来，要么得从上一个阶段重新开始，非常浪费。

3.2 面试现场的代码级表达

如果到了现场，能用简洁的伪代码把流水线结构描述出来，效果会非常好。我推荐一种表达方式：先定义每个阶段的函数，然后用一个简单的循环把它们串起来。

def run_pipeline(input_data): outline = outline_agent.generate(input_data) draft = draft_agent.write(outline) review_result = review_agent.check(draft) if not review_result.passed: # 把审核意见拼进上下文，让初稿 Agent 重写 draft = draft_agent.rewrite(draft, review_result.suggestions) final = polish_agent.polish(draft) return final

不用真的写完整代码，面试官只在乎你脑子里有没有"状态"和"数据流"的概念。你可以顺带说一句："我在每个环节都定义了统一的 Message 对象，包含 role、content、metadata 字段，这样哪个阶段出了问题，我可以通过日志回溯到具体节点。"

这种表达有几个好处：第一，体现你有工程落地能力，不是只画概念图；第二，自然地引入"重试、回调、异常处理"这些工程话题；第三，让面试官觉得你的设计是可控、可观测的。别忘了，多 Agent 系统面试，本质上是系统设计面试，不是文学创作。

3.3 流水线的死穴与应对

流水线架构的死穴是：当任务顺序不确定、需要动态决策时，它就会变得非常僵硬。比如一个开放域问答系统，用户可能问技术、问攻略、问情感，如果固定走一条流水线，前置的"意图识别 Agent"一旦判断错误，后面整个流程都会跑偏。

面试官一旦追问"动态任务怎么处理"，不要硬扛，大大方方承认流水线适合确定性强的任务。你可以立刻补一句："所以我在系统里做了一个前置分流：先用意图识别模块判断任务类型，再根据类型选择不同的流水线模板。这样既有流水线的稳定性，又兼顾了动态性。"

另外，流水线的错误传播是累积的。第一阶段的输出如果有小瑕疵，经过后面几轮放大，最后的结果可能面目全非。我处理这类问题的方式是：在关键节点加入交叉验证 Agent，比如让"事实核查 Agent"独立复查初稿中的关键数据，而不是完全依赖上游。面试里可以主动说这个点，一般都能引起面试官的兴趣。

4. 架构三：Graph/网络协作架构，讲好"有限状态"与"动态路由"

4.1 图结构比树结构更接近现实

Graph 架构是目前大厂面试里越来越常见的高阶话题。它不像 Supervisor 那样只有一个中心，也不像 Pipeline 那样固定顺序，而是把不同 Agent 看成图上的节点，Agent 之间的关系看成边，任务沿着边流动，边可以带条件判断、分支、循环和并行逻辑。

为什么说图结构更接近现实？因为现实任务几乎不会是一条线走到底。比如做一份行业研究报告，你可能需要先收集数据，根据数据质量决定是否需要补充采集，再决定是走分析师撰写还是图表优先展示。这种"根据中间结果动态决定下一步"的流程，只有图能表达清楚。

在面试里讲 Graph 架构时，我不建议一上来就搬框架名。更稳妥的打开方式是：先讲你遇到的问题，然后说"我发现用线性的 Agent 编排无法处理任务分支，于是用图的方式重构了状态流转"。这样面试官会认为你是从问题出发选择了方案，而不是为了用图而用图。

4.2 如何解释节点和边的设计

面试官非常喜欢问细节："你的图里面节点之间的边是怎么定义的？边上的条件逻辑放在哪里？是放在代码里，还是让 LLM 去判断？"这个问题没有标准答案，但你需要表达清楚两种做法。

第一种，条件逻辑放在代码里。也就是说，Agent 返回结果后，由程序逻辑判断下一跳去哪个节点。这种方式的好处是可控、可测试、成本低；坏处是灵活度不够，遇到语义模糊的情况容易判断错。第二种，条件逻辑也交给 LLM。比如让一个 Router Agent 读取当前所有节点的语义描述，然后从候选中选择下一跳节点。好处是灵活，坏处是增加了延迟和 token 消耗，而且 Router Agent 本身可能选错。

我的建议是：在面试中强调"默认用代码规则，对规则覆盖不了的情况再用 Router Agent"，这是一种非常成熟的工程态度。你可以说："我把每个节点设计成类，节点之间通过显式的 next() 方法（或统一消息队列）连接，边上维护一个 condition 对象，condition 可以是规则表达式，也可以是一个轻量模型。"这比你只丢出一张拓扑图显得实在得多。

另外，还需要解释 Graph 架构的状态保持问题。多 Agent 之间的上下文如何传递？你是把所有历史消息全部塞给下一个节点，还是让每个 Agent 只接收结构化摘要？如果全部塞，上下文窗口会爆；如果只传摘要，又可能丢失关键信息。我通常的做法是：全局维护一份"记忆库"，只把当前节点相关的关键信息拼入 prompt，同时定期把关键结论写回记忆库。面试时把这个机制讲出来，面试官会眼前一亮。

4.3 面试官看向量积、上下文窗口时的回答思路

Graph 架构很容易引出两个进阶追问：一是"你如何管理 Agent 之间的长期记忆"，二是"上下文长度超了怎么办"。这两个问题背后，面试官是在考察你有没有考虑真实系统的资源约束。

上下文管理方面，可以这样回答：我采用三层机制。第一层是短期上下文，就是当前任务节点的全部输入输出；第二层是会话摘要，用专门的压缩 Agent 把历史关键信息压缩成摘要，超过阈值就滚动覆盖；第三层是持久化向量存储，重要结论和实体关系写入向量库，需要时通过相似度检索召回。这套机制不仅能缓解上下文爆炸，还能让每个 Agent 专注于自己的子任务，避免无关信息干扰。

如果在 Graph 里引入了向量检索，面试官紧接着就会问："你用的什么向量库？"这时候你别瞎编，就老实说"我用的是开源方案，主要关注召回准确率和检索延迟"。如果没实际用过，就坦诚说"这是我设计中的一部分，还没有在线上大规模压测，但我做过小规模实验"。面试最忌胡编乱造，专业的人一听就知道你有没有真做过。

5. 架构四：Debate/对抗与反思架构，体现进阶思考

5.1 多角色辩论的原理

Debate 架构是这 4 种里面最有"高级感"的一种，也是很多人试图用来装点门面、但常常讲砸的一种。核心思路是：让多个 Agent 扮演不同立场或不同专业背景的角色，围绕同一个问题给出各自的方案，然后互相质疑、补充、修正，最后得到比单个 Agent 更可靠的结论。

原理其实很简单：单个 LLM 存在系统性偏差，比如过于自信、跟风主流观点、忽略反例。当你让两个或多个模型互相辩论时，它们会暴露彼此的漏洞，迫使对方重新审视自身推理过程，从而提升推理质量。面试官问 Debate 架构，通常不是想听你吹"多模型就是比单模型强"，而是想听你如何解决辩论的收敛问题。

最典型的情况：两个 Agent 谁也说服不了谁，一直吵下去，永远不会结束。如果你没有应对机制，面试就会垮掉。我见过一个候选人说"我让它们辩论五轮然后取最后一轮的结果"，那个方案太粗糙，因为最后可能依然是对立状态。

5.2 收敛机制与成本控制

面试里讲 Debate 架构，一定要主动讲收敛设计。我整理了几个可落地的策略：

• 固定轮数 + 裁判汇总：设定最大辩论轮数，结束后由一个中立的裁判 Agent 综合双方论点，输出最终结论。这是最常用的兜底方案。
• 基于置信度的提前终止：每个 Agent 在每一轮给出回答时附一个置信度分数，当两个 Agent 的置信度同时高于阈值且观点趋同，就提前终止。这个方案可以省 token。
• 证据投票机制：各方必须从给定的检索材料里引用证据，相同证据条数多的一方在汇总时权重更高，避免纯语义空转。
• 反思式辩论：每一轮辩论结束后，加入一个反思 Agent，要求双方先复述对方观点的核心论据，再提出反驳，这样可以减少误解式吵架、增强有效交锋。

成本方面也不能避而不谈。辩论架构的 token 开销通常比 Pipeline 高 3~5 倍，延迟也更明显。面试官问"你这方案线上能用吗"，你应该主动说："对于高价值、低频率的推理任务（比如医疗建议、合同审查），我可以用完整辩论；对于高频简单任务，我用单 Agent + 校验兜底。"这种成本分层意识非常加分。

5.3 面试加分项：反思与自我修正

Debate 架构还有一种变形，叫 "自我反思" 架构：不安排多个 Agent，而是让同一个 Agent 对自己的输出进行多轮批判修正。你完全可以把它跟 Debate 一起讲，作为"降低运行成本"的替代方案。

我建议的面试话术是："我在做合同风险审查时，先用一个 Agent 起草风险清单，再让审查 Agent 专门挑刺，把挑出的问题返给起草 Agent 修改。这相当于让模型自己和自己辩论。"如果追问"你为什么不直接让两个不同模型辩论"，可以回答："两个模型会带来额外的部署成本和延迟，在一致性要求高的场景里，我更倾向于让同一模型扮演不同角色分步反思，保证风格统一。"

记住，Debate 架构的面试目标是展示你的纵深思考能力，而不是展示你用了多强的卡。当你能主动给出收敛策略和成本预算时，面试官就知道你不是在背概念了。

6. 面试回答的通用框架：从场景约束推导架构选型

6.1 四步法：定目标 -> 画边界 -> 选拓扑 -> 控成本

很多候选人问我："5 分钟怎么讲清楚一个多 Agent 系统？"我的回答是：不要上来就画架构图，先讲推导过程。我总结了一个百试不爽的"四步法"。

第一步，定目标。一句话说清你的系统解决什么问题，核心指标是什么。比如"我要做一个文档问答助手，核心指标是准确率，不能接受答案里出现事实错误"。面试官只要听到这里，就知道你清楚自己在做什么。

第二步，画边界。明确哪些任务必须交给 Agent，哪些任务可以用规则或传统程序完成。很多系统根本不需要在多 Agent 里塞一个"时间戳生成器"或者"字符串格式化器"。你要表现出"知道 LLM 适合做什么、不适合做什么"，这是资深工程师和调包侠的分水岭。

第三步，选拓扑。根据业务流程对 Agent 之间依赖关系的分析，选择 Supervisor、Pipeline、Graph 或 Debate。具体怎么选？我一般用三个判断条件：任务步骤是否固定？步骤之间是否有数据依赖关系？是否需要动态决策？ 如果步骤固定、依赖明确，选 Pipeline 或 Supervisor；如果存在条件分支、并行、循环，选 Graph；如果任务既固定又需要高质量论证，可以局部加 Debate 子流程。

第四步，控成本。成本包括 token 开销、延迟、模型调用次数和出错时的重试成本。你需要给每个节点预估一次调用的 token 量和延迟，然后估算最坏情况下的端到端耗时。面试官问“你系统响应为什么这么慢”，如果你能报出"每个子 Agent 平均 300ms，串联了 5 个节点，最坏耗时 1.5 秒"，这就是非常专业的回答。

6.2 一张自检表帮你应对追问

我把自己在面试前常用的自检清单分享出来，每一条都可以作为你回答的牵引线：

这张表也是我自己带团队时的复盘框架。每次系统出问题，第一件事不是改代码，而是按照这个表把对应位置打叉，再决定是调 Prompt、调拓扑还是调基础设施。面试里能把这套思维讲出来，面试官想不给高分都难。

7. 踩过坑后的真实建议

7.1 别把"多Agent"说成"多个Prompt"

我听到过太多候选人说："我做了三个 Prompt，分别扮演客服、售后和技术专家，这就是多 Agent 系统。"这种回答在一年前可能还能糊弄过去，现在绝对不行。多 Agent 系统的核心是多个交互单元之间的通信、协调和决策机制，而不只是几个不同的 system prompt。

你至少要讲清楚：Agent 之间通过什么机制交换信息？是共享同一个上下文缓冲，还是通过结构化消息？Agent 的决策是由 LLM 独立做出的，还是由外部代码逻辑控制的？任务失败时谁会负责兜底？

如果你真的只做了多个 Prompt，那你也可以在面试里这样讲："我最初用多个 Prompt 做角色分工，后来遇到上下文互相干扰、角色指令遗忘等问题，于是引入了一个小的控制模块来管理 Agent 间的消息传递和状态维护，演进成了一个轻量级的 Supervisor 架构。"这个说法既诚实，又能展示你的成长过程。

7.2 面试官要的不是架构图，而是你的取舍逻辑

有些候选人准备了一套非常精美的架构图，到了面试现场对着图讲了五分钟，面试官打断问："你为什么在这个环节用向量搜索而不是直接全文拼接？"他答不上来。

实际上，面试官想通过你的项目，看看你能否在一个不确定性极高的系统里做出理性决策。"我用了 chroma 存向量，因为试过全量拼接会把 prompt 撑爆"比"我用向量存储来管理长期记忆"好得多。前者展示了你做过测试、有数据意识、知道失败模式；后者只是一句正确的废话。

所以，我强烈建议：在准备多 Agent 面试时，把重点从"架构长什么样"转移到"为什么长这样"。每一个设计决策，都准备一条理由：为了降低延迟？为了减少 token 成本？为了避免下游错误累积？为了提升可维护性？哪怕这条理由最后被面试官反驳了，你们的讨论也能往更深层次走，而深度恰恰是评分的关键。

7.3 如果只有 30 秒，怎么讲清楚

最后分享一个压缩表达技巧。如果面试官时间很紧，只给你 30 秒介绍项目，你可以用这个句式："我做一个 XX 系统，面临 XX 约束，所以我设计了 XX 架构，核心是让 A Agent 做 XX、B Agent 做 XX，通过 XX 方式协作，最终把 XX 指标从 X 提升到 X。"

比如："我做一个法律文书审核系统，面临事实准确性要求极高的约束，所以我设计了混合架构：用 Pipeline 保证流程稳定，在关键条款审查节点加入 Debate 双 Agent 交叉验证，并设置了三轮轮数上限和中立裁判汇总，最终把关键条款漏检率降低了一半。"

30 秒内包含了目标、约束、架构选型、核心机制、量化效果，这就是一个完整的"面试字节"。你可以把它当作万能模板，对话术调整顺序，但一定保留"约束 -> 选型 -> 机制 -> 效果"这个骨架。

我自己在面试别人的时候，最反感的是候选人把 Agent 当成一种魔法，说"我用 Agent 实现了所有功能"。真正被录用的那些人，往往都是老老实实讲清楚"我为什么要分好几个 Agent、它们怎么配合、失败了我怎么处理"的人。多 Agent 系统面试没有标准答案，但只要你掌握了这 4 种经典架构的拓扑、动机、局限和应对策略，再用四步法把你自己的项目套进去，就很难被问倒。

希望这篇总结能帮你在下一次面试里少踩几个坑。如果你也在准备多 Agent 相关的岗位，不妨自己动手搭一个最小的 Supervisor 和 Pipeline 对比实验，把 token 数、响应时间、错误率记录下来——有了亲手测过的数据，你在面试里的底气会比背十篇架构文章都足。