Factory发布跨模型编程Agent框架

Factory 发布的 Droid 1.0，把编程 Agent 的改进重点放在了模型周围：工具怎么调用、结果怎么回传、循环什么时候停。它默认让模型先写 JavaScript，再由程序批量执行工具，减少模型反复读取中间结果的开销。

Factory 自测显示，这套方式能降低部分任务的成本，并提高同模型下的任务通过率。但它没有全面领先：搭配 GPT-6.1 Sol 时，Droid 每个通过任务的耗时比 Codex 长 10%。值得读的，是这些收益从哪里来，以及哪些数字不能直接套到自己的项目上。

让程序处理工具结果，为什么能省钱

原文把 harness 定义为模型周围的整套执行框架，包括提示词、工具、结果回传方式和运行循环。Droid 1.0 的核心变化，就是默认启用程序化工具调用（programmatic tool calling，PTC）。

传统循环通常是模型调用工具、读取结果，再决定下一步。搜索命中、日志、文件内容不断进入上下文，即使最后只需要其中几行，也得先交给模型处理。

Droid 的 Script 工具改了这条路径：模型编写 JavaScript，在沙箱里编排工具调用，程序负责筛选、统计和汇总，只有打印的输出返回模型。互不依赖的调用可以并发执行，一次模型请求可以驱动数百次工具调用。

省下来的主要是模型读取中间材料、反复决定下一步的开销。

沙箱自身没有文件、网络或系统访问能力，需要通过提供的工具完成操作。这不代表整个 Agent 不能访问这些资源，而是执行程序和工具权限之间有边界。原文称，这条路线建立在 CodeAct（Wang 等，2024）的思路上。

Factory 给了三组内部案例：

• 修复单元测试时，同样执行 15 次工具调用，模型调用从 10 次降到 5 次，耗时从 56.8 秒降到 41.6 秒。
• 整理 Linear 时，移动并验证 151 个 issue，执行 312 次工具调用；Script 使用 2 次请求、约 61,000 tokens。直接调用对应的 36 次请求、约 310 万 tokens，则是 Factory 的估算。
• 扫描 CI 时，2 次请求处理了 547 次运行中的 5,384 个 job，进入模型上下文的工具结果不到 0.1%。

三组数字的证据强度不同，尤其不能把 Linear 的估算当成两种模式都实际跑过。Factory 还称，在 Claude Opus 5.5 上，Script 比直接工具调用降低成本 15%；该模式已对 10 个模型默认开启，包括 GPT-6.1 Sol 和 Kimi K3。

同一个模型换执行框架，成绩能差多少

Factory 在 Terminal-Bench 4 上固定模型，对比不同 harness，每个任务运行 3 次，测试时间为 2026 年 10 月 23 日至 28 日。

使用 Claude Opus 5.5 时，Droid 通过率为 65.2%，Cursor 和 OpenCode 均为 62.1%，Devin 为 59.6%，Claude Code 为 57.6%。Droid 每个通过任务的成本为 $4.73，原文称相比对手最多低 24%，耗时减少 16% 至 26%；相比 Claude Code，tokens 用量还少 17%。

换成 GPT-6.1 Sol，Droid 为 57.6%，每个通过任务 $0.79；Codex 为 54.0%，OpenCode 为 51.0%，Devin 为 45.0%。不过，Droid 的每个通过任务耗时比 Codex 长 10%。

这里有一个影响解读的统计口径：成本和耗时只统计双方都在 3 次试验中全部通过的任务。 它能帮助比较共同成功任务的执行效率，却不能代表完整任务集的总账单，因为失败尝试的开销没有体现在这一指标里。

这些也都是 Factory 自己报告的结果。固定模型有助于观察执行框架的作用，但不能据此断言，自家仓库里的页面开发、Node 服务维护也会获得相同比例的提升。

除了 Script，哪些细节也在影响成本

Droid 的基础提示词从 20,887 input tokens 缩到 13,055，减少 37%；初始携带的工具定义从 11 个减到 2 个，低频工具按需加载。原文另称工具定义减少 46%，但没有解释这一比例与工具数量变化分别采用什么口径。

缓存也做了配合：新加载的工具追加到请求末尾，减少对已有前缀的扰动。Factory 称，典型生产请求有 98% 的输入从缓存读取。这个数字描述的是缓存读取比例，不能直接当成总费用降低比例。

运行循环增加了限制：连续出现 3 次相同工具调用会收到提醒，达到 6 次就停止；上下文压缩摘要则从 8,000 tokens 扩大到 16,000 tokens。前者限制重复消耗，后者试图保留更多任务信息，是否足够仍取决于摘要质量。

桌面应用的首屏绘制从 1,839 ms 降到 488 ms，每增加一个会话的内存开销从约 350 MB 降到约 20 MB。它们改善的是使用体验，不能混进模型推理速度的收益里。

这些改进多数来自内部 Agent Factory 循环：Agent 读取失败、提出修改，在受影响的模型家族上测试，再由工程师审查合并。原文没有给出这套流程的独立收益数据。

我的判断

我认同它优先优化工具结果回传的方向。对于批量检索、日志筛选、CI 检查，很多中间步骤本来就适合用程序完成。让模型看到筛选依据和必要结果，比反复塞入整份材料更有成本上的合理性。

前提是任务能被拆成明确操作。程序筛错日志、汇总时丢掉异常，也会让模型在不完整的信息上继续判断。原文没有展示这类失败的频率和处理方式。

常见替代做法是先写固定脚本，再让 Agent 调用。固定脚本便于审查和复用；Script 更适合临时组合操作，但对模型生成编排逻辑的可靠性要求更高。文章没有两者的对照数据，这里的取舍仍属于工程判断。

模型独立和自带 API key 提供了选择空间，不保证每个模型都有相同表现。采购时还要区分 SDK 与完整产品：SDK 是 Apache 2.0，完整 harness 的许可证原文未披露，付费计划从 $20/月起。

能拿来做什么

• 如果日常 AI 编程经常卡在测试日志和 CI 排查，可以先把结果统计、失败项过滤交给脚本，再让模型分析保留下来的证据，并保留查看原始输出的入口。
• 如果正在开发 Node Agent，可以研究 @factory/droid-sdk，它提供同一套 harness 的会话、流式输出和 MCP 工具接入；Droid 也提供 macOS、Windows 桌面端和终端界面。
• 如果要比较 Droid 与现有工具，就用同一模型跑自己的真实任务，同时记录成功率、总费用、失败开销和耗时，分别判断它是否适合交互开发与批量维护。
• 如果维护自己的工具调用循环，可以借鉴重复调用提醒和停止机制，同时检查压缩摘要是否保留了约束、已完成操作及未解决错误。