10月29日，Factory发布了Droid 1.0，版本号同时推进到桌面端、命令行和SDK。这次没有新模型，改的是模型外面那一层。Factory自己给这层起了个名字叫harness，含义是包裹在模型外围的全部工程：提示词怎么组织、工具怎么定义、工具结果怎么回到上下文、整个循环怎么跑。它认为在长任务里，瓶颈往往不在模型，而在这层。
常规的智能体循环是一问一答式的：模型发起一次工具调用，结果被追加进上下文，模型再决定下一步。每一步都要重发完整的指令和不断变长的历史，一个需要几十步的任务跑下来，输入词元会被重复计费几十次。
Droid 1.0的做法是给模型一个Script工具。模型不再逐个调用，而是写一段JavaScript，在沙箱里运行，由这段程序去调用Droid暴露的工具。沙箱本身没有文件、网络和系统权限，唯一能碰到的就是Droid的工具集。原始文件、搜索结果、日志都作为变量留在程序内部，只有脚本打印出来的内容会回到模型上下文。
这个改动带来的不只是省钱。循环、过滤、条件判断和校验都变成了代码里的确定性逻辑，不再依赖模型"记得住每一个分支"。并发调用也自然成立，一批互相独立的调用耗时约等于最慢的那一个，而不是它们的总和。对需要扫描整个代码库、逐个文件比对许可证、或者把上百条记录按规则改写这类工作，这种差别是数量级的。
代价同样明确。模型必须会写这段程序，写错了整批调用都会失败，而失败信息往往只给你一句语法错误的行号。调试一个脚本比调试一次工具调用更难，因为它把"模型判断错了"和"代码写错了"混在了一起。Factory的应对是让脚本可以分步执行、把中间结果打印出来，但这仍然把一部分调试负担转移给了使用者。
Factory给的第一组数字来自它自己的项目管理系统：把151个issue从一个队列移到另一个队列，每个issue要校验15个字段，总计312次工具调用。按直接调用的方式估算，需要约36次模型请求和约310万输入词元；改用Script模式后是2次请求、约6.1万词元。
第二组是批量任务：547次运行共5384个测试作业，550次工具调用，每批60个。直接调用需要59到187次请求，Script模式同样只需2次请求，返回给模型的是一个五行摘要，里面标出41个失败作业，进入上下文的工具结果不到总量的千分之一。
第三个例子更贴近日常：修一个失败的单元测试。同样15次工具调用，直接调用用了10轮模型交互、耗时56.8秒，Script模式用了5轮、41.6秒，其中模型调用时间从42.3秒降到28.0秒。程序可以等最多5分钟再返回当前输出，也可以转到后台继续跑，完成时再唤醒模型，不需要轮询。
Factory在10月23日至28日之间跑了Terminal-Bench 4，同一模型对比不同harness。搭载GPT-6.1 Sol时，Droid通过率57.6%，每个通过任务成本0.79美元，官方称比Codex高3.5个百分点、成本低12%，但每个通过任务慢10%；搭载Claude Opus 5.5时通过率65.2%，每个通过任务4.73美元，比Cursor与OpenCode的62.1%、Devin的59.6%、Claude Code的57.6%高出3.0到7.6个百分点，成本最多低24%。
方法学部分有几处需要打折。Devin无法关闭"向用户提问"的工具，遇到它停下来提问的题目，只要Codex通过就算Devin通过，平均每个试验4.7道；Anthropic的内容审核拦下Opus 5.5的试验，被换到更早的Opus 5上重跑；每个任务三次试验，全部由厂商自己执行。没有任何第三方复现出现在发布报道里。
更值得注意的是一个纵向对比：同样用Opus 5.5，换一个harness，通过率能从57.6%走到66.4%。这个跨度说明在编程智能体这个品类里，"用哪个模型"和"用哪层壳"已经不是同一个问题，而后者的差异正在变大。
除了Script模式，1.0还做了几处工程优化。起始提示词从20887词元压到13055词元，降幅37%，主要做法是把11个工具定义改成只前置2个，其余按需加载。官方称生产环境中典型请求的输入有98%命中供应商缓存，而缓存文本的处理价格显著更低。
Script模式在Opus 5.5上让Droid的成本下降约15%，节省主要来自调用六次以上工具的长尾脚本。这个分布很关键：短任务几乎不受益，越是"要扫一遍全仓库"这类工作，收益越大。它对应的正是企业里最耗人力的那部分活。
Factory明确说这个思路不是自己发明的，公开承认来自2024年的CodeAct论文，并指出Cloudflare与Anthropic在2025年底把它带进生产环境，Codex今年把它带进了编程智能体。它押的注是把这个模式设为默认，而不是当成可选开关。
harness之争的落点很实际。团队通常在Anthropic、OpenAI和开源权重模型之间来回切换，每换一次就要重新适应各家自己的壳。一个模型无关、按模型族分别调优提示词与工具描述的中立壳，理论上能减少这种迁移损耗。Factory Router可以自动选模型，也支持用BYOK接本地端点。
但12%的成本差放在自己的代码库上可能被完全抹平，也可能被放大。最省事的验证方式是挑十个真实任务，在两个harness上各跑一遍，看通过率、总耗时和人工复核时间。一个下午就能得出结论，比读任何评测都可靠。真正需要留意的是复核时间这一项，harness跑得越快，单位时间内产出的改动就越多，人工审查会成为新的瓶颈。
这也带出一个组织层面的问题。当智能体能在一个请求里跑几百次工具调用，权限边界怎么划就成了绕不开的事。沙箱不给文件和网络权限是对的，但工具本身会触达真实系统，脚本一次调用几百个写操作时，回滚成本远高于逐次确认的模式。