Subagent 是什么

专家咨询 vs 代理人

一、原理：两种 multi-agent 模型的本质差别

上一章我们看到 opencode 通过 multi-agent 解决"context 装不下、角色专精、并行加速"3 个问题。但 multi-agent 的实现方式有两种根本不同的模型——它们的差别决定整个产品架构姿态。

我们对比两种模型。

模型 A：代理人（Agent as Delegate）

主 AI 把任务完整委托给子 AI——"你去做这件事，做完告诉我"。

主 AI 让子 AI 独立工作——子 AI 有自主权决定怎么做、用什么策略、跟谁交互。子 AI 完成后返回"我做完了，结果是 X"。

类比人类——你让助理"帮我订下周去上海的机票，预算 3000 以内，靠走道"——你不管助理怎么订（携程？App？打电话？）。助理回来报告"订好了，国航 CA1234，3:00 pm 起飞"。

这种模型的关键特征：

• 主 AI 不参与子 AI 的过程
• 子 AI 有完整决策权
• 通信是任务+结果模式

模型 B：专家咨询（Agent as Consultant）

主 AI 找子 AI 咨询特定信息——"帮我看看 X 是什么样的"。

子 AI 不替主 AI 做决策——它只提供信息和建议。主 AI 拿到子 AI 的回答后，自己整合到对当前任务的判断里。子 AI 不知道主任务的全貌，只关心自己被问的问题。

类比人类——你做技术决策时找资深工程师咨询"React 跟 Vue 哪个更适合 X 项目"——专家给你分析和建议。但最终决定怎么做的还是你。

这种模型的关键特征：

• 主 AI 参与决策——子 AI 只提供信息
• 子 AI 有有限的视野——只看到被问的问题
• 通信是问题+答案模式

两种模型听起来微妙，但架构影响巨大：

架构差异 1：信息可见性

代理人模型——子 AI 需要看到全局任务才能独立完成。"订机票"任务的子 AI 需要知道用户偏好、预算、目的、约束……所有这些都要传给子 AI。

专家咨询模型——子 AI 只需要看到被问的问题。"React 怎么样"这个问题不需要传"我在做什么项目"——专家就回答 React 本身。

后者的信息传递成本低得多。

架构差异 2：信任传递

代理人模型——主 AI 必须信任子 AI 的决策。子 AI 返回"已订好"，主 AI 不会去验证——必须接受结果。

专家咨询模型——主 AI 保留判断权。子 AI 说"React 适合"，主 AI 还可以质疑、对比、选择不接受。

后者给主 AI 更多控制力。

架构差异 3：失败影响

代理人模型——子 AI 失败 = 任务失败。主 AI 没法补救（它不知道子 AI 在做什么）。

专家咨询模型——子 AI 失败（给不出答案）= 主 AI 缺少一个信息源。主 AI 可以问别的专家、跳过这个问题、用其他方式补救。

后者更鲁棒。

架构差异 4：用户信任

代理人模型——用户对 AI 的信任要求高（AI 替我做决策）。如果 AI 出错——用户感觉"被 AI 坑了"。

专家咨询模型——用户对 AI 的信任要求低（AI 给我建议，我自己决定）。即使 AI 给错建议——用户感觉"我自己选的"。

后者对用户更友好。

opencode 选了专家咨询模型——这是个明确的产品判断。我们看具体怎么做。

二、案例：opencode 选了专家咨询模式

看 task.txt 里关于 subagent 的描述：

"Each agent invocation starts with a fresh context unless you provide task_id to resume the same subagent session. When starting fresh, your prompt should contain a highly detailed task description for the agent to perform autonomously and you should specify exactly what information the agent should return back to you in its final and only message to you."

注意几个关键点。

关键点 1：fresh context

子 agent 启动是 fresh context——不继承主 agent 的对话历史。子 agent 只看到主 agent 传给它的 prompt。

这意味着——主 agent 必须显式构造子 agent 需要的所有 context。如果主 agent 想让子 agent 处理"用户最初的需求"——必须把那段需求再写一遍传过去。

这是个专家咨询模型的特征——专家不需要看你的全局任务，只需要看你的问题。

关键点 2：specify exactly what information to return

主 agent 必须明确告诉子 agent "你要返回什么"。

"返回你找到的所有相关文件路径"——具体。

"做做看 X"——模糊（这是代理人风格）。

明确的"返回什么"让子 agent 聚焦——它知道自己的输出会被主 agent 怎么用。

关键点 3：one final message

子 agent 完成后只返回一条 message——单次回答，不是持续对话。

这是个关键限制——子 agent 不能跟主 agent "讨论"、不能 "follow-up"、不能"反问"。一次性的问答。

如果你想再问——再派一个 subagent（或者用 task_id resume）。

关键点 4：trust the output

"The agent's outputs should generally be trusted"

主 agent 收到子 agent 的回答后应该信任——不要重新验证、不要重新做一遍。

这看似跟"专家咨询保留判断权"矛盾——但其实不矛盾。专家咨询的"判断权"是整合权（主 agent 决定怎么用这个信息），不是"否决权"（主 agent 不会说"专家错了"）。

主 agent 可以决定"这个建议跟我其他信息冲突，不用它"——但不会"我重新调研一遍专家说的事"。后者浪费 token，没意义。

把这 4 个关键点合起来——opencode 的 subagent 模式是这样的：

主 agent 派生子 agent：
- 传给子 agent 详细问题
- 明确指定子 agent 要返回什么
- 等子 agent 跑（fresh context）
- 收到子 agent 一条回答
- 信任回答，整合到自己的工作

这是个专家咨询模型——子 agent 是"被咨询的专家"，主 agent 是"做决策的人"。

为什么 opencode 选这种模式？几个理由。

理由 1：避免子 agent 的"自由发挥"破坏主任务

如果是代理人模式——子 agent 有自主权——它可能"创造性发挥"，做了一些主 agent 没期望的事。比如主 agent 派生子 agent "查 X 文档"，子 agent 决定"顺便也改一下 X 实现"——破坏了主任务。

专家咨询模式约束子 agent 只回答问题、不替主 agent 做决策——避免越界。

理由 2：调试容易

如果 multi-agent 出问题——专家咨询模式容易 trace：主 agent 问了什么、子 agent 答了什么、主 agent 怎么整合——线性流程。

代理人模式难 trace——子 agent 内部可能跑了 10 个子任务、做了 20 个决策——出问题不知道在哪。

理由 3：成本可控

专家咨询模式下，子 agent 的工作量有限（回答一个问题）——成本可估算。

代理人模式下，子 agent 可能跑很久很多步——成本不可控。

理由 4：跟主任务的整合自然

子 agent 返回"我发现的事实是 X"——主 agent 直接整合到自己的"工作记忆"。

如果子 agent 返回"我做了这些操作"——主 agent 需要重新理解操作的影响。整合成本高。

理由 5：失败局部

子 agent 失败 = 主 agent 缺一个信息 = 主 agent 可以问别的、跳过、用其他方式。

代理人模式下 subagent 失败 = 整段任务失败——破坏性大。

这 5 个理由合起来——专家咨询模型对 opencode 这种"开发者工具"场景更合适。

三、设计启示：差别决定整个架构姿态

这一章的核心论点：multi-agent 模型的选择是个根本设计判断——专家咨询和代理人对应完全不同的产品姿态。

如果你做 AI 产品考虑 multi-agent，下面几条原则有用：

1. 先想清楚要哪种模型

不要稀里糊涂"做了 multi-agent"。明确选择：

• 专家咨询——主 AI 决策、子 AI 提供信息
• 代理人——主 AI 委托、子 AI 自主完成

每种适合不同场景：

• 开发者工具 → 专家咨询（用户要控制）
• 助理类产品 → 代理人（用户要省心）
• 自动化产品 → 代理人（无人介入）
• 创意工具 → 专家咨询（用户要保留判断）

2. 专家咨询模型的子 agent 要返回简洁信息

子 agent 的回答应该是"事实陈述 + 建议"——主 agent 容易整合。

不要让子 agent 返回长篇大论的"我做了什么过程"——主 agent 看不完。

3. 代理人模型的子 agent 要充分授权

如果你选代理人——给子 agent 完整 context、足够工具、充分时间。

不要"半委托"——又让子 agent 自主又限制它太多——子 agent 困惑。

4. 明确"信任输出"

不论哪种模型，prompt 里明确"trust the output"——避免主 agent 重做子 agent 的工作。

5. 让子 agent 视野有限

不要让子 agent 看到全局任务。它只需要看自己被分配的部分。

视野有限让子 agent 聚焦、减少越界风险。

6. 调试工具要支持 multi-agent

logging 要能 trace 子 agent 调用——"主 agent 在 turn X 派生了 Y subagent，prompt 是 Z，结果是 W"。

没有这种 trace，multi-agent 出问题没法 debug。

7. 成本监控要分层

记录主 agent 和子 agent 各自的 token 消耗。如果子 agent 的成本占比过高——说明 multi-agent 设计有问题（任务该自己做的派给了 subagent）。

8. 失败要局部化

不论哪种模型——子 agent 失败应该不影响主 agent。主 agent 看到失败，可以决定补救路径。

把"局部失败 → 全局失败"的传染切断。

最后一个观察。Multi-agent 模型的选择决定你产品的姿态。

代理人模型是"AI 替你做事"——产品姿态是"自动化、省心"。

专家咨询模型是"AI 帮你做事"——产品姿态是"辅助、可控"。

两种姿态都有市场。但你必须选一个——不能模糊。模糊会让用户体验混乱：用户期望 AI 自动做（代理人）但实际 AI 一直问问题（咨询）——失望。或者反过来——用户期望保持控制但 AI 自己做了——惊吓。

opencode 选了专家咨询——清晰的开发者工具姿态。用户保持掌控权、AI 是高级帮手。

下一章 5.3 我们看 opencode 在专家咨询模式下的一个有意思设计——子 agent 不知道自己是子 agent。