内容来源：X 社区长文。https://x.com/_avichawla/status/2046500537584218438
作者：@_avichawla
原发布时间：2026-04-21

Claude Code backend context cost source cover

Claude Code 后端上下文成本：别让智能体反复猜

Claude Code 做前端页面时，很多成本花在读文件、改代码和跑构建上；但做全栈应用时，真正容易失控的地方往往在后端：认证、数据库、存储、向量检索、边缘函数、权限策略、日志和第三方模型调用。

原因不是模型突然变差，而是后端系统通常是为人类开发者设计的。人类可以打开控制台看项目状态，可以根据经验判断错误来自平台层还是业务代码层，也可以把多个页面里的线索拼起来。智能体看不到这些隐含状态，只能通过工具调用一点点探查。

如果后端没有把“当前状态、可执行操作、错误来源、下一步建议”结构化暴露给 Claude Code，智能体就会用 token 来补这个缺口：多查文档、多跑命令、多试几种修复、多次部署、多次读取日志。上下文越长，每一次错误重试都会变得更贵。

这篇社区文章的核心观点是：降低 Claude Code 成本，不只是换模型或压缩上下文，也要做后端上下文工程。

后端为什么会成为 token 消耗大户

一个智能体开发全栈功能时，后端工具通常要回答三类问题：

  • 这个项目现在是什么状态；
  • 我应该怎么修改它；
  • 修改失败时，错误到底发生在哪一层。

如果这三类信息暴露得不清楚，Claude Code 就会开始猜。

比如做一个带 Google OAuth、文件上传、向量检索和问答能力的应用，智能体需要知道：

  • 哪些认证 provider 已经配置；
  • 数据库有哪些表、扩展、RLS 策略和函数；
  • 存储桶是否存在，权限是什么；
  • 边缘函数是否部署成功；
  • 模型调用走哪个 API，密钥在哪里配置；
  • 报错是业务代码错、权限错、平台网关错，还是第三方服务错。

人类开发者可以通过控制台和经验快速判断，Claude Code 只能依赖工具返回的信息。如果工具每次只返回局部状态，或者错误信息不区分层级，智能体就会进入高成本探索模式。

Backend context source image

常见问题一：文档检索返回太多无关内容

很多 MCP server 会把文档检索做成“给一个关键词，返回一大段完整文档”。这对人类阅读也许还行，但对智能体并不经济。

Claude Code 可能只想知道“Next.js 里 OAuth callback 应该怎么接”，但工具返回了整个认证文档：邮箱密码、magic link、手机号、SAML、SSO、OAuth、服务端渲染、客户端库等内容全混在一起。

这会带来两个问题：

  • 重要信息被大量无关内容稀释；
  • 每次工具调用都把无关内容塞进上下文。

当任务横跨认证、数据库、存储和函数部署时，这类文档开销会反复出现。模型越认真推理，越会围绕这些材料做判断，token 成本也越高。

常见问题二：没有“一次性后端总览”

人类打开后端控制台，可以同时看到表、策略、函数、存储桶、认证配置和日志入口。智能体通常没有这个视图。

如果 MCP 只提供 list_tables、execute_sql、list_functions 这类碎片化工具，Claude Code 就要多次调用，再自己拼图。更麻烦的是，有些状态可能根本没有通过工具暴露，例如某些平台级认证开关、控制台配置或默认安全策略。

结果是：智能体以为自己已经理解了项目，其实漏掉了关键平台状态。后续一旦报错，它会优先修改代码，因为代码是它看得见的东西；但真实问题可能在代码执行前就被平台层拦截了。

Backend state source image

常见问题三：错误缺少结构化上下文

错误信息如果只告诉 Claude Code “401”“403”“500”或一段原始日志，智能体很难判断根因。

以 401 为例，它可能来自：

  • 浏览器没有带 token；
  • 服务端读取 session 的方式错了；
  • RLS 策略拒绝访问；
  • 边缘函数平台层先做了 token 校验；
  • 第三方 OAuth 配置不完整；
  • token 格式和当前 SDK 不匹配。

这些错误对人类来说可以继续打开控制台排查，但智能体如果拿不到结构化线索，就只能试。每试一次，就会产生新的代码修改、部署、日志读取和对话历史重发。

这也是 token 成本被放大的地方：不是一次错误很贵，而是错误循环很贵。

什么是后端上下文工程

上下文工程通常被理解成提示词、RAG、记忆和上下文压缩。但对 Claude Code 这类编码智能体来说，后端本身也是上下文的一部分。

后端上下文工程要解决的是：把智能体下一步真正需要的信息，以更小、更准、更可执行的形式暴露出来。

一个更适合智能体的后端工具层，通常需要三类能力：

  • 静态知识：SDK 用法、平台规则、常见坑；
  • 可执行操作：创建表、运行迁移、部署函数、管理配置；
  • 动态状态：当前项目拓扑、配置、资源、日志和错误来源。

原文用 InsForge 作为例子说明这种架构：用 Skills 承载静态知识，用 CLI 执行后端操作，用 MCP 查看实时状态。这里不把它作为唯一推荐方案，而是把它当作一种设计模式来看。

Backend context engineering source image

第一层：用 Skills 放静态知识

静态知识不适合每次通过 MCP 查询。SDK 用法、代码示例、常见坑、认证模式、部署注意事项，变化频率不高，更适合做成 Skills。

Skills 的好处是可以渐进披露：会话开始时只加载 Skill 的名称和描述，Claude 判断任务相关时再读取完整内容。这样既能让 Claude 发现能力，又不会一开始把所有文档塞满上下文。

后端类 Skills 可以按领域拆开，例如：

  • 前端如何调用后端 SDK；
  • CLI 怎么管理资源；
  • 常见错误怎么排查；
  • 第三方认证 provider 怎么配置。

拆得越清楚，Claude 越容易只加载当前任务需要的那一小块。

第二层：用 CLI 做确定性执行

对创建表、启用扩展、部署函数、设置密钥这类操作，CLI 往往比 MCP 更适合智能体执行。

原因是 CLI 可以做到：

  • 输出 JSON；
  • 返回明确 exit code；
  • 支持非交互确认参数；
  • 可以和 jq、grep、awk、测试脚本组合；
  • 便于记录完整命令和结果。

这会让 Claude Code 更容易判断“这一步到底成功没有”。如果每个动作都有结构化输出，智能体就不需要通过多轮自然语言解释来猜测状态。

第三层：用 MCP 查看动态状态

MCP 仍然很有价值，但更适合处理“当前状态是什么”，而不是承载大量静态文档。

理想的 MCP 工具应该能一次返回项目拓扑，例如：

  • 认证 provider；
  • 数据表和关键字段；
  • RLS 策略；
  • 存储桶；
  • 函数列表；
  • 可用模型；
  • 最近错误；
  • 面向智能体的 hints。

这类状态会随着开发过程变化，适合通过工具实时读取。文档和模式则更适合放在 Skills 里。

原文实验怎么看

原文做了一个对比实验：用 Claude Code 分别基于两个后端方案构建同一个 DocuRAG 应用，功能包括 Google OAuth、PDF 上传、文本切分、向量入库、问答检索和权限隔离。

原作者给出的结果是：

  • 一组会话消耗约 10.4M tokens，期间多次人工报告错误；
  • 另一组会话消耗约 3.7M tokens，人工介入更少；
  • 差异主要来自认证和边缘函数排障过程中的重试循环。

这些数字有参考价值，但不能直接当作普遍结论。因为单次实验会受任务实现、平台配置、提示词、模型版本、网络环境、账号权限等因素影响。

更稳妥的结论是：当智能体缺少后端状态和错误来源时，调试循环会显著放大 token 成本。

对团队更有用的落地检查表

如果你正在让 Claude Code 参与全栈开发，可以先检查自己的后端工具层：

  • 有没有一个命令或工具能返回项目总览；
  • 返回结果是否是结构化 JSON；
  • 错误是否区分平台层、权限层、业务代码层和第三方服务层；
  • 常见 SDK 用法和坑点是否已经做成 Skills；
  • 高风险操作是否需要人工确认；
  • 部署、迁移、回滚是否有确定性命令；
  • Claude 能不能自己运行验证，而不是只说“应该可以”；
  • 每次失败是否会把日志和状态写入可复盘文件。

如果这些问题的答案大多是否定的，Claude Code 就会用更多 token 来弥补缺失的信息。

小结

Claude Code 的成本优化，不应该只盯着模型价格、上下文压缩和提示词长度。对全栈任务来说，后端上下文是否结构化，往往决定了智能体是“一次理解后执行”，还是“边猜边试边重试”。

一个适合智能体的后端工作流，应该尽量做到：

  • 静态知识放进 Skills；
  • 确定性操作交给 CLI；
  • 动态状态通过 MCP 暴露；
  • 错误返回结构化原因；
  • 高风险动作有确认和护栏；
  • 验证结果可机器读取。

这不是为了某一个后端产品，而是为了减少智能体在不确定性里消耗 token。模型越强，越应该给它更清晰的工具和状态，而不是让它把能力浪费在猜测后端到底发生了什么。