说实话，看到 OpenAI 那篇《Harness Engineering》的时候，我正在改一份 300 行的 CLAUDE.md。
不是第一次改。是第 N 次。
每次 Agent 犯了个错，我就得回去加一条规则。改完再跑，大概率又冒出新问题，于是再改。这个循环来来回回几十次之后，那份文档变得像一部宪法——有架构规范、命名约定、错误处理策略、甚至”禁止做什么”的负面清单。
我一边改一边觉得自己在浪费时间。
写代码才是正事吧？
直到我读到那篇文章。然后我意识到一件事——
这不是浪费时间，这就是工作本身。
一个百万行代码的实验#
OpenAI 做了个实验。
3 个工程师，5 个月，从空仓库开始，用 Codex Agent 构建了一个超过 100 万行代码的产品。
1500 个 PR，平均每人每天 3.5 个。所有代码由 Codex 生成，没有一行手写。
第一反应可能是：AI 真牛逼。
但仔细读下来，最有价值的部分不是”AI 多牛”，而是他们踩了哪些坑。
早期进展比预期慢得多。
不是因为 Codex 编码能力不够。而是环境没搭好——Agent 不知道项目的依赖结构，不理解架构约束，无法验证产出是否正确。
给它一个任务，它能写出代码。但写出来的代码经常违反设计原则——然后需要人来 review、人来改、人来解释”为什么不能这么做”。
跟一个新人入职的体验几乎一模一样：能力没问题，但不了解组织的规矩。
他们花了大量时间做一件事：
把规矩写下来，让机器能读懂。
调速器的工人后来去哪了#
知乎上 @riba2534 的回答让我想到了一个类比。
1780 年代，蒸汽机刚出现。工人得守在旁边，盯着压力表，手动拧阀门。转速太快就关小，太慢就开大。一个人同时充当传感器和执行器。
后来 James Watt 发明了离心调速器——一个带飞球的机械装置。转速快了飞球升高，自动关小阀门；慢了就降低，自动开大。
工人的角色变了：从亲手拧阀门，到设计调速器本身。
2010 年代，同样的事又发生了一次。
你不需要 SSH 进服务器手动重启进程了。Kubernetes 让你声明一个目标状态——“我要 3 个副本、每个 2G 内存”——控制器会持续监测，有偏差就自动修正。
工程师从手动运维，变成了编写目标 spec。
然后是现在。
OpenAI 那 3 个工程师不写代码了。他们设计运行环境、构建反馈回路、把架构约束编码成可执行的规则。Agent 生成代码，Linter 和测试自动验证，不合格的打回重来。
三次转变，同一个模式。
Norbert Wiener 在 1948 年给这个模式取了个名字：控制论（cybernetics）。
这个词来自希腊语 kubernetes——舵手。
没错，Kubernetes 的名字也来自同一个词根。
从亲手划桨，到开始掌舵。每一次都是这样。
为什么代码是最后被攻克的？#
编译器早就知道语法错不错了。测试框架早就知道行为对不对了。Linter 早就知道风格合不合规了。
这些底层反馈回路存在了几十年。但它们只能回答”是什么层面”的问题——
这行代码能编译吗？测试跑得通吗？格式对不对？
它回答不了的问题是——
这个架构决策合不合理？这个抽象层次划分得对不对？这个设计三之后会不会变成技术债？
架构层面的判断，既没有传感器来感知，也没有执行器来修正。
直到 LLM 出现。
LLM 能理解代码的意图（传感器），也能生成新代码（执行器）。当你把架构规范写成文档、把设计约束编码成 Linter、把质量标准变成 CI 检查——你第一次在架构层面闭合了反馈回路。
Nicholas Carlini 做过一个实验：让 16 个 Agent 并行构建一个 C 编译器。他事后说：
“我大部分的精力都花在设计 Claude 周围的环境上。”
和 OpenAI 那 3 个工程师做的，是同一件事。
Harness 到底长什么样？#
如果你把 Agent 想成”一个会调用工具的大脑”——
那 Harness 就是你给这个大脑配的身体、传感器、护栏、操作台、流程制度和保险。
知乎上 @mCell 用了一个更工程化的拆解，我觉得说得很好：
上下文装配系统。 不是一份大 Markdown，而是一个动态拼装系统——不同来源的信息有不同优先级、不同新鲜度，必须先在工程上把层级建好再交给模型。
工具治理系统。 工具不是”多几个 function call”那么简单——模型如何发现工具、参数如何校验、风险如何分级、调用如何被拦截，这些必须是一个可治理的系统，不能是一堆裸奔接口。
安全与审批系统。 只要 Agent 能写文件、跑 shell，它就不只是聊天模型了。安全边界不能只靠”请在 prompt 里加一句不要做危险操作”。得落在运行时。
反馈与状态系统。 Agent 能持续做事，不是因为会一直”想”，而是因为不断收到反馈——执行结果、审批状态、输出截断、命令拒绝。你要把系统内部发生的事翻译成模型能消费的反馈语言。
熵管理系统。 这层很多人忽略。Agent 持续运行，系统一定会”变脏”——prompt 越来越长、rules 越来越旧、memory 里混入无效信息。OpenAI 那篇文章说得很直白：当一切都重要时，一切都不重要。
同一个模型，换了个底盘#
让我最震撼的数据不是”100 万行代码”。
是这几个：
- SWE-agent： 同一个模型，仅靠 Agent-Computer Interface 的设计改进，性能提升 64%。
- IBM Research： 纯 LLM 代码审查捕获 45% 的错误；加上确定性工具后，跳到 94%。
- LangChain： 没换模型，只优化了 Harness，Terminal Bench 2.0 成绩从 52.8% 升到 66.5%，排名从 Top 30 跳到 Top 5。
模型没变，变的只是 Harness。
@mCell 在回答里说了一句话：
“我在 memo code 里故意用一个将近一年的 DeepSeek 模型来测。因为我想验证的不是’模型天赋有多高’，而是’环境设计能把一个普通模型托到什么程度’。”
这比”换个新模型突然变强”有价值得多。
两派人，谁对？#
行业对这个方向有真实分歧。
“Build Heavy Harness”阵营 ——OpenAI、Stripe（Minions Agent 每周合并 1000+ PR）、Cursor（500 亿美元估值）。证据扎实，市场在用真金白银投票。
“Trust The Model”阵营 ——Anthropic 的 Claude Code 团队明确表示”模型之上尽可能薄的包装层”。Noam Brown 说过：为较弱模型构建的复杂脚手架，会被更强的模型替代。
两边都有道理。
但我的判断是：这不是二选一。
编译器越来越强大，我们并没有丢掉 CI/CD。因为验证和约束是独立于工具能力的需求。你的架构规范不会因为模型变强就不需要了。你的测试不会因为 Agent 写得更好就可以删掉。
Ben Thompson 用价值链理论说得很清楚：利润从商品化的模块流向集成的环节。模型正在被商品化——越来越多公司提供越来越相似的模型。model + harness 的集成才是难以复制的差异化。
Martin Fowler 提了两个尖锐的问题：100 万行代码跑起来到底对不对？从零开始的 AI-native 仓库和改造一个 10 年老仓库，完全是两回事。
这两个问题没有人能回答。但不回答不代表这件事不重要。
所以工程师到底在干什么？#
回到开头那个问题——写 CLAUDE.md 花的时间比写代码多，是不是废了？
不是。
瓦特调速器的工人后来没有回去拧阀门。
不是因为他们不会拧。
是因为回去拧阀门这件事，已经没有任何意义了。
但我还想补一句三个回答都没说透的话——
Harness Engineering 不是因为 AI 才有的需求。它是一直存在、但一直被忽视的软件工程。
文档、测试、架构约束——这些”最佳实践”我们喊了 30 年。为什么以前可以跳过？
因为代价来得很慢。
一个开发者写出违反架构规范的代码，code review 打回，改一遍，重新提交。就算 review 没发现，技术债也是几个月后才爆发。你总归拖得起。
但 Agent 时代这个等式变了——
一个没有被规范约束的 Agent，会以机器的速度、全天候地重复同样的错误。
跳过文档的代价从”慢”变成了”不可承受”。
所以该做的事情从来没变过。只是不做这些事的代价，终于变得你躲不掉了。
你们团队开始搭 Harness 了吗？目前踩了什么坑？评论区聊聊。
我在知乎上看到一个观点挺有意思：未来最值钱的工程师，不是代码写得最快的，而是 CLAUDE.md 写得最好的。你同意吗？