@akshay_pachaar：Sam Altman 在七月为开源工具框架辩护。一个月后，有人推出了它，并且更高效……

Sam Altman 在七月为开源工具框架进行了论证。 一个月后，有人推出了它，并且比大多数托管工具框架更高效。 以下是它旨在解决的问题： 你的代理令牌费用中有很大一部分是模型重复阅读它已经读过的内容。 这不是模型的错。其周围的运行时决定了每个提示中包含什么以及模型被调用的频率。 例如，一个代理在第四步查询 CRM 并获取 400 行数据。这些行被堆积在对话历史中。 到第十九步时，模型不得不不必要地阅读这些行十五次，而每次读取的令牌都按输入费率计费。 这是因为你的工具框架在每个回合组装提示并保留了这些行。 这给你提供了两个杠杆：工具框架向前传递多少上下文，以及它调用模型的频率。 有四种实用方法来避免提示不必要地增长： → 按需加载工具架构。一个拥有 100 个工具的服务器不需要在代理只调用两个工具时将所有 100 个放入每个提示。 → 将大结果卸载到磁盘。将大响应转换为简短预览和文件路径，而不是在每个回合重放整个结果。 → 委托给子代理。让一个子代理在其自身上下文中使用三十次工具调用，并返回一个摘要给根代理。 → 在代码中运行工具链。一个脚本调用三个工具，连接结果并返回一个表，而不是三个回合各拖拽一个完整响应。 但减少上下文只是一半的工作。你还需要控制模型被调用的频率。 一个良好的工具框架应该在工作能以更少步骤完成时避免不必要的规划、验证和反思。 TrueFoundry 的开源代理工具框架 TrueForge 围绕这两个控制构建。 它位于模型和工具之间，决定每个提示中包含什么以及何时真正需要另一次模型调用。它还将令牌使用分解到工具框架、技能、指令、工具和消息中。 DevRev 的 Enterprise-Bench 是对此进行测试的地方，针对多步骤任务，其中代理从一个系统拉取记录并与另一个系统进行协调。 TrueFoundry 在那里运行 TrueForge 对比 Claude Managed Agents，两者使用相同模型，并且都完成了相同数量的任务。 平局是重要的部分，因为它意味着底层的差距不是质量权衡。 TrueForge 在接近三分之一的令牌数下达到该分数，并且返回模型的次数大约减少了 40%。对于相同的结果，这比 Claude Managed Agents 便宜约 2.7 倍。 换用开源模型使其更加犀利。TrueForge 搭配 GLM-5.2 的得分略高于以上任一设置，并且整个基准测试运行在列表价格下花费约 3 美元。 开源的重要性超越了许可证。底层模型可以无需重写代理即可替换，并且当数据不能离开时，整个内容可以在自己的环境中运行。 所有这些归结于模型周围的运行时、它传递的上下文、它暴露的工具以及它返回模型的次数。 这就是生产工具框架实际拥有的内容。 完整的任务列表、每次运行的数据以及 MIT 许可代码在 GitHub 上：http://github.com/truefoundry/trueforge… （别忘了加星） 你可以在下面引用的文章中阅读更多相关内容。 感谢 TrueForge 团队与我合作完成此项目。