清理 151 个工单、执行 312 次工具调用，传统 AI 编码助手要和模型来回拉扯 36 轮，烧掉约 310 万个 Token；而 2026 年 10 月发布的 Factory Droid 1.0 只向模型发了 2 次请求、消耗约 61,000 个 Token 就干完了同样的活。参数竞赛卷到头之后，真正决定 Agent 账单厚度的，已经换成了模型外面的调度壳子。
Factory 把这层壳子叫做 Harness，涵盖提示词、工具定义、结果回传方式和执行循环。Droid 1.0 支持 macOS 与 Windows 桌面端、终端 UI 以及 Apache 2.0 协议的 Node SDK（@factory/droid-sdk），起步价每月 20 美元。它不绑定单一模型，支持自带 API 密钥或用 Factory Router 混合调度，直接把战火烧向了 Anthropic 的 Claude Code、OpenAI 的 Codex CLI，以及 Cursor、Devin 和开源的 OpenCode。
把工具调用折叠进一段 JS 脚本
传统 Agent 循环有个致命的增肥机制。每次调用工具，原始文件、搜索结果和报错日志都会全量塞回模型上下文，步数一多，Token 消耗爆炸，模型的注意力也被海量废话稀释。
Droid 1.0 的核心动作，是将基于 2024 年学术界 CodeAct 思路的 编程式工具调用（PTC）设为默认，落地为一个 Script 工具。模型不再一步一请示，而是直接写一段 JavaScript 代码扔进沙盒并发执行，单次请求就能驱动上百次工具调用。原始文件和日志留在程序内部消化，最后只有打印出来的关键结果会传回给模型。
官方实测数据很直观。修复单元测试时，15 次工具调用所需的模型请求从 10 次降到 5 次，耗时从 56.8 秒缩至 41.6 秒；排查横跨 547 次运行、共 5,384 个任务的 CI 流水线时，2 次请求就跑完，进入模型上下文的工具结果 不到 0.1%。在 Claude Opus 5.5、GPT-6.1 Sol 和 Kimi K3 等 10 个默认开启该模式的模型上，仅 Opus 5.5 的单任务成本就比直接调工具降了 15%。
除了改写调用逻辑，Factory 还在内部搞了一条 Agent Factory 流水线，让 Agent 自动读取失败日志并提修改方案，经工程师审核后合并。这套内循环帮 Droid 1.0 把基础提示词从 20,887 个输入 Token 砍掉 37% 至 13,055 个（发生在 0.170.0 到 0.250.0 版本之间，因跨模型分词器口径差异，实际字符数缩减为 35%）；初始加载工具定义从 11 个减到 2 个，定义体积降了 46%，冷门工具改成按需加载并追加在请求末尾，让生产环境的 缓存命中率达到 98%。
为防死循环，连续 3 次相同调用会触发提醒，6 次直接熔断，压缩摘要容量从 8,000 Token 翻倍至 16,000 Token；桌面端首屏渲染也从 1,839 毫秒压到 488 毫秒，新增会话内存从 350 MB 降到 20 MB。
跑分第一背后的统计滤镜与减速反常
把上下文收拾干净后，Factory 拿出了 2026 年 10 月 23 日至 28 日跑出的 Terminal-Bench 4 成绩单。在同模型对决中，Droid 1.0 搭配 Claude Opus 5.5 拿到 65.2% 的通过率（单任务成本 4.73 美元），搭配 GPT-6.1 Sol 拿到 57.6%（单任务成本 0.79 美元），账面通过率压过了 Cursor、Codex、Claude Code、Devin 和 OpenCode。
| 编码框架 | Claude Opus 5.5 通过率 | GPT-6.1 Sol 通过率 | 同模型耗时对比（以 Droid 为基准） |
|---|---|---|---|
| Factory Droid 1.0 | 65.2% ($4.73/任务) | 57.6% ($0.79/任务) | 基准线 |
| OpenCode | 62.1% | 51.0% | Droid 快 4% 至 24% |
| Cursor / Devin | 62.1% / 59.6% | 未披露 / 45.0% | 成本最高比 Droid 贵 24% |
| Claude Code / Codex CLI | 57.6% / 未测试 | 未测试 / 54.0% | Opus 上快 26% / Sol 上慢 10% |
但翻开 Factory Research 于 10 月 29 日发布的《Droid 1.0: Building a Frontier Harness》技术报告底稿，我对这份成绩单里的“降本提速”幅度不太买账。
最核心的水分在于 幸存者偏差。报告在对比 codex@0.163.0 与 claude-code@2.1.306 等竞品时，规定每个任务跑 3 轮，但单任务成本与耗时 只统计双方在 3 次尝试中全部通过的交集任务。真实生产环境里最烧钱的恰恰是反复报错、推倒重来的失败任务，把沉没成本一刀切掉，算出来的省钱比例显然过于乐观。
评测过程还掺杂了不少人工打补丁的操作。遇到基础设施故障就重跑；Claude Opus 5.5 触发安全审核拦截后，测试被直接 降级替换成 Opus 5 重跑；Devin 因为向用户提问而中止的部分任务，干脆被直接赋了 Codex 的通过结果；而 Cursor 在两次测试中缺失的 Token 数据，更是靠估算补上的。
跑分筛掉了失败的账单，却筛不掉生产环境里的真实试错。
哪怕顺着官方数字看，也能抓到一个关键反常。在 GPT-6.1 Sol 模型上，Droid 虽然比原生 Codex 通过率高 3.5 个百分点、成本低 12%，但通过任务的耗时反而 比 Codex 慢了 10%。这戳破了编程式调用的万能神话。让模型先构思并写出一段带控制流的 JS 代码再跑，本身就会增加生成开销；遇到部分模型或简单任务，先写脚本再调工具反而画蛇添足。
- 结论.Harness 层的按需加载与尾部缓存追加确实能省下真金白银，这是 Claude Code 与 Codex 等原厂工具接下来必须补课的工程细节；但评估引入第三方框架的 ROI 时，必须把失败重试和脚本生成延迟算进总账。
沙盒无权限，不等于宿主机安全
相比跑分滤镜，我更在意的是 Script 模式在安全边界上撕开的口子。
Factory 官方强调，运行 JS 脚本的沙盒本身没有文件、网络或系统访问权限。这话字面上没错，但经不起推敲。模型写这段 JS 脚本的唯一目的，就是在沙盒里批量驱动外部的 Droid 宿主工具。
韩非子讲“人主之患在于信人，信人则制于人”。放在企业研发与安全团队（SecOps）的场景里，以前 Agent 每调一次命令行工具，外层的安全钩子（Hook）还能逐条看清、逐条拦截；现在上百次工具调用被折叠进一段动态生成的 JS 脚本里并发跑起来，单步可控的助手瞬间变成了批处理黑盒。
开源社区已经撞上了这块暗礁。GitHub 上的开源安全防御工具 Dicklesworthstone/destructive_command_guard 在文档中明确警告，Droid 的 Script 工具内部 嵌套的 Execute 调用 尚未验证受到保护，且特定版本还存在 Hook 加载回归问题。另一个第三方 Droid 封装项目 safzanpirani/ruddr 也指出，Droid 仅强制执行自身的自主性级别，根本 没有提供外部文件系统级别的容器隔离。
- 风险.当高危宿主工具被包裹在沙盒脚本内部并发触发时，企业现有的单步命令审计与拦截护栏极易被穿透，把局部失误放大成批量的破坏性操作。
把 312 次调用压进 2 次请求，展示了外围调度框架压榨模型潜力的彪悍工程力。但省下 300 万个 Token 的代价，是把透明的单步执行塞进了嵌套脚本的暗箱。对于打算把 Droid 1.0 接入生产代码库的团队来说，先给宿主机套上一层真正的外部容器隔离，远比盯着那 65.2% 的跑分重要得多。