从编码代理到软件工厂：Zach Lloyd 谈开发系统的改进与验证

一、嘉宾背景

在本期 Latent Space: The AI Engineer Podcast 中，Alessio Fanelli 与 Shawn “swyx” Wang 对谈 Warp 的 Zach Lloyd，讨论云端软件工厂需要怎样的基础设施，以及团队如何判断编码代理是否得到了有效使用。嘉宾资料将 Lloyd 介绍为专注软件工厂方向的 Warp 团队成员，未注明具体职务。

Lloyd 表示，软件工厂是他和 Warp 共同关注的方向。他的经验包括团队使用自身工厂开展开发、检查运行记录和调优成本的实践。访谈将架构解释、产品演示与内部经验结合在一起。他直接参与被讨论的平台，因此能够说明配置和工作流的细节；有关效果的陈述，也需要保留其作为平台参与者和内部实践者的来源属性。

贯穿访谈的是 Lloyd 对两类工程工作的区分：产品工程负责交付功能，工厂工程负责改进构建软件的系统。后者所需的工具、判断方法与责任边界，构成了这场讨论的主线。

二、本期主要内容

Lloyd 将软件工厂定义为运行在云端的代理系统：不同代理承担明确角色，拥有一定自主性，其行为可以测量，团队能够据此调优并开展基准比较。按照这个定义，大量使用代理只是起点。团队还需要知道系统如何配置、各个流程如何衔接，以及这些安排如何共同产生最终结果。

在 Warp 的实现中，一个工厂对应一个产品面，例如移动应用或服务端应用。仓库、技能、MCP 连接、外部集成和开发工作流都通过 YAML 声明，分诊、规格制定、实现等阶段大致沿用团队已有的开发流程。产品工程师可以通过 Slack、Linear、Jira、GitHub、API 或 MCP 提交工作；平台团队、DevX 团队和工程管理者则使用这些工具观察、优化代理开发。前者关注任务能否顺利交付，后者还需要查明交付顺利或受阻的原因。

演示中的移动应用任务从 Slack 发起，对话、代理执行轨迹和产物集中保存在一起，其中包括应用截图。Lloyd 希望记录能够覆盖团队的代理工作，而不局限于某位工程师本地终端中的一次会话。工作从哪里进入、代理如何执行、最终产生什么，都应有可供事后检查的记录。

工厂的测量指标包括交付耗时、吞吐量和每个已合并 PR 的人工介入次数，成本则可以按人员、自动化任务和开发阶段拆分。评分器用于进一步识别问题：平台提供通用标准，公司也可以定义自己的判定标准，对保存下来的代理对话进行事后评分。LLM 评判机制允许设置模型、提示词、运行范围和抽样率；抽样率也可用于控制评估本身的资源消耗。

在这套架构中，编排器只是一个组件。它负责推进工作流阶段、调用模型、加载技能和触发自动化，工作入口则把工厂连接到团队已有的工具。执行记录和测量能力使团队能够检查这些动作及其结果。Lloyd 所讨论的软件工厂，正是由这些相互连接的能力组成。

三、核心观点：推理、例子与边界

声明式配置让开发流程本身也能接受工程化改进。Lloyd 用 Terraform 作类比：配置纳入版本管理后，团队可以查看流程的历史版本，在分支上测试修改，并回滚失败的变更。编码代理也因此有了明确的修改对象，可以针对同一份工厂代码提出改进 PR。流程变更由此变得可表达、可审查、可比较，但一项修改能够写成代码，并不意味着它已经被证明有效。

跨工具记录则为故障诊断补足上下文。Lloyd 举例，一项工作可能从 Slack 进入 Linear，经过 GitHub 评审、合并与发布，最后出现服务器崩溃。如果只留下实现代理的一段对话，就难以判断问题出在需求理解、评审交互还是后续执行。将这些记录关联起来，调查者才能沿着结果追查过程。不过，记录只是调查材料；确定故障原因，仍需分析各个环节。

冗余测试是节目讨论的一种具体失败模式。Lloyd 观察到，代理探索实现方案时会编写测试，却有时在任务结束后留下不必要的部分，既使仓库膨胀，也浪费 token。针对这类行为建立评分器，比单看生成了多少代码更能反映维护成本。但测试是否必要，仍要结合仓库和任务判断。评分器可以提示维护者检查，不能单凭评分就决定删除测试。

改进代理的演示也有明确的验证边界。Lloyd 称，系统找到了 54 个分诊失败案例，认为如果允许分诊代理启动调查子代理，这些案例可能得到改善；代理还可以据此向工厂定义提交 PR。他随后明确表示，系统当时尚不能回放这些历史运行，以验证建议是否有效。因此，这 54 个案例说明系统提出了一项有针对性的改进假设，不能理解为已经挽救了 54 次失败，也不足以证明自主学习的完整闭环已经成立。

另一项能力是建立内部基准测试：从公司的真实代理任务中挑选案例，例如组成前端任务集，再比较不同模型与 harness 的组合。这里的 harness 指承载代理执行、工具使用等行为的运行框架。演示中的两种配置，一种正确率约为 95%、平均成本为 6 美元，另一种正确率为 93%、平均成本为 2 美元。这组结果呈现了质量与成本的具体取舍，但仅适用于演示任务集。缺少任务构成和评判细节，就无法据此给模型作普遍排名；能够重跑基准任务，也不代表前述改进建议已经自动经过历史回放验证。

Warp 的内部成本变化说明，调优对象包括模型选择、子代理数量和重复工作。Lloyd 称，使用过强的分诊模型、启动过多子代理以及重复执行任务，曾使每个 PR 的成本约为 80 美元；调整后降至约 15—20 美元。他还报告，最近一个月 PR 吞吐量提高约 40%，回滚率没有增加。这些数字来自他的内部经验陈述，节目没有提供样本量或受控比较，因而无法将吞吐量增长全部归因于某项配置，也不能视为对其他团队收益的承诺。它们提示团队，需要在完整工作流中衡量模型能力和代理数量带来的成本与效果。

这套系统的适用范围也有限。Lloyd 认为，对只有几个人的团队而言，它可能过于复杂；约五到十名工程师或许是开始适用的规模，而大型组织又需要投入更多实施工作。他还指出，高度定制的基础设施和强大的内部开发团队会影响采用，并以 Uber、Ramp 自建系统为例。这些是他对适用性的判断，并非统一的采购门槛。软件工厂能否改善交付，还取决于组织是否有足够多、足够重复的协调与优化需求。

四、学习与应用

沿用访谈中的方法，团队可以先选定一个产品面，将相关仓库、技能、MCP 连接和开发阶段写成可评审的工厂定义，并指定维护责任人。这是一种实施建议：有了明确的变更对象，才便于追踪流程调整及其影响。起步时不必覆盖整个组织，但需要将任务入口、代理运行、产物与最终 PR 联系起来，使团队能够检查执行过程、解释交付结果。

指标需要同时反映交付数量、成本和人工介入程度。按人员、自动化任务和开发阶段拆分成本，有助于发现分诊或某类自动化是否消耗过高；再结合交付耗时、吞吐量和回滚情况，判断成本下降是否伴随质量损失。对于冗余测试等失败模式，可以先以明确的提示词和有限抽样配置评分器，再检查其判断是否符合维护者预期。评分结果和改进建议都需要验证，生成了一份配置 PR，并不足以证明修改会带来收益。

模型与 harness 的选型，可以从真实历史任务组成的小型任务集开始，记录不同组合的正确性和成本。如果不同任务类型呈现出不同取舍，再考虑按工作流分别路由。评估平台时，还应分别核实两项能力：能否重跑基准任务，以及能否对每项改进建议自动回放历史运行、确认效果。Lloyd 已明确说明，后一环节当时尚未具备。

基础设施需要适应实际工作条件。不同部门可能需要不同的 MCP 访问权限，因此不能默认所有连接都向全员开放。计算层宜保持可替换；涉及 iOS 模拟器交互的任务，需要确认平台支持 Mac VM，仅有默认的 Linux 式沙箱并不足够。对于已有推理供应商承诺额度或自有兼容 harness 的团队，还应核实接入能力，让配置选择符合现有采购与运行条件。

工作入口可以优先采用团队已有的工具。Lloyd 提到，创业公司常见的工具组合有助于简化接入，服务器故障或用户反馈频道也可以将工作送入工厂，并让多名相关同事参与处理。实际采用时，可以先选定范围清楚的反馈类型，明确何时交给工厂、由谁确认结果。这是根据访谈提出的应用建议；节目并未证明所有频道都适合自动化处理。

团队规模、实施负担和计费方式也需要一并考虑。小团队可能通过直接订阅编码工具获得更合适的成本结构，高度定制的环境则可能需要承担更多接入工作。节目讨论了订阅相对 API 计费的价格优势，但这些差异不足以直接作为预算依据，尤其是 Lloyd 明确表示，他不知道轮换多个订阅是否被允许。决策前仍需核实实际可用的条款与费用，并将维护、评估和集成工作计入比较。

来源

• 原始节目：⚡️ The 2026 Software Factory Infra Stack — Zach Lloyd, Warp.dev