subagent 会多花多少 token？多 agent 成本与使用策略

使用 subagent 或多 agent 工作流，通常都会增加 token 用量。区别不在于“会不会增加”，而在于增加多少、换来的并行效率和稳定性是否值得。

如果任务很小，直接让主 agent 完成通常更省。只有当任务可以清楚拆分，或者需要独立复查时，subagent 才更容易体现价值。

subagent 不是更便宜的并行线程

很多人第一次看到 subagent，会下意识把它理解成“并行线程”：主 agent 做一部分，subagent 做另一部分，速度变快，所以应该更划算。

实际不是这样。subagent 本质上也是一个独立的模型调用。它需要读任务说明、理解上下文、读取文件、分析问题，再输出结果。也就是说，它不是主 agent 的免费副本，而是额外启动了一条推理链路。

所以使用 subagent 的核心判断不是“能不能并行”，而是“并行带来的时间节省、质量提升，是否值得额外 token 成本”。

为什么会增加 token

一次 subagent 调用通常会额外消耗这些 token：

• 主 agent 写给 subagent 的任务说明；
• 传递给 subagent 的上下文；
• subagent 自己读取文件和分析问题；
• subagent 生成结果或修改说明；
• 主 agent 回收结果后的复查、整合和验证。

如果多个 agent 读取同一批大文件，重复消耗会更明显。尤其是代码库分析、长文档翻译、批量内容整理这类任务，如果拆分不好，token 会花在重复理解上下文上。

重复读取上下文是最大的 token 浪费

subagent 真正浪费 token 的地方，往往不是“多开了一个 agent”，而是多个 agent 反复读同一批材料。

比如一个任务要处理 6 篇文章，如果 4 个 agent 都先读完整站点结构、完整技能文档、完整文章列表，再各自处理一点点内容，那么并行会很贵。更好的做法是先由主 agent 确定边界，再让每个 subagent 只读自己负责的文章目录。

更省 token 的拆法通常是：

• 每个 agent 只负责一个明确目录；
• 给 subagent 的上下文越短越好；
• 不让多个 agent 重复做同一类探索；
• 主 agent 最后统一复查，而不是让每个 agent 都做全量复查；
• 能用脚本统一检查的部分，不交给多个 agent 反复检查。

换句话说，subagent 的成本控制重点是边界，而不是数量。

大概会增加多少

下面是一个粗略估算，实际消耗取决于上下文长度、文件大小、任务复杂度和 agent 数量。

这不是精确计费公式，只是经验范围。真正的消耗还要看每个 agent 是否需要读完整文件、是否需要长推理、是否会反复等待和补充上下文。

如何给 subagent 写更省 token 的任务说明

任务说明越宽泛，subagent 越容易自己去探索上下文，token 消耗也越高。更省的写法是把边界写清楚。

一个好的 subagent 任务说明应该包含：

• 只允许处理哪些文件或目录；
• 哪些文件只能读，哪些文件可以写；
• 已有文件是否允许覆盖；
• 需要保留哪些字段，比如 date、slug、aliases；
• 输出时只汇报什么结果；
• 不需要做哪些事情，比如不要跑完整构建、不要改无关文件。

例如，处理翻译时，不要只写“把文章翻译成多语言”。更省 token 的写法是：“只处理 content/post/2026/05/240，读取 index.zh-cn.md，只创建缺失的 index.en.md、index.zh-tw.md、index.ja.md、index.es.md，已存在则跳过，保留 date 和 slug。”

这种说明更长一点，但能减少 subagent 自行猜测和重复探索，整体通常更省。

按文件/目录拆分，比按语言/步骤拆分更省

如果是批量文章翻译，按“文章目录”拆通常比按“语言”拆更好。

比如要翻译 6 篇文章，每篇都要生成英文、繁体、日文、西语。更推荐让一个 agent 负责一篇文章目录内的所有语言，而不是让一个 agent 负责所有英文、另一个负责所有日文。

原因很简单：一篇文章的 front matter、代码块、链接、表格和语义上下文只需要读一次。如果按语言拆，多个 agent 会重复读取同一篇源文，token 会被放大。

同样的逻辑也适用于代码任务。优先按模块、目录、组件拆分，而不是按“先分析、再实现、再测试”这种步骤拆分。步骤拆分很容易让每个 agent 都重新读一遍上下文。

什么情况下值得用

subagent 的价值主要在两点：并行和独立视角。

适合使用的场景包括：

• 多篇文章批量翻译；
• 多个目录可以独立修改；
• 前端、后端、测试可以明确分工；
• 一个 agent 写实现，另一个 agent 做风险复查；
• 高风险修改需要第二视角检查。

这类任务里，token 会增加，但总耗时可能明显下降，而且每个 agent 只盯一块内容，注意力更集中。

什么时候值得用一个 agent 做复查

复查型 agent 不一定总值得用。它适合风险高、影响面大、主 agent 容易遗漏细节的任务。

比较值得加复查 agent 的情况包括：

• 修改涉及登录、支付、权限、数据删除；
• 多语言内容会影响分类、URL、站内链接；
• 大范围重构后需要独立找回归风险；
• 用户明确要求 code review 或风险审查；
• 主 agent 已经做了实现，但需要第二视角看边界条件。

不值得加复查 agent 的情况也很明确：单文件小改、标题微调、简单 front matter 修正、只跑一个命令。这些任务主 agent 自查就够了。

什么情况下不值得用

不适合使用 subagent 的场景很常见：

• 单文件小改；
• 简单问答；
• 只需要跑一个命令；
• 改动范围很小；
• 任务不能清楚拆分；
• subagent 必须反复等待主 agent 提供上下文。

这类任务用 subagent 往往只是增加开销。主 agent 直接处理更快，也更省 token。

我的默认策略：省 token 优先，风险任务才加复查

如果目标是尽量节省 token，可以采用下面这套策略：

• 小任务：不用 subagent。
• 中等任务：不用 subagent。
• 大批量任务：默认也不用 subagent，除非用户明确要并行提速。
• 高风险任务：可以多用一个 agent 做复查，用 token 换稳定性。

这套策略更偏保守。它牺牲了一部分并行速度，但能减少重复读取上下文和重复推理带来的 token 消耗。

如果任务很大但不高风险，我也会优先考虑脚本、批量检查和本地结构化处理。只有当拆分非常清楚，或者用户明确希望并行提速时，才更适合引入多个 agent。

更均衡的策略

如果既想控制成本，又不想完全放弃并行，可以采用折中方案：

• 默认主 agent 直接做；
• 只有任务能按文件或目录明确拆分时才考虑 subagent；
• subagent 只读取自己负责的文件；
• 不让多个 agent 同时读同一批大文件；
• 主 agent 最后统一复查关键字段、测试结果和 Git diff；
• 高风险任务才增加一个独立复查 agent。

这能避免“为了并行而并行”。subagent 应该服务于明确的效率或质量目标，而不是成为默认动作。

小结

subagent 和多 agent 一定会增加 token 用量。单个 subagent 可能只是增加一点，多个 agent 并行时则可能成倍增加。

是否值得用，取决于任务本身：如果任务能清楚拆分，或者风险高到需要独立复查，额外 token 可能是值得的；如果只是单文件小改、简单问答或常规检查，直接由主 agent 完成更省。

一句话总结：小任务省 token，大任务看拆分，高风险才用额外 agent 换稳定性。