30 秒看懂
Zach Lloyd 与 Shawn Wang 共同演示 Warp 的软件工厂方法。他们讨论流程即代码、轨迹、评估、基准测试、模型成本、基础设施分层,以及不同规模团队面临的取舍。
- 1工厂即代码Lloyd 定义了包含明确智能体角色、工具和阶段的可衡量云端流程。
- 2衡量结果演示跟踪吞吐量、人为互动、成本和智能体行为。
- 3用真实工作做基准团队可以重放有代表性的任务,比较模型和 harness。
- 4调整成本Lloyd 报告 Warp 调整自身配置后的内部成本与吞吐量变化。
- 5适合团队规模他说,对于非常小的团队,这套基础设施可能过于复杂。
要点建议
- 以版本化代码定义智能体流程、工具和集成,让修改可供审查。
- 尝试优化系统之前,先收集轨迹和任务结果。
- 用具有代表性的工作比较模型和 harness,同时衡量成本与正确率。
- 完整的软件工厂会增加开销,可能不适合非常小的团队。
按章节阅读整理后的全文
定义软件工厂
Lloyd 介绍智能体角色、流程即代码以及从现有工具接入。
Shawn Wang 请来 Warp 的 Zach Lloyd,讨论为使用编程智能体的团队提供云基础设施的软件工厂。Lloyd 说,他希望让这一概念具体且可衡量,而不是把它当成“更多使用智能体”的模糊标签。
Lloyd 将软件工厂定义为云端智能体系统,其中明确规定了为产品开发软件的角色和工作流程。系统具有一定自主性,但团队应能持续衡量、调整并对其进行基准测试。
企业常常带着彼此割裂的自动化流程而来。Lloyd 认为工厂本身应以代码定义,包括代码仓库、技能、MCP 集成和工作流程。Warp 的平台为移动应用或服务端应用等产品界面设置对应工厂。
工作流程可以包括分诊、规格制定和实现。Warp 用 YAML 文件表示配置。Lloyd 区分了提交工作和交付功能的产品工程师,以及负责设计和改进工厂本身的人员。
工作可以从 Slack、任务跟踪工具、GitHub、API 或 MCP 进入。不管入口是什么,任务都会启动一个预先定义的流程。Lloyd 的目标是把这些不同活动纳入一个可观察的系统。
可观察性与评估
演示收集轨迹,并使用指标和自定义评分器查找失败模式。
系统收集智能体对话、产物和轨迹。演示中,Lloyd 展示了一个从 Slack 发起的移动应用任务,包括对话、计算机操作截图和智能体执行的步骤。跨任务的记录可以为改进提供数据。

团队可以查看交付时间、每个已合并拉取请求的人为互动次数、吞吐量和成本。Lloyd 说,Warp 使用每个 PR 的成本,并按人员、自动化流程或开发阶段拆分支出,寻找调整模型和工作流程的机会。
另一层用于评估智能体行为。Warp 提供通用评分器,团队也可以为导致构建失败等特定问题定义自己的评分器。这些规则可定制,并以代码表示。
一个例子是查找智能体探索解决方案时编写、之后却遗留的冗余测试。大模型评委根据提示词检查抽样的历史运行记录。抽样率很重要,因为运行评委本身也有成本。
Wang 问这些视图由谁使用。Lloyd 说,使用者通常是工程经理、CTO、开发者体验团队或平台团队,而不是每一位日常工作的产品工程师。
他说,一般原则并不限于 Warp:保存相关工作,使其可观察、可衡量。这样团队便能根据自己的任务比较模型和 harness,而不是只依赖印象或社交媒体推荐。
改进与基准测试
智能体可以提出流程修改,任务重放则用于比较模型与 harness 配置。
单独的改进循环可以检查失败评分并提出修改。在一个例子中,系统找到了可能因使用子智能体而受益的分诊案例。由于工厂配置是代码,智能体可以提出修改配置的拉取请求。
Lloyd 说,下一步计划是重放历史案例,检验建议的修改是否真的有帮助。他将重放功能描述为未来工作,并非演示时已具备的能力。
进行基准测试时,团队可以整理真实任务,例如前端改动,再用不同模型和 harness 的组合重放。Lloyd 说,平台除了支持 Warp 自己的 harness,也支持与多个外部 harness 比较。

示例图将正确率与平均成本对应起来。Lloyd 比较了一个约 95% 正确率、每项任务 6 美元的配置,以及一个约 93% 正确率、2 美元的配置。这些数字只适用于演示任务集,屏幕也提示部分评分尚不完整。
团队可以利用自己的基准结果,将任务路由到不同模型或 harness。Lloyd 称之为工厂工程:将智能体配置视为一个工程系统,而不是猜测哪种配置最好。
基础设施技术栈
技术栈包括版本化定义、记录、访问控制、计算、推理和编排。
Wang 询问工厂背后的基础设施技术栈。Lloyd 从以代码声明式定义开始,将其类比为基础设施即代码。版本控制让团队能够创建分支、测试和回滚流程修改,智能体也可以提出改进。
下一层收集跨工具的对话、产物和交互。任务可能从 Slack 开始,在跟踪工具中继续,产生 GitHub 审查,最终甚至引发生产事故。完整记录可以帮助人或智能体调查问题原因。
系统还需要集成和访问控制。大型组织可能需要为市场、销售和工程团队设置不同权限。Lloyd 强调,组织要求越多,部署就越复杂。
他建议把计算资源视为可插拔的一层:团队可以选择不同沙箱供应商或平台。Linux 沙箱能覆盖许多任务,而 iOS 工作流程可能需要 Mac 虚拟机和模拟器。
推理服务和 harness 也可以替换。Lloyd 说,客户可以使用已有的模型供应商额度、通过 Warp 购买推理,或使用兼容的外部 harness。目标是在模型和工具变化时保持灵活。
对于改进层,Lloyd 报告说,Warp 通过调整模型选择和避免冗余子智能体工作,将内部每个拉取请求的成本从约 80 美元降至 15 至 20 美元。他说一个月内吞吐量提高了 40%,测得的回滚率没有上升。
编排器读取工厂定义并推动工作经过各阶段,调用模型、技能和自动化流程。Lloyd 将它视为平台的一个组成部分,而非整个平台。
最后一层是入口:人们应该能从已有工具启动工作。Lloyd 说 Warp 内部很大一部分工作从 Slack 开始,但任务跟踪工具、终端、API 或 MCP 也都可以作为入口。
谁需要它?
两人讨论团队规模、定制基础设施、订阅经济性和工程角色。
Wang 问团队是否真的需要所有这些层。Lloyd 说,只有几个人的团队可能觉得完整工厂过于复杂,应使用更简单的工具。他提出大约五到十名工程师可能是一个下限,同时指出是否适合取决于具体团队。
大型公司通常拥有更多定制基础设施,需要更多实施工作。一些使用常见协作和任务工具的成长型团队可能更容易设置。共享记录可以将反馈、事故和合适的同事连接到工作中。
被问及最有力的批评时,Lloyd 提到实施适配和经济性。拥有大型内部开发平台的公司可能自行构建系统,而小团队可能发现订阅工具更加经济。
两人讨论了订阅价格与按 API 用量计费可能存在的巨大差异。Lloyd 说,他不知道企业使用多个订阅的每一种做法是否都被允许;经济性和适用条款取决于具体供应商和方案。
Lloyd 说,Warp 将其工厂产品定位为优化和生产力平台,而非转售 token。他认为模型供应商的定价对独立编程智能体企业构成艰难的竞争挑战。
在即将举行的演讲中,Lloyd 计划区分产品工程和工厂工程。后者需要培养改进辅助构建软件的系统所需的技能和工具,与直接构建产品的工作并行。
同频道的其他文章
1:12:24EN → 简体中文
1:07:22EN → 简体中文
27:34EN → 简体中文
26:05EN → 简体中文
1:16:38EN → 简体中文
1:46:40EN → 简体中文