最近面试了一个做 Agent 项目的候选人简历上写着“熟悉多 Agent 系统”。我问了句如果让你用一个多 Agent 方案解决企业内部知识库问答你会怎么设计他愣了几秒然后开始背框架的组件名。我其实不太在意你用的是什么框架我更想听的是——你手里有哪几种经典架构为什么选这种代价是什么。这篇文章想把这件事一次讲透。多 Agent 系统这个词这两年确实被炒得很热但面试官真正在意的东西并没有变你能不能把一个复杂任务拆成多个可控的单元再让它们通过合理的结构协作。我面试别人也被别人面试积累下来最有效的回答框架就是把 4 种经典架构放在一起讲Supervisor 中心调度、Pipeline 流水线、Collaborator 协作讨论、Hierarchical 层级递归。这篇文章适合两类人一类是正在准备大模型应用岗位面试的开发者另一类是已经做过 Agent 项目但总被追问得很狼狈、想系统整理一遍的工程师。1. 面试官问“多 Agent 系统”到底在考察什么能力1.1 概念可以背但架构思维背不出来很多人一提多 Agent 就搬出“自主规划、工具调用、反思”这些词一听就知道是刚读完概念文章。面试官真正想考察的不是你会不会定义 Agent而是你有没有办法把一个模糊的、非确定性的问题拆成一组可以验收、可以管控、可以降级的子任务。说白了多 Agent 不是为了让系统看起来更高级而是单 Agent 确实解决不了一些问题。比如一个 Agent 又要理解用户意图又要查业务库又要写报告又要自我检查提示词会越写越长上下文越塞越满最后效果一定是不稳定的。你把不同职责拆给不同 Agent每个 Agent 只做一件事反而更容易调优。所以当你讲多 Agent 的时候第一句话不能是“多 Agent 就是多个大模型协同工作”而要直接说“单 Agent 在哪里遇到了瓶颈所以我用多 Agent 来解耦”。面试官要的是这个。1.2 三个高频追问方向提前摸清套路我总结了一下面试官围绕多 Agent 的追问几乎都落在三个方向。第一个方向是“给你一个场景请你做架构选型”。比如设计一个客服助手、设计一个文档处理流程、设计一个代码评审系统。这时他考的是你对任务类型的判断能力这个任务是强流程还是弱流程子任务之间是顺序依赖还是可以并行答案没有唯一标准但你的判断过程必须合理。第二个方向是“针对你简历上的项目深挖异常场景”。面试官会问某个 Agent 答错了怎么办上下文爆了怎么办两个 Agent 结果互相矛盾怎么办这些问题考察的是你有没有真正跑过项目因为只有踩过坑的人才能说出具体兜底手段。第三个方向是“现场推演”。他可能会说如果现在把任务复杂度扩大十倍或者参与 Agent 数量增加十倍你原来的架构还成立吗这个问题看着是开放题其实考的是你能不能意识到架构的扩展边界在哪里以及你有没有主动设计过演进路径。这三个方向都指向同一个核心——你不是在背答案你是在跟面试官证明一件事我遇到问题的时候脑子里有一套完整的“拆解、选型、兜底、演进”的方法论。2. 四种经典架构逐一拆解从内部结构到面试话术2.1 SuperVisor 中心调度模式Supervisor 是很多人接触到的第一种多 Agent 架构。它的结构很像一家公司的“技术总监 若干个交付小组”一个主 Agent 负责任务的接收、理解、拆解和分发然后等待下游 Agent 的结果最后统一汇总反馈给用户。它的核心特点是有一个中心节点。这个中心节点不一定自己做具体任务但要负责两件关键的事情一是意图识别判断当前任务应该交给哪个子 Agent二是任务描述它得把目标清楚地转述给子 Agent。我建议面试时把这个点讲出来因为很多人只会说“主 Agent 负责调度”但说不出调度到底调什么。这里给一个简化的流程示意def supervisor_run(task, agents): # 第一步中心节点做意图识别判断该派给谁 target route(task) # 第二步把任务描述给下游 Agent并执行 result agents[target].run(task) # 第三步做结果校验 / 简单汇总 return validate_or_summarize(result)你要知道这里的意图识别是有可能出错的。如果任务分类错了再强的下游 Agent 也没用所以通常建议在中心节点加一个“置信度阈值”和“兜底策略”比如识别置信度低于某个值时不自动路由而是先要求用户确认或者转人工。Supervisor 模式的优点是好理解、好管控、职责清晰缺点是中心节点容易成为瓶颈而且分类错误的代价会向下游放大。面试里我一般这样收尾这个架构适合任务边界相对明确的场景。如果场景里有很多突发分支我不会硬上 Supervisor而会把低频分支做成独立 Agent 或者人工兜底再统一接到入口。这个兜底意识恰恰是面试官想听的工程化思维。2.2 Pipeline 流水线模式Pipeline 模式也被很多人叫做链式模式。它跟 Supervisor 最大的区别是没有中心调度节点任务处理像工厂流水线一样按固定顺序流过多个 Agent前一个 Agent 的输出就是后一个 Agent 的输入。这种架构非常适合那些步骤固定、依赖关系明确的场景。比如文档处理流程先做格式清洗再做内容抽取再做分类打标最后生成摘要报告。你很难让一个 Agent 同时完成所有步骤但拆成流水线之后每一段的输入输出都是明确的你甚至可以对每段单独做评测。流水线模式的核心是要认清“上一个环节输出什么形态的数据下一个环节需要什么样的输入”。这一步一旦没设计好后面全是坑。伪代码可以写成这样def pipeline_run(data, stages): current data for stage in stages: current stage(current) # 每个阶段输出后都做一次校验防止错误累积 current validate(current) return current这里有一个面试加分点主动说“错误累积”。流水线模式最大的问题不是单点效果差而是前面环节的错误会一路带到后面最终结果经常被最差的一环拖累。所以我一般在面试中会说每个阶段的输出都会用规则或者一个小模型做格式和内容校验不通过就不往下游传。这个“不让脏数据进入下一环”的思路会让面试官觉得你真的懂工程。2.3 Collaborator 协作 / 讨论模式第三种模式和前面两种完全不一样。Collaborator 模式没有中心调度也没有固定的先后顺序多个 Agent 是平级的它们通过互相讨论、评审、修改最后收敛出一个共同结果。你可以理解成是一屋子专家在开圆桌会议不是领导派活而是互相挑毛病。这种模式最适合那些需要多视角验证的任务。举个例子代码评审系统里可以有一个 Agent 专门看逻辑漏洞一个 Agent 专门看代码规范一个 Agent 专门写修复建议最后它们互相 review 几轮产出一份综合评审报告。再比如需要多角色协作的写作任务让一个 Agent 写初稿另一个 Agent 从用户视角提出修改意见第三个 Agent 做最终润色。协作模式要注意的是“终止条件”。没有终止条件的协作就是一场没有尽头的会议。我建议面试时主动讲这个点每一轮协作都会检查结果是否收敛如果两个 Agent 连续两轮互相否决且没有新增意见就强制结束并交给仲裁逻辑处理甚至直接取置信度更高的版本。协作模式如果没有轮次上限token 成本会飞上天。伪代码示意def collaborator_run(question, agents, max_rounds3): draft agents[0].response(question) for i in range(max_rounds): reviews [a.review(draft) for a in agents[1:]] merged merge_feedback(reviews) if not merged: break # 没有新意见提前收敛 draft improve(draft, merged) return draft面试中讲 Collaborator 模式时我会强调它的优势是灵活、鲁棒单点挂了其他节点还能继续。但要立刻补一句代价一致性和可解释性成本更高因为你很难说清楚最终结果是谁贡献的。能主动权衡优缺点这本身就是加分项。2.4 Hierarchical 层级递归模式第四种是 Hierarchical 层级递归模式也叫树状模式。它的核心思想是顶层 Agent 不直接执行到底而是把任务拆成子任务分给第二层 Agent第二层如果还搞不定再继续往下拆直到子任务足够简单再由一个具体执行的 Agent 完成。这个架构非常适合超大目标的拆解。比如做一个全站自动化运营 Demo目标是“根据本周数据生成一份完整的下周运营方案”顶层 Agent 先拆成数据分析、用户洞察、活动策划、风险控制几个板块每个板块的负责 Agent 再继续拆更细的动作。你会发现越往下的 Agent任务越聚焦上下文越短反而越稳定。层级递归模式的设计关键是“层深”和“分支数”。层数不是越深越好一般 2 到 3 层就够再深就会出现“拆出来的子任务没人认领”的问题。分支数也不要贪多一个节点的子节点数量控制在 3 到 5 个以内方便冲突仲裁。def hierarchical_run(task, depth0): if depth MAX_DEPTH or is_simple_task(task): return base_agent.run(task) sub_tasks split_task(task) results [hierarchical_run(t, depth 1) for t in sub_tasks] return merge_results(results)这个模式在面试中的表达比较容易出彩因为你可以讲它对“上下文控制”的帮助每一层只保留自己那一层的摘要和子任务结果不会把全量信息一次性塞进模型。换句话说你不是用层级模式显得复杂而是用它来对抗超长上下文的失控。这个理由非常务实。2.5 四种架构对比速查表我自己在面试前会把这四种架构在脑子里过一遍表格这里直接分享出来架构一句话类比适合场景主要风险面试加分话术Supervisor技术总监派活任务边界清晰、子能力可枚举中心节点瓶颈、意图分类错误放大入口统一、扩展方便但要有置信度兜底Pipeline工厂流水线强流程、固定步骤错误逐级累积每阶段校验、隔离脏数据Collaborator圆桌会议多视角评审、互相修正死循环、成本不可控设置终止条件结果收敛机制Hierarchical公司组织架构复杂目标、规模大拆解不完整、信息损耗控制层深用分层对抗长上下文面试时这张表不用背但你要能现场画出来。画不出来也没关系重要的是讲每一个架构时你都能说出它的代价而不是只讲优点。3. 面试中的架构选型三个决策条件帮你给出有理有据的答案3.1 选型之前先问自己三个问题我发现很多人在面试中一说到“怎么选架构”就开始凭感觉这是最容易扣分的地方。其实选型是有迹可循的我建议按下面三个问题依次过一遍。第一个问题任务能不能预先拆成稳定步骤如果能而且执行顺序几乎不变直接考虑 Pipeline如果步骤本身不确定每一步要依赖前一步的结果来决策Pipeline 就不合适要考虑 Supervisor 或 Collaborator。第二个问题子任务之间是强依赖还是弱依赖强依赖是指后一步必须拿到前一步的完整结果这时候 Pipeline 天然合适。弱依赖是大家各自负责一块最后拼到一起这时候 Supervisor 的并行派发效率更高。第三个问题单个 Agent 要处理的上下文量级有多大如果任务本身非常大一次性塞给谁都会超窗这时候就需要 Hierarchical 做逐级拆解。如果任务不大但涉及不同专业视角Collaborator 更合适。这三个问题一过架构基本就浮出来了。面试中你只要把这个判断过程讲出来比直接丢结论有说服力得多。3.2 一张表对应常见面试场景拿面试官常出的场景来举例大致可以这样匹配面试常见场景推荐架构核心理由企业内部知识库问答助手Supervisor不同数据源、不同专业域拆成子 Agent统一入口路由多步骤文档处理上传文件到输出报告Pipeline处理顺序固定前一步输出决定后一步输入代码评审 / 合同审查Collaborator需要多个专家视角互相验证结论更可靠复杂经营分析 / 大型方案产出Hierarchical任务大需要逐级拆解避免单 Agent 上下文爆炸一个入口同时服务多个低频长尾需求Supervisor 人工兜底分类不确定时先确认再路由不过要声明一点这个表是经验参考不是标准答案。面试的时候你要强调“我的选型依据是任务特征”而不是“我背了这张表”。3.3 主动说混合架构和演进路径是拉开差距的关键真实生产环境里很少有一个系统从头到尾只靠一种架构。我见过很多案例最后都是混合的。比如一个内容审核 Demo主入口是 Supervisor审核流程内部却是一个 Pipeline审到高风险内容时又会让一个 Collaborator 小组介入讨论。这种演进路径是面试中非常值的加分项。你可以这样说第一版先用 Supervisor 把东西跑通跑通后发现某一个子 Agent 经常出错于是把它替换成一个小的 Collaborator 小组再往后流程固定了又把其中某些环节收编成 Pipeline。一个系统不会一夜之间长成最终形态它一定是基于真实反馈逐步变复杂的。面试官听到这种回答就会觉得你不是在做演示项目而是在用工程思维解决问题。4. 多 Agent 面试中的高频追问与避坑指南4.1 上下文爆炸和 Token 成本怎么答追问方式通常是多个 Agent 如果各自都要拿全部上下文Token 翻好几倍你怎么控制这里建议回答框架是“局部上下文 摘要层 按需拉取”。每个 Agent 只拿自己关心的那部分上下文不需要全局信息。比如客服系统里订单 Agent 只需要订单上下文退款 Agent 只需要退款单和用户历史记录而公共信息只做一份全局摘要。RAG 也是这时候的好帮手需要什么信息就检索什么信息而不是把所有内容都塞进 prompt。另外一个很重要的点是主动说“Token 预算”。我在实际项目里会为每一个 Agent 单独设置输出长度上限特别是中间过程的输出能短就不要长。不要小看这一步很多系统失控就是因为在中间环节疯狂输出最后每一步都在为 TDK 的浪费买单。最怕听到的回答是“我们直接用更大上下文窗口的模型”。这不是不对而是不经济。面试官想听到的是你做过程序员的思考而不是只会换硬件。4.2 结果不一致和容错问题怎么答这个追问几乎是必考的你多 Agent 系统里每个 Agent 各说各话结果不一致怎么办回答可以先从“仲裁机制”开始。如果一个任务有多个 Agent 参与就需要一个明确规则优先级高的 Agent 说了算还是投票机制还是靠另一个评审 Agent 做最终裁决。一定要提前定好不要靠模型现场“随机应变”。然后是失败处理。任何一个下游 Agent 都可能超时、返回空结果、或者结果格式不对。我的做法是给每个任务维护一个状态机pending、running、succeeded、failed、retrying。超过重试次数就走降级流程比如返回一个通用兜底结果或者直接转人工。面试中讲到这里时我习惯补一句多 Agent 系统的可靠性不是靠某一个 Agent 有多强而是靠整套任务状态的可观测性。所有关键节点要能记录日志、能回放否则出了问题你根本不知道是哪个环节丢的。4.3 工具调用权限和多角色安全边界多 Agent 和单 Agent 最大的区别之一是“工具权限变多了”。每个 Agent 可能都要调用外部 API、查询数据库、读写文件。如果所有 Agent 共享同一份权限风险非常高。我建议面试时主动讲最小权限原则每个 Agent 只能调用自己职责范围内的工具。比如负责查询天气的 Agent 不应该能操作数据库负责写邮件的 Agent 不应该能读财务系统。同时工具调用前加中间准入层校验参数是否合法而不是让 Agent 直接裸调。还有一个很多人忽略的点多 Agent 会放大提示注入的风险。如果某个 Agent 拿到的是外部内容它有可能把这个内容当成指令再去影响其他 Agent。我的习惯是任何 Agent 从外部拿到的内容都要先过一层“内容清洗”再结构化传参绝不允许把原始外部文本直接拼进另一个 Agent 的指令前缀里。这两点讲出来面试官会觉得你的安全意识很到位。4.4 高频追问速查清单离开面试考场前我把这些年常见的追问整理成了一张表面试官追问建议回答骨架避坑提醒多个 Agent 上下文重复Token 成本高怎么办局部上下文、全局摘要、RAG 按需拉取别说“换更长上下文的模型”两个 Agent 结果冲突怎么办仲裁优先级 / 投票 / 独立评审别让模型自己随机选一个某个 Agent 一直报错怎么办超时、重试、降级、人工兜底别只说“调 prompt”如何评判多 Agent 系统的效果子任务成功率 最终任务完成率 人工抽检别只报一个整体正确率如何保证每个 Agent 不越权最小权限、参数校验、调用日志别觉得 Agent 不会乱来如何防止 Agent 互相带偏拆分输入来源、清洗外部内容、限制交流层级别让低质量 Agent 直接写指令这张表你可以自己再丰富。关键是每个问题你都得有至少一套“可落地的做法”哪怕面试官没全问到你主动带出来也能显示出你的实战积累。5. 从被面到面别人我总结出的几个表达心得第一个心得开口先讲一句话定义再用类比展开。比如“Supervisor 模式就是一个总监把活拆给几个专业小组各自干完再由总监汇总”。先给面试官一个锚点后面的细节他才跟得上。第二个心得先画结构再讲代码不要把面试官淹没在细节里。很多候选人一开始就贴配置、贴参数面试官根本没建立全局感。正确顺序是先说架构图再说关键模块最后才说你自己改过的参数。第三个心得主动谈代价。一个上来只说多 Agent 多牛、而不说成本多高的候选人我一般不会给高分。因为生产环境里每一轮 Agent 调用都在烧钱、都在增加延迟能意识到这部分说明你真的上过线。第四个心得把“没用过某某框架”转换成“我不依赖特定框架”。框架只是工具面试官更想确认你理解底层机制。就算你只写过标准库只要能说清楚状态节点和通信流程也一样有价值。第五个心得讲失败案例比讲成功案例更值钱。我面试时主动说过一个因为没加 Agent 轮次上限、结果整个系统跑了一个小时还没停的教训。面试官听完反而追着问细节。真实感这东西比包装出来的完美重要得多。第六个心得别把 Agent 拟人化得太厉害。说“Agent 觉得”“Agent 想”会让你显得不专业更准确的说法是“模型基于当前上下文生成了什么”。你是在管理概率分布不是在管理一群有自我意识的下属。第七个心得把面试当作方案评审。不要等着被一句一句问你可以主动说“我接下来从选型、成本、风险、演进四个角度展开”。一旦你掌握了叙述节奏面试官就会顺着你的框架去提问你反而更从容。第八个心得最后一定要留一个“可继续优化”的尾巴。比如讲完一个系统后说如果我现在重新设计会把某个环节改成异步机制。这短短一句让人觉得你有一种不断迭代的习惯而迭代能力恰恰是这个领域最稀缺的素质。说回我自己的经历。面了这么多候选人之后我越来越确定一件事多 Agent 系统面试的核心不是考你是不是看过最新的技术报告而是考你面对一个不确定的复杂问题时有没有能力给它套上结构、边界和兜底策略。概念名词谁都能说但能把四种架构讲清楚、讲出代价、讲出演进路径的人才是真正干活的人。下次面试前试着把四种架构各找一个亲手做过的场景去套一遍你会有完全不一样的感觉。