多个 AI Agent 一起工作，比一个 Agent 更难管：Multi-Agent 协作的 3 个核心问题

摘要一个 Agent 容易失控多个 Agent 一起失控会变成灾难。Multi-Agent 协作是 2025 年 AI 应用最热门的架构方向但真正落地时面临三个核心问题Agent 之间怎么通信、怎么防止重复劳动、怎么避免「抢功」式输出。本文拆解这三个问题的根因和工程解法。 目录开篇为什么 Multi-Agent 比单 Agent 更难管问题一Agent 之间的通信协议——谁该先说话问题二重复劳动——两个 Agent 做了同一件事问题三输出冲突——三个 Agent 给出了三个答案架构设计三种 Multi-Agent 拓扑面试追问总结开篇为什么 Multi-Agent 比单 Agent 更难管单 Agent 失控你能定位问题。一个 Agent 调用了错误的 Tool你可以改 Tool 定义、加 System Prompt、加 Hard Stop。Multi-Agent 失控你面对的是一整张通信网络。Supervisor Agent 把任务分配给了三个 Worker Agent其中一个 Worker 给出了错误结论另外两个 Worker 基于这个错误结论继续工作——最后 Supervisor Agent 把三个 Worker 的输出合并成一份「逻辑自洽但完全错误」的报告交付给你。没有人做错。每个 Agent 的行为单独看都是合理的。但整体输出是错的。Multi-Agent 的核心矛盾每个 Agent 是独立推理的但它们共同服务于一个任务。当任务被分解后每个 Agent 只能看到自己手里的碎片看不到整体画面。本文拆解三个核心问题通信、重复、冲突。每个问题都有根因分析和可落地的工程解法。问题一Agent 之间的通信协议——谁该先说话三种通信模式Multi-Agent 协作的第一个设计决策Agent 之间怎么传递信息通信模式描述适用场景风险共享内存所有 Agent 读写同一个共享文档/数据库信息需要全局可见时并发写冲突、死锁消息传递Agent 之间点对点发送消息任务有明确的前后依赖时消息丢失、顺序错乱Supervisor 路由所有信息汇总到中央节点由它分发需要统一协调时Supervisor 成为瓶颈根因Agent 没有「等待」的概念人类团队协作有一个默认机制等人。一个任务分给三个人这三个人会自然地等其他人完成后再合并。但 Agent 没有这个机制——如果 Worker Agent A 需要 Worker Agent B 的输出作为输入而 B 还没完成A 会怎么做答案是不等。自己猜一个输入先干着。Scenario A❌ 错误行为 Supervisor: 分配任务给 Agent A 和 Agent B Agent A: 收到任务立即开始工作用「空输入」假设 B 的输出 Agent B: 还没准备好被 A 催了 → Agent A 和 B 的输出无法对齐 Scenario B✅ 正确行为 Supervisor: 分配任务给 Agent A 和 Agent B Agent A: 等待 B 的输出通过 Supervisor 路由或消息队列 Agent B: 完成通知 Supervisor Supervisor: 把 B 的输出交给 A Agent A: 开始工作 → 输出正确对齐解法明确「等待点」Python带等待点的 Multi-Agent 协作class SupervisorAgent: def __init__(self): self.shared_context {} # 共享上下文 def dispatch_task(self, task, workers): # 1. 分析任务依赖图 deps self.analyze_dependencies(task) # 2. 先执行无依赖的任务 ready_workers deps.get_ready() for worker in ready_workers: worker.start() # 3. 有依赖的任务进入等待队列 waiting_workers deps.get_waiting() # 4. Worker 完成后写入共享上下文 while waiting_workers: completed self.wait_for_completion(waiting_workers) completed.write_to(self.shared_context) # 5. 检查是否有任务现在可以开始了 newly_ready deps.check_unblocked(completed) for worker in newly_ready: # 把依赖任务的输出注入新任务的 context worker.inject_context(self.shared_context) worker.start() # 6. 合并所有 Worker 输出 return self.merge_outputs(workers)金句Multi-Agent 协作失败的第一原因不是模型能力不够是没有人定义「谁等谁」。问题二重复劳动——两个 Agent 做了同一件事典型场景用户问「帮我分析一下特斯拉和比亚迪的财报。」Supervisor 把任务拆成Worker A分析特斯拉财报Worker B分析比亚迪财报看起来很清晰。但实际运行时Worker A: 需要查询两家公司的营收数据 → 调用 search_financial_data(companyTesla) Worker B: 也需要查询两家公司的营收数据 → 调用 search_financial_data(companyBYD) → 同时调用了 search_financial_data(companyTesla) ← 重复 Supervisor: 收到了两份 Tesla 数据一份来自 A一份来自 B → 不知道该信哪份或者合并时出现冲突根因分析重复劳动的根因是任务分解时没有做「去重规划」。Supervisor 把一个大任务按「维度」切分特斯拉 vs 比亚迪但两个子任务里有共同的信息需求行业背景数据、宏观经济数据。这些「共同需求」没有被识别出来单独处理。解法提取公共任务先执行一次任务分解先去重再分配def decompose_task(user_query): # 1. 分析所有 Worker 的公共信息需求 all_requirements extract_all_requirements(workers) # 2. 识别公共需求 common_requirements find_common(all_requirements) # 例如行业背景、两家公司对比数据 # 3. 先执行公共任务只执行一次 common_context executor.run(common_requirements) # 4. 给每个 Worker 注入公共上下文 for worker in workers: worker.inject(common_knowledge, common_context) # 5. 再执行各自的专属任务 results [worker.run() for worker in workers] return results金句Multi-Agent 不是把任务拆了扔给一堆 Agent 就完事了——公共需求必须被识别和去重否则你的 Token 成本翻倍输出质量反而下降。问题三输出冲突——三个 Agent 给出了三个答案典型场景用户问「这个季度的产品策略应该怎么调整」Supervisor 把任务分配给三个 AgentData Agent分析数据 → 结论应该降价Market Agent分析市场 → 结论应该提价Product Agent分析产品 → 结论维持现状三个 Agent 都没有做错但 Supervisor 合并输出时面对三个互相矛盾的结论它会怎么做根因分析输出冲突的本质是每个 Agent 只基于自己收到的信息做决策没有「交叉验证」机制。Data Agent 不知道 Market Agent 说了什么Market Agent 不知道 Product Agent 说了什么。如果它们知道彼此的结论可能会修正自己的判断——人类就是这样协作的。解法一让 Agent 之间「读」彼此的结论Round-based Multi-Agent多轮交叉验证def multi_agent_with_validation(workers, max_rounds2): Round 1: 每个 Worker 独立得出结论 Round 2: 每个 Worker 看到其他 Worker 的结论后修正自己的结论 # Round 1 round1_results [worker.run() for worker in workers] # 把其他 Agent 的结论注入每个 Agent 的 context for i, worker in enumerate(workers): others_results [r for j, r in enumerate(round1_results) if j ! i] worker.inject(peer_conclusions, others_results) # Round 2: 重新推理 round2_results [worker.run() for worker in workers] # Supervisor 综合 return supervisor.synthesize(round2_results)解法二Supervisor 做最终仲裁投票/优先级仲裁策略def supervisor.arbitrate(conflicting_results): 冲突仲裁策略 # 策略1按置信度排序 sorted_results sorted( conflicting_results, keylambda r: r.confidence_score, # 哪个 Agent 对自己的结论最自信 reverseTrue ) # 策略2按数据充足度排序 sorted_results sorted( conflicting_results, keylambda r: r.data_volume, # 哪个 Agent 拿到的数据最充分 reverseTrue ) # 策略3投票少数服从多数但适用于事实性问题 return sorted_results[0] # 返回最高优先级结论金句Multi-Agent 的输出冲突不是 Bug是系统设计缺陷的信号——说明你没有给 Agent 之间交叉验证的机制。架构设计三种 Multi-Agent 拓扑拓扑一Supervisor 模式星型结构[User] ↓ [Supervisor] / | \ [A] [B] [C] \ | / (写回共享内存)特点Supervisor 负责任务分解、进度管理、结果合并。Worker 只负责执行。适用任务有明确的主从关系、需要中央协调。代表LangGraph 的 Supervisor 架构。拓扑二Peer-to-Peer 模式网状结构[A] ←→ [B] ↑ ↑ ↓ ↓ [C] ←→ [D]特点Agent 之间直接通信没有中央节点。适用对等任务如辩论、评审、多视角分析。代表AutoGen 的多 Agent 对话模式。拓扑三Pipeline 模式流水线结构[A] → [B] → [C] → [D]特点每个 Agent 处理一个阶段上一阶段的输出是下一阶段的输入。适用有明确先后顺序的工作流如数据采集 → 分析 → 报告生成。代表数据 ETL 管道。面试追问Q1Multi-Agent 的 Token 成本怎么控制Multi-Agent 的 Token 消耗通常比单 Agent 高 3-5 倍因为每个 Agent 都有自己的 System Prompt、每个 Agent 之间要传递上下文、最后还要合并输出。优化方向① 精简每个 Agent 的 System Prompt只保留必要指令② 用摘要压缩传递的上下文而不是传原始对话历史③ 设计「Early Exit」机制——如果第一个 Agent 已经得到了满意答案后续 Agent 可以跳过。Q2Multi-Agent 怎么保证数据安全Agent 会不会泄露信息这是 Multi-Agent 的隐私问题。解法① 信息隔离每个 Agent 只知道自己的任务不知道全局信息② 权限分级某些敏感数据只能被特定 Agent 访问③ 输出审查在 Agent 输出合并前加一道审查步骤。需要注意大模型本身不会「主动保密」它的 System Prompt 必须显式说明保密边界。Q3Supervisor Agent 失控了怎么办Supervisor 是单点故障。解法① 给 Supervisor 也加 Hard Stop最大任务分解数量② 实现 Supervisor 的「后备方案」——如果 Supervisor 在 N 秒内没有返回结果触发降级逻辑用预设策略或回退到单 Agent③ 记录完整的 Supervisor 决策日志方便事后复盘。总结问题根因解法通信混乱Agent 没有「等待」机制明确等待点Supervisor 路由分发重复劳动任务分解时没做去重规划先提取公共需求执行一次输出冲突Agent 之间没有交叉验证多轮交叉验证 仲裁策略核心一句话Multi-Agent 不是「一堆 Agent 同时工作」是一套有通信协议、任务规划和仲裁机制的协作系统。架构设计在前工程实现在后。 你在 Multi-Agent 项目中遇到过什么问题评论区聊聊。