多Agent架构面试怎么答？四种经典架构与选型指南

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

面到多 Agent 系统这道题，很多人第一反应是背概念：什么"多个智能体协作完成任务"、什么"分工明确各司其职"。但真坐到面试桌对面，面试官抛出一句"你设计一个多 Agent 系统，怎么划分角色"，能答到点子上的人其实不多。

我前后参与过几轮这类岗位的面试，也帮朋友做过模拟面，发现一个规律：面试官问多 Agent，从来不是想听你复述定义，而是想看你有没有真正"拆过系统"。他关心的是三件事——你能不能把一个大任务拆成多个 Agent 能接的活、你知不知道 Agent 之间怎么传话、你踩没踩过协作失控的坑。这三件事对应到架构上，就是角色划分、通信机制、协调策略。

所以这篇不聊虚的，我把多 Agent 系统里最常被问到的四种经典架构拆开讲，每种都配上"面试怎么答"的话术框架，以及我在实际项目里踩过的坑。不管你是准备面试，还是真的要动手搭一套多 Agent 系统，这些内容都能直接拿去用。

先给个整体认知：多 Agent 系统本质上是在解决"单个大模型搞不定复杂任务"的问题。一个 Agent 能力再强，上下文窗口有限、单点容易出错、没法并行。拆成多个 Agent 之后，每个 Agent 专注一小块，通过协作把整体能力放大。但拆得越细，协调成本越高，这就是架构设计要平衡的核心矛盾。

下面四种架构，从简单到复杂排列，基本覆盖了目前主流的多 Agent 设计思路。

2. 流水线架构：最容易被低估的"老实人"方案

2.1 流水线架构长什么样

流水线（Pipeline）架构是最朴素的一种：把任务拆成几个固定阶段，每个阶段一个 Agent，前一个的输出就是后一个的输入，像工厂流水线一样串起来。

举个具体例子。假设要做一份行业调研报告，流水线可以这样设计：

• 检索 Agent：负责搜集原始资料，输出一堆候选文档
• 筛选 Agent：从候选里挑出高相关的，去重、打标签
• 分析 Agent：对筛选后的资料做归纳、提炼观点
• 撰写 Agent：把分析结果组织成结构化报告
• 校对 Agent：检查事实错误、逻辑漏洞、格式问题

每个 Agent 只干一件事，输入输出格式固定，串行执行。

2.2 为什么面试官爱问这个

流水线架构看着简单，但它考察的是你对任务分解的理解。面试官会追问："你怎么保证每个阶段的输出质量？"这时候你要能说出几个关键点。

第一，阶段边界要清晰。每个 Agent 的输入输出必须是结构化数据，不能是"一段模糊的自然语言"。我一般会用 JSON schema 约束，比如检索 Agent 必须输出{documents: [{title, content, source}]}这种格式。这样下游 Agent 拿到数据不用猜，直接解析。

第二，要有质量门禁。流水线最大的风险是"垃圾进垃圾出"，前一阶段错了，后面全错。所以每个阶段之间要加校验。比如筛选 Agent 输出后，检查文档数量是否在合理区间、标签是否覆盖了关键维度。不达标就回退重跑，而不是硬着头皮往下走。

第三，错误处理要明确。某个阶段失败了怎么办？是重试、跳过还是终止整个流程？我的经验是：检索类阶段可以重试，分析类阶段失败最好终止并报警，因为分析错了后面全白搭。

2.3 流水线架构的面试话术

如果面试官让你设计一个多 Agent 系统，而你判断任务本身是线性的、阶段明确的，直接上流水线，然后这样答：

"这个任务我倾向于用流水线架构，因为它阶段清晰、依赖关系是线性的。我会把任务拆成 N 个阶段，每个阶段一个 Agent，输入输出用结构化 schema 约束。关键设计点有三个：一是阶段边界要可验证，每个阶段的输出都要有质量门禁；二是错误处理策略要分阶段定，检索类可重试、分析类要终止；三是整个流水线要能观测，每个阶段的耗时、成功率、输出质量都要打点，方便定位瓶颈。"

这段话的杀伤力在于：你不仅说了架构，还说了为什么选它、怎么保证质量、怎么运维。面试官一听就知道你干过。

2.4 流水线的坑：别把它当万能药

流水线最大的问题是不灵活。任务一旦不是线性的，比如需要反复迭代、需要根据中间结果动态调整，流水线就抓瞎了。

我踩过一个坑：早期做一个内容生成系统，用流水线串了"大纲→初稿→润色→配图"四个 Agent。结果发现润色阶段经常发现大纲有问题，但流水线没法回退到大纲阶段，只能硬着头皮润色一篇逻辑有问题的稿子。后来改成允许"润色 Agent 打回大纲 Agent"的机制，才解决。

所以流水线适合阶段稳定、依赖单向的任务。如果你的任务需要反复迭代，往下看第二种架构。

3. 主管-下属架构：一个"包工头"带一队"工人"

3.1 主管-下属架构的核心逻辑

主管-下属（Supervisor-Worker）架构，也叫编排者模式。核心是一个"主管 Agent"负责拆解任务、分配工作、汇总结果，下面挂若干个"下属 Agent"各干各的。

和流水线的区别在于：流水线是固定顺序，主管-下属是动态调度。主管根据任务情况，决定派谁去干、干几轮、什么时候收工。

还是拿调研报告举例。主管 Agent 拿到"写一份行业调研报告"的任务后：

1. 先拆解成子任务：搜集资料、分析竞品、整理数据、撰写报告
2. 把"搜集资料"派给检索 Agent
3. 拿到结果后，判断资料够不够，不够就再派一轮
4. 资料够了，派给分析 Agent
5. 分析完，派给撰写 Agent
6. 最后自己汇总、检查、输出

主管 Agent 是大脑，下属 Agent 是手脚。

3.2 主管 Agent 到底怎么"思考"

这是面试高频追问点。主管 Agent 本质上是一个带工具调用能力的 LLM，它的"思考"就是一轮轮的推理+决策。

具体实现上，主管 Agent 通常有一个循环：

def supervisor_loop(task): context = init_context(task) while not task_done(context): # 1. 推理当前状态，决定下一步 decision = llm_reason(context) # 2. 根据决策调用对应下属 Agent if decision.action == "delegate": result = call_worker(decision.worker, decision.input) context.update(result) elif decision.action == "finish": return decision.output # 3. 检查是否需要调整策略 if need_replan(context): context = replan(context)

关键在llm_reason这一步：主管要能根据当前上下文，判断"现在该干什么"。这需要给主管一个清晰的系统提示词，告诉它有哪些下属、每个下属能干什么、什么情况下该派谁。

我一般会这样写主管的提示词：

你是一个任务协调者。你有以下下属：检索员（负责搜集资料）、分析师（负责归纳提炼）、撰写员（负责成文）。你的职责是：1）把用户任务拆成子任务；2）按依赖顺序派发给合适的下属；3）检查下属输出质量，不合格就打回重做；4）所有子任务完成后汇总输出。每次只派一个任务，等结果回来再决定下一步。

3.3 主管-下属架构的面试话术

面试时如果任务有明显的"总-分"结构，可以这样答：

"这个任务我倾向用主管-下属架构。设一个主管 Agent 负责全局调度，下面挂几个专职下属。主管的核心能力是任务拆解和动态调度，它维护一个任务队列，根据依赖关系和完成情况决定下一步派谁。下属 Agent 只负责执行，输入输出结构化。这个架构的好处是灵活，能处理非线性任务；代价是主管 Agent 本身可能成为瓶颈，而且主管的决策质量直接决定整个系统的上限。"

3.4 主管架构的两个致命坑

坑一：主管上下文爆炸。所有下属的输入输出都要汇总到主管这里，任务一复杂，主管的上下文窗口就撑爆了。我的解法是：主管只保留"摘要级"信息，详细结果存在外部存储里，主管需要时再按需读取。比如下属返回的不是完整文档，而是"文档已生成，ID 是 xxx，摘要如下"。

坑二：主管决策死循环。主管可能反复派同一个任务，或者在下属失败时不停重试。必须加最大轮次限制和失败熔断。我一般设主管最多调度 20 轮，单个下属连续失败 3 次就跳过并记录，避免整个系统卡死。

4. 黑板架构：让 Agent 自己"抢活干"

4.1 黑板架构是什么

黑板（Blackboard）架构来自经典 AI 领域，核心思想是：所有 Agent 共享一块"黑板"（公共数据区），每个 Agent 盯着黑板，发现有自己的活就主动去干，干完把结果写回黑板，触发其他 Agent。

和主管架构的区别在于：没有中心调度者。主管架构是"我派你干"，黑板架构是"我看到有活就干"。这是一种去中心化的协作方式。

举个例子。做一个复杂的数据分析任务，黑板上初始写着"原始数据集"。几个 Agent 同时盯着：

• 清洗 Agent 看到"原始数据集"，主动清洗，写回"清洗后数据集"
• 特征 Agent 看到"清洗后数据集"，主动做特征工程，写回"特征集"
• 建模 Agent 看到"特征集"，主动训练模型，写回"模型"
• 评估 Agent 看到"模型"，主动评估，写回"评估报告"

每个 Agent 不需要知道别人在干什么，只需要知道"黑板上出现什么状态时我该动手"。

4.2 黑板架构的触发机制怎么设计

这是黑板架构的技术核心。每个 Agent 都要有一个"触发条件"，满足条件才动手。触发条件通常基于黑板上的状态。

实现上有两种常见方式：

方式一：轮询。每个 Agent 定期检查黑板，看触发条件是否满足。简单但浪费资源，而且有延迟。

方式二：事件驱动。黑板状态变化时，主动通知相关 Agent。效率高，但需要维护订阅关系。

我实际项目里更常用事件驱动，因为轮询在 Agent 数量多的时候开销太大。具体做法是：黑板维护一个"状态-订阅者"映射，某个状态更新时，只通知订阅了该状态的 Agent。

class Blackboard: def __init__(self): self.state = {} self.subscribers = {} # state_key -> [agents] def subscribe(self, state_key, agent): self.subscribers.setdefault(state_key, []).append(agent) def update(self, state_key, value): self.state[state_key] = value for agent in self.subscribers.get(state_key, []): agent.notify(state_key, value)

4.3 黑板架构的面试话术

如果任务模块之间耦合松、可以并行、没有强依赖顺序，可以这样答：

"这个任务我倾向用黑板架构。设一块共享黑板存放中间状态，每个 Agent 订阅自己关心的状态，状态满足触发条件就主动执行，结果写回黑板。这个架构的好处是解耦彻底，加新 Agent 不用改调度逻辑，扩展性强；代价是控制流不直观，调试困难，而且容易出现多个 Agent 同时抢同一个活的问题，需要加锁或者状态标记。"

4.4 黑板架构的坑：并发冲突和死锁

并发冲突是黑板架构最常见的问题。两个 Agent 同时看到"待处理数据"，同时开始处理，结果重复劳动甚至互相覆盖。解法是给黑板状态加"处理中"标记，Agent 动手前先抢占，抢到才干活。

死锁是另一个坑。Agent A 等 Agent B 的输出，Agent B 等 Agent A 的输出，互相等，永远不动。解法是设计状态依赖时保证无环，或者加超时机制，等太久就放弃并报警。

我踩过一次死锁的坑：清洗 Agent 等特征 Agent 的反馈来调整清洗策略，特征 Agent 等清洗 Agent 的输出才能开始，结果两个都不动。后来改成清洗 Agent 先出一版结果，特征 Agent 基于这版先跑，跑完反馈给清洗 Agent 做二次优化，才打破死锁。

5. 层级架构：大团队怎么管

5.1 层级架构的适用场景

层级（Hierarchical）架构是主管-下属的"多层版"。当 Agent 数量多到几十个，一个主管管不过来时，就要分层：顶层主管管几个中层主管，每个中层主管管几个执行 Agent。

这种架构适合超大规模、任务层次深的场景。比如一个完整的软件开发流程，顶层是"项目经理 Agent"，下面分"需求组""开发组""测试组"，每组再有自己的主管和执行 Agent。

5.2 层级架构的关键设计

层级架构的核心是信息逐层汇总和任务逐层分解。

任务分解是自上而下的：顶层主管把大任务拆成几个中任务，分给中层主管；中层主管再把中任务拆成小任务，分给执行 Agent。

信息汇总是自下而上的：执行 Agent 把结果给中层主管，中层主管汇总后给顶层主管，顶层主管做最终决策。

这里的关键是每层只关心自己这一层的信息。顶层主管不需要知道每个执行 Agent 的细节，只需要知道"开发组完成了没有、质量如何"。这样每层的上下文都不会爆炸。

5.3 层级架构的面试话术

如果任务规模大、层次深，可以这样答：

"这个任务规模比较大，我倾向用层级架构。顶层设一个总协调 Agent，下面按职能分几个组，每组一个组长 Agent 带若干执行 Agent。任务自上而下逐层分解，结果自下而上逐层汇总。关键设计点是：每层只暴露摘要级信息给上层，详细数据存在下层，避免上层上下文爆炸；同时每层要有独立的失败处理，下层失败不能直接拖垮上层。"

5.4 层级架构的坑：层数不是越多越好

层级架构最大的诱惑是"无限分层"，但每加一层，通信开销和延迟就翻倍。我的经验是：三层基本够用，超过三层就要重新审视任务分解是否合理。

另外，层级架构容易出现"信息失真"：执行 Agent 的真实情况经过几层汇总后，到顶层主管那里已经变味了。解法是给关键信息加"直通通道"，比如严重错误可以越级上报，不用一层层传。

6. 四种架构怎么选：一张表说清楚

面试时最容易被追问的是"你为什么选这个架构"。我把四种架构的对比整理成表，方便你快速判断。

选型的基本原则是：能用简单的就别用复杂的。任务线性就流水线，有总分结构就主管-下属，模块松耦合就黑板，规模大就层级。很多面试者一上来就说"我要用层级架构"，结果任务本身很简单，反而显得不懂取舍。

7. 面试现场：从"背架构"到"讲取舍"

7.1 面试官真正想听的三层回答

我观察下来，多 Agent 架构这道题，回答分三个层次：

第一层：能说出架构名字和基本特征。这是及格线，但只答到这层，面试官会觉得你只是背过书。

第二层：能说清每种架构的适用场景和取舍。这是良好线，说明你理解架构背后的设计逻辑。

第三层：能结合具体任务给出选型建议，并预判可能的坑。这是优秀线，说明你真干过。

大部分人卡在第一层到第二层之间。突破的关键是：每讲一个架构，都主动说它的代价。比如讲主管架构，主动说"主管可能成为瓶颈，我会用摘要级信息+外部存储来缓解"。这种"我知道它的缺点"的表达，比单纯夸优点有说服力得多。

7.2 一个完整的回答示例

假设面试官问："设计一个自动写代码的多 Agent 系统，你怎么架构？"

可以这样答：

"我会用主管-下属架构，因为写代码这个任务有明显的总分结构。顶层一个主管 Agent 负责理解需求、拆解任务、调度下属。下面挂几个专职 Agent：需求分析 Agent 负责把模糊需求转成明确规格，编码 Agent 负责写代码，测试 Agent 负责跑测试，修复 Agent 负责根据测试结果改代码。

主管的核心逻辑是：先派需求分析，拿到规格后派编码，编码完派测试，测试不过派修复，修复完再测，循环直到通过或达到最大轮次。这里我会设两个保护：一是最大迭代轮次，防止无限修；二是每轮把测试报告摘要给主管，详细日志存外部，避免主管上下文爆炸。

为什么不选流水线？因为写代码需要反复迭代，测试不过要回退到编码，流水线的单向依赖处理不了。为什么不选黑板？因为写代码的依赖关系比较强，编码必须在需求分析之后，用黑板反而增加协调成本。"

这个回答的完整度在于：有选型、有理由、有细节、有取舍、有保护机制。面试官听完基本能判断你干过真活。

7.3 面试中的高频追问及应对

追问一："Agent 之间怎么通信？"

答：结构化消息为主，自然语言为辅。关键数据用 JSON schema 约束，保证可解析；需要传递语义信息时用自然语言，但要求简洁。通信方式上，同步调用简单但阻塞，异步消息灵活但复杂，看场景选。

追问二："怎么保证 Agent 输出质量？"

答：三层保障。一是提示词约束，明确输出格式和标准；二是自动校验，用规则或另一个 Agent 检查输出；三是人工兜底，关键节点留人工审核入口。

追问三："Agent 失败了怎么办？"

答：分类型处理。可重试的（如网络超时）自动重试；不可重试的（如逻辑错误）打回上游或终止；连续失败的熔断并报警。关键是每个 Agent 都要有明确的失败语义，不能默默失败。

追问四："怎么评估多 Agent 系统的效果？"

答：看三个指标。任务完成率（最终有没有做出来）、效率（耗时和 token 消耗）、质量（输出是否达标）。对比单 Agent 基线，看多 Agent 是否真的带来了提升，还是只是增加了复杂度。

8. 我在实际项目里踩过的几个坑

8.1 坑一：Agent 数量不是越多越好

刚开始做多 Agent 系统时，我有种"多拆几个 Agent 总没坏处"的错觉。结果一个任务拆了 8 个 Agent，协调开销比干活还大，整体耗时反而比单 Agent 长。

后来我定了个原则：每个 Agent 必须能独立说清楚"我负责什么、我的输入是什么、我的输出是什么"。说不清楚的，要么合并，要么砍掉。一般一个系统 3-5 个 Agent 是比较舒服的区间。

8.2 坑二：提示词里的"角色扮演"要克制

给 Agent 写提示词时，很多人喜欢写一大段角色设定："你是一位资深的、经验丰富的、严谨的……"。实测下来，这种冗长的角色描述对输出质量提升有限，反而占用了宝贵的上下文。

我的做法是：角色描述一句话带过，重点写清楚"职责边界"和"输出格式"。比如"你是检索员，负责搜集资料，输出 JSON 格式的文档列表，每篇包含标题、正文、来源"。简洁明确，比华丽的人设有用得多。

8.3 坑三：别忘了给系统加"刹车"

多 Agent 系统最容易失控的地方是循环。主管不停派任务、Agent 不停重试、黑板不停触发，最后 token 烧光、时间耗尽。

我现在做任何多 Agent 系统，第一件事就是加刹车：

• 全局最大轮次限制
• 单个 Agent 最大重试次数
• 总 token 预算上限
• 总耗时上限

超过任何一个阈值，系统强制停止并输出当前最好结果。这个"刹车"机制在面试里也是加分项，因为它体现了你的工程思维。

8.4 坑四：日志和可观测性要一开始就做

多 Agent 系统的调试难度是单 Agent 的好几倍。如果一开始不做日志，出问题根本不知道是哪个 Agent、哪一步出的错。

我的做法是：每个 Agent 的每次调用都记录输入、输出、耗时、token 消耗。主管的每次决策也记录。这样出问题时，能完整回放整个协作过程，快速定位。

9. 写在最后：架构是手段，不是目的

聊了这么多架构，最后说个可能有点反直觉的观点：面试时不要急着秀架构，先想清楚任务本身。

我见过不少候选人，一上来就说"我要用层级架构加黑板机制"，结果任务本身只是个简单的线性流程，用流水线就够了。这种"杀鸡用牛刀"的回答，反而暴露了不懂取舍。

真正的高手，是能根据任务特点，选出刚好够用的架构，并且清楚地说出为什么不用更复杂的方案。这种"克制"背后，是对每种架构代价的深刻理解。

多 Agent 系统这几年确实火，但它的本质没变：用多个简单单元的组合，解决单个复杂单元搞不定的问题。架构只是组合方式，核心还是任务分解和协作机制。把这两点想透，面试怎么问都不慌。

如果你正在准备这类面试，建议拿一个自己熟悉的场景，把四种架构都套一遍，想想每种架构下任务怎么拆、Agent 怎么通信、失败怎么处理。练上三五个场景，基本就能应对大部分追问了。