如何将 Claude Code 成本降低 2.5 倍（利用 Karpathy 的上下文工程原则）

一份完整的开源工具解析，展示如何在不修改 CLAUDE(.)md、提示词或模型的情况下，将 Claude Code 会话成本降低 2.5 倍（附设置指南及有效原因说明）。

MCPMark V2 揭示了一个反直觉的现象。

将 Claude 从 Sonnet 4.5 升级到更智能的 Sonnet 4.6 后，通过 Supabase 的 MCP 服务器处理相同 21 个数据库任务时，后端 token 用量从 1160 万增加到 1790 万。

模型更智能了，但后端 token 用量反而上升。

原因很微妙，并且与模型本身无关。

问题在于后端向代理暴露信息的方式。当上下文不完整时，更强的模型并不会跳过信息缺口。

相反，它会更努力地推理，运行更多的探索查询，并更频繁地重试。因此，随着模型改进，缺失上下文的成本只会增加，而非减少。

让我们看看为什么传统后端会让代理更费力，后端上下文工程应该是什么样子，以及在一个真实项目中的成本差异。

为什么 Firebase 会让代理更费力

Firebase 是一个可靠的后端。

但它并非设计为由编码代理操作，其三个假设在代理接管工作流时会转化为 token 成本。

1) 工具表面及其文档膨胀了上下文

通常让编码代理访问 Firebase 的方式是官方 Firebase MCP 服务器（内置于 firebase-tools 中）。它提供了超过 50 个工具，并自动激活你项目所需的工具。

连接它会在任何工作开始前将该工具清单加载到代理的上下文中，并且服务器还会暴露文档资源，这些资源会自动拉入会话。

清单随着 Firebase 的产品表面增长，而不是随你实际构建的内容而变化，因此即使是一个只涉及一两个服务的小型应用，也会携带 Crashlytics、Remote Config、App Hosting 等定义。

2) 缺乏后端状态的单一视图

Firebase 没有“显示整个后端”的调用。

相反，状态分散在多个独立命令中，例如：

• firebase projects:list
• apps:list
• apps:sdkconfig
• firestore:databases:get
• firestore:indexes 等。

Firestore 因为无模式而让情况更糟。

没有可读的已声明结构，因此代理从样本文档推断集合的字段和类型，而不是查询模式。

它从多个部分调用中拼凑信息，这种碎片化的发现模式会不断累积，因为每个调用只返回一个片段，并且部分结果还需要更多命令来解释。

3) 错误返回时没有结构化上下文

Firestore 返回通用错误。

例如，“PERMISSION_DENIED: Missing or insufficient permissions” 这个相同字符串，无论是配置错误的安全规则、集合路径中的拼写错误，还是在用户身份验证之前发出的请求，都返回同样的信息，并且从未指明是哪个规则失败。

同样的差距也出现在凭据和配置错误中，消息报告的是症状，而非后端实际想要什么。

代理无法从文本中定位原因，因此它形成一个假设，尝试修复，重新运行，然后再次得到相同字符串。每次重试都会重新发送不断增长的对话，这正是 token 成本累积之处。

这三个瓶颈——庞大的工具表面、碎片化的状态发现以及不透明的错误重试——会迅速叠加。

一个更彻底推理的模型会使每个探索步骤更昂贵，随着模型的改进，差距会越来越大。

“后端上下文工程”应该是什么样子

解决方案不是换用一个更差的模型。

而是给代理提供一个结构化的后端上下文，使其无需探索和猜测。

这正是 Karpathy 所说的上下文工程：“将上下文窗口填充上下一步所需准确信息的微妙艺术和科学。”

他明确将工具和状态作为该上下文的一部分。自然的直觉是将这个想法应用于提示词和 RAG 检索。

但后端也是上下文窗口的一部分，而目前，它在代理编码中是最被忽视的部分。

要看到这在实践中是什么样子，InsForge（开源，Apache 2.0）正是实现了这种方法。

GitHub 仓库 → https://github.com/InsForge/InsForge

关键架构差异在于它如何向 Claude Code 传递上下文。

三个层次协同工作，每个层解决不同的问题以减少 token：

• Skills：用于静态知识。
• CLI：用于直接后端操作。
• MCP：用于实时状态检查。

1) Skills：零往返的静态知识

InsForge 处理知识的主要方法是 Skills。它们在会话启动时直接加载到代理上下文中，并采用渐进式披露方式。

因此，只有元数据先加载（每条 Skill 约 70 到 150 token），只有当任务匹配时才加载完整内容。

四个 Skills 覆盖了完整的技术栈，每个限定于特定领域：

• insforge：用于与后端通信的前端代码。
• insforge-cli：用于后端基础设施管理。
• insforge-debug：用于结构化错误诊断，涵盖常见故障（如认证错误、慢查询、边缘函数失败、RLS 拒绝、部署问题和性能下降）。
• insforge-integrations：用于第三方认证提供商（Clerk、Auth0、WorkOS、Kinde、Stytch）。

一条命令即可安装全部四个：

claude mcp add insforge-skills

2) CLI：用于直接执行

这提供了执行层。

每条命令都支持 --json 以输出结构化结果，-y 以跳过确认提示，并返回语义退出码，以便代理可以编程方式检测认证失败、项目缺失或权限错误。

以下是代理实际运行的一些示例操作：

# 创建数据库
insforge db create my-database --json

# 列出 Bucket
insforge storage list --json

# 创建 Bucket
insforge storage create my-bucket --json

# 部署边缘函数
insforge edge deploy functions/hello --json

# 获取环境变量
insforge env list --json

代理解析 JSON 并根据退出码处理错误。

3) MCP 工具：用于实时后端状态

MCP 通过一个 get_backend_metadata 工具保持对实时状态检查的实用性，该工具在大约 500 token 内返回完整的拓扑结构，并包含一个 hints 字段用于代理特定指导。

设计选择是将 MCP 用于变化的状态，而不是用于不变的文档。

模型网关位于这一切的中心。

它是一个兼容 OpenAI 的端点，可跨提供商（OpenAI、Anthropic、Gemini、Grok）路由请求，因此 text-embedding-3-small 和 gpt-4o 可以通过同一 SDK 访问，无需单独密钥和外部连线。

Firebase 与 InsForge：使用 Claude Code 构建 DocuRAG

为了具体说明，我在两个后端上用 Claude Code（Opus 4.8）构建了相同的 DocuRAG 应用，保持嵌入模型和生成模型不变，因此后端是唯一的变量。

用户通过 Google 登录，上传 PDF，文本被分块并嵌入（text-embedding-3-small，1536 维），向量被存储和检索，GPT-4o 在检索到的块上回答问题，并具有每用户隔离。

这几乎同时触及了所有后端原语：用户认证、文件存储、文档表、向量嵌入、嵌入生成、聊天补全、检索边缘函数，以及隔离每个用户文档的 RLS。

以下是每个后端的设置：

1) Firebase

Firebase 在 Claude Code 开始之前需要真正的预配置，大部分工作需在控制台中手动完成：

• 在 console(.)firebase(.)google(.)com 创建项目并注册一个 Web 应用以获取客户端 SDK 配置。
• 启用 Firestore（标准版，nam5 区域）和 Cloud Storage，并在认证下添加 Google 登录提供商。

然后安装代理技能，添加 MCP 服务器，并认证 CLI：

# 加载 Firebase Firestore 知识
claude mcp add firebase-firestore
# 加载 Firebase Auth 基础知识
claude mcp add firebase-auth-basics
# 添加 Firebase MCP 服务器
claude mcp add firebase
# 认证 Firebase CLI
firebase login
# 列出项目
firebase projects:list

添加 MCP 服务器会将其完整工具清单加载到会话中，这是第一个机制的作用。

此外，还需要单独提供 OpenAI API 密钥，因为 Firebase AI Logic 只提供 Gemini 和 Imagen，而不提供 gpt-4o 或 text-embedding-3-small。

2) InsForge

• 创建一个 InsForge 账户并创建一个新项目（你也可以使用 Docker Compose 在本地完全自托管运行 InsForge）。
• 安装四个代理技能，然后登录并将 CLI 链接到项目：

# 加载 InsForge 技能
claude mcp add insforge-skills
# 认证 CLI
npx insforge auth login
# 获取项目元数据（显示所有现有配置）
npx insforge metadata --json

这会安装 insforge（SDK 模式）、insforge-cli（基础设施命令）、insforge-debug（故障诊断）和 insforge-integrations（第三方认证提供商），在会话启动时占用大约 714 token 的元数据。

这些技能范围狭窄，因此只有相关的会被激活。

无需添加 MCP 服务器，也无需点击控制台。认证、存储、向量存储和模型网关都可通过 CLI 由代理从单个提示词中提供，无需单独的 OpenAI 密钥。

两次运行的提示词几乎相同，只有一个差异。

• Firebase：

使用 Firebase 构建一个 DocuRAG Web 应用。用户通过 Google OAuth 登录，上传 PDF，然后对文档内容提问。使用 OpenAI API（GPT-4o 用于生成，text-embedding-3-small 用于嵌入）。所有内容必须隔离到每个用户。

• InsForge：

使用 InsForge 构建一个 DocuRAG Web 应用。用户通过 Google OAuth 登录，上传 PDF，然后对文档内容提问。也用于模型网关。所有内容必须隔离到每个用户。

功能上的一个差异是模型连线。

• Firebase 通过“OpenAI API 的 LLMs/嵌入模型”路由生成和嵌入，需要连接两个系统，因为 Firebase 没有提供 GPT-4o 的网关。
• InsForge 说“也用于模型网关”，只有一个系统。

我并行运行了两个会话并记录了完整构建过程。以下是并排视频，展示了从提示词到工作应用的过程。

它还展示了基于两个不同后端的最终输出。

在深入了解会话特定细节之前，以下是最终构建后的数据：

• Firebase： 1570 万 token，$12.95，4 条用户消息
• InsForge： 630 万 token，$4.87，1 条用户消息，0 个错误报告。

现在让我们看看每个会话实际发生了什么。

为了客观分析，我将两次运行的完整 Claude Code 会话历史导出（为 JSONL 文件）并输入到一个单独的 Claude 实例中。下面的分析，包括工具调用次数、错误序列和 token 分解，均来自对这些会话日志的解析。

Firebase（消耗 1570 万 token，花费 $12.95）

初始代码构建进行得很顺利。

• 代理加载了 firebase-firestore 和 firebase-auth-basics 技能。
• 然后通过 Firebase MCP 服务器（firebase_get_environment、firebase_list_projects）和 CLI 发现了后端状态。
• 它找到了一个在仪表板中设置的现有 docurag 项目。

它搭建了完整的 Next.js 应用，编写了 Firestore 安全规则和一个 1536 维的向量索引，编写了 API 路由和浅色模式 UI，生产构建在经过几次自我修正后通过了测试，包括它自己捕获的分块代码中的一个空格去除错误。

问题 1) 认证没有无头路径

构建后我遇到的第一个问题是缺少配置文件。

会话留下了一个 .env.local.example 模板，但没有真正的 .env.local，因此应用程序没有 Firebase 配置来启动。代理无法自行填写。

这些值来自一个注册的 Web 应用，注册并读取其配置文件只能在已登录的 CLI 中进行。

问题 2) 检索返回了错误的作者

我的第一个真实查询暴露了一个 RAG 错误。我询问上传论文的作者，应用程序返回了论文中引用的错误名字，而不是实际作者。

明显的怀疑对象是分块，但数据说明并非如此。

对于“作者是谁？”这个问题，最近的五个块全部来自参考文献和致谢部分，其中充满了被引用的名字，因为一个作者列表在嵌入空间中比“作者”这个词更接近参考文献。

第 0 块从未进入前五名，因此 GPT-4o 读取了参考文献块并报告了那些名字。

修复方法是提高 top-k 并始终按文档顺序将开头几个块重新纳入。

问题 3) 聊天历史在刷新后丢失

然后我注意到页面刷新后之前的提问消失了。

聊天历史只存在于 React 状态中，因此重新加载会清空它。

代理将每轮对话移入 Firestore（在 users/{uid}/documents/{docId}/messages 下），添加了一个读取它的端点，并在打开文档时加载它。

它通过写入几轮对话、按顺序读取并清理来检查往返。

问题 4) 重复的文件编辑

整个会话期间有一个奇怪的模式保持不变。

Firebase 一次只透露一点点状态和失败信息，通过 CLI 探测、简短的错误消息甚至其自身的 SDK 源代码，因此代理只有在写完代码后才了解到某些信息。

凭据问题是我运行中最清晰的例子。

代理提交了一个看起来正确的设置，只有通过测试运行和读取 firebase-admin 内部代码才显示它是错误的。

这类模式显著增加了 token 使用量。

每次新信息在代码写完后才到达时，代理都会重新打开文件并将增长中的对话重新发送给模型。

抛开通用的 RAG 修复不谈，大部分重编辑工作是因为代理需要重写代码以匹配后端在事后才揭示的信息。

会话期间，总共有 25 个文件在被写入后又被编辑过：

并非所有 Firebase 的问题都源于后端。

通用 RAG 调整和一些构建修复也在列表中。但最重的一批是结构性的：仅 API 路由就被重新打开了十次，因为凭据连线、持久化改造以及每轮修复最终都落在了同一个处理程序上。

最终会话统计：

• 141 次工具调用（51 次 bash 命令，46 次写入，25 次编辑）
• 2 次 MCP 工具调用
• 1570 万 token
• $12.95

InsForge（消耗 630 万 token，花费 $4.87）

InsForge 会话从单个构建提示词就达到了相同的工作应用，没有错误报告。

它的第一个操作是 npx @insforge/cli metadata --json，该命令在一个结构化响应中返回了配置的认证提供商、现有表、存储桶和可用模型。

代理在编写任何代码之前就掌握了完整图景。

Schema 通过迁移进行，创建了 documents、document_chunks 和 chat_messages 表，全部启用行级安全，因此每个用户只能看到自己的数据。

在这次运行中，云层级没有提供 pgvector，因此代理将嵌入存储为 double precision[] 列，并在一个 SQL 函数（match_document_chunks）中运行精确余弦相似度，SDK 传递和返回纯数数组。

一个带有路径范围 RLS 的私有 documents 存储桶处理文件存储。

认证是通过 SSR 流程的 Google OAuth，重定向 URL 由 CLI 列入白名单。

关于模型网关，元数据响应已经列出了 text-embedding-3-small 和 gpt-4o，因此代理通过 InsForge SDK 调用两者，无需单独的密钥和跨服务集成。

端到端 RAG 测试首次运行即通过。

之前在 Firebase 上出问题的两件事在这里从未出现。chat_messages 表作为标准 schema 的一部分被提供，因此聊天历史在刷新后默认保持。

此外，因为网关是后端的一部分，嵌入和补全调用不需要单独的凭据或集成。

而且，这是整个 InsForge 运行中唯一的文件编辑。

这两个文件都是配置文件（insforge.toml、package.json），没有触及应用程序代码。

每个路由、库和组件都只写一次，从未重新打开。

这就解释了为什么运行成本保持低廉。

代理的第一个操作是一个 metadata --json 调用，一次性返回了整个后端状态，因此它是在一个完整图景下编写的，而不是逐步发现。

一旦它提交了一个文件，其背后的假设就保持有效，之后没有新信息使其失效。没有后期信息意味着没有重新打开，没有重新打开意味着对话永远不会被重新发送来重写已编写的代码。

最终会话统计：

• 1 条用户消息（构建提示词，无后续）
• 102 次工具调用（28 次 bash 命令，29 次写入，3 次编辑）
• 0 次 MCP 工具调用
• 630 万 token
• $4.87

会话总结对比

我让 Claude 生成了一个并排对比。