@_avichawla: 我仅凭一项改动就将Fable 5的token用量降低了2.5倍！ - 之前：5.5 M tokens · 7 errors · $8.94 - 之后：2.3 M tokens · …

我仅凭一项改动就将Fable 5的token用量降低了2.5倍！ - Before: 5.5 M tokens · 7 errors · $8.94 - After: 2.3 M tokens · 0 errors · $4.17 两次构建的最终结果相同，但智能体所走的路径却截然不同。 在两次运行中，智能体都从相同的事情开始，即它在构建任何东西之前先了解后端，例如： - 权限策略 - 可用的存储桶 - 已配置的身份认证提供商 - 边缘函数如何部署 第一次运行使用了Firebase，它是为使用仪表盘的人类开发者构建的。 虽然开发者可以通过点击选项卡来读取上述状态，但智能体没有仪表盘。因此它通过API调用来收集相同的信息。 而且没有单个Firebase调用能返回这些信息。智能体需要多次查询，每次查询都会返回过多数据。 例如，当智能体询问登录配置时，Firebase还会返回整个认证表面及其支持的所有方法。 这远超出了它所需的上下文。并且这种情况在它检查的每个后端部分都重复出现。 某些状态（例如哪些身份认证提供商处于活动状态）根本无法查询。我自己提供了这些信息。否则智能体就会猜测。 错误进一步加剧了token用量。 当开发者看到“权限被拒绝”时，他们可以查看控制台，判断是规则、路径还是未经身份验证的请求。 Firebase也向智能体返回了相同的字符串，而它没有任何周围的上下文来进行调试。 于是它再次猜测，选择了最可能的原因，并重写了代码，消耗了更多token。 这种Firebase设置让我在构建一个全栈RAG应用时消耗了550万token，并在错误时进行了7次手动干预。 但通过使用InsForge作为后端上下文工程层（开源且可通过Docker自托管），我将token用量降低到230万，手动干预降为0。 它提供了与Supabase/Firebase相同的原语，但为智能体而非仪表盘构建了整个信息层。 在一次消耗约500 token的CLI调用中，智能体在编写一行代码之前就看到了完整的后端拓扑。 这包括身份认证、数据库、存储、边缘函数、模型网关、微虚拟机以及部署。 此外，不是每次任务都将整个产品表面加载到上下文中，而是仅在相关时激活四个范围狭窄的技能，以保持最低的认知负荷。 为了确保在需要时高效重试，每次CLI操作都返回带有有意义的退出码的结构化JSON，这样智能体永远不会猜测下一步该做什么。 这是InsForge的GitHub仓库：http://github.com/InsForge/InsForge… （别忘了给它加星😄） 下面的视频展示了最终构建，比较了Firebase和InsForge。 为了更深入了解，我最近发布了一个完整的演练，在两个后端上构建相同的RAG应用，并进行了端到端检查。 请在下面阅读。