1. 多 Agent 系统面试的底层逻辑拆解
面试里被问到多 Agent 系统，很多人第一反应是背概念：什么 Agent 是能感知环境并做出决策的智能体，多 Agent 就是多个智能体协作。这种回答在初级面试里勉强能过，但一旦面试官往深了追问“那你说说具体怎么协作”“通信怎么设计”“冲突怎么解决”，立刻就露馅了。我面过不少人，也被人面过，这个问题的核心从来不是考你知不知道多 Agent 这个词，而是考你有没有真正想过：多个智能体凑在一起，到底怎么组织、怎么分工、怎么保证整体不崩盘。
多 Agent 系统本质上是一个分布式决策系统。你可以把它类比成一个公司：每个 Agent 是一个员工，有的负责调研，有的负责写代码，有的负责审核。公司要运转，就得有组织架构、有沟通机制、有决策流程。面试官想听的，就是你对这套“组织架构”的理解。你选什么架构，取决于任务复杂度、Agent 之间的依赖关系、以及你对可靠性、成本、延迟的权衡。这跟选微服务还是单体架构是一个道理，没有银弹，只有取舍。
这篇文章我整理了四种经典的多 Agent 架构模式，每一种都从“为什么这么设计”讲到“面试怎么答”，再补上实操中容易踩的坑。不管你是准备面试，还是真的要在项目里落地多 Agent 系统，这些内容都能直接拿去用。我会尽量用大白话把原理讲透，同时给出可以直接复现的代码骨架和参数建议，让你不光能答，还能做。
1.1 为什么面试官爱问多 Agent 架构
单 Agent 系统的问题很明显：一个模型再强，它的上下文窗口有限，工具调用能力有限，而且一旦任务链条变长，错误会累积放大。多 Agent 的思路就是分而治之，把一个大任务拆成若干子任务，每个子任务交给专门的 Agent 处理，最后汇总结果。这个思路听起来简单，但落地时会遇到一堆问题：Agent 之间怎么传递信息？如果两个 Agent 给出矛盾结论怎么办？某个 Agent 卡住了整个流程怎么继续？
面试官问架构，其实是在考察你有没有系统性思维。你能不能把一个模糊的需求拆解成清晰的角色和流程？你能不能预判哪些环节容易出问题？你能不能在设计阶段就把容错和可观测性考虑进去？这些能力比你会不会调 API 重要得多。我见过太多候选人，代码写得挺溜，但一问架构就只会说“让它们互相聊天”，这种回答基本就止步于一面了。
1.2 四种架构的适用场景速览
在展开细节之前，先用一张表把四种架构的核心特征和适用场景列出来，方便你建立整体认知。后面每个章节会逐一深入拆解。
| 架构模式 | 核心思想 | 适用场景 | 面试考察重点 |
|---|---|---|---|
| 流水线式 | 按固定顺序依次处理 | 步骤明确、依赖线性的任务 | 流程设计、错误传递 |
| 主管-下属式 | 一个协调者分配任务给执行者 | 任务可并行、需要汇总 | 任务分解、结果聚合 |
| 辩论式 | 多个 Agent 互相质疑和修正 | 需要高可靠性判断的任务 | 冲突解决、收敛策略 |
| 黑板式 | 共享空间逐步完善方案 | 复杂、非结构化问题 | 状态管理、触发机制 |
这四种不是互斥的，实际项目里经常混用。比如一个主管-下属系统里，某个子任务可能用辩论式来提升质量。面试时你可以先给出分类框架，再结合具体场景说明你会怎么选，这样回答既有结构又有深度。
2. 流水线式架构：最直观但也最容易踩坑
流水线式是多 Agent 系统里最容易理解的模式：Agent A 处理完把结果交给 Agent B，B 处理完交给 C，像工厂流水线一样。比如一个内容生产系统，Agent A 负责选题，Agent B 负责写初稿，Agent C 负责润色，Agent D 负责配图建议。每个 Agent 只关心自己的环节，输入输出定义清楚就行。
这种架构的优势是逻辑清晰、易于调试。哪个环节出了问题，直接看那个 Agent 的输入输出就能定位。而且每个 Agent 的提示词可以独立优化，不会互相干扰。但它的缺点也很致命：错误会沿着流水线累积。如果 Agent A 的选题偏了，后面 B、C、D 做得再好也是白费。而且流水线是串行的，总延迟等于所有环节延迟之和，对于实时性要求高的场景不太友好。
2.1 流水线式的设计要点与参数选择
设计流水线时，最关键的是定义清楚每个环节的输入输出契约。我习惯用结构化的格式来约束，比如 JSON Schema，这样上游的输出必须符合下游的输入要求，否则直接报错而不是让错误悄悄传递。举个例子，选题 Agent 的输出必须包含topic、target_audience、key_points三个字段，写稿 Agent 的输入就校验这三个字段是否存在。
另一个要点是设置检查点。不是每个环节都需要检查，但在关键节点上加一个验证 Agent 能大幅降低错误传播的概率。比如在初稿完成后加一个事实核查 Agent，如果发现事实错误就打回重写，而不是让错误进入润色环节。这个验证 Agent 可以用不同的提示词策略，甚至用不同的模型，形成交叉验证。
参数方面，我一般会给每个环节设置最大重试次数和超时时间。重试次数建议 2-3 次，太多会浪费时间，太少可能因为偶发问题失败。超时时间根据任务复杂度定，简单的分类任务 10 秒足够，复杂的生成任务可能需要 60 秒以上。这些参数要写在配置里，方便调整。
# 流水线式架构的简化骨架 class PipelineAgent: def __init__(self, name, prompt_template, input_schema, output_schema, max_retries=2, timeout=30): self.name = name self.prompt_template = prompt_template self.input_schema = input_schema self.output_schema = output_schema self.max_retries = max_retries self.timeout = timeout def process(self, input_data): # 校验输入 self.validate(input_data, self.input_schema) for attempt in range(self.max_retries): try: result = self.call_llm(input_data) self.validate(result, self.output_schema) return result except ValidationError as e: if attempt == self.max_retries - 1: raise input_data = self.add_error_feedback(input_data, str(e))上面这段代码展示了流水线 Agent 的核心逻辑：输入校验、重试、输出校验。实际项目中你还需要加上日志记录和耗时统计，方便后续分析瓶颈在哪。
2.2 面试中如何描述流水线架构
面试时被问到流水线，你可以这样组织回答：先说明适用场景，比如“当任务可以拆成明确的线性步骤时，我会优先考虑流水线式”。然后讲设计要点，重点提输入输出契约和检查点机制。接着主动说出局限性，比如“串行导致延迟高，错误会累积”，再给出你的应对方案，比如“在关键节点加验证 Agent，同时设置重试和降级策略”。
这样回答的好处是，你不仅展示了你知道什么，还展示了你知道什么时候不该用它。面试官会觉得你有实战判断力，而不是只会套模板。我面人的时候，最怕听到“流水线就是一个个处理”这种干巴巴的描述，完全没有设计思考。
注意：流水线式不适合步骤之间有强交互的任务。如果下游需要根据上游的中间状态动态调整策略，流水线就会很别扭，这时候应该考虑主管-下属式或黑板式。
2.3 实操中的避坑经验
我在实际项目里用流水线踩过最大的坑是上下文丢失。每个 Agent 只拿到上一个 Agent 的输出，但有些任务需要全局信息。比如润色 Agent 如果不知道原始需求，可能会把专业术语改成通俗表达，反而偏离了目标读者。解决办法是在每个环节的输入里都带上原始任务描述，让 Agent 始终知道自己在为什么目标服务。
另一个坑是格式漂移。上游 Agent 这次输出 JSON，下次可能输出 Markdown，导致下游解析失败。我的做法是在提示词里用 few-shot 示例固定格式，同时在代码层面做严格的 schema 校验，不符合就重试。重试时把校验错误信息反馈给模型，让它知道哪里不对。实测下来，加上错误反馈后，格式合规率能从 70% 提升到 95% 以上。
3. 主管-下属式架构：任务分解与结果聚合的艺术
主管-下属式（也叫 Orchestrator-Worker 模式）是我在项目里用得最多的一种架构。它的核心思想是：一个主管 Agent 负责理解任务、拆解子任务、分配给下属 Agent，最后收集结果并汇总。下属 Agent 各自独立执行，互不干扰。这种架构特别适合任务可以并行、子任务之间依赖较少的场景，比如市场调研、多源信息汇总、批量内容生成。
跟流水线相比，主管-下属式的优势在于并行度高、扩展性强。你可以根据任务量动态增加下属 Agent 的数量，主管负责协调。而且下属 Agent 可以用不同的模型或提示词，针对不同子任务做优化。但它的难点也很明显：任务分解的质量直接决定最终效果。如果主管把任务拆错了，下属做得再好也没用。另外，结果聚合也是个技术活，多个下属返回的信息可能有重复、矛盾、遗漏，怎么合并成一份高质量的最终输出，需要仔细设计。
3.1 主管 Agent 的任务分解策略
任务分解是主管-下属式的核心。我试过几种策略，各有优劣。最简单的是按维度分解，比如调研一个行业，就按市场规模、竞争格局、技术趋势、政策环境等维度拆。这种拆法适合结构化程度高的任务，主管只需要知道有哪些维度就行。另一种是按步骤分解，比如写一份报告，拆成收集资料、整理大纲、撰写正文、审核修改。这种适合流程明确的任务。
更复杂的是动态分解，主管先做一个初步分析，根据分析结果决定下一步拆什么。比如先让一个下属去搜索相关信息，主管看到结果后再决定深入哪些方向。这种策略灵活但成本高，因为主管需要多轮推理。我一般会在任务复杂度高、预先不知道有哪些子任务时用动态分解，否则优先用静态分解，省时省力。
分解时有个关键原则：每个子任务必须可独立执行且结果可验证。如果两个子任务需要频繁交互，那就不该拆开，应该合并成一个。我见过有人把“写一篇文章”拆成“写第一段”“写第二段”，这就很蠢，因为段落之间需要连贯，拆开反而增加协调成本。正确的拆法可能是按章节拆，或者按“写初稿”和“润色”拆。
3.2 结果聚合的三种模式
下属 Agent 返回结果后，主管需要聚合。我总结了三種模式，按复杂度递增。
第一种是拼接式，直接把所有结果按顺序拼起来。适合子任务结果相互独立的情况，比如收集了十个城市的天气信息，直接列出来就行。这种最简单，但只适用于结果之间没有逻辑关系的情况。
第二种是摘要式，主管对每个结果做摘要，然后合并成一份精简报告。适合信息量大、需要提炼的场景。比如十个下属各自调研了一个竞品，主管需要提炼出每个竞品的核心差异点，而不是把十份完整报告堆在一起。摘要式聚合需要主管有较强的信息压缩能力，提示词里要明确“提取关键信息，去除冗余”。
第三种是综合式，主管不仅汇总，还要做推理和判断。比如多个下属对同一个问题给出了不同答案，主管需要分析哪个更可信，或者综合出一个新结论。这种模式对主管 Agent 的能力要求最高，通常需要用更强的模型，并且给它足够的上下文来做判断。我在做技术方案评估时用过这种模式，让下属分别从性能、成本、可维护性三个角度评估，主管综合三方意见给出最终建议。
| 聚合模式 | 适用场景 | 主管能力要求 | 典型提示词策略 |
|---|---|---|---|
| 拼接式 | 结果独立、无需加工 | 低 | 按顺序列出所有结果 |
| 摘要式 | 信息量大、需要提炼 | 中 | 提取每个结果的关键点并合并 |
| 综合式 | 结果有冲突、需要判断 | 高 | 分析各方观点，给出综合结论 |
3.3 面试回答框架与实操代码
面试时被问到主管-下属式，我建议按“场景-分解-执行-聚合”四步来答。先说适用场景，强调并行和扩展性。然后讲分解策略，说明你会根据任务特点选择静态或动态分解。接着讲执行，提一下下属 Agent 的隔离性和独立重试。最后讲聚合，把三种聚合模式说出来，并说明你会根据结果之间的关系选择。
# 主管-下属式架构的简化骨架 class Orchestrator: def __init__(self, workers, aggregator): self.workers = workers # 下属 Agent 列表 self.aggregator = aggregator # 聚合器 def run(self, task): # 第一步：分解任务 subtasks = self.decompose(task) # 第二步：并行执行 results = [] for subtask in subtasks: worker = self.select_worker(subtask) result = worker.execute(subtask) results.append(result) # 第三步：聚合结果 final_output = self.aggregator.aggregate(results, task) return final_output def decompose(self, task): # 调用主管模型进行任务分解 prompt = f"将以下任务拆解为可独立执行的子任务：{task}" return call_llm(prompt)这段代码的关键在于decompose和aggregate两个方法，它们决定了整个系统的上限。实际项目中，我会给主管 Agent 加上“分解结果校验”步骤，确保拆出来的子任务数量合理、描述清晰、没有重叠。如果分解结果不合格，就让主管重新拆，最多重试两次。
提示：下属 Agent 的数量不是越多越好。我实测下来，超过 8 个下属后，主管的聚合质量会明显下降，因为上下文太长，模型容易忽略细节。如果任务确实需要很多下属，可以考虑分层，先分成几个大组，每组再设一个子主管。
3.4 常见失败模式与应对
主管-下属式最常见的失败是任务分解粒度不当。拆得太粗，下属执行不了；拆得太细，协调成本超过收益。我的经验是，每个子任务的预期执行时间在 10 到 60 秒之间比较合适。如果某个子任务预计超过 2 分钟，就考虑再拆；如果少于 5 秒，就考虑合并。
另一个失败模式是下属返回空结果或错误结果。主管需要能识别这种情况并决定是重试、跳过还是换一个下属。我一般会让下属在返回结果时附带一个置信度评分，主管根据评分决定是否采纳。置信度低的就重试或换人，置信度高的直接采纳。这个机制能显著提升整体稳定性。
4. 辩论式架构：用对抗提升判断质量
辩论式架构的思路跟前面两种完全不同。它不是把任务拆开，而是让多个 Agent 对同一个问题给出各自的答案，然后互相质疑、辩论，最终收敛到一个更可靠的结论。这种架构特别适合需要高可靠性判断的场景，比如事实核查、方案评估、风险分析。单个模型可能会犯错，但多个模型从不同角度审视，错误被发现的概率就大大增加。
辩论式的核心价值在于对抗性验证。一个 Agent 提出观点，另一个 Agent 专门找漏洞，第三个 Agent 做裁判。这种机制能有效减少幻觉和偏见。但它的成本也最高，因为同一个问题要被处理多次，而且辩论轮数越多，成本越高。所以辩论式通常用在关键决策上，而不是所有任务都用。
4.1 辩论式的角色设计与轮次控制
一个典型的辩论式系统包含三种角色：提议者、质疑者、裁判。提议者负责给出初始答案和论据，质疑者负责挑毛病、提出反例，裁判负责听取双方意见后做出最终判断。角色可以固定，也可以轮换，轮换的好处是避免某个 Agent 形成固定偏见。
轮次控制是辩论式的关键参数。轮次太少，问题没充分暴露；轮次太多，成本高且可能陷入无意义的争论。我一般设置 2-3 轮辩论。第一轮提议者陈述，质疑者反驳；第二轮提议者回应质疑并修正观点，质疑者再反驳；第三轮裁判总结并裁决。如果第二轮后双方已经达成一致，可以提前结束。
# 辩论式架构的简化骨架 class DebateSystem: def __init__(self, proposer, challenger, judge, max_rounds=3): self.proposer = proposer self.challenger = challenger self.judge = judge self.max_rounds = max_rounds def run(self, question): history = [] # 第一轮：提议者给出初始答案 proposal = self.proposer.propose(question) history.append(("proposer", proposal)) for round_num in range(self.max_rounds): # 质疑者反驳 challenge = self.challenger.challenge(question, history) history.append(("challenger", challenge)) # 提议者回应 response = self.proposer.respond(question, history) history.append(("proposer", response)) # 检查是否达成一致 if self.is_converged(history): break # 裁判裁决 verdict = self.judge.decide(question, history) return verdict这段代码里，is_converged是一个关键方法，用来判断辩论是否已经充分。我通常会让裁判 Agent 来做一个中间判断，如果裁判认为双方观点已经清晰、分歧点明确，就可以提前结束辩论。这样能省下不少成本。
4.2 辩论式在面试中的表达技巧
面试时讲辩论式，重点要突出你对可靠性的追求和对成本的权衡。你可以说：“对于需要高可靠判断的任务，我会用辩论式，让多个 Agent 交叉验证。但我会控制辩论轮数在 2-3 轮，并且设置收敛条件，避免无休止争论。”这样既展示了你知道这个架构，又展示了你有成本意识。
面试官可能会追问：“如果辩论双方一直无法达成一致怎么办？”这时候你可以说：“我会让裁判 Agent 做最终裁决，并且记录分歧点。如果分歧涉及事实性问题，我会引入外部工具验证，比如搜索或数据库查询。如果分歧涉及主观判断，我会把双方观点都呈现给用户，让用户决定。”这个回答展示了你的兜底思维。
注意：辩论式不适合有明确标准答案的任务。如果一个问题有唯一正确答案，直接验证就行，不需要辩论。辩论式适合的是那些需要权衡、判断、评估的任务。
4.3 实操中的成本控制与质量平衡
辩论式最大的问题是成本。三个 Agent 各跑三轮，token 消耗是单 Agent 的九倍以上。我在项目里用过几种控制成本的方法。一是动态轮次，简单问题一轮就结束，复杂问题才跑满三轮。二是模型分级，提议者和质疑者用中等模型，裁判用强模型，因为裁判需要做最终判断。三是缓存复用，相同问题的辩论结果缓存起来，避免重复计算。
质量方面，我发现质疑者的提示词设计最关键。如果质疑者只是泛泛地说“我觉得不对”，辩论就没有价值。好的质疑者提示词应该引导它从具体维度挑毛病，比如“检查论据是否充分”“检查逻辑是否有漏洞”“检查是否有反例”。我通常会给质疑者一个检查清单，让它逐项核对，这样挑出来的问题更具体、更有价值。
5. 黑板式架构：复杂问题的渐进式求解
黑板式架构源自经典的人工智能系统，核心思想是：多个 Agent 共享一个“黑板”（共享数据空间），每个 Agent 都可以读取黑板上的信息，根据自己的专长往黑板上添加新信息，直到问题被解决。这种架构特别适合问题结构不清晰、需要多领域知识协作的场景，比如复杂故障诊断、多学科方案设计。
跟前面三种架构相比，黑板式的最大特点是没有固定的执行顺序。哪个 Agent 在什么时候被触发，取决于黑板上的当前状态。比如黑板上出现了“疑似硬件故障”的信息，硬件诊断 Agent 就被触发；出现了“疑似软件配置问题”，软件诊断 Agent 就被触发。这种事件驱动的机制让系统非常灵活，但也增加了设计和调试的难度。
5.1 黑板式架构的核心组件
一个黑板式系统包含三个核心组件：黑板、知识源、控制单元。黑板是共享数据结构，存储所有中间状态和结果。知识源就是各个 Agent，每个 Agent 负责特定领域的处理。控制单元决定下一步触发哪个 Agent，它根据黑板上的状态和预定义的触发规则来做决策。
黑板的存储结构设计很关键。我一般用分层结构：最底层是原始输入，中间层是各个 Agent 产生的中间结果，最上层是最终方案。每个 Agent 往黑板上写数据时，要标注来源、时间戳、置信度，方便其他 Agent 判断信息的可靠性。控制单元的触发规则可以用简单的条件判断，也可以用规则引擎，甚至用一个小模型来做决策。
# 黑板式架构的简化骨架 class Blackboard: def __init__(self): self.data = {} # 分层存储 self.history = [] # 操作历史 def write(self, key, value, source, confidence): self.data[key] = { "value": value, "source": source, "confidence": confidence, "timestamp": time.time() } self.history.append((key, source)) def read(self, key): return self.data.get(key) class KnowledgeSource: def __init__(self, name, condition, handler): self.name = name self.condition = condition # 触发条件 self.handler = handler # 处理逻辑 def can_trigger(self, blackboard): return self.condition(blackboard) def execute(self, blackboard): result = self.handler(blackboard) blackboard.write(self.name, result, self.name, 0.8) class ControlUnit: def __init__(self, sources): self.sources = sources def run(self, blackboard, max_iterations=20): for _ in range(max_iterations): triggered = [s for s in self.sources if s.can_trigger(blackboard)] if not triggered: break # 选择优先级最高的知识源执行 source = self.select_highest_priority(triggered) source.execute(blackboard) return blackboard.data这段代码展示了黑板式的核心循环：检查触发条件、选择知识源、执行、写回黑板。实际项目中，select_highest_priority可以用简单的优先级数字，也可以用更复杂的策略，比如根据历史成功率动态调整。
5.2 面试中如何展示黑板式的理解
黑板式是四种架构里最少被候选人提到的，如果你能在面试中主动提到它，会是一个加分项。你可以这样引入：“除了常见的流水线和主管-下属，还有一种黑板式架构，适合问题结构不清晰、需要多领域协作的场景。”然后解释黑板、知识源、控制单元三个组件，重点说明事件驱动的触发机制。
面试官可能会问：“黑板式和主管-下属式有什么区别？”你可以说：“主管-下属式是主管主动分配任务，控制流是自上而下的；黑板式是 Agent 根据黑板状态被动触发，控制流是事件驱动的。主管-下属式适合任务可预先分解的场景，黑板式适合任务边界模糊、需要逐步探索的场景。”这个对比能展示你对两种架构的本质理解。
提示：黑板式在面试中不需要讲得太细，除非面试官明确追问。因为它的实现复杂度高，实际项目里用得相对少。但知道它的存在和适用场景，能体现你的知识广度。
5.3 实操中的状态管理与触发优化
黑板式最大的实操难点是状态爆炸。随着 Agent 不断往黑板上写数据，黑板会越来越大，控制单元的选择成本也会增加。我的做法是给黑板设置过期机制，超过一定时间或一定轮次的数据自动降权或归档。另外，每个 Agent 写入时要做去重检查，如果黑板上已有相同信息，就不重复写入。
触发优化方面，我试过用优先级队列来管理知识源。每个知识源有一个基础优先级，再根据当前黑板状态动态调整。比如当黑板上出现“高置信度矛盾”时，冲突解决 Agent 的优先级会临时提高。这种动态调整能让系统更快收敛。实测下来，加上优先级队列后，平均求解轮次能减少 30% 左右。
6. 四种架构的对比与选型决策
前面四章分别拆解了四种架构，这一章做一个横向对比，帮你在面试和实操中快速做选型决策。选型没有绝对的对错，关键看任务特征和约束条件。我一般从四个维度来评估：任务复杂度、任务确定性、可靠性要求、成本预算。
任务复杂度低、步骤明确的，优先流水线式，简单可靠。任务可以并行、子任务独立的，用主管-下属式，效率高。任务需要高可靠判断、允许一定成本的，用辩论式。任务边界模糊、需要多领域探索的，用黑板式。实际项目里经常是混合使用，比如主管-下属式的主框架里，某个关键子任务用辩论式来提升质量。
| 评估维度 | 流水线式 | 主管-下属式 | 辩论式 | 黑板式 |
|---|---|---|---|---|
| 任务复杂度 | 低 | 中 | 中高 | 高 |
| 任务确定性 | 高 | 中 | 中 | 低 |
| 可靠性要求 | 中 | 中 | 高 | 中高 |
| 成本预算 | 低 | 中 | 高 | 中高 |
| 实现难度 | 低 | 中 | 中 | 高 |
| 调试难度 | 低 | 中 | 中高 | 高 |
6.1 面试中的选型回答模板
面试时如果被问到“你会怎么选”，我建议用这个模板：先问清楚任务特征，然后给出你的选型理由，最后说明你会怎么应对该架构的局限性。比如：“如果任务步骤明确、依赖线性，我会选流水线式，因为实现简单、调试方便。但我会在关键节点加验证 Agent 来防止错误累积。如果任务可以并行，我会选主管-下属式，同时控制下属数量在 8 个以内，避免聚合质量下降。”
这个模板的好处是，你不仅回答了选什么，还回答了为什么选、怎么用好。面试官会觉得你是有实战经验的人，而不是只会背书的考生。我面人的时候，最欣赏的就是这种有取舍、有兜底的回答。
6.2 混合架构的实战案例
实际项目里，纯用一种架构的情况很少。我做过一个技术方案评估系统，主框架是主管-下属式：主管把评估任务拆成性能、成本、可维护性三个子任务，分配给三个下属。每个下属在评估时，内部又用了辩论式：一个提议者给出评估结论，一个质疑者挑毛病，最后下属自己综合。主管收到三份评估后，用综合式聚合，给出最终建议。
这个混合架构的效果比纯主管-下属式好很多，因为每个子任务的评估质量都经过了辩论验证。但成本也高了大约三倍。所以我在非关键任务上会关掉辩论环节，只在关键决策上开启。这种灵活配置的能力，是面试官很看重的。
注意：混合架构会增加系统复杂度和调试难度。我建议先用简单架构跑通，确认瓶颈后再引入复杂架构。不要一上来就设计一个四层嵌套的混合系统，那样出了问题你根本不知道是哪一层导致的。
6.3 从面试题到落地项目的思维转换
面试题往往简化了现实问题，但底层思维是一样的。面试官问“多 Agent 系统怎么答”，本质上是问“你怎么设计一个多 Agent 系统来解决实际问题”。你在面试中展示的架构思维、取舍逻辑、避坑经验，直接迁移到项目里就是设计文档的雏形。
我的建议是，准备面试时不要只背概念，而是真的动手搭一个小系统。哪怕只是用几个 Agent 做一个简单的调研工具，你也会遇到任务分解、结果聚合、错误处理这些真实问题。有了这些经验，面试时你讲的东西就有血有肉，面试官能感受到你是真的做过，而不是临时抱佛脚。
7. 面试高频追问与应对策略
多 Agent 系统的面试，架构只是开场，面试官通常会往深里追问。这一章我整理了几个高频追问，以及我总结的应对策略。这些追问覆盖了通信、容错、评估、成本四个维度，基本能把候选人的真实水平摸清楚。
7.1 Agent 之间怎么通信
这是最常见的追问。很多人只会说“它们互相发消息”，但具体怎么发、发什么格式、怎么保证消息不丢，就答不上来了。我的回答框架是：通信内容结构化、通信方式异步化、通信过程可追溯。
结构化是指消息用 JSON 等格式，包含发送者、接收者、消息类型、负载、时间戳等字段。异步化是指 Agent 之间不直接调用，而是通过消息队列或共享存储来传递信息，这样某个 Agent 挂了不会阻塞整个系统。可追溯是指所有消息都记录日志，方便排查问题。如果面试官追问具体技术选型，可以说用 Redis 做消息队列，用数据库做持久化，但重点还是设计思路，不要陷入具体工具的细节。
7.2 某个 Agent 失败了怎么办
容错是多 Agent 系统的核心挑战。我的应对策略分三层：重试、降级、隔离。重试是针对偶发失败，比如网络超时，重试 2-3 次通常能解决。降级是针对持续失败，比如某个 Agent 一直返回错误，就换一个备用 Agent，或者跳过这个环节用默认值。隔离是针对严重失败，比如某个 Agent 陷入死循环，就把它强制终止，不影响其他 Agent。
面试时你可以举一个具体例子：“如果写稿 Agent 连续三次超时，我会先检查是不是提示词太长导致推理慢，如果是就精简提示词；如果不是，就切换到备用模型；如果备用模型也失败，就返回一个模板化的初稿，让后续环节继续，而不是整个流程卡死。”这个回答展示了你的分层容错思维。
7.3 怎么评估多 Agent 系统的效果
评估是多 Agent 系统里最容易被忽视的环节。很多人搭完系统就完了，不知道怎么衡量好坏。我的评估框架包含三个层面：单 Agent 质量、系统整体质量、成本效率。
单 Agent 质量看每个 Agent 的输出是否符合预期，可以用人工抽检或自动指标。系统整体质量看最终输出是否解决了问题，可以用端到端的评估集。成本效率看每次任务的 token 消耗和耗时，跟单 Agent 方案对比，看多 Agent 带来的质量提升是否值得成本增加。我一般会做一个简单的 A/B 测试，同一批任务分别用单 Agent 和多 Agent 跑，对比质量和成本。
| 评估层面 | 评估指标 | 评估方法 | 合格标准 |
|---|---|---|---|
| 单 Agent 质量 | 输出合规率、准确率 | 人工抽检 + 自动校验 | 合规率 > 95% |
| 系统整体质量 | 任务完成率、用户满意度 | 端到端评估集 | 完成率 > 90% |
| 成本效率 | token 消耗、耗时 | 与单 Agent 对比 | 质量提升 > 成本增加 |
7.4 成本怎么控制
成本控制是面试官很关心的实际问题。多 Agent 系统的成本通常是单 Agent 的几倍到几十倍，如果不加控制，很容易失控。我的控制策略有四个：模型分级、缓存复用、动态降级、预算上限。
模型分级是指不同 Agent 用不同级别的模型，简单的分类任务用轻量模型，复杂的推理任务用强模型。缓存复用是指相同或相似的子任务结果缓存起来，避免重复计算。动态降级是指在预算紧张时，自动关闭辩论等高成本环节。预算上限是指给每个任务设置最大 token 消耗，超过就强制终止。这四个策略组合使用，能把成本控制在可接受范围内。
提示：面试时提到成本控制，最好给一个具体数字。比如“我会把多 Agent 的成本控制在单 Agent 的 3 倍以内，如果超过就说明架构设计有问题，需要优化。”这样面试官会觉得你对成本有量化意识。
8. 从零搭建一个多 Agent 系统的实操记录
这一章我记录一次从零搭建多 Agent 系统的完整过程，包括需求分析、架构选型、代码实现、调试优化。这个系统是一个技术调研助手，输入一个技术主题，输出一份调研报告。我选择这个案例是因为它覆盖了任务分解、并行执行、结果聚合、质量验证等多个环节，能很好地展示多 Agent 系统的完整流程。
8.1 需求拆解与架构选型
需求很明确：用户输入一个技术主题，系统输出一份包含概述、原理、应用场景、优缺点的调研报告。我评估了一下，这个任务可以拆成四个子任务：概述、原理、应用、优缺点。四个子任务之间依赖较少，可以并行执行。所以主框架选主管-下属式，主管负责拆解和聚合，四个下属分别负责一个子任务。
每个子任务内部，我加了一个简单的验证环节：下属生成内容后，用一个验证 Agent 检查内容是否完整、是否有明显错误。验证不通过就打回重写。这个验证环节相当于在每个下属内部加了一个微型流水线。整体架构就是主管-下属式为主，流水线式为辅的混合架构。
8.2 核心代码实现与参数配置
主管 Agent 的提示词我写了三版才稳定。第一版太笼统，拆出来的子任务有重叠。第二版加了“子任务必须互斥且完整”的约束，好了一些。第三版加了 few-shot 示例，拆解质量才稳定下来。下属 Agent 的提示词关键是明确输出格式，我要求每个下属返回 JSON，包含section_title、content、confidence三个字段。
# 技术调研助手的核心配置 ORCHESTRATOR_CONFIG = { "model": "strong-model", "temperature": 0.3, "max_tokens": 2000, "decompose_prompt": """ 将以下技术主题拆解为四个调研子任务：概述、原理、应用场景、优缺点。 要求：子任务互斥且完整，每个子任务用一句话描述。 输出格式：JSON 数组，每个元素包含 task_name 和 task_description。 """ } WORKER_CONFIG = { "model": "medium-model", "temperature": 0.5, "max_tokens": 3000, "max_retries": 2, "timeout": 60 } VALIDATOR_CONFIG = { "model": "medium-model", "temperature": 0.1, "check_items": ["内容完整性", "事实准确性", "逻辑连贯性"] }参数选择上，主管用强模型是因为任务分解需要较强的推理能力。下属用中等模型是因为子任务相对独立，不需要太强的全局理解。温度设置上，主管用 0.3 保证拆解稳定，下属用 0.5 保留一定创造性。超时设 60 秒是因为生成 3000 token 的内容通常需要 30-50 秒。
8.3 调试过程与优化记录
第一版跑下来，最大的问题是聚合质量差。主管把四个下属的内容直接拼接，读起来很生硬，而且有重复。我改成摘要式聚合，让主管先提炼每个部分的核心观点，再合并成一份连贯的报告。改完后可读性明显提升。
第二个问题是验证环节误判率高。验证 Agent 经常把正确的内容判为错误，导致不必要的重写。我调整了验证提示词，把“检查是否有错误”改成“检查是否满足以下三个条件”，并给出具体条件。改完后误判率从 30% 降到 10% 左右。
第三个问题是成本超预期。四个下属加一个主管加四个验证，一次调研消耗的 token 是单 Agent 的 12 倍。我做了两个优化：一是验证环节只在置信度低于 0.7 时才触发，二是相同主题的调研结果缓存 24 小时。优化后平均成本降到单 Agent 的 5 倍左右，质量仍然明显优于单 Agent。
8.4 最终效果与经验总结
最终系统在 50 个测试主题上的表现：任务完成率 96%，人工评估质量评分 4.2/5，平均耗时 45 秒，平均成本是单 Agent 的 5 倍。质量提升主要体现在内容的完整性和逻辑性上，单 Agent 经常遗漏某些维度，多 Agent 系统基本不会。
踩过的坑里，最值得分享的是不要过早优化。我一开始就想设计一个完美的架构，结果花了很多时间在辩论环节上，后来发现辩论对这个任务帮助不大，反而增加成本。后来我砍掉辩论，先用简单架构跑通，再根据实际瓶颈逐步优化，效率高很多。这个经验在面试里也适用：先给出一个合理的基线方案，再说明你会怎么根据反馈迭代，而不是一上来就堆最复杂的架构。
提示：搭建多 Agent 系统时，建议先用两个 Agent 跑通最小闭环，确认通信和聚合没问题后再增加 Agent。我见过有人一上来就搭八个 Agent，结果调试了两天都没跑通，最后放弃。从简到繁，是最高效的路径。
