软件工厂实战：用Codex与Claude Code搭建可评测的自我进化开发流水线

当模型、提示词、执行框架（harness）或技能集频繁更换时，一个现实问题摆在每个重度使用编程 Agent 的开发者面前：你无法判断这些改动究竟带来了多少实际收益。B站上分享的这套「软件工厂」方案，核心价值不在于替代本地编程 Agent，而在于提供一套可重复、可度量、可持续改进的工程流程。

据该视频作者 Owain Lewis 介绍，他同时以独立开发者和大企业工程师的双重身份工作，因此方案设计兼顾了单人与团队两种场景。

什么是软件工厂：把 Agent 编程变成可观测的流水线

作者对软件工厂的定义是：一套让编程 Agent 按既定流程运行的底层设施。你投入工作，系统每次都以完全相同的流程执行，并记录该次运行的全部指标与数据。

这解决了 Agent 编程中的几个典型痛点：

• 不必再手动管理 worktree、分支和本地环境配置
• 任务被委派后，系统负责排队、执行与回收结果
• 每一次运行都留下历史记录，便于纵向对比

他用 SSH 隧道的方式解决了安全与访问的矛盾：控制面与工作节点都运行在无公网入口的虚拟机上，本地通过隧道连接，既保持私有性，又不需要复杂的安全架构。这一点对独立开发者尤其友好——不用为安全付出额外的架构成本。

worktree 是 Git 的一项多工作树特性：同一个仓库可以检出多个独立的工作目录，每个目录对应不同分支，共享同一份对象数据库。对编程 Agent 而言，每个任务在独立 worktree 中执行，可以避免分支切换和未提交改动互相干扰，任务失败时也能直接丢弃整个目录。软件工厂把这套流程自动化，开发者无需再手动创建、切换和清理 worktree，这是它把「本地手工操作」变成「系统化流水线」的一个具体体现。

架构拆解：控制面与数据面

整个系统分成两层，这个划分是理解后续所有设计的基础。

控制面：工作的调度与观测中心

控制面负责任务管理。任务提交后被排队，完成后结果回流到控制面，形成可查询的仪表盘。从视频演示看，UI 中能看到已完成与进行中的任务列表，以及平均任务耗时（示例为 18 分钟）、累计 token 消耗（示例为 1500 万）等分析数据。

数据面：Worker 与执行器的分工

数据面由 Worker 组成。这里有一个常被混淆的区分：Worker 不等于 Agent 执行器（executor）。Worker 负责拉取任务、搭建环境、把任务交给对应的编程 Agent，再记录结果回传控制面。Worker 可以横向扩展——多台虚拟机、Kubernetes Job，甚至云实例池都可以。

执行器层则支持 Codex 与 Claude 等不同模型，模型列表在配置中显式声明。这意味着你可以把同一个任务交给不同执行器跑，用数据说话。

Kubernetes Job 是 K8s 中用于运行一次性任务的控制器：它创建一个或多个 Pod，确保指定数量的 Pod 成功终止后即视为完成，失败则按策略重试。Job 天然适合软件工厂的 Worker 场景——每个任务拉起一个 Pod 执行，结束后自动回收，按需扩缩。相比长期运行的虚拟机，Job 的调度粒度更细、资源利用率更高，但需要集群基础设施；作者将其列为 Worker 的可选扩展方式之一，正说明 Worker 层被刻意设计成与执行器解耦、可按环境替换。

工头模式：用统一提示词保证一致性

系统中每个任务都先交给一个「工头」（foreman）协调 Agent。工头负责拆解任务，并按固定顺序把子任务分派给子 Agent，直到完成代码变更、打上标签。

作者强调，这套流程连标签管理方式都被写进配置。当你修改工头提示词，后续每一个任务都会使用新版本——这正是「一致性」的来源。反过来说，如果每个开发者各自使用不同的提示词与技能集，团队层面就失去了任何可比较性。

系统中还配置了两类触发器：一类定期扫描代码库，用成本更低的模型做健康检查、发现缺陷并自动开单；另一类监听 GitHub 上的特定标签，一旦出现就自动把工作拉入工厂。这是工作进入系统的两条入口。

评测体系：让每一次改动都有据可依

这部分是整个方案最有价值的部分，也是作者的出发点。

工厂模式下，所有任务走完全相同的步骤序列，因此当你想换模型或调整提示词时，可以跑上几天、积累足够数据，再对比周期时间与任务完成率的变化。这是一种低成本的受控实验。

作者还提到一批「半确定性」评测：通过自动化检查与测试，验证标签是否正确、工作流是否被遵循。此外，每次运行都会产生结构化元数据，包括耗时、token 数、命令执行次数、Agent 轮次等，这些数据可以直接交给 Agent 解读。

一个具体案例很能说明问题：他让 Agent 通过 SSH 登录虚拟机，审查最近运行输出，寻找降低 token 消耗的提示词优化空间。Agent 分析后给出的建议是——把部分环节从「Agent 驱动」改为确定性的 Python 脚本，由脚本监控 CI 再委派给 Agent。脚本更便宜、更可预测、更易测试，输出结构也更稳定。

这个改进通过打标签的方式重新进入工厂，由 Agent 自行实现，然后再用数据验证效果。如果验证有效，同样的改动会被移植回本地开发环境。作者指出，由于他每天在每个任务上都复用同一套编程循环，这类改进的收益会被放大到全部工作中。

这种「分析运行数据 → 发现改进点 → 自动化实施 → 数据验证」的闭环，比单纯追求更强的模型更有长期价值。

部署与成本：虚拟机选型的现实考量

作者选择把控制面与 Worker 都部署在云上，理由是想把本地开发环境与 Agent 基础设施分开，也有助于更清楚地思考架构。

成本方面他给了具体对比：Google Cloud 伦敦区域的 E2 medium 约 32 美元/月（不含磁盘），同类配置在 Google Cloud 上也要接近 30 美元/月；而 Hetzner 的 Ubuntu 16GB 实例（赫尔辛基）明显更便宜。他本人的做法是——大头基础设施放在 Google Cloud，但对成本敏感的部分选择更实惠的供应商。当然，如果预算有限，本地运行完全可行。

数据库用的是 SQLite，配置项包括最大并发任务数、工头与审计任务的提示词定义、以及执行器与可用模型列表。作者强调执行器层是可扩展的，你可以接入任意编程执行器做对比实验。

团队场景：共享基础设施带来的杠杆

作者在数百上千名开发者的大型企业中工作过，对团队场景有明确判断：共享基础设施让所有人使用同一套工作流，任何一次提示词或配置的改进都会惠及全团队。

对比之下，如果每位开发者各自使用不同模型、不同 harness、不同提示词和技能，团队层面既没有一致性，也没有可重复性，改进几乎无从谈起。他把这类比为 CI/CD：系统级改进带来的是集体杠杆，而不是个体经验的零散累积。

适用边界：并非所有工作都适合进工厂

作者的态度相当克制。设计类工作、需要反复迭代探索的任务不适合放进工厂——这类工作需要贴近代码、快速来回、借助浏览器验证。他本人仍会在本地使用编程 Agent 处理这类工作。

工厂的典型场景是：把大量任务排队，安排在夜间批量执行，按顺序推进，第二天早上统一审阅结果。也就是说，本地 Agent 与软件工厂是互补关系，而不是替代关系。

对想要提升 Agent 编程确定性的开发者来说，这套方案给出的启示很清晰：先建立可观测的运行记录，再用数据驱动流程改进，最后把验证有效的改动固化进流程。工具选择反而是次要的。