Token on KnightLi的博客

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 换稳定性。

大模型 API 为什么按 Token 收费：一文讲清输入、输出和上下文成本

Sat, 25 Apr 2026 08:44:32 +0800

大模型 API 的计费方式里，最容易让人困惑的一点，就是为什么几乎所有平台最后都会落到 token 这个单位上：大模型为什么按 token 收费，而且不同 token 还会有不同价格。

很多人刚接触模型 API 时，最容易困惑的不是模型能力，而是账单。明明只问了几个问题，为什么费用会涨得这么快？为什么输入便宜、输出更贵？为什么上下文一长，成本就开始明显失控？

如果把这件事讲简单一点，可以先记住一句话：模型收费，买的不是“一次回答”，而是整段推理过程中消耗的计算与带宽资源。

1. 什么是 token

在大模型计费里，token 不是“字数”也不是“单词数”，而是模型处理文本时使用的切分单位。

它可能是：

一个汉字
一个英文单词的一部分
一个标点符号
一小段常见词组合

所以 API 平台通常不会按“每句话”或“每次请求”收费，而是按模型实际读入和生成的 token 数量收费。
这比按请求次数计费更合理，因为同样是一次请求，可能只输入 20 个字，也可能塞进去 20 万 token 的上下文，两者消耗完全不是一个量级。

2. 为什么输入和输出要分开定价

现在大多数模型 API，都会把价格拆成两部分：

输入 token 价格
输出 token 价格

而且常见情况是：输出 token 比输入 token 更贵。

原因并不难理解。

模型处理输入时，本质上是在“读”和“编码”已有内容；但生成输出时，它需要一步一步预测下一个 token，再继续预测下一个 token。这个过程不只是读取，而是持续进行推理和采样，所以通常更耗算力。

你可以把它粗略理解成：

输入：像把材料递给模型
输出：像让模型现场写答案

“现场写”的计算成本，通常比“把材料读一遍”更高，所以输出价格更贵是很常见的设计。

3. 为什么上下文越长，费用越容易失控

很多人以为自己只是在“多贴一点背景资料”，但从模型账单的角度看，这件事的影响往往比想象中大。

原因在于：模型每次调用时，通常都要重新处理当前请求里带进去的整段上下文。

也就是说，如果你当前请求里包含：

系统提示词
历史对话
工具返回结果
长文档片段
代码文件内容

这些内容都会一起进入输入 token 计费。

所以真正让账单变大的，往往不是最后那一句提问，而是它前面拖着的一大串上下文。
当对话轮数增加、工具调用变多、历史消息不断回灌时，token 成本就会被一轮轮放大。

4. 工具调用为什么特别容易涨 token

在 Agent、代码助手、工作流自动化这类场景里，token 消耗通常比普通聊天高得多。

问题不只是“模型回答了一段话”，而是整个流程里会不断出现这些内容：

读文件
看日志
调接口
返回 JSON
执行工具结果再回填给模型

每一次工具调用的结果，只要被重新塞回下一轮上下文，就会继续变成新的输入 token。

这就是为什么很多开发者会发现：
不是模型本身单价特别离谱，而是工作流把 token 账单一层层叠上去了。

例如一个编码 Agent 连续做下面这些事：

读取项目结构
打开几个源码文件
跑一次测试
把报错日志喂回模型
再读取更多相关文件

每一步都可能让后续请求背着更长的上下文继续跑。这样即使单价不变，总账单也会很快增长。

5. 为什么同样是模型，价格会差很多

不同模型的 token 价格差异，背后通常不只是“厂商想卖贵一点”，而是和几个因素直接相关：

模型规模
推理效率
上下文长度
部署成本
目标市场

模型越大、激活参数越多、推理链路越复杂，单次生成一个 token 的成本通常就越高。
如果模型还支持超长上下文、复杂推理、工具调用优化，那它的基础设施压力也会进一步增加。

所以定价本质上是在覆盖几类成本：

GPU / 加速卡资源
显存占用
推理延迟
网络与服务稳定性
峰值并发能力

便宜模型不一定差，贵模型也不一定适合所有场景。很多时候价格差，反映的是“这类能力大概值多少基础设施成本”。

6. 为什么缓存输入会更便宜

不少模型平台现在会提供：

cached input
prompt caching
prefix caching

这类能力的共同思路是：如果一大段输入已经算过，不要每次都从头按原价重算。

比如一个固定 system prompt、固定工具说明、固定长文档前缀，如果每轮都完全重复发送，平台就有机会把其中一部分计算缓存下来。这样同样是输入 token，缓存命中的部分就可以按更低价格计费。

这也解释了为什么很多 API 价格页会出现三档甚至更多价格：

普通输入
缓存输入
输出

它们反映的不是文字内容不同，而是底层计算是否可以复用。

7. “便宜 token”为什么不等于“总成本更低”

很多人看到某个模型“每百万 token 超便宜”，第一反应是总成本一定更低。实际上不一定。

因为总账单大致等于：

token 单价 × 实际消耗量

而实际消耗量又会被很多因素放大：

提示词写得太长
历史消息不清理
工具结果回填过多
输出太啰嗦
一个任务反复重试

所以真正决定账单的，通常不是单价一个变量，而是：

模型单价
每轮输入长度
每轮输出长度
调用次数
工作流设计

这也是为什么“低单价模型”在某些 Agent 任务里，最后总费用仍然可能不低。因为它可能需要更多轮交互、更多补充上下文、更多失败重试。

8. 开发者该怎么估算 token 成本

如果你想在项目里更稳地控制预算，可以先用一个很朴素的估算方式：

统计平均每次请求的输入 token
统计平均每次请求的输出 token
估算一个任务会调用多少轮
再乘上对应模型单价

举个思路上的例子：

每轮输入 8k tokens
每轮输出 1k tokens
一个任务跑 10 轮

那它真正消耗的就不是“一次问答”，而是：

输入约 80k tokens
输出约 10k tokens

如果中途还有日志、工具结果、文件内容不断追加，总量还会继续上升。

所以做预算时，最好不要只看单轮，而要看一个完整任务闭环到底会吃掉多少 token。

9. 怎么实际控制账单

如果你已经在用 API 或 Agent，下面这些做法通常最有效：

缩短 system prompt，避免重复废话
定期裁剪历史消息
工具返回结果只保留必要字段
长文档先检索，再喂局部片段
控制输出长度，避免模型无上限展开
对高价值任务用贵模型，低价值任务用便宜模型

很多时候，省钱最有效的方式不是一味换更便宜的模型，而是先把工作流里无意义的 token 消耗砍掉。

10. 这件事真正该怎么理解

大模型 token 定价，说到底是在给“模型读了多少、想了多少、写了多少”计费。

它不是传统软件那种按账号、按次数、按包月就能完全描述的资源模型，因为模型调用本身就是一个动态计算过程。你塞进去的上下文、拉起的工具、要求的输出长度，都会直接影响成本。

所以理解 token 定价，最重要的不是背价格表，而是先建立一个直觉：

长上下文会涨输入成本
长输出会涨生成成本
工具链会放大总 token
缓存和工作流设计会明显影响账单

只要把这几个点想清楚，大多数模型 API 的价格结构其实都不难理解。

AI 名词解释：用大白话讲清楚 Agent、MCP、RAG 和 Token

Thu, 23 Apr 2026 13:13:40 +0800

刚开始接触 AI，最容易劝退人的通常不是模型本身，而是讨论里那些一串串名词。Agent、MCP、RAG、AIGC、Token 看起来都很常见，但如果没人先用人话讲一遍，很多人其实只是在“眼熟”，并没有真正听懂。

这篇就顺着一组常见入门解释的思路，把 10 个高频 AI 名词压缩成一套更容易记住的解释。目标不是讲得多学术，而是先帮你建立一个能跟上日常讨论的基础框架。

10 个常见 AI 名词，分别是什么意思

1. Agent：不只会聊天的执行型 AI

Agent 可以先理解成“会干活的 AI 助手”。

普通聊天机器人更像是你问一句、它答一句；Agent 则更进一步，它会把任务拆开、安排步骤、调用工具，再把结果交回来。比如你让它帮你整理资料、查信息、生成文档，它不只是给建议，而是可能直接把这些动作串起来做完。

所以 Agent 的关键，不在“会不会说”，而在“能不能做”。

2. OpenClaw：驻留在电脑里的 AI 助手

视频里把 OpenClaw 形容成一种“住在电脑里的 AI 管家”。

你可以把这类工具理解成更贴近桌面操作的 AI 助手：它不只是接收文字，还可能直接观察界面、调用本地工具、按流程执行任务。和普通网页聊天相比，这类工具更强调实际操作能力。

如果说 Agent 是抽象层面的“执行型 AI”，那这类桌面型助手更像是它在个人电脑上的一种具体落地形式。

3. Skills：给 Agent 装上的能力包

Skills 可以理解成 Agent 的功能模块或操作说明。

同一个 Agent，装上不同的 Skills，就能表现出不同的专长。比如有的偏文案生成，有的偏数据整理，有的偏代码处理。它们有点像手机里的 App，也有点像一套套可复用的工作流程。

所以很多时候，不是模型突然“变聪明”了，而是它背后多了一组明确的规则、工具和步骤。

4. MCP：AI 连接外部工具的统一接口

MCP 全称是 Model Context Protocol。

如果用生活里的比喻，它有点像 AI 世界里的 Type-C 接口。以前模型想接不同工具，往往要一套一套单独对接；有了统一协议之后，接入方式会更标准，也更容易复用。

对普通用户来说，最值得记住的一点是：MCP 解决的不是“模型会不会回答”，而是“模型怎么安全、稳定地连上外部工具和资源”。

5. 抽卡：AI 生成结果带有随机性

“抽卡”这个说法常见于 AI 绘图、视频生成和内容创作场景。

意思很简单：同样的提示词、同样的大方向，每次生成出来的结果也可能不一样。有时候效果惊艳，有时候明显翻车，所以很多人会把反复尝试生成结果这件事，形容成像游戏里抽卡。

它提醒我们的其实是同一件事：AI 生成不是固定公式，而是带概率和波动的过程。

6. API：应用和模型之间的连接方式

API 全称是 Application Programming Interface，也就是应用程序接口。

它可以理解成程序之间沟通的标准入口。你在自己的应用、脚本或编辑器里调用模型服务，本质上就是通过 API 发请求、拿结果。

如果把模型服务比作一家餐厅，那么：

菜单像 API 文档
点菜像发起 API 请求
后厨出餐像模型返回结果

所以很多工具表面上看起来不一样，底层其实都是在调用某种 API。

7. 多模态：AI 不只处理文字

“多模态”说的是 AI 不再只会读写文本，而是可以同时处理多种信息形态。

比如它可以看图、听语音、理解视频、生成图片，甚至做实时语音和视频交互。和早期只会处理文字的模型相比，多模态模型更像是在同时拥有“看、听、说、写”的能力。

这也是为什么现在很多 AI 产品的交互方式，已经不再局限于一个输入框。

8. RAG：先检索资料，再组织答案

RAG 是 Retrieval-Augmented Generation，通常译作检索增强生成。

它适合解决一个很现实的问题：模型本身的训练数据有时间边界，也不知道你企业内部的新文档、客服记录和业务规则。RAG 的思路就是，先从指定资料里把相关内容找出来，再结合这些资料生成回答。

它的价值通常体现在三点：

答案更容易贴近真实资料
可以追溯回答依据来自哪里
新文档加入后，知识可随时更新

所以很多企业知识库、智能客服和内部问答系统，底层都会用到 RAG。

9. AIGC：AI 生成内容的总称

AIGC 是 AI Generated Content 的缩写。

它不是某一个单独工具，而是一个总称，泛指 AI 生成出来的内容，包括文本、图片、音频、视频等各种形式。你看到的 AI 写稿、AI 制图、AI 做短视频、AI 配音，都可以放进 AIGC 这个大框里理解。

这个词真正重要的地方在于，它描述的是一种内容生产方式，而不是某个具体模型。

10. Token：模型处理内容时的计量单位

Token 可以理解成模型处理文本时使用的基础计量单位。

它不完全等于“一个字”或者“一个单词”，但在使用层面上，你可以先把它当成模型计算和计费时的通用单位。你的输入会消耗 Token，模型的输出会消耗 Token，上下文里保留的历史内容同样会占用 Token。

所以为什么很多模型服务都在强调上下文长度、成本控制和压缩提示词，本质上都和 Token 有关。