Vibe coding 都没学完，Prompt Engineering 课还在卖，Context Engineering 墨迹还没干，现在又来一个——AI圈造新词的速度赶上模型迭代了。
但等等，这不就是我过去半年一直在干的事儿吗？写 CloudMD 告诉 AI 我是谁、什么规则必须遵守；配 Hooks 在 Agent 的关键节点注入检查；建知识库给 AI 准备决策需要的上下文；调 Skills 定义 AI 能用什么工具、有什么权限。
Harness 这个词的英文原意是马具、缰绳。不是马本身，是套在马身上、让它能拉车、能被引导的那整套东西。没有它，马就是一匹乱跑的野马——力气再大也白搭。
三层关系：Prompt vs Context vs Harness
这三层关系很好懂：
- Prompt Engineering：是你对马说的话——"向左转"、"跑快点"
- Context Engineering：是帮马看路的——地图、路标、地形
- Harness Engineering：是缰绳、马鞍、围栏和道路本身——让十匹马同时安全跑起来的系统
Prompt 管你问什么；Context 管你给模型看什么；Harness 管整个东西怎么运转。
LangChain实战案例：换套缰绳，排名从30跳到前5
先说最硬的一个数据：LangChain 的 Coding Agent 在 Terminal Bench 2.0 上的成绩从 52.8% 涨到了 66.5%，排名从 Top 30 跳到 Top 5。
重点是：模型完全没换。他们只改了三种东西——系统提示词、工具配置、中间件钩子。同一个模型，换了套缰绳，成绩天差地别。
模型可能已经不是瓶颈了，瓶颈是你给它搭了个什么样的环境。
OpenAI Codex实验：100万行代码与没人问的问题
然后是 OpenAI 自己的实验。Codex 团队三个工程师（后来扩到七个），五个月时间，用 Codex 搞出了一个 100 万行代码的 Beta 产品，零行人工手写，约 1500 个 PR 合并。
这些数字很炸，但有个问题没人聊：这 100 万行代码的质量怎么样？
速度快了十倍，不代表产出好了十倍。每人每天 3.5 个 PR，谁在做代码审查？六个月后需要改需求的时候，这 100 万行好改吗？
Harness三要素详解
Martin Fowler 把 Harness 拆成了三块：
第一块：上下文工程
给模型一张地图，不是一本 1000 页的说明书。维护一个持续更新的代码库知识库，加上 Agent 能实时看到的系统状态。
上下文是稀缺资源——塞太多反而挤占干活的空间。
第二块：架构约束
不光靠 AI 自己检查，还有代码检查器和结构测试在旁边盯着。硬规则，不遵守就编译不过。
第三块：垃圾回收
专门有个 Agent 周期性运行，不写代码不做功能，就干一件事——找文档里的矛盾和架构违规。一个专职找茬的 AI。
Anthropic的三Agent架构
Anthropic 走了另一条路。他们搞了个三 Agent 的架构：
- 规划者（Planner）：负责把简单指令扩展成详细的产品规格
- 生成者（Generator）：按迭代一次做一个功能
- 评估者（Evaluator）：跑端到端测试
灵感来自生成对抗网络（GAN）——训练一个专门的评估者让他一直挑刺，比让生成者自己检查自己管用得多。谁都不擅长批评自己，AI 也一样。
他们还发现 Claude Sonnet 4.5 有"上下文焦虑"：上下文太多，表现反而变差。压缩不够，必须定期清空重来。
Harness 不是越大越好——这可能是最反直觉的部分。
历史渊源：60年前的航天工程师就在做类似的事
到这里，你可能想：这不就是给老东西起了个新名字吗？说实话还真有点。
航天工程师 60 年前就在做类似的事了。 NASA 让飞船自动执行任务，围绕自动化系统设计的约束、反馈循环、冗余检查、异常处理——和今天说的 Harness 没有本质区别。
工业控制领域也一样，PLC 编程里的安全连锁机制就是一种 Harness。
AI 圈不是发明了 Harness Engineering，是终于意识到自己需要学几十年前就有的工程纪律。
个人实践：从零开始搭建 Harness
作者去年 8 月搭了 CloudMD 自动化写作工作流，从那以后写文章轻松太多，平时做做选择、喷一喷不满意的地方就好了。
但让这套系统好用的不是模型有多强，是围绕它搭的那一圈东西：
- CloudMD 路由器：从一个简单的规则文件变成路由器，就干一件事——判断当前任务属于哪个工作区，然后指向对应的规则。写公众号时不会被 iOS 开发的规则干扰。
- Hooks：在 Agent 的执行关键操作前后注入脚本。编辑文件之前自动跑 linting，生成代码之后自动做类型检查。这不是 prompt 里写的"请注意代码规范"，是物理上拦住他——不合格就不让过。建议和约束完全两回事。
- Skills：解决模块化的问题。
- 知识库：给 AI 准备决策需要的上下文。
路由器 + Hooks + Skills + 知识库加在一起，就是一个 Harness。
这个生长方式和 Mitchell Hashimoto（HashiCorp 联合创始人、Terraform 创造者）说的一样。他在 2026 年 2 月写了《My AI Adoption Journey》，首次给这个实践命名。
方法极其朴素：每次 Agent 犯错，就工程化一个方案让他再也犯不了同样的错。他拿自己的终端模拟器 Ghost 举例——配置文件里每一行都对应着 Agent 过去犯过的一次错。文件是活的，一直在涨。
如果你想开始，三条就够：
- 给地图，不给说明书。CloudMD 应该像地图——项目结构、文件关系、关键约束，不要把每步都写死。AI 需要方向感，不需要僵化步骤。
- 每次犯错加一条规则。空文件开始，Agent 犯一个错就加一条。三个月后，那个文件就是你的 Harness——高度定制，因为全是你场景里真实出过的问题。
- 让 AI 查 AI。Anthropic 的 Evaluator 思路，别让 AI 自己查自己。最简单的做法：写完后开一个新对话，把结果贴进去，找出所有问题。你会惊讶第二个 AI 能发现多少第一个漏掉的。
Martin Fowler的"经验工程"问题
最后聊一个我想了很久的问题。Martin Fowler 在文章里说：如果太早把人类从 "in the loop" 移到 "on the loop"，将来可能没人真正懂得怎么回事，也就没人能设计好的 Harness。
这句话值得多读两遍。
现在设计 Harness 的人都是写过很多年代码的老手。Mitchell Hashimoto 能给 Ghost 写好 Harness，因为他理解终端模拟器的每个细节。OpenAI 那三个工程师能驾驭 100 万行代码，因为他们知道什么架构是好的、什么会在三个月后爆炸。
但下一代呢？新手程序员从第一天起就不写代码，只写 CloudMD，他能设计出好的 Harness 吗？
Martin Fowler 把这叫"经验工程"——怎么在 AI 写所有代码的时代培养新人？
作者自己是个有意思的样本：从来没手写过代码，所有产品都是 AI 写的，小猫补光灯上了 App Store 付费榜 Top 1，累计用户超百万。他的 Harness 从零开始，在和 AI 互动中一点一点长出来，没有任何编程经验可以迁移。
但他得对自己诚实：能设计 Harness 不是因为天生懂系统设计，是因为在和 AI 协作的上千小时里观察到了它的行为模式——它什么时候偷懒、什么时候幻觉、什么时候需要硬约束而不是温柔提醒。
这些判断力不来自写代码的经验，但来自另一种经验——和 AI 反复较劲的经验。
问题可能不是"写代码的经验能不能被替代"，而是不管你积累的是什么经验，足够多的经验本身就是设计 Harness 的前提。没有捷径，换了个赛道而已。
总结：Harness是长出来的
以上就是本期内容的要点。
Harness Engineering 不是新发明——是让一群人意识到自己工作的重心变了。没有捷径，但只要开始踩坑，你的 Harness 就会一点点长出来。
留给你想：你愿意花够多时间、踩够多坑吗？
本文内容整理自 B站视频 (b23.tv/n3zCqUv)
← 返回博客首页