最近面试辅导和模拟面试里，多 Agent 系统的出镜率高到离谱。不少同学拿着单 Agent 的工程经验去面试，被问到"你如何设计多 Agent 协作"时，能聊出 Supervisor、ReAct 这些名词，但一问到数据流、容错、状态同步就卡壳。这个现象其实很正常，因为多 Agent 不是单一技术点，而是一整套组织结构设计，它考察的是你在大规模、多角色协作任务里的系统思维。
这篇内容就围绕面试场景，把我在实际项目里验证过的 4 种多 Agent 经典架构拆开讲清楚：每种架构长什么样、解决什么问题、代价是什么、面试官会追问什么、以及怎么组织回答才能既显深度又不踩坑。不论你是刚接触 Agent 开发，还是已经在生产环境里跑过多轮对话，这套思路都可以直接拿来用在简历项目讲述和现场答题里。
1. 面试官问多 Agent，到底想听到什么
1.1 从单 Agent 到多 Agent：到底多出了什么问题
单 Agent 系统的设计核心是"一个人把所有事干完"：输入、规划、调用工具、生成回答都集中在一个模型循环里。多 Agent 系统则完全不同，它把一个庞大任务拆成多个角色，每个角色由一个独立的 Agent 承担，通过消息传递、任务调度、结果汇总来完成整体目标。
这里的难点不在"拆"，而在于拆完之后怎么协作。你至少要想清楚三层问题：
- 结构层：谁是主导者？Agent 之间的关系是上下级、平级还是混合？下一步该由哪个 Agent 接手。
- 通信层：Agent 之间通过什么协议交换数据？是共享内存、消息队列还是函数调用？消息格式怎么定义才能让不同 Agent 都理解。
- 执行层：某个 Agent 失败了怎么隔离？结果冲突谁来仲裁？整个系统的延迟和成本怎么控制。
面试官问多 Agent 架构，本质上是在考察你对这三层有没有全局认知。如果你只会描述"我让两个 Agent 一个写代码一个查 Bug"，但没有说清楚分工逻辑、数据接口、失败恢复，那这个回答是站不住脚的。
1.2 面试官考察的三个核心维度
我复盘了多次实际面试后，发现面试官在评价多 Agent 回答时，重点看三个维度：
第一个是分解能力。遇到一个复杂任务，你能不能合理地把它拆成有边界的子问题。比如"写一份行业研究报告"，可以拆成资料收集、数据清洗、框架搭建、初稿撰写、事实核查这几个环节，每个环节适合单独做一个 Agent 还是合并到一起，需要你给出理由。
第二个是协作机制设计。各 Agent 之间如何传递信息、如何共享上下文、如何避免死循环和重复劳动。面试官会关注你是否意识到"Agent 之间不能靠随便传字符串完事"，而是需要定义清晰的消息结构和状态管理。
第三个是工程权衡。任何架构都不是银弹，你需要讲清楚每种方案在延迟、成本、可控性上的取舍。比如全网状协作灵活但难以调试，主管-工作者模式可控但存在单点瓶颈——你能说出这些利弊，才算真正理解多 Agent。
很多候选人的问题在于，把多 Agent 当成"堆模型"，认为只要创建多个 Agent 实例就等于实现了多 Agent 系统。这就像项目里多开几条线程不等于并发安全，多写几个微服务不等于分布式架构。我在面试里经常举一个反例：给同一个 PDF 阅读器做五个 Agent，每个 Agent 都接同一个大模型，只是 prompt 不同——这不叫多 Agent，这叫多 prompt 路由。真正的多 Agent 必须有独立的职责边界、独立的上下文生命周期和明确的协作接口。
2. 四种经典架构逐个拆解
2.1 主管-工作者模式：最稳妥的面试答案
主管-工作者模式，英文常叫 Supervisor-Worker，是最容易理解和表达的第一种架构。核心思想很简单：一个 Supervisor 负责全局调度，把大任务分解成子任务，分发给多个 Worker Agent，然后收集结果、校验质量、汇总输出。
用生活类比来说，这就是一个项目经理带着几个专业工程师干活。项目经理不负责具体编码，但负责拆需求、排优先级、验收成果；工程师只负责自己擅长的模块，完成后上报结果。这样做的好处是职责清晰、流程可控，每件事都有明确的负责人。
在面试回答时，我建议你这样描述执行流程：
- 接收用户任务，Supervisor 基于自身规划能力生成任务清单；
- 根据每个子任务的需求，Supervisor 选择匹配的 Worker，并通过结构化的任务描述下发给对应 Agent；
- Worker 执行任务，可能需要调用外部 API、工具或检索知识库，最终返回结构化结果；
- Supervisor 对结果做质量检查，不满足要求则触发重试或回退；
- 所有子任务完成后，Supervisor 汇总生成最终答案。
这个流程里最关键的是第 4 步。很多候选人只讲到分发和收集，忽略了质量校验环节。面试官最想听的是 Supervisor 不只是"传话筒"，它还需要负责任务状态跟踪和异常兜底。你可以补充说明：校验逻辑不一定要靠模型，也可以是固定的规则，比如"是否包含代码块""是否引用指定文献""字段完整性校验"，混合使用规则校验和模型校验能显著提升稳定性。
下面是我在实际项目中用过的简化版主管-工作者调度伪代码：
# 伪代码：简化版 Supervisor 调度 # worker: dict[str, Agent]，key 是任务类型，value 是具体 Agent 实例 class Supervisor: def __init__(self, workers: dict[str, Agent]): self.workers = workers async def run(self, user_task: str) -> dict: # 1. 任务规划 plan = self.planner.generate_plan(user_task) results: dict[str, dict] = {} for step in plan.subtasks: worker = self.workers[step.type] retry_count = 0 while retry_count < step.max_retry: result = await worker.run(step=step, context=plan.context) if self.is_valid(result, step.validator_rules): results[step.id] = result break retry_count += 1 else: # 2. 兜底策略：标记失败或降级 results[step.id] = self.fallback(step) # 3. 结果汇总 return self.aggregator.merge(plan, results)注意代码里的max_retry和fallback，这两个参数体现了工程思维。任何多 Agent 系统都必须考虑单点失败，不能假设大模型每次返回都正确。fallback可以是调用另一个便宜模型、返回固定提示词、或者直接跳过该子任务但告知用户。
这种架构的优缺点，面试时可以从以下几点出发：
- 优点：职责边界清晰，调试方便，结果可审计；Worker 可以独立更换、独立测试，不影响全局。
- 缺点：Supervisor 容易成为瓶颈；如果任务之间需要频繁的信息交换，中心结点压力很大；而且 Supervisor 本身也是一个大模型调用，在多轮复杂任务下会累积 token 成本和延迟。
2.2 流水线模式：线性处理复杂任务
流水线模式，也叫 Pipeline 架构。它把多 Agent 系统组织成一条固定的处理链路，每个 Agent 只负责链路上的一个阶段，输入经过所有阶段后产生最终输出。这就像工厂的生产线，原材料依次经过切割、组装、质检、包装，每个环节只做一件事。
这种架构适用于流程稳定、阶段边界清晰、顺序固定的场景。最典型的是内容生成场景：先由选题 Agent 确定主题方向，然后由大纲 Agent 生成文章结构，再由写作 Agent 填充内容，最后由审核 Agent 检查事实性与合规性。每一步的输出就是下一步的输入，中间不需要复杂的路由决策。
面试回答时，要重点突出"契约定义"而不是"流程本身"。因为流水线的核心难点是相邻 Agent 之间如何交接数据。如果你只说"我把上一步的结果传给下一步"，那等于没说。你需要定义好中间产物的 schema：
{ "stage": "outline", "article_id": "a-123", "title": "多 Agent 系统设计指南", "sections": [ { "section_id": "1", "heading": "为什么需要多 Agent", "key_points": ["单 Agent 局限", "任务复杂度", "协作需求"], "word_count_target": 800 } ] }每个 Agent 只认这个 schema，不会收到多余的信息，输出也严格按照 schema 返回。这样做有三个好处：一是每个阶段可以独立测试，用 mock 数据喂给下游；二是出问题时能快速定位是哪一环的数据格式不对；三是新加一个处理阶段时不需要改动其他环节，只要保证接口兼容即可。
流水线的缺点也需要说清楚。首先是错误传播不可忽视，如果第二阶段的输出有错误，第三阶段会在错误基础上继续加工，错误会被逐级放大。所以流水线中必须加入校验节点，可以是一个专门的审查 Agent，也可以是规则过滤器。其次，整条链路的延迟是各环节延迟之和，如果某个环节用了一个很慢的模型，整个流程都会被拖慢。可以考虑的关键优化思路是：把可以并行处理的阶段放在同一层级，比如"资料检索"和"历史对话分析"同时执行，合并之后再进下一阶段。
这个架构在面试里的表达方式可以很结构化：
- 先说明业务场景为什么适合线性处理；
- 定义每个 Agent 的输入输出 schema；
- 说明错误处理和重试策略；
- 给出链路的可观测性设计，比如每个阶段日志带上 request_id。
2.3 网状协作模式：灵活但难以掌控
网状协作模式，也叫 Peer-to-Peer 或 全网状。在这种架构里，没有中心调度节点，所有 Agent 地位平等，它们通过广播、订阅或点对点消息来协商任务的分配和执行。某个 Agent 收到任务后，如果自己处理不了，会向协作网络发送消息，让其他 Agent 帮助完成。
这个架构和现实中的团队协作很像：没有固定 leader，谁擅长什么问题谁就主动认领，互相之间可以讨论、修改、反馈。它非常适合开放式任务，比如头脑风暴、复杂推理、需要多视角交叉验证的场景。
以我熟悉的"多文档综合分析"为例，可以设计多个 Reader Agent 分别阅读不同领域的文档，当其中一个 Agent 发现某个观点需要另外一份文献支持时，直接向持有该文献的 Agent 发起请求，而不需要经过中心节点转发。
网状协作模式的优点很明显：高灵活性，Agent 之间可以动态建立通信路径，适合任务结构难以预先确定的场景；并行度高，多个 Agent 可以同时协作。缺点更明显：系统行为不可预测，可能会产生消息环路、重复劳动或死锁；调试困难，问题出现时需要追踪多个 Agent 之间的消息链路，排查成本比较高；全局状态难维护，谁在执行哪个子任务、哪些消息已经处理过，这些都需要额外的机制来保证。
面试时如果要讲网状协作，一定要展示你对"失控风险"的认识。可以提几个工程保障手段：
- 所有消息带唯一的 message id 和 source agent 标识，配合超时机制；
- 限制消息的最大跳数 max_hop，超过即丢弃，避免无限循环；
- 引入共享黑板（Blackboard），Agent 之间的产物统一写在黑板上，而不是靠点对点消息秀依赖；
- 设置全局任务超时，超过时限触发兜底策略。
代码层面的消息转发伪代码可以这样展示：
# 伪代码：网状协作的消息处理 MESSAGE_ID = itertools.count() MAX_HOP = 5 async def process_message(msg: Message, agents: list[Agent]): if msg.hop_count >= MAX_HOP: logger.warning("message %s exceeded max hop", msg.id) return # 丢弃 interested = [a for a in agents if a.can_handle(msg.task_type)] for agent in interested: reply = await agent.process(msg) if reply.status == "request_more": next_msg = Message( id=next(MESSAGE_ID), task_type=reply.task_type, payload=reply.context, source=agent.name, hop_count=msg.hop_count + 1, ) await process_message(next_msg, agents)面试官听到你主动提出MAX_HOP、消息风暴、黑板的取舍，会觉得你真的踩过坑，而不是只背了概念。
需要注意，网状架构在简历项目里如果没有明确落地的场景，建议不要当成主打方案。因为面试官大概率会追问"你怎么验证最终收敛性""消息乱序怎么处理"，这些问题回答不好反而扣分。如果你确实做过一个小型协作式 Agent 系统，即便数据规模不大，也可以把上述机制讲清楚，这就是加分项。
2.4 分层/层级模式：复杂系统的组织法则
分层架构，也叫 Hierarchical，是在主管-工作者模式之上的递归式扩展。每一层有一个"协调者 Agent"，它管理下一层的若干个 Agent；而下一层的 Agent 也可以是再下一层的协调者。从拓扑上看，它是一个树状结构，而不是单层的 Star 拓扑。
分层模式适合非常复杂、子任务之间又有嵌套关系的系统。比如一个企业级智能运维助手：顶层 Orchestrator 负责理解用户意图，判断是"日志诊断""性能优化"还是"配置变更"；下一层有各自的负责人，比如日志诊断负责人再拆分成日志收集 Agent、异常分析 Agent、修复建议 Agent；再往下可能还需要细分。
用生活的类比来说，这和公司组织架构完全一致：CEO 不直接管每个工程师，而是通过部门经理、团队组长一层层传导目标。每一级只管理自己直接下属的少量 Agent，控制幅度有限，因此整个系统可以扩展得很大，同时每一级仍然保持清晰的责任边界。
面试回答分层架构时，要讲清楚两个关键点：
第一，为什么需要层。答案是控制范围有限。一个 Supervisor 如果直接管理超过 7-8 个 Worker，光是状态跟踪和结果校验就会消耗它大量注意力，准确率明显下降。分层的价值在于把复杂度分摊到树的各个层级，而不是集中在根节点。
第二，逐级传递的语义损耗。上层 Agent 给下层 Agent 派发任务时，需要把抽象的任务描述翻译成子任务；子 Agent 返回结果后，上层还要重新组织成更抽象的语言继续向上传递。这个过程中如果 prompt 工程没做好，信息失真会比较严重。你可以强调每个层级都需要定义"报送格式"，甚至用结构化字段代替自然语言摘要。
分层架构的不足也要主动提及：整体延迟会显著增加，因为请求要沿树向上传递再向下分发；全局优化困难，每一层只做局部最优，最后可能全局次优；成本也更高，因为这个系统里运行着很多个大模型调用。你的表述可以是："所以分层架构适用于复杂度和并发度都高的组织级任务，但对于日常的小工具，用一层 Supervisor 就足够了，不要为了架构而架构。"
2.5 四种架构横向对比与选型逻辑
面试桌上最常出现的问题之一是："如果你来设计一个 XX 系统，你会选哪种架构？"这时你不仅要说选择，还要说选型依据。我习惯用一张表来组织对比：
| 架构类型 | 拓扑结构 | 控制方式 | 典型场景 | 主要风险 | 面试展示重点 |
|---|---|---|---|---|---|
| 主管-工作者 | 星型 | 中心化 | 任务边界清晰、需要审计 | 单点瓶颈、调度复杂度 | 任务分解、校验兜底 |
| 流水线 | 线性链 | 预设顺序 | 内容生成、数据处理流程 | 错误传播、累积延迟 | 数据契约、阶段校验 |
| 网状协作 | 全互联 | 去中心化 | 开放式探索、交叉验证 | 不可预测、调试困难 | 消息机制、环路控制 |
| 分层/层级 | 树状 | 分级协调 | 复杂组织级系统 | 请求延迟、全局优化难 | 递归分解、语义收敛 |
选型逻辑上，我总结为一个简单的判断流程：
- 如果任务结构相对固定，优先考虑流水线，实现简单且易于观测；
- 如果任务有分支且需要统一管控，选择主管-工作者；
- 如果系统规模很大，需要水平扩展，在主管模式之上叠加分层；
- 如果任务非常开放、无法预先编排，只能使用网状协作，但必须设计好安全护栏。
你在回答时能顺着这个思路走，面试官会觉得你不是在背架构清单，而是真的有一套判断方法论。
3. 面试回答的通用框架与表达技巧
3.1 万能答题模板：定义-结构-流程-数据流-容错-权衡
很多同学面试多 Agent 时东一句西一句，聊得散。我后来总结了一个答题模板，叫六步法，基本可以应对所有多 Agent 设计题：
- 定义目标场景：用一句话说清楚系统解决什么问题，用户是谁，输入输出是什么；
- 给出架构图：不用画图，用语言描述拓扑结构，比如"这是一个主管-工作者模式，中间有一个 Supervisor，下方挂 4 个 Worker"；
- 描述核心流程：从拿到用户请求到最终返回，中间分几步，谁执行、谁校检；
- 明确数据流与状态：Agent 之间传什么格式的消息，上下文存在哪里，如何防止上下文越传越乱；
- 说明容错策略：如果某个 Agent 超时、返回错误、或者结果冲突，你是怎么处理的；
- 主动谈权衡：这套设计在成本、延迟、可控性上做了哪些取舍，换一种架构为什么不行。
举个例子，假设面试题是"设计一个企业舆情分析系统"。你可以这样回答：
第一步，场景：需要从全网多源信息中识别与企业相关的敏感舆情，完成风险分级和报告生成。第二步，架构：我采用主管-工作者模式，Supervisor 负责任务拆解与结论汇总，Worker 包括数据采集、实体识别、情感分析、风险研判四个独立 Agent。第三步，流程：用户输入监控主题后，Supervisor 生成监控策略，采集 Agent 抓取信息，实体识别 Agent 提取公司、产品、人物关联，情感分析 Agent 判断态度倾向，风险研判 Agent 综合输出风险等级。第四步，数据流：统一使用 JSON 格式，每个 Agent 只关心自己需要的字段，中间结果放入共享存储，同时保存每个消息的 parent_id 用于链路追踪。第五步，容错：对于采集失败的源，重试两次仍失败则跳过并标记为"采集异常"；情感分析 Agent 输出置信度低于 0.6 时，风险研判 Agent 会要求重新分析一次。第六步，权衡：主管-工作者模式相比网状协作牺牲了灵活性，但换来了审计能力和可调试性，对于金融级舆情场景，可控优先于灵活。
这个模板的优势在于：不管面试官怎么变着法问，你都能把答案包裹在一个完整的工程故事里，而不是零零散散地挤牙膏。
3.2 用案例支撑：把项目经历讲成架构决策
在面试场景中，问答不只是考察知识记忆，更深层的考察点是：你有没有真的搭过系统。最常见的答题陷阱是，候选人只说"我当时用了 Lang 框架 / 用 AutoGen 跑了个 demo"，但没有说明为什么选择这个方案。你可以尝试用"项目背景-约束条件-架构选择-验证结果-反思"的五段式结构来讲述你的项目。注意项目经历需要基于真实工作或学习成果，如果目前没有，可以设计一个小型模拟项目来做。比如你做了一个"多文档问答系统"，当时约束是团队只有一个人，需求是在一个月内上线，文档类型覆盖技术白皮书、法律文本和用户手册。你选择了分层架构，因为三个文档类型差异太大，一个 Agent 处理所有类型的效果不理想。于是顶层路由 Agent 先判断文档类型，再下发给专业 Agent。验证结果是有 200 份测试文档，准确率比单 Agent 提升了 15%，但成本上升了约 40%。反思则是：顶层路由的误判会直接影响下游效果，下一步可以做置信度阈值，低于 0.7 时走人工确认。
这种回答方式好在哪？好在它展示了你的决策能力。你不仅知道架构名字，还知道它在具体约束下为什么是对的、代价是什么、未来如何演进。这比背一百个名词都有效。
3.3 说清楚权衡与边界：避免"万能药"式回答
面试中经常会问"你这个架构有没有缺点？"很多人答不上来，或者试图美化自己的选择。正确的策略是主动承认权衡，并且给出补偿手段。
比如你选的是主管-工作者模式，面试官问瓶颈在哪。你可以说："这个问题确实存在，Supervisor 的上下文容量和调度能力会随着任务数量增加而下降。我的处理方案有两个：一是给 Supervisor 配备外部记忆存储，把长对话历史放到向量库里，不要全部塞进上下文；二是引入子管理层，超过 6 个并发子任务时自动建立二级协调者，把单层 Star 转成两层树。这样做虽然增加了一点延迟，但避免了 Supervisor 过载。"
这个回答里最打动面试官的是"我知道有缺陷，且有具体解法"。这比硬撑说"我的架构没有短板"要可信得多。
同时，你还要有一根弦：多 Agent 不是所有问题的答案。有些任务单 Agent 加一个检索工具就解决了，硬上多 Agent 反而增加延迟、成本和不可控性。面试时如果能说出"这个场景我不推荐多 Agent，因为……"反而能凸显你的判断力。举个例子："如果用户是一个只处理中文短文本的分类器，完全不需要多 Agent。用一个带结构化输出的单模型调用效果更好，因为多 Agent 的收益在于处理需要多角色、多阶段、多视角的复合任务。没有这种复杂度之前，引入多 Agent 只是在制造复杂度。"
4. 高频追问与防坑清单
4.1 状态与记忆：Agent 之间如何共享上下文
追问频率最高的问题之一是："多个 Agent 之间的记忆如何同步？"不少候选人会脱口而出"把它们的历史消息拼在一起发到下一个 Agent 就行"。这在简单场景下确实可行，但一旦 Agent 数量超过 3 个、任务轮次超过 5 轮，这种拼接会让上下文长度失控，而且信息混杂会干扰模型判断。
更稳妥的设计是引入共享记忆层。常见做法是：
- 短期记忆：放在内部的临时存储里，记录当前任务的中间状态，格式化为结构化日志；
- 长期记忆：存入向量数据库，Agent 需要时用 embedding 检索相关记忆片段，而不是全量拼接；
- 工作记忆：每个 Agent 维护一个只与自己任务相关的上下文窗口，避免全局噪音。
你可以举一个很实际的例子：假设一个 Agent 负责收集数据，另一个负责写分析报告。分析 Agent 并不需要知道采集 Agent 访问了哪些 URL、耗费了多少时间，它只需要最后的结构化数据表。因此采集 Agent 的"细节日志"不应该进入分析 Agent 的上下文，只有"结果摘要"需要传递。这个决策可以用一个词概括：上下文最小化。面试官非常吃这一套，因为它体现了你对上下文窗口钱的敏感度。
4.2 错误传播与容错：Agent 答错了怎么处理
面试官很爱问："如果其中一个 Agent 返回了错误结果，你的系统怎么处理？"回答时必须区分两类错误：
第一类是显式错误，比如 API 调用失败、JSON 解析失败、字段缺失。这类问题可以通过重试、降级、熔断机制解决。重试要注意幂等性，如果第一次调用已经产生了副作用，不能贸然重试。
第二类是隐式错误，比如模型本身"一本正经地胡说八道"，输出格式完全正确但内容不对。这类问题最棘手，因为它很难被规则检测。我的处理思路是引入多 Agent 交叉验证：让另一个独立 Agent 对结果进行反向检查，比如总结类任务，让审计 Agent 重新阅读原文并核对摘要中的每一项是否有依据。还可以增加置信度预估机制，要求 Agent 在返回结果时附带置信度，低于阈值时自动进入人工审核队列。
这里有一个值得在面试中展示的小技巧：设计一个"验证 Agent"时，不要给它和被验证 Agent 相同的 prompt，否则它的错误模式会重合。应该让它从一个对立视角出发，比如一个做"生成答案"，一个做"从答案中找漏洞"，只有后者找不到漏洞时才算通过。这就是红队思想在多 Agent 中的应用。
4.3 性能与成本：如何估算多 Agent 的消耗
多 Agent 系统的 token 消耗是单 Agent 的数倍甚至数十倍，面试官问成本和性能其实是想知道你是否有经济头脑。
一个非常实用的估算方法是"单任务成本预算"。拿到需求后，先预估每类 Agent 的输入输出长度：
单次任务 token 预估 = Σ(每个 Agent 的输入 tokens + 每个 Agent 的输出 tokens) 成本预估 = 总 tokens × 每 token 单价如果任务需要 5 个 Agent，每个 Agent 平均消耗 4000 input tokens 和 500 output tokens，那么单次任务的 总 tokens 约为 22500。如果一个方案成本是另一个的 3 倍，但准确率只提升了 2%，那就需要重新考虑是否值得。面试时主动给出这种量化意识是加分项。
性能优化层面可以提三个手段：
- 并行执行：无依赖的 Agent 之间用并发调度，把链路从串行变成并行，总延迟取决于最慢的那个 Agent，而不是所有 Agent 之和；
- 级联模型选择：简单任务用便宜的小模型，复杂任务才路由到大模型，避免所有 Agent 都满载运行；
- 增量上下文更新：不要让每个 Agent 都从头读取全部历史信息，而是把新增信息增量写入共享状态，读取时按需拉取。
4.4 评估与运维：多 Agent 系统怎么测试和监控
这个问题近两年越来越多，因为面试官开始关注系统的工程化程度。你可以从三个层面回答：
- 离线评估：构建一个覆盖典型用户请求的测试集，包含基础正常情况和异常坏例。用统一的指标比较多 Agent 系统与单 Agent 基线，比如任务成功率、关键信息覆盖度、格式合规率。
- 在线监控：为每次请求分配一个 trace_id，贯穿所有 Agent 调用。你需要从日志里能还原出"用户请求→Supervisor 规划→Worker1 执行→纠错→最终回复"的整条链路。任何一个节点失败，都应该在监控面板上可见，而不能只靠用户投诉才发现。
- 效果调优：多 Agent 的优化周期比单 Agent 长得多。一次 prompt 修改可能影响下游多个环节，所以要建立局部回归机制。每次改动某个 Agent 之后，只跑与该 Agent 相关的子测试集，而不是全部任务都回归一遍，这样效率会高很多。
有一个面试中可以用来当亮点的设计：在整体推理链路上设置"影子模式"。新架构上线前，让它和旧架构并行跑，但不对用户输出，只记录结果差异。一个周期后统计"新方案变好、变差、持平"的比例，再决定是否全量切换。这个做法在很多实验平台里叫 shadow test，面试中提出来会给人很强的工程落地感。
4.5 高频追问速查表
| 追问方向 | 可能的追问示例 | 回答要点 |
|---|---|---|
| 架构选型 | 为什么选主管-工作者而不是网状协作？ | 可控性、可审计、任务边界清晰 |
| 数据流 | Agent 之间传递什么格式？ | JSON Schema、共享存储、消息 trace |
| 状态管理 | 上下文都在哪存？ | 短期日志、长期向量库、最小上下文原则 |
| 容错恢复 | Agent 失败怎么办？ | 重试、幂等、降级、失败隔离 |
| 成本控制 | 这个系统贵吗？ | 预算法、级联模型、并行化 |
| 效果验证 | 你怎么确定多 Agent 比单 Agent 好？ | 离线测试集、基线对比、回归测试 |
| 可扩展性 | 再加 10 个 Agent 怎么办？ | 分层架构、控制幅度、服务注册 |
| 团队协作 | 代码怎么多人维护？ | Agent 配置文件独立、契约测试 |
| 安全合规 | 如何防止 Agent 乱说话？ | 输出审核 Agent、Allowlist、人工审批流 |
这份速查表不用全背，重点是每个方向都要有"能展开讲 30 秒"的内容。
5. 加分项：让面试官觉得你真的做过
5.1 用数据契约替代自然语言传递
多 Agent 系统里最容易翻车的地方是消息传递里的信息损耗。很多项目早期用纯自然语言文本在 Agent 之间传结果，比如"我分析完了，发现这个用户有负面情绪"，下游 Agent 再从中抽取关键信息。这种方式的坏处是下游模型会遗漏或误解细节，而且难以自动化测试。
我在实际项目中开始全面推行结构化数据契约后，问题少了很多。每个 Agent 的输出先经过一个 validator，字段缺失、类型错误会在这一步直接拦截，而不是一路带到最终结果里。这种"用 schema 定义接口"的思路在后端开发里是常识，但在 Agent 开发里很多人忽略了。
你在面试中可以这么说："我会为每个 Agent 定义输入输出 Schema，输出先经过 pydantic 校验再进入下一环节。这不是为了炫技，而是为了并行开发和单点测试。A Agent 的开发者可以 mock 一份符合 Schema 的数据喂给 B Agent，不用等真实链路跑通。这样整个系统的迭代速度会快很多。"
5.2 可观测性是生产环境的第一需求
生产环境里的 Agent 系统，你没法指望用户描述"它回答得不对"时你能立刻定位问题。设计日志时，我会为每次 Agent 调用记录以下字段：请求 ID、Agent 名称、输入摘要、输出摘要、token 消耗、延迟、重试次数、校验结果。所有日志汇聚到一个查询界面，输入请求 ID 就能看到完整链路。
面试时你可以把这个设计讲成一个真实故事："有一次线上反馈说某个回答出现事实错误，我只花了几分钟就通过 trace_id 定位到是一名 Worker 在检索阶段召回了一篇来源不明的资料。后来改进方案不是改模型，而是给检索 Agent 增加来源白名单过滤，问题就解决了。"这个故事并不复杂，但能清楚展示你的生产意识。
5.3 降级链路：多 Agent 挂了也不能裸奔
多 Agent 系统可以做得很复杂，但工程上永远要留一条后路。我在搭建系统时，始终设计一个"降级开关"：
- 全功能模式：多 Agent 完整协作；
- 降级模式：只保留最核心的 Agent，其余用规则或检索流程替代；
- 兜底模式：直接调用单 Agent 甚至一个固定的 prompt 模板，保证用户永远能得到响应，而不是超时报错。
面试中如果你能主动讲出这个降级链路，会让面试官把你看作一个有经验的系统设计者，而不是只会写 demo 的人。你可以说："多 Agent 的价值在高复杂度任务上，但鲁棒性才是底线。我宁可损失一部分效果，也不允许整个系统因为某个 Agent 的异常而完全不可用。"
5.4 Agent 自身的 prompt 配置化与资产沉淀
如果你负责的产品里有很多不同职责的 Agent，给每个 Agent 写死 prompt 不是好做法。工程化一些的做法是：每个 Agent 的配置独立为一个文件，包含角色定义、职责边界、可用工具列表、输入输出格式、校验规则、失败处理策略。这样业务调整时只改配置不写代码，新加 Agent 时也能复用已有模板。
这一点在面试里可以体现你的中台思维。你甚至可以主动建议："如果 Agent 数量超过 20 个，我会再建一个 Prompt 版本管理机制，记录每次修改的原因和效果对比，避免团队里几个人各自改 prompt 导致管理混乱。"这种建议说明你不只关注模型效果，还关注团队协作效率。
6. 我对多 Agent 面试准备的实际体会
过去一段时间的模拟面试里，我最大的感触是：能说出架构名字的人很多，能把架构讲成决策过程的人很少。面试官并不是要你默写四种模式的定义，而是想通过你的回答判断：遇到一个开放问题，你能不能拆解、能不能取舍、能不能落地。建议你在准备时多问自己几个为什么：为什么选这个拓扑？为什么在这里用多 Agent 而不是单 Agent？一个 Agent 出错了成本是多少？
有一个很有效的练习方法：拿一个你熟悉的需求，分别用 4 种架构各设计一遍，然后写成一份对比笔记。不需要每种都实现，但在纸面上推演数据流、瓶颈、容错的过程，会让你对架构的理解远比背概念深刻。我自己就是这么做的，后来几乎任何架构问题都能在脑子里快速定位到对应的取舍逻辑。
最后再分享一个小技巧：面试时不需要把 4 种架构全讲一遍，挑最适配题目场景的 1-2 种仔细展开就行，但要让面试官感觉到"其他方案你也会，只是在这个场景里你做了合理选择"。你可以在回答末尾加一句："如果换一个约束条件，比如更看重灵活性而不是可控性，我也许会调整为网状协作，不过需要额外考虑消息风暴问题。"这句话留给面试官的印象，往往比前面的长篇大论更深刻。
