Dex Horthy 说 harness 不能救所有问题

Dex Horthy 的题目很直接：”Harness Engineering is not Enough”。这场和前面很多演讲形成张力。当天大家都在讲 harness、loop、workflow，他提醒大家：不要以为外层系统能解决所有模型问题。

原视频：https://www.youtube.com/watch?v=htM02KMNZnk

这不是 skill issue

Dex 开场就说，这不是 skill issue。再多 harness engineering、再多 loop maxing，也不能解决某些模型训练层的问题。

这句话很重要。过去一段时间，AI coding 社区有一种乐观叙事：模型只要放进足够好的 harness，就能完成越来越复杂的软件工作。加上下文、加工具、加测试、加 retry、加 reviewer，系统好像会自然变强。

Dex 并不是否定这些东西。他反对的是把所有失败都解释成 “我们还没把 harness 搭好”。有些失败来自模型训练本身，比如模型对长期维护性、复杂抽象、真实代码库约束、测试边界的理解不够。

坏代码会复利

他讨论了 coding model 的训练方式、benchmark 的局限，以及复杂代码库里的维护性问题。很多 benchmark 测的是能不能解一个封闭任务，但真实工程里的任务不是这样。真实任务有历史包袱、团队规范、性能约束、安全边界和未来维护成本。

如果模型生成的代码只是 “当前能跑”，但破坏了抽象、污染了测试、绕过了安全边界，短期看是进展，长期看是债务。更麻烦的是，如果再让 agent 修 agent 造成的问题，坏抽象可能会一层层滚大。

这和本地知识库里 “comprehension debt” 的概念一致：loop 越快生成你没理解的代码，仓库内容和团队理解之间的差距越大。真正账单会在以后 debug 时出现。

harness 还是重要，但不是万能

我自己的判断是，Dex 不是反对 harness。他反对的是一种幻觉：只要把模型放进足够复杂的 loop，软件工厂就会自动成立。

更现实的看法是双层改进。外层系统要更可验证：spec、tests、permissions、trace、review、rollback 都要强。底层模型也要为真实工程任务训练：长期代码库、维护性、跨文件依赖、安全约束、团队规范，都应该进入训练和评估。

这场给 software factory 降温很必要。否则大家会把所有风险都包装成 workflow 问题，然后在生产里发现模型本身没有学会某些工程判断。

软件工厂不是 harness 胜利，也不是模型胜利。它是模型能力和外层系统共同进化。少任何一边，都不稳。

Dex 挑战的是当下最流行的解释

过去一年，很多人把 AI coding 的失败解释为 harness 问题：上下文没给够、工具没接好、测试没跑起来、权限没设计好。这个解释有很大部分是对的，但 Dex 说它不够。

他的观点是，有些失败不是外层系统能完全解决的，而是模型训练本身还没学会某些深层软件工程能力。比如长期维护性、复杂抽象边界、代码库历史约束、隐性架构原则，这些不是多接几个工具就自然解决。

这个提醒很必要。否则行业会陷入一种乐观幻觉：只要 harness 足够复杂，任何模型都能成为可靠工程师。

harness 和模型能力不能互相甩锅

我觉得更准确的说法是：harness 和模型能力是共同瓶颈。没有 harness，强模型也会在缺上下文和缺验证里乱跑；模型能力不够，再好的 harness 也只能限制它犯错，不能让它真正理解复杂任务。

这和现实团队很像。流程很好但人能力不足，产出仍然差；人很强但流程混乱，风险也很高。软件工厂需要两边一起成熟。

对团队的现实建议

Dex 这场会让团队更谨慎地评估 agent 任务。不要把所有任务都自动化，也不要把失败简单归因于 prompt 不好。

可以先把任务分层：机械改动、局部 bugfix、测试生成、文档补全，适合较高自动化；涉及架构、长期演进、复杂业务语义的任务，需要更强人类参与。这个分层不是保守，而是承认模型和 harness 都还在发展中。

来源与说明

本文基于 AI Engineer World’s Fair 2026 Day 1 主舞台视频转录、官方日程信息，以及本地 AI engineering 知识库整理。文章不是逐字稿，而是按单场分享的主线、上下文和工程启发重写。