@_avichawla: 更聪明的 Claude 模型消耗的 tokens 更多，而不是更少！而且这不是 3-5% 的微小差异，而是高出 54% 的 token 使用量。…

更聪明的 Claude 模型消耗更多的 token，而不是更少！而且这绝不是微不足道的 3-5% 的差异，而是高达 54% 的 token 用量增长。这听起来似乎违反直觉，但 MCPMark V2 基准测试在 21 项后端任务中证实了这一点。原因与模型本身无关，而是取决于代理（agent）在开始构建之前需要掌握的信息。 当构建全栈应用时，Claude Code（CC）必须理解整个后端架构，例如： - 已存在哪些表 - 哪些行级安全（RLS）策略处于活动状态 - 有哪些存储桶可用 - 配置了哪些身份验证提供商 - 部署了哪些边缘函数 大多数后端并不会清晰地提供这些信息。例如，在使用 Supabase 时，通过 MCP 请求 OAuth 设置会返回完整的身份验证文档，包括电子邮件/密码、魔法链接、电话认证、SAML 和 SSO 等部分。这比代理实际需要的 token 数量多了 5 到 10 倍。而且，这种情况发生在每个领域中的每一次 MCP 调用中。 随后，代理通过单独的 `list_tables`、`execute_sql` 和 `list_extensions` 调用来发现系统状态，每次调用仅返回部分视图。某些信息，例如配置了哪些身份验证提供商，根本无法通过 MCP 查询。此外，当出现错误时，Supabase 无论是平台层拒绝还是函数代码报错，都会返回相同的错误代码。代理无法准确推断问题所在，因此会针对可能根本不在代码层面的问题，循环尝试代码级别的修复。 更优秀的模型并没有神奇的方法可以跳过这些信息缺口。相反，它会更加努力地填补这些空白，这意味着更多的探索性查询、更多的推理以及更多的重试。这就是为什么使用更强大的 Claude 模型时，token 成本反而上升的原因。 一种更智能的方法已在 InsForge 中实现。InsForge 是一个开源后端（可通过 Docker 自托管），提供与 Supabase 相同的基础设施原语，但其架构设计基于一个假设：操作后端的是代理而非在仪表盘上操作的人类。 在编写任何代码之前，单次 CLI 调用即可在约 500 个 token 内返回完整的后端拓扑结构。代理能在一个结构化的响应中看到所有表、身份验证提供商、存储桶以及可用的 AI 模型。与 Supabase 那种触发范围广泛的单一技能不同，InsForge 拥有四个范围狭窄的技能： - 创建表仅激活 CLI 技能。 - 调试技能仅在代码出错时激活。 - 构建前端仅激活 SDK 技能。 - 连接第三方身份验证仅激活集成技能。 由于代理仅加载与当前任务匹配的内容，其认知负荷得以保持精简。CLI 在每次操作中都返回带有语义退出码的结构化 JSON，因此代理始终清楚操作是成功还是失败，以及原因何在。这里没有含义模糊、可能代表三种不同情况的 401 错误。 我在相同的全栈 RAG 应用上测试了这两个后端，并记录了完整会话： **Supabase：** - 消耗 1040 万个 token - 需要 10 次人工干预 **InsForge：** - 消耗 370 万个 token - 整个过程无任何错误，成功完成构建 这并非 Supabase 特有的问题。大多数后端都是为能够查看仪表盘并解读原始错误的人类设计的。当由代理操作后端时，每一个缺失的上下文片段都需要一次探索性调用，而每一个模糊的错误都会进入重试循环。解决这一问题的方法是在代理开始编写代码之前，为其提供结构化的后端上下文。InsForge 正是这一理念的一个开源实现，你可以通过 Docker 自托管它。 GitHub 仓库（9k+ 星）：https://github.com/InsForge/InsForge… （别忘了点亮星号 ⭐） 你可以在下方的文章中查看我使用 Supabase 和 InsForge 构建全栈 RAG 的详细步骤。