专栏 · Agent 工程手艺 › 第 93 期 · AGENT 工程 · 收录于 2026 年 8 月 16 日
光有 harness 工程不够:软件工厂为什么失败——Dex Horthy(HumanLayer) DH
Dex Horthy · AI Engineer
6.2万 观看
2,131 赞
3.4% 点赞率
86 评论
62.7万 频道订阅
数据截至 8 月 27 日
▶ 双人对谈 · 本期速读电台 00:00 / 11:54
1× TL;DR · 三句话
一 2025 年 7 月，HumanLayer 创始人 Dex Horthy 亲手跑了一个"熄灯软件工厂"（lights-off：没人读代码，需求和故障全塞进队列交给 AI agent），几个月后它崩了——一个 agent 怎么都修不好的问题冒出来、网站宕机，他被迫回去 debug 一个自己三个月前就停读的代码库。→ 详细 二 他的核心论断：这不是技术不到位、也不是规模（scale）问题，再多 harness（agent 的外壳/脚手架，管上下文、工具、循环）或 token 都救不了，因为它本质是模型训练问题——coding 模型只被"test 有没有通过、有没有弄坏别的"这一条 reward（奖励信号）强化，没有任何东西惩罚糟糕架构，而糟糕架构的代价要几个月后才爆。→ 详细 三 解法不是继续 yolo（凭感觉一把梭），而是"把灯重新打开"：用 AI 把产品评审、系统架构、程序设计、垂直切片这些判断前置，前期 30 分钟对齐能省下几小时 review，让你既跑得快、又始终在读代码、对代码负责。→ 详细
开场：多花 token 就行？ 大家都在抢着把 AI 编程搬进生产环境，StrongDM 甚至搭了个"没人读代码"的熄灯工厂；主流叙事是"你才是瓶颈、模型已够好、代码不要钱，只管多发布"。Dex 要反驳的正是这套。→ 详细 裂缝已现（有数字） ：朋友 Mario 在 AI Engineer Europe 上恳求大家慢下来——本不该因 coding agent 宕机的公司在频繁宕机；Faros AI 的报告显示，自今年 1–2 月普及 AI 编程工具后，PR（pull request，代码合并请求）审查质量大幅下滑、评论更多更长、大量 PR 没任何审查就合并，故障数和人均 bug 数都大幅上升。→ 详细 "是你姿势不对"（skill issue） ：很多人会说 token 堆不出效果是你技术问题（skill issue）；Dex 说他在 YouTube 上讲"怎么更好地用 AI"的演讲加起来约 100 万播放，但今天要证明这根本不是规模问题、也不是姿势问题。→ 详细 核心论断：这是模型训练问题 ：再多 harness engineering、再疯狂加 loop（循环，指 agent 反复"思考-调工具-观察"的自动化回合）都解不了一个本质属于模型训练的问题——所以"harness 还不够"。要理解它，得去啃 coding 模型是怎么训练出来的。→ 详细 软件工厂简史 ："软件工厂"一词早在 1968 年 NATO 会议上就被定义；2022 年的典型工厂 = 工程师/PM/领导层 → 丢进 tracker（任务看板，如 Linear/Jira/Beads）→ 有人领任务开发 → 自动/手动测试 → 发 PR、人来审查 → 上生产 → 用户抱怨提 bug → 加监控 → 出事就凌晨三点把工程师叫醒。→ 详细 前期规划的老智慧 ：团队几十年前就发现"开发"和"审查大改动"都要花几小时到几天，于是加了前期的架构、方案、sprint 规划，靠提前对齐来降低返工概率、减少逐行审查的时间。→ 详细 Agentic 软件工厂：75% ：现在几乎每家公司都在讲自己搭了个产出 75% 代码的 coding agent 工厂——把"有人做"换成"agent 做"，配上 orchestration、harness、sandbox、模型、computer use；再加 agentic 代码审查和回归测试，但人来审查/测试仍是瓶颈。→ 详细 熄灯工厂（lights-off） ：干脆把所有故障和用户反馈直接路由进工厂、醒来就有现成 PR；这套"不再读代码"的打法由 Dan Shapiro 提出，叫 lights off。Dex 当场断言："那行不通。"→ 详细 【益项 · 亲历】熄灯工厂 3–6 个月后崩了 ：Dex 说 agent 大概在 3–6 个月后就真的开始吃力，尤其在现在这种发布节奏下；2025 年 7 月 HumanLayer 彻底走了熄灯路线来验证这一点。→ 详细
认真试上几个月，你总会碰到至少一个哪怕最高级 prompt 也解决不了的问题——只能做调研、做复现，一头扎进那个你三个月前就停读的代码库找哪儿坏了；与此同时网站已挂、用户已气炸。→ 详细
更痛的是，你正痛苦地读着自己放任溜进系统的 slop code（AI 糊出来的垃圾代码）；Dex 的结论是模型有个短板——没有相当程度的人为引导（steering），它没法随时间维护并提升代码库质量。→ 详细
跟 vibe coding 无关 / brownfield ：引用 Addy 的原话——一个人 vibe coding（凭感觉写）一个十来人用的副业项目，和一个团队要让十年企业系统再撑一个季度，几乎没有任何共同约束；HumanLayer 关心的是复杂代码库里的难题，常说的 brownfield（存量老代码库，典型是十年老 Java 项目）就是后者。→ 详细 短板到底是"可维护性" ：可维护性差 = 想改一处就会弄坏别处，即 Martin Fowler 说的 shotgun surgery（霰弹式修改）这种教科书级 code smell（坏味道）；《软件设计的哲学》作者 John Ousterhout 本周也在场。模型在一次性问题、vibe code 新营销站上比 2024/25 强了太多，但在"提升代码库质量"上几乎没长进——而且没有好 benchmark（基准测试）能衡量它。→ 详细 为什么 Claude Code 赢 ：Claude Code 不到一年营收从 0 做到 40 亿、现约 90 亿美元；此前 Aider、Codebuff 用的工具一模一样（read/write/edit/grep/bash），区别在于这是头一回有模型实验室针对"要分发给用户的那个 harness"去训练模型。OpenAI 十一月的演讲也说：不拥有模型权重、没法在自己 harness 里做 RL（强化学习）的人，永远打不过同时握着模型和 harness 的人。→ 详细 【益项 · 根因】60 秒讲 coding 模型的 RL ：引用 Codex 首发时的技术团队成员 Calvin French-Owen 的幻灯片——LLM 本质是 next-token（下一个词）预测器；训练时给一个问题、生成一堆解题 trace（尝试轨迹）。→ 详细
按"正确性 / test 过没过"给每条轨迹打分，再 reinforce（强化好行为、压低坏行为）。经典 benchmark 是 SWE-bench Multilingual：约 15 分钟的任务，取自 Redis、jq、Django 等开源仓库，reward 是二元的 1 或 0——"有没有修好、且修的过程中没弄坏别的"。→ 详细
真实例子是 Fastlane（Ruby 项目）：某处没检查 nil 导致空指针、stack trace 直接炸；评测会 check out 到人类修复前的状态，藏起 test patch 和 golden patch，还会撤销模型对 test 文件的改动（因为模型会为了跑通直接把 test 注释掉），最后跑测试全过才给 reward。→ 详细
关键点：这套体系里根本没法因为"糟糕的程序设计 / 侵蚀可维护性"去惩罚模型——于是你看到根本不需要的地方被套上 try-catch、或把一个东西硬转成另一个只为让 test 过（另一位讲者给过的例子）。→ 详细
【益项 · 根因】架构的代价滞后数月，reward 传不回来 ：验证"代码质量/可维护性"比验证"能跑、test 过"难上好几个数量级，因为糟糕架构的代价函数以月、以年计——一次生成当时看不出，几个月后才发现"有人这块 vibe 得太狠"，那个 reward 信号根本没法跨越这么长的时间间隔传回去。→ 详细
连"让模型当裁判评质量"也有天花板：如果模型真知道好代码长什么样，它一开始大概就直接写出来了。→ 详细
更好的 benchmark 长什么样 ：benchmark 和 verifier（验证器）虽是两回事、必须是不同数据集，但形态一样、方向对。前沿探索包括：Abundant AI 的 SWE Marathon（400 小时任务，比如把整个 Excel 每个功能都克隆出来）、Datacurve 的 DeepSuite（现实里从没被真正做出来、因此不在训练集的大型开源任务）、Cognition 的 Frontier Code（多 PR 任务，还会给"在打补丁前就不会失败的 test"扣分、用 judge model 查代码质量规则）。→ 详细 verifier 能抬下限、抬不了上限 ：review agent 加更多 token 能抬高质量下限，但你仍受限于"RL 阶段到底能教会模型什么"；所以 Dex 放话——至少现在，还是逃不掉要读代码。想一路 yolo prompt 等到 GPT7 也行，但"去他的 bitter lesson（苦涩的教训）"，眼下这些问题得靠工程解决。→ 详细 【益项 · 解法】把灯打开：判断前置四步 ：Dex 的解法是"turn the lights back on"、把 code review 放回来，靠前期规划降低"漫长/困难 review"的概率。第一步是产品评审（product review：要解决什么问题、期望行为、看 mockup 线框图），他现场展示了昨天做的一份带新功能 mockup 的产品评审。→ 详细
小需求仍直接丢给 agent；大的则先做系统架构（组件契约、数据模型、各种约束）——用一份文档讲清系统之间怎么拼、高层全景长什么样。→ 详细
接着做被严重低估的程序设计（program design）：别以为架构一定对模型就能尽情发挥，要深入看类型、方法签名、程序布局、调用栈；Cloudflare 的 Dylan Mullroy 就把 call graph（调用图）用进他的规划流程。→ 详细
最后做垂直切片（vertical slices：实现的先后顺序、多仓库协调、边建边验证），因为模型默认做的是横向规划。核心账目：前期规划对齐花的这 30 分钟，能在 review 上省下好几个小时，所以逐行读完每一行代码仍然可行。→ 详细
【益项 · 解法】好 PR 是享受，坏 PR 是负担 ：你不是 PR 太多，而是烂 PR 太多；好的 PR review 起来是享受——"嗯这很棒，这就是我们说好的"。→ 详细
哪怕一个 PR 只需返工 20%（对很多 AI vibe 出来的垃圾这已算客气），对审查者和提交者都是情绪与智力的双重负担；用模型辅助规划对齐后：对齐更短（AI 一次性给全信息）、review 更快（前期已对齐）、编码更快（AI 写的）——你真的在加速，但依然读每一样东西、依然对代码负责。→ 详细
01
闪电问答 / 收尾 本场无问答环节，仅有收尾寄语：
收尾寄语 ：听完这些容易有点沮丧——谁不想什么都 yolo、再也不用读代码。但我们是工程师，这些不过是约束条件；模型有的事擅长、有的不擅长，那就在给定约束下想办法解决问题。用好 loop（它们很棒）、去解决难题、去寻找杠杆。→ 详细
02
联系方式
嘉宾 ：Dex Horthy，HumanLayer 创始人。→ 详细 HumanLayer ：一个 AI IDE + 协作平台，自称"你软件工厂的构建模块"，即将推出更好的软件质量 verifier；做了个"Claude Code / Codex 版的 Figma"式协作工作空间，带你走完这类工作的工作流。正在找 design partner（设计合作伙伴）、在旧金山招创始工程师，幻灯片实时公开。→ 详细 试用 ：humanlayer.com，对小团队免费。→ 详细