Factory Droid 1.0：模型无关编程Agent的脚本模式突破

Factory 发布了 Droid 1.0，一个将程序化工具调用设为默认机制的模型无关编程 Agent 框架。在 Factory 自家的 Terminal-Bench 4 测试中，搭配 Claude Opus 5.5 的 Droid 取得 65.2% 的得分，每个通过任务的成本为 4.73 美元。

编程 Agent 的工具调用困境与解法

当前主流编程 Agent 大多依赖模型逐个发起工具调用，每一步都需要模型推理并返回结构化请求，再由外部框架解析执行。这种来回交互的模式在简单任务上尚可接受，但面对需要数十次工具调用的复杂编程场景时，延迟叠加和上下文膨胀会显著拖累效率。

Factory 给出的答案是"脚本模式"——让 Agent 以编写代码的方式批量组织工具调用，而非逐个请求。Droid 1.0 将这一模式设为默认行为，意味着 Agent 在规划阶段就会倾向于生成可执行的脚本片段，一次性完成多步操作。这与传统 function calling 的路径有本质区别：后者把每次调用当作独立事件，前者则把调用序列当作一段可编译执行的程序。

这种设计思路并不陌生，此前已有研究探索过代码作为 Agent 行动媒介的潜力。但 Droid 1.0 的独特之处在于将其工程化为一套完整的产品级框架，并且明确宣称模型无关——不绑定特定厂商的模型能力假设。

Function Calling（函数调用） 是大模型与外部工具交互的主流机制：模型根据用户意图，输出一段结构化的 JSON，指明要调用的工具名称和参数，由外部框架解析并执行，再把结果回传给模型继续推理。它的优点是清晰、可控，每一步都可审计；缺点是每次调用都需要一次完整的模型往返。对于需要几十步操作的编程任务，这种“一次一问一答”的模式会累积大量延迟，并让上下文窗口被反复的工具结果填满，既拖慢速度也推高 token 成本。

“代码即行动”（Code as Action） 是一类让 Agent 用编写代码来代替逐次工具调用的思路。代表性研究包括 CodeAct 等工作，其核心观察是：代码本身具备循环、条件分支、变量复用和中间结果保存的能力，模型可以用一段脚本表达原本需要多次调用才能完成的操作序列。相比 function calling，这种方式的优势在于减少模型往返次数、把中间状态留在执行环境而非上下文窗口里，从而同时降低延迟和 token 消耗。Droid 1.0 的“脚本模式”正是这一思路的产品化落地。

模型无关意味着什么

"模型无关"这个定位值得拆开看。编程 Agent 框架通常深度耦合特定模型的工具调用格式、上下文窗口特性和推理风格，换模型往往意味着重新调优提示词和执行逻辑。Droid 1.0 声称打破这一限制，理论上允许用户在不同模型之间切换而无需重构 Agent 行为。

从 Terminal-Bench 4 的测试配置来看，Factory 选择 Claude Opus 5.5 作为参考模型，并公布了每任务成本。这个细节透露出两层信息：其一，脚本模式的效率优势可能部分来自减少模型往返次数，从而降低 token 消耗；其二，成本数据被作为核心指标公布，说明 Factory 认为编程 Agent 的经济性正成为竞争焦点。

说一下，单一基准测试和单一模型配置无法完整验证"模型无关"的普适性。不同模型对脚本生成的理解能力差异、对长上下文脚本的容错表现，都会影响实际体验。Factory 目前披露的数据仅覆盖一个测试场景，跨模型对比数据尚未公开。

Terminal-Bench 4 成绩的解读边界

65.2% 的通过率和 4.73 美元的单任务成本，放在编程 Agent 的评测语境中是一个有参考价值但不宜过度解读的数字。Terminal-Bench 系列聚焦终端环境下的任务完成能力，与真实开发工作流存在差距——真实项目中的需求模糊性、代码库规模和环境依赖复杂度，都不是基准测试能完全模拟的。

成本指标的呈现方式也值得注意。"每个通过任务"的成本意味着失败任务的消耗被分摊进成功任务中，这个口径对评估实际使用成本有帮助，但不同任务难度分布下的可比性有限。若基准任务集偏向中等难度，成本数字可能偏乐观。

从行业趋势看，编程 Agent 的竞争正从"能不能做"转向"做得多快多省"。Droid 1.0 把成本作为发布亮点，呼应了这一转向。脚本模式在理论上具备减少交互轮次、压缩上下文占用的优势，这与成本优化目标一致。

Terminal-Bench 是一个面向终端环境的 Agent 评测基准，任务通常要求在命令行中完成文件操作、代码修改、环境配置、脚本调试等操作，由自动化的验证脚本判定任务是否通过。它比纯问答类基准更贴近真实工程场景，但仍然是在受控的容器环境中运行，任务描述相对明确、代码库规模有限。因此其得分可以横向比较不同 Agent 的终端操作能力，却难以直接外推到大型遗留代码库、多服务协作或需求含糊的真实开发流程。

程序化工具调用的工程挑战

把工具调用写成脚本，听起来简单，工程落地却有不少坑。脚本需要被执行环境安全地解析和运行，工具接口需要被抽象成可供脚本调用的函数签名，脚本执行失败后的回滚和重试逻辑也要重新设计。传统逐次调用的错误处理相对局部，脚本模式下一次执行可能涉及多个工具，部分失败的状态管理复杂度更高。

另一个隐性挑战是调试体验。当 Agent 生成的脚本出错时，开发者需要理解脚本逻辑、定位失败的工具调用、判断是模型生成问题还是工具接口问题。这套调试链路比单步调用更复杂，框架需要提供足够的可观测性才能让开发者接受这种模式。

Droid 1.0 将脚本模式设为默认而非可选项，说明 Factory 对这一模式的稳定性有相当信心。但默认设置也意味着用户需要主动适应新的交互心智模型，这对早期采用者构成一定门槛。

对开发者的实际意义

对于正在评估编程 Agent 工具的团队，Droid 1.0 提供了一个值得关注的方向性样本：工具调用范式正在从"模型驱动逐步请求"向"模型生成可执行程序"迁移。这一迁移如果被验证有效，会改变 Agent 框架的设计重心——从优化单次调用的提示词，转向优化脚本生成的质量和执行的可靠性。

模型无关的承诺则关乎长期灵活性。在模型能力快速迭代的当下，把 Agent 框架与特定模型解耦，理论上能降低迁移成本。但这一承诺的实际兑现程度，需要等更多跨模型测试数据出现后才能判断。

Factory 此次发布的信息密度并不高，核心数据集中在一个基准和一个模型配置上。Droid 1.0 的脚本模式究竟在多大范围的任务类型上优于传统调用方式，多模型切换下的表现一致性如何，这些关键问题仍待更多独立评测来回答。