企业官网建设流程全解析

多 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 系统本身就是一个强调协作和清晰分工的设计问题，你怎么把你的业务讲得成体系，比你怎么证明会背架构概念重要得多。