Zach Lloyd：让软件工厂可以衡量和修改

Warp 创始人兼 CEO、前 Google Docs 工程负责人 Zach Lloyd 将软件工厂描述为支持智能体开发的基础设施。他的演示使用 Warp 销售的工厂平台。

Lloyd 说，很多公司仍处于交互式提示阶段：工程师指挥本地智能体构建功能、修复错误。他们希望实现成本和治理可控的自动化开发，但人可能成为瓶颈。

他认为，受到攻击的本地智能体可能拥有与用户相同的权限，而每人各自配置的工具和技能也难以审计。他建议将智能体放进沙箱，并在云端运行。

在他的模式中，人提交工作，智能体参与分类、规格制定、实现和验证。组织需要定义人和智能体如何互动，再持续衡量和改进工作流。

Lloyd 建议把工厂视为基础设施：支持不同模型和智能体框架，适配现有系统。用版本控制的代码定义工作流、技能、工具和运行环境，便可测试不同版本，也能让智能体提出修改。

他说，大型客户希望控制输入输出数据、基础设施和推理服务，并能选择模型与框架。他把这称为 AI 主权，认为企业应该掌握系统的核心组成部分。

Lloyd 认为，公共基准不足以决定哪个模型适合特定组织。团队应记录真实任务、评估智能体运行、利用结果发现失败模式，并基于自身工作建立比较不同配置的基准。

他区分了两种工作：产品工程师通过工厂构建功能和修复错误；工厂工程则改进技能、上下文和模型选择，让系统本身表现更好。平台团队或产品工程师都可以承担后者。

在 Warp Factories 演示中，Lloyd 展示了供管理者查看生产力、自动化程度、周期和支出的视图。系统保存智能体运行、对话和产物，作为检查和改进流程的材料。

工程师可以通过已有工具提交工作，例如 Slack、Linear 或 GitHub。Lloyd 说，工厂会集中收集工作并保留上下文。编排智能体再把任务引向分类、规格、实现或审查等步骤。

工厂仓库保存智能体定义、自动化配置、基准、运行设置、技能和 webhook。Lloyd 说，对这些定义进行版本管理，可以测试并自动化改进系统本身。

Warp 使用评分智能体检查已完成的运行，其中包括检测冗余测试。Lloyd 将其称为在线评估：发现的失败可以成为改进流程的线索。演示中的评分由语言模型充当裁判。

自我改进循环会汇总反复出现的失败、寻找模式，并提出对工厂定义的修改。在一个示例中，系统发现智能体未阅读相关技能导致 37 次失败，并建议通过 pull request 解决。

Lloyd 建议从过去的代表性任务建立基准，再用不同模型配置重放。团队可以针对自己的代码和工作流比较质量与成本，而不是只依赖公开排行榜。

在他的示例中，GLM 5.3 Flash 的得分约为 93%，成本约 2 美元；GPT 5.6 Sol 得分约为 95%，成本约为前者三倍。这些分数针对展示的内部任务集；Lloyd 随后说明评分由模型裁判完成。

Lloyd 将工厂技术栈概括为：代码中的工厂定义、数据和上下文、沙箱计算、灵活推理、衡量与改进、编排，以及通过现有工具接入。

被问到如何验证时，Lloyd 建议使用可用于检查改动的规格，以及从用户视角生成证据的计算机操作验证。他认为这些方法可以减轻大量生成的 pull request 带来的审查负担。

关于预算规划，他建议衡量每个 pull request 的成本，区分用于评分和基准测试的比例，再估算项目开支。他最主要的建议是建立一个能够衡量和改进的流程。

关于基准数据整理，Lloyd 建议先手动挑选具有代表性的小、中、大难度任务。保存了会话记录的工厂也可以推荐要纳入的历史运行。他说，演示中的正确率图表使用大语言模型裁判；人工评分也合理，但当时尚未加入。

有人询问 Warp Factories 是否开源。Lloyd 说它不是开源的，但支持接入现有工具，也不限于企业用户。他认为平台更适合团队，对个人来说可能过于复杂。