单智能体 vs. 多智能体编排

多智能体系统究竟是什么。

多智能体系统是若干智能体——各有自己的提示、工具与上下文窗口——被协调以解决一个任务。它是沿着全景篇中状态归属与上下文坐标轴的分解：不是一个智能体在一个历史里持有一切，而是把工作分区，使每个智能体只看到自己那一片。协调结构就是架构。

关键在于，多智能体不是"更聪明"。同一基础模型驱动的三个智能体不会超过该模型的能力上限。你获得的是结构性的：隔离的上下文、并行执行、可强制的能力边界。你支付的是协调税。这个决策是工程权衡，不是能力升级——把它当作后者是这个领域最常见的架构错误。

拆分的正当理由。

• 上下文隔离。一个长子任务（深度代码搜索、多文档研究）否则会用它不需要的细节淹没主智能体的窗口。子智能体在自己的窗口里干活并返回一个紧凑结果。这是最强、最常见的真实理由。
• 并行。真正独立的子任务跨子智能体并发运行——这是单一串行智能体无法匹敌的延迟优势。
• 能力/权限边界。一个高权限工具（生产写、支付）藏在一个只做那件事、有自己护栏的窄范围智能体之后。分解成为一个你可以审计的安全边界。
• 不同的专长配不同工具/提示。当子任务需要确实不同的工具集与指令时，分开的智能体比一个臃肿提示更干净——尽管一个路由进专门处理器往往就够，无需完整多智能体自治。

两种拓扑。

监督者/工作者（orchestrator-workers）。一个监督者分解任务、把子任务委派给工作者、综合其结果。工作者之间不交谈；所有协调流经监督者。这是主力拓扑——Anthropic 的研究系统用一个领头智能体派生子智能体并行探索并回报。控制与可观测性集中；监督者是瓶颈与单点故障。

# Supervisor / worker
plan = supervisor.decompose(task)
results = parallel_map(
    lambda sub: worker_for(sub.kind).run(sub),  # isolated context each
    plan.independent_subtasks,
)
return supervisor.synthesize(task, results)        # reconcile, not concat

交接/网络。智能体点对点传递控制：一个分流智能体把对话交给一个专家，后者可能再交接。灵活，对会话流程自然，但控制去中心化，循环与乒乓很容易出现，端到端可观测性困难。把交接约束到一个小的、经验证的图；绝不允许任意网状。

没人编入预算的协调税。

多智能体的成本真实、反复且常被低估：

• token 爆炸。每次交接都重新序列化上下文。多智能体系统通常烧掉等效单一智能体数倍的 token——这是被度量过的、预期之中的成本，不是 bug。
• 错误复合。错误跨交接传播并放大。监督者一个小误读，会变成工作者忠实执行的一个完全错误的子任务规格。
• 有损上下文传递。工作者只看到监督者传过来的东西。交接欠规范，工作者就会自信地解决错误的问题——多智能体的主导失败模式。
• 调试就是分布式系统调试。故障活在智能体之间的接缝里。你需要带关联 ID 的跨智能体追踪，否则无法重建发生了什么。
• 综合本身是个难任务。合并工作者输出、解决矛盾、去重，是监督者必须真正做的非平凡推理——拼接会产出不连贯的结果。

一个决策框架。

默认用单一智能体。它有一个上下文、一个 trace、一个失败面，构建、调试与运行都便宜得多。审慎升级：

• 一个带良好工具集的单一 ReAct 智能体 → 处理绝大多数真实工作负载。永远从这里开始。
• 当工具选择退化时加一个路由器——比自治智能体更便宜更简单，且捕获大部分"专门化"价值。
• 当某子任务可证明地污染主窗口时，为上下文隔离加子智能体——最干净、理由最充分的多智能体之举。
• 仅当子任务确实可并行或需要分开的能力边界，且你承受得起 token 与调试税时，才走监督者/工作者拓扑。
• 仅对会话分流流程使用对等交接，在一个小的、显式验证的图上带循环守卫。

需要点名并避免的反模式："每角色一个智能体"照搬组织架构图（人靠共享理解协调，智能体不会）；深层智能体层级（错误随深度几何复合）；自由形态智能体网状（无界循环、无可观测性）；以及对单一 ReAct 循环已能处理的任务上多智能体（纯开销）。

诚实的权衡：多智能体以乘性 token 账单、复合错误、有损交接和分布式系统调试为代价，买入上下文隔离、并行与可审计的能力边界。当结构性收益具体且经度量时动用它——绝不要因为更多智能体听起来更有能力。它们并非如此。