Factory 发布 Droid 1.0：面向企业开发的智能体 harness

在过去的一年里，我们与全球一些最大的企业中的数十万开发者合作。与这些团队并肩工作，我们构建并强化了一个前沿代理框架，它直接满足企业开发的需求：在复杂任务上实现高质量的结果，高效利用资源，以及强大的安全控制。

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

Droid 是我们的代理框架。代理框架是模型周围的一切：提示、工具、工具结果如何返回，以及运行所有内容的循环。代理现在可以工作数小时或数天，跨越数百次交互，并且每次交互都会重新发送指令、工具和历史记录。

今天的 Droid 更新是迄今为止最大的一次。在相同的任务上，Droid 比为其模型构建的原生框架效率高出 20%。它还设计用于未来：当前沿模型可以作为代码规划整个工作流程时，Droid 允许它们在单个模型请求中运行数百次工具调用。

Factory 是模型无关的。我们相信最好的代理框架是为每个模型构建的，因此我们的用户可以选择市场上的最佳模型，或者让 Droid 使用我们的自动模型路由器 Factory Router 选择最有效的组合。

为许多模型构建优化的框架使框架变得更好。当你针对单个模型进行调优时，很难将真实进步与对该模型怪癖的适应区分开来。跨模型工作确保了最强的改进具有普遍性，并且能够超越启发它们的模型。

这就是我们内部 Agent Factory 的想法。代理与基准测试失败以及用户在真实会话中遇到的摩擦一起学习，提出更改，并在每个受影响的模型系列上测试每一个。我们的工程师审查证据并决定哪些可以发布。

结果是，为每个前沿模型（无论是开放权重还是封闭权重）进行了优化的、企业级的编码代理。

本文的其余部分涵盖了头对头的测试结果、框架背后的设计原则、我们如何构建内部 Agent Factory，以及推动最大影响的根本变化。

市场上最高效的框架

在相同的任务上使用相同的模型，Droid 比我们测试过的其他每个框架成本更低，得分更高。

随着代理运行时间的增加，这种差距变得更加重要。在数百步中，更好的代理为后续步骤构建更少错误，而更便宜的代理允许你在相同的预算上运行更多代理。Droid 为它支持的每个模型调整其提示、工具描述和工具调用模式，因此每个支持的模型都能获得这些收益，包括当你使用自己的 API 密钥时。

这些结果背后的最大变化是允许模型从程序中调用工具。

程序化工具调用

在标准的代理循环中，模型直接调用工具，并且每个工具输出都附加到其上下文中。程序化工具调用 (PTC) 对长期工作采取了不同的方法：代理编写一个程序来调用工具。

使用 PTC，代理可以在前期进行推理，编写一个调用工具的工作流代码，然后通过一次调用执行整个程序。例如，它可以编写一个工作流来读取数百个文件并找到其中提及某个主题的少数文件，分诊数十个 Linear 工单，或者按照确定性过程分步运行复杂的数据库迁移。

CodeAct (Wang 等人，2024) 表明，通过代码执行优于 JSON 和文本工具调用，在 17 个模型中均表现更优。Cloudflare 和 Anthropic 在 2025 年底将这一想法投入生产，而 Codex 则在今年将其应用于编码代理。

我们之所以将 PTC 设为 Droid 1.0 的默认选项，有三个原因。首先，它保持了代理的上下文窗口干净，因为它接收到的只是其程序的输出。普通的工具输出（原始文件、搜索结果、日志）会保留在程序中作为变量。其次，它减少了模型请求的数量，因为一个程序可以运行多次调用，这使得复杂任务更快且更便宜。第三，它使代理更可靠：在代码中运行的检查和循环是确定性的，消除了模型可能懒惰并放弃某个案例的可能性，尽管它最初计划处理。

脚本模式

Droid 将 PTC 实现为一种脚本工具。模型编写 JavaScript，该脚本在一个沙盒中运行，没有任何文件、网络或系统访问权限。

一个脚本可以在一次模型请求中做出数百次工具调用，因此指令和历史记录只需发送一次，而不是每隔几次调用就重新发送。打印的输出有大小限制，完整结果会被记录下来，模型可以稍后搜索它们。不依赖于彼此的调用可以并行运行，因此一批调用的耗时取决于其中最慢的调用。

由于这些调用是代码，一个结果可以影响下一次调用。例如，一个程序可以搜索、读取每个匹配项，并在一次遍历中过滤结果。使用直接调用，每个步骤都会耗费一次模型请求。

与直接工具调用相比，脚本模式使 Droid 在 Claude Opus 5.5 上的成本降低了 15%。大多数脚本都很小，每项任务的节省集中在那些做出六次或更多工具调用的 12.5% 的脚本中。

从那个尾部中选取的两个脚本，来自我们自己的会话（简化，名称和标识符已更改），展示了这种效果。对于每个脚本，脚本和直接调用会做出相同的工具调用。区别在于它们需要多少次模型请求：直接调用会将几个调用放入每个请求中，并在步骤之间等待模型，而脚本则在一个程序中运行它们。直接调用的数据是估计值，假设每个请求有 3 到 10 次调用。

Linear 清理将 151 个问题在不同的队列之间移动并验证了每次移动，总共 312 次工具调用。使用直接调用，每个请求都会重新发送指令和不断增长的历史记录，因此即使每个请求有 10 次调用，这项任务也会需要 36 个请求并读取约 3.1M 个输入标记。脚本只用了 2 个请求和 ~61,000 个标记：一次请求来编写程序，另一次请求来读取它打印的内容。

CI 扫描显示了节省的另一半：模型读取的内容。脚本检查了 5,384 个桌面任务，跨越 547 次运行，共 550 次工具调用，每次 60 个，在 2 个请求中完成，而不是估计的 59 到 187 个请求。模型只看到了一个五数字摘要，包括 41 个失败的任务。不到 0.1% 的工具结果进入了它的上下文。扫描在模型处理另一项任务时大约在后台运行了 8 分钟。

它是如何提高质量的

• A cleaner context. Raw files, search results, and logs stay in the program, so the model reasons over less noise.
• Loops and workflows run deterministically. The Linear cleanup compared 15 fields before and after every write, kept exact counts, and was written to stop at the first issue that changed in any other way.
• Planning happens up front. The model works out the whole sequence in its reasoning, and the program it writes is the plan. Stronger models plan further ahead, so their Scripts are more complex and do more in a single request.

Frontier models already get the most out of programmatic tool calling, and we expect the gains to grow as the frontier does.

Script mode is on by default for 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, and Kimi K3.

Design choices

Programmatic tool calling is simple to add and easy to get wrong. These are the choices that mattered most.

The Agent Factory

Script mode, and the per-model choice of whether to use it, came out of the same loop that produces most of Droid's changes. New models and snapshots arrive every few weeks. No team can keep up by tuning a harness for each one by hand.

The loop starts when a model first becomes accessible, often as an early-access snapshot. An automation that tracks more than 20 models adds it to Droid and checks it against our behavioral assertions. Passing those is the minimum, not the bar for release. From then on, every available model is evaluated through the product itself: in live environments, through QA, and on daily benchmark runs. Live error logs and the friction users hit are added to each model's results, so the agent reviewing them sees benchmark failures and real sessions side by side.

A single failure says little, so the agent looks for causes that repeat across tasks and models. It turns each finding into a proposed change that states its hypothesis, and a controlled experiment measures the change on every model it touches.

Because agents write most of these changes, the agent proposing a change and the engineer reviewing it need the same idea of what a good change looks like. Every turn re-sends the whole request, so a badly placed instruction or a stale tool output doesn't hurt just once. It distracts the model on every turn after it, costing quality, tokens, and time. Every proposal is held to the same principles:

• Budget every token, and keep large tool results in files.
• Grow the request by always maintaining the prompt cache.
• 分析推理的热路径，缓存你能缓存的任何内容。
• 跟踪后台工作，例如长命令和子代理，并在它完成时唤醒模型。
• 当代理卡住时，始终准备好下一步：提示、重试、总结或停止。

Droid 提出的更改取决于它为之工作的目标。一个附加要求是每个目标必须在每个模型系列中保持不变。当我们调整 GPT-6.1 Sol、Claude Opus 5.5、GLM 5.3 和 Kimi K3 的脚本模式时，我们的一个目标是，在脚本和直接工具的情况下，模型应该选择脚本。这个循环产生了对提示、脚本内部调用的工具的描述以及脚本结果的结构的更改。没有单一的改变移动了每个模型，但三个改变一起在所有模型上达到了目标。

另一个目标是脚本模式在每个系列中比直接调用成本更低。对每个文件读取的每一行进行编号停止了 Sol 通过 shell 重新读取文件以获取行号，并在一项任务上将 Opus 的成本降低了 22%。它还为每个读取添加了大约每行两个标记，这使 GLM 的成本提高了 8%，使 Kimi 的成本提高了 32%，这些模型没有任何东西可以保存。它作为选项提供给模型在需要行号时请求。

工程师位于循环的末端。他们阅读每个带有其证据的建议，检查它是否符合这些原则，并决定什么可以发布。结果是与模型提供者的 harness 保持同步的 harness。

超越程序化工具调用

程序化工具调用是循环产生的最大改变，但不是唯一的改变。其余的改变较小，分布在 harness 中：提供者可以重用每个请求的多少、每个请求包含什么、循环在回合出错时如何恢复以及每个请求发出有多快。

保持提示缓存热

提供者通过前缀缓存请求，因此任何改变都会使它之后的所有内容失效。Droid 的请求已经是追加式的，只有一个例外：工具发现。工具定义位于请求的顶部附近，因此在中途加载 MCP 或连接器工具意味着重新处理整个对话。Droid 现在将新发现的工具追加到请求的末尾，保留缓存的提示前缀不变。

在生产环境中，典型的请求从缓存中读取了98%的输入，并且98.6%的请求是严格追加-only的。监控器通过将每个请求与之前的请求进行比较，并命名任何破坏缓存的部分来保持这种状态。这些破坏是昂贵的：请求早期的一个单个更改的令牌会强制重新处理整个请求。这些也是代理工厂的理想工作，该工厂已经交付了几个提示缓存修复程序。git状态更改后，下一个请求现在只添加176个新令牌。回滚重用了99.8%的缓存，而同一类型的第二个子代理重用了96.5%。错误也不会重置缓存，因为Droid在已经持有它的提供程序上重试失败的请求。

将基础提示减少37%

第一个请求携带指令、工具定义和启动上下文，这些内容在每个后续步骤中都随之一起出现，因此它是我们削减最严重的部分。在Droid 0.170.0和0.250.0之间，它从20,887个输入令牌缩小到13,055个（减少37%）。

大部分的节省来自于工具。Droid以前会发送11个工具定义。现在它只发送2个，并且很少使用的工具在模型需要时按需加载。工具定义减少了45%，Droid在启动时添加的提醒减少了三分之一。系统提示则相反，增长了31%，尽管旧提示的大部分规则都被缩短了。增长来自于两个新领域的指导：代理如何与用户交谈，以及它如何处理环境细节，例如图像、连接的应用程序和个人数据。

大部分的重写都是由模型自己完成的。一个自动化过程会给模型Droid的指令，并要求它找到重复、矛盾或不明确的指导。每个发现都成为一个建议的编辑，像任何其他更改一样进行测试。

有限的自主性

代理独立运行的时间越长，它陷入困境、重复工作或完全放弃任务的方式就越多。Droid检测到每一种情况，并且每种情况都导致一个定义的下一步：一个提示、重试或停止。规则存在于循环中而不是模型中，因此它们适用于Droid支持的所有提供程序，并且新模型在第一天就获得它们。

陷入困境通常出现在流中。在Factory管理的Anthropic流中，4分钟的沉默被视为丢失的流并重试。达到硬时间限制的响应最多尝试两次，而中途中断的响应在重试之前被移除，因此模型只在完整的答案上构建。

重复的工作是通过计数来捕获的。连续三个回合没有可见的输出，Droid就会停止。三个相同的工具调用会得到一个提示，并且六个会停止循环。返回新结果的重复，例如轮询构建，可以继续。

放弃任务最常发生在长时间对话被总结时。这些压缩摘要现在有16,000个令牌的空间，从8,000个增加到16,000个，因为据我们估计，三分之一或更多是填满了旧的限制。

然而，不是每个长时间的等待都是失败。当模型开始需要一段时间的工作，例如一个子代理或一个长时间运行的命令时，它可以移动该工作到后台并睡眠。Droid在工作完成后用提醒唤醒它。

分析热点路径

请求被缓存并优化后，模型的响应时间基本上不在我们的控制之中。我们无法控制请求到达它的速度。Droid 在每次交互中重建其连接的应用程序列表，并且随着会话历史的增长，预检工具的查找速度变慢。

第一次交互的开销最大。登录检查重复了工作并且一个接一个地运行。启动请求等待 Droid 的所有代码加载，第一个模型请求等待每个 MCP 服务器稳定。使用自己的 Amazon Bedrock 凭据的用户面临额外的延迟，而那些凭据正在加载。

在我们的最新更新中，这些等待时间都已消失或被解决。Droid 重用其连接的应用程序列表，直到连接更改，将每次交互的准备时间缩短到 24 毫秒。在受控测试中，仅此更改就将中位数响应时间提前了 13%。Droid 现在只读取会话历史中最新的部分，因此预检工具的查找大约需要一毫秒。登录检查并行运行而没有重复，从 101 毫秒减少到中位数 59 毫秒。droid exec 在其代码仍在加载时一起发送其身份、功能标志、组织策略和连接器请求，将中位数时间从 1,741 毫秒减少到 646 毫秒。MCP 服务器与第一次交互一起启动，因此一个需要 3 秒初始化的服务器不再拖延，并且 Bedrock 凭据在第一个请求之前就准备好了。除了用户的机器之外，我们在推理代理中修复了路由问题，从每个模型调用中减少了 150 毫秒。

这些结果在真实的生产代理交互中很明显。Droid 从输入到发送请求花费了 124 毫秒：97 毫秒收集上下文，27 毫秒构建它。这意味着模型请求负责用户在第一次获得标记时体验的 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 个模块不再在启动时解析。按键输入时启动完成，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 上，它比 Codex 使用的 token 少 12%，但耗时多 10%。

这些时间仅涵盖任务本身。在任务周围，Droid 打开、启动会话和退出的时间只有 8 月的几分之一，因此启动新会话或切换多个几乎不花钱。

尝试 Droid 1.0

Droid 1.0 今天可用。 下载桌面应用 用于 macOS 和 Windows，或 安装终端 UI。

要在相同的 harness 上构建，使用 Droid SDK (@factory/droid-sdk)。它运行与 CLI 相同的 Droid，因此本文中的每次改动都包含在内。从 Node，应用程序可以启动 Droid，保持多回合会话，流式传输其工作，并通过 MCP 给它提供自定义工具。从另一个进程或本地浏览器工具，它可以连接到正在运行的 Droid 守护进程并管理那里的会话。

方法学

• Head-to-head.
  • 使用的版本：[email protected]、[email protected]、[email protected]、[email protected]、[email protected]。
  • 使用的模型：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 的一些任务上，它选择提问而不是完成。为了保持比较公平，如果 Codex 通过了任务，Devin 停止提问的任务也被计为通过（每次试验平均 4.7 个任务）。这仅影响准确性，不影响成本或时间。
  • 光标在任务中途重新连接时会低估 token，因此对于发生这种情况的两个试验，我们从记录中估计了缺失的使用量。
  • 成本和时间按每个通过的任务计算，以每个提供者的列表价格为准。图表从左到右按成本从高到低排列。
  • Droid 一次与一个 harness 比较，使用相同的模型。
  • 我们仅计算两个 harness 在所有三次试验中都通过的任务，因此它们在相同的工作上被测量。
  • 成本基于使用的 token，按列表价格计算。
  • 时间是代理工作的时间，不包括设置或评分。
• Everything else.
  • 这里描述的每次改动都在生产 Droid 中运行。
  • 生产数据来自 Droid 自身的遥测数据，不包括 CI：提示重用、每周最新发布的启动中位数、退出时间和首次回合跟踪。
  • 提示重用按请求测量：从提供者缓存中读取的输入标记份额，在截至 10 月 22 日的 7 天内有 20.4M 个生产 Droid CLI 请求，不包括 CI 和评估。按标记而不是按请求加权，份额为 91.5%。仅追加是提示缓存监控器未标记的请求份额。
  • 与启动时间相关的某些指标来自控制测试，这些测试比较了在同一任务和机器上更改前后的构建。
  • 建模数字是 Script 示例的直接调用方面：低端每个请求 10 次调用，高端每个请求 3 次调用，每个请求大约有 28,000 个固定指令。

引用

工厂研究。"Droid 1.0：构建一个前沿 harness。" 工厂，2026 年 10 月。factory.ai/news/frontier-harness