Harness工程还不够

Dex Horthy · AI Engineer

视频 19:17 原文约 2.1 万字预计阅读 11 分钟来源视频 ↗ 中英对照全文

双人对谈 · 本期速读电台 00:00 / 11:54

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 写的）——你真的在加速，但依然读每一样东西、依然对代码负责。→ 详细本场无问答环节，仅有收尾寄语：
收尾寄语：听完这些容易有点沮丧——谁不想什么都 yolo、再也不用读代码。但我们是工程师，这些不过是约束条件；模型有的事擅长、有的不擅长，那就在给定约束下想办法解决问题。用好 loop（它们很棒）、去解决难题、去寻找杠杆。→ 详细
嘉宾：Dex Horthy，HumanLayer 创始人。→ 详细
HumanLayer：一个 AI IDE + 协作平台，自称"你软件工厂的构建模块"，即将推出更好的软件质量 verifier；做了个"Claude Code / Codex 版的 Figma"式协作工作空间，带你走完这类工作的工作流。正在找 design partner（设计合作伙伴）、在旧金山招创始工程师，幻灯片实时公开。→ 详细
试用：humanlayer.com，对小团队免费。→ 详细

🎯 于你何益为你定制 · 非通用结论

这场演讲跟你手上两个"agent 工厂"直接对得上：一个跑过熄灯工厂并崩掉的人，把"为什么会崩、怎么救"讲透了。下面两条高相关，其余诚实略过。

🎯 Holdwell ERP 多-Agent PRD 工厂

怎么做的（Dex 的路径）：Dex 把熄灯工厂跑崩后，诊断不是"harness 不够"或"token 不够"，而是模型训练层面的结构性缺陷——coding 模型只被"test 过没过、有没有弄坏别的"这条二元 reward 强化，糟糕架构的代价函数以"月/年"计，几个月后才爆，reward 信号根本传不回当初那次生成。所以他的解法是"把判断前置"：产品评审 → 系统架构（组件契约/数据模型/约束）→ 程序设计（类型、方法签名、调用栈）→ 垂直切片，前期 30 分钟对齐省下几小时 review，并明确"至少现在还逃不掉读代码"。

你可以怎么做：你的痛点写着"跨线对齐、agent 产出缺可观测/可验证"——这场正好给了两个抓手。其一，三驾马车碰撞环节（补强/修正/第 3 案）里要有一双专门盯"架构/可维护性"的眼睛，因为这恰恰是模型天然不会自罚的维度（它优化的是"PRD/产出过评审"，不是"半年后这套实体模型还好不好改"）——6 条产品线强耦合、跨线联动频繁，跨线对齐这种"滞后爆"的债，正是 shotgun surgery 式的代价。其二，"agent 产出的可观测/可验证"对应 Dex 的教训：他等到的"证据"是网站几个月后宕机，太贵了；你需要在真人评审前放一个能提前把架构债显影的检查点（哪怕是人来读、或一份强制的跨线对齐文档），而不是等下游返工才发现。

更深一层（镜子）：Dex 说"如果模型知道好代码长什么样，它一开始就写出来了"——所以 judge-model / AI 互评只能抬高质量下限、抬不了上限。照回你的工厂：你产出的是 PRD 不是代码，但同一个 reward-gap 照样成立——一个只优化"过评审"的 agent，不会替你惩罚半年后才显现的一致性/可维护性债。三驾马车碰撞里的互看互评同理，"架构/可维护性"这一维必须由真人评审来 own，不能全托给 agent 互评。

所以呢：在真人评审里把"架构/可维护性"单拎成一条必须回炉闭环的硬标准、专盯模型不自罚的滞后债，这大概是你"真人评审意见回炉闭环"最该先补的一格。

🎯 app_incubator 7-Agent 造 App 链路

怎么做的（Dex 的路径）：Dex 解法的第一步就是"把该做什么前移"——先做产品评审（要解决什么问题、期望行为、看 mockup），他现场展示的正是一份带新功能 mockup 的产品评审；再把系统架构当成 agent 动手前的工程契约。这跟你 app_incubator 的"设计稿即工程强制契约、把该做什么前移到 agent"几乎是同一句话，等于被一位跑过工厂的人当众背书。

你可以怎么做：前置这半段你已经对了，这场给你补的是"后半段的红线"——"没人读代码"的熄灯打法会在 3–6 个月后崩。你的 7-Agent 链路若在某个 App 上走向"全自动、没人读"，同样的雷会踩。可在链路里保留一个"人读代码"的强制环节，尤其当某个 App 从新建（greenfield）长成半年以上的存量系统（brownfield）之后。

更深一层（冲突/边界）：Dex 明说模型在"一次性问题、vibe code 新营销站"这类 greenfield 上比 2024/25 强了太多，短板只在"随时间维护代码库质量"。app_incubator 多在造"新 App"，更偏 greenfield，所以熄灯风险本就比 Holdwell 那套存量 ERP 低——但一旦某个 App 活过 3–6 个月，它就变成 brownfield，风险曲线开始上翘。别把两者用同一套"读不读代码"的松紧度对待。

所以呢：前置那套你已经对了；真正要提前埋的是"App 转入存量期后由谁读代码"的那一环，别让某个成功的 App 悄悄滑进熄灯态。

诚实闸门：其余项目

StockHelp（投资）：自用的 Streamlit 小工具、偏 greenfield，正落在 Dex 说"vibe code 无妨"的那条赛道，本场对它几乎无直接可借鉴；唯一的投资弱信号是——Claude Code 一年内营收 40→90 亿美元，加上"同时握模型权重 + harness 才有护城河"这条垂直整合论点，可作观察 AI coding 赛道竞争格局的一个侧写。
内容号（xiaohongshu / onehuman_company）：不涉代码，基本无关；仅 onehuman 的"大佬说 X 我试了"验证体可把本场当一颗选题种子（Dex 说熄灯工厂会崩，你拿 app_incubator 实测过），仅此一点。

一句镜子：Dex 整场其实在讲你写过的操作系统——"判断力 > 努力、问该不该做先于做多快、杠杆 > 工时"。他的"30 分钟前置对齐省几小时 review"就是判断前置换杠杆；"模型只优化短期 test-pass"则提醒你：真正的杠杆点，在那几个人不该外包出去的判断上。

接着读

NO.92 · AI 产品数据模型即护城河 Mike Phipps · 11 分钟 NO.91 · Agent 工程砍掉多智能体流水线 Subbiah Sethuraman · 10 分钟