Multi-Agent 祛魅：为什么 Agent 越多，不一定越聪明？

从单 Agent 到多 Agent 协作：深入理解 Supervisor、Handoff、Parallel Workflow，以及性能、成本与可靠性的工程取舍

一、一个反直觉的现象：Agent 从1个增加到5个，系统却变差了

假设我们正在开发一个 AI 行业研究 Agent。

用户提出需求：

“研究过去24小时 OpenAI、Anthropic、Google DeepMind 的重要动态，生成一份附有来源的中文报告。”

最初，系统只有一个 Agent。

它负责搜索资料、核实来源、筛选新闻、整理内容、生成报告。

虽然有时执行较慢，但整体能够完成任务。

后来，我们决定引入 Multi-Agent 架构。

系统被拆分成五个 Agent：

1. Planner Agent：负责规划。

2. Research Agent：负责搜索。

3. Verification Agent：负责事实核查。

4. Writer Agent：负责写作。

5. Reviewer Agent：负责质量检查。

从架构图上看，系统更加专业，也更接近一个真实的研究团队。

然而上线测试后，我们发现：

原本30秒能完成的任务，现在需要90秒。

Token 消耗上涨了数倍。

Research Agent 找到的链接在传给 Writer Agent 时丢失了部分上下文。

Reviewer Agent 认为报告不够完整，要求重新研究。

Planner Agent 又派发了与之前重复的任务。

最后，报告质量没有明显改善。

为什么会这样？

因为我们犯了一个常见错误：

把任务拆分成更多 Agent，误认为系统就自动获得了更强的智能。

Multi-Agent 不会凭空创造能力。

它只是改变计算、上下文和决策的组织方式。

如果拆分方式合理，多 Agent 可以提高并行度、扩大探索范围、隔离上下文。

如果拆分方式不合理，它就会增加沟通成本、重复计算、状态冲突和错误传播。

所以，一个真正值得讨论的问题是：

什么时候应该使用 Multi-Agent，什么时候一个 Agent 反而更好？

二、先说结论：Multi-Agent 是一种架构选择，不是能力等级

在很多技术讨论中，人们习惯把 Agent 系统理解成一条演进路线：

Prompt
   ↓
RAG
   ↓
Tool Calling
   ↓
Single Agent
   ↓
Multi-Agent

仿佛越往下，技术就越高级。

但这条路线并不准确。

实际上，RAG、工具调用、Agent 和多 Agent 分别解决不同问题。

多 Agent 不一定比单 Agent 高级，更不意味着它适合所有复杂任务。

OpenAI 在《A Practical Guide to Building Agents》中给出的建议非常明确：

优先充分发挥单 Agent 的能力。

当单 Agent 因提示词复杂、工具选择困难或职责边界不清而持续表现不佳时，再考虑拆分。

Google Cloud 的 Agentic AI 架构指南也建议从单 Agent 开始。

这两家官方实践背后有一个共同原则：

不要因为系统复杂，就默认需要更多 Agent；只有当任务结构要求分工时，多 Agent 才具有工程价值。

可以把两种架构理解成：

单 Agent

一个推理主体使用工具完成整个任务。

             User Task
                 │
                 ▼
            Single Agent
                 │
       ┌─────────┼─────────┐
       ▼         ▼         ▼
     Search     Files    Database
       │         │         │
       └─────────┼─────────┘
                 ▼
             Final Result

Multi-Agent

多个推理主体分别处理任务，再进行协调。

             User Task
                 │
                 ▼
             Supervisor
                 │
       ┌─────────┼─────────┐
       ▼         ▼         ▼
    Agent A    Agent B    Agent C
       │         │         │
       ▼         ▼         ▼
    Result A  Result B  Result C
       │         │         │
       └─────────┼─────────┘
                 ▼
             Synthesis
                 │
                 ▼
             Final Result

区别不在于有没有工具，而在于：

系统中有多少个独立进行决策的模型执行单元，以及这些单元怎样交换信息和控制权。

需要注意：多个函数、多个工具、多个处理阶段，并不必然构成 Multi-Agent。

一个由普通 Python 函数组成的流水线，即使包含10个步骤，也可能只是确定性 Workflow。

三、Single Agent 与 Multi-Agent：真正的工程差异

维度	Single Agent	Multi-Agent
架构复杂度	较低	较高
上下文管理	集中	分布式，需要交接
专业分工	依赖工具和指令	可以配置独立专家
并行执行	可以并行调用工具	可以并行独立推理
Token消耗	通常更可控	容易增加
执行延迟	路径较短	取决于并行收益和协调成本
调试难度	较低	需要跨Agent追踪
故障传播	较集中	可能跨Agent放大
权限控制	一个执行主体	需要多主体隔离
适合场景	边界明确的任务	可拆分的复杂任务

这里有两个容易误解的地方。

第一，单 Agent 也可以并行执行工具。

例如，一个 Agent 使用 asyncio.gather() 同时请求三个搜索API，并不一定需要创建三个独立 Agent。

第二，Multi-Agent 也不一定是并行的。

如果 Agent A 必须等待 Agent B，Agent B 又必须等待 Agent C，那么整个系统仍然是一条串行链路。

只是每一步多了一次模型上下文切换。

因此，真正值得优化的是任务的依赖关系，而不是 Agent 数量。

四、Multi-Agent 的四种核心模式

2026年的主流 Agent 框架已经提供了多种协作模式。

OpenAI Agents SDK 重点介绍 Agents as Tools 与 Handoffs。

Google ADK 则提供 Sequential、Parallel、Loop 和多智能体协调模式。

结合实际工程，我建议重点理解四类架构。

模式一：Supervisor / Manager

由一个中心 Agent 负责整体任务。

它根据需要调用专业子 Agent，收集结果，再生成最终回答。

                   User
                    │
                    ▼
               Supervisor
                    │
         ┌──────────┼──────────┐
         ▼          ▼          ▼
     Researcher   Analyst    Reviewer
         │          │          │
         ▼          ▼          ▼
       Finding    Metrics     Issues
         │          │          │
         └──────────┼──────────┘
                    ▼
               Supervisor
                    │
                    ▼
                Response

这种方式最适合一个主体需要对最终结果负责的任务。

例如：

• 综合行业研究。

• 多来源商业分析。

• 复杂报告生成。

• 多专业领域咨询。

• 跨多个系统的信息汇总。

OpenAI Agents SDK 使用 Agent.as_tool() 支持这一模式。

Manager 把专业 Agent 当作工具调用，同时保留最终回复的控制权。

这种方式的主要优点是职责明确。

但它也有明显问题。

如果 Supervisor 的任务拆分能力不够好，它可能让多个子 Agent 重复研究同一个问题。

如果子 Agent 输出过长，Supervisor 又会遇到上下文压力。

如果所有结果都必须经过 Supervisor，中心节点就可能成为延迟和信息瓶颈。

所以，Supervisor 不应该只是“一个负责指挥的更大模型”。

它还需要明确的委派规则、结果协议、任务预算和终止条件。

模式二：Handoff

Handoff 是控制权转移。

例如，一个客服 Agent 接收到用户请求：

“我要申请退款。”

它识别出请求类型，然后把任务交给退款专家 Agent。

                User
                 │
                 ▼
             Triage Agent
                 │
          Intent Detection
                 │
       ┌─────────┼─────────┐
       ▼         ▼         ▼
     Billing   Refund    Technical
      Agent     Agent      Agent
                 │
                 ▼
            User Response

和 Supervisor 的区别是什么？

在 Supervisor 模式中，专家完成子任务后，控制权返回管理器。

而在 Handoff 模式中，专家可能直接成为当前对话的执行主体。

OpenAI Agents SDK 的 Handoffs 就体现了这种语义。

这种设计适合：

• 客服意图路由。

• 多领域专业助手。

• 不同团队处理不同业务。

• 需要切换工具权限和指令的任务。

但 Handoff 不等于无成本切换。

Agent 之间必须明确哪些信息需要传递。

例如，用户已经完成身份验证，是否需要将验证状态交接给新 Agent？

哪些历史消息需要保留？

哪些敏感信息不得传播？

如果交接不完整，用户可能被反复询问相同问题。

如果交接过度，又可能导致上下文膨胀或权限泄露。

因此，Handoff 本质上也是一个 Context Engineering 和安全边界问题。

模式三：Parallel / Fan-out & Fan-in

对于多个相互独立的子任务，可以并行执行。

例如：

研究 OpenAI、Anthropic、Google 的最新动态。

每家公司都可以独立检索，然后统一汇总。

                 Research Task
                       │
                       ▼
                   Task Split
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       OpenAI       Anthropic      Google
       Research      Research      Research
          │            │            │
          └────────────┼────────────┘
                       ▼
                 Result Merge
                       │
                       ▼
                 Fact Checking
                       │
                       ▼
                  Final Report

这种模式的主要价值在于并行性和独立上下文。

但有一个重要前提：

子任务之间应该足够独立。

如果 Agent B 必须等 Agent A 的结果才能开始执行，那么强行并行只会产生错误假设或重复工作。

此外，Parallel Workflow 不一定需要多个自主 Agent。

如果任务只是同时读取三个API，使用普通并发工具调用通常更简单。

只有当每个分支本身需要多轮推理、搜索和决策时，独立子 Agent 才更有价值。

模式四：Sequential Workflow

在这种模式下，不同阶段按照固定顺序执行。

例如：

       Email Ingestion
              │
              ▼
         Bill Parser
              │
              ▼
        Field Validator
              │
              ▼
          Database
              │
              ▼
      Reminder Scheduler

这非常适合信用卡电子账单这样的业务流程。

但有一个问题：

这里真的需要五个 Agent 吗？

答案通常是不需要。

邮件下载、金额解析、字段验证、数据库写入和提醒安排，都可以由普通代码完成。

只有某个环节需要开放性推理，且规则解析无法有效覆盖时，才考虑引入模型。

因此，Sequential Workflow 是一种编排模式，不意味着每个节点都应该是一个 LLM Agent。

这也是 Google ADK 的设计值得借鉴的地方。

它将工作流控制与模型决策明确区分。

确定性的执行顺序，可以交给 Workflow Agent 或普通程序。

不必为了调度另一个模型，而再调用一个模型。

五、真实案例：Anthropic 多 Agent Research 为什么有效？

2025年6月13日，Anthropic 发布了技术文章：

How we built our multi-agent research system

它是理解 Multi-Agent 工程价值与代价的重要资料。

Anthropic 的 Research 系统采用了 Orchestrator-Worker 模式。

一个 Lead Researcher 负责规划研究。

多个 Subagent 独立探索不同方向。

最后，主 Agent 整合发现，并通过额外的引用处理步骤生成研究结果。

官方实验数据

Anthropic 报告：

在其内部 Research 评测中，使用 Claude Opus 4 作为主 Agent、Claude Sonnet 4 作为子 Agent 的多 Agent 系统，比使用单个 Claude Opus 4 的基线表现高出 90.2%。

必须强调：

这属于特定模型组合、内部任务集与系统配置下的实验结果。

它不是“所有多 Agent 系统平均提高90.2%”，也不能直接外推到编程、客服和金融业务。

Anthropic 还提供了两个非常重要的工程观察。

第一，多 Agent 系统尤其适合需要广泛搜索、能够分成多个独立方向的 Research 任务。

第二，多 Agent 系统的 Token 消耗明显增加。

根据其公开观察：

普通 Agent 任务的 Token 使用量约为普通聊天交互的4倍。

多 Agent 系统则可能达到普通聊天交互的约15倍。

这里比较的是不同交互形态下的使用量，并不意味着每个 Multi-Agent 系统都恰好比对应 Single-Agent 系统消耗15倍 Token。

为什么这个架构有效？

因为复杂研究通常具有很强的可分解性。

例如研究全球半导体供应链，可以拆分为：

• 美国芯片设计。

• 中国制造能力。

• 欧洲设备供应。

• 台积电产能。

• 先进封装。

• 政策和出口管制。

这些方向既有关联，又可以在相当程度上独立探索。

多个子 Agent 能够使用不同上下文窗口，并行发现信息。

然后由主 Agent 整合。

真正带来收益的是：

更广的探索范围、更高的并行度，以及更充分的推理预算。

并不是因为出现了“多个智能体”这个名字，系统就自动拥有了群体智慧。

Anthropic 也公开了失败经验

其早期系统曾经出现：

• 为简单任务创建大量子 Agent。

• 不同子 Agent 重复搜索。

• 搜索范围不断扩大却没有终止。

• 结果交接过于冗长。

• 子 Agent 等待造成执行阻塞。

Anthropic 因此加入了任务复杂度与资源分配规则。

对于简单查找任务，不必创建大量 Agent。

对于复杂的广度研究任务，才适当增加并行探索。

这说明：

优秀的 Multi-Agent 架构，核心不在于如何创造更多 Agent，而在于如何限制不必要的 Agent。

六、为什么 Agent 越多，错误可能越多？

从概率上看，多阶段系统存在一个很容易理解的问题。

假设某个任务必须依次经过四个阶段：

规划、检索、分析、汇总。

每个阶段正确完成的概率都为95%。

如果我们暂时采用独立成功的简化假设：

整体成功率为：

[
P(\text{success}) = 0.95^4 \approx 81.45%
]

如果把链路增加到八个必须全部正确的阶段：

[
P(\text{success}) = 0.95^8 \approx 66.34%
]

这不是对真实 Multi-Agent 系统的统计结论，因为不同阶段之间可能相关，也可能存在纠错机制。

但它揭示了一个重要风险：

如果新增 Agent 只是增加串行决策环节，而没有提高阶段质量或提供有效纠错，整体成功率可能下降。

实际系统中还有更复杂的错误传播机制。

1. 信息丢失

Research Agent 找到一条关键事实。

传给 Analyst Agent 时被压缩。

Analyst Agent 再传给 Writer Agent 时，来源链接丢失。

最终 Writer Agent 给出了无法追溯的结论。

这就是多级交接造成的信息损耗。

2. 错误放大

一个 Agent 把未经核实的事实当成正确结论。

其他 Agent 基于它继续推理。

最终报告可能形成一套逻辑完整、却建立在错误前提上的分析。

3. 重复工作

多个子 Agent 不知道其他 Agent 已经完成了什么。

于是重复搜索、重复调用工具、重复生成内容。

4. 状态竞争

两个 Agent 同时修改同一份文件。

一个 Agent 的修改覆盖了另一个 Agent。

或者多个 Agent 对同一个外部业务操作进行重复提交。

5. 责任不清

最终结果出现错误。

但系统不知道错误来自规划、检索、分析还是汇总。

这些问题并不是模型越强就一定自动消失。

它们需要明确的任务协议、状态管理、执行隔离和评测系统来解决。

七、Multi-Agent 中最重要的设计：任务契约

我认为，生产级 Multi-Agent 最容易被低估的不是 Prompt，而是 Agent 之间的数据契约。

不建议让 Supervisor 只对下级 Agent 说：

“请研究一下这个主题。”

更合理的方式是提供结构化任务。

例如：

{
  "task_id": "research-anthropic-001",
  "objective": "核实Anthropic过去24小时的重要公告",
  "scope": {
    "company": "Anthropic",
    "time_window_hours": 24
  },
  "constraints": {
    "require_primary_sources": true,
    "max_tool_calls": 15,
    "no_external_side_effects": true
  },
  "output_schema": {
    "events": "array",
    "sources": "array",
    "uncertainties": "array"
  }
}

这个任务契约至少解决五件事：

目标明确。 子 Agent 知道自己需要交付什么。

范围明确。 避免重复研究其他 Agent 的领域。

预算明确。 防止无限搜索。

权限明确。 不允许未经授权地执行外部操作。

输出明确。 Supervisor 不需要从长篇自然语言中猜测结构。

对于多个 Agent 的协作，应尽量使用结构化数据、引用标识和持久化产物。

不要把全部协作信息都塞进聊天消息。

共享状态还是独立状态？

这里存在另一个重要的架构选择。

如果所有子 Agent 共享一个可写状态，容易出现修改冲突。

如果每个子 Agent 完全隔离，又会产生信息同步问题。

我更推荐：

局部状态隔离 + 结构化结果交接 + 受控共享存储。

例如：

              Shared Task Metadata
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
       Agent A      Agent B      Agent C
       Local State  Local State  Local State
          │           │           │
          ▼           ▼           ▼
       Artifact A   Artifact B   Artifact C
          │           │           │
          └───────────┼───────────┘
                      ▼
               Result Merger

如果多个 Agent 必须修改同一资源，就应该引入锁、事务、版本控制或其他冲突解决机制。

对于 Coding Agent，可以考虑独立工作树或独立沙箱，最终通过补丁合并和测试验证。

不能让多个 Agent 无约束地同时修改生产环境。

八、动手实现：一个可运行的单 Agent 与多 Agent 对照实验

接下来实现一个最小示例。

这次不依赖真实模型API。

原因是我们希望先独立验证：

并行执行是否能降低延迟，以及协调本身是否会产生额外开销。

示例采用 Python 标准库的 asyncio。

我们模拟三个互相独立的研究任务：

• OpenAI资料收集。

• Anthropic资料收集。

• Google资料收集。

两套系统完成完全相同的任务。

单 Agent 模式

依次执行三个任务。

Multi-Agent 模式

同时运行三个独立 Worker，再执行一次结果汇总。

为展示成本差异，我们额外加入一个模拟 Token 预算。

注意：

这不是对 OpenAI、Anthropic 或 Google 模型的真实性能测试。

它只是一个用于理解调度、并行和协调成本的确定性实验。

完整 Python 代码

import asyncio
import time
from dataclasses import dataclass


@dataclass(frozen=True)
class Task:
    name: str
    delay: float
    result: str
    tokens: int


TASKS = [
    Task(
        "OpenAI", 0.06,
        "官方发布记录", 120
    ),
    Task(
        "Anthropic", 0.09,
        "研究工程记录", 140
    ),
    Task(
        "Google", 0.12,
        "架构实践记录", 100
    ),
]


async def research(task: Task) -> dict:
    # 模拟独立的网络或模型等待
    await asyncio.sleep(task.delay)

    return {
        "source": task.name,
        "finding": task.result,
        "tokens": task.tokens,
    }


async def single_agent(tasks):
    start = time.perf_counter()
    reports = []

    for task in tasks:
        reports.append(await research(task))

    return {
        "mode": "single",
        "elapsed": time.perf_counter() - start,
        "tokens": sum(
            x["tokens"] for x in reports
        ),
        "reports": reports,
    }


async def multi_agent(tasks):
    start = time.perf_counter()

    # 并行上限，避免无限创建任务
    semaphore = asyncio.Semaphore(3)

    async def worker(task):
        async with semaphore:
            return await research(task)

    reports = await asyncio.gather(
        *(worker(t) for t in tasks)
    )

    # 模拟协调和结果汇总开销
    await asyncio.sleep(0.03)

    return {
        "mode": "multi",
        "elapsed": time.perf_counter() - start,
        "tokens": sum(
            x["tokens"] for x in reports
        ) + 220,
        "reports": reports,
    }


async def main():
    baseline = await single_agent(TASKS)
    parallel = await multi_agent(TASKS)

    expected = {t.name for t in TASKS}

    for result in [baseline, parallel]:
        found = {
            x["source"]
            for x in result["reports"]
        }

        print(
            f"{result['mode']}: "
            f"complete={found == expected}, "
            f"time={result['elapsed']:.3f}s, "
            f"token_proxy={result['tokens']}"
        )


if __name__ == "__main__":
    asyncio.run(main())

将代码保存为 multi_agent_demo.py，运行：

python multi_agent_demo.py

使用 Python 3.10 及以上版本即可，无须安装第三方依赖。

一次实测输出

single: complete=True, time=0.271s, token_proxy=360
multi: complete=True, time=0.151s, token_proxy=580

这些时间来自上述模拟程序的一次实际运行，不是模型基准测试。不同设备调度会产生少量波动。

结果分析

指标	串行单Agent模拟	并行多Agent模拟
任务完整率	100%	100%
执行时间	0.271秒	0.151秒
模拟Token量	360	580
相对Token用量	1.00×	1.61×

为什么多 Agent 更快？

因为三个独立的等待阶段并行执行。

为什么 Token 预算更高？

因为我们模拟了额外的协调和汇总调用。

但也要注意，这个实验只证明：

在给定的模拟等待时间和协调开销下，并行调度缩短了墙上时钟时间。

它并没有证明多个 LLM Agent 比一个 LLM Agent 更聪明。

真实系统还必须考虑：

• 子 Agent 的独立推理成本。

• 模型调用排队。

• API并发限制。

• 结果质量。

• 重复搜索。

• 上下文交接。

• 错误恢复。

• 真实Token计费。

如果单 Agent 也能并行执行三个工具调用，那么两者的延迟差距可能明显缩小。

因此，正确的评测至少应该包含三个基线：

A：单 Agent 串行工具调用。

B：单 Agent 并行工具调用。

C：Multi-Agent 并行独立推理。

只有证明 C 相比 B 仍有足够收益，才能说明多 Agent 的额外复杂度值得引入。

九、真实 Multi-Agent 应该怎样写？

如果需要真正调用多个模型执行单元，可以使用 OpenAI Agents SDK。

安装：

pip install openai-agents

以下是一个简化的 Manager 架构示例：

import asyncio
from agents import Agent, Runner


openai_researcher = Agent(
    name="OpenAI Researcher",
    instructions=(
        "研究OpenAI相关信息。"
        "只陈述有依据的事实，"
        "明确指出缺少来源的内容。"
    ),
)

anthropic_researcher = Agent(
    name="Anthropic Researcher",
    instructions=(
        "研究Anthropic相关信息。"
        "区分官方公告与第三方评论。"
    ),
)

manager = Agent(
    name="Research Manager",
    instructions=(
        "你负责综合研究报告。"
        "根据需要委派专业任务，"
        "核对信息是否充分，"
        "不能编造来源。"
    ),
    tools=[
        openai_researcher.as_tool(
            tool_name="research_openai",
            tool_description="研究OpenAI主题",
        ),
        anthropic_researcher.as_tool(
            tool_name="research_anthropic",
            tool_description="研究Anthropic主题",
        ),
    ],
)


async def main():
    result = await Runner.run(
        manager,
        "比较OpenAI与Anthropic的Agent工程理念"
    )
    print(result.final_output)


if __name__ == "__main__":
    asyncio.run(main())

这段代码展示的是正式 SDK 的 Manager / Agents-as-tools 用法。

运行前需要配置受支持的模型访问凭据。

但它并没有接入实时网页搜索工具，所以只能演示多 Agent 协作，不能直接保证生成包含最新事实与真实引用的研究报告。

要用于实际研究，需要进一步配置可信搜索、文档读取、来源验证和结果持久化工具。

另外，Agent.as_tool() 并不自动意味着并行执行。

如果需要确定性的并行调度，可以在可信应用代码中使用 asyncio.gather() 等方式协调独立 Agent。

Handoff 示例

对于客服类任务，则可以使用另一种结构：

from agents import Agent, Runner


billing_agent = Agent(
    name="Billing Specialist",
    instructions="处理账单相关咨询。",
)

support_agent = Agent(
    name="Technical Support",
    instructions="处理技术问题。",
)

triage_agent = Agent(
    name="Triage",
    instructions=(
        "识别用户问题类型，"
        "将账单问题转给Billing，"
        "将技术问题转给Support。"
    ),
    handoffs=[
        billing_agent,
        support_agent,
    ],
)


result = Runner.run_sync(
    triage_agent,
    "我想查询本月账单"
)

print(result.final_output)

这两种模式看起来相似，但在实际产品中有不同含义。

Manager 负责最后的合成与表达。

Handoff 则让被委派的 Agent 接管后续交互。

因此，在选型之前，应该先问：

最终谁对用户的结果负责？

这个问题往往比“需要多少个 Agent”更重要。

十、Multi-Agent 成本到底应该怎么算？

很多团队只比较总 Token 数。

但对于真正运行的 Agent 系统，成本应该包含更多部分。

我建议采用以下模型：

[
C_{\text{total}} =
C_{\text{model}}
+
C_{\text{tools}}
+
C_{\text{runtime}}
+
C_{\text{retries}}
+
C_{\text{review}}
]

其中：

• Model：模型输入、输出和推理成本。

• Tools：搜索、浏览器、数据库、第三方API等成本。

• Runtime：容器、沙箱、队列和执行资源。

• Retries：失败重试产生的额外成本。

• Review：自动验证和人工审核成本。

比“每次执行花多少钱”更有价值的指标是：

[
C_{\text{success}} =
\frac{\text{总执行成本}}
{\text{成功完成的任务数}}
]

例如，假设有100个相同评测任务：

方案	成功任务	总成本	每成功任务成本
Single Agent	80	$4.00	$0.050
Multi-Agent	90	$10.00	$0.111

以上为虚构示例。

Multi-Agent 的成功率提高了，但每成功任务成本也大幅增加。

是否值得？

取决于任务的价值。

对于高价值的复杂研究，额外成本可能完全合理。

对于大量简单分类任务，这种架构则可能不经济。

此外，不能只比较平均延迟。

Multi-Agent 需要关注 P95、P99 延迟，因为只要一个关键子 Agent 卡住，整个任务就可能被阻塞。

并行任务的延迟模型

假设三个独立分支耗时分别为：

• Agent A：5秒。

• Agent B：8秒。

• Agent C：12秒。

串行执行需要：

[
T_{\text{serial}} = 5+8+12=25\text{s}
]

理想并行执行需要：

[
T_{\text{parallel}} =
\max(5,8,12)=12\text{s}
]

但实际还存在：

• 启动开销。

• 协调开销。

• 汇总开销。

• 队列等待。

• 失败重试。

因此更接近：

[
T_{\text{multi}} =
T_{\text{dispatch}}
+
\max(T_1,T_2,\ldots,T_n)
+
T_{\text{synthesis}}
]

并行收益只有在节省的时间超过这些额外开销时，才会显现。

更重要的是，增加一个很慢的子 Agent，可能成为新的关键路径。

所以，Multi-Agent 的优化重点应是关键路径，而不是单纯增加并发数。

十一、怎样建立 Multi-Agent Evals？

上一篇《Agent Evals》已经讨论了任务成功率、轨迹、成本和稳定性。

在 Multi-Agent 系统中，这些评测需要进一步细化。

我建议增加以下指标。

指标	解决的问题
End-to-end Success	最终任务是否完成
Delegation Accuracy	是否正确拆分和指派任务
Coverage	子任务是否覆盖全部需求
Duplication Rate	是否出现重复工作
Handoff Fidelity	交接是否丢失关键事实
Evidence Traceability	结论能否追溯来源
Cost per Success	每成功任务成本
Critical Path Latency	最慢关键路径耗时
Recovery Rate	子Agent失败后能否恢复
Safety Violations	是否发生越权和数据泄露

如何开展公平实验？

建议以真实业务任务为基础，设置相同的成功条件。

比较：

1. 单 Agent + 工具。

2. 单 Agent + 并行工具。

3. Multi-Agent + 固定工作流。

4. Multi-Agent + 动态 Supervisor。

所有方案使用相同或可比的数据源、工具权限和验证标准。

同时记录完整版本信息：

• 模型版本。

• Prompt版本。

• Agent数量。

• 工作流配置。

• Tool Schema。

• Token预算。

• 并发限制。

• 测试集版本。

• 评分器版本。

对于具有随机性的模型，应当重复试验，并报告统计不确定性。

不能凭一次运行成功，就认定多 Agent 更可靠。

一个值得注意的评测原则

Anthropic 在多 Agent Research 实践中强调，应重视最终任务状态和实际结果，而不是强制 Agent 遵循某一条预设的执行轨迹。

这对 Multi-Agent 同样重要。

如果系统通过不同但合法的路径完成任务，评测不应该仅因为调用顺序不一致就判定失败。

但对于安全边界、资源权限、必须执行的验证步骤，则仍然需要硬性检查。

十二、什么时候应该坚决避免 Multi-Agent？

我总结了五种不适合的情况。

1. 任务高度确定

例如：

读取邮箱、解析固定格式账单、写入数据库、设置还款提醒。

这类任务主要需要的是可靠的普通程序。

引入多个 Agent 只会增加不可预测性。

2. 子任务高度依赖

例如：

先完成数据库迁移，才能继续修改业务代码，然后才能运行集成测试。

如果执行步骤具有严格先后关系，就不一定能通过多 Agent 获得并行收益。

3. 共享状态非常复杂

多个 Agent 必须同时修改同一个代码仓库、数据库或业务对象时，协调成本可能显著增加。

除非可以清晰隔离工作区，否则不建议直接并行写入。

4. 任务成本极其敏感

对于大量低价值、低复杂度请求，Multi-Agent 可能让单位任务成本显著上升。

5. 无法建立客观评测

如果团队连单 Agent 的成功条件都没有定义清楚，就不应该急着增加多个 Agent。

否则，系统变复杂之后，反而更难判断改动是否有效。

先建立 Eval，再决定是否拆 Agent。

十三、生产级 Multi-Agent 应该具备哪些保护机制？

如果已经确认业务确实需要多个 Agent，那么我建议至少实现以下能力。

并发预算

限制每个任务最多能够创建多少个子 Agent。

同时限制模型调用次数、Token预算和总执行时间。

避免一个简单问题生成几十个不必要的子任务。

结构化交接

Agent之间使用明确的数据结构传递结果。

重要资料使用可追溯的Artifact引用，而不是反复复制整段文本。

任务幂等

对于数据库写入、订单创建、邮件发送等有副作用的操作，必须建立幂等控制。

不能让多个子 Agent 重复执行同一业务操作。

独立权限

每个子 Agent 只获得完成本职任务所需要的工具和数据访问权限。

研究 Agent 不应默认拥有修改生产数据库的权限。

故障隔离

一个子 Agent 失败，不应自动导致其他全部任务丢失结果。

系统应该支持部分完成、有限重试和明确的失败汇报。

可观测性

记录每个子 Agent 的：

• 任务目标。

• 模型版本。

• 工具调用。

• 执行时间。

• Token消耗。

• 输出结果。

• 错误类型。

• 父任务关联ID。

明确终止条件

Supervisor 必须知道什么时候停止委派。

否则，Agent可能不断研究、审查、重写和重新研究。

长任务需要检查点与超时机制。

这些控制机制应该由可信 Runtime 实现，不能全部依赖模型自觉遵守。

十四、一个实用的 Multi-Agent 决策框架

当我们拿到一个新的 Agent 需求时，我建议依次回答四个问题。

第一个问题：任务能否用普通代码完成？

如果可以，优先使用确定性 Workflow。

第二个问题：单 Agent 是否已经出现可复现的能力瓶颈？

如果没有，就继续优化工具、Prompt、Context和模型选择。

第三个问题：子任务是否能够独立执行？

如果能够独立执行，优先评估并行工具调用，再评估独立 Agent。

第四个问题：多 Agent 能否在真实评测中带来足够收益？

如果质量、延迟或扩展性收益不足以覆盖协调成本，就没有必要引入。

可以总结为：

                 New Task
                    │
                    ▼
          能否用确定性代码完成？
               │          │
              是          否
               │          │
               ▼          ▼
           Workflow   Single Agent
                          │
                          ▼
                  是否存在明确瓶颈？
                     │        │
                    否        是
                     │        │
                     ▼        ▼
                  继续优化  能否独立拆分？
                               │       │
                              否       是
                               │       │
                               ▼       ▼
                           优化单Agent  并行工具基线
                                        │
                                        ▼
                                  Multi-Agent实验
                                        │
                                        ▼
                                  Evals与成本比较
                                        │
                                        ▼
                                  决定是否上线

这个流程不是否定 Multi-Agent。

而是让 Multi-Agent 成为经过验证的架构选择，而不是预设答案。

十五、从前六篇到今天：Agent 系统的真正复杂度在哪里？

回顾这个系列：

第一篇，Harness Engineering。

解决 Agent 如何运行和控制。

第二篇，Context Engineering。

解决 Agent 在当前任务中应该看到什么。

第三篇，Memory Engineering。

解决 Agent 如何保存与更新长期经验。

第四篇，Agent Evals。

解决 Agent 是否真正变好。

第五篇，Tool Calling 与 MCP。

解决 Agent 如何访问真实世界，以及如何控制权限。

第六篇，Runtime 与 Sandbox。

解决 Agent 如何在受限环境中安全执行。

今天的第七篇，Multi-Agent。

解决多个推理主体应如何协作，以及如何避免协调成本吞噬能力收益。

这些技术可以组合成下面的架构：

                   User Task
                       │
                       ▼
                  Agent Harness
                       │
                       ▼
                Task Classification
                       │
             ┌─────────┴─────────┐
             ▼                   ▼
        Single Agent        Multi-Agent
             │                   │
             │             Supervisor
             │                   │
             │         ┌─────────┼─────────┐
             │         ▼         ▼         ▼
             │       Agent A   Agent B   Agent C
             │         │         │         │
             │         └─────────┼─────────┘
             │                   │
             └─────────┬─────────┘
                       ▼
                  Tool Gateway
                       │
                  Agent Runtime
                       │
                    Sandbox
                       │
                       ▼
                 Real-world State
                       │
                       ▼
                 Verification
                       │
                       ▼
                     Evals
                       │
                       ▼
                Improvement Loop

可以看到：

Multi-Agent 只是整个系统中一个可选的协作层。

它不能取代 Harness。

不能取代 Context Engineering。

不能取代工具权限。

更不能取代 Evals。

如果基础工程能力不完善，增加 Agent 数量往往只是扩大已有问题。

结语：未来优秀的 Agent 系统，可能比我们想象的更简单

Multi-Agent 是 AI Agent 领域很有吸引力的方向。

它让我们能够构建拥有不同专业能力、不同上下文和不同工具权限的执行单元。

对于复杂研究、广泛搜索、多领域决策和可以充分并行的任务，多 Agent 具有真实价值。

Anthropic 的公开研究表明，在合适的任务和资源配置下，多 Agent 可以显著改善研究效果。

OpenAI 与 Google 的工程指南也提供了成熟的编排方式。

但这些实践并不意味着所有 Agent 产品都应该变成 Multi-Agent。

很多时候，一个设计合理的单 Agent，加上清晰的工具、适当的上下文管理和可靠的验证机制，就已经能够很好地完成任务。

如果确实需要分工，我们也应该先考虑确定性 Workflow、并行工具调用和明确的业务边界。

只有当独立推理、专业分工或上下文隔离带来了可测量的收益，Multi-Agent 才真正值得使用。

Agent 的数量不是能力指标。

真正重要的是：

任务是否完成？

结果是否正确？

成本是否合理？

延迟是否可接受？

权限是否得到控制？

失败是否能够恢复？

改进是否能够复现？

最终，优秀的 Agent 架构并不是拥有最多 Agent 的架构。

而是能够用最少的必要复杂度，持续可靠完成真实任务的架构。

Multi-Agent 的终极目标，不是让多个 AI 一起工作，而是让整个系统比最好的单 Agent 基线做得更好。