面试这事最怕的不是不会，是会了但说不出来。多Agent系统面试就是典型代表，面试官一句“你们的多Agent系统用的什么架构”，不少人脑子里翻涌着论文、框架、实践案例，开口却只剩“多个Agent一起配合干活”这种一句话答案。这个问题在我这些年参与技术面试时出现频率稳居前三，几乎每个候选人都会被问到。

很多人会问：多Agent系统面试到底该怎么准备？我总结出来的经验是，先忘掉ZZZ，“xx架构能用就行了”这种想法，把4种经典架构按面试官想听的逻辑重新过一遍。这篇文章不做概念搬运，直接讲清楚每种架构长什么样、为什么存在、面试时怎么组织语言、被追问时怎么接住。

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

1.1 对“多Agent”的基础认知要过关

先明确一个基本前提：多Agent系统不是“多次调用大模型”，而是多个具备独立角色、独立目标、独立记忆甚至独立工具权限的智能体，通过某种组织结构协作解决单一智能体搞不定的复杂任务。

面试官问架构之前，心里有一个默认前提：你能不能分清楚Agent和多Agent系统的区别。一个Agent配上工具，那是工具调用；几个Agent各自配一套工具集、共享一份上下文状态、按规则互相传递消息，这才是多Agent系统的范畴。

很多候选人在这一层就开始模糊。有人会把“一个Agent里写了好几个function call”说成多Agent，也有人把“两段Prompt拼一起”当成多Agent。面试官只要追问一句“那你的Agent之间消息协议是什么”，基本就露馅了。

1.2 面试官真正想听的能力分层

关于多Agent架构，面试官的真实考察点可以拆成三层：

• 概念层：你是不是真的理解每种架构的角色边界、消息流向和状态管理方式，而不是背了几个名词。
• 权衡层：给定一个业务场景，你能不能说出为什么选这种架构而不选另一种，代价是什么。
• 工程层：你聊的架构里有没有超时、重试、熔断、上下文隔离、失败恢复这些落地细节。

我见过不少候选人在“概念层”表现很好，架构图画得漂亮，一进“权衡层”就露怯。问一句“为什么不用单一协调者”，答不上来，只能反复说“感觉这个更灵活”。这种答案会让面试官怀疑他根本没把架构放进真实场景里验证过。

所以回答架构问题的核心套路不是“我知道几种”，而是“我能判断什么时候用哪一种”。这篇文章后面给到的话术，也都是围绕这个标准来设计的。

2. 第一种经典架构：单一协调者（Orchestrator-Workers）

2.1 架构图景：一个大脑加多个触手

单一协调者架构是最容易理解、也是面试里最好展开的一种。简单说：有一个主Agent叫Orchestrator，负责任务理解、拆解、分配、汇总，下面挂N个工作Agent，每个工作Agent只负责执行自己领域内的子任务。

拓扑结构用文字描述大概是：

RootAgent（协调者/规划者） ├── WorkerAgent A（负责信息检索） ├── WorkerAgent B（负责数据分析） └── WorkerAgent C（负责结果校验）

这个结构特别像一个老板带几个执行员工。老板不亲自做执行，但所有决策、资源调度、信息汇总都集中在老板手里。工作Agent之间不允许直接通信，要交换数据必须经过协调者中转。

这种架构最核心的设计哲学是“可控优先”。你想想，一个系统里多个Agent都在自由发挥，最怕的是什么？是行为不可控、改了这个影响那个。单一协调者把所有调度逻辑收拢到一个节点上，新增一个工作Agent、修改一个调度规则、插一段校验逻辑，都只动协调者一处，不碰其他Agent。

2.2 面试话术：突出“可控”与“可观测”

面试时描述这种架构，我建议往“可控性”和“可观测性”两个关键词上靠，这两个词正好踩中工程落地的考察点。

你可以这样说：

对于任务边界清晰、有明确流程控制的场景，我会优先考虑单一协调者架构。协调者负责意图识别、任务拆解和结果汇总，每个工作Agent聚焦单一职责。我选择它的第一个原因是可控性：所有决策路径都经过中心节点，方便插入校验和兜底逻辑。第二个原因是可观测性：中心节点记录了完整的任务流转日志，出了问题能快速定位到具体环节。

如果面试官问你“这个架构的缺点”，别慌，这个问题反而是你展示深度的机会。核心缺点有三个：

• 协调者是单点，一旦主Agent崩溃，整个任务链直接断掉。解法是为主协调者设计独立的失败恢复路径，比如把中间状态持久化到外部存储，重启后从最近一个checkpoint继续。
• 协调者承担了太多上下文，容易超出大模型的上下文窗口。解法是控制子任务粒度和消息摘要长度，不要让所有原始信息都堆在协调者那里。
• 工作Agent缺乏信息流通，部分需要协作判断的任务没法完成。解法是引入共享记忆库或者消息中间件，由协调者控制读写权限。

2.3 追问环节的准备

面试官对比单一协调者时最爱追问两个问题，提前备好：

第一个追问是“某个Worker挂了怎么办”。不要只回答“重试”，要说出重试的边界。比如设置最大重试次数，超过次数后让协调者降级处理，把失败信息返回给上层而不是无限卡住。再进一步，可以说明Worker是无状态优先的，任务放到工作Agent之前先把必要信息打包成完整输入，避免Worker依赖内部状态导致重试失败。

第二个追问是“多个Worker之间需要共享数据时怎么办”。标准答案是“共享存储加读写权限控制”。可以用一个Redis或者向量数据库作为共享记忆，协调者分配读写权限，防止两个Worker同时写导致脏数据。

3. 第二种经典架构：群聊式（Peer-to-Peer）协作

3.1 架构图景：一群平等的个体自由发言

群聊式架构和单一协调者正好相反。这种模式里没有中心调度者，所有Agent地位平等，通过共享的消息流互相订阅、发布和响应。它像一群人围在会议室里讨论问题，谁有想法谁说话，谁跟谁观点互补就直接互动。

拓扑画出来大致的形态是：

AgentA <─────> AgentB ↑ ↑ ↑ ↑ ↓ └────── AgentC AgentD <─────> AgentE

每个Agent都可以读取公共消息流，也可以把自己的输出发出去。信息传输方向不再经过中心节点，自由度和爆发力很高。

这种架构在开源框架里很常见，主要用来做“多角色脑暴”和“并行方案探索”。举例来说，你要设计一个新产品方案，可以同时放三个Agent，一个扮演技术负责人，一个扮演产品经理，一个扮演合规专员，让他们针对同一个需求分别提出意见，再互相评论和补充。这种情况下，单一协调者反而显得死板，因为评论文本无法提前规划成固定子任务。

3.2 面试话术：突出“探索性任务的高效性”

面试里聊群聊式架构，第一句话先点定位：这是探索性任务优先的架构，适合没有固定流程、需要从多个角度逼近答案的场景。

完整话术可以这么组织：

当任务本身是探索性的，比如方案评审、头脑风暴、多视角分析，我会考虑群聊式架构。这种架构的好处是Agent之间可以直接交换信息，不需要把所有内容都回传到中心节点，避免了上下文冗余。多个Agent可以从不同维度看到同一个问题，结论会更立体。

紧跟着必须主动说出它的短板，否则面试官会觉得你只看到优点。短板我总结了三条：

• 结果不可控。所有Agent都在自由发言，容易出现论述发散、主题漂移。解决办法是引入一个独立的汇聚节点，或者增加轮次上限。
• token消耗高。每个Agent都在读写公共消息流，如果上下文长时间保留，费用和延迟都会爆炸。解决办法是定期做消息摘要，把历史内容压缩后再放回公共流。
• 可能出现死循环。AgentA提出观点，AgentB反驳，AgentA再反驳，循环十几个回合没有收敛。解决办法是设收敛条件，比如连续N轮没有新信息就自动终止。

3.3 追问环节的准备

面试官对这个架构最感兴趣的追问点是“你怎么让讨论收敛下来”。

这里有一个很实在的解法：不是指望讨论自然停止，而是把“终止”本身当作一个Agent角色。设计一个专门负责监控的Agent，它不参与观点讨论，只观察每个Agent的发言是否有新增内容，连续两轮都没有新信息就输出一个结束信号。这样设计之后，群聊式架构就有一点往混合方向靠了，但收敛问题确实能解决。

另一个高频追问是“Agent之间的消息怎么路由”。不要回答得太抽象，我一般这么说：每条消息带一个结构化头字段，标明发起者、接收者、消息类型、关联的讨论主题ID，Agnet根据订阅规则消费消息。如果某个Agent只对该关问题感兴趣，就不会接收到无关噪声。这实际上是在给Agent通信加一层过滤机制。

4. 第三种经典架构：流水线（Pipeline）处理

4.1 架构图景：一条工序明确的流水线

流水线架构的思路来自工业生产线。任务像原材料一样进入生产线，依次经过多个Agent，每个Agent只处理一道工序，处理完传给下一个Agent，直到最后产出成品。

画出来是：

输入 → AgentA（意图识别） → AgentB（信息检索） → AgentC（结果生成） → 输出

每个环节的输入是上一环节的输出，输出是下一环节的输入。环节之间可以插入存储、校验、人工审批等中间节点。

流水线架构和单一协调者容易混淆，实际区别在于：单一协调者架构里，协调者对每个子任务有强调度能力，工作Agent并行跑；流水线架构里，任务本身按顺序流动，每个环节是稳定的工序，不太需要中心调度者来告诉这一步该做什么，因为顺序是固定的。

这种架构的优势是职责极度单一。每个Agent只需要关注自己这一道工序，Prompt设计更聚焦，上下文也可以做得很短。而且每个环节可以独立替换、独立重试、独立测试。

4.2 面试话术：突出“稳定流程的吞吐”

面试里讲流水线架构，锚点是“稳定流程”。

话术参考：

当任务处理链路相对固定、顺序关系明确时，流水线架构是最合适的。我在设计内容审核链路时会用这种架构，先由意图识别Agent判断内容类型，再由安全检测Agent做规则扫描，最后由质量评估Agent打分。整个流程顺序稳定，每个环节都可以单独扩容和单独降级。

如果想在这个回答里加分，可以主动提一个计算模型：流水线的总延迟是各环节延迟之和。假设每个环节平均耗时是80毫秒，三级流水线理论延迟就是240毫秒，但实际要考虑队列等待时间。如果某个环节成为瓶颈，只能在它后面再加并行副本，而不是简单增加链路上所有节点的资源。

再补一个中间状态落地的细节：每个环节的输出数据要落到存储里，这样当下一环节失败时可以选择从该环节重新触发，而不用整个任务从头再来。

4.3 追问环节的准备

一个常见的追问是“某个环节失败了怎么处理”。我的建议是做出分级策略：前置环节出错了可以直接重试，因为不涉及前面环节的副作用；后面环节出错需要先确认前序输出是否已持久化，已持久化的话只重跑失败环节，没持久化就得回溯到最近的检查点。

另一个追问“怎么扩展流水线上的新环节”。回答思路是设计统一的输入输出Schema，只要是结构化数据，新环节就可以像插件一样插进去。但要注意，每增加一个环节，链路延迟会线性增长，所以新增环节要评估“收益 vs 延迟成本”。

这类架构面试官容易接的示例还有：代码提交后依次走静态检查Agent、安全扫描Agent、性能检测Agent。每个环节都独立跑，失败直接返回给开发人员。

5. 第四种经典架构：分层混合（Hierarchical）协调

5.1 架构图景：金字塔式的分工

分层混合架构是前面几种的组合体，也是我实际项目里用得最多、最推荐在面试中展示“系统设计能力”的架构。它的特点是没有一个全能的中心，而是呈树状递进。

结构上分得比较清楚：

RootAgent（全局统筹者） ├── CoordinatorA（子协调者） │ ├── WorkerA1 │ └── WorkerA2 └── CoordinatorB（子协调者） ├── WorkerB1 ├── WorkerB2 └── WorkerB3

最顶层的RootAgent只做全局级别的任务拆解，按业务域切分给子协调者；子协调者负责自己领域内的二次拆解，指挥具体执行Agent。执行Agent之间不直接跨域沟通，跨域信息由上一级协调者传递。

这个架构理解起来最自然的类比是公司组织架构。CTO不直接写代码，只管几个业务线总监；每个总监管自己团队里的经理；经理带着一线员工干活。层级越多，信息传导越慢，但每个层级的上下文范围被天然限制住了。

5.2 面试话术：突出“可扩展性与职责边界”

面试中聊分层混合架构，不要急着画图，先讲清楚它的适用边界。我的表达方式是：

对于大型复杂系统、涉及多个业务域的场景，我会选择分层混合架构。第一层用一个全局协调者负责意图分类和域间路由，第二层按领域设置子协调者，每个子协调者自己管理领域内的执行Agent。这么做的好处有三个：一是上下文被分层隔离，不会全堆到一个中心节点；二是领域内逻辑可以独立迭代，改售后流程不碰订单流程；三是故障半径小，一个子协调者挂了，其他域的任务还能继续跑。

这里要特别注意：分层混合架构不是“更大一号的单一协调者”，它的核心区别在于“每一层都有决策权”。全局协调者不关心领域内的具体实现，只关心结果；子协调者拥有自己领域内的调度自由。这在面试里说出来，面试官会觉得你真正理解了这个架构的价值。

延迟问题是分层架构绕不开的软肋，面试里一定要主动提。每一层信息传递都要经过父节点，层级越深延迟越高。解决思路是给每层设定超时上限，并尽量把跨层交互设计成一次性的请求响应，而不是低效的反复协商。

5.3 追问环节的准备

面试官每次听到这种树状结构，最担心的就是“一层挂了，整个体系崩不崩”。

回答这个问题要突出“子域自治”。子协调者内部尽量不依赖全局协调者的实时调度，全局协调者只是在开始阶段做任务分派，后续子协调者可以独立推进。等到结果汇总阶段再通过一个协议通知上层。这样全局协调者短暂不可用，也不会影响已经下发的任务继续跑。

另一个追问是“多级超时怎么设置”。经验做法是每层设置与业务预期匹配的响应上限，比如执行Agent层30秒超时，子协调者层60秒超时，全局协调者层120秒超时。低层超时不直接向全局暴露，而是先尝试降级，再失败才逐级上报。这样上层拿到的永远是“最终结果”，而不是一堆底层异常堆栈。

这个架构特别适合在客服领域举例：全局协调者判定这是订单问题还是售后问题，然后分给对应的子协调者，子协调者再调度查单Agent、退款Agent或人工客服转接流程。

6. 实战答题：把4种架构融进一套面试回答框架

6.1 三段式：定义、权衡、演进

聊完四种架构，说一个让我受益最深的答题框架。面试官问架构题时，别直接报答案，按三段式来：

第一段“定义与定位”，用一句话说清楚这个架构是什么、要解决什么问题。比如“单一协调者架构适合任务边界清晰的流程控制型系统”。

第二段“权衡与选择”，结合具体业务场景说明为什么选它不选其他架构，讲清楚牺牲了什么。比如选择单一协调者是牺牲了并行探索能力，换来了强可控性。

第三段“演进与落地”，补充失败重试、超时、监控、扩展性这些工程细节。这一段最能拉开和普通候选人的差距。

这三段说下来，既展示了广度，又展示了深度。面试官不会觉得你在背题，反而会觉得你系统性地想过这些问题。

6.2 一个完整的示范回答

拿一个实际场景演示一下完整回答。假设面试官问：“你们需要做一个多Agent的智能文档分析系统，文档类型杂、分析维度多、流程不确定，你选什么架构？”

可以这样答：

文档类型杂说明意图判断复杂，分析维度多说明需要并行处理，流程不确定说明不能提前设置固定工序。所以我会选择分层混合架构，顶层用一个全局Agent先做文档分类，识别出它属于合同类、报表类还是技术文档类。第二层按文档类型设置子协调者，合同类的协调者去调度条款提取Agent、合规分析Agent、风险评分Agent；报表类的协调者去调度数据读取Agent和趋势解读Agent。全局协调者不干预具体分析逻辑，只负责把最终结果汇总成统一格式。这样设计的理由是每一类文档的分析流程都可能在后续快速变化，中层协调者可以独立调整自己领域内的流程，不牵连其他模块。同时我会在每个层级的调度节点上设置超时和降级策略，比如条款提取Agent失败两次就自动转人工标记，而不是无限重试。

这个回答涵盖了架构选型、理由阐述、容错设计，还给到了可落地的细节，面试官后续追问都有得聊。

6.3 高频追问点速查表

我在面试里整理过一份高频追问表，每次准备候选人问题都用它。放在下面供参考：

这些追问其实都在考察一个核心能力：你能不能把这个架构当成一个真实系统来运营，而不是停留在理论模型里。

7. 我踩过的坑与面试官视角的观察

7.1 错误回答长什么样

这些年面试下来，我总结出几类典型的“踩坑式回答”，列出来大家可以直接对照自查：

我记忆特别清楚的一次面试，候选人上来就画了一个很标准的单一协调者拓扑，画完说“这个架构非常好”。我问了一句“好在哪里”，他愣住了，只说得出“大家都在用”。其实架构本身没有绝对的好坏，好坏全靠场景来定义。不结合场景聊架构，等于白聊。

7.2 几条特别想说的实操建议

准备这类问题，光看文章是不够的，需要动手做几件事。

第一件事：拿一个你熟悉的业务场景，用四种架构各设计一遍。比如“做一个多Agent周报生成系统”，用单一协调者怎么做、流水线怎么做、群聊式怎么做、分层怎么做。做完你会明显感觉到每种架构的手感不同，面试时被问到“为什么选这个”时也有真实依据。

第二件事：练习“边说边画”。面试很多是白板题，你一边画拓扑一边讲理由，讲到哪里画到哪里。不要先把图画完再解释，那样节奏很闷。练习时可以对着镜子或者录屏，看自己能不能在三分钟内把一种架构讲清楚。

第三件事：准备一个自己真实踩过坑的案例。面试官很爱问“你在实际项目中遇到过什么问题”，你不需要说多么宏大的故障，一个小例子就够了。比如“我们的协调者Agent上下文经常超限，后来把长文档改成了分块检索注入，问题解决了”。这种细节远比背十个架构名词有用。

7.3 面试之外的复用价值

准备这些架构不只是为了面试。我自己在实际项目中设计多Agent系统时，首先想的也是这四种原型。接到一个需求，先判断它是流程型、探索型、顺序型还是领域复杂型，然后从四种架构里选原型做改造。这种思考方式能让你少走很多弯路。

如果把多Agent系统比作组建一支团队，单一协调者是强leader模式，群聊式是扁平小组模式，流水线是标准化车间模式，分层混合是事业部制模式。你在面试里要做的，不只是说出这四种组织的名字，而是让面试官看到：你知道在什么场景下组建什么样的团队，知道每个角色该干什么，也知道队伍出问题时怎么处理。

每次面试到这个问题，我最后都会跟候选人说一句：架构没有标准答案，但你对架构的理解深度，一定会在对话里暴露出来。把四种原型吃透，再用自己的场景去验证，这道面试题大概率就稳了。