多Agent系统面试全解析：4种经典架构与代码骨架详解

多Agent系统这几个字现在已经是大模型方向面试的必考钉子户了。我这几轮技术面下来发现不管岗位写的是应用工程师、算法工程师还是架构师面试官总会绕到同一个话题——你了解多Agent系统吗有没有设计过多Agent架构。第一次被问到的时候我也差点卡壳后来把做项目时的方案复盘了一遍才发现面试官真正想知道的东西其实很固定。这篇文章我准备把4种经典的多Agent架构连同它们的适用场景、代码骨架、常见追问一次性讲清楚。如果你正在准备大模型应用方向的面试或者刚准备给产品引入多Agent能力但不知道从哪下手这篇可以直接拿去用。没有绕来绕去的大词全是能落地、能开口讲的干货。1. 面试官问多Agent系统表面问架构实际问什么1.1 多Agent系统为什么成了大模型岗位的必考题先说个判断面试官问多Agent绝对不只是问你知不知道这个概念而是把它当成了一把尺子用来量你的工程能力、系统设计能力和对LLM应用的理解程度。原因不复杂。现在的企业级大模型应用早就不是单个Prompt调来调去就能撑住的阶段了。真实业务里的任务往往很长、很杂涉及多个知识域、多步操作甚至需要多个模型或工具配合。比如一个客服机器人要同时处理退款、物流、产品咨询、投诉升级这些子任务对Prompt的要求完全不同混在一个Agent里做上下文互相污染指令一多就乱。所以业界的普遍做法就是把系统拆成多个Agent不同Agent各自负责一个领域再通过一套机制让它们协作。面试官在这个问题背后实际考察的是三件事有没有真实落地的经验。说的细节是否具体能不能说出踩过的坑一听就能分辨是背资料还是真做过。有没有系统设计的意识。多Agent不是写几个Agent类就行角色边界、通信方式、失败处理、成本控制这些都要有通盘考虑。有没有成本与效果权衡的判断力。架构选型不是越复杂越好关键看场景值不值得。如果你答的时候能往这三方面靠面试官心里的评分就已经上去了。1.2 先分清边界什么样的问题才值得多Agent上场很多同学一听到多Agent就兴奋觉得什么任务都能拆成几个Agent来显得高级。这是面试大忌。面试官只要追问一句你这个场景为什么不能一个Agent加几个工具解决站不住脚的回答当场就露馅。我自己现在判断是否上多Agent只看三个条件你可以直接拿去用任务本身是否包含多个独立性较强的子任务。例如同时需要查技术资料、查市场价格、查用户反馈这些子问题不共享上下文可以并行拆开才划算。是否要求不同角色视角。比如一份方案既要技术可行性评估又要商业成本评估还要安全合规评估单Agent很难同时扮演好这么多角色。是否有结果验证需求。当答案的准确性直接影响业务结果时靠多个Agent互相质疑来降低出错率这条路子是成立的。如果三个条件一条都不占那就老老实实用单Agent加工具。面试时主动说这个场景我用单Agent就够了反而会让面试官觉得你懂取舍。1.3 五段式答题框架从开场到落地一次说清准备多Agent面试题时最忌讳的就是背答案式的干讲架构。你要有一个能覆盖所有追问的答题骨架不管面试官从哪切入你都能拉回到这条主线上。我自己总结的框架是五段式场景先行。先给一个具体业务场景说明任务为什么复杂、单Agent为什么搞不定。没有场景谈架构就是空中楼阁。角色定义。明确系统里有哪几个Agent每个Agent的职责、输入、输出是什么边界在哪里。协作模式。说明采用哪种架构为什么是这个架构各Agent之间是调度关系、流水线关系还是平等讨论关系。通信与状态。说明消息怎么传、中间结果放哪、上下文怎么隔离、怎么避免信息丢失。容错与评估。说明某个Agent挂了怎么办调用失败了怎么办以及上线后怎么评估效果是否达标。不管面试官问你讲讲多Agent还是问你给我设计一个多Agent系统你都可以用这五段来组织语言。顺序稳定信息密度高还显得思路特别清楚。2. 4种经典多Agent架构场景拆解代码骨架2.1 中心化调度架构Supervisor-Worker这是最经典、面试中出现频率最高的一种架构也是绝大多数真实系统的首选。核心思路很直白有一个主管Agent负责接收任务、拆解任务、分配给不同的工人Agent执行最后汇总结果。工人Agent之间一般不直接通信所有消息都经过主管中转。它就像一支项目团队项目经理接需求、分活、收活开发人员只管把自己手里的模块做完交回去。这种架构的适用场景非常明确任务类型多、但每个子任务可以相对独立地处理。我给你举一个我做过的最典型的例子——智能客服工单系统。用户提交一个售后问题里面可能同时涉及订单状态、物流进度、退款规则。如果一个大模型Agent全包很容易在三个领域之间来回横跳角色一会儿是物流专家一会儿是售后专家输出质量肉眼可见地下降。拆成多个Worker之后物流Agent只调物流接口、订单Agent只查订单系统准确性高很多。代码骨架大概是这个风格class SupervisorAgent: def __init__(self, workers): self.workers workers # {物流: agent_a, 订单: agent_b, ...} def run(self, task): plan self.plan(task) # 1. 主管拆解子任务 results {} for name, sub_task in plan.items(): worker self.workers[name] results[name] worker.run(sub_task) # 2. 分发并执行 return self.merge(task, results) # 3. 汇总并生成最终答案别看代码短面试时你能把这个逻辑讲透就够用了。你需要重点讲清楚的是主管Agent的拆解策略和结果合并策略。拆解策略最常见的做法是让主管Agent先做一次意图识别输出一个JSON结构里面包含子任务列表和对应的Agent编号合并策略则是让主管Agent看到所有子结果之后再做一次统一生成避免多个Worker各自说各自话。这种架构的优点是好理解、好控制、权限清晰业务上需要审批或风控的位置天然适合放在主管节点。缺点也明显主管是单点一旦它判断失误整个系统跟着错任务量大了之后主管还要承担海量信息汇总上下文容易超长。2.2 流水线架构Pipeline流水线架构在面试里属于看起来简单但很容易答浅的类型。你得讲出它的适用边界才能拿高分。核心思路就是把一个完整任务切成一串有序阶段每个阶段由一个Agent负责上一个Agent的输出是下一个Agent的输入像工厂流水线一样一个工位接着一个工位往下走。最典型的场景是内容生产流程选题Agent先根据热点和用户画像出一个选题方向大纲Agent接着生成结构化大纲初稿Agent按大纲写成完整内容润色Agent再调整语气和表达最后校对Agent检查错别字和事实性错误。每一步只负责一件事Prompt可以写得很专注输出质量确实比一个Agent从头写到尾更稳定。代码骨架比中心化还简单def run_pipeline(task, stages): current task for stage in stages: current stage.agent.run(current) current stage.validate(current) # 每个阶段出口做校验 return current这里有一个很重要的面试加分点千万别把流水线说成依次调用一下就完事。你要强调每个阶段的出口校验也就是对上一层输出做格式检查、关键词检查或质量打分不满足条件就触发本Agent重写。这代表你有工程上的兜底意识面试官最吃这一套。流水线的优点是结构清晰、每个环节都能独立测试和优化出了问题很容易定位到是哪个环节。缺点是从头到尾延迟是累加的中间任何一环卡住后面全部停工而且它不适合需要反复来回调整的创造性任务。比如写报告大纲阶段定了方向到了润色阶段才发现方向偏了想回头改这时候流水线就尴尬了因为它根本不会回头。2.3 辩论/对抗验证架构Debate这是一种比较有炫技性质的架构但我建议每个准备面试的人都掌握因为它非常能体现你对LLM能力边界的理解。核心思路是针对同一个问题让多个Agent扮演不同角色或持有不同立场各自独立给出答案然后互相看到对方的答案并提出质疑多轮之后由裁判Agent或者投票机制选出最终结果。这个机制本质上模拟了人类团队里的互相挑毛病一个人单独写代码容易写错但两个人互相code review问题暴露得快得多。最适用的场景是高风险、高精度要求的任务。比如代码审查、事实核查、合同条款检查、产品方案评审。以代码审查为例你可以让一个Agent扮演实现者写代码另一个Agent扮演攻击者专门找漏洞第三个Agent扮演性能专家评估效率最后让裁判Agent综合三方观点给出修改建议。这种多角色对抗出来的结果通常比单个Agent的自问自答靠谱得多因为LLM在同一段上下文里又当运动员又当裁判立场很难真正分开。它的代码骨架比前两个复杂一点核心是多轮往返 收敛机制class DebateSystem: def __init__(self, debaters, judge): self.debaters debaters self.judge judge def run(self, question, max_rounds3): views {name: agent.run(question) for name, agent in self.debaters.items()} for _ in range(max_rounds): transcript .join( f{name}: {view}\n for name, view in views.items() ) for name, agent in self.debaters.items(): # 每个Agent看到别人观点后输出反驳或补充 views[name] agent.run(question \n其他人的观点如下请质疑其中漏洞\n transcript) return self.judge.run(question, views)面试官如果对这个架构感兴趣大概率会追问辩论什么时候结束和怎么保证收敛。你提前准备答案设定最大轮数防止死循环式互怼每次Agent输出观点时必须给出对上一轮其他观点中你同意什么、反对什么的明确说明最后汇总时采用投票或裁判裁决不追求完全一致的共识只要求在预设轮数内产生最优结果。这个架构的缺点也必须要主动说Token消耗大概是单Agent的几倍响应时间变长而且如果辩论双方模型能力不对等弱的那一方容易变成你说得对的复读机。面试时主动点出这些成本显得你思考过落地不只是在背理论。2.4 分层/混合架构Hierarchical/Hybrid前三种架构讲完面试官如果还愿意继续聊大概率会抛出那个经典问题如果你面对的场景特别复杂呢这时候你就要亮出第四种架构分层/混合架构。它不是一个单一模式而是根据任务真实结构把前面几种模式组合成树状或网状的系统。上层Agent负责粗粒度拆解下层Agent在各自范围内再使用适合的协作方式。生活里最接近的类比是公司的组织架构总公司只管战略和资源分配不干涉具体执行事业部接到任务后在自己范围内决定是走项目制还是流水线式推进到了项目组这一层还可以开评审会来验证方案质量。每一层有每一层的分工不必强求全公司用一种管理方式。我举个实际例子你就知道这种架构的威力了。比如设计一个行业研究报告自动生成系统顶层主管Agent接到生成医疗行业报告这个任务后先做粗拆分数据处理、内容撰写、图表设计、质量审校。数据处理Agent内部其实可以走流水线——先采集、再清洗、再分析、再出表内容撰写Agent内部也可以用辩论模式让市场分析师、医学顾问、编辑三个角色反复打磨图表设计Agent则相对独立直接按数据和结论生成图表。最后所有结果汇聚到顶层主管做统稿。这种架构的价值在于每一层都只用解决自己那一个复杂度级别的问题整体系统才有能力承接真正的企业级任务。代码层面没有统一的骨架因为本质上是组合。面试时不用写完整代码做一个伪代码级的过程描述就够了top_supervisor拆解出子任务 for 每个子任务: 分发给对应子系统的入口Agent 子系统内部自行决定协作模式 最终由top_supervisor汇总所有子系统的输出分层架构的优点是好扩展、能并行、单点故障的影响面可控。缺点是链路长、调试难、通信成本高对可观测性要求极高。面试讲到这个的时候一定要主动提一句所以我在分层系统里一定会给每次请求分配全局Trace-ID每层处理日志都带上这个ID否则出了问题根本没法定位这句话能让你和只会画架构图的候选人明显区分开。2.5 一张表搞定架构选型面试选型回答金句我建议你把这四种架构的对比表记在脑子里面试官问你什么时候用哪种的时候你直接按这个表去套架构核心特征最适用场景最大优势最大风险中心化调度一个主管拆派汇多样性任务、权限要求高的业务控制力强流程清晰主管成为单点流水线顺序执行、层层接力固定流程、步骤依赖强简单稳定、易定位问题延迟累加、无法回头辩论/对抗多角色互评、判决汇总高风险、高准确率要求准确率更高、暴露盲区成本和耗时成倍增加分层/混合多种模式组合复用企业级复杂系统弹性强、容量大调试和观测成本高选型的时候还有一个能直接搬的表达模板这个任务有两个特点一是子任务依赖顺序强二是偶尔有高风险节点所以我会用流水线做主链路在关键节点引入一个辩论Group做结果校验。这种组合式选型的表述比你干巴巴地说我用的是分层架构高级很多因为它体现的是你真正在思考任务的本质。3. 面试官高频追问怎么接6个问题应对思路3.1 不能只说架构名高频追问逐个拆解面试官几乎不可能在你讲完架构之后不追问。我整理了出现频率最高的6个追问每个都附上应对思路。追问一多个Agent输出矛盾怎么办这几乎是必问的。不要回答不会矛盾这种傻话多Agent系统天然会产生冲突。回答思路分三步第一定义仲裁机制通常有一个汇总节点或裁判Agent来做优先级决策第二在角色定义阶段就声明各Agent的权威边界例如涉及退款金额以财务规则Agent的结论为准其他Agent不得推翻第三如果矛盾来自事实层面引入知识库或工具查询作为唯一事实源而不是让Agent继续吵。追问二某个Agent挂了怎么办这个追问考察工程兜底意识。你得先说监控每个Agent调用都有超时设置超过阈值就标记失败再说降级如果替代的Agent不存在就直接调用一个快速处理的备选Prompt或者走固定规则最后说隔离一个Agent失败不影响其他Agent的结果未完成的部分用默认值或人工介入。能完整说出这三层基本就过关了。追问三上下文太长中间结果放不下怎么办这是多Agent系统最现实的工程问题。建议回答第一每个Agent保留自己的独立上下文不把全量中间结果传给下游而是传压缩后的结构化摘要第二中间结果落库用任务ID关联下游Agent按需取出而不是靠上下文传递第三对长文本做摘要或向量化检索只把相关的部分塞进Prompt。这套说法在真实项目里完全行得通面试官也最能共鸣。追问四怎么控制成本和延迟多Agent系统最被人诟病的地方就是成本。我的回答模板是按任务难度分级选模型简单分类任务用轻量模型复杂创作才用最强模型能并行的Agent就并行调用把整体时间压下去对高频重复的子任务加一层缓存同时记录每个任务的Token消耗和延迟异常飙升时告警。追问五为什么非要多个Agent不用一个Agent加工具这个追问其实是挖坑看你会不会为了炫技而过度设计。你应该大方承认如果一个Agent加工具能搞定我绝不会用多Agent。多Agent只在任务存在强角色分裂、需要并行验证、或上下文会互相干扰的时候才上。能这么回答的人面试官才会相信你真的做过选型。追问六多Agent跑飞了怎么停下来有经验的面试官会问得很工程化。你可以说所有Agent之间的通信都走一个控制层控制层里设置最大调用次数、最大耗时和结果校验函数校验不通过就终止并返回最近一次的有效结果对抗类型的系统则用最大轮数硬限制。这代表着你对失控风险有预案属于加分表现。3.2 把真实项目讲成系统设计题STAR模板实战如果你被问介绍一个你做的多Agent项目千万不要平铺直叙我用了什么框架搭了一个是什么的系统。面试官要的不是产品发布会是你做设计决策的过程。我常用的讲述框架是STAR变体但顺序要调整成合面试口味场景一句话说明业务背景和痛点。例如我们做一个售后工单系统此前用单Agent处理遇到混合问题经常答错转人工率一直很高。任务一句话定义你的目标。例如把常见售后问题的自动化解决率从55%提到75%以上同时控制单次请求成本在0.01元左右。设计决策这部分占70%的篇幅。不要只讲我用了中心化架构要讲你比较过什么方案、为什么选了它。可以说我对比过流水线和中心化调度最后因为用户工单的子任务之间没有强顺序关系、但类型很杂所以选了中心化主管先分类再分发。结果与反思给出量化结果说清楚用了哪些指标。然后主动补一个不足当时没做足够的降级方案某个Agent模型服务不稳定的时候整条链路会卡住后来加了超时和兜底Prompt才解决。这个模板最大的好处是不管你做的项目规模多小只要决策过程是真的讲出来都像模像样。面试官想听的从来不是你做过多少牛逼系统而是你有没有一套稳定的思考方式去面对未知问题。4. 实战避坑与加分细节从能用到说得漂亮4.1 设计多Agent系统最容易踩的5个坑我自己最早做多Agent的时候几乎把所有坑都踩了一遍。挑5个最常见的提醒你面试时主动说出这些坑比背一百条理论都加分。第一个坑为了多Agent而多Agent。一个任务明明不复杂硬拆成四五个Agent光是协调它们就花掉大量Token和时间最终效果还不如单Agent。解法就是在拆之前先自问三遍这个子任务自己是否有独立判断的价值。第二个坑角色定义只写了一句你是一个负责XX的Agent。这是最大的隐患。两个Agent的职责边界写不清楚任务一来就开始抢活或互相推。我后来强制要求每个Agent必须有三个文档职责说明、输入Schema、输出Schema。输出必须是一个合法JSON字段写死这样下游Agent才好解析。第三个坑所有Agent共用一个Context。曾经为了省事我让多个Agent共享同一个聊天上下文结果A的中间输出污染了B的判断系统越跑越乱。这事之后就坚持一个原则每个Agent的上下文必须隔离Agent之间只通过结构化消息传递信息绝不把原始聊天记录整个丢给对方。第四个坑完全没有超时机制。最初的系统只要一个Agent调用超时整条链路就卡死用户体验就是机器人已读不回。后来统一加上了超时、重试和降级三步超时自动重试一次再不成功就走兜底规则或者转人工。第五个坑没有评估就直接上。多Agent系统的表现受Prompt影响很大调一个人的输出很稳人一多就不可控。我现在任何多Agent系统上线前必须准备一个最小评测集一般50到100条典型任务每次改动架构都要跑一遍看整体通过率的变化。面试提到这个习惯会被认为工程素养很高。4.2 面试过程中最能拿捏面试官的3个加分细节最后分享3个我在面试时亲测有效的加分细节全是我从实际答辩经验里总结出来的。加分细节一主动画通信流程。面试官让你讲架构时不要只靠嘴说。你可以说我习惯把通信流程拆成三步来描述用户请求到达入口、入口解析任务类型、然后按类型走对应链路……边说边在白板上画箭头和方框。能画出清晰流程图的人面试官默认你是真想清楚了的哪怕白板画画水平一般也比干说强。加分细节二主动给成本估算。讲完架构后补一句成本账杀伤力很大。你可以说按这个方案估算一次复杂工单处理大概要调用6次模型最强模型的Token消耗大概4000到6000成本大约在几分钱量级相比人工处理还是划算的。这句话一出来面试官会立刻从他懂架构升到他懂落地。加分细节三主动承认边界和反例。不要把自己的方案说成全能的。你补一句这种架构有一个明显的缺点就是中心化调度主管模型一崩全崩所以如果稳定性要求极高我也会考虑在主管层做双模型备份或者降级到规则路由这种带边界的表达远比我这个方案很完美可信。说点我自己的感受。面试这东西架构名称背得再熟也只是一层壳面试官真正想验证的是你有没有在真实项目里被多Agent的问题毒打过。所以我建议你别只盯着这4种架构的结论而是找个小任务自己搭一遍拆一拆、跑一跑把中间产物打出来看看哪怕做个最小Demo都行。我自己就是被线上系统的各种幺蛾子折磨过之后再去看这些架构理论才真正明白它们各自在为哪些实际问题兜底。最后再分享一个小技巧面试前把你做过的多Agent任务整理成两三张输入输出截图 一次完整链路日志面试时随手翻开讲细节那比什么模板话术都管用。