第 23 章多 Agent 的基本模式¶

多 Agent 往往是 Agent 讨论里最容易让人兴奋的主题之一，但也是最容易被滥用的主题之一。很多系统在单 Agent 还没做稳的时候，就急着拆成多个角色，结果复杂度快速上升，收益却并不明确。本章先不讨论实现，而先讲模式。

23.1 为什么会需要多 Agent¶

只有当任务中存在明显的角色分化、上下文压力过大、或不同子任务确实适合不同专长处理时，多 Agent 才开始有意义。否则，它通常只是把单 Agent 的问题复制多份。

最常见的一种模式是 Manager-Worker。管理者负责拆任务、收结果和做仲裁，工作者负责执行具体子任务。这种模式适合任务可拆分、结果可汇总的场景。

另一种常见模式是 Planner-Executor。规划 Agent 负责整体策略，执行 Agent 负责工具调用和动作落地。它适合阶段清晰、计划和执行负担明显不同的任务。

当任务失败成本高时，常见做法是引入评审或批判角色。它不直接执行任务，而是负责检查输出、发现越界或指出遗漏。它的价值在于降低错误级联。

flowchart LR
    A["Manager / Planner"] --> B["Worker / Executor"]
    B --> C["Reviewer / Critic"]
    C --> D["协调 / 仲裁"]
    D --> E["最终结果"]

有些系统会按领域拆专家 Agent，例如代码、文档、数据、运维各自负责不同问题。这种模式只有在领域边界清楚、通信成本可控时才值得引入。

多 Agent 的模式很多，但本质上都是围绕职责分化展开。真正重要的问题从来不是“能不能拆”，而是“拆完以后每个角色是否真的更清楚、更轻、更可控”。下一章会继续讨论这些角色之间到底该怎么通信。