多 Agent 系统面试怎么答我总结了 4 种经典架构这两年只要面试 AI 应用岗位十个里面有八个会被问到“多 Agent 系统怎么设计”。我作为经常端坐在对面的人说实话最怕听到的回答是“这个简单用 LangGraph 编排几个 Agent 就行。”它不能说错但完全没有踩到考点。面试官问的从来不是你会不会套某个框架而是你有没有想清楚 Agent 之间的职责边界、通信成本、失败恢复和扩展性。这篇文章我会把面试中最高频出现的 4 种经典架构——中心化编排、层级分解、黑板架构、合同网协议——逐个拆给你看。每种架构都会给出一套可以照着说的答题思路包括它解决什么问题、适合什么场景、面试被追问时怎么圆。最后还会附上我自己面试别人时最常用的追问清单以及候选人最容易翻车的几个坑。不管你正在准备系统设计面试还是想把自己手头项目讲得更有架构感这份内容都值得你花 15 分钟看完。1. 先把考官意图摸清多 Agent 面试到底考什么很多人准备这个 topic 时会去背一堆术语比如 Agent 记忆、规划器、工具调用、RAG结果一到现场就被问住。要想不被问穿你得先明白面试官手里的评分表大概长什么样。1.1 表面问架构实际考的是这五件事多 Agent 系统听起来很高大上但面试官真正想确认的是你有没有系统设计能力。拆开来看他关心的是五件事。第一职责边界。每个 Agent 管什么事什么事它绝对不能碰。如果所有 Agent 都“什么都会”那其实就是没有架构。面试官希望你嘴里说出的是一组边界清晰的角色而不是一句“我有三个 Agent”。第二通信成本与协议。Agent 之间是同步调用还是异步消息走的是工具接口、结构化 JSON还是共享数据库表一旦两个 Agent 之间聊天链路里会引入多少延迟和不确定性很多候选人在这一点上完全没概念。第三容错与降级。某个 Agent 返回乱格式或者直接超时系统会怎样你会不会设计超时、重试、熔断甚至规则兜底这个点最容易被忽略但它恰恰是区分初阶和资深工程师的分水岭。第四横向扩展能力。任务量翻十倍你是加一个 Agent 实例就能扛住还是要推翻整个编排逻辑面试官很在意你的架构能不能平滑扩展。第五可观测性。出了问题你靠什么排查日志里有没有 trace_id每个 Agent 的输入输出有没有留痕没有可观测性的多 Agent 系统本质上是台没有仪表盘的飞机。1.2 先背熟一套四步答题框架我见过很多答得不错的候选人他们并不是把每个架构背进骨子里而是遵循了一套固定的回答节奏。第一步先用一句话定义场景。比如“我要做一个能自动写行业研报的系统”。没有场景后面的架构就是在空气里搭积木。第二步交代角色划分。你要说清楚这个系统里有哪几个 Agent各负责哪一段。例如资料采集 Agent、数据清洗 Agent、分析 Agent、写作 Agent。第三步说明信息怎么流动。谁发起、谁响应、是推还是拉任务结果最终汇集到哪里。这段要用你自己的项目经验去支撑而不是背概念。第四步主动交付出权衡。你要点明这个架构最大的优点和最大的短板以及什么条件下我会换成另一种架构。这一点非常加分因为它直接证明你不是只会背 PPT。公式化一点就是“场景 角色 通信 权衡”四件套。接下来四种架构我都会用这个框架给你演示怎么自然地说出口。2. 四种经典架构逐个拆怎么讲才显水平下面进入正题。这四种架构是面试题里出现频率最高的强烈建议你先把它们的区别画在脑子里。2.1 中心化编排架构Centralized Orchestrator这是目前工程里最常用也最容易讲清楚的一种。它的核心思想很简单有一名“调度总管”所有任务先交给它由它判断任务性质再分发给下游各专职 Agent。下游 Agent 干完活以后把结果交还总管由总管做最后汇总。整个结构是典型的星型拓扑。我在面试中建议这样组织语言“如果我要做一个人工客服外的智能辅助系统我会采用中心化编排架构。首先我会定义一个总控 Agent它不负责具体业务回答只负责意图识别和任务分发。下游我挂三个执行 Agent分别是订单查询 Agent、售后规则 Agent 和知识库问答 Agent。总控接收用户问题后先做意图分类随后把请求路由到对应 Agent。所有 Agent 通过统一的 JSON Schema 上报结果总控在拿到结果后拼装最终回复。”这一段讲完你已经把“场景 角色 通信”都交代了比干背“主从架构”直观太多。面试官接下来通常会问为什么你要中心化这就到了交付出权衡的地方。你可以说“中心化编排的好处是流程可控、链路可追。每个 Agent 的输入输出都经过总控做权限管控、敏感词过滤、内容回滚都很方便。代价则是总控本身会成为瓶颈一旦下游 Agent 数量非常多或者单次任务需要来回交互很多轮这个中心的压力和复杂度会直线上升。所以我一般建议 Agent 数量在十几个以内或者流程相对固定时再用。”要额外注意一个表达细节不要说“我用了 LangGraph 所以它是 Agent 架构”。编排框架只是实现工具不是架构本身。面试官希望听到的是你的设计意图而不是框架名。2.2 层级分解架构Hierarchical Architecture中心化编排是“一个总管带一群执行者”。层级架构则更像一个大公司顶层是董事会中层是总监底层是员工。任务从最上层开始逐层拆解每一层都只跟上下两级通信下层干完活以后把结果不断向上归并。我建议用一个偏研发管理的例子来讲“我要做一个跨平台 App 的缺陷自动分析系统。第一层总控 Agent 接收到仓库里的 bug 描述后把它拆成前端问题、后端问题、数据问题三类。第二层是模块负责人 Agent它不直接处理原始问题而是把任务分给具体的代码分析子 Agent。第三层执行 Agent 只处理自己那一小段分析工作返回给上一层层层汇总最后总控产出完整报告。”这段回答里最亮眼的部分是“上一层只做拆解不亲自干活”。你讲清楚了层级架构和中心化编排的区别中心化是扁平指挥层级是递归授权。讲到权衡时你可以说“层级架构特别适合任务本身可以被递归拆解的复杂场景。它比中心化好的地方在于每一层只做有限范围的工作局部改动不容易影响全局同时不同层级可以选用不同能力的模型——顶层用强推理模型做规划底层用小模型甚至规则引擎做批量执行成本上会更经济。”然后你要主动暴露它的短板“层级一旦深了链路延迟会变长因为每多一层就要多做一次序列化和传递。另外错误会层层传导如果顶层的拆解指令有偏差下面所有分支都在往错误方向跑。所以我一定会在顶层加一个人工校验点让它在关键节点上确认子任务没有被拆偏。”这个表述有观点、有取舍面试官会认为你真的在分布式环境里吃过亏。2.3 黑板架构Blackboard Architecture黑板架构是这四种里最容易被低估的一种。它和我前面说的两种架构有本质不同没有强主控。它借鉴了早期专家系统的协同方式。多个业务专家围坐在一起面前放一块黑板谁看到黑板上出现了自己能处理的信息谁就上去把结果补充到黑板上。大家并不直接彼此调用而是围绕“黑板”这个公共存储区协作。面试里最合适的例子是做多路径信息融合判断“假设我要做一个风险交易识别系统我会用黑板架构。我开一个公共事件库当黑板不同的专家 Agent 分别负责设备指纹分析、行为序列分析、风控规则匹配。它们不直接互相调用而是都监听同一个风险事件槽位。当行为序列 Agent 发现某个账号的登录频率异常后它会在黑板上追加一条观察结果设备指纹 Agent 看到这条结果后发现该设备之前也关联过黑名单于是它再补充一条高置信度标记。最后所有信息在黑板上汇聚由一个汇总模块生成最终风险分。”这个例子完美解释了“为什么用黑板”——问题本身没有固定处理流程不同专家看问题的角度不同谁有发现谁就往公共区里写。接着讲权衡“黑板结构最大的优点是解耦和异构集成不同 Agent 甚至可以用不同语言实现只要它们读得懂黑板格式。但它的风险在于并发写入。两个 Agent 同时发现同一个异常时黑板内容可能会被覆盖或者出现重复处理。我在实际设计中会让每个 Agent 分配一个专属槽位并且对黑板操作加版本号和乐观锁这样写冲突基本可控。另一个代价是完成时间不可预测因为没有一个中心来控制推进节奏所以它不太适合对响应时间有硬性要求的在线场景。”面试官如果顺着追问“你怎么保证各 Agent 都在干活而不是一起等”你可以补一句“我给每个槽位设计了超时机制超过一定时间没有新增信息系统会主动触发汇总逻辑避免流程僵死。”这句话能立刻拉高整体回答的工程感。2.4 合同网协议架构Contract Net Protocol / Market-based最后一种架构的视角非常独特它把任务分配这件事变成了一场招标。在这种架构下一个管理 Agent 手头有任务但它不确定底下哪些执行 Agent 当前空闲、能力强弱如何。于是它把任务发布成招标书广播给所有执行 Agent。执行 Agent 根据自己的当前负载和能力投标管理者根据投标信息选一家签合同然后执行者交付结果。我通常建议用一个动态负载均衡的例子去讲“假设我有一套大规模文件转码服务每天会进来不同格式的视频文件。文件类型、大小和机器负载一直在变不可能提前把每个任务钉死给某一台机器。我会用合同网架构调度器收到转码请求后把转码任务和文件特征发到任务队列各转码执行 Agent 根据自身 GPU 剩余情况来投标调度器选择出价最合适、信誉度最高的执行者双方建立一次转码合同。任务完成后执行 Agent 上报结果合同关闭。”这段内容自然带出了合同网的核心优势——动态性和负载均衡。你不需要提前知道谁有空让执行者自己来说“我可以”。再说权衡“代价首先是通信开销变大了。每次任务都要广播一次投标信息如果任务颗粒度特别小花在招标上的开销会比执行本身还贵。所以我只会在任务量适中、单个任务耗时较长、或者节点能力异构明显的场景使用合同网架构。另一个问题是可能遇到恶意投标执行者为了中标夸大自身能力所以架构里要保留一个信用评分表历史失败率高的 Agent 会被降权。”我特别喜欢让候选人在这个点多说一句“如果任务粒度太大我不会用合同网我会回到中心化编排反之如果节点能力完全同构也不需要这么复杂的机制。”这种边界判断非常能体现架构敏感度。3. 面试官最爱追问的四个坑这样接才不掉分上面四种架构你都能按模板答出来后面试还远没有结束。通常面试官还会在你这套回答上继续加压。我把这几年来最常出现的追问整理成了一组速查建议你提前想好对策。3.1 “你这个架构为什么不用另一种”这是一个典型的能力分水岭问题。它不要求你证明自己选的架构是天下第一而是要你用“比较级”说话。遇到这个问题别慌直接踩在“对比维度”上输出。我给大家一个我常用的小表格思路语气上可以这样说架构类型控制力容错难度通信开销适合规模中心化编排很强中等低中等层级分解较强高中大规模复杂任务黑板架构弱中等中异构专家多、流程不定合同网弱高高动态节点、弹性伸缩然后针对你的场景挑一行说理“我选的中心化编排核心原因是业务链路固定流程只要按步骤执行就不会出问题。如果业务变成动态寻找最优节点我才会切到合同网。”这句一出口面试官就知道你是真的理解架构而不是背了一份PPT。3.2 “Agent 之间的通信协议具体怎么定”别用一句“用自然语言对话”来回答这在大规模系统里几乎是灾难。自然语言通信意味着不稳定、不可测也很难做权限管控。更稳的答案是“我会先把所有 Agent 间交互定义为结构化消息消息格式长这样消息类型、发起方、目标方、任务标识、负载内容、时间戳、超时策略。同时我能把一个 trace_id 贯穿整条调用链。这样每个 Agent 之间本质上是消息管道而不是无边界闲聊。”你还可以顺带补一句“如果某个 Agent 需要调用另一个 Agent 的私有能力我会规定它只能通过注册在服务目录上的接口调用而不是直接读对方内部状态。这样保证各 Agent 对自身世界保持封装改动一个 Agent 不会炸一片。”3.3 “多个 Agent 共享上下文时怎么避免冲突”面试官问这个通常是因为他们之前被分布式一致性问题伤过。你直接落到实践中“我不会让不同 Agent 直接写同一个全局内存。首先各自执行过程产生的中间态写入隔离的工作区间只有得到确认的结果才允许写入共享区。如果一定有两个 Agent 需要协作修改同一目标我会让共享区使用版本号或条件更新先到先得后来者发现版本不一致就需要回退重算。”说完再来一句金石良言“更重要的是我觉得多 Agent 系统里不是所有变量都适合共享。能用单 Agent 内部状态解决的就不必公开到全局。职责边界清晰永远是第一优先级。”3.4 “如果某个 Agent 挂了或者给出错误结果怎么办”直接说实话你不该在短时间里把每个 Agent 都做成经得起故障轰炸的工业系统但你要让面试官知道你愿意为此付代价。我推荐这样回答“我会分三层处理。第一层是调用层超时重试超时阈值要按每个 Agent 的耗时特征单独设置不能用统一值。第二层是熔断降级如果一个 Agent 连续失败三次我会把它标记为不健康后续请求走备用通道或规则引擎兜底。第三层是结果校验层对于关键任务我会让另一个轻量监控 Agent 对结果做一次合理性抽查发现问题就走人工复核。这层不是平白多花钱而是它能显著提升系统可信度。”这段回答把“随机应变”和“工程控制”都体现出来了面试官很难再有理由追着你不放。4. 真实的回答示范一份可以直接套用的面试话术我不建议任何人在面试时照背八股文但一套经过验证的回答结构完全可以帮你快速建立答题信心。下面这段示范你可以改成自己的项目后反复练习。“我之前做过一个项目是给业务团队用的自动数据分析助手。它核心要解决的任务是普通运营同学输入问题后系统能自己查数、算指标、出图表而不是由数据分析师手工写 SQL。这个项目里我采用了多 Agent 架构具体是中心化编排加局部层级设计。最上面是一个调度 Agent负责解析用户问题并判断该走哪个查询链路。中间层我放了一个 SQL 生成 Agent 和一个图表生成 Agent但 SQL 生成 Agent 解决问题的能力还不够它需要继续调用两个子 Agent一个负责根据语义匹配指标字段另一个负责做复杂条件筛选。子 Agent 的结果回到中间层由中间层拼出完整 SQL最终交回调度 Agent 汇总输出。选这个架构的考虑是整个流程有相对固定的处理路径用中心化编排能保证可追踪、可审计。而局部层级拆分是因为单个文本转 SQL 的任务太复杂硬让一个 Agent 搞定会频繁出错拆成两级后每个子 Agent 的关注范围更窄准确率也会提升。当然这样的代价是流程多了两层调用延迟会略有上升。我在每个环节都加了最小超时时间如果某个 Agent 没有在预期时间内返回系统会直接降级到规则模板生成 SQL而不是无限等待。”这段话说不上惊艳但结构完整、有理由、有取舍、有容错是典型的能过面试的回答。我自己在面试别人时只要候选人能说到这个完整度就已经比大批只会报 LangChain API 名字的人好太多了。5. 我作为面试官见过的高频翻车点聊完了“怎么答才是加分的”我再给你泼一盆冷水以下这些坑我几乎每周都会见到希望你千万别踩。5.1 从头到尾只谈框架不谈职责“我用 CrewAI 定义了一个 Manager三个 Worker……”这是框架描述不是架构描述。我会追问“如果 Manager 挂了你的业务能继续吗”大部分人当场卡住。以后凡是提到框架都要后接一句具体职责这样才算落到架构层。5.2 只讲优点完全回避短板没有人觉得世上存在“零代价的系统”你不说弊端面试官也会追着问还不如主动点。在提到任何架构时你都应该习惯性带上“不过它的代价是……”这句话这会显得你非常有实战意识。5.3 把可观测性放在最后才提有时候我会中途问一句“你怎么排查线上 Agent 状态”很多人会愣住了。其实答案不复杂日志里带上 trace_id、每个 Agent 输入输出单独写事件表、关键节点做指标采集。但你要在回答架构时顺带提一句而不是等面试官追问才猛地想起来自己有日志系统。5.4 把通信设计成自然语言大杂烩我一听到“这个 Agent 发消息给另一个 Agent 说”就眼皮一跳。实际上生产环境里大部分 Agent 通信应该用结构化消息。自然语言只应该出现在面对用户或需要解释说明的场景。把这一点定义清楚你就成功一半了。5.5 不考虑资源成本多 Agent 系统最容易被低估的就是钱。每个 Agent 背后可能都是一个独立模型推理一次任务让四个 Agent 干活单次调用成本直接翻四倍。我很喜欢在面试里补问“你最贵的 Agent 调用在哪一层”会让他意识到你关注成本结构。回答时你可以这么说“顶层规划 Agent 用的是高推理模型底层的执行 Agent 很多可以用小模型甚至普通规则模板让成本集中在真正需要智能的地方。”6. 面试前最后 30 分钟的快速自查清单不管你准备的多充分都有可能在临场时话到嘴边却说不出完整的结构。以下这个清单我建议你在面试等待区快速过一遍。第一你的系统角色清单说得清吗能不能一口气报出每个 Agent 的名字、职责、会调用哪些工具、不该碰哪些问题。第二你的信息流讲得清吗谁是入口、谁是出口、中间经过几个节点、每个节点传什么消息。不要让人脑补你的架构图。第三你的异常处理是什么至少要有超时、重试、降级、人工兜底四件事中的两个。第四你说得清为什么不用其他架构吗哪怕只用一句“因为我的任务是固定流水线所以不选择黑板架构”也比完全沉默好。第五你有没有数据指标支撑你的说法比如使用多 Agent 架构后准确率从多少提升到多少平均延迟增加多少毫秒。真实数字比一百句自夸都管用。最后分享一个我多年面试下来养成的私人习惯。我不会去背那些完美的教科书式回答而是会挑一个我自己真正做过的场景把上面的四步框架套进去。面试现场的高压氛围下人只会记得最熟悉的故事不会记得最完美的答案。多 Agent 系统本身就是一个强调协作和清晰分工的设计问题你怎么把你的业务讲得成体系比你怎么证明会背架构概念重要得多。