你以为写代码是程序员的终极技能？OpenAI最近一篇帖子直接把这个幻想砸碎了：他们用Codex代理（他们的AI编码代理）在五个月里建了一个内部产品，代码量上百万行，零行手工敲的。工程师不再写代码，而是设计环境、建反馈回路、编码约束——代理自己去生成、测试、部署一切。这听起来像科幻，但它已经发生在2026年2月11日的OpenAI官方博客《Harness engineering: leveraging Codex in an agent-first world》里。

读着读着，我突然有种熟悉的既视感。不是第一次看到这套路，而是第三次。第一次是1780年代詹姆斯·瓦特的离心调速器（centrifugal governor）。以前蒸汽机需要工人站在旁边手动调阀门，速度太快就手动关小蒸汽，太慢就开大。瓦特搞了个带重球的飞球装置：转速高，重球飞起，拉动阀门自动减蒸汽；转速低，重球落下，开大蒸汽。工人没消失，工作变了——从手动调阀，变成设计和调校这个“调速器”。

第二次是Kubernetes。以前运维工程师手动重启服务、扩容pod、回滚部署。现在你只声明“想要的状态”：三个副本、这个镜像、这些资源限制。控制器不停观察实际状态，一旦偏离，就自动调和：重启崩溃的、扩容、回滚。工程师的活儿从“救火”变成“写好spec，让系统自己对齐”。

第三次就是现在。OpenAI工程师不再写代码，而是建“harness”（约束系统）：定义意图、建反馈回路、编码架构约束。然后代理去干脏活累活。百万行代码，五个月，零手工。工程师的工作从“实现”变成“掌舵”。

这三个例子，同一个模式。1948年诺伯特·维纳（Norbert Wiener）给它起名：控制论（cybernetics），希腊词源“kubernētēs”——舵手。你不再转阀门，你掌舵。每次模式出现，都是因为有人建了足够强的传感器和执行器，让反馈回路在那个层级闭合。

为什么代码库是最后一个顽固堡垒？

以前代码库也有反馈回路，但只在低层：编译器检查语法、测试套件验证行为、linter检查风格。这些是真正的控制论控制，但只管机械可查的东西。更高层——这个改动符不符合系统架构？这个抽象会不会在代码长大后爆炸？——没有传感器和执行器。只有人类能同时判断“好坏”和写修复。

LLM把两端同时砸开。它能“感知”人类以前专属的层级（理解架构、意图、权衡），也能“执行”在那个层级（重构模块、改接口、围绕实际契约重写测试）。第一次，反馈回路能在真正重要的决策层闭合。

但闭合回路只是必要条件，不是充分。瓦特的调速器需要调校。K8s的控制器需要正确的spec。LLM在你代码库上工作，更难调校。

入门级：建基本回路——代理能跑的测试、能解析的CI输出、能指向修复的错误消息。Nicholas Carlini用16个并行Claude代理建C编译器时说：“我大部分精力花在设计Claude周围的环境——测试、环境、反馈。”简单prompt，但基础设施精心设计。

难的部分：用你系统的专有知识校准传感器和执行器。大多数人卡在这里，还怪代理：“它老做错，不懂我们代码库。”诊断错了。代理不是能力不足，是知识没外部化。你的“好”标准、架构偏好、禁忌模式，全锁在你脑子里，没写下来。代理不会通过渗透学习。如果你不写，它第一百次还犯第一次的错。

工作就是把你的判断变成机器可读：真正的分层和依赖方向的架构文档、带修复建议的自定义linter、编码团队品味的黄金原则。OpenAI自己也这么干：每周五花20%时间清理“AI垃圾”——直到他们把标准编码进harness本身。

往前走的唯一路：文档、自动化测试、编码架构决策、快速反馈回路。这些实践三十年来每本工程书都推荐。大多数人跳过，因为代价慢而分散：质量渐降、上手痛苦、技术债悄然复合。

代理工程让代价极端化。跳过文档，代理每PR都忽略你规范——不是一个PR，是机器速度、全天候。跳过测试，反馈回路根本闭不上。跳过架构约束，漂移速度比你修复快。陷阱是：你没法用代理清理烂摊子，因为代理也不知道啥叫“干净”。

实践没变，无视的惩罚变得无法承受。

生成-验证不对称（P vs NP的直觉，LLM实证由Cobbe等人证明）：生成正确解比验证难。你不需要比机器写得更好，你需要比它评估更好：指定“正确”长啥样、认出输出偏哪、判断方向对不对。

瓦特时代设计调速器的工人，没回去转阀门。不是他们不会，而是没意义了。

从码农到总经理的跃迁，就藏在这里。以前我们写代码，现在我们建harness、掌舵系统。不是取代人类，是把人类从低层体力活解放到高层认知活。

但前提是你得先把自己的判断外化、把“好”写下来。否则代理不是帮手，是放大你混乱的怪物。

读完OpenAI这篇，我最大的Aha：未来工程师不是代码写得快的人，而是“系统舵手”——谁先建好那个能让代理可靠闭环的harness，谁就领先。

兄弟，你准备好从转阀门，变成掌舵了吗？

紫微AI推荐18篇 Harness 精讲

深度综述：Effective Harnesses for Long-Running Agents

2026年AI Agent 的真相，模型成了可互换的引擎，Harness 才是决定 Agent 能不能真正落地的产品

控制论重生：Harness Engineering 才是真正的未来工程师工作

Harnesses & Agent Frameworks 敢诚实回答这个问题的人，从瞎试工具的一人公司，真正变成知道怎么选、怎么用、怎么赚钱的“智能生意人”。

AI Agent 的成功秘诀：Harness 才是产品，模型只是引擎
Harnesses & Agent Frameworks 敢诚实回答这个问题的人，从瞎试工具的一人公司，真正变成知道怎么选、怎么用、怎么赚钱的“智能生意人”。
AI Agent 的成功秘诀：Harness 才是产品，模型只是引擎
Agent Harness 工程实战：文件系统、沙箱、Ralph Loop 与 Middleware 生产级实现（附完整代码）

​​​​​​​​​​​​​​​​​​​​​AI Agent 的核心秘密：不是大模型，而是 Harness 工程

别再试图让 Agent 适应你的代码库，而是让代码库和流程适应 Agent。AI Coding Agent 时代，工程师不再是“码农”？Harness Engineering 实战 playbook

训练环境决定 AI Agent 天花板：Harness 如何塑造 RL 训练循环

AI Agent 时代，模型只是“基础设施”，Harness 才是你真正的产品

从零手把手用本地Ollama + GPT-OSS搭建AI Agent Harness：完全离线、私有、零成本让AI真正“永动机”干活

LLM Agent 非法动作频发？Google DeepMind 用 AutoHarness 自动生成代码“安全带”，小模型直接反超大模型！

Harness 才是王道：为什么 3 个工程师能月产百万行代码，而你的 Agent 还在原地打转？

AI Agent 的本质不是模型，而是流程设计：Harness 才是真正的王牌（实战篇）

大多数开发者以为 AI Agent 拼的是模型能力，但 Anthropic 最新实验告诉你：真正决定成败的是「生成-评估」分离的 Harness 设计

用AI自主开发完整App时，你是不是也卡在“代码看着行、实际一用就崩”？Anthropic的Harness设计给出答案

我是紫微AI，我们下期见。

（完）