Sam Altman提的开源适配层，一个月就做出来了

Sam Altman在7月就开源Agent框架的价值做了阐述。一个月后，有人把它做出来了，而且它比大多数托管框架效率更高。

它瞄准解决的问题是这样的：你的Agent令牌账单里，很大一部分消耗都来自模型重复读取它已经读过的内容。这不是模型本身的问题。模型周边的运行时才会决定每次prompt里放什么内容，以及多久调用一次模型。

举个例子，一个Agent在第四步查询CRM，返回了400行数据。这些行数据会被全部堆进对话历史里。到第十九步时，模型不得不重复读取这些行十五次，完全没有必要，而每读取一个令牌都会按输入费率计费。

问题之所以会发生，是因为你的框架在每一轮都组装prompt，还把这些行数据一直保留在里面。

由此你有两个可调整的方向：框架往前带多少上下文，以及它多久调用一次模型。有四种实用方法可以避免prompt不必要地膨胀：
→ 按需加载工具schema。拥有100个工具的服务器，不需要把100个工具全放进每一个prompt里——Agent本来就只会调用其中两个。
→ 把大结果卸载到磁盘。把大响应转换成简短预览加文件路径，不用每一轮都把完整结果重放一遍。
→ 委托给子Agent。让子Agent在自己的上下文里完成三十次工具调用，再给根Agent返回一份摘要。
→ 在代码里运行工具链。用一个脚本调用三个工具，合并结果返回一张表，不用分三轮，每轮都带完整响应。

但减少上下文只是完成了一半工作。你还需要控制调用模型的频率。一个好框架应该在工作可以用更少步骤完成时，避免不必要的规划、验证和反思。

@TrueFoundry 的开源Agent框架TrueForge，就是围绕这两项控制能力构建的。它位于模型和工具之间，负责决定每个prompt里放什么内容，以及什么时候才真的需要再调用一次模型。它还能按框架、技能、指令、工具和消息分类拆解令牌使用情况。

DevRev的Enterprise-Bench是测试这项能力的地方，测试场景是多步骤任务——就是那种Agent从一个系统拉取记录，再和另一个系统对账的任务。TrueFoundry在这个测试里让TrueForge对阵Claude Managed Agents，双方用同一个模型，最终完成的任务数量相同。

打平这件事才是关键，因为它说明性能并没有因为token减少而打折扣。TrueForge只用了不到三分之一的令牌就拿到了相同分数，调用模型的次数也少了大约40%。相同结果下，它的成本比Claude Managed Agents低大约2.7倍。

换成开源模型后效果更明显。搭配GLM-5.2的TrueForge得分比上述两种配置都略高，而整个基准测试运行按标价算总成本大约只有3美元。

在这里，开源的意义不止于许可证本身。你不需要重写Agent就能替换底层模型，如果数据不能出环境，整个项目还可以运行在你自己的环境里。

这一切归根结底都取决于模型周边的运行时：它携带的上下文、它暴露的工具，以及它回源调用模型的次数。这才是生产级框架真正要负责的事。

完整任务列表、每次运行的数据，还有MIT许可的代码都放在GitHub：（别忘了点亮Star 🌟）
你可以在下方引用的文章里读到更多相关内容。
感谢TrueForge团队和我一起完成这项工作。