智能体面试准备（七）：多智能体协作——角色分工、辩论与流水线三大范式及可运行实现

智能体面试准备七多智能体协作——角色分工、辩论与流水线三大范式及可运行实现前面六篇把单 Agent 的核心组件讲完了ReAct 循环、工具调用、规划分解、记忆系统。但面试走到中后段面试官几乎一定会抛出这个问题什么时候需要多个 Agent多 Agent 系统怎么设计这道题答不好有两种典型翻车方式一种是把多 Agent 吹成银弹面试官会追问成本和失败模式另一种是完全否定多 Agent面试官会拿 MetaGPT、Claude 的多 Agent Research 系统反问。这一篇把多智能体协作的三大范式、通信与协调机制、失败模式讲清楚最后给一个不依赖任何框架的可运行多 Agent 实现。一、先回答为什么单 Agent 的三个天花板多 Agent 不是为了炫技而是单 Agent 撞到了三个结构性天花板1. 上下文窗口污染。单 Agent 处理复杂任务时工具返回的原始数据网页全文、日志、代码文件会迅速塞满上下文。检索十个网页上下文就废了——后续推理在一堆噪声上进行质量断崖下跌。多 Agent 的解法是上下文隔离子 Agent 在自己的独立上下文里干脏活只把蒸馏后的结论交回主 Agent。2. 角色专业化困难。一个 system prompt 既要它是严谨的代码审查员、又要它是激进的方案设计师两种行为模式互相干扰。拆成两个 Agent各自的提示词可以写得极端专一行为一致性显著提升。3. 串行执行的时间墙。单 Agent 的 ReAct 循环本质是串行的。调研类任务里十个子问题彼此独立串行跑十轮太慢多个子 Agent 并行跑墙钟时间直接除以并行度。Anthropic 的多 Agent Research 系统论证过这一点主 Agent 分派多个搜索子 Agent 并行工作效果超过单 Agent 的最大原因就是 token 预算的并行扩展。反过来面试也要主动说出多 Agent 的代价token 消耗成倍增长Anthropic 实测多 Agent 系统 token 用量约是单 Agent 对话的 15 倍、错误会在 Agent 间传播放大、调试难度指数上升。结论口径任务可分解且子任务间低耦合时多 Agent 收益为正强顺序依赖、需要全局一致状态的任务单 Agent 加好的上下文工程往往更优。二、三大协作范式范式一角色分工Role-Based / 主管-工人一个 Orchestrator主管负责理解任务、拆解、分派多个 Worker 各带专属提示词和工具集干活主管汇总。MetaGPT 的软件公司产品经理→架构师→工程师→测试和 CrewAI 的 crew 都是这个范式。关键设计点任务描述的信息完整性。主管给子 Agent 的指令必须包含目标、输出格式、工具边界、任务边界——子 Agent 看不到全局上下文指令模糊就会重复劳动或跑偏。这是多 Agent 工程里最常见的翻车点。范式二辩论Debate / 对抗互查多个 Agent 对同一问题独立作答然后互相看对方的答案、批评、修正若干轮后收敛或由裁判 Agent 定夺。适用场景事实核查、方案评审、数学推理——本质是用多样性对冲单模型的自信错误幻觉。面试细节辩论范式的收益来自采样多样性不同 Agent 用不同温度/提示词/甚至不同底座模型如果所有辩手同质辩论会迅速变成互相恭维式收敛几轮后一起错。实践上常配魔鬼代言人角色强制唱反调。范式三流水线Pipeline / 顺序加工任务按固定阶段流转A 的输出是 B 的输入像工厂流水线。翻译→润色→审校或者代码生成→静态检查→测试生成。和角色分工的区别在于没有中央调度拓扑是静态的每个 Agent 只管自己这一段。优点是可预测、易调试、每段可单独评估缺点是缺乏灵活性上游错误会顺流而下。三个范式对比表面试可以直接画维度角色分工主管-工人辩论流水线拓扑结构星型中心调度全连接互相可见链式单向任务分配动态主管决定相同任务并行静态预定义并行能力强Worker 并行强辩手并行弱顺序依赖典型场景深度调研、复杂工程任务事实核查、方案评审内容加工、代码流水线主要风险指令传递失真、调度开销同质化收敛、成本高错误顺流传播代表系统MetaGPT、Claude ResearchMulti-Agent Debate 论文翻译/审校链调试难度高中低三、通信与协调多 Agent 的真正难点范式好讲通信才是工程难点。面试官追问两个 Agent 怎么共享信息要能分层回答1. 消息传递 vs 共享黑板。消息传递Agent 间点对点发结构化消息如 AutoGen 的对话式语义清晰但通路多了容易乱。共享黑板blackboard所有 Agent 读写同一个共享状态如 LangGraph 的 State全局可见但要处理并发写冲突。生产系统常混用任务分派用消息成果沉淀用黑板/文件系统。2. 结构化输出是通信的生命线。Agent 间传自然语言会产生传话游戏式的信息衰减工程上必须强制 JSON Schema 约束的结构化消息任务 id、状态、产物、置信度接收方按字段消费。3. 终止与预算控制。多 Agent 系统最烧钱的事故是两个 Agent 互相客气地对话不终止。必须有硬性护栏最大轮数、总 token 预算、无进展检测连续 N 轮状态未变即熔断。4. 错误隔离。子 Agent 失败不能带崩全局——主管要能感知失败超时/异常/低置信度输出选择重试、换 Agent 或降级为自己处理。四、可运行实现主管-工人 辩论混合范式下面这段代码不依赖任何 Agent 框架用一个 MockLLM 演示完整的多 Agent 协作骨架——重点看结构结构化消息、角色隔离、预算控制、汇总裁决。把 MockLLM 换成真实 API 调用即可投产。import json, time from dataclasses import dataclass, field dataclass class Message: sender: str role: str # task / result / critique / verdict content: dict # 结构化载荷 ts: float field(default_factorytime.time) class MockLLM: 演示用按角色返回预设回复。真实场景换成 chat API。 def __init__(self, persona): self.persona persona def chat(self, system, user): if self.persona optimist: return {answer: 选择方案A直接上多Agent, confidence: 0.62, reason: 并行度高扩展性好} if self.persona skeptic: return {answer: 选择方案B先做单Agent上下文工程, confidence: 0.78, reason: 任务耦合度高多Agent通信成本会吃掉并行收益} if self.persona judge: return {verdict: 方案B, confidence: 0.8, reason: 两位辩手中怀疑派给出了成本证据且任务描述显示强顺序依赖} return {answer: unknown, confidence: 0.0} class Agent: def __init__(self, name, persona, system_prompt): self.name, self.llm name, MockLLM(persona) self.system_prompt system_prompt self.inbox: list[Message] [] def receive(self, msg: Message): self.inbox.append(msg) def work(self) - Message: task self.inbox[-1].content # 只消费最新任务上下文隔离 reply self.llm.chat(self.system_prompt, json.dumps(task, ensure_asciiFalse)) return Message(self.name, result, reply) class Supervisor: 主管分派 - 收集 - 辩论裁决 - 输出带预算护栏 def __init__(self, workers, judge, max_rounds3, budget_calls10): self.workers, self.judge workers, judge self.max_rounds, self.budget max_rounds, budget_calls self.calls 0 def _call(self, agent) - Message: if self.calls self.budget: raise RuntimeError(token/调用预算耗尽触发熔断) self.calls 1 return agent.work() def run(self, task: dict) - dict: # 1) 并行分派同一任务给不同角色辩论范式 results [] for w in self.workers: w.receive(Message(supervisor, task, task)) results.append(self._call(w)) # 2) 交叉批评把对方答案发给彼此此处一轮可循环 max_rounds for i, w in enumerate(self.workers): rival results[1 - i].content w.receive(Message(supervisor, critique, {rival_answer: rival, **task})) # 3) 裁判汇总 self.judge.receive(Message(supervisor, task, { question: task[question], candidates: [r.content for r in results]})) verdict self._call(self.judge) return {final: verdict.content, traces: [r.content for r in results], llm_calls: self.calls} if __name__ __main__: sup Supervisor( workers[Agent(A-乐观派, optimist, 你倾向新技术给出激进方案), Agent(B-怀疑派, skeptic, 你负责挑刺重点评估成本与风险)], judgeAgent(J-裁判, judge, 比较候选答案依据证据裁决), budget_calls10) out sup.run({question: 新调研系统应该用多Agent还是单Agent, context: 子任务间存在强顺序依赖团队2人预算有限}) print(json.dumps(out, ensure_asciiFalse, indent2))这段代码值得在面试里展开讲的设计点上下文隔离——Worker 只消费分派给它的结构化任务不共享全量历史结构化消息——Message带 sender/role/contentAgent 间不传裸文本预算熔断——budget_calls硬性护栏防对话不终止异质辩手——乐观派/怀疑派 persona 不同避免同质化收敛可替换性——MockLLM 换成真实 API、Supervisor 的 for 换成 asyncio.gather 就是生产骨架。五、失败模式与面试加分项多 Agent 系统的失败模式是高阶面试题能主动说出来非常加分可引用 Berkeley 的 MAST 多 Agent 失败分类研究规格不清主管给子 Agent 的任务描述缺少边界子 Agent 各自理解产出无法拼装Agent 间失配A 假设 B 已完成某步B 以为 A 负责任务掉在地上验证缺失没有独立的验收环节错误结果被逐级信任传递到最终输出成本失控并行 Agent 都在重复检索同样的资料责任归因困难出错后难以定位是哪个 Agent、哪轮消息引入的错误——所以 tracing每条消息落盘、每次调用记录输入输出在多 Agent 系统里不是可选项而是必需品。高频面试题清单什么任务适合多 Agent什么任务不适合可分解低耦合 vs 强顺序依赖多 Agent 的 token 成本比单 Agent 高多少值得吗约一个数量级用任务价值判断两个 Agent 意见冲突怎么办裁判 Agent / 置信度加权 / 升级人工怎么防止多 Agent 死循环对话最大轮数预算熔断无进展检测主管怎么把任务描述清楚目标/格式/工具边界/任务边界四要素多 Agent 怎么调试结构化 tracing回放每条消息下一篇讲主流 Agent 框架横评LangChain / LlamaIndex / CrewAI 的架构哲学与选型。