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

Sun, 31 May 2026 14:17:42 +0800

使用 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 数量。

场景	token 增加
单个 subagent 处理一个小任务	约 `1.2x - 2x`
2-4 个 agent 并行处理可拆分任务	约 `2x - 5x`
多个 agent 各自读取大量文件、做长分析	可能 `5x+`
主 agent 和 subagent 重复读同一批大文件	浪费最明显

这不是精确计费公式，只是经验范围。真正的消耗还要看每个 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 换稳定性。

成本优化 on KnightLi的博客