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 拿到写一份行业调研报告的任务后先拆解成子任务搜集资料、分析竞品、整理数据、撰写报告把搜集资料派给检索 Agent拿到结果后判断资料够不够不够就再派一轮资料够了派给分析 Agent分析完派给撰写 Agent最后自己汇总、检查、输出主管 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 怎么通信、失败怎么处理。练上三五个场景基本就能应对大部分追问了。 
长河君 · 2026/10/22 15:55:18 · 阅读 1.2k 多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 拿到写一份行业调研报告的任务后先拆解成子任务搜集资料、分析竞品、整理数据、撰写报告把搜集资料派给检索 Agent拿到结果后判断资料够不够不够就再派一轮资料够了派给分析 Agent分析完派给撰写 Agent最后自己汇总、检查、输出主管 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 怎么通信、失败怎么处理。练上三五个场景基本就能应对大部分追问了。