同题同模型便宜三成！Claude托管智能体开源平替一周暴涨4.7k Star

智猩猩AI整理

编辑：金水

8 月 26 日，阿里巴巴在 X 上发了一条消息：TrueFoundry 把自家的Qwen模型家族接入了 TrueForge。从十亿参数以下的轻量模型到 480B 的旗舰机型，所有型号都收进了同一个 API，背后撑着1M token的上下文窗口，agent 运营成本比托管在单一供应商平台上低约 50%。

那么这是什么呢？TrueFoundry推出的开源 Agent Harness TrueForge，就是冲着"agent 跑得贵"这个老问题去的。

一个工具返回 5 万 token 的 JSON，如果没人去剔除，后续每一步模型都反复读回；几十个工具的 schema，哪怕只用到两个，也从头到尾占满每条 prompt，账单就这样偷偷涨上去。

TrueForge 不碰模型，只重新设计模型周围那一圈代码：只把这次运行真正需要的东西放进上下文，其余的按需加载、写盘或隔离。

它还冲上了 Trendshift 趋势榜，在 TypeScript 分类里获得当日第 2、当周第 3，全语言综合榜则是当日第 15、当周第 14；GitHub 上更是拿到 4.7k Star。

在 DevRev 的 Enterprise-Bench 上，TrueForge 和 Claude 托管版跑了同样的 14 个任务、解出了同样多的题，却只用了对方约三分之一的 token，工具调用少四成；换成更便宜的 GLM-5.2，成本还能再降七成多。

01

四种让 Context 保持平整的策略

方法的核心思想并不复杂，在合适的时机把东西从模型面前移走。上下文不是消失，只是在它被需要的时候才被加载；

加载多少、什么时候加载，由 harness 控制。具体到 TrueForge，由四类策略协同完成这件事。

1、启动时把输入上下文压薄

TrueForge 在启动时把两类东西刻意压薄。

一类是技能（skills），它们是 git 化的SKILL.md包，agent 启动时只看到名字和描述，正文等用到时再从沙箱去读；

另一类是工具定义，默认走 deferred 加载（预设preload=false），agent 启动时拿到的只是 MCP server 的名字和描述，而不是一整套 schema。

好处很直接， 一个平台暴露了上百个工具，agent 只用两三个，剩下几十个的参数说明就不会白白占着窗口。等真要用某个工具，再去现查它的名字、参数、返回格式，查到就用。

真正用到工具时，通过四个调用按需取：

• list_tools列出某 MCP server 上所有可用的工具名。


• get_tool_info拿到单个工具的描述和输入输出 schema。


• get_tool_output_schema单独取输出形状，写 Code Mode 脚本前看一眼，避免去猜原始 JSON 的字段。


• call_tool按名字发起调用。

  


核心原则是只加载这次运行需要的，不要把所有系统支持的都加载进来。

一个暴露 100 个工具的内部 platform server，agent 只用 2 个，其余 98 个从头到尾都不会进 prompt。

2、运行时大响应落盘 + 子代理隔离上下文

假设你接到一个典型支持场景：当前哪些账号开 ticket 最多？都在聊什么？这件事需要查工单系统、把 ticket 关联到 CRM 的账号、再去读相关文档。

工具调用本身是可控的，数据回流才是失控的那部分。

工单系统一次可能返回 400 条 open ticket，每条带标题、描述、评论、标签、负责人、时间戳。agent 其实只需要账号 ID 和主题，剩下的字段会随着进入后续每一次模型调用。

TrueForge 用两招解决。

先把大响应落盘：工具返回太大就写进沙箱文件，context 里只留预览和路径，要细看才去读；好几份一起回来塞不下时，它把最大的那份先挪走。

剩下的交给子代理：12 个账号要分别查，就让根 agent 开 12 个子 agent 各查各的、只回摘要，于是根 agent 眼里只有 12 份摘要，原始记录在子代理那边就消化掉了。

3、Code Mode把工具链塌缩成一段脚本

"按账号统计 ticket 数"本质就是拼数据。

普通做法是把两组数据都拉到 context，模型做匹配、做统计，要来回跑好几轮模型。中间的 ID 一遍遍经过模型。

Code Mode 做法：写一段 Python，调用两次拿到原始数据，在代码里 join、count、print。

结果是 ID 留在脚本里，只有那张汇总表进 context。多步骤数据处理从模型循环里被搬走，留给模型的活少了。

4、Compaction阈值之上压缩历史

前面三招管的是"别让东西进对话"。还有种情况：对话本身变得太长了。

TrueForge 设了个上限（默认 5 万 token），一旦越过，TrueForge 对"意图、决策、文件与产物、错误与修复、下一步"做一份结构化摘要，把更早的消息替换掉。完整的事件历史继续留在服务器上，随时可回溯。

5、四种策略，如何配合

它们可以叠加在同一次运行里，从不同角度削减模型的工作量。起步关掉预加载，子任务丢给子代理，子代理里的大结果写文件，最后用 Code Mode 汇总，长对话再触发压缩。

说到底，harness 管的是两件事，即模型看什么、看几遍。两件事都压住，token 才真掉得下来。

03

如何使用

动手其实就一行命令。本地装好 Node 22.14 以上，跑：

npx @truefoundry/trueforge

它会起一个用 SQLite 存状态的本地服务，浏览器打开 localhost:8790 就能进聊天界面。

要接的东西在 Settings 里配一次，之后所有 agent 都能复用：模型供应商（OpenAI、Anthropic、Gemini 或任意兼容端点都行）、MCP server（支持 header 鉴权和 OAuth）、技能包（用到才加载）、沙箱（填个 Daytona key，沙箱按需拉起，密钥留在服务器端）。

本地模式下 macOS 和 Linux 自带沙盒，原生 Windows 才需要接 Daytona。

接好之后有三种用法：最省事用内置聊天界面；想写程序自动跑，就调它的 TypeScript SDK；想嵌进自己的产品，把界面组件直接嵌进去。

本地模式适合自己试玩，默认没登录、数据都在本地 SQLite 里，别暴露到公网。

要服务团队就切托管模式，背后挂 Postgres 和 Redis，用 Docker Compose 或 Helm 部署，支持多副本和登录，团队部署时建议打开 OIDC 登录。

04

性能实测：

同题同模型，便宜三成

TrueForge 在 DevRev 的 14 个企业任务上，用同样的模型、同样的工具、同一个盲评法官，跟 Claude 托管版和 deepagents 跑同一套题。

结果很清楚：同样用 Opus 4.8，TrueForge 和 Claude 托管版解出同样多的题，却只花对方约 30% 的钱，token 只有三分之一；换成开源的 GLM-5.2，成本还能再降 75%。

便宜的原因很朴素，agent 的钱大多花在反复把上下文发给模型的循环里，而 TrueForge 让这个循环更瘦，每轮指令更精简、工具调用更少（同结果下平均每任务 19 次，对手是 32 和 40 次），还用压缩和离载代替一遍遍重发历史。

05

这个工程为什么值得做

回到开头那个场景：两个 harness 跑同一个模型，答案差不离，一个却多花 2.7 倍 token。

差距就来自每次运行时摆在模型面前的东西，这些决定要么你主动做，要么默认继承，而默认继承的代价往往是账单变厚。

更深一层是利益冲突。托管平台既卖模型、又替你决定 token 怎么花，自然不会主动告诉你"换个便宜模型，这活儿只要几分之一的价"。

TrueForge 走厂商中立，模型、MCP、密钥你都自带，那层运行时归你，而企业想要的正是这个夹在用户和模型之间的控制点。

模型一直在变，新模型连 Claude Code 的规划步骤都内化掉了，但有件事模型接不了：它没法替 harness 拦下一个 5 万 token 的响应、不让它读十六遍。

runtime 仍决定每次看什么、调几次，这正是 harness 值得认真做工程的地方；而 TrueForge 把 benchmark 开源、用数字而不是口号来比，也是这条赛道在成熟的信号。

关注+星标，获取AI前沿进展与开源一线动态