⚡️ 2026 年软件工厂基础设施技术栈 — Zach Lloyd, Warp.dev

摘要

• Lloyd 的软件工厂是一层独立的基础设施，用于在公司范围内管理智能体开发。 其基本单元是“每个产品界面一座工厂”，把代码仓库、技能、集成和工作流都写进代码。集中记录运行轨迹，让绩效可衡量；算力、推理和智能体运行框架都可插拔，企业无需重建整套系统就能替换组件。
• Warp 表示，过去一个月每个 PR 的成本从约 80 美元降至约 15–20 美元，PR 吞吐量提高 40%，回滚率没有上升。 Lloyd 将成本下降归因于分诊时改用比 Opus 更便宜的模型，以及减少智能体的重复劳动和过多的子智能体。他的运营原则是“观察、衡量、调优”。
• 私有基准测试能把模型选择转化为可衡量的成本与正确率权衡。 Lloyd 举例称，GPT-5.6 Sol 的正确率为 95%，每项任务约 6 美元；GLM-5.3 Flash 的正确率为 93%，每项任务 2 美元；展示的模型已经略显过时。把测试框架与模型一并评测，可以针对各公司的工作流做路由选择，摆脱“凭感觉”。
• 将工厂写进代码后，智能体也能提出对生产系统本身的改进。 Warp 的自我改进智能体发现，有 54 次分诊失败本可通过启用调查型子智能体来避免，并提出了配置变更。用历史运行记录回放来验证改进建议仍在规划中：“我们还没有做到这一步。”
• 最明确的客户，是共享工作量足以支撑平台的成长型工程组织。 Lloyd 暂定门槛约为 5–10 名工程师；拥有 10–100 名工程师的公司，如果使用常见集成，采用过程可能相当简单。只有几个人的团队，他的建议是“别这么做”；Uber 或 Ramp 这类基础设施高度定制的公司则面临另一种障碍，因为它们会自己搭建系统。
• 在 Lloyd 看来，订阅补贴让纯编码智能体业务很难做。 Swyx 称，API 计费可能贵 5–50 倍，并举例说，200 美元的订阅对应 8,000 美元的 API 用量。Lloyd 表示，“如果能这么做”，订阅会是最便宜的选择，但他不知道轮换使用订阅是否合规；Warp 的商业定位是优化和提升生产力，而不是“转售 token 的产品”。

精读

1. 软件工厂要把工作流写进代码，才能落地

• Lloyd 将软件工厂定义为一种云端智能体系统：角色明确，具备一定自主性，团队可以“调优、衡量、做基准测试”。他反对把零散自动化随意串起来，因为那样没有具体对象可供评估。Warp 的基本单元是“每个产品界面一座工厂”：一款移动应用或服务器应用，以及对应的代码仓库、技能、MCP 集成和分诊、需求规格定义、实现等工作流阶段。
• Terraform 的类比解释了底层逻辑：用 YAML 声明工作流，再借助版本控制管理版本、开分支测试，并在必要时回滚。编码智能体随后可以提出对工厂本身的改动。配置本身由此成为推动生产流程持续改进的对象。
• 这套模式将分工拆成两部分：产品工程师通过工厂交付功能，工厂工程师则负责改进工厂的运作方式。Lloyd 将后者称为“打造构建软件的系统”。运营仪表盘主要面向平台或 DevEx 团队、工程经理和 CTO，而不是普通工程师日常使用的界面。

2. 集中记录运行轨迹，让智能体的质量和经济性可衡量

• 集中记录之所以重要，是因为一个任务可能从 Slack 开始，在 Linear 里继续，经过 GitHub 评审并合并，之后还可能引发服务器崩溃。把对话、工具交互、产物和计算机操作截图放在一起，智能体或人工就能从故障往回追溯。Lloyd 表示，如果员工各自在本地运行 Claude Code 或 Codex，公司通常不会留下这类共享记录。
• 衡量体系结合 DORA 式交付指标、吞吐量、成本，以及每个已合并 PR 所需的人工介入次数。成本需要按人员、自动化和 SDLC 阶段拆分，才能找出在哪些环节更换模型或技能可以降低每个 PR 的成本。Lloyd 的目标是摆脱“凭感觉”（the realm of vibes），转向可衡量的评估。
• 评分器结合默认检查项和公司自定义的失败模式，通过 LLM 评判器、评分提示词和抽样率来控制评估成本。一个具体问题是：智能体在摸索实现方案时会写下不必要的测试，之后却没有清理，导致代码仓库膨胀、token 浪费。谈到评分能力时，Lloyd 承认：“这方面我们还有很多工作要做。”
• 基准测试会把公司精选的任务放到不同模型和运行框架上回放，包括 Warp 自家的框架、Claude Code、Codex 和 Pi。演示中的结果已经略显过时：GPT-5.6 Sol 的正确率为 95%，每项任务约 6 美元；GLM-5.3 Flash 的正确率为 93%，每项任务 2 美元。这样的权衡可以指导企业根据自身工作流和代码库选择模型或运行框架。

3. 自我改进能提出方案，但还不能证明方案有效

• 自我改进智能体会检查评分失败案例，并提出对工厂定义的修改。有一个智能体发现，54 次分诊失败本可通过启动调查型子智能体来避免。由于工厂本身就是代码，智能体可以直接针对配置提交 PR，让改进建议成为可供评审的软件变更。
• 回放验证这一步尚未完成。Lloyd 希望用历史任务测试每项建议改动，检查它是否真的能改善结果，但他表示：“我们还没有做到这一步。”提出改进建议和证明改进能解决过去的失败，是两项不同的能力。
• Warp 自己调优后，每个 PR 的成本从约 80 美元降到“20 美元或 15 美元左右，差不多这个量级”。Lloyd 提到的浪费来源包括：分诊时用了其实没必要的 Opus、智能体配置造成重复劳动，以及启用过多而非更少的子智能体。过去一个月，PR 吞吐量提高 40%，测得的回滚率没有上升，这也让他更相信“观察、衡量、调优”（observe, measure, tune）这套原则。

4. 基础设施保持模块化，并从现有工具接入

• Lloyd 认为，编排器只是平台的一层，而不是平台本身：它执行声明好的阶段、调用模型、加载技能并触发自动化。周边基础设施还需要具备数据访问和组织权限管理能力，包括为市场、销售和工程团队配置不同的 MCP 访问权限。
• 算力环境应该可以替换。Warp 主要使用 Namespace，但 Lloyd 希望沙箱供应商可以插拔，并提到 Daytona、Modal 和 E2B。默认环境可能是 Linux；测试 iOS 应用则需要运行模拟器、实际操作应用的 Mac 虚拟机。平台必须适配任务所需的环境。
• 推理和智能体运行框架也应保持开放。企业可能已经承诺在 Anthropic、OpenAI 或 Google 消费一定额度，因此 Warp 允许客户接入自己的推理服务，也可以通过 Warp 购买。平台还支持 Pi 等外部运行框架，以及其他兼容 ACP 的选项。
• 接入方式应顺着现有工作习惯走：Warp 约 60% 的工作从 Slack 开始，但任务也可以从项目跟踪工具、GitHub、API 或 MCP 进入。工程师可以先在本地 Claude Code 里完善规格，再提交给平台。Lloyd 设想的是“无头基础设施”，既能接收崩溃告警或客户反馈，也能拉上熟悉相关代码的团队成员共同处理。

5. 团队规模和推理补贴决定商业适配度

• Swyx 提出的现实问题是：B2B SaaS 的 CTO 是否真的需要这么多层基础设施？对于几个人的团队，Lloyd 的建议是“别这么做”，直接使用 Claude Code 或 Codex 的订阅服务。他认为适用门槛可能在 5–10 名工程师左右；对 10–100 名工程师的成长型公司，如果使用 Slack、Linear 或 Jira 这类常见工具组合，部署可能相当接近自助式。
• 规模扩大也会带来集成成本：大型组织不应指望完全即插即用。Uber 或 Ramp 这类基础设施高度定制、内部开发团队规模庞大的公司，并不适合 Warp 的产品，因为它们会自己构建系统。Lloyd 进一步预测，大多数公司都会拥有类似的基础设施，位置就在 CI/CD 的下一层。
• 订阅补贴让经济账更复杂。Swyx 称，API 计费可能贵 5–50 倍，并对比了一档 200 美元的订阅和 8,000 美元的 API 用量；他还提到有人轮换使用 17 个订阅。Lloyd 说，“如果能这么做”，订阅会是最便宜的选择，但又表示：“我很难想象这会被允许”，“我确实不太清楚”。他还认为，这种做法无法规模化。
• Lloyd 希望 Warp 不落入“纯编码智能体业务”：如果底层推理成本高出太多，独立智能体就无法竞争。谈到 Cursor 时，他说：“我觉得他们找到了完美的退出方式，转型成了一家模型实验室。”Warp 的商业定位是编码智能体优化与生产力平台，从而避开“转售 token 产品”的经济模式。