引言：你真的了解AI编程Agent花掉你多少钱吗？

当你向Claude Code输入一行指令"帮我修复这个bug"时，你可能以为模型只收到了你输入的那几个字。但事实远非如此。Systima团队近日发布了一份详尽的基准测试报告，揭示了一个令人震惊的事实：Claude Code在读取你的提示之前，就已经发送了约33,000个token——而同类工具OpenCode仅需约7,000个token。这意味着，每当你和AI编程助手对话一次，你就已经在为一个你看不见的"隐藏账单"买单。

这份报告在Hacker News上获得了超过440个赞，引发了开发者社区的广泛讨论。今天，我们来深入剖析这个被忽视的"Token膨胀"问题，以及它对AI编程工具生态的深远影响。

Token开销的冰山结构：33k token从何而来？

Systima团队通过一个本地LLM网关，在API边界层精确捕获了每个请求的完整payload。他们的测试环境非常透明：Claude Code 2.1.207和OpenCode 1.17.18，都锁定在claude-sonnet-4-5模型上。

结果显示，Claude Code的33,000 token基线主要由三部分构成：工具定义（约24,000 token）、系统提示（约6,500 token）和注入的脚手架代码。相比之下，OpenCode的工具定义仅约4,800 token，系统提示约2,000 token。工具schema是最大的token消耗者——Claude Code注册了27个工具，每个工具的JSON Schema描述都贡献了大量token。

更值得关注的是，当你添加一个72KB的项目指令文件（AGENTS.md或CLAUDE.md）时，每个请求会额外增加约20,000 token。再加上5个MCP服务器的schema，每个请求在用户输入任何内容之前就已经达到了75,000至85,000 token——这已经占据了200K上下文窗口的40%以上。

缓存效率的巨大鸿沟：54倍的差距

报告中最具技术深度的发现来自缓存行为分析。OpenCode的请求前缀在每次运行中都保持字节级一致——相同的系统提示、相同的工具定义、相同的消息结构。这意味着它只需要在会话开始时缓存一次payload，后续请求几乎零缓存写入。

而Claude Code的行为截然不同。它在同一任务中发出了三种不同类型的请求（预热探测、主对话、子代理调用），每种都有不同的前缀。更糟糕的是，Claude Code在会话中间多次完整重写其约43K token的前缀——在完全相同的任务上。Systima在不同模型（Sonnet 4.5和Fable 5）上重复测试，都观察到了这个行为。

量化来看：在同一文件摘要任务上，Claude Code的缓存写入量是OpenCode的5.9到54倍。由于缓存写入按溢价计费（5分钟TTL为1.25倍基础费率，1小时TTL为2倍），这个差异直接反映在账单上。正如报告指出的："重新写入字节级相同的缓存前缀不会带来任何代码质量提升——它只是为相同的内容再次付费。"

子代理的乘数效应：4.2倍的token爆炸

当任务复杂度上升，需要将工作分发给子代理时，token消耗会出现戏剧性增长。Systima测试了一个需要多步骤处理的任务：Claude Code使用6个HTTP请求，累计输入约199,000 token；而OpenCode使用4个请求，仅消耗约41,000 token。

在涉及子代理分发的场景中，差距更为惊人。一个直接完成需要121,000 token的任务，分发给两个子代理后消耗了513,000 token——4.2倍的膨胀。原因很简单：每个子代理都要支付自己的启动成本（系统提示+工具定义），而父代理还要读取子代理的完整转录。

OpenCode在这方面做了显著优化：其子代理请求携带一个精简的1,379字符系统提示和5个工具，而非完整的27个工具集。这个设计差异直接影响了生产环境中的token账单。

MCP服务器的隐性税：每个1,000-1,400 token

MCP（Model Context Protocol）服务器是AI编程工具扩展能力的重要机制，但每个服务器都带来了不可忽视的token税。Systima测试了从1个到5个MCP服务器的配置，发现每个小型MCP服务器每次请求增加约1,000至1,400 token。5个服务器将Claude Code的工具数量从27个增加到69个，OpenCode从10个增加到52个。

这意味着一个配置了11个MCP服务器（覆盖邮件、日历、任务管理等功能）加上72KB指令文件的OpenCode实例，首次请求就达到了90,817 token——携带179个工具和277KB的schema。而Claude Code在类似配置下达到了约75,000 token和118个工具。

Anthropic的J-Lens：理解LLM在想什么

与Token膨胀问题形成有趣对比的是，Anthropic在同一周发布了关于LLM内部机制的重要研究成果。他们开发了一种名为"Jacobian Lens"（J-Lens）的新技术，揭示了Claude模型内部一个被命名为"J-Space"的隐藏空间。

J-Space包含与模型即将生成的词汇相关的独立词语——可以理解为模型在"开口说话"之前"脑海中"浮现的词汇。Anthropic发现，LLM实际做的事情经常与它声称自己在做的事情不同。通过监控J-Space中的词汇变化，研究人员获得了一种理解和控制模型行为的新方式。

这项发表在MIT Technology Review上的研究，与Token开销问题形成了深层呼应：我们不仅需要知道模型"想说什么"，还需要知道为了让它"想"，我们已经付出了多少token成本。J-Lens可能为未来的token优化提供新的方向——通过更精确地理解模型的推理路径，减少不必要的token消耗。

实践建议：如何降低你的Token账单

基于Systima的测试数据，以下是可以立即采取的优化措施：

第一，审计你的指令文件。一个72KB的AGENTS.md文件每个请求增加20,000 token。考虑精简到核心指令，或者使用分层加载策略——只在需要时注入相关部分。

第二，谨慎使用MCP服务器。每个服务器带来1,000-1,400 token的固定税。评估每个MCP服务器是否真正必要，以及是否可以合并功能减少服务器数量。

第三，减少子代理分发。子代理是最大的token乘数（4.2倍）。对于简单任务，直接在主会话中完成；只在确实需要并行处理时才使用子代理。

第四，关注缓存行为。使用如OpenCode这样具有稳定前缀的工具，可以大幅减少缓存写入。如果你在使用Claude Code，考虑定期清理会话以避免不必要的缓存重写。

第五，监控你的实际token使用。正如Systima建议的，设置一个本地代理来捕获每个请求的完整payload和API返回的使用数据。"如果你运行生产级的Agent系统，却无法回答'上周二我们到底给模型发送了什么'，这才是最需要填补的差距。"

结语：Token经济学的未来

Token膨胀问题揭示了AI编程工具生态中一个被严重低估的成本维度。随着AI Agent在软件开发中的角色日益重要，Token效率将成为衡量工具价值的关键指标之一。

Claude Code的高token消耗可能为其更强大的编排能力提供了支撑，但这需要通过严格的基准测试来验证——在哪些任务上，额外的token确实带来了质量提升？在哪些任务上，它只是浪费？Systima的测试框架已经证明，在相同质量结果下，token差异是纯粹的成本差异。

未来，我们可能会看到更多专注于token效率的工具和优化策略。Anthropic的J-Lens研究也在暗示，更深层的模型理解可能带来更高效的交互方式。在AI编程的下一阶段，"花更少的token做更多的事"可能成为核心竞争力。