Factory 发布 Droid 1.0 智能体框架，默认启用程序化工具调用

在过去一年里，我们与全球一些最大型企业中的数十万名开发者展开了合作。在与这些团队并肩工作的过程中，我们构建并不断打磨了一套前沿的智能体框架，直接满足企业开发的需求：在复杂任务上取得高质量结果、高效利用资源，以及强有力的安全管控。

今天，我们推出 Droid 1.0：它比以往任何时候都更准确、更高效、更快速，由全新的设计原则和程序化工具调用引擎驱动。

Droid 是我们的智能体框架。智能体框架是模型周围的一切：提示词、工具、工具结果的返回方式，以及驱动这一切运行的循环。如今，智能体可以跨数百个回合连续工作数小时甚至数天，而每个回合都会重新发送指令、工具和历史记录。

今天对 Droid 的更新是迄今为止规模最大的一次。在相同任务上，Droid 的表现优于为其模型原生构建的框架，效率最高提升 20%。它也为未来而设计：当前沿模型能够将整个工作流规划为代码时，Droid 让它们能在单次模型请求中执行数百次工具调用。

Factory 在设计上不依赖特定模型。我们相信，最好的智能体框架是为每一种模型而构建的，因此我们的用户可以选择市场上最好的模型，也可以让 Droid 通过我们的自动模型路由器 Factory Router 选择最高效的模型组合。

构建一个针对多种模型优化的框架，会让框架本身变得更好。当你只针对单一模型进行调优时，很难将真正的进步与对该模型特性的适配区分开来。跨模型工作能确保最强的改进具有泛化能力，并在启发这些改进的模型之外依然成立。

这就是我们内部 Agent Factory 背后的理念。智能体会研究基准测试中的失败案例，以及用户在实际会话中遇到的摩擦，提出改动建议，并在其影响的每一个模型家族上逐一测试。我们的工程师审查证据，并决定哪些改动上线。

最终成果是市场上最高效、面向企业就绪的编码智能体，针对每一种前沿模型进行了调优，无论其权重是开放还是闭源。

本文余下部分将介绍正面对比结果、框架背后的设计原则、我们如何构建内部 Agent Factory，以及带来最大影响的核心改动。

市场上最高效的框架

在相同任务、相同模型下，Droid 的得分更高、成本更低，优于我们测试过的所有其他框架。

图 1 Terminal-Bench 4GPT-6.1 Sol

未展示 Cursor：它无法访问 OpenAI 模型。

Opus 5.5

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. 模型调用 1，8.52 秒，然后 TodoWrite todos，5 毫秒；Read invoice.ts，14 毫秒。
2. 模型调用 2，3.27 秒，然后 Read invoice.test.ts，22 毫秒。
3. 模型调用 3，4.04 秒，然后 Execute git status，218 毫秒。
4. 模型调用 4，3.42 秒，然后 Read tax.ts，14 毫秒。
5. 模型调用 5，3.55 秒，然后 Read money.ts，20 毫秒。
6. 模型调用 6，3.57 秒，然后 TodoWrite todos，5 毫秒；ApplyPatch invoice.test.ts，1.05 秒。
7. 模型调用 7，3.42 秒，然后 TodoWrite todos，6 毫秒；Execute vitest run，3.59 秒。
8. 模型调用 8，4.73 秒，然后 Execute eslint，7.94 秒；Execute prettier --check，432 毫秒。
9. 模型调用 9，5.49 秒，然后执行 git diff --check，120 毫秒；执行 git status，271 毫秒。
10. 模型调用 10，2.33 秒，然后 TodoWrite todos，7 毫秒，并给出最终答案。

Script 工具，逐次如下：

1. 模型调用 1，8.64 秒，然后一个 Script，421 毫秒，运行 TodoWrite todos，5 毫秒；Read invoice.test.ts，22 毫秒；Read invoice.ts，14 毫秒；执行 git status，218 毫秒；Read tax.ts，14 毫秒；Read money.ts，20 毫秒。
2. 模型调用 2，5.35 秒，然后一个 Script，1.25 秒，运行 TodoWrite todos，5 毫秒；ApplyPatch invoice.test.ts，1.05 秒。
3. 模型调用 3，3.36 秒，然后一个 Script，3.78 秒，运行 TodoWrite todos，6 毫秒；执行 vitest run，3.59 秒。
4. 模型调用 4，8.42 秒，然后一个 Script，8.14 秒，运行执行 eslint，7.94 秒；执行 prettier --check，432 毫秒；执行 git diff --check，120 毫秒；执行 git status，271 毫秒。
5. 模型调用 5，2.27 秒，然后 TodoWrite todos，7 毫秒，并给出最终答案。

直接工具调用：模型在每进行一到两次工具调用后就会被再次调用。模型调用 1 次，工具调用 0 次，耗时 0.0 秒。Script 工具：每次模型调用都会编写一个程序，由该程序运行其工具调用并返回一个结果。模型调用 1 次，工具调用 0 次，耗时 0.0 秒。模型调用、工具调用、Script、节省的时间

由于这些调用是代码，一个结果可以影响下一次调用。例如，程序可以在一次执行中搜索、读取每个匹配项并筛选结果。而使用直接调用时，每一步都需要一次模型请求。

与直接工具调用相比，在 Claude Opus 5.5 上，Script 模式将 Droid 的成本降低了 15%。大多数 Script 都很小，而每项任务的节省主要集中在其中 12.5% 会发起六次或更多工具调用的 Script 上。

来自该尾部、取自我们自己会话的两个 Script（已简化，并更改了名称和标识符）展示了这一效果。对于每一个，一个 Script 和直接调用会发起相同的工具调用。区别在于它们需要多少次模型请求：直接调用每次请求只能容纳少数几次调用，并在步骤之间等待模型，而一个 Script 会在一个程序中运行全部调用。直接调用的数字是估算值，假设每次请求进行 3 到 10 次调用。

Linear 清理在队列之间移动了 151 个 issue，并逐一验证了每次移动，总共 312 次工具调用。使用直接调用时，每个请求都会重新发送指令和不断增长的历史记录，因此即使每个请求进行 10 次调用，该任务也需要 36 个请求，并读取约 310 万个输入 token。而 Script 只用了 2 个请求和约 61,000 个 token：一个请求用于编写程序，另一个用于读取程序打印的内容。

CI 扫描展示了节省的另一半：模型读取的内容。Script 在 547 次运行中检查了 5,384 个桌面任务，共 550 次工具调用，每次 60 个，仅用 2 次请求完成，而按估算需要 59 到 187 次请求。模型只看到一份包含五个数字的摘要，其中包含 41 个失败任务。不到 0.1% 的工具结果进入了它的上下文。该扫描在后台运行了约 8 分钟，期间模型在处理另一项任务。

图 3 Script 与直接调用

同样的 312 次工具调用，两种方式。直接调用，按每次请求 10 次调用建模：36 次模型请求，每个原始结果都进入模型的上下文。一个 Script：2 次模型请求，一次用于编写程序，一次用于读取它打印的 6 行内容；原始结果留在程序中。

同一批 312 次工具调用的模型请求数直接调用1一个 Script1

直接调用每次请求可容纳 10 次调用，模型会在下一批之前读取每一个结果。

任务：将 151 个已批准的 issue 移至 backlog，并验证每个 issue 仅状态发生变化。

直接调用 · 每次模型请求 10 次调用请求 1 · 模型选择第一批调用模型 ↔ 工具每批一次模型请求0 次工具调用读取上一份报告模型等待每一批每个原始结果上下文0 个原始结果

• 目前还没有

一个脚本 · 调用在程序内部运行请求 1 · 模型编写 ScriptProgram 在模型外部运行 0 次嵌套调用 原始结果留在这里 只有程序打印的内容（text()）会进入上下文 模型读取的内容

• 目前还没有打印任何内容

这个 Script 是在请求 1 中编写的，text() 会打印给模型 1const remaining = new Set(readReport('<report>').notAttempted) // 151 个 issue 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 个 issue 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 })

它如何提升质量

• 原始文件、搜索结果和日志都留在程序里，因此模型需要推理的噪声更少。循环和工作流以确定性的方式运行。Linear 清理任务在每次写入前后比较 15 个字段，保留精确计数，并设置为在遇到第一个以任何其他方式发生变更的 issue 时停止。规划在前期完成。模型在其推理中梳理出整个执行序列，而它编写的程序就是计划。更强的模型能规划得更远，因此它们的脚本更复杂，也能做更 原始文件、搜索结果和日志都留在程序里，因此模型需要推理的噪声更少。
• 循环和工作流以确定性的方式运行。 Linear 清理任务在每次写入前后比较 15 个字段，保留精确计数，并设置为在遇到第一个以任何其他方式发生变更的 issue 时停止。
• 规划在前期完成。 模型在其推理过程中梳理出整个执行序列，而它编写的程序就是计划。更强的模型能规划得更远，因此它们的脚本更复杂，也能在单次请求中完成更多工作。

前沿模型已经能从程序化工具调用中获得最大收益，我们预计随着前沿能力的提升，这些收益还会继续增长。

对于 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 的大多数改动也正是由这个循环产生的。新的模型和快照每隔几周就会出现。没有任何团队能靠为每一个模型手工调优 harness 来跟上节奏。

图 4 Droid 是如何构建的下一轮循环01引入新模型被加入 Droid 并接受检查。02评估每个模型运行相同的任务。03读取轨迹智能体找出失败运行之间的共同点。04提出附带明确假设的变更草案。05测试在每个受影响的模型上进行受控实验。工程师合并每个模型运行所依赖的 harness，以及运行这一循环的智能体。

这个循环始于一个模型首次可供使用之时，通常是以早期访问快照的形式。一套追踪 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%，而这两个模型本来就没有可节省的空间。它作为一项选项发布，模型在需要行号时会请求启用它。

工程师位于这个循环的末端。他们阅读每一项提案及其证据，对照这些原则进行核查，并决定哪些内容可以发布。最终得到的是一套能与模型提供商保持同步的框架。

超越程序化工具调用

程序化工具调用是这个循环带来的最大变化，但并非唯一的变化。其余的变化较小，分散在整个框架中：每次请求中提供商可以复用多少内容、每次请求包含什么、当某一轮出错时循环如何恢复，以及每次请求发出的速度有多快。

保持提示词缓存处于热状态

提供商按前缀缓存请求，因此任何改动都会使其后的所有内容失效。Droid 的请求原本就是仅追加的，只有一个例外：工具发现。工具定义位于请求顶部附近，因此在会话中途加载 MCP 或连接器工具意味着要重新处理整个对话。现在，Droid 会将新发现的工具追加到请求末尾，从而保持已缓存的 prefix 不受影响。

图 5 加载工具。一个示例请求，两种方式。之前 · 新工具插入工具列表：73,500 个 token 全新处理，28,000 个从缓存复用。Droid 1.0 · 新工具追加到末尾：1,500 个 token 全新处理，100,000 个从缓存复用。

其他变更的规则相同 · 实测

会话期间的变更	下一次请求，从缓存读取
Git 状态变更 · 测试中 · 复用 19,976 个 token，新增 176 个	99.1%
会话回滚在测试中	99.8%
第二个子代理，类型相同，测试中	96.5%
加载新工具前后对比测试，Azure · 全部 26,400 个 token 均被复用	100%

从缓存读取再次处理新 token

在生产环境中，典型请求有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%）0.170.0（Opus 4.8）0.250.0（Opus 5.5）

大部分改写工作是由模型自己完成的。一个自动化流程会定期把 Droid 的指令交给模型，让它找出重复、矛盾或含糊的指导内容。每项发现都会变成一条拟议修改，并像其他任何变更一样接受测试。

有界自主性

智能体自主运行的时间越长，就越有可能陷入停滞、重复工作或彻底放弃任务。Droid 能检测出上述每一种情况，并且每种情况都会对应一个明确的下一步：提醒、重试或停止。这些规则存在于循环之中，而非模型之中，因此它们对 Droid 支持的每一个提供商都适用，新模型在第一天就能获得这些规则。

卡住通常会在流中显现出来。在 Factory 管理的 Anthropic 流上，4 分钟无输出即视为流中断并会重试。触及硬性时间限制的响应最多尝试两次，而中途中断的响应会在重试前被移除，因此模型只会基于完整的回答继续构建。

重复性工作通过计数来捕获。连续三轮没有可见输出，Droid 就会停止。三次完全相同的工具调用会收到一次提醒，六次则终止循环。如果重复调用返回了新结果，比如轮询构建状态，则可以继续。

丢弃任务最常发生在长对话被摘要的时候。这些压缩摘要现在有 16,000 个 token 的空间，高于此前的 8,000 个，因为据我们估计，此前有三分之一甚至更多的内容会填满旧的上限。

然而，并非每一次长时间等待都是失败。当模型开始执行需要较长时间的工作时，例如子智能体或长时间运行的命令，它可以将这项工作移到后台并进入休眠。当工作完成时，Droid 会用提醒将其唤醒。

剖析热路径

在请求被缓存和裁剪之后，模型的响应时间基本已不在我们的掌控之中。但我们把请求送达模型的速度仍在我们手中。Droid 在每一轮都会重建已连接应用的列表，而随着会话历史增长，预检工具查找也变得越来越慢。

第一轮的开销最大。登录检查重复执行，而且一个接一个地串行运行。启动请求要等待 Droid 的全部代码加载完成，而第一个模型请求则要等待所有 MCP 服务器就绪。自带 Amazon Bedrock 凭据的用户还要额外等待这些凭据加载。

在最新更新中，这些等待都已消失或不再挡路。Droid 会复用已连接应用的列表，直到连接发生变化才重建，从而将轮次准备时间缩短至 24 毫秒。在一项受控测试中，仅这一项改动就让中位响应完成时间提前了 13%。Droid 现在只读取会话历史的最新部分，因此预检工具查找大约只需一毫秒。登录检查并行执行且不重复，中位耗时从 101 毫秒降至 59 毫秒。 droid exec 在自身代码仍在加载时，就一并发送身份、功能开关、组织策略和连接器请求，将首次模型请求的中位时间从 1,741 毫秒缩短至 646 毫秒。MCP 服务器与第一轮同时启动，因此一个需要 3 秒才能初始化的服务器不再拖慢它，Bedrock 凭据也在首次请求之前就绪。在用户机器之外，我们推理代理中的一项路由修复为每次模型调用节省了 150 毫秒。

结果在一次真实的生产智能体轮次中显而易见。Droid 从按下 Enter 到发送请求耗时 124 毫秒：97 毫秒用于收集上下文，27 毫秒用于构建上下文。这意味着在用户等待首个 token 的时间里，模型请求占了 97%。

从启动开始

除了智能体循环之外，Droid 1.0 还削减了用户在应用本身遇到的延迟：打开应用、启动会话、同时运行多个会话以及退出应用。

3.8×3.8×3.8×首次绘制更快 · 1,839 → 488 毫秒3.0×3.0×3.0×更快到达首个提示 · 1,876 → 618 毫秒30 毫秒30 毫秒30 毫秒退出，生产环境中位数 · 原为 648 毫秒

开启是每次会话中的第一次等待。在8月25日和10月20日两个版本之间，首次绘制的中位时间从1,839毫秒降至488毫秒，Droid接受提示的时间从1,876毫秒降至618毫秒，两者均缩短约70%。其中大部分来自在首帧之前减少工作量。Droid现在发布预编译代码，因此启动时不再解析约6,000个模块。启动完成期间按键即可被记录，并且CI会让任何使首次按键p95超过250毫秒的改动失败。升级到Bun 1.4.2后，Linux、macOS和Windows上的p95启动时间缩短了13–22%，对于后者，Droid现在还跳过控制台设置并缓存系统证书列表。

远程计算机上的会话在守护进程中运行，因此必须等守护进程就绪后才能启动。过去，守护进程需要先等待登录 shell、证书、区域设置和技能加载完成。现在，这些内容都改为即时加载。在开发者的 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

未显示 Cursor：它无法访问 OpenAI 模型。

Opus 5.5

在 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 守护进程，并在那里管理会话。

方法论

• 正面交锋。
  • 使用的版本： 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 对每项任务运行了三次试验。
  • 因测试框架之外的原因而失败的试验进行了重跑：评测未能启动、模型请求超时，或提供商容量不足。
  • Anthropic 的内容审核在 Claude Opus 5.5 上阻止了部分任务。对于所有遇到此情况的 harness，这些试验都在 Claude Opus 5 上重新运行，直到不再出现内容审核错误。GPT 模型没有此类拦截。
  • Devin 无法关闭其向用户提问的工具，因此在某些任务上使用 GPT-6.1 Sol 时，它会停下来提问而不是完成任务。为保证比较公平，如果 Codex 通过了某项 Devin 停下来提问的任务，则该任务计为通过（每次试验平均 4.7 项任务）。这只影响准确率，不影响成本或时间。
  • Cursor 在任务中途重新连接时会少计 token，因此对于发生这种情况的两次试验，我们根据对话记录估算了缺失的用量。
  • 成本和耗时按每个通过的任务计算，采用各提供商的标价。图表中成本从左到右由最贵到最便宜排列。
  • Droid 每次只与一个 harness 在同一模型上进行比较。
  • 我们只统计两个 harness 在全部三次试验中都通过的任务，因此两者是在相同的工作上进行比较。
  • 成本基于所用 token 计算，按标价计价。
  • 时间是指智能体实际工作所花费的时长，不计入环境搭建或评分环节。
• 其他所有内容。
  • 这里描述的每一项改动都在生产环境的 Droid 中运行。
  • 生产数据来自 Droid 自身的遥测，并排除了 CI：提示复用、每周最新版本的启动中位数、退出时间，以及首轮追踪。
  • 提示复用按请求衡量：在截至 10 月 22 日的 7 天内，对 2040 万次生产环境 Droid CLI 请求统计，从提供商缓存读取的输入 token 占比，CI 和评测已排除。若按 token 而非按请求加权，该占比为 91.5%。仅追加是指提示缓存监控未标记的请求占比。
  • 一些与启动时间相关的指标来自受控测试，这些测试在同一任务和同一机器上比较变更前后的构建。
  • 建模数字对应 Script 示例中直接调用的一侧：低端为每请求 10 次调用，高端为 3 次，每请求约有 28,000 个 token 的固定指令。

引用格式：Factory Research。“Droid 1.0: Building a Frontier Harness。”Factory，2026 年 10 月。factory.ai/news/frontier-harness

Droid 1.0 今天就能运行本页面上的所有内容。

试用 Droid