夜雨聆风最近，一篇DeepSeek分享的分析在开发者圈子里引起了讨论。文章对比了OpenClaw和Claude Code的Token消耗，引发了很多人对AI编码代理"Token经济学"的思考。下面就是这篇分享的截图，我们先看看它到底说了什么：
💡 核心数据：DeepSeek的核心结论是： "OpenClaw在同一模型下的Token消耗，通常会远高于Claude Code"。 并给出了一组对比数据——每轮Token消耗、实际成本、缓存命中率等。 这个结论听起来很有道理，毕竟OpenClaw是个全功能的Agent平台，跑多个代理、做自动探索，"费Token"似乎理所应当。...
⚠️ 样本量有限：根据微软和斯坦福联合发表的论文（arXiv: 2604.22750），同一任务在不同LLM上的Token消耗差异可达30倍。单次对比很难得出普遍性结论。
2026年4月，微软研究院和斯坦福数字经济实验室联合发表了一篇里程碑式的论文（arXiv: 2604.22750），首次系统研究了AI Agent在编码任务中的Token消耗模式。这是目前最权威的数据来源。
🔎 发现一：Agent任务极其"烧Token" Agentic编码任务消耗的Token量，是单纯"代码推理"或"代码聊天"任务的1000倍。而且，驱动成本的主要是输入Token（System Prompt + 上下文 + 历史对话），而非输出Token。这和很多人的直觉相反——你以为贵在模型"思考"（输出），实际上贵在模型"阅读"（输入）。
🤔 🔎 发现二：Token消耗极不稳定 同一任务的不同运行，Token消耗波动可达30倍。而且——划重点——更高的Token消耗并不等于更高的准确率。准确率往往在中等到中等偏高的Token消耗区间达到峰值，之后"越多越不准"。
🔎 发现三：模型间Token效率差异巨大 在SWE-bench Verified基准上，Kimi K2和Claude Sonnet 4.5平均比GPT-5多消耗150万Token——这是真正的量级差异。
🔎 发现四：人类高估了自己的判断力 专家对任务难度的评估，与实际Token消耗之间的相关性很弱。说明"凭感觉判断哪个任务更费Token"是极其不可靠的。就连前沿LLM自己也无法准确预测自己的Token消耗（相关性最高仅0.39），且系统性地低估实际成本。
根据Digital Applied团队2026年4月发布的AI编码工具Token消耗排行榜（数据来自OpenRouter），市场份额一目了然：
*注：OpenClaw作为平台运行多个并发Agent，822B是平台级聚合数据，与其他工具的个体会话数据不可直接等同。
• OpenClaw — 822B Token/天（55%）
• Kilo Code — 302B Token/天（20%）
• Claude Code — 166B Token/天（11%）
• Cline — 97.2B Token/天（6%）
根据BSWEN的技术分析，OpenClaw的Token消耗模式可以分解为：
OpenClaw的Token消耗分布 • 问题分析与规划：~15% • 探索与文件搜索：~25% • 决策与回溯：~20% • 实际代码生成：~30% • 验证与迭代：~10%
对比之下，Claude Code更"直来直去"——你告诉它做什么，它就做什么。探索少、回溯少、Token消耗就少，但代价是自主性降低。
核心洞察：OpenClaw的额外Token消耗不是Bug，是Feature。它为自主探索和错误回溯支付了保险费。在简单任务上这确实是浪费，但在复杂遗留系统重构中，这恰恰是价值所在。
来看一个真实案例：迁移一个3年老项目的认证系统从JWT到OAuth2——
📋 举个例子：把老项目认证系统从JWT迁移到OAuth2。
用Claude Code：15,000 Token → API $45 + 人工2.5h $330 = $375
用OpenClaw：87,000 Token → API $261 + 人工0.5h $75 = $336
贵的是你的时间，不是API。
② 提示缓存
DeepSeek的核心结论是：
"OpenClaw在同一模型下的Token消耗，通常会远高于Claude Code"。
并给出了一组对比数据——每轮Token消耗、实际成本、缓存命中率等。
这个结论听起来很有道理，毕竟OpenClaw是个全功能的Agent平台，跑多个代理、做自动探索，"费Token"似乎理所应当。
② 提示缓存
✔ 提示缓存的对比非常有价值：Claude Code的缓存命中率高得惊人（92.7%），这是它"看起来Token多但实际成本低"的核心原因。
② 提示缓存
✔ 成本结构的分析切中要害：实际成本不等于Token数量乘以单价。缓存命中率、输出Token比例、重试开销等，都是重要因素。
② 提示缓存
⚠️ 对比维度可能错位：截图中的"平均每轮Token消耗"数据显示Claude Code为67,600 Token而OpenClaw为18,500 Token——从原始Token量来看，Claude Code其实更高。但结论却说OpenClaw更"费Token"，这背后有一个关键原因：统计口径的差异。OpenClaw的18,500是计费Token（去除缓存命中后的实际计费量），而Claude Code的67,600是原始Token（包含被缓存的输入）。换句话说，Claude Code的实际计费Token可能不到5,000。DeepSeek分析的核心洞察正在于此——缓存机制对成本的影响巨大，但对比时把"原始Token"和"计费Token"放在同一列，容易让人困惑。
③ 上下文工程
🔎 发现一：Agent任务极其"烧Token"
Agentic编码任务消耗的Token量，是单纯"代码推理"或"代码聊天"任务的1000倍。而且，驱动成本的主要是输入Token（System Prompt + 上下文 + 历史对话），而非输出Token。这和很多人的直觉相反——你以为贵在模型"思考"（输出），实际上贵在模型"阅读"（输入）。
① 模型路由
策略一：模型路由（Model Routing）
不是所有子任务都需要最强模型。UC Berkeley和Canva的研究表明，RouteLLM等路由系统可以在保持95% GPT-4性能的同时，实现85%的成本降低。实践中建议的流量分配：
• Tier 1（简单分类/格式化）→ 小模型 → 覆盖70%流量
• Tier 2（中等推理/补全）→ 中型模型 → 20%流量
• Tier 3（复杂推理/架构）→ 前沿模型 → 10%流量
② 提示缓存
策略二：提示缓存（Prompt Caching）
这是Claude Code"省Token"的秘密武器。System Prompt、工具定义、安全指令在绝大多数调用中保持不变。缓存命中时，读取成本仅为原始输入的10%。
• Anthropic：缓存读 $0.30/M（vs 正常$3.00/M），90%折扣
• OpenAI：默认启用，50%折扣
• 编码Agent通常可节省40-60%
③ 上下文工程
策略三：上下文工程（Context Engineering）
"塞得越多越好"是最昂贵的错误思路。建议：
• 为检索内容设定固定Token预算（如4,000 Token），强制优先级排序
• 使用分层检索（xMemory架构将Token从9,000降至4,700）
• 使用LLMLingua等提示压缩工具，可将上下文长度减少20-50%
• 有实践者通过组合RAG优化+提示压缩，将成本从$100+/会话降至$10以下
② 提示缓存
策略四：缓存感知的任务规划
Claude Code官方文档明确指出缓存管理的最佳实践：
• 在会话开始时确定模型和Effort Level——中间切换会清空全部缓存
• 避免在会话中途编辑CLAUDE.md——System Prompt变化会导致全部缓存失效
• 文件加载顺序很重要：稳定的架构文件优先加载，编辑频繁的文件后加载
• /compact命令要主动用，不要等到上下文快满了才被动使用
② 提示缓存
3️⃠ 计入缓存命中率
原始Token量毫无意义，实际计费Token才是关键。Claude Code 92.7%的缓存命中率意味着它的实际成本可能只有表面的10%。
策略二：提示缓存（Prompt Caching） 这是Claude Code"省Token"的秘密武器。System Prompt、工具定义、安全指令在绝大多数调用中保持不变。缓存命中时，读取成本仅为原始输入的10%。 • Anthropic：缓存读 $0.30/M（vs 正常$3.00/M），90%折扣 • OpenAI：默认启用，50%折扣 • 编码Agent通常可节省40-60%
DeepSeek的分析作为一个讨论起点是很有价值的——它让更多人意识到Token成本是个不可忽视的问题。但随着AI Agent从玩具走向工具、从辅助走向主力，我们需要的不是简单的"谁更省Token"的排名，而是更精细的成本效益分析框架。
省Token不是目的，解决问题才是。当你评估一个AI编码代理时，不妨问自己：它帮我省了多少时间？它解决的问题值多少钱？
省Token不是目的，解决问题才是。
