1. 为什么面试官会对多 Agent 系统“打破砂锅问到底”先聊个现实场景。你在面试一家做 AI 应用的公司聊完项目和基础八股之后面试官突然抛出这么一句“你说你做过 Agent那你了解多 Agent 系统吗能不能讲讲你站在架构师的角度会怎么设计一套多个 Agent 协作的系统”这一句话其实是一个“高阶筛子”。很多人一听“多 Agent”就以为是在问 LangChain、AutoGen 怎么用其实面试官真正想考察的东西至少有四层你知不知道多 Agent 系统是干嘛的它解决单 Agent 解决不了的问题你有没有真正拆解过一个系统而不只是调过几个框架 API你知不知道常见的系统形态有哪些各自的优缺点和适用场景是什么你有没有踩过跨 Agent 协作的坑比如死锁、重复劳动、上下文漂移、最终一致性这些实战问题。换句话说面试官不怕你不会怕的是你把简历上的“多 Agent 项目”吹得天花乱坠结果问两句就露馅。这篇文章想做的事情特别简单把我在面试和实际项目里反复会用到的四种经典架构整理成一套可以“当场讲出来”的答题框架。你如果能把这四种架构理解透了再配合文章后半段给的话术模板和追问应对思路面试时遇到多 Agent 相关的题目基本不会有盲区。那四种架构分别是黑板架构、编排器-工作者架构、谈判式协作架构、分层式架构。别急着背名词每种架构我都会先讲它的核心思想再讲面试时应该怎么开口讲最后讲它容易踩的坑。这样你背下来的不是答案是理解。2. 四个名字背后的本质区别先分清“查字典”和“开会讨论”在展开每一种架构之前你先想清楚一件基础的事多 Agent 系统到底在解决什么单 Agent 也好普通程序也好本质上是一个“输入 → 处理 → 输出”的管道。但到了真实场景里你会发现很多任务根本没法定死成一条管道。举个例子你给我一段需求文档让我写一份部署方案。这件事可能要查资料、可能要拆解文档、可能要画架构图、可能要评估风险和成本而且这几件事之间还有依赖关系——先查完资料才能画图画完图才知道哪些资源不够资源不够又要回去改方案。如果用单个 Agent 硬干模型上下文窗口有限做完第一步忘了第二步而且所有知识都堆在同一个上下文里最后输出的东西很容易“前后打架”。多 Agent 系统把一个大问题切成若干小问题让每个 Agent 负责一个子任务专精一点再用一套机制把各自的结果拼起来。这个“切成多少块”“每块谁负责”“大家怎么协同”就是架构问题。四种经典架构的本质区别其实可以类比成现实里几种团队协作方式架构类比协作风格系统形态黑板架构进入一间屋子所有人都能往黑板上写/擦谁看见信息就继续处理共享空间 去中心化无中心调度编排器-工作者项目经理把任务拆成工单分给不同岗位的工程师收齐结果再汇总中心化 任务分发单一调度者谈判式协作几个专业顾问各执一词互相提意见、质疑、修正最后达成共识去中心化 冲突消解平级互动分层式架构前台接待 → 部门主管 → 具体执行人逐级往下派活信息逐层过滤层级递进 逐级抽象上下级关系每种架构都有它的适用面面试时你要能说出“我为什么在这种场景选这种架构”这才是加分项。2.1 黑板架构团队在一面大黑板前共同解题黑板架构的核心思想特别朴素有一个共享的“工作区”多个 Agent 在这个工作区里协同完成一个复杂任务。每个 Agent 都可以往黑板上写东西也可以读取黑板上已有的内容看到与自己职责相关的信息时它就主动接手处理处理完把新结果写回黑板。这个架构最早是从传统人工智能的黑板系统演化来的那会儿做语音识别、图像理解的系统就是这么干的一个模块负责提取音素一个模块负责识别单词一个模块负责语法分析大家都在黑板上交互。放到今天的多 Agent 架构里黑板的“实体”可以是数据库、向量索引、消息队列、共享内存甚至是一份结构化文档。面试时怎么讲你可以这么说“我理解的黑板架构核心是去中心化共享空间。比如我做过的一个项目里需要让多个 Agent 协作分析一份技术文档我先梳理出一个标准化的信息黑板里面划分了目标、约束、发现、结论几个区域。不同 Agent 按自己的职责去读、去写。研究员 Agent 把检索到的资料写到‘发现’区分析 Agent 读取资料后更新‘约束’区最后规划 Agent 参考所有区域生成行动建议。整个过程没有固定的调用先后顺序谁准备好谁就处理灵活性非常高。”这么打样可以体现出两个关键认知一是“黑板上应该写结构化格式”要不可能写的和读的理解不一致黑板的格式约定本身就是一套协议二是“没有中心调度者不代表没有规则”区域划分、读写权限、冲突合并策略都是架构师设计师给的。什么场景适合任务本身的子任务之间没有一定顺序天然是“看到什么处理什么”的流水线子任务类型多样化每个 Agent 各自有专业领域不好由中心来精确调度系统需要长期运行某个 Agent 挂掉后其他 Agent 可以把它的未完成部分接力下去。对应的话术和坑“黑板架构适合那种解耦性要求高、多 Agent 并发的场景。但是有个明显的坑共享状态如果写乱了整个系统就乱了。你得给黑板设计一套带版本管理的写入协议每个人只能写自己的区域或者只能通过消息队列来写入不能直接改别人的结果。”面试官如果追问“黑了之后怎么处理”你可以接“我会用事件驱动的方式做更新——黑板本身不存复杂状态它只是一个消息总线的落盘视角真正的业务状态放在各自的 Agent 内部。这样就算某个 Agent 崩溃了重启起来看一遍自己感兴趣的消息就恢复了。”这里有个细节值得注意纯黑板架构在真实系统里很少全量落地因为容易出现“多个 Agent 同时读一个数据然后各自产生新结果”的重复计算问题。所以实战中往往会加一点“抢占式”标记Agent 处理前先声明“这块我在处理”处理完再解锁。面试时你主动说出这种优化反而比背定义高级很多。2.2 编排器-工作者架构项目经理下令工程师干活如果说黑板架构是“去中心化的自由协作”编排器-工作者架构就是“有中心控场的任务分发”。这也是目前业界落地最多、最容易在项目里快速跑起来的多 Agent 形态。核心思路很清晰有一个编排器 AgentOrchestrator它接收用户的初始需求把需求拆成若干子任务再把子任务下发到不同的工作者 AgentWorker。每个 Worker 通常只负责一种专业能力比如代码生成、数据库查询、文档检索、报告撰写。Worker 执行完把结果回传给编排器编排器再做合并、校验、补充调用等后续动作甚至决定要不要再拆一轮子任务。面试时怎么讲“我当前这个项目用的就是编排器-工作者架构因为它最适合我们那种‘需求入口单一、子任务种类多样、结果要汇总统一输出’的场景。入口 Agent 先做意图识别拆解出用户请求包含哪几个步骤。比如用户说‘帮我调研一下某个市场方向并生成报告’我的编排器会把它拆成信息检索、数据整理、报告生成三个 Worker 任务。编排器逐个下发每个 Worker 只关注自己的子任务返回结构化结果。最后编排器统一合并写作形成最终报告。这样单个 Worker 的 Prompt 很短很聚焦准确度明显更高而且新增一种能力只需要加一个专用 Worker 类型不需要改动编排器的逻辑。”为什么很多人觉得编排器架构好上手因为它的流程天然像程序员脑子里“主函数调子函数”的模型调度是显式的状态是集中的出错时定位点很明确。面试官想要听到的不是“我用了 LangChain 的 AgentExecutor”而是你能讲清楚“编排器与 Worker 之间用什么协议通信”“各个 Agent 的输入输出定义是什么”这类问题。什么场景适合子任务边界明确、调用顺序相对固定的场景需要强流程控制每一步都有明确负责人调试成本要低想快速上线一套系统。对应的话术和坑编排器架构最经典的坑是编排器成了瓶颈。所有子任务都要经过编排器聚合一旦编排器输出格式不稳定后面所有 Worker 全部白跑。我遇到过一种情况Worker 正常返回结果但编排器在做汇总时把关键信息给截错了最后输出的报告内容全对但引用对不上。后面我加了“编排器只负责调度不负责改写业务内容”的约束汇总时只做格式标准化和证据拼接效果好了很多。另一个高频坑是任务拆解粒度。拆得太细一次交互要来回十几轮延迟和 token 成本都受不了拆得太粗每个 Worker 又变成全能 Agent没什么意义。我的一般经验是子任务拆到“这个 Worker 不需要读其他上下文就能独立完成的颗粒度”就可以停手拆不下去就算了不要为了“多”而拆。面试时你可以主动补一句经验“我实际操作下来编排器架构最好设计成轻量调度、重量执行的模式。编排器只负责理解用户意图和分配任务具体领域逻辑全放进 Worker。这样编排器 Prompt 比 Worker Prompt 简单得多Token 消耗也更可控。”2.3 谈判式协作架构不搞上下级大家靠说服第三种架构在面试里出现的频率越来越高因为很多面试官拿它来考你“有没有思考过 Agent 之间的冲突处理”。谈判式协作架构也叫辩论式架构、多角色博弈架构。它的特点是系统里没有单一主导者多个 Agent 对同一个问题会给出不同角度的观点然后通过一轮轮“你来我往”的讨论交换论据、质疑、修改自身立场最终逼近一个共识结论。典型场景包含让两个 Agent 分别模拟“利润导向”和“风险导向”视角去评估一个方案让一个 Agent 写方案、另一个 Agent 挑刺、第三个 Agent 做最终仲裁。这个架构解决的核心痛点是单个 Agent 生成的答案往往过于“顺着用户来”缺少批判性如果能让不同角色之间互相“抬杠”最终结论的鲁棒性和自洽性会明显提高。面试时怎么讲“我做过一个项目需要让 Agent 输出一份技术方案的决策建议。单个 Agent 输出容易片面所以我引入了谈判式协作。一个 Agent 扮演架构师负责正面阐述方案的优点另一个 Agent 扮演运维专家负责从故障风险、可维护性、监控成本上提出质疑还有一个小型仲裁 Agent收集两个立场的关键论据之后综合给出结论。整个过程会进行两到三轮交互每一轮两个专家 Agent 根据对方上一轮的论点修正自己的论据。相比单 Agent 直接输出最终方案里的盲区明显减少了特别是在风险和成本方面覆盖率提高了很多。”这种讲法有几个面试官会立刻抓住的钩子“两个 Agent 一直争论不完怎么办”对应策略是“最后一定有仲裁 Agent 或投票机制兜底”“它们的辩论会不会跑题”对应策略是“每一轮都要输出固定结构比如【本轮观点】【对对方的反驳】【修正后的立场】”“这样成本是不是翻了好几倍”对应策略是“只在关键决策点上启用辩论常规子任务不做”。什么场景适合决策类任务需要综合多个立场内容生成任务需要做事实核查和逻辑自洽高风险场景宁可多花推理成本也不允许出了错没人发现。对应的话术和坑“谈判式协作最大的问题不是效果而是成本。两个 Agent 辩论三分钟可能要调用几十次模型接口如果每一步还用长上下文那成本是线性甚至指数级上升的。我现在一般只让两个 Agent 最多辩论三轮而且每轮严格限制输出长度防止对话越滚越长。”还有一个很隐蔽的坑当两个模型基于同一个底座的时候它们的“辩论”经常在自说自话最后一轮反转只是因为提示词里写了“请修改你的立场”。这时候面试官如果追问“你的辩论和复读有什么区别”你就得承认这个问题并说出来——在真实场景里最终裁决靠的不是让模型说服另一个模型而是引入外部可信数据源比如代码执行结果、数据库统计结果、人工规则作为裁判依据。这个答案能把场面直接扳回来。2.4 分层式架构大系统里的纵向切分四种架构里分层式架构通常最容易和编排器-工作者架构混淆。它俩的区别在于编排器架构是“一个中心多个执行者”的辐射结构分层架构则是一层套一层的递进结构每一层负责不同抽象级别上一层往往定义“目标”下一层定义“怎么做”再下一层定义“具体执行动作”。你可以把分层架构理解为企业的正式组织架构董事会决定战略高管层解读战略分解为年度目标部门经理把目标拆成执行计划一线员工负责具体干。每一层都是下一层的入口也是上一层的出口。在技术实践里一个典型的分层多 Agent 系统可能长这样决策层 Agent接收用户模糊目标负责判断“该做什么”规划层 Agent接收决策层目标负责输出“分几步做”的计划执行层 Agent接收计划子项负责直接调用工具、写代码、查资料、出结果反馈层 Agent收集执行结果回溯校验是否达成了决策层的目标再把结论反馈给上层。面试时怎么讲“对于复杂业务系统我习惯把多 Agent 拆成分层结构。核心原因是不同层的职责和抽象级别差异太大——决策层考虑的是用户要什么规划层考虑的是要做什么执行层考虑的是具体怎么做把这些全部放到同一个调度循环里语义会互相污染。分层之后每一层的边界非常清楚也更容易做权限控制和单点测试。”单点测试这个词很关键。面试官一听就知道你理解“分层分的是抽象边界不是简单的前后顺序”。接着你可以补一句“分层架构还有个额外好处是容错。执行层的一个 Agent 挂掉我可以让执行层内部的替身 Agent 补位不需要打扰决策层如果是决策层需要换模型策略只需要改最上层下层完全不用动。”什么场景适合企业级应用面向复杂业务流需要考虑权限隔离、审计追踪的场景系统复杂到只靠一个编排器会变成“上帝 Agent”的情况。对应的话术和坑分层架构的坑也很典型——每一层之间如果都传递完整上下文越往下传输量越大最终你会发现下层 Agent 被灌了几千行上下文性能剧烈下降。实际工程里一般靠“信息浓缩”解决决策层输出只需要提目标规划层输出只需要提计划步骤执行层拿到的永远是被上层过滤后的精简上下文而不是上一层的全文对话。分层架构另一个坑是延迟很高。因为信息要一层层地传递、加工、再往上反馈用户等不起。实战中通常会采用“异步反馈”策略先把用户最关心的结果直接给出来后台再慢慢做精细化校验这跟 Web 开发里的“乐观更新”一个道理。你面试时能提出这种优化思路面试官会明显高看你一眼。3. 面试时的分层拆解四种架构各自怎么“讲出彩”很多求职者有个误区觉得自己只要能把四种架构的名字和定义背出来面试就够了。实际上如果面试官让你“介绍一下你的多 Agent 项目”你张口就把四种架构全倒出来反而会被认为是死记硬背。更聪明的答法是先讲清楚你项目的最核心场景然后说明对应选择的架构形态从形态延伸到特性再给出对比和取舍。这样做既展现了独立思考又不会被追问到“你干嘛不用另一种架构”的时候卡壳。下面摘出四段话术每一段都是可以临场改编的“答题模板”你直接替换成自己项目关键词就行。3.1 黑板架构的答题话术“在我上一版项目里我遇到了一个多 Agent 协作问题三个 Agent 同时处理同一批用户反馈需要一个公共工作区来共享标签和结论。我用了黑板架构公共区域是一个结构化表格每个 Agent 有独立的写入列读取别人的列前必须带上自己的版本号最后按版本号合并结果。这个方案的好处是单个 Agent 崩溃不影响其他 Agent黑色区还能做任务分区坏处是并发写冲突时要处理版本冲突系统增加了额外的重试逻辑。”这段回答为什么好因为引入了“版本号”这个工程细节。面试官一听就知道你不是拿一个玩具项目来糊弄的而是在真实环境里处理过并发问题。3.2 编排器-工作者架构的答题话术“我们现在的主力系统是标准的编排器-工作者架构。我负责设计了一个 Prompts 协议每个 Worker 只能接收 JSON 格式的任务参数和上下文输出也要按 JSON 里的固定字段返回编排器本身不带领域知识只负责拆任务、检查返回格式、组合结果。我在这套架构里加了一个 is_retriable 的标志位Worker 返回结果不合法时编排器会重试一次还不行就打进人工队列。上线后任务成功率从 91% 提到 98%延迟没有明显增加。”“固定 JSON 协议”和“重试标志位”属于架构落地的硬细节比单纯说“我用 LangChain 写的 Agent”高出几个段位。如果有面试官追问“为什么不用黑板架构”你就可以说“我们的子任务前后依赖很强需要确定性执行顺序编排器模式更适合黑板架构适合并发协作不适合强流程场景。”一个取舍直接把四种架构的边界也顺带交代了。3.3 谈判式协作架构的答题话术“我在做一个智能客服工单分析系统的时候用了谈判式协作但不是全局使用。只有高优先级投诉工单才触发两个 Agent——一个偏用户满意度一个偏风险合规——先各出各的报告第二轮互相指出对方遗漏的风险点最后由仲裁 Agent 按一个固定权重公式用户体验 40%、合规 40%、成本 20%给出最终标签和优先级。常规工单还是走编排器不对投诉工单做辩论这样既保住了准确率又控制了成本。”这段话术里最有价值的是“权重公式”。它告诉面试官你没有把辩论当成玄学来用而是设定了明确的仲裁规则系统是可解释的。3.4 分层式架构的答题话术“我有一个比较复杂的内部系统接入的场景达到十几个单靠一个编排器实在太重了。后来我拆成了三层入口决策层负责 session 管理和意图判断中间规划层把意图翻译成具体的任务清单底层执行层调用内部 API、数据库和第三方工具。结果返回时执行层只把简洁的结论上抛不把冗长的执行日志全部带上去。这样分层之后我们每个层的职责范围都不超过 5 个 Agent出了问题能很快定位到是哪个层哪个 Agent不用像以前一样在长会话里大海捞针。”强调“简洁结论上抛不上抛日志”是一个很工程化的认知直接体现分层的好处。面试官听到这里通常不会打断因为这已经远超“会调 API”的层面了。4. 面试官最爱追问的六个多 Agent 问题提前背好回答框架题型背完实战的追问才是大头。面试官最爱问的六个方向基本是围绕“性能、成本、一致性、工程质量”来的。我梳理了高频六问和可复用的回答框架建议你逐个过一遍。4.1 “多个 Agent 之间怎么通信”这是最基础也是第一个容易被问秃的问题。通信方式大致有四种通信方式适用场景弊端直接函数调用子任务强耦合、可同步等待架构死板不好扩展消息队列/事件总线异步任务、解耦协作调试链路变长、消息可能乱序共享存储/数据库黑板架构、共享状态场景并发冲突需要处理共享结果 外部回调跨服务协作需要定义回调协议我最推荐的面试答法是直接说“我在项目里选了哪种”并举个例子。千万不要把所有通信方式都当成并列选项背一遍——那是八股文不是工程经验。比如你选了消息队列那么只要回答“哪个场景用到了同步调用哪个场景改成了异步回调为什么这么改”就有信息量。“我们的通信现在分两套编排器下任务用同步 HTTP JSON因为需要能及时拿到结果给用户反馈Worker 上报中期进度用消息总线因为不想阻塞。后面我发现长期轮询的效率很低就把‘处理进度查询’改成由 Worker 主动 push 完成事件前端监听事件刷新页面。这样用户体验好了很多代码也更好维护。”4.2 “多个 Agent 的上下文和记忆是共享还是隔离”这个问题考的是你对 LLM 上下文成本和一致性的理解。标准答案是大部分隔离少部分共享。每个 Agent 长期记忆可以放专业领域文档、知识库、向量检索短期记忆只放本轮子任务相关上下文跨 Agent 的共享记忆只传递结论和摘要而不是全文。这个策略能大幅降低 token 成本同时避免 Agent 被无关信息干扰。“我们的设计是每一轮子任务都有独立的上下文窗口Worker 收工后上下文就释放只有编排器维护一个轻量的全局记忆节点记录关键结论。这样单个 Worker 的上下文不会爆炸而且自动化测试时不需要构造超长上下文。”4.3 “Agent 之间出现冲突怎么解决”这个问题能直接用 2.3 谈判式架构的思路回答但不用直接背架构而是给冲突处理优先级外部事实优先——能查到权威数据源的冲突用数据说话规则仲裁优先——业务规则写死在仲裁 Agent 的 Prompt 或代码逻辑里投票/加权仲裁——多个 Agent 各提观点按权重投票人工兜底——均无法消解时标记为“需人工确认”不要硬输出。然后补一句“冲突本身不可怕可怕的是没有一个明确的仲裁顺序。我通常会把仲裁规则设计成代码而不是全交给模型判断这样才能保证一致性。”4.4 “多 Agent 系统的效果怎么评测”这个问题非常考验真实项目经验。你不能只说“看准不准”因为多 Agent 系统的“准”分成两层单体执行的准确率和协作流程的准确率。推荐回答框架层一单 Agent 单元测试——每个 Worker 单独给定样例数据看输出格式、内容正确率层二流程集成测试——多 Agent 协作一整轮检查最终产出是否达到用户预期层三端到端业务指标体系——如任务成功率、平均交互轮数、用户反馈满意度、耗时 P95层四回归测试——把历史典型问题做成题库每次改 Prompt 或架构先跑一遍题库再上线。“实践中我还会统计‘无效交互占比’也就是 Agent 重新请求或者重复执行的次数占总请求的比例这个指标比单纯的准确率更能反映系统协作是不是顺畅。”4.5 “系统里某个 Agent 挂掉了怎么办会不会蝴蝶效应”多 Agent 系统最大的脆弱点就是连锁故障一个 Worker 超时了编排器等着Operator 超时了上层等着最终用户干等。回答时最好能体现你考虑过“容错层级”分层策略进程级每个 Agent 独立进程/容器崩溃互不影响任务级超时自动重试、降级到备用 Agent流程级编排器检测到关键链路失败后切换到简化流程保证基本可用系统级内置熔断开关必要时关闭多 Agent 协作退化成单 Agent 人工兜底“有一次我们一个 Worker 第三方查询接口不稳定导致整条链路响应超时。后来我在编排层加了一个性能熔断规则如果某个 Worker 连续三次失败就把它的职责临时交给一个降级 Worker用缓存数据顶上保证用户至少能拿到一部分结果。这个设计比让用户干等着强得多。”4.6 “多 Agent 一定比单 Agent 好吗什么时候别用”这是很多面试官最后会用来“一锤定音”的问题。别被问住答案其实很清晰多 Agent 有收益但也有成本大多数简单任务单 Agent 就够了强行拆分会增加延迟、成本和调试难度。面试官想看你有没有成本意识。你可以用这三个条件判断是否值得上多 Agent任务是否需要多个角色视角协同任务是否可以拆成边界清晰且可以并行的子任务结果是否需要经过交叉验证、协作修正。三条都不满足就不值得上多 Agent。能主动说出“我判断过这个项目没必要用多 Agent”的候选人反而比满嘴都是多 Agent 的人更可信。5. 一套完整的面试回答模板从“自我介绍”到“追问话术”最后给一套可复用的面试答题模板帮你把 1 分钟自我介绍和 5 分钟架构讲解连起来。先声明模板不是让你逐字背诵而是帮你建立“回答结构”。你把下面连起来过一遍遇到问题时你会发现自己已经有底气了。第一步一句话定场景30 秒“我之前做过一个智能报告生成系统用户只需提交需求描述系统就会自动完成情报检索、数据整理、报告撰写等工作。当时整个方案我选了多 Agent 架构来做因为任务类型跨度太大单 Agent 要么上下文爆炸要么输出质量不稳定。”这段开场的作用是快速告诉面试官“我做过、我为什么做、不是赶时髦”。第二步讲你选的架构和原因60-90 秒“架构上我选了编排器-工作者形态因为子任务之间的先后依赖比较强需要确定性的执行流程。入口 Agent 负责意图识别检索 Worker 负责查资料分析 Worker 负责汇总成结构化数据写作 Worker 负责写报告。编排器不掺和具体业务只做任务调度和结果合并。”这段的要点在于“架构希望解决的问题是什么”。不要只说名词。第三步讲落地的关键细节90-120 秒“两个工程细节最影响效果。一个是任务协议我们每个 Worker 的输入输出都约定成 JSON 结构编排器校验格式不合格就触发一次重试这就极大降低了模型自由发挥导致下游解析失败的场景。另一个是上下文隔离Worker 每轮只拿到 2-3 条必要的上下文不引入长对话历史这样 token 消耗控制住响应速度也上来了。”这是你比“背概念的人”拉开差距的地方。面试官想听的就是你有没有处理过真实工程细节。第四步讲效果 一个坑60 秒“上线后任务完成率从单 Agent 的 85% 提到了 96%。踩过的最大一个坑是编排器的汇总逻辑Worker 返回没有问题时编排器改写关键结论时出错。后来我们让编排器只做校对和合并不允许改动 Worker 的专业判断这个情况就再也没有出现过。”如果你能顺带说一句“后来我在另外一个小任务里试过黑板架构发现并发刷新支持更好但确定性不如编排器所以最终扣回了原有方案”那面试官对你的印象就不再是“会用一个架构”而是“真的比较过架构取舍”。追问场景模拟示例面试官问“为什么报告生成这里不用谈判式架构”你可以答“我也考虑过谈判式适合答案存在多面性、需要一致性共识的场景。报告生成的校验任务里我实际上嵌了一个轻量辩论模块——写作 Worker 产出初稿后由审核 Worker 模拟用户视角挑刺只有评审一次不是多轮强辩论。主要是考虑用户体验这套系统要在一分钟以内给出报告多轮辩论一加至少多花 10-20 秒对大多数用户不值得。”这套回答的好处是既承认用了辩论思路也说明了你用它的边界在哪里面试官继续深挖边界问题时你已经提前把自己的“取舍逻辑”甩出来了。6. 写在最后多 Agent 面试不是考记忆是考“为什么”我自己面试过很多候选人也在不少项目里被面试官问过同样的问题。我最深的体会是多 Agent 相关题目面试官真正想验证的不是“你见过多少框架”而是“你有没有在真实约束下权衡过方案”。你能把四种架构的适用边界想清楚再结合自己的项目把每一步取舍都讲出理由这场面试就不会差。如果你对四种架构的定位还是有点乱最后给你一个记忆口诀“黑板靠空间编排靠控制谈判靠冲突分层靠抽象”。面试的时候无论对方想往哪个方向深挖你都从这句话出发去组织答案。希望这套总结能帮你踩准节奏拿到想要的 Offer。