想象这样一个场景：你打开一个AI编程助手，输入”好的”两个字让它确认一下。就这两个字——在它真正”看到”这两个字之前，它已经在后台默默消耗了大约33,000个token的计算配额。而另一个功能类似的工具，同样的情况下只用了约7,000个。
这不是比喻，也不是估算。这是Systima团队在Anthropic的API接口上加了一层日志代理，逐条记录每一次请求的原始数据后得到的实测结论。他们在博客中公开了完整的实验方法和原始数字，随后这篇文章在Hacker News上获得了超过400个推荐和200多条讨论。
笔者想用普通人能理解的方式，聊聊这个数字背后的三件事：AI编程工具在”看到你的话之前”到底干了什么？为什么子Agent是真正的token黑洞？以及，按量计费的商业模式在其中扮演了什么角色。
Token是什么？为什么它像”汽油”一样烧得飞快？
在进入具体数字之前，先解释一个关键概念。Token可以理解为AI处理文本时的最小计量单位——它不是”一个字”，大约是英文的0.75个单词，或中文的1到2个字。当你使用按量付费的AI服务时，每处理一个token就产生一笔账单。
AI编程工具与普通的AI对话不同。你在网页版跟Claude聊天，它收到的基本上就是你的提问。但AI编程工具需要在你的提问之外，额外塞入大量的”准备工作”——告诉AI它是谁、它能调用哪些工具、你的项目有什么规则、现在的工作目录在哪、操作系统的环境信息等等。
这些额外内容被称为”脚手架”（harness overhead）。问题是，脚手架的大小差异巨大。
33,000 vs 7,000：一次回复”OK”的账单对比
Systima的实验设计很直接：让两个AI编程工具——Anthropic官方的Claude Code，和开源的OpenCode——分别执行同一个最简单的任务：回复”OK”。
Claude Code在读到”OK”这两个字之前，先向API发送了约33,000个token。这些token的构成是这样的：大约6,500个token是系统提示词（告诉AI”你是谁、你该怎么做”），约24,000个token是27个工具的定义（读文件、写文件、执行命令、管理子Agent、定时任务……），还有约2,000个token是注入的提醒块（任务状态、可用技能列表、当前环境信息）。
OpenCode只用了约7,000个token：约2,000个token的系统提示词，约4,800个token的10个工具定义。它没有额外的提醒块，结构非常精简。
这里有一个容易被忽略的细节：这33,000个token并不是”花一次就完了”。在AI编程工具的工作模式中，每一轮对话——每一次跟模型的往返——都要重新发送这些脚手架内容。也就是说，如果你的任务需要跟AI来回沟通10轮，光脚手架就要消耗330,000个token，还不算你实际的代码和对话。
缓存本应省钱，但Claude Code把它弄砸了
AI服务商通常会提供一种叫”提示缓存”的机制：如果连续请求中大部分内容没有变化，就可以用很低的价格从缓存中读取，而不是重新计算。这是控制成本的关键手段。
但Systima发现了一个关键差异：OpenCode的请求前缀每次都是字节级完全相同的，这意味着它只需要写一次缓存，之后每次读取都按十分之一的价格计费。而Claude Code在同一个任务的连续请求中，反复重写了数万个缓存token，同一任务下写入缓存的次数是OpenCode的54倍。
缓存写入比缓存读取贵得多。换句话说，用户看到账单数字上涨，很大程度的原因是工具没有高效地利用缓存。
生产环境的真实账单：从33K到85K
上面的33,000还是”裸奔”状态——没有项目配置、没有插件、没有额外工具。真实的生产环境是什么样的？
Systima做了一个”叠加实验”。他们先在一个空项目中测试，然后逐步加入真实开发场景的配置：
第一步，放入一个72KB的项目指令文件（AGENTS.md或CLAUDE.md，用来告诉AI你的代码规范）。单这一步就给每个请求增加了约20,000个token。
第二步，接入5个轻量级的MCP服务器（让AI能读写邮件、管理任务、查询数据库等）。又加了约5,000到7,000个token。
累计下来，在一个真实的开发环境中，Claude Code在读到用户提问之前，就已经消耗了75,000到85,000个token。而OpenCode在类似的叠加下也会膨胀，但由于起点低，绝对值仍然可控。
子Agent：真正的token黑洞
如果说脚手架消耗是”油耗偏高”，那子Agent就是”油箱漏了”。
子Agent是Claude Code的一项重要功能：当任务比较复杂时，主Agent可以派出多个”分身”并行工作，每个子Agent独立读取代码、分析问题、返回结果。这听起来高效，但代价惊人。
Systima拿同一个任务做了对比：直接执行消耗了121,000个token；改用两个子Agent并行执行，消耗暴涨到513,000个token——是原来的4.2倍。
为什么差这么多？因为每个子Agent都是一个独立的工作单元。它有自己的系统提示词（虽然比主Agent精简），有自己的工具集，需要重新读取项目文件来理解上下文。子Agent完成任务后，它的整个对话记录还要被主Agent”吞下去”作为参考。这就像你派两个人去查资料，结果每个人回来时不仅带了答案，还带了一整箱他们翻过的所有原始文件。
HN上一位用户的经历更加极端。他写道：“我给了Claude Code一个比较大的任务，它立刻启动了7个子Agent，在我的预算烧光之前，没有一个子Agent完成了任务。5小时后再试，结果一样。“而同样的任务，用主Agent按顺序执行，完全没问题。
Anthropic的商业模式困局
到这里，一个自然的疑问浮现：这是设计缺陷，还是商业模式使然？
Anthropic的API是按token计费的。Claude Code作为一个官方工具，它的token消耗越大，Anthropic的收入越高。但这不意味着一定是”故意设计”——更可能是一种结构性激励：当你的收入取决于用户消耗多少token时，你不会像开源社区那样有强烈的动力去精简脚手架。
OpenCode之所以能做到7,000个token的”地板”，很大程度上因为它是一个开源项目——它的设计目标不包括最大化API收入。而Claude Code的27个工具、多层提醒块、子Agent的完整引导机制，每一个设计决策都有”功能更全”的正当理由。但当这些”功能更全”被叠加起来，用户的账单就成了副产品。
但Claude Code也有赢的时候
公平地说，Systima的测试也发现了一个对Claude Code有利的场景。
在一个需要多步骤操作的任务中（写代码、运行测试、根据错误修改、再测试），Claude Code的总消耗反而比OpenCode低了。原因是Claude Code会把多个工具调用打包在一次请求中完成，而OpenCode是一个工具调用走一轮请求。虽然Claude Code每轮请求的底座更重，但OpenCode因为没有打包能力，重复支付了9次底座开销，最后总账反而更多。
这个发现揭示了一个微妙的事实：工具的token效率不仅仅是底座有多轻，还取决于它如何组织工作流程。底座重但能打包，和底座轻但要反复跑，孰优孰劣取决于具体的任务。
这对普通用户意味着什么？
如果你不写代码，可能会觉得这是一个”程序员的问题”。实际上，随着AI工具从”聊天”走向”干活”，这种按量计费的计费模型会影响到每一个使用者。
当你在Cursor里改一行代码，或者在Claude Code里让AI帮你修一个bug，每一次操作背后都在发生着类似的故事：大量的系统指令正在被重复发送，子Agent在后台旋起旋灭，缓存在被反复重写——而账单就在这些看不见的动作中悄悄累积。
Systima的实验把那些原本藏在黑箱里的数字拉到了阳光下。作为使用者，了解这些数字的存在，本身就是一种信息上的赋权。
或者用更直白的话说：下次看到API账单的时候，你会知道，那上面的数字，大概只有一小部分是你真正用到的。
参考链接：
- Systima: Claude Code vs OpenCode Token Overhead
- HN 讨论 (item?id=48883275)