Factory 发布 Droid 1.0，以程序化工具调用构建企业级 Agent harness
Droid 1.0: Building a Frontier Harness
Factory 发布 Droid 1.0，一个模型无关的 agent harness，主打程序化工具调用（PTC），模型通过编写 JavaScript 程序在沙箱中一次执行数百个工具调用。
原文给出 Droid 1.0 的基准对比数据和程序化工具调用设计细节，读者可以据此评估这个 Agent harness 的成本与质量取舍。
驱动 Factory 企业级智能体的全新引擎，专为复杂项目和日常开发打造。
2026年10月29日作者：Factory Research阅读时长 15 分钟
分享
过去一年，我们与全球一些最大型企业中的数十万名开发者合作。在与这些团队并肩工作的过程中，我们构建并不断打磨了一套前沿的智能体运行框架（agent harness），直接满足企业开发的需求：在复杂任务上给出高质量结果、高效利用资源，并具备强大的安全管控。
今天，我们推出 Droid 1.0：它比以往更准确、更高效、也更快，背后是全新的设计原则和一套程序化工具调用引擎。
Droid 是我们的智能体运行框架。所谓运行框架，指的是模型之外的一切：提示词、工具、工具结果的返回方式，以及驱动这一切运转的循环。如今智能体可以连续工作数小时甚至数天、跨越数百个回合，而每个回合都要重新发送指令、工具和历史记录。
此次 Droid 的更新是迄今规模最大的一次。在相同任务上，Droid 的表现优于各模型自带的原生运行框架，效率最高提升 20%。它也为未来做好了准备：当前沿模型能够把整个工作流规划成代码时，Droid 可以让它们在单次模型请求中执行数百次工具调用。
Factory 在设计上不绑定任何模型。我们相信，最好的智能体运行框架应当为每一种模型而构建，这样用户既能选择市面上最强的模型，也能让 Droid 通过我们的自动模型路由 Factory Router，挑选最高效的模型组合。
为多种模型打造运行框架，本身就会让框架变得更好。如果只针对单一模型调优，就很难分清哪些是真正的进步，哪些只是对该模型特性的迁就。跨模型工作能确保最有力的改进具有普适性，并且在启发它的那个模型之外依然成立。
这正是我们内部 Agent Factory 的理念。智能体会研究基准测试中的失败案例，以及用户在真实会话中遇到的阻碍，提出改动方案，并在每一个受影响的模型家族上逐一测试。我们的工程师审核证据，再决定哪些改动上线。
最终成果是市面上最高效、面向企业、并为每一种前沿模型（无论开放权重还是闭源权重）调优过的编程智能体。
本文余下部分将介绍正面对比的结果、运行框架背后的设计原则、我们如何搭建内部 Agent Factory，以及带来最大影响的核心改动。
市面上最高效的运行框架
在相同任务、相同模型下，Droid 的得分高于我们测试过的其他所有运行框架，成本却更低。
图 1 Terminal-Bench 4
GPT-6.1 Sol
通过率与每个通过任务的成本对比，GPT-6.1 Sol。Droid：57.6%，$0.79；OpenCode：51.0%，$0.77；Codex：54.0%，$0.90；Devin：45.0%，$1.27。
未列出 Cursor：它无法访问 OpenAI 模型。
Opus 5.5
通过率与每个通过任务的成本对比，Opus 5.5。Droid：65.2%，$4.73；Cursor：62.1%，$4.78；OpenCode：62.1%，$6.20；Devin：59.6%，$6.21；Claude Code：57.6%，$5.71。
Terminal-Bench 4。使用 GPT-6.1 Sol 时，Droid 比 Codex 高 3.5 分，成本低 12%；比 OpenCode 和 Devin 高 6.6 至 12.6 分。使用 Claude Opus 5.5 时，Droid 比 Cursor、OpenCode、Devin 和 Claude Code 高 3.0 至 7.6 分，成本最多低 24%。方法说明
智能体运行时间越长，这个差距就越重要。在数百个步骤中，更强的智能体犯的错误更少，后续步骤可以在此基础上继续推进；而成本更低的智能体则让你能在同样的预算下运行更多智能体。Droid 会针对它支持的每个模型分别调整提示词、工具描述和工具调用模式，因此每个受支持的模型都能获得这些收益，包括你自带 API 密钥的情况。
这些结果背后最大的变化，是让模型可以从程序中调用工具。
程序化工具调用
在标准的智能体循环中，模型直接调用工具，每次工具输出都会追加到上下文中。程序化工具调用（PTC）则针对长周期任务采取了不同的思路：智能体编写一个程序来调用这些工具。
借助 PTC，智能体可以先进行推理，为工具调用工作流编写代码，然后在一次调用中端到端执行整个程序。例如，它可以编写一个工作流来读取数百个文件并找出其中提到某个主题的少数几个，对数十个 Linear 工单进行分诊，或者按照确定性流程分步执行一次棘手的数据库迁移。
CodeAct（Wang 等，2024）表明，在 17 个模型上，通过代码执行操作优于 JSON 和文本工具调用。Cloudflare 和 Anthropic 在 2025 年底将这一思路投入生产，Codex 今年又将其引入编码智能体。
我们在 Droid 1.0 中将 PTC 设为默认，原因有三。第一，它能让智能体的上下文窗口保持干净，因为它收到的只是其程序的输出。普通的工具输出（原始文件、搜索结果、日志）作为变量留在程序内部。第二，它减少了模型请求次数，因为一个程序可以运行多次调用，从而让复杂任务更快、更便宜。第三，它让智能体更可靠：检查和循环在代码中确定性地运行，消除了模型可能偷懒、尽管原本计划过却漏掉某个情况的可能性。
脚本模式
Droid 将 PTC 实现为一个 Script 工具。模型编写 JavaScript，在沙箱中运行，自身没有文件、网络或系统访问权限。
一个 Script 可以在一次模型请求中发起数百次工具调用，因此指令和历史只发送一次，而不是每隔几次调用就重新发送。打印输出有大小上限，完整结果会记录在日志中，模型之后可以搜索。互不依赖的调用会并发执行，因此一批调用的耗时取决于其中最慢的那次调用。
图 2 程序化工具调用
直接工具调用：10 次模型调用和 15 次工具调用，耗时 56.8 秒。Script 工具：5 次模型调用和同样的 15 次工具调用，耗时 41.6 秒，快了 15.2 秒。
直接工具调用，逐次如下：
- 模型调用 1，8.52 秒，然后 TodoWrite todos，5 毫秒；Read invoice.ts，14 毫秒。
- 模型调用 2，3.27 秒，然后 Read invoice.test.ts，22 毫秒。
- 模型调用 3，4.04 秒，然后 Execute git status，218 毫秒。
- 模型调用 4，3.42 秒，然后 Read tax.ts，14 毫秒。
- 模型调用 5，3.55 秒，然后 Read money.ts，20 毫秒。
- 模型调用 6，3.57 秒，然后 TodoWrite todos，5 毫秒；ApplyPatch invoice.test.ts，1.05 秒。
- 模型调用 7，3.42 秒，然后 TodoWrite todos，6 毫秒；Execute vitest run，3.59 秒。
- 模型调用 8，4.73 秒，然后 Execute eslint，7.94 秒；Execute prettier --check，432 毫秒。
- 模型调用 9，5.49 秒，然后 Execute git diff --check，120 毫秒；Execute git status，271 毫秒。
- 模型调用 10，2.33 秒，然后 TodoWrite todos，7 毫秒，并给出最终答案。
Script 工具，逐次如下：
- 第 1 次模型调用，8.64 秒，随后执行一个脚本，421 毫秒，运行 TodoWrite todos，5 毫秒；读取 invoice.test.ts，22 毫秒；读取 invoice.ts，14 毫秒；执行 git status，218 毫秒；读取 tax.ts，14 毫秒；读取 money.ts，20 毫秒。
- 第 2 次模型调用，5.35 秒，随后执行一个脚本，1.25 秒，运行 TodoWrite todos，5 毫秒；ApplyPatch invoice.test.ts，1.05 秒。
- 第 3 次模型调用，3.36 秒，随后执行一个脚本，3.78 秒，运行 TodoWrite todos，6 毫秒；执行 vitest run，3.59 秒。
- 第 4 次模型调用，8.42 秒，随后执行一个脚本，8.14 秒，运行 Execute eslint，7.94 秒；执行 prettier --check，432 毫秒；执行 git diff --check，120 毫秒；执行 git status，271 毫秒。
- 第 5 次模型调用，2.27 秒，随后运行 TodoWrite todos，7 毫秒，并给出最终答案。
直接工具调用
模型每进行一到两次工具调用后就会被再次调用。
模型调用
1
工具调用
0
耗时
0.0 秒
脚本工具
每次模型调用都会写一个程序，由它执行各项工具调用并返回一个结果。
模型调用
1
工具调用
0
耗时
0.0 秒
模型调用工具调用脚本节省时间
下面是一个常见的会话模式：用 GPT-6.1 Sol 在高推理档位修复一个失败的单元测试，并在同一时间轴上分别回放两种方式。采用
直接工具调用时，模型每进行一到两次工具调用后就会被再次调用，总共
10
次。采用
脚本工具时，每次模型调用都会写一个程序，由它执行各项工具调用并返回一个结果，因此同样的
15
次工具调用只需
5
次模型调用。模型调用耗时从
42.3 秒
降到
28.0 秒
,任务完成时间从
56.8 秒
缩短到
41.6 秒
。工具耗时均为实测值。直接调用方式把同样的调用按每次模型调用一到两次来安排，工具结果与下一次模型调用之间间隔
0.15
秒。每次工具调用各占一行，宽度与调用耗时成正比。悬停或点按条形可查看精确耗时。
由于这些调用本身就是代码，一个结果可以影响下一次调用。例如，一个程序可以一次完成搜索、读取所有匹配项并筛选结果。若用直接调用，每一步都要消耗一次模型请求。
与直接工具调用相比，在 Claude Opus 5.5 上，脚本模式将 Droid 的成本降低了 15%。大多数脚本都很小，每个任务的节省主要集中在其中 12.5% 会发起六次及以上工具调用的脚本上。
从我们自己的会话中选取了处于这一长尾的两个脚本（已简化，名称和标识符有改动），用以说明效果。对每个脚本，脚本方式和直接调用方式执行相同的工具调用，区别在于所需的模型请求次数：直接调用每次请求只能容纳少量调用，且步骤之间要等待模型；而脚本方式在一个程序中全部执行。直接调用的数字为估算值，假设每次请求 3 到 10 次调用。
Linear 清理任务在队列之间移动了 151 个 issue 并逐一验证，共 312 次工具调用。若用直接调用，每次请求都要重新发送指令和不断增长的历史记录，因此即便按每次请求 10 次调用计算，该任务也需要 36 次请求，读取约 310 万输入 token。而脚本方式只用了 2 次请求、约 61,000 token：一次请求用于编写程序，一次用于读取程序打印的结果。
CI 扫描则体现了节省的另一半：模型读取的内容。脚本检查了 547 次运行中的 5,384 个桌面任务，共 550 次工具调用，每次并发 60 个，只用了 2 次请求，而估算需要 59 到 187 次。模型只看到一份包含五个数字的摘要，其中包括 41 个失败任务。进入其上下文的工具结果不到 0.1%。该扫描在后台运行了约 8 分钟，期间模型继续处理另一项任务。
图 3 脚本方式与直接调用对比
同样是 312 次工具调用，两种做法。直接调用按每次请求 10 次调用估算：需要 36 次模型请求，而且每个原始结果都会进入模型的上下文。而用一段 Script：只需 2 次模型请求，一次用来写程序，一次用来读取它打印出的 6 行内容；原始结果都留在程序里。
第 1 次请求中写出的 Scripttext() 会把内容打印给模型
1const remaining = new Set(readReport('<report>').notAttempted) // 151 个问题
2
3// 两个队列并行读取
4const queues = await Promise.all([listAll('Triage'), listAll('<queue 2>')])
5const targets = queues.flat().filter((i) => remaining.has(i.id))
6
7const verified = [], failures = []
8for (const batch of chunks(targets, 3)) { // 每次处理 3 个问题
9 await Promise.allSettled(batch.map((i) => setStatus(i, 'Backlog')))
10 const after = await Promise.allSettled(batch.map((i) => getIssue(i)))
11 after.forEach((r, n) =>
12 (onlyStatusChanged(batch[n], r.value) ? verified : failures).push(batch[n].id))
13 if (failures.length) break // 遇到第一处意外变更就停止
14 if (verified.length % 30 === 0) text(`${verified.length} of 151 verified`)
15}
16
17writeResult('<result file>', { verified, failures })
18text({ verified: verified.length, failures })
这是 Factory 自己会话中一段真实的 Script，即 Linear 清理任务，经过简化并改了名称。两边都跑在同一个示意性的时钟上。直接调用一侧是按每次请求
10
次调用做的估算：每一批都要等模型读完上一批的结果。如果按每次请求
3
次调用算，就需要
107
次请求。由于每次请求都要重新发送约 28,000 个 token 的指令，直接调用一侧要读取
约 310 万
个输入 token；而 Script 只读取
61,000
. 结果大小按典型问题的规模估算。
它如何提升质量
- 更干净的上下文。原始文件、搜索结果和日志都留在程序里，模型推理时受到的噪声干扰更少。
- 循环和工作流以确定性的方式运行。Linear 清理任务在每次写入前后都比较 15 个字段，保留精确计数，并且被设定为一旦某个问题出现其他任何变更就立即停止。
- 规划在前。模型在推理过程中就把整个执行顺序想清楚，它写出的程序就是计划。模型越强，规划得越远，写出的 Script 也越复杂，单次请求能完成的事情越多。
前沿模型已经能把程序化工具调用发挥到极致，我们预计随着前沿模型不断进步，收益还会继续扩大。
Script 模式默认对 GPT-6.1 Sol、GPT-6.1 Terra、GPT-6 Astra、GPT-6 Sol、GPT-5.6 Sol、Claude Fable 5.1、Claude Fable 5、Claude Opus 5.5、Claude Opus 5 和 Kimi K3 开启。
设计取舍
程序化工具调用实现起来简单，却很容易做错。以下是最关键的几项取舍。
| 取舍 | 实现方式 | 为何重要 |
|---|---|---|
| 程序拿到的是真实数据 | 完整文件，以及结构化、带类型的搜索结果。 | 过滤和计数都在代码里完成，不消耗 token。 |
| 字面文本原样传递 | 文件内容、补丁和命令都放在原始输入块里，不做转义字符串处理。 | token 更少，格式错误的调用也更少。 |
| 编辑结果返回简短 | 在程序中执行编辑，返回的摘要和直接编辑一样简短。 | 文件不会被重新粘贴回上下文。 |
| 长任务不会卡住 | 程序最多等待 5 分钟，然后交回目前为止的输出。它也可以在后台启动并立即返回。 | 模型可以继续工作。 |
| 无需轮询 | 有专门的工具负责查看、等待或停止正在运行的程序。后台任务完成后，Droid 会唤醒模型。 | 不必再花请求去问任务是否完成。 |
智能体工厂
脚本模式，以及每个模型是否使用它的选择，都出自同一个循环——Droid 的大多数改动正是由这个循环产生的。新模型和新快照每隔几周就会出现，没有哪个团队能靠手工为每一个调优运行框架来跟上节奏。
图 4 Droid 的构建方式
01
引入
新模型被加入 Droid 并接受检查。
02
评估
每个模型都运行相同的任务。
03
读轨迹
智能体找出失败运行之间的共同点。
04
提议
一份附带明确假设的改动草案。
05
测试
在每个受影响的模型上做受控实验。
工程师合并
每个模型运行的框架，以及运行这个循环的智能体。
每个新模型都从第 1 步进入。Droid 自己运行每一步，在工程师审查并合并之前，任何改动都不会上线。改进后的 Droid 再运行下一轮循环。
循环从模型首次可用时开始，通常是一个抢先体验的快照。一套追踪 20 多个模型的自动化流程会把它加入 Droid，并用我们的行为断言来检查它。通过断言只是最低要求，并不是发布门槛。此后，每个可用模型都通过产品本身来评估：在真实环境中、通过 QA，以及每日基准测试。线上错误日志和用户遇到的摩擦会被补充到每个模型的结果中，这样负责审查的智能体就能同时看到基准测试失败和真实会话。
单次失败说明不了什么，所以智能体会寻找在不同任务和模型之间重复出现的原因。它把每个发现转化为一份提议改动，写明假设，再用受控实验在每一个受影响的模型上衡量改动效果。
由于这些改动大多由智能体编写，提出改动的智能体和审查它的工程师必须对“什么是好的改动”有相同的理解。每一轮都会重新发送整个请求，所以一条位置不当的指令或一份过时的工具输出不会只造成一次伤害，它会在之后的每一轮里分散模型的注意力，损失质量、token 和时间。每份提议都必须遵循同样的原则：
- 精打细算每一个 token，把大型工具结果保存在文件里。
- 始终维护提示词缓存，让请求逐步增长。
- 剖析通往推理的热路径，能缓存的一律缓存。
- 跟踪后台工作，比如长命令和子智能体，并在完成时唤醒模型。
- 智能体卡住时，总要准备好下一步：轻推、重试、总结或停止。
Droid 提出的改动取决于它要达成的目标。此外还有一项要求：每个目标都必须在所有模型家族上成立。我们在 GPT-6.1 Sol、Claude Opus 5.5、GLM 5.3 和 Kimi K3 上调整 Script 模式时，目标之一是：同时提供 Script 和直接工具时，模型应当选择 Script。这个循环产出的改动涉及提示词、Script 内部所调用工具的描述，以及 Script 结果的结构。没有任何一项单独改动能推动所有模型，但三项合在一起，在所有模型上都达成了目标。
另一个目标是让 Script 模式的成本在每个模型家族上都低于直接调用。给每个读取文件的每一行编号，让 Sol 不再通过 shell 重读文件来获取行号，并在某个任务上把 Opus 的成本降低了 22%。但这也让每次读取每行多出约两个 token，使 GLM 的成本上升 8%、Kimi 上升 32%——这两个模型本来就没有可节省的空间。最终这项功能作为可选项发布，由模型在需要行号时主动请求。
工程师处在循环的末端。他们会结合证据阅读每一份提案，对照这些原则进行核查，再决定哪些改动上线。最终得到的是一套能与模型提供方保持同步的 harness。
超越程序化工具调用
程序化工具调用是这个循环产出的最大改动，但并非唯一改动。其余改动较小，分散在 harness 各处：每次请求中提供方可复用的部分有多少、每次请求包含什么内容、一轮出错后循环如何恢复，以及每次请求发出的速度。
保持提示词缓存有效
提供方按前缀缓存请求，因此任何改动都会使其后的内容全部失效。Droid 的请求原本就是只追加的，只有一个例外：工具发现。工具定义位于请求靠前的位置，因此在会话中途加载 MCP 或连接器工具，意味着要重新处理整段对话。现在 Droid 会把新发现的工具追加到请求末尾，保持已缓存的前缀不受影响。
图 5 加载工具
同一请求的两种方式示意
改动前 · 新工具插入工具列表
73,500 个 token 重新处理
28,000 个 token 从缓存复用
改动前：28,000 个 token 从缓存复用，73,500 个 token 重新处理。
Droid 1.0 · 新工具追加到末尾
1,500 个 token 重新处理
100,000 个 token 从缓存复用
Droid 1.0：100,000 个 token 从缓存复用，1,500 个 token 重新处理。
| 会话中的改动 | 下一次请求从缓存读取的情况 |
|---|---|
Git 状态变化 测试中 · 19,976 个 token 复用，176 个新增 | 99.1% |
会话回滚 测试中 | 99.8% |
第二个同类型子智能体 测试中 | 96.5% |
加载新工具 Azure 上的前后对比测试 · 全部 26,400 个 token 复用 | 100% |
从缓存读取重新处理新增 token
上图：一个约
100,000
个 token 的请求示意，其中约
28,000
个 token 的指令和工具位于对话之前。提供方只会复用请求开头直到第一个改动处为止的部分。把工具插入工具列表会改动请求靠前的位置，因此其后的整段对话都要重新处理。追加到末尾时，该工具就是唯一新增的部分。下图：会话中的其他改动，以及下一次请求从缓存读取的比例，均为测试实测；工具加载是在 Azure 上进行的前后对比测试。
在生产环境中，典型请求有 98% 的输入来自缓存，98.6% 的请求严格只做追加。监控程序会拿每个请求与前一个请求比对，指出任何破坏缓存的部分，从而维持这一状态。这类破坏代价高昂：请求开头只要有一个 token 发生变化，就得整体重新处理。这也正是 Agent Factory 最擅长的工作，它已经交付了多项提示词缓存修复。现在，git 状态变化后，下一个请求只新增 176 个 token。回滚能复用 99.8% 的缓存，同类型的第二个子智能体复用 96.5%。出错也不会重置缓存，因为 Droid 会在已经持有该请求的提供商那里重试失败的请求。
基础提示词缩减 37%
首个请求携带指令、工具定义和启动上下文，这些内容会随之后每一轮一起发送，因此是我们削减力度最大的部分。从 Droid 0.170.0 到 0.250.0，它从 20,887 个输入 token 降到 13,055 个（减少 37%）。
节省主要来自工具。Droid 过去会预先发送 11 个工具定义，现在只发 2 个，不常用的工具在模型需要时按需加载。工具定义减少了 45%，Droid 在启动时添加的提醒减少了三分之一。系统提示词则相反，增长了 31%，尽管旧提示词中的大部分规则都被缩短了。增长来自两个领域的新指引：智能体如何与用户交流，以及如何处理图像、已连接应用和个人数据等环境细节。
图 6 提示词预算
实测
工具定义
15,798 → 8,528−46%
启动提醒
3,463 → 2,362−32%
系统提示词
1,618 → 2,155+33%
消息“hi”
8 → 10+2
总计
20,887 → 13,055−37%
Opus 4.8 上的 0.170.0Opus 5.5 上的 0.250.0
会话首个请求（用户输入“hi”）的输入 token 数：Droid
0.170.0
在
Claude Opus 4.8
上对比
0.250.0
在
Claude Opus 5.5
。这些部分在之后的每一轮对话中都会一并发送。Droid 过去会预先发送 11 个工具定义，现在只发送 2 个；不常用的工具会在模型需要时再加载。这两个版本运行在不同的模型上，因此分词器不同；若按字符数计算（字符数不依赖分词器），请求量从
57,035
降至
36,802
(
−35%
).
大量改写工作由模型自己完成。有一套自动化流程会定期把 Droid 的指令交给模型，让它找出其中重复、矛盾或表述不清的指导内容。每条发现都会变成一项修改建议，并像其他任何改动一样接受测试。
有边界的自主性
智能体自主运行的时间越长，就越容易卡住、重复劳动，或者干脆把任务丢掉。Droid 能检测出这几种情况，并且每种情况都有明确的下一步：轻推一下、重试，或者停止。这些规则写在循环里，而不是模型里，因此对 Droid 支持的每一家提供商都成立，新模型从第 0 天起就能用上。
卡住通常会在流里表现出来。在 Factory 托管的 Anthropic 流上，静默 4 分钟即视为流中断，会进行重试。触及硬性时间上限的响应最多尝试两次；中途中断的响应会在重试前被移除，这样模型只会在完整答案的基础上继续构建。
重复劳动靠计数来发现。连续三轮没有可见输出，Droid 就会停止。三次完全相同的工具调用会触发一次轻推，六次则终止循环。如果重复调用返回了新结果，比如轮询构建状态，则可以继续。
任务丢失最常发生在长对话被压缩总结的时候。现在这些压缩摘要的容量从 8,000 个 token 提升到了 16,000 个，因为我们估计有三分之一甚至更多的摘要都顶到了旧上限。
不过，并非所有漫长的等待都是故障。当模型开始一项耗时的工作，比如启动子智能体或执行长时间运行的命令时，它可以把这项工作移到后台并进入休眠。工作完成后，Droid 会用提醒把它唤醒。
剖析热路径
请求已经做了缓存和精简，模型的响应时间基本不在我们掌控之中。但请求送达模型的速度，我们还能管。Droid 过去每一轮都会重建已连接应用的列表，而且随着会话历史变长，预检工具查找也越来越慢。
第一轮的开销最大。登录检查重复做同样的工作，而且还是一个接一个地跑。启动请求要等 Droid 的全部代码加载完，第一次模型请求则要等所有 MCP 服务器就绪。自带 Amazon Bedrock 凭据的用户还要额外等待这些凭据加载。
在最新版本中，这些等待要么消失了，要么被挪出了关键路径。Droid 会复用已连接应用的列表，直到连接发生变化才重建，把每轮准备时间缩短到 24 毫秒。在一项对照测试中，仅这一项改动就让响应完成时间的中位数提前了 13%。Droid 现在只读取会话历史的最新部分，因此预检工具查找只需约 1 毫秒。登录检查并行执行且不再重复，中位数从 101 毫秒降到 59 毫秒。droid exec 在代码仍在加载时就同时发出身份、功能开关、组织策略和连接器请求，把首次模型请求的中位时间从 1,741 毫秒缩短到 646 毫秒。MCP 服务器与第一轮同时启动，因此一个需要 3 秒初始化的服务器不再拖住第一轮，Bedrock 凭据也会在首次请求之前就绪。在用户机器之外，我们在推理代理中修复了路由问题，让每次模型调用都省下 150 毫秒。
这些改进在真实的生产智能体轮次中一目了然。从按下 Enter 到发出请求，Droid 只用了 124 毫秒：97 毫秒用于收集上下文，27 毫秒用于构建请求。这意味着用户等待首个 token 的时间里，有 97% 花在模型请求本身。
从启动就快
除了智能体循环，Droid 1.0 还削减了用户在应用本身遇到的延迟：打开应用、启动会话、同时运行多个会话以及退出。
3.8×
首次绘制更快 · 1,839 → 488 毫秒
3.0×
到首个提示词更快 · 1,876 → 618 毫秒
30 毫秒
退出，生产环境中位数 · 原为 648 毫秒
打开应用是每个会话的第一次等待。在 8 月 25 日到 10 月 20 日的版本之间，首次绘制的中位时间从 1,839 毫秒降到 488 毫秒，Droid 接受提示词的时间从 1,876 毫秒降到 618 毫秒，各自缩短了约 70%。这主要来自在第一帧之前少做事情。Droid 现在发布预编译代码，因此启动时不再解析约 6,000 个模块。启动完成前按键就能被记录，而且任何让首次按键 p95 超过 250 毫秒的改动都会导致 CI 失败。升级到 Bun 1.4.2 后，Linux、macOS 和 Windows 上的启动时间 p95 降低了 13–22%；在 Windows 上，Droid 现在还跳过了控制台初始化，并缓存了系统证书列表。
远程计算机上的会话运行在守护进程里，所以守护进程就绪之前会话无法启动。过去，守护进程要先等登录 shell、证书、locale 和技能加载完。现在这些内容都改为按需即时加载。在一位开发者的 Mac 上，从启动到就绪的中位时间从 1,956 毫秒降到 392 毫秒；使用空 shell 配置时则从 887 毫秒降到 376 毫秒。
最深层的变化在架构上。过去同时运行多个会话意味着要跑多个进程，每个进程约占 350 MB 内存，因此五个并行子智能体加上主会话要占用 2 GB 以上。现在它们共享守护进程的进程，每个会话只增加约 20 MB，/new 也是瞬间完成。
退出是最后一项等待，过去它依赖网络。现在 Droid 把尚未完成的遥测和会话同步交给一个分离进程处理，然后立即退出。生产环境中的退出中位时间从 648 毫秒降到 30 毫秒。
比以往更快
省 token 的改动也能省时间：脚本模式发出的请求更少，剩下的每个请求也更小，且大部分命中缓存。在 Claude Opus 5.5 上，Droid 每完成一个通过任务所需的时间比 Claude Code 少 26%，token 用量少 17%。在 GPT-6.1 Sol 上，它的 token 用量比 Codex 少 12%，但耗时多 10%。
图 7 Terminal-Bench 4
GPT-6.1 Sol
每任务分钟数对比每通过任务成本，GPT-6.1 Sol。Droid：25.8 分钟，$0.79；OpenCode：26.89 分钟，$0.77；Codex：23.52 分钟，$0.90；Devin：29.09 分钟，$1.27。
未列出 Cursor：它无法访问 OpenAI 模型。
Opus 5.5
每任务分钟数对比每通过任务成本，Opus 5.5。Droid：42.6 分钟，$4.73；Cursor：57.74 分钟，$4.78；OpenCode：56.25 分钟，$6.20；Devin：50.71 分钟，$6.21；Claude Code：57.37 分钟，$5.71。
Terminal-Bench 4。在 Opus 5.5 上，Droid 每完成一个通过任务所需的时间比其他所有 harness 少 16% 到 26%。在 GPT-6.1 Sol 上，它比 Codex 多花 10% 的时间，但成本低 12%，比 OpenCode 和 Devin 少花 4% 到 11% 的时间。方法说明
这些时间只涵盖任务本身。在任务之外，Droid 打开、启动会话和退出的耗时都只有八月份的一小部分，因此新建会话或在多个会话间切换几乎不花时间。
试用 Droid 1.0
Droid 1.0 今日发布。可下载 macOS 和 Windows 桌面应用，或安装终端 UI。
如果想在同一个 harness 之上构建，可以使用 Droid SDK（@factory/droid-sdk）。它运行的是与 CLI 相同的 Droid，因此本文中的每一项改动都随它一同发布。在 Node 中，应用可以启动 Droid、维持多轮会话、流式获取其工作过程，并通过 MCP 为它提供自定义工具。从另一个进程或本地浏览器工具中，应用可以连接到正在运行的 Droid 守护进程并在那里管理会话。
方法说明
- Head-to-head.
- 使用的版本：
codex@0.163.0、claude-code@2.1.306、cursor-cli@2026.10.19-6bbf2c4、devin@3000.11.92、opencode@2.1.2。 - 使用的模型：Claude Opus 5.5（高推理）和 GPT-6.1 Sol（高推理）。
- 选择高推理是因为它是我们平台上最受欢迎的推理选项，最能代表委托给 Droid 的工作负载。
- 基准测试：Terminal-Bench 4，全部任务，默认时间限制，运行于 2026 年 10 月 23 日至 28 日。
- 每个 harness 对每个任务运行三次试验。
- 因 harness 之外的原因失败的试验会重跑：评测未能启动、模型请求超时，或提供商容量不足。
- Anthropic 的内容审核在 Claude Opus 5.5 上拦截了部分任务。对每个遇到此情况的 harness，这些试验都在 Claude Opus 5 上重跑，直到不再出现内容审核错误。GPT 模型没有此类拦截。
- Devin 无法关闭向用户提问的工具，因此在某些任务上使用 GPT-6.1 Sol 时，它会停下来提问而不是完成任务。为保证对比公平，如果 Devin 停下来提问的任务在 Codex 上通过了，就计为通过（每次试验平均 4.7 个任务）。这只影响准确率，不影响成本或时间。
- Cursor 在任务中途重连时会少算 token，因此出现这种情况的两次试验中，我们根据对话记录估算了缺失的用量。
- 成本和时间按每个通过的任务计算，采用各供应商的标价。图表中成本从左到右由高到低排列。
- Droid 每次只与一个 harness 在同一模型上对比。
- 我们只统计两个 harness 在三次试验中全部通过的任务，确保两者衡量的是同样的工作。
- 成本按所用 token 以标价计算。
- 时间指智能体实际工作的时间，不含环境搭建和评分。
- 使用的版本：
- Everything else.
- 这里描述的每一项改动都已在生产版 Droid 中运行。
- 生产数据来自 Droid 自身的遥测，已排除 CI：提示词复用、每周最新版本的启动中位数、退出时间，以及首轮追踪。
- 提示词复用按请求统计：截至 10 月 22 日的 7 天内，生产环境 Droid CLI 的 2040 万次请求中，从供应商缓存读取的输入 token 占比，已排除 CI 和评测。若按 token 而非按请求加权，该占比为 91.5%。仅追加指提示词缓存监控未标记的请求占比。
- 部分与启动时间相关的指标来自受控测试，在同一批任务和同一台机器上对比改动前后的构建。
- 建模数字对应 Script 示例中的直接调用一侧：每次请求低端 10 次调用、高端 3 次调用，每次请求约有 28,000 个 token 的固定指令。
引用格式
Factory Research. "Droid 1.0: Building a Frontier Harness." Factory, October 2026. factory.ai/news/frontier-harness
来源：Factory 研究 / 产品 · factory.com