多烧 2.5 倍的冤枉Token：Claude Code 的账单杀手，竟然藏在你的后端设计里

公众号名称：程叙架构与AI.

作者名称：AI兴观点

发布时间：2026-06-12 11:27

原文链接：https://x.com/_avichawla/status/2063548691353629040

✅点击上方🔺公众号🔺关注我✅

不是工具评测，是一个被忽视的发现：AI Agent 的成本，模型只占一半，另一半在后端的「语境设计」。

一个反直觉的事。

MCPMark V2 最近跑了一组对比测试。把 Claude Code 从 Sonnet 4.5 换到 Sonnet 4.6 ——更聪明的模型。你猜 token 消耗会怎样？

降了？没变？涨了。

同样的 21 个数据库任务，后端 token 消耗从 11.6M 涨到了 17.9M。

模型更聪明，后端烧钱更多。 这不是 bug，是信号。

反直觉的发现：模型越强，代价越大

原因跟模型能力无关。

当后端暴露给 Agent 的信息不完整时，更强的模型不会忽略这个缺口——它会更努力地推理、发起更多探索查询、更多次重试。

每多一次查询，上下文重新发送一次，token 就在翻倍。

这不是某个特定工具的问题。几乎所有传统后端——Firebase、Supabase、Postgres——都是为人类开发者设计的。人看仪表盘、读懂模糊错误、在脑子里拼凑状态。Agent 不会。 Agent 只能调用、等待、猜测、再调用。猜一次不对，整个对话重新发一遍。

这中间的 token 损耗，随着模型变强只会越来越大。

传统后端的三个隐形烧钱点

Avi Chawla 用 Firebase 跑了一个完整的 DocuRAG 应用构建实验。暴露了三个结构性问题。

第一个：工具接口膨胀

官方 Firebase MCP 服务器带了超过 50 个工具。你的项目可能只用 Firestore + Auth，但工具清单把 Crashlytics、Remote Config、App Hosting 全部装进来。Agent 在每次调用前都要加载这些无关的定义。

第二个：状态碎片化

Firebase 没有一个 “整个后端长什么样” 的单次查询接口。想理解后端状态，Agent 需要手动拼凑：

firebase projects:list
apps:list
apps:sdkconfig
firestore:databases:get
firestore:indexes

每个命令只返回一小块，Firestore 无 schema 又让问题更糟——Agent 得从样本文档里推导字段结构，而不是直接读 schema。

第三个：错误不暴露原因

Firestore 的错误返回永远是同一句话：PERMISSION_DENIED: Missing or insufficient permissions。

是安全规则配错了？集合路径拼错了？用户没认证？同一个字符串。 Agent 只能先猜一个原因，改代码，重跑，再看到同一个错误。每一次重试，整个对话上下文重新发送。

这三个问题叠加，产生了一个反直觉的放大效应：模型越聪明，每一步推理花费越高，差距越大。

什么才是「给 AI 设计的后端」

Karpathy 有个概念叫 context engineering——“用正确信息填充上下文窗口的精妙艺术”。大多数人把它用在 prompt 和 RAG 检索上。但后端也是上下文窗口的一部分，而且是目前最被忽视的一部分。

InsForge（开源，Apache 2.0）在 GitHub 上 67k+ star，走的就是这条路。

它的设计有三层，每层解决一个不同的 token 消耗问题：

Skills（技能）：静态知识。渐进式加载，metadata 先于全量内容。初始加载每份 skill 约 70-150 tokens，只有任务匹配时才展开全文。覆盖完整技术栈：前端 SDK 模式、CLI 基础设施命令、结构化错误诊断、第三方认证集成。
CLI（命令行）：直接操作层。每个命令支持 --json 结构化输出、-y 跳过确认、语义退出码——Agent 可以编程解析结果并根据退出码决定下一步。
MCP（实时状态）：通过 get_backend_metadata 一次性返回完整后端拓扑，约 500 tokens。不是把文档塞进 MCP，是只把实时变化的状态放进 MCP。

同一个 App，两套后端：真实账单对比

Avi 在 Firebase 和 InsForge 上分别用 Claude Code（Opus 4.8）构建了同一个 DocuRAG 应用——用户用 Google 登录、上传 PDF、切片嵌入、向量检索、GPT-4o 回答。

推理模型和嵌入模型保持一致，唯一变量是后端。

Firebase 端

Firebase 的初始构建很顺利。Agent 搭建了整个 Next.js 应用，写了安全规则和向量索引，生产构建一次性通过。

但问题从构建完成后才刚刚开始。

首先是认证没有无头路径。Agent 留下了 .env.local.example 模板，但真正的 .env.local 它填不了——那些值来自注册的 web 应用，而注册和读取配置只支持在登录终端操作。

其次是检索返回了错误的作者。用户问 “谁是这个论文的作者”，结果返回了参考文献里的引用姓名。不是切分问题——“作者” 这个词在向量空间里跟参考文献更近。

然后是聊天记录刷新就丢。历史记录放在 React state 里，刷新页面就没了。Agent 需要把每一轮迁移到 Firestore。

最严重的模式：Agent 在写完代码后才学到后端信息，于是反复打开已写好的文件修改。一个认证凭据的问题，Agent 先提交了看起来对的方案，跑一次测试和读一次 firebase-admin 源码才知道错了。

整个 session 期间，25 个已写好的文件被反复编辑，仅 API 路由就被重开了 10 次。

InsForge 端

InsForge 的构建过程完全不同。

Agent 的第一步是 npx @insforge/cli metadata --json，一次性返回了整个后端状态：已配置的认证提供商、已有的表结构、存储桶信息、可用的 AI 模型。

Agent 在写第一行代码之前，已经拿到了完整蓝图。

Schema 通过迁移文件完成。模型网关已经在 metadata 里暴露了 text-embedding-3-small 和 gpt-4o，Agent 通过同一套 SDK 调用，无需额外配置和密钥。

RAG 端到端测试一次性通过。

整个 session 中，只有 2 个文件被编辑——都是配置文件（insforge.toml、package.json），没有一个应用代码文件。

账单

	Firebase	InsForge
Token 消耗	15.7M	6.3M
费用	$12.95	$4.87
用户消息	4 条	1 条
错误报告	多次	0 次
已写文件的编辑次数	25 次	2 次（纯配置）
MCP 调用	2 次	0 次

结论：后端接口不是给人看的

这个比较揭示的问题不限于 Firebase。

几乎所有后端都是为人类开发者设计的——人看仪表盘、解读模糊错误、在脑内跟踪多个服务的状态。当 Agent 接手这个工作流时，这些假设全变成了 token 成本。

Agent 不能打开仪表盘。不能从模棱两可的日志里猜出错的根源。每次猜错，它都要重新发送整段对话。

这跟 “用更好的 prompt 能不能优化” 不是同一个问题。问题的根源是：你的后端把信息喂给了谁。

InsForge 走了相反的路——状态以结构化 metadata 一次性返回，CLI 提供程序化控制，技能编码了正确的模式。Agent 不需要探索，不需要猜测，自然不需要重跑。

所以它的费用只有 Firebase 的 37%，但更重要的数字不是钱——是整个 session 只发了 1 条人类指令，而 Firebase 需要 4 条。

你其实不用换后端。但下次让你的 Agent 去操作一个不熟悉的后端时，看看它做了什么——是在写代码，还是在拼图。

这个对比里最让我在意的不是 InsForge 比 Firebase 省多少钱，而是：越来越多基础设施正在被 Agent 直接消费，但它们的设计起点还是 “给人看” 的。 这层错位不修复，AI 越强，浪费越大。

写到这我想问一句：你平时用 Claude Code / Cursor 的时候，发现在哪个环节最烧 token？是配置认证、发现 API、还是调试错误？评论区聊聊。

如果觉得这篇文章有帮助，欢迎点赞、在看、转发！有问题也可以在评论区留言，我会尽量回复！

内容效果不满意？点此反馈