本文永久链接 – https://tonybai.com/2026/07/27/why-software-factories-fail-harness-engineering-not-enough

大家好，我是Tony Bai。

导读：

当“75% 的代码由 AI 生成”成为行业炫耀的资本时，HumanLayer 创始人 Dex Horthy 却在 AI Engineer World’s Fair 上泼了一盆冷水：他亲手关掉代码审查的灯，跑了几个月的全自动“软件工厂”，最后差点把自己的公司拖垮。他给出的诊断是：这不是 harness 不够聪明，而是训练编程模型的方式，从根上就没法教会它们“可维护性”这件事。

文章要点：

  • 行业正流行“黑灯软件工厂”：不读代码、不做人工评审，只靠测试和监控兜底，号称能实现 10 到 100 倍提速；
  • Faros AI 的行业数据显示：PR 评审质量在下降、无评审合并的比例在飙升、线上事故和人均 bug 数同步走高；
  • Dex Horthy 的核心论点：这不是“工程做得不够狠”的问题，而是当前编程模型的强化学习训练方式，天生学不会“可维护性”；
  • 编程模型的奖励信号只盯着“测试是否通过”，没法惩罚烂架构——因为烂架构的代价往往要几个月甚至几年后才会显现；
  • Claude Code 之所以一炮而红，关键不是 harness 做得多花哨，而是模型厂商把模型和它要分发的 harness 绑在一起训练；
  • 解药不是放弃 AI，而是把“人工评审”请回来，用 AI 把产品评审、架构设计、程序设计、垂直切片这套前置对齐流程做快，三十分钟的规划能省下几个小时的返工。

开场：75% 代码由 AI 写，行业却在悄悄“黑灯”

2026 年，几乎每一家把 AI 编程当回事的公司，都在讲同一个故事：我们的软件工厂已经能自动产出七成以上的新代码。这个数字确实惊人，也确实让很多团队第一次感受到了“代码是免费的”这种叙事的诱惑力——你不再是瓶颈，模型足够好了，只管往里喂需求，剩下的交给流水线。

但 Dex Horthy——HumanLayer 的创始人，一个在 Agentic Coding 领域已经积累了上百万 YouTube 播放量的实践者——在 AI Engineer World’s Fair 的演讲里给出了截然不同的判断：这条路走不通。

他把这场演讲的标题起得直白：《Harness Engineering is not Enough：Why Software Factories Fail》。翻译过来就是一句话——你把 harness（脚手架、编排层、沙箱、评审 agent）堆得再精巧，也解决不了一个更底层的问题，那就是当前的编程模型压根没被训练出“维护代码”这个能力。

软件工厂简史：从人工流水线到“黑灯工厂”

要理解 Dex 的论点，得先回到“软件工厂”这个说法本身。这个词最早可以追溯到 1968 年的一次 NATO 会议，但真正和这篇文章相关的历史，从 2022 年——也就是 AI 编程爆发前夕——讲起更合适。

2022 年的经典流水线是这样的：

  • 工程师、产品经理、管理层一起决定要做什么，把需求丢进 Jira 或 Linear 之类的任务追踪系统；
  • 有人认领任务、动手实现，期间可能有自动化测试也可能有人工测试；
  • 提交 Pull Request 后，一套检查加上人工代码评审，必要时再拉下来跑一遍；
  • 出问题打回重做，没问题就上线；
  • 上线之后用户开始反馈、报 bug、提需求，这些又重新汇入队列，循环往复。

团队很早就发现，“动手实现”和“人工评审”这两个环节都是以小时甚至天为单位的重活。于是行业发展出了架构设计文档、迭代规划这些前置对齐机制，目的很简单：提前把认知对齐了，返工率就会降下来，评审也不用逐行死磕。

到了 Agentic 软件工厂，最直观的变化是“有人实现”被替换成了“agent 实现”——编排系统、harness、沙箱、模型、计算机操作能力一起上阵，“实现”这一步从几天缩短到几小时甚至几分钟。但人工评审和测试这一环节的耗时并没有同比例下降，很快就成了新的瓶颈。

于是行业的解法顺理成章：既然可以用 agent 写代码，那也可以用 agent 做代码评审、做回归测试。

再往前一步，就是**“黑灯工厂”（lights-off software factory）**——这个说法由 Dan Shapiro 提出：既然评审这么慢，干脆不评审了，把资源全部投入测试、监控、灰度发布等其他环节，让线上事故直接路由回工厂重新生成补丁，用户反馈也直接喂进队列。团队唯一要做的事，变成了“能往队列里塞多少任务，能多快地测试和上线”。

Dex 的判断很干脆：这条路走不通。

数据不会说谎：代码质量正在肉眼可见地下滑

这不只是 Dex 一个人的直觉。他在演讲中提到，另一位从业者 Mario 在 AI Engineer Europe 上公开呼吁大家“慢下来”——原因是一些原本不该因为编程 agent 出问题而宕机的公司，正在因为 agent 的失误而宕机。

更系统性的证据来自 Faros AI 的一份行业报告：自 2026 年初大规模采用 AI 编程工具以来，Pull Request 的评审质量明显下降，评论数量更多、篇幅更长，同时有相当比例的 PR 是在完全没有评审的情况下直接合并的；与此同时，线上事故数量和人均 bug 数都在同步上升。

行业里流行的解释是“你用得不对”——只要 harness 工程做得再狠一点，再往 PR 评审机器人里塞一些“对抗性评审”之类的魔法提示词，就能鱼与熊掌兼得：速度提升 10 到 100 倍，质量不打折，还不用做人人都讨厌的代码评审。Dex 想说的是：这不是一个“规模问题”，再多的 harness 工程、再多的循环嵌套循环（loop maxing），都解决不了一个本质上是模型训练层面的问题。

Dex 的至暗时刻：一次持续数月的“黑灯实验”

这个判断不是纸上谈兵。Dex 特别强调，这篇文章的内容和“vibe coding”没有关系——一个人写着玩的、大概十几个人会用的副业项目，和一个维系了十年的企业级系统之间，几乎没有共同的约束条件，互相指导对方“应该怎么活”通常没什么意义。HumanLayer 关心的，是如何在复杂的、有历史包袱的代码库（他们称之为 brownfield）里解决难题——这类代码库以前的典型印象是“十年历史的 Java 老系统”，但 Dex 观察到，在如今的迭代节奏下，一个 agent 大约在三到六个月之后就会开始明显吃力。

他知道这一点，是因为 HumanLayer 自己在 2025 年 7 月真的把灯关了：跑了一段时间彻底的“黑灯软件工厂”。结果是，几个月之后，团队遇到了一个再高级的提示词都解决不了的问题——不得不回头去研究一个已经三个月没人读过的代码库，去做复现、去排查。与此同时，线上服务在出问题，用户在抱怨，团队自己也在被淹没在这几个月里悄悄堆积起来的“AI 味”代码里。

Dex 把这次经历总结成一个简单的结论：模型有一个明确的短板——它们没法在没有人类持续介入的情况下，维护并改善代码库的质量。这里说的“可维护性”，指的是那种典型的代码坏味道：改动代码库某一处，很容易在不经意间牵连并破坏另一处，也就是 Martin Fowler 所说的“霰弹式修改”（shotgun surgery）。

值得注意的是，Dex 特别澄清：如果只看“解决单个孤立问题”或者“随手搭一个营销落地页”，模型确实比一两年前强了不少；但在“提升代码库整体质量”这件事上，他认为进展并不明显。目前还没有足够好的基准测试能直接证明这一点，但只要长期和编程 agent 打交道，大概率会有同样的体感：它们往往会让代码库随时间推移变得更难维护。

核心诊断：为什么模型学不会“维护代码”

要理解这个短板从哪来，得先搞清楚为什么第一个真正意义上的现象级编程 agent——Claude Code——能在不到一年时间里做到几十亿美元级别的收入规模。在它之前，Aider、CodeBuff 之类的命令行 agent 已经存在，工具集也差不多，都是读文件、写文件、编辑、检索、执行命令这一套。真正的分水岭在于：这是第一次由模型厂商，把模型和它最终要分发给用户的那套 harness 绑在一起训练。换句话说，模型不是“被适配”到某个外部工具链上，而是从训练阶段起就在这套工具链里反复练习工具调用和多步任务的解决。OpenAI 团队去年 11 月的一次分享也提到过类似的观点：如果你是个 harness 开发者，却不掌握模型权重、无法在自己的 harness 里对模型做强化学习，你相对于同时掌握模型和 harness 的厂商，天然处于劣势。

60 秒看懂：编程模型的强化学习是怎么“喂”出来的

Dex 用一个极简的流程解释了当前主流的编程模型强化学习训练是怎么运作的：先给模型一个问题，让它反复尝试、生成一大批不同的解题轨迹；对每一条轨迹打分——代码能不能跑通、测试能不能通过；然后做强化：让“坏”的行为在未来变得更不可能发生，让“好”的行为变得更可能发生，模型权重据此更新。

一个典型例子是 SWE-bench Multilingual 这类基准：任务大多来自 Redis、jq、Django 这样的开源项目，时长大约十几分钟一个，奖励是二元的——问题修好了没有，以及有没有在修的过程中把别的地方弄坏。

演讲中举了一个来自 Fastlane（一个 Ruby 项目）的真实案例：某处代码没有做空值检查，导致空指针异常报错。基准测试会准备一个“问题修复前”的基础提交、一份描述期望行为的测试补丁，以及一份人类当年实际写出的“标准答案补丁”——这两者都对模型隐藏。

agent 去尝试解决问题、保存它生成的补丁；系统会撤销它对任何测试文件做的改动（因为确实见过模型为了让测试通过而直接把测试注释掉），再套用标准的测试补丁，看新旧测试是否都能通过。通过就给奖励，不通过就不给。

病灶解剖：验证“测试通过”容易，验证“这代码还能不能维护”极难

问题就出在这里：在这套体系里，没有任何机制能因为“程序设计糟糕”或者“正在腐蚀系统可维护性”而惩罚模型。这正是为什么会看到那些莫名其妙包裹在代码外面的 try/catch，或者纯粹为了让测试通过而做的类型强转——模型的唯一目标就是让测试变绿，至于代码本身是不是在“应付了事”，它并不关心。

如果说“代码能跑、测试能过”这件事验证起来相对容易，那“代码是否具备可维护性”的验证难度要高出好几个数量级，

原因很直接：一段架构糟糕的代码，代价往往要以月甚至年为单位才会真正显现出来。等到你几个月后才发现某次“随手改改”埋下了雷，想再把这个惩罚信号反向传导回训练那一刻，几乎是不可能的。

前沿模型在这方面确实在缓慢变好，但基准测试和用于训练的验证器之间存在天然的结构性相似——虽然严格意义上它们必须是不同的数据集，但整体形态是相通的，所以可以把当前基准测试的演进方向，看作是行业在“评估代码可维护性”这件事上正在摸索的路径。

下一代评测基准：行业在尝试的几条路

演讲中提到了几个正在探索的方向：

  • SWE Marathon（来自 Abundant AI）：设计了长达 400 小时量级的任务，比如“把 Microsoft Excel 的每一个功能都克隆一遍”，并配套了更复杂的奖励通道设计；
  • DeepSuite（来自 Data Curve）：同样是基于开源仓库的大型任务，但特意挑选那些从未在现实世界中被真正实现过的功能，以避免训练数据污染；
  • Frontier Code（来自 Cognition）：面向多 PR 的复杂任务，加入了一些更精细的机制，比如如果模型写的测试在打补丁之前就应该失败却没有失败，会被惩罚，同时引入一个“裁判模型”专门判断代码是否符合既定的质量规范。

但 Dex 同时给出了一个清醒的判断：靠“用模型评判代码质量”这条路能走多远是有天花板的——因为如果一个模型真的知道什么是好代码，它一开始就会直接写出好代码。

评审 agent、多花一些 token 去反复检查，确实能把及格线往上抬一抬，但终究还是被“强化学习阶段到底能教会模型什么”这件事卡住了脖子。

所以他的结论是：至少在现阶段，人类还是得亲自读代码。当然，如果你愿意一直 YOLO 提示词、一路等到某个远超当前水平的模型出现，那也是一种选择，只是“苦涩的教训”（bitter lesson）不会因此就消失——眼下这些问题，还是得靠工程手段先解决一部分。

当前阶段的解药：把灯重新打开——前置对齐四步法

既然验证器和基准测试还没跟上，Dex 给出的解法不是放弃 AI，而是把代码评审这盏灯重新打开，同时用 AI 把“前置对齐”这件事做得更快、更彻底，从而尽量降低评审环节漫长而痛苦的概率。具体是四层：

  1. 产品评审：先把问题和期望的行为界定清楚，包括看清楚设计稿，理解到底要解决什么；
  2. 系统架构：明确组件之间的契约、数据模型、约束条件，把系统之间怎么拼接这件事想明白——需要说明的是，规模较小的任务依然可以直接丢给 agent，不必都走这一整套流程；
  3. 程序设计：这是 Dex 认为目前被严重低估的一环——很多人以为架构想清楚了，模型就能直接“开干”，但真正决定代码质量的，往往是类型定义、方法签名、调用栈这些更细粒度的设计；来自 Cloudflare 的 Dylan Mulroy 在实践中也常用调用关系图作为规划的一部分，Dex 认为这个方向是对的；
  4. 垂直切片：确定实现顺序、跨仓库如何协同，以及每个阶段之间要如何检查——这部分和“模型更擅长横向铺开还是纵向切片”的话题相关，感兴趣可以去找 Dex 在 AI Engineer Miami 上的相关分享。

这套流程背后的核心逻辑很朴素：前期花三十分钟做规划和对齐，往往能在评审阶段省下几个小时。而且这条路径确实能做到——逐行读代码依然是可行的。

Dex 特别强调一个反直觉的观点：如果你发现自己被大量 PR 淹没，真正的问题往往不是“PR 太多”，而是“烂 PR 太多”——一个真正对齐过的好 PR，读起来是一种享受，因为你几乎是在确认“对，这就是我们讨论过的方案”；但哪怕一个 PR 只需要百分之二十的返工——这对相当一部分“AI 味”很重的代码来说已经算很客气了——它给评审者和提交者带来的情绪和认知负担依然不小。

用模型辅助规划和对齐之后，整个链路会同时在三个环节提速：对齐更快，因为可以借助 AI 一次性把所需信息都拉齐；评审更快，因为前期已经对齐过；编码更快，因为这部分本来就是 AI 完成的。结果是速度确实起来了，但人依然在逐行读代码，依然对代码拥有实质性的所有权。

小结：工程师的价值，恰恰在“约束”里

听完这些，很容易感到有点泄气——毕竟“再也不用读代码”的世界确实诱人。

但 Dex 的落脚点很朴素：工程师的工作，本质上就是在一组约束条件下解决问题；模型在某些事情上确实很擅长，在另一些事情上确实还不行，工程师要做的是搞清楚边界在哪，然后在边界之内继续去解决难题、去寻找杠杆。循环（loop）这个工具很好用，该用就用，但真正值得投入精力的，是那些复杂代码库里的硬骨头。

参考资料

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。