最近面试辅导和模拟面试里多 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并通过结构化的任务描述下发给对应 AgentWorker 执行任务可能需要调用外部 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(stepstep, contextplan.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超过即丢弃避免无限循环引入共享黑板BlackboardAgent 之间的产物统一写在黑板上而不是靠点对点消息秀依赖设置全局任务超时超过时限触发兜底策略。代码层面的消息转发伪代码可以这样展示# 伪代码网状协作的消息处理 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( idnext(MESSAGE_ID), task_typereply.task_type, payloadreply.context, sourceagent.name, hop_countmsg.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 种仔细展开就行但要让面试官感觉到其他方案你也会只是在这个场景里你做了合理选择。你可以在回答末尾加一句如果换一个约束条件比如更看重灵活性而不是可控性我也许会调整为网状协作不过需要额外考虑消息风暴问题。这句话留给面试官的印象往往比前面的长篇大论更深刻。