别让 AI 一趟只跑一次腿：Factory Droid 1.0 这笔 token 账是怎么省下来的
Factory 发布 Droid 1.0，Script 模式让模型写一段 JavaScript 一次调几百次工具；Linear 与 CI 两个例子、缓存率与 Terminal-Bench 4 成绩均为厂商自报或自测。
1
周末不卷，随便写点。
前两天看 Factory 发的 Droid 1.0 博文，有一个例子给我看笑了。
清理 Linear 上的 151 个 issue。
一共要调用 312 次工具。
按传统做法，据 Factory 的模型估算，大概要发 36 次模型请求，吃掉约 310 万输入 token。
换成他们新的 Script 模式，只发了 2 次请求，约 6.1 万 token。
活是一样的活。
账完全不是一个账。
先说明一下，这篇里的数字都来自 Factory 官方博文，是厂商自报。
本来我以为这又是那种「我们优化了底层架构」的公关话术。
结果仔细看了一圈，冒昧了。
这事儿还真不是玄学，是一笔特别朴素的跑腿账。
2
先讲清楚，传统 agent 是怎么干活的。
你让它办事，它调一个工具，拿到结果，回来跟模型汇报一次。
模型想一想，再让它调下一个工具，再汇报一次。
一次只跑一次腿。
问题在哪儿？
在于每次汇报，模型都得把前面的所有聊天记录、所有工具结果重新看一遍。
你想想看，这像什么？
像你让一个人去超市买东西，每次只告诉他买一样。
他买完回来，你再把整张清单从头念一遍，告诉他下一样。
买 312 样东西，你就得念 312 遍越来越长的清单。
腿是他跑的。
嗓子是你的。
而在大模型的世界里，嗓子就是 token，token 就是钱。
3
Script 模式干的事情，说白了就一句话：别念清单了，直接把清单写下来。
据 Factory 官方博文，Droid 1.0 对 GPT-6.1 Sol、Claude Opus 5.5 等一批模型默认开启 Script 模式。
模型不再一个一个地点工具，而是写一段 JavaScript。
这段程序在一个沙箱里跑，一次请求里可以调用几百次工具。
模型只看最后的结果。
那个 CI 的例子更夸张。
扫描 5,384 个 job，调用 550 次工具，模型最后只看到五个数字的摘要（厂商自报）。
五个数字。
中间那几千个 job 的日志，模型压根没碰。
这就像你雇了个跑腿，他一趟把东西全买齐了，回来只给你一张小票，上面写着总共几样、花了多少、缺了哪几样。
你需要知道的就这些。
剩下的，谁关心？
当然，让模型写程序去调工具，听起来就有点让人后背发凉。
万一它写着写着，顺手把你硬盘清了呢？
Factory 的说法是，这个沙箱没有文件、网络和系统权限。
程序只能调用 Droid 给它的工具，碰不到别的东西。
讲道理，风控的第一原则就是这个：能干活的东西，先把手脚绑好。
4
光是少念清单，还不够。
这篇博文我觉得真正值钱的，是后面那一串不起眼的工程细节。
第一个是缓存。
大模型的提示缓存有个特点，前面的内容只要一个字没变，就能复用，便宜很多。
但很多 agent 一加载新工具，就把工具定义插到前面去，整段缓存当场作废。
Factory 的做法是，新工具一律追加到请求末尾。
前面的东西一个字不动。
据官方说法，生产中典型请求有 98% 的输入走缓存。
这就是会过日子。
为什么这事儿重要？
因为缓存命中和不命中，价格差得不是一星半点。
很多团队的账单高，不是模型贵，是自己手欠，每次都把前面的东西挪一挪，等于每次都按原价买单。
钱就是这么一点一点漏出去的。
第二个是首包减肥。
以前一上来就把一大堆工具定义塞给模型，不管用不用得上。
现在预先发送的工具定义从 11 个降到 2 个，首包从 20,887 token 降到 13,055 token，官方自报是 -37%。
用不上的东西，先别背在身上。
第三个是刹车。
模型有时候会犯傻，同一个工具用同样的参数反复调。
Droid 的规则是，三次相同调用就提醒，六次就停。
这个设计我太熟悉了，就是风控里的频控。
你不设上限，迟早有一天被一个死循环把预算薅穿。
第四个是压缩摘要上限，从 8k 提到 16k。
长任务做到一半要压缩历史，摘要太短就容易丢关键信息，丢了就得重做，重做又是钱。
第五个最朴素：内存。
多开几个会话，以前每个会话是一个约 350MB 的进程，现在改成共享 daemon，每会话约 20MB。
退出时间的中位数从 648ms 降到 30ms，这些也都是官方自报。
这些单拎出来都不起眼。
但每一项都是在抠成本。
谁的钱都不是大风刮来的。
5
然后是大家最爱看的跑分。
Factory 拿 Terminal-Bench 4 做了一轮对比。
注意，这是厂商自测，时间是 10 月 23 日到 28 日，三次试验。
用 GPT-6.1 Sol 当模型时，Droid 比 Codex 高 3.5 分，成本低 12%，但耗时长 10%。
用 Opus 5.5 当模型时，比 Cursor、OpenCode、Devin、Claude Code 高 3.0 到 7.6 分，成本最多低 24%，每个通过的任务耗时少 16% 到 26%。
另外，官方称 Script 模式在 Opus 5.5 上比直接调用省 15% 成本。
这些数字怎么看？
我的建议是，先打个问号。
不是说人家造假，而是自家考场、自家监考、自家阅卷，这种成绩天然要打折看。
而且你注意，GPT-6.1 Sol 那一组，人家自己也写了耗时更长。
肯把不好看的那一行放出来，这点我是认的。
但跑分是跑分，你自己的任务是你自己的任务。
真想知道省不省钱，拿自己的活跑一遍，看账单。
账单不会骗人。
6
最后说说，这事儿跟普通人有什么关系？
这里还有一层有意思的利益链。
模型厂商按 token 收钱。
harness 厂商帮你省 token。
你说这俩是什么关系？
表面上是合作伙伴，底下其实是在抢同一块蛋糕。
你每省下一个 token，就是模型厂商少收一个 token 的钱。
那为什么 harness 厂商还要拼命帮你省？
因为它卖的不是 token，是「用我这个，比用别人的便宜」。
省钱就是它的产品。
用户越精，它越好卖。
这跟外卖平台补贴骑手、商家、消费者三头讨好不一样，它就讨好一头：掏钱的那个人。
讲道理，这种生意我是支持的。
谁帮我省钱，我就给谁鼓掌。
如果你只是用 agent，关系是：以后同样的活，可能花的钱更少，等的时间更短。
如果你在写 agent，关系就大了。
这篇博文基本就是一份可以抄的作业： - 能批量办的事，让模型写程序一次办完 - 新东西往后放，别动前面的缓存 - 用不上的工具定义，先别发 - 给重复调用设频控 - 进程能共享就共享
没有一条是黑科技。
全是省钱的笨办法。
而真正赚钱的，往往就是这些笨办法。
Droid 1.0 现在有 macOS 和 Windows 桌面版，有终端界面，还有 SDK @factory/droid-sdk。
站内之前写过 OpenCode 的 /goal 命令，讲的是怎么让 agent 自己跑得更久，这篇讲的是跑得久了怎么不烧钱，两篇可以对着看。
说到底，AI 这一行卷到现在，比的早就不只是谁的模型更聪明了。
还比谁更会过日子。
只能说，我爱这个精打细算的世界。
来源：Factory 官方博文《Building a Frontier Harness》。所有数字均为厂商自报；Linear 例子中传统做法的 36 次请求、约 310 万 token 为 Factory 的模型估算；Terminal-Bench 4 结果为厂商自测（10 月 23 日至 28 日，三次试验）；Script 模式对 GPT-6.1 Sol、Claude Opus 5.5 等一批模型默认开启；风控类比与成本判断为作者看法。