Multi-Agent：什么时候该用、什么时候不该用

魚飞

659人浏览 · 2026-06-29 12:31:34

魚飞 · 2026-06-29 12:31:34 发布

阅读时间：约 14 分钟
前置知识：理解 Agent 决策循环（P01）、上下文管理（P03）、重试与错误处理（P04）

P05 让 Agent 有了记忆。但架构上还有一个选择：一个 Agent 干到底，还是拆成多个？你会听到两种声音：“别拆，单 Agent 够用"和"拆了效果好 90%”。谁对？

前言：一场没有标准答案的论战

Cognition（Devin 母公司）的主张：不要建 Multi-Agent 系统。 多 Agent 编排增加复杂度、毁掉可调试性、把上下文工程就能解决的问题变成了架构问题。

Anthropic 的反证：用 Opus 4 协调多个 Sonnet 4 子 Agent，在复杂研究任务上比单 Agent Opus 4 提升了 90.2%。

两家都做生产级 Agent，都拿得出数据。而且两家都是对的：因为他们在解决不同的问题。

Multi-Agent 不是"更好"的架构。它是一种特定场景下的工具。用对了收益巨大，用错了烧 token 还降低质量。

📌 本章核心：Multi-Agent 的决策依据是三个信号：上下文污染、并行探索、工具过多。大多数场景先优化单 Agent 更划算。

第一部分：单 Agent 为什么对大多数场景够了

Google Research 发现：在严格顺序推理任务上，Multi-Agent 比单 Agent 性能下降 39% 到 70%。原因很简单：每多一层 Agent 间信息传递，就多一层压缩。压缩就是丢东西。

Anthropic 自己也说：大多数团队不需要 Multi-Agent 系统，单个 Agent 改进 prompt 效果就能匹配复杂多 Agent 架构，代价更低。80% 的企业场景，单 Agent 就够了。

单 Agent 的三大优势

共享上下文是资产。 读过的文件、看到过的错误、试过的方案，全在一个上下文窗口里。拆成多个 Agent，协调者看到的是摘要而不是原始数据：摘要是带损耗的。

调试是可控的。 一个上下文窗口 = 一条可追踪的链路。多 Agent 的失败会跨边界级联：B 失败了因为 A 的摘要漏了关键细节。排查 B 找不到问题，几小时后才发现是 A 的压缩出错。

延迟可预测。 每步一次模型调用。多 Agent 每次交接增加 2-10 秒延迟。

📌 本章要点：单 Agent 对 80% 场景够用。共享上下文 = 信息不丢、调试 = 一条链路、延迟 = 可预测。

第二部分：三种真正需要 Multi-Agent 的场景

场景一：上下文污染

一个上下文窗口里同时分析两家竞争公司的数据，模型的心理模型会混在一起。

为什么 Multi-Agent 能解决：两个子 Agent 分别在独立上下文里各自分析，协调者收到两份干净的独立报告，再做对比。信息从未混合。

def analyze_competitors(report_a, report_b):
    agent_a = SubAgent("分析师-A")
    agent_b = SubAgent("分析师-B")
    result_a = agent_a.run(f"分析这份年报：{report_a}")
    result_b = agent_b.run(f"分析这份年报：{report_b}")
    return Coordinator().run(f"对比：\nA:{result_a}\nB:{result_b}")

场景二：并行探索

需要同时研究 20 篇论文、同时调 8 个 API、同时查 5 个数据库。单 Agent 只能串行。5 个子 Agent 同时跑，总时间是一个 Agent 的五分之一。

场景三：工具过多

注册了 50 个工具，模型选错的概率显著增加，工具描述本身占几千 token。按功能拆成专门子 Agent，每个只暴露 3-5 个工具。

混合模式：最实用的折中

Anthropic 自己的数据：Multi-Agent token 消耗是单 Agent 的 10-15 倍。大部分生产环境用混合模式：一个主 Agent + 按需启动一次性子 Agent。

class HybridAgent:
    def __init__(self):
        self.coordinator = Coordinator()
    
    def solve(self, task):
        plan = self.coordinator.plan(task)
        results = {}
        for step in plan:
            if step.requires_isolation:
                sub = SubAgent(step.context)
                results[step.id] = sub.run(step.prompt)
                # 子 Agent 跑完即弃
            else:
                results[step.id] = self.coordinator.execute(step)
        return self.coordinator.synthesize(results)

📌 本章要点：三种适用场景：上下文污染、并行探索、工具过多。混合模式（主 Agent + 按需子 Agent）最实用。

第三部分：四种不该用 Multi-Agent 的反模式

反模式	为什么错
拟人化角色分工	角色名称不等于能力边界。同一模型换 system prompt 不算真正的拆分
简单查询也拆 Agent	查天气一次工具调用就能完成，拆三个 Agent 烧 15 倍 token
顺序依赖硬拆并行	A 的输出是 B 的输入，拆开后在传递中丢失信息
为了"好看"上架构	每多一层协调，多一层调试难度、多 10 倍成本

总结：什么时候坚决不拆

大多数编码任务（单仓库）
简单查询（查天气、问价格）
顺序依赖的任务
拟人化角色（没有真正的能力域差异）
Token 预算紧张

📌 本章要点：简单查询、低价值任务、顺序依赖、单仓库编码，先优化单 Agent 更划算。Multi-Agent 不是默认选项。

第四部分：通信模式：指挥链就够了

Multi-Agent 之间怎么通信？两种方案：

指挥链（Coordinator → Sub-Agent）：所有通信经过协调者。可追踪、可调试、协议简单。适合内部系统。

A2A 协议：Agent 之间自由互发消息。Google 2025 年提出，适合跨组织场景。但日常开发基本用不到：Coordinator 知道全局任务目标，直接指挥比让 Agent 自己协商效率高得多。

📌 本章要点：内部系统用指挥链就够了。A2A 留给跨组织场景。

实战：正确 Multi-Agent 的三个关键细节

class SubAgent:
    """独立上下文，完成单一分析"""
    def __init__(self, name, system_prompt):
        self.name = name
        self.messages = []  # 独立上下文空间
    
    def run(self, task):
        self.messages = [
            {"role": "system", "content": self.system_prompt},
            {"role": "user", "content": task}
        ]
        return {"agent": self.name, "result": call_llm(self.messages)}

class Coordinator:
    """汇总子 Agent 结果，综合判断"""
    def synthesize(self, sub_results):
        results_text = "\n\n".join(
            f"[{r['agent']}]: {r['result']}" for r in sub_results
        )
        return call_llm([{
            "role": "user",
            "content": f"基于以下独立分析，给出综合对比：\n{results_text}"
        }])