ISSUE / 047
把优秀程序员的工程自律，翻译成 Harness Engineering
最近很多天没更新，不是没在想这件事，反而是因为这段时间一直在实践 Harness Engineering。 但越做，我有时候反而越迷茫。 我到底是在做 agent harness，还是在做 Harness Engineering？ 后来我慢慢觉得，这两个词虽然看起来很近，但其实不是一层东西。 如果非要简…
最近很多天没更新，不是没在想这件事，反而是因为这段时间一直在实践 Harness Engineering。
但越做，我有时候反而越迷茫。
我到底是在做 agent harness，还是在做 Harness Engineering？
后来我慢慢觉得，这两个词虽然看起来很近，但其实不是一层东西。
如果非要简单分一下，我现在会觉得，Agent Harness 更像是在搭一套 Agent 的运行底座。
它处理的，更多是那些不属于“模型自己思考”的事情。比如工具怎么接、记忆怎么带、上下文什么时候注入、失败了怎么重试、遇到高风险动作怎么卡审批、多 Agent 之间怎么分工协作。
换句话说，它更像是在解决：怎么让 Agent 这套东西真的能跑起来，而且能比较稳定地跑下去。
而 Harness Engineering 讨论的，其实是另一件事：你要用什么样的工程约束、验证机制、恢复机制和规则系统，让这些 Agent 的产出长期可控、可维护、可演化。
- 前者更像是在解决“怎么把 Agent 跑起来”。
- 后者更像是在解决“怎么让它做出来的工程结果长期别坏掉”。
也正因为这样，表面上看大家讲的好像都是 Harness，但我越来越强烈地感觉到，很多人嘴里的 Harness，其实不是一回事。
甚至有一天，我拿着自己正在搭的那套工程，忍不住直接问 AI：
“我这 tm 到底算是在搞 Harness Engineering 吗？”
这个问题听起来有点好笑，但当时我其实是认真的。
因为你一边在搭系统，一边会发现自己越来越容易陷进各种局部问题里：怎么编排 Agent，怎么设计 Prompt，怎么接 Skill，怎么做 Memory，怎么接 MCP，怎么让流程自动流转……
这些东西当然都重要。
但做着做着，我开始觉得，自己好像一直在回答“怎么让系统跑起来”，却没有真正回答另一个更底层的问题：
我到底想造一个什么样的系统？
后来我又重新沉淀了很久，慢慢有了一些新的感悟。所以有了这篇文章。
我现在越来越觉得，Harness Engineering 真正值得思考的核心，并不只是“如何让 Agent 写代码”，而是另一个更底层的问题：
优秀程序员究竟为什么优秀？以及，能不能把这种优秀沉淀成一套可重复执行的系统。
这个问题想清楚之后，很多事都会变得通透。
很多团队复制了生产力，却没有复制治理力
这也是为什么很多团队已经接入了 Agent，效果却始终不够稳定。
工具很多，模型很强，Prompt 越写越复杂，编排流程也越来越完整。表面上看，一切都在进步。但最终产出的结果，总让人觉得差一点。
功能也许能跑。 代码也许能交。 效率也许确实提高了。 可项目并没有因此变得更健康。
问题往往出在这里：系统复制了程序员的生产力，却没有复制程序员的治理力。
它能生成代码，却不一定能识别边界已经开始坏掉。 它能自动修 bug，却不一定知道当前抽象已经撑不住需求。 它能跑测试，却不一定理解“能跑通”和“做完整”之间还有很大差距。 它能做 review，却不一定能判断这次改动是否正在制造新的破窗。
于是就会出现一种很常见的现象：短期看效率提升了，长期看系统更脆弱了。
这其实是很多 AI 工程实践容易踩进去的坑。
自动化解决的是动作执行问题。 工程化解决的是秩序维持问题。
Harness Engineering 真正难的地方，就在这里。
优秀程序员，强在持续维持秩序
我们平时说一个程序员优秀，往往会先想到这些标签：写代码快、框架熟、定位问题准、复杂需求也能拿下。
这些当然重要，但如果你真的长期观察一个靠谱的工程师，你会发现他最稀缺的能力，很多时候并不是把功能写出来，而是持续维持系统秩序。
他会天然地约束自己。
不会轻易让临时方案长成长期结构。 不会觉得“这次先 any 一下”“这次先 copy 一段”“这次先跳过测试”只是小问题。 不会为了短期推进，把边界、命名、职责、抽象随手打乱。
他也会主动恢复秩序。
看到代码开始变脏，会想着清理。 看到抽象开始失效，会及时重构。 看到边界开始松动，会主动收口。 看到同类错误反复出现，会补上一道防线，让下一次更难再犯。
所以，优秀程序员真正厉害的地方，往往不是“写了多少代码”，而是“守住了多少秩序”。
Harness Engineering，到底在抽象什么
如果今天重新总结 Harness Engineering，我更愿意把它理解为：
它是在把优秀程序员脑中那些隐性的工程自律，翻译成系统能力。
一个优秀工程师身上，通常有几种非常关键的特征。
第一，边界感。
知道什么东西该放在哪一层，什么逻辑不该混进当前位置，什么捷径会伤害长期演化。
第二，洁癖。
看到重复实现、职责错位、命名混乱、越层依赖，会天然不舒服。
第三，恢复意识。
功能写完不会立刻离开，而是会看周边有没有被污染，有没有该补的测试、兜底、状态处理。
第四，复盘能力。
出过一次错，就会思考怎样让同类错误以后更难发生。
第五，完成定义。
能跑通不等于完成，真正完成还包括质量、边界、可维护性、可验证性、回归范围。
这些能力表面上看像是个人修养，实际上都可以工程化。
边界感，可以沉淀成架构规则和越层检查。 洁癖，可以沉淀成命名规范、重复逻辑检测、公共层污染检测。 恢复意识，可以沉淀成回修流程、重构触发器、回退机制。 复盘能力，可以沉淀成错误分类、规则升级和经验记忆。 完成定义，可以沉淀成多维度验收门禁。
当这些东西被系统化，Harness Engineering 才真正成立。
真正被抽象的，不该只是“开发动作”
这也是我这段时间越来越清晰的一个感受。
很多人理解 Harness，还是习惯从“动作链路”去理解：任务怎么分配，模型怎么调度，Prompt 怎么拼，工具怎么接，记忆怎么读写，Verifier 怎么挂进去。
这些都重要，但它们更像是“执行层能力”。
如果一个系统只有这些东西，它可以变得很能干，但不一定会变得很可靠。它也许会越来越会做事，却不一定越来越会把事情做对，更不一定越来越会把系统维持在一个健康状态。
所以真正需要被抽象的，不只是“开发动作”，而是工程秩序本身。
也就是说，我们要抽象的不只是：
- 任务怎么拆
- Agent 怎么协作
- 工具怎么串
- 结果怎么提交
我们更要抽象：
- 什么叫健康的边界
- 什么叫合理的职责
- 什么叫真正完成
- 什么叫一次安全的改动
- 什么叫系统依然保持干净
- 什么叫局部问题不会扩散成全局腐化
这些东西，才是 Harness Engineering 最值得沉淀的部分。
重构，本质上是一种结构恢复
我最近还有一个感受越来越强：重构本质上很像一种错误恢复。
很多人一提到错误恢复，会想到重试、回滚、补偿、故障转移。这些当然都对，但那更多是运行时视角。
如果把代码库本身看成一个长期运行的系统，就会发现它也需要恢复机制。
一个需求做完后，边界被轻微破坏了一点。 一段重复逻辑多了一份。 一个特殊分支又塞进公共模块里。 一个临时方案被默认保留下来。 一个小妥协变成新的常态。
这些问题短时间内未必爆炸，但如果没有恢复机制，它们会在后续迭代中不断累积，最后拖垮整个系统的可维护性。
所以从工程演化的角度看：
修 bug，是行为层恢复。
重构，是结构层恢复。
门禁，是预防性恢复。
Review，是认知层恢复。
规范沉淀，是免疫记忆形成。
这个视角很重要，因为它会改变我们设计 Harness 的方式。
好的 Harness 不该只会“生成”，它还要会“恢复”。 功能可以写偏。 抽象可能失效。 边界可能被污染。 规则也会随时间漂移。
一个成熟的系统，应该知道什么时候做局部修补，什么时候做结构收口，什么时候该回退重来，什么时候该把某类问题升级成规则。
真正该沉淀的，是工程秩序
所以我现在越来越认同一个判断：
Harness Engineering 最值得抽象的，不是某个模型调用方式，也不是某个 Agent 的 Prompt 模板，而是工程秩序本身。
真正长期稳定的东西，通常不是某个具体需求，也不是某个工具栈，更不是这次调用哪一个模型。
更稳定的，往往是这些问题的答案：
什么叫健康的边界。
什么叫合理的职责。
什么叫真正完成。
什么叫一次安全的改动。
什么叫系统依然保持干净。
什么叫局部问题不会扩散成全局腐化。
换句话说，优秀程序员脑中的“工程直觉”，其实可以拆开：
把边界感拆成规则。
把洁癖拆成约束。
把完成定义拆成验收门。
把恢复意识拆成回修与重构流程。
把复盘能力拆成错误分类与规则升级机制。
最后形成一个真正有闭环的系统：
任务进入。
系统识别任务类型。
自动装配约束。
Agent 执行实现。
多维度验证。
发现偏差。
触发回修或重构。
沉淀经验。
更新规则。
当一个系统具备这样的闭环，它就已经不只是“会写代码”，它开始具备某种工程免疫力。
优秀程序员和优秀 Harness，本质上在做同一件事
如果把全文收束成一句话，我会这样概括：
优秀程序员，是把工程秩序内化为个人习惯的人。优秀 Harness Engineering，是把这种工程秩序外化为系统能力。
前者依赖个人修养。 后者追求机制复制。 前者让少数高手长期守住质量。 后者让更多人、更多 Agent、更多任务，也能在同样的秩序下工作。
所以，Harness Engineering 真正值得做的，不只是自动开发流水线。
它更像是在做一件更有价值的事：
把优秀程序员身上最稀缺、最难传授、最容易流失的工程自律，沉淀成一套可以被重复执行的系统。
当你这样理解它，很多具体问题都会重新排序。
Prompt 只是手段。
模型只是执行器。
多 Agent 只是编排方式。
Skill、Memory、Review、Verifier 只是部件。
真正的核心，是你有没有把“优秀工程师如何维持秩序”这件事抽象清楚。
这件事一旦想明白，Harness Engineering 的方向就会清晰很多。
因为你终于知道，自己真正要造的，到底是什么。
你要造的，不只是一个会自动开发的流水线。 你要造的，是一个能抵抗破窗、能在偏航后自我恢复、能从错误中长出新规则的工程系统。
而这，可能才是 Agent 时代最值得做的工程。