我们如何将 Claude Code 的令牌使用量降低了 2.8 倍！

99% 的人以为“模型升级=更省钱”，结果我们在 MCPMark V2 基准里撞上了反例：模型更聪明，账单却更高。Claude 从 Sonnet 4.5 升到 4.6 后，通过 Supabase MCP 服务器跑 21 个数据库任务，后端令牌从 1160 万涨到 1790 万。模型推理更强，但在不完整的上下文里，它会更努力地“脑补”，而不是更克制地“省着用”。

MCPMark V2 的数据把这个现象暴露得很直接：

  • Sonnet 4.5：约 1160 万后端令牌
  • Sonnet 4.6：约 1790 万后端令牌
  • 同一批 21 个数据库任务，只换了模型版本

原因并不在模型本身，而在后端怎么把信息喂给代理。当上下文有大块空白时，更强的模型不会礼貌地略过，而是：

  • 花更多令牌推理缺失部分
  • 发起更多探索性查询
  • 在错误上反复重试

缺失的上下文不会因为模型升级而消失，只会变成更贵的“推理黑洞”。接下来我们拆开看：后端是怎么悄悄变成令牌黑洞的，替代架构长什么样，以及在真实项目里，成本到底能差到什么程度。

为什么 Supabase 的 MCP 服务器会“吃掉”那么多令牌

文档检索：一次性倾倒整本“说明书”

Supabase 本身是个很好的后端平台，但它最初是给人类开发者设计的，后来才加上 MCP 服务器。这层 MCP 在 AI 代理视角下，有三个明显的“令牌放大器”，第一个就是文档检索。

当 Claude Code 想通过 Supabase 配置 Google OAuth 时，会调用 search_docs MCP 工具。Supabase 的实现会在每次调用时返回完整的 GraphQL 模式元数据，令牌量往往是代理真正需要内容的 5–10 倍。

文档检索示意图

如果代理只想要“如何配置 OAuth 登录”，返回的却是整套认证文档：邮箱/密码、魔法链接、短信、SAML、SSO 全都塞进上下文。数据库查询、存储配置、边缘函数部署等场景也一样，每次 search_docs 都是一次“整卷倾倒”。

在一个完整会话里，代理要配置认证、数据库、存储和函数，这种“全量文档灌输”本身就能浪费掉成千上万令牌。说白了，代理每问一次，就被迫读一遍“产品白皮书”。

状态碎片化：代理看不到“总览仪表盘”

人类开发者用 Supabase 时，会先打开仪表盘：

  • 哪些认证提供商是开的
  • 当前有哪些表、RLS 策略
  • 存储桶和边缘函数配置如何

代理却完全看不到这块 UI。它只能通过零散的 MCP 工具，比如 list_tables、execute_sql 等，去一点点摸索当前后端状态，却没有一个“告诉我整个后端长什么样”的统一入口。

状态碎片化示意图

结果就是：

  • 代理需要多次调用，才能拼出一个不完整的“后端地图”
  • 有些关键信息（比如启用了哪些 OAuth 提供商）根本无法通过 MCP 拿到
  • 每次调用都要消耗令牌，还经常因为格式或内容不全再发起后续查询

这种碎片化的状态发现过程，本质上是在用令牌做“盲人摸象”。模型越聪明，摸得越细，花得也越多。

错误上下文：只有原始报错，没有结构化线索

错误一定会发生，尤其是代理在“猜测式”操作后端时。Supabase 在出错时会返回原始错误信息，比如：

  • RLS 拒绝导致的 403
  • 配置错误的边缘函数返回 500

人类开发者会：看错误 → 打开仪表盘 → 查日志 → 对照配置 → 修掉问题。代理没有这条路径，它只能拿到一串错误文本，然后自己推理原因，再尝试修复。

如果修复失败，它会重试；每次重试，都会把整个对话历史重新发给模型，令牌成本一层层叠加。有用户反馈，在复杂项目里，单是“修一个 401 错误”就能触发十几轮重试，账单直接翻倍。

据我们导出的 Claude Code 会话日志统计，在一次 Supabase 会话中，单个边缘函数错误就触发了 8 轮修复尝试和 8 次重新部署，每一轮都重新发送更长的对话历史。

这三种机制——文档开销、状态发现、错误重试循环——叠加在一起，就构成了一个“令牌放大器”。当你换上 Sonnet 4.6 这种推理更深入的模型时，每一步探索都更彻底，也更昂贵，这就是为什么模型升级后令牌差距被进一步拉大。

后端上下文工程：不换模型，换“喂法”

把后端也当成“上下文窗口”的一部分

想降成本，直觉是“换个便宜点的模型”。我们试过，效果有限。真正有效的是换一个视角：把后端本身当成上下文工程的一部分。

Karpathy 提过“上下文工程”的概念：在有限的上下文窗口里，用恰到好处的信息填充，让模型既有足够信息，又不过载。他提到的上下文不只包括提示和 RAG 检索，还包括工具和状态。

大多数团队只在提示词和文档检索上做文章，却忽略了后端这块巨大的上下文源。结果就是：模型在“半盲状态”下工作，用大量令牌去猜本可以直接告诉它的东西。

为了验证另一种做法，我们用开源项目 InsForge 做了一个对照实验。InsForge 提供的原语和 Supabase 类似：

  • Postgres + pgvector
  • 认证、存储、边缘函数、实时

InsForge 架构示意图

不同点在于：InsForge 在这些原语之上加了一层“结构化信息层”，专门为代理消费而设计。核心问题变成：

  • 如何在不爆上下文的前提下，把静态知识喂给模型？
  • 如何用最少的往返，让代理掌握实时后端状态？
  • 如何在错误发生时，给出对代理友好的结构化线索？

三层协同：Skills、CLI、MCP 各管一摊

InsForge 的上下文工程架构可以粗略拆成三层：

  • Skills：承载静态知识，零往返加载
  • CLI：负责直接操作后端，提供结构化输出
  • MCP：只做实时状态检查，而不是文档检索

每一层都在不同维度上减少令牌浪费，合在一起，才出现了 2.8 倍的整体降幅。

Skills：静态知识的“零往返缓存”

渐进式披露：先给目录，再按需展开

在 InsForge 里，大部分知识通过 Skills 提供。它们在会话开始时就被加载进代理上下文：SDK 用法、代码示例、边缘案例等，代理不需要任何工具调用就能直接引用。

四个技能示意图

关键是它用了“渐进式披露”：

  • 会话开始时，只加载每个技能的元数据（名称、描述），每个大约 70–150 令牌
  • 只有当代理判断“这个技能和当前任务相关”时，才请求完整内容
  • 这样可以安装 100+ 个技能，而不会一上来就把上下文挤爆

四个核心技能覆盖了完整栈：

  • insforge：前端如何和后端交互
  • insforge-cli：后端基础设施管理
  • insforge-debug：常见失败场景的结构化诊断（认证错误、慢查询、边缘函数失败、RLS 拒绝、部署问题、性能下降）
  • insforge-integrations：第三方认证（Clerk、Auth0、WorkOS、Kinde、Stytch）

安装也很简单：

npx skills add insforge/insforge-skills

据我们在实际项目中的观察，这种“先目录后正文”的方式，比 MCP 那种“要么全给要么不给”的文档检索，平均能减少 3–5 倍的文档相关令牌消耗。

真实体验：少走弯路的感觉很明显

我在一次内部测试里，用 Claude Code + InsForge 重建了一个已有的多租户 SaaS 后端。之前用传统 MCP + 文档检索的方案，Claude 经常会：

  • 选错客户端库
  • 忽略某些边缘配置（比如多租户隔离策略）
  • 在错误上绕圈子

换成 Skills 之后，代理一开始就拿到了“正确姿势”的模式示例，很多坑直接绕开。说实话，第一次看它一遍过跑通登录、RLS 和向量检索时，我也不太确定是运气好还是架构真的起作用，后来多跑了几轮，结果都比较稳定。

CLI：用结构化命令替代“工具连环调用”

一条命令，带回完整状态和清晰信号

真正动手改后端时（建表、跑 SQL、部署函数、管理密钥），InsForge CLI 是主力接口。每个命令都支持：

  • --json：结构化输出，方便代理解析
  • -y：跳过交互确认
  • 语义化退出码：能区分认证失败、项目不存在、权限不足等

这对 Claude Code 很友好，因为它可以直接用 jq、grep、awk 等 Unix 工具处理 CLI 输出。如果用 MCP 工具来做同样的事，往往需要多次顺序调用才能拼出同样的信息。

一些真实会话里常见的命令：

# 发现后端当前状态
npx @insforge/cli metadata --json

# 数据库操作
npx @insforge/cli db query "CREATE TABLE posts (...)" --json
npx @insforge/cli db policies

# 边缘函数
npx @insforge/cli functions deploy my-handler
npx @insforge/cli functions invoke my-handler --data '{"action":"test"}' --json

# 存储
npx @insforge/cli storage create-bucket documents --json
npx @insforge/cli storage upload ./file.pdf --bucket documents

# 前端部署
npx @insforge/cli deployments env set VITE_INSFORGE_URL https://...
npx @insforge/cli deployments deploy ./dist --json

# 诊断
npx @insforge/cli diagnose db --check connections,locks,slow-queries

代理只需要解析 JSON 和退出码，就能判断下一步怎么走，而不必在模糊错误文本上反复试探。

有用户反馈，用 CLI + JSON 输出后，原本需要 20 多次 MCP 工具调用才能搞清楚的数据库状态，现在一条 metadata 命令就能拿到，而且错误排查时间缩短了一半以上。

风险提示：CLI 也不是银弹

当然，CLI 也有自己的坑。比如：

  • 如果命令设计得过于宽泛，代理可能一条命令就做了太多危险操作
  • JSON 输出字段不稳定时，代理的解析逻辑会频繁失效

所以在设计给代理用的 CLI 时，最好：

  • 保持命令粒度适中，可组合但不至于“一键毁库”
  • 固定 JSON schema，版本升级时显式标注

这部分工作量不小，但一旦打磨好，后续每个项目都能复用。

MCP：只做实时状态，不再当“文档服务器”

单次调用拿到完整拓扑

在 InsForge 架构里，MCP 仍然存在，但角色被大幅收窄：

  • 不再负责文档检索（那是 Skills 的事）
  • 只负责实时状态检查（状态会变）

InsForge 的 MCP 服务器暴露了一个轻量工具 get_backend_metadata，一次调用返回完整后端拓扑的结构化 JSON：

{
  "auth": {
    "providers": ["google", "github"],
    "jwt_secret": "configured"
  },
  "tables": [
    {"name": "users", "columns": ["id", "email", "created_at"], "rls": "enabled"},
    {"name": "posts", "columns": ["id", "title", "body", "author_id"], "rls": "enabled"}
  ],
  "storage": { "buckets": ["avatars", "documents"] },
  "ai": { "models": [{"id": "gpt-4o", "capabilities": ["chat", "vision"]}] },
  "hints": ["Use RPC for batch operations", "Storage accepts files up to 50MB"]
}

一次调用，大约 500 令牌，代理就知道：

  • 哪些认证提供商是开的
  • 有哪些表、列、RLS 状态
  • 存储桶和 AI 模型配置
  • 一些专门给代理的“提示”（hints 字段），比如批量操作建议、文件大小限制

关键设计是：

  • MCP 只用于“会变的东西”（状态）
  • “不会变的东西”（文档、模式示例）放进 Skills

这和典型 MCP 用法刚好反过来，也是 InsForge 在同样任务下令牌消耗远低于 Supabase 的主要原因之一。

实战对比：用 Claude Code 搭建 DocuRAG

同一个应用，两套后端，两种提示

为了把差异讲清楚，我们用 Claude Code 分别在 Supabase 和 InsForge 上搭建同一个 DocuRAG 应用：

  • 用户用 Google OAuth 登录
  • 上传 PDF，文本分块并用 text-embedding-3-small（1536 维）嵌入
  • 向量存进 pgvector
  • 用户用自然语言提问，由 GPT-4o 基于检索结果回答

这个应用几乎踩遍所有后端原语：

  • 认证
  • 文件存储
  • 文档表
  • 向量嵌入与检索
  • 边缘函数
  • 每用户隔离的 RLS

Supabase 侧的提示：

Build a chat with document app called DocuRAG.
It will be a typical RAG setup where a user
can upload a document. It will be chunked, embedded,
and stored in a vector DB. Once done, a user can ask
questions about the document. The engine will retrieve
the relevant chunks after embedding the query. Finally,
it will generate a coherent response using GPT-4o based
on the query and the retrieved context. Add Google OAuth.
Use Supabase as the backend and LLMs/embedding models via
the OpenAI API. Build frontend in next.js.

InsForge 侧的提示：

Build a chat with document app called DocuRAG.
It will be a typical RAG setup where a user
can upload a document. It will be chunked,
embedded, and stored in a vector DB. Once done,
A user can ask questions about the document.
The engine will retrieve the relevant chunks
after embedding the query. Finally, it will
generate a coherent response using GPT-4o based on
the query and the retrieved context. Add Google OAuth.
Use Insforge as the backend and also for the model
gateway. Build the front-end in Next.js.

唯一关键差别：

  • Supabase：通过 OpenAI API 使用 LLM 和嵌入模型（需要连接两个系统）
  • InsForge：同时作为后端和模型网关（一个系统搞定）

我们把两次完整构建过程都录了视频，并对比了最终应用效果。

视频演示

重要提示：Supabase 需要在 Claude Code 之外手动配置 Google OAuth。我们得去 Google Cloud Console 创建 OAuth 2.0 客户端 ID、配置同意屏幕、添加测试用户邮箱、复制客户端 ID 和密钥，再粘到 Supabase 仪表盘。InsForge 这一步是内置的，不需要额外操作。

成本对比：1040 万 vs 370 万 令牌

先看结果：

令牌和成本对比图

  • Supabase：约 1040 万令牌，12 条用户消息（其中 10 条是错误报告），成本 9.21 美元
  • InsForge：约 370 万令牌，1 条用户消息（0 条错误报告），成本 2.81 美元

我们导出了两次运行的完整 Claude Code 会话历史（JSONL），再用另一个 Claude 实例解析，统计了工具调用次数、错误序列和令牌细分。下面是拆解。

Supabase 会话：令牌被错误重试“吃掉了”

初始构建：看起来一切顺利

一开始，Supabase 会话进展很顺畅：

  • 代理加载 supabase 技能
  • 通过 MCP 工具（list_tables、list_extensions、execute_sql）发现后端状态
  • 搭建 Next.js 项目
  • 创建数据库模式
  • 编写两个边缘函数：ingest-document 和 query-document
  • 完成部署，构建通过

构建流程截图

问题出在真正跑起来之后。

第一个坑：登录失败，客户端/服务端库混用

尝试用 Google OAuth 登录时，应用直接报错。代理选错了 Supabase 的 Next.js 客户端库。

登录错误截图

Next.js 的 OAuth 回调在服务器端运行，但代理用了浏览器端的客户端库，登录状态只存在于浏览器，服务器端拿不到，导致整个登录流程失败。

代理通过：

  • 切换到 @supabase/ssr
  • 重写登录会话处理
  • 重新构建

才把这个问题修掉。

修复登录截图

文档上传：8 轮错误循环，问题其实在“代码上游”

登录搞定后，开始上传文档。边缘函数报错，用户把错误贴给 Claude，Claude尝试修复，失败，再修，再失败……一共循环了 8 轮：

错误循环截图

中间尝试过的方案包括：

  • 手动添加认证头 → 同样错误
  • 重新部署并加日志 → 同样错误
  • 显示真实错误而不是通用错误 → 变成网络/CORS 问题
  • 修 CORS → 回到原始错误
  • 换另一种方式读取登录令牌 → 还是不行
  • 再换一种认证方法 → 依旧失败

根因其实很简单：Supabase 在边缘函数代码运行前有一层平台级安全检查。代理安装的新认证库发出的令牌格式，平台层认不出来，于是请求在函数代码执行前就被拒绝了。

安全层示意图

代理看到的只是一个又一个 401/403 错误，却完全不知道拒绝发生在“代码上游”。它只能在函数代码里不断尝试修复，结果当然是徒劳。

真正的解决方案是：

  • 关闭平台自动令牌检查
  • 在函数代码内部自己处理认证

但日志没有明确区分“平台级拒绝”和“代码级拒绝”，代理也拿不到这层结构化信息，于是只能在错误循环里烧令牌。

最终统计：

  • 12 条用户消息（10 条是错误报告）
  • 135 次工具调用
  • 30+ 次 MCP 工具调用
  • 约 1040 万令牌
  • 成本 9.21 美元

InsForge 会话：一次性看清状态，零错误跑通

先看清环境，再动手改东西

InsForge 会话的节奏完全不同。一开始，代理就用 CLI 做了一次“全局体检”：

npx @insforge/cli metadata --json

后端状态概览

这条命令返回了：

  • 已配置的认证提供商
  • 现有表和列
  • 存储桶
  • 可用 AI 模型
  • 实时频道等

代理在写任何代码之前，就对环境有了完整、结构化的认知。对比之下，Supabase 会话需要多次 MCP 调用（list_tables、list_extensions、execute_sql）才能拼出类似信息，而且还缺少像 verify_jwt 这种关键行为的描述。

模式和函数：6 条命令搞定，0 次重试

模式设置通过 6 条 CLI 命令完成，全都一次成功：

CLI 命令执行

  • 启用 pgvector
  • 创建 documents 和 chunks 表（含 vector(1536) 列）
  • 为两张表启用 RLS
  • 创建访问策略
  • 设置 match_chunks 相似度搜索函数

每条命令都返回结构化 JSON，代理可以在继续下一步前确认“这一步真的成功了”。

认证和边缘函数的问题在这里完全没出现：

  • insforge 技能里已经包含了正确的 Next.js 客户端库模式
  • 代理第一次就选对了用法
  • 两个边缘函数（embed-chunks 和 query-rag）部署后直接可用

无错误部署

代理也不需要单独集成 OpenAI、管理第二个 API 密钥或处理跨服务认证。metadata 响应里已经列出了 text-embedding-3-small 和 gpt-4o 作为可用模型，代理直接通过 InsForge SDK 调用即可。

最终统计：

  • 1 条用户消息
  • 77 次工具调用
  • 0 次 MCP 工具调用
  • 约 370 万令牌
  • 成本 2.81 美元

我们让 Claude 自己对两次会话做了并排总结，结果也印证了这一点：

总结对比图

Supabase 会话的令牌主要烧在错误重试和边缘函数的反复部署上，而 InsForge 会话则把更多令牌花在“第一次就做对”的构建上。

认知增量：后端不是“被动资源”，而是主动的上下文接口

这次对比其实揭示了一个更大的问题：

  • 绝大多数后端是为人类开发者设计的
  • 假设开发者能看仪表盘、读模糊错误、在脑子里整合多服务状态

当 AI 代理接管工作流时，这些假设全部失效：

  • 代理看不到仪表盘
  • 日志不说明错误来源
  • 状态分散在多个服务和接口里

状态碎片化示意图

InsForge 选择了另一套假设：

  • 后端通过结构化元数据暴露状态，CLI 给代理可编程控制，成功/失败信号清晰
  • Skills 编码了“正确模式”，代理不需要用试错来摸索
  • 模型网关和后端在同一系统里，避免跨服务集成的大量调试

在当前 AI 工程热潮下，这其实是一个挺重要的信息差：

真正决定令牌成本的，不只是模型单价，而是你有没有把后端当成“上下文接口”来设计。

InsForge 完全开源，Apache 2.0 许可，可以用 Docker 自托管。代码、Skills 和 CLI 都在 GitHub：

如果你正在用 Claude Code 或其他代理型 IDE 做严肃项目，这套“后端上下文工程”的思路，值得先收藏起来，等下一个项目直接照着改造后端接口，效果会比单纯换模型更明显。

常见问题

Q：我现在已经在用 Supabase + Claude Code，有必要为了省令牌直接迁到 InsForge 吗？

A：不一定要立刻迁移，先评估你当前项目的令牌结构更稳妥。可以先导出几次典型会话的日志，看令牌主要花在：构建、文档检索还是错误重试。如果错误重试和状态发现占比很高，那说明你的后端对代理并不友好，这时有两条路：要么在 Supabase 上自己加一层“结构化状态接口”和更细的错误信号，要么在新项目上尝试 InsForge 这种为代理优化过的后端。短期内可以先从小项目或内部工具开始试，避免一次性大迁移带来的风险。

Q：如果我不想引入新的后端平台，怎么在现有后端上做“上下文工程”？

A：可以从三个小步骤开始：第一，梳理出代理最常用的静态知识（SDK 用法、模式示例、常见错误），做成类似 Skills 的结构化文档，按需加载而不是每次全量检索。第二，为后端加一个“状态总览”接口，一次返回认证、表结构、RLS、存储等关键信息，避免代理用多次调用拼状态。第三，改造错误返回格式，在 JSON 里显式标注错误来源（平台级/代码级）、可疑配置项和推荐下一步操作。这样做不需要换平台，却能显著减少令牌浪费和调试时间。

Q：怎么判断一个后端是否适合被 AI 代理操作，有没有简单的检查标准？

A：可以用“三个信号”快速判断：1）有没有统一的结构化元数据接口，让代理一条命令就看到当前拓扑；2）错误信息是否区分平台级和业务级，并提供机器可读的错误码和上下文；3）是否支持脚本化/CLI 操作，并能输出稳定的 JSON 结果。如果这三点都满足，代理通常能高效工作；如果缺一两项，令牌成本和调试时间就会明显上升。建议你在选型或自建后端时，把这三条当成“代理友好度”检查清单来用。

Q：令牌成本已经很高了，除了优化后端，还有哪些降本手段是值得优先做的？

A：可以按优先级这样排：先优化上下文结构，再考虑模型和参数。具体来说，第一步是减少无效上下文，比如重复的系统提示、全量文档、长日志，把它们拆成可按需加载的块。第二步是优化工具调用策略，避免在状态不变的情况下反复查询，必要时在客户端做缓存。第三步才是调整模型组合，比如用便宜模型做检索和预处理，把昂贵模型只用在关键决策和生成上。很多团队一上来就换小模型，结果体验变差、调试成本上升，反而得不偿失。

Q：未来模型上下文越来越大，是不是就不用这么折腾上下文工程了？

A：上下文变大会缓解一部分问题，但不会自动解决“信息结构”和“错误信号”这两件事。即便有百万级上下文，如果你把一堆无结构的文档、日志和错误堆进去，模型还是得花大量推理去“找重点”，令牌照样烧得快。更现实的风险是：上下文越大，单次调用越贵，一旦错误重试循环出现，成本会比现在更吓人。所以，越往大上下文时代走，“把什么放进上下文、怎么放”这件事反而更关键。上下文工程不是权宜之计，更像是未来几年 AI 工程的基础能力之一。

如果你已经在用代理写后端，这套“后端上下文工程”的做法会在一次次真实构建里帮你省下时间和钱；如果你还在观望，不妨先把这篇留着，等哪天账单开始刺眼的时候，再回来对照着改后端接口，往往比问十个朋友都更有用。