多 Agent 系统这几年几乎成了大模型方向面试的必考题问法五花八门“你的项目里多个 Agent 怎么协作”“任务规模翻十倍现在的方案还扛得住吗”或者干脆丢来一句“设计一个多 Agent 系统要求……”。我一边带候选人准备一边自己也常坐在面试官那一侧听回答见得最多的不是知识不够而是把概念背得很熟、一聊到取舍就露馅。面试官真正想验证的是你面对真实任务时能不能把“架构”这件事讲清楚。所以我把自己接触到的回答里最高频、也最能体现功底的考察点压成了 4 种经典架构编排者-执行者、层级式、共享黑板、辩论/对抗式。接下来逐个拆开每种架构的拓扑长什么样、信息怎么流动、决策权在谁手里、适合什么场景、面试怎么答才不会翻车。1. 面试官在多 Agent 架构问题上到底想听什么1.1 六个躲不开的考察点先说结论面试官通常不会直接问“你知道几种多 Agent 架构”而是把问题藏在一个看似开放的场景里。真正被考察的是这六件事拓扑与角色系统里有几类 Agent谁是执行者、谁是决策者、谁负责汇总。任务拆解主目标怎么变成子任务拆解是预定义还是 Agent 现场判断。通信机制Agent 之间是同步还是异步走消息通道还是共享状态。冲突裁决多个结果不一致时谁说了算依据是什么。状态管理运行中的中间状态集中在哪单点挂了怎么恢复。成本意识每轮任务要调用几次模型、上下文最长会涨到多少 token。每一条都能单独做成一个追问。比如你说“我用了编排模式”他接着就问“如果 worker 返回混乱主 Agent 怎么合并如果主 Agent 坏了呢”这些问题的答案不会在概念定义里只能在你的设计决策里。我面试时有一个习惯先让候选人讲方案再选一个局部反复深挖。深挖三次之后基本就能判断对方是“把这个系统跑通过并改过”还是“只看过别人的架构图”。这种判断对你自己也有用——准备面试时与其多背一篇概念不如把上面六条提前写成“自己项目的填空题”。1.2 裸背概念的三种“送命”回答这些年听过的反面教材高度一致大概三种一、定义型。“多 Agent 系统是指多个智能体通过协作完成复杂任务的一种架构……”说完等于没说面试官等不到任何设计信息。二、名词堆砌型。“我用了思考-行动循环、Function Calling、RAG、全自动 Agent 那套思路配合某个编排框架的多 Agent 编排队列还有……”你在讲菜单不是讲系统。三、高开低走型。架构图画得很完整一问“你项目里 planner 的指令怎么写的”“worker 拿到的上下文是原始数据还是裁剪后的”马上开始含糊。这三个问题的共同病根是把“架构”当成了“名词集合”而不是“一套在约束条件下做取舍的方案”。面试加分的高分逻辑其实不复杂先说应用场景再说为什么选某种拓扑再补关键细节和代价最后提一句这个方案在什么情况下会失效。这个顺序我会在后面的每个架构里结合话术示范。2. 第一种经典架构编排者-执行者Orchestrator-Workers2.1 拓扑结构最好讲但别讲成流水账编排者-执行者是最容易理解、也最容易在面试里站稳脚跟的一种。系统里有一个中心节点通常叫 Planner 或 Orchestrator负责接收最终目标、拆解子任务、分派给下游 Worker、回收结果、汇总判断Worker 彼此不直接通信所有信息都要经过中心节点。这个模式为什么值得第一个讲因为它是绝大多数生产系统的第一形态。你做一个内容分析项目、爬取整理项目、报告生成项目第一步几乎都是“一个大脑 一群手”。面试时先承认这个事实能避免给人一种“为了显得高级而故意复杂化”的印象。描述这个架构时可以加一点自己的设计痕迹而不是只说拓扑。例如我做过一个“用户反馈分析”模拟项目主 Agent 拿到一批原始反馈文本后把它拆成四个子任务——情感判断、主题聚类、风险点识别、竞品对标。每个子任务交给一个 WorkerWorker 的指令里写清楚了“输出必须是一个 JSON 对象包含哪些字段”。等四处结果都返回主 Agent 再汇总成一张表格。这个例子虽然简单但足够支撑你讲清楚拓扑、通信、决策三个维度。2.2 这个架构最容易踩的三个深坑先说输出契约问题。Worker 返回的内容如果没有强结构主 Agent 就要花大量精力做文本解析最后合并出来的结论还不稳定。我的做法是每个 Worker 的命令里都自带输出 Schema哪怕只是一个简短 JSON 示例也要在指令尾部明确“只输出 JSON不要解释”。宁可多花 20 个 token 做格式约束也不要让后续解析变成一场灾难。然后是上下文隔离。很多人做项目时图省事把原始数据一股脑塞进系统提示所有 Worker 都看得到。实际上面试官很爱问“你的 Agent 之间会不会上下文污染”这时你要能说出Worker 只会拿到自己需要的那份子集而不是全量原始数据。这不只是保护 token更是避免 Worker 被无关注入信息带偏。最后是结果合并。如果四个 Worker 给出的结论互相矛盾主 Agent 怎么裁我常用的策略是优先级加置信度先看数据源可信度再看 Worker 返回时是否自带置信度分数。这个细节说出来面试官会知道你处理过真实冲突。2.3 面试回答示范与适用边界给你一段可以直接改写的表述“我的系统采用编排者-执行者结构。主 Agent 对用户目标做任务拆解并把每个子任务的上下文裁剪好Worker 之间没有直接通信结果以结构化 JSON 返回由主 Agent 做最终汇总。这样做的收益是每个 Worker 只需要专注单一职责指令可以写得很短代价是主 Agent 的上下文会成为瓶颈所以我在拆解时会控制返回内容的长度。”这段话暴露了一个关键信息你不是只会画图你知道这个架构的瓶颈在哪。这就够了。它的适用场景是任务边界清晰、步骤明确、最终答案依赖多源信息合并不太适合完全开放的探索型任务那种任务让中心节点做决策会经常卡壳。3. 第二种经典架构层级式Hierarchical3.1 编排者变成瓶颈之后自然会长出管理层任务一多编排者-执行者模式会快速撞上四个问题中心节点上下文越来越长单个大脑的拆解能力有限所有 Worker 都等着同一个调度器延迟放大中心节点一旦失败整个系统瘫掉。这时候很自然的进化方向就是层级式。层级式的核心是引入中间管理层。一个高层的 Supervisor 只管几个中层 Manager每个 Manager 再带自己的小组。信息是逐级下发的高层说“我要一份竞品分析”中层把它变成“找数据、做访谈、看财报”三块指令底层再把这些变成具体的检索和写作动作。反过来结果也逐级汇总底层只向自己的直属上级汇报。这个结构我用一个公司类比讲过很多次老板不直接给每个基层员工派活而是先找部门负责人部门负责人再拆给小组长。层级的意义从来不是为了好看而是为了控制每个节点的上下文规模和决策复杂度。3.2 面试官对层级结构的三个高频追问第一个追问“一个 Manager 管几个下属”这就是管理跨度问题。跨度小层级深决策链长延迟高跨度大Manager 的上下文又会被压爆。我的经验是底层执行类 Worker 可以多配因为它们的指令短但凡是需要做判断、做汇总的中间节点跨度最好不要超过 5 个否则它的上下文管理会变得非常痛苦。第二个追问“如果某个底层 Worker 失败了错误信息报给谁”正确回答是报给它的直属 Manager由 Manager 决定是重试、换 Worker 还是带着局部结果向上汇报。如果每个失败都直接回到总节点层级就白分了。第三个追问“这么层层传递延迟不是很高吗”这里要主动提到“层级剪枝”简单任务不该走完整棵树。一个请求过来先由入口判断如果子任务足够简单直接交给下层小组单点完成完全不触发上层拆解。面试时能把剪枝说出来会明显区别于只会背“树状结构”的人。3.3 话术模板什么时候选层级而不选编排者一个比较自然的说法是“当任务本身具有天然层级结构或者单层编排者上下文压力太大时我会把调度拆成多层。上层节点只负责目标意图和资源分配下层节点负责具体执行和局部汇总。这样每个节点的上下文都保持可控系统也具备更高的并行度代价是消息传递多一跳需要额外的链路追踪设计。”这里要给出一个关键的取舍判断小团队、任务步骤不多选编排者团队规模扩大、任务可以被明显划分为子域而且子域内部还要继续拆分才值得上层级。面试时如果被问“你为什么不直接用编排者”你可以回答“因为我的任务里存在两个层级的复杂度单层会让中心节点变成事实上的单点瓶颈。”这个回答同时展示了你对两种架构的理解深度。4. 第三种经典架构共享黑板Blackboard4.1 把协作从“消息传递”改成“共享状态”第三种架构的思路和前面完全不同Agent 之间不直接传话也不再围绕某个中心节点汇报而是共用一块“黑板”——可以理解为一个共享的、有结构的状态空间。每个 Agent 都在这块黑板上读写谁发现了一个线索就把线索贴上去谁有能力处理某类信息就上去认领并回写结论。生活里最好类比的是会议室里的白板几个同事围在一起做头脑风暴每个人随手写自己的发现有人写完以后另一个人看到它触发了一个新想法接着补上去。没有人统一指挥“你写这句、他写那句”协作是靠“看到别人结果之后的自主反应”完成的。这个架构解决了编排者和层级式的一个通病中心节点并不总是知道所有事。当任务本身充满不确定性、探索路径没法提前规划清楚时黑板模型让每个 Agent 都能按自己的专业特长自发贡献。比如一个故障诊断系统日志分析 Agent、条文匹配 Agent、历史案例 Agent 各查各的谁先找到有效线索就写到黑板上其他人看到以后继续深挖。4.2 面试里必须主动讲清楚的四个问题黑板模型听起来很“联邦”但面试官的第一反应往往是“这不就是一个共享全局变量吗怎么保证不崩”。你要提前准备四个回答。一是写入一致性两个 Agent 同时往黑板写冲突结论怎么办。我的做法是给每个发布条目加“主题标签、时间戳、来源 ID”写入时做层级锁或乐观锁下游消费端按标签过滤。二是结论冲突黑板上有多个互相矛盾的中间结论怎么收敛。这时需要一个仲裁机制可以是预定义的规则集合也可以由一个专门的仲裁 Agent 定时扫描黑板并合并。注意这个仲裁者不是调度者它只负责“收敛”不负责“指挥”。三是上下文爆炸黑板如果无限膨胀每个 Agent 都要扫描全量的话成本是不可控的。我的建议是分区订阅——黑板按业务域拆成多个空间每个 Agent 只订阅和自己相关的区域。这和消息队列里的 topic 分区是一个道理。四是可追溯性最终结论必须能回溯到中间条目。每个写入条目都要保留“由哪个 Agent 根据哪些旧条目产生”的依赖信息这样审计和调试才有抓手。4.3 话术与适用边界什么时候说黑板方案是加分项一段可以参考的话术“这个任务的路径存在很多不确定性不适合一开始就把执行顺序定死所以我用了黑板架构。多个 Specialist Agent 基于共享状态做异步探索产生的新结论继续成为别人的输入同时我对黑板做了分区和条目追踪避免上下文膨胀和结论不可追溯。相比编排模式它的交换成本更高但换来了更强的探索能力。”这句话点到三个加分点知道为什么要用、知道怎么做分区、知道代价是什么。适用场景大约是内容生成、故障诊断、研究分析这类开放型任务如果流程非常固定、步骤严格有序、或者需求方要求“每一步都必须由人确认”黑板模型就不太合适强制使用只会让你自己陷入一致性调试的无底洞。5. 第四种经典架构辩论/对抗式Debate/Critique5.1 多 Agent 不只是分工还可以是博弈前三种架构本质上是“分工协作”Agent 之间是合作关系辩论/对抗式则完全不同它让多个 Agent 扮演不同的立场通过互相挑错来逼近更可靠的结论。最常见的配置是两个角色一个 Writer/Generator 负责给出方案一个 Critic 负责攻击这个方案里的漏洞、歧义和风险。严谨一点的系统还会加第三个角色 Judge/Moderator负责收尾在多轮辩论之后给出最终裁决。整个系统就是一个循环生成者给出初稿批判者从一致性、完整性、可执行性等维度提出意见生成者基于意见修改批判者再检查直到满足某个终止条件。我自己用这个模式做过一个“方案审查”DemoWriter 先给一份技术方案Critic 按“成本、风险、落地难度”三个维度逐条打回Writer 带着这些意见重写最多迭代三轮。跑出来的结论是多一轮批判方案里明显不合理的内容会大幅减少但到第三轮以后收益递减很明显。这个“收益递减”本身就是面试时喜欢的观察点说明你真的测过而不只是看过论文。5.2 轮次、裁判和成本三个不能含糊的参数面试官一旦确认你懂这个架构立刻会追问三个参数。第一轮数是固定的还是动态的固定轮次的好处是可预期坏处是浪费。如果 Critic 已经说“这版没问题”系统还硬要再跑两轮就纯粹烧钱。我的经验是设一个“早停”条件连续一轮没有新的有效修改意见就判定收敛并终止。第二裁判能不能保持中立。很多人犯过一个错让 Writer 自己总结自己改了哪些问题然后把总结丢给 Judge。这等于让运动员兼裁判。正确做法是 Critic 的意见原样保留Judge 接收的是带完整证据链的内容而且 Judge 的指令里要明确“不能因为某条意见语气强硬就采纳”。第三成本怎么控制。辩论架构是所有多 Agent 模式里 token 消耗最高的一种。一篇文章做两轮辩论可能等于普通生成任务的 5 到 6 倍调用量。面试时主动算一笔账会非常加分比如“我的典型任务模型调用次数是生成 2 次加批判 2 次加裁决 1 次上下文最长约 8000 token所以我只在高质量输出场景使用。”5.3 什么时候该用、什么时候千万别用该用的场景创意方案生成、复杂逻辑验证、安全合规审查、需要把“不同角度的观点”显式建模的任务。这类任务单次生成质量不够而多轮辩论正好制造“自我对抗”来补盲区。千万别用的场景实时交互业务、高频低延迟接口、成本敏感的数据批量任务。我在一次日志分类任务里试过给每个样本配一个 Critic结果准确率只提升了一点成本翻了 4 倍后来果断砍掉。面试时讲这种“试用后权衡放弃”的经历比单纯背书的效果好得多。你也可以总结成一句话辩论架构是质量放大器不是通用骨架只有当你对质量有硬要求、且能忍受额外成本时才值得把它放在主流程。6. 面试实战一道经典多 Agent 设计题的完整推演6.1 拿到题目后先别画架构图先列约束面试里常出现的题是“设计一个多 Agent 系统快速生成一份市场竞品分析报告结论要能追溯到数据源。”很多人一听就开画把四个架构全部画进来反而糊了。我的推演顺序是这样的。第一步找任务特点多源数据收集、统一步奏但有局部不确定性、最终需要一个汇总判断、对结论可追溯有硬要求。第二步找主架构大部分子任务边界清晰需要把收集和分析拆分天然适合编排者-执行者。于是我确定入口是 Planner三类 Worker 分别负责公开数据整理、结构化资料抓取、定性观点收集。第三步补质量环节竞品报告属于高质量输出单靠汇总不够。我加一个 Critic Agent对汇总报告按“数据充分性、时效性、风险提示”三个维度打回一次。这里就自然用到了辩论架构但只做一轮防止成本失控。第四步定冲突与追溯机制Worker 返回的每条结论都带来源链接和置信度Planner 合并时发生冲突按“来源等级优先加置信度评分”裁决。最终报告里每个关键结论都附证据链。这一步直接把“可追溯”从口号变成了数据结构。第五步说清状态与恢复中间汇总表放在共享存储里Planner 负责维护状态机某个 Worker 超时允许整体降级用缓存数据补位并标注“该结论置信度偏低”。这么答下来你其实没有刻意炫耀“我用了几种架构”但面试官能明显感觉到你不是套模板你的每个选择都由业务约束驱动。6.2 高频追问与高分应答速查表整理了一份面试官最爱追问的问题建议面试前自己对着练追问类型考察点高分回答要点为什么不用某某架构取舍能力先承认对方说的架构合理再给边界我的任务要求什么所以不适合上下文会不会污染状态管理按需裁剪Worker 只见子集关键字段用独立空间隔离一个 Agent 挂了怎么办容错设计超时、重试、降级三层机制说明重试幂等性靠任务 ID 保证任务规模加十倍怎么扩展水平扩展优先增加 Worker 并行数若还到瓶颈再按域拆层级或分黑板空间怎么评估系统质量指标意识分任务定义完成率、正确率、平均调用次数、延迟、成本如何 Debug 多 Agent 问题可观测性全局链路 ID记录每个 Agent 的输入与输出支持会话回放系统里谁最终负责职责边界明确最终决策节点避免“大家互相商量”这种暧昧回答这张表最好结合自己的项目案例改写不要背我这里的原话。面试官很容易听出你是在背通用模板还是在讲自己的系统。6.3 四个容易翻车的实战忌讳第一不要把所有架构都塞进同一个方案。曾有一个候选人让我印象深刻他画了满满一页编排者、层级、黑板、辩论全占了。追问却发现他根本说不清数据在哪儿流动。架构越多需要交代的通信边界越多除非有明确理由否则尽量让主链路简洁。第二不要回避“代价”这个词。只讲架构带来的收益、不讲它的成本在面试官看来是经验不足。主动说出“这个架构的 token 成本高”“它的调试难度大”反而显得可信。第三不要忽略最终的交付形态。很多 Agent 项目最后输出的不是一段文本而是一份带数据的报告或一个可执行的计划。把产出结构纳入架构设计能让你的方案落到地上。第四不要吹“完全自治”。多 Agent 系统里完全没有人参与风险很高靠谱的设计一定会在关键节点保留人工确认或仲裁入口。面试时主动提“我在这里留了一个人审环节”是很加分的工程判断。6.4 最后分享一点我在面试中的判断标准从我自己坐在面试官那一侧的经验看最看重的只有三点状态放哪里、失败怎么处理、谁做最终决策。这三个问题答得越具体候选人的架构功底就越清楚。反过来如果你准备面试我建议你别再背那种“多 Agent 系统是指……”的介绍了而是挑一个自己写过或者认真拆解过的项目把这三个问题的答案写下来。你会发现当这三个点想明白之后四种架构的区别、适用边界、甚至面试官后面所有的追问都会变得很好应付。这也是为什么我很少要求候选人现场默画架构图而是盯着一个局部反复问细节——真正理解系统的人细节兜得住。