为什么需要多个 AI

单 Agent 的 3 种局限

一、原理：单个 LLM 干不动的三种场景

到第 4 篇为止我们看的都是"单 Agent 怎么工作"——一个 LLM、一份 system prompt、一个主循环、一个 context window。这种"单 Agent 模型"能解决 80% 的场景。

但有 20% 的场景，单 Agent 解决不了。我们看具体哪些场景。

场景 1：context 装不下

用户让 AI 重构一个 50 万行的大代码库。AI 要先理解架构（读 100 个文件）、再设计方案（综合所有信息）、再实施（改 50 个文件）。

50 万行代码就算只取关键文件 100 个，也几十 K tokens。加上 system prompt、对话历史、工具调用历史——很快撞到 context window 上限。

单 Agent 装不下这种"广覆盖任务"——它要么省略阅读（决策质量低）、要么频繁触发 compaction（细节丢）。

场景 2：任务需要专精

用户让 AI 修 bug。AI 要做几件事：

• 探索代码（找到 bug 所在）—— 需要"读得多、记不深"的能力
• 设计修复方案 —— 需要"想得清楚、考虑全面"的能力
• 写测试 —— 需要"边界穷举、细节严谨"的能力
• 实施修复 —— 需要"小心改、不破坏其他"的能力

这 4 件事的"理想 system prompt"不一样：

• 探索 → "你是 explorer，多读快读，记关键路径"
• 设计 → "你是 architect，慢想全面，提出方案"
• 测试 → "你是 test writer，覆盖边界，考虑异常"
• 实施 → "你是 implementer，最小改动，不破坏现有"

一份 system prompt 同时教 LLM 这 4 个角色——不现实。每个角色的偏好相互冲突——"多读快读"跟"慢想全面"不在一起。

单 Agent 没法做"角色冲突的复合任务"。

场景 3：任务可以并行

用户让 AI 写一份调研报告——"对比 React、Vue、Svelte 的 reactivity 系统"。

理想做法：派 3 个 AI 同时调研——一个看 React、一个看 Vue、一个看 Svelte，最后汇总。

如果单 Agent 串行做——读 React → 读 Vue → 读 Svelte → 汇总——时间是 3 倍。

单 Agent 没法利用"任务可并行"的优势——它一次只能跑一个上下文。

这 3 个场景对应 multi-agent 的 3 个驱动力——context 隔离 + 角色专精 + 并行加速。

理论上的解决方案叫 multi-agent——一个产品里有多个 AI，根据需要派生子 agent 处理特定任务。每个子 agent 有自己的 context、自己的角色、自己的工具集。它们相互配合完成大任务。

但 multi-agent 不是想做就能做好——它涉及很多产品判断：

• 什么时候派生子 agent vs 主 agent 自己做？
• 子 agent 应该看到主 agent 的什么 context？
• 子 agent 返回的结果怎么整合到主 agent？
• 子 agent 失败了怎么办？
• 多个子 agent 之间怎么协调？

这些判断每个 AI 产品都要做。opencode 的选择是其中一种——我们看具体怎么处理。

二、案例：opencode 7 个 native agent 的分层

opencode 内置了 7 种 native agent——每种有自己的角色、工具集、权限。从 R5 / R6 研究文档看，它们是：

这 7 个 agent 分三层：

第一层：主 agent（用户直接对话）

build 和 plan 是用户直接对话的 agent。用户敲下 prompt，对话的是 build 或 plan。

build 是"全能型"——可以动手做任何事。plan 是"思考型"——只能读、写方案。

用户通过 mode 切换在 build / plan 之间切。

第二层：子 agent（主 agent 派生的专家）

explore 和 general 是子 agent。它们不能被用户直接对话——只能被主 agent 通过 task 工具派生。

explore 是"探索专家"——只读，专门走深路径。主 agent 派生 explore 让它"去看 X 模块的实现"——explore 用大量 context 探索，最后返回一个简洁结论给主 agent。

general 是"通用执行者"——主 agent 想分包某段工作给子 agent 时用。

第三层：hidden agent（用户看不见的系统级 AI）

title / summary / compaction 是 hidden agent——用户和主 LLM 都不知道它们存在。它们在后台跑系统级任务（4.7 章讲过）。

这 3 层有清晰的信息流向：

用户
  ↓ (对话)
build / plan agent (主)
  ↓ (task tool 派生)
explore / general agent (子)
  ↓ (返回简洁结果)
build / plan agent (整合到主对话)

[并行]
hidden agent (在后台跑，用户和主 agent 都看不到)

这是 multi-agent 的"骨架"——3 层，每层有明确职责、明确通信方式。

为什么 opencode 选这个结构？因为它解决了开头的 3 个场景：

对场景 1（context 装不下）的解决：

主 agent 派生 explore subagent 处理"大量探索"——subagent 有自己的 context，跑完释放。主 agent 不被吃满。

对场景 2（角色专精）的解决：

不同 agent 有不同 system prompt：

• build 的 system prompt 是"全能 coding agent"（5 张脸之一）
• plan 的 system prompt 是 "plan-mode.txt"（5 步工作流）
• explore 的 system prompt 教它"探索快、记关键"
• general 的 system prompt 通用

每个 agent 在自己的角色里专精。

对场景 3（并行加速）的解决：

主 agent 可以同时派生多个 subagent——并行跑。task.txt 明确鼓励："Launch multiple agents concurrently whenever possible"。

3 个调研子 agent 并行——3 倍速度。

opencode 通过这个"3 层 + 7 agent"的设计，把单 Agent 解决不了的 20% 场景覆盖了。

三、设计启示：什么任务该单 Agent、什么该多 Agent

这一章的核心论点：multi-agent 不是默认选择——只在单 Agent 真的解决不了时才用。

判断什么任务该用 multi-agent，下面几条原则有用：

1. 默认偏向单 Agent

如果一个任务用单 Agent 能跑——优先单 Agent。简单、低成本、容易调试。

只在以下情况升级到 multi-agent：

• context 真的装不下
• 任务需要角色冲突的专精
• 任务可以并行

2. 识别"广覆盖任务"用 subagent 隔离 context

阅读大代码库、研究多个文档、对比多个方案——这些任务的 context 需求都很大。

派生 subagent 隔离 context——主 agent 不被吃满。

3. 识别"角色冲突任务"用不同 agent 类型

主 agent 需要"主动、能动手"——偏向 build。

但任务里有"只想思考、不动手"的阶段——派生 plan 风格的 subagent，让它在只读环境思考。

不要让一个 agent 既能"主动改"又"克制不改"——不现实。

4. 识别"可并行任务"用并发 subagent

任务可以拆成独立子任务——并行派生多个 subagent。

task.txt 鼓励并行——但需要主 agent 学会"识别可并行"。这是个能力，需要训练（用例多了 LLM 自然学会）。

5. agent 类型不要太多

opencode 有 7 个 agent（含 hidden）——是个合理范围。

如果你做 AI 产品有 20 个 agent——LLM 选择困难、维护负担大。控制在 5-10 个，每个有清晰职业。

6. 明确每个 agent 的 system prompt

不要写"通用 agent prompt"——每个 agent 有自己的 system prompt，反映它的角色。

opencode 的 plan-mode.txt、explore agent 的 prompt 都是专门写的。

7. 子 agent 的工具集要约束

不是所有 agent 都能用所有工具。explore 只读、plan 只写 plan file、build 全能。

约束让每个 agent 在自己的"安全区"——不会越界。

8. 子 agent 的返回结果要简洁

主 agent 调用子 agent，最关心的是结论。子 agent 不要返回长篇大论——返回简洁的"我发现了 X、建议 Y、风险 Z"。

让主 agent 容易整合到自己的工作流。

最后一个观察。Multi-agent 是个强大但被滥用的设计模式。

很多产品看到 "multi-agent" 火，就把简单任务也拆成多个 agent——结果是 over-engineering。3 个 agent 协作做的事，1 个 agent 直接做更快。

Multi-agent 的真正价值是解决单 Agent 解决不了的问题——不是"看起来更高级"。

opencode 的克制态度——只在真正需要时用 subagent、子 agent 有清晰角色和约束、主 agent 默认自己做——是值得学的。

下一章 5.2 我们看 multi-agent 的两种根本模型——专家咨询 vs 代理人。opencode 的选择决定了整个架构姿态。