2026年2月OpenAI 在官方博客发表了一篇名为《Harness Engineering: Leveraging Codex in an Agent-First World》的文章。核心内容只有一件事一个三人工程师小组用五个月时间完全依靠 AI Agent 交付了约 100 万行代码、1500 个 Pull Request全程没有任何人手动写过一行代码。数字本身并不稀奇真正值得关注的是这件事发生的时间节点以及它背后折射出来的工程范式转变。三个人五个月一个不成文的规定2025年8月OpenAI 内部一个三人小组承接了一个新产品开发任务。他们给自己设了一条规则所有代码必须由 Codex AI Agent 生成人类工程师不动键盘写代码。五个月后产品上线。代码库约 100 万行人均每天合并 3.5 个 Pull Request。Martin Fowler 在评价这项实验时说“Harness Engineering 包含了上下文工程、架构约束和垃圾回收是对 AI 赋能软件开发的一种有价值的框架性阐述。”这个实验之所以值得关注不是因为它证明了 AI 能写代码——这一点早已无需证明——而是因为它回答了一个更具体的问题当 AI 真的可以承担大部分编码工作时工程师究竟该做什么“驾驭”是什么意思Harness在英文里本义是马具、挽具——不是让你骑马而是让马老老实实拉车。OpenAI 用这个词是在描述一种特定的工程师角色不再生产代码而是设计一个让 AI 能把事做对的环境。这和“Prompt Engineering”有本质区别。写提示词是告诉 AI 怎么做这件事Harness Engineering 是提前把“这件事的上下文、约束和验证方式”设计成 AI 可以理解的结构让它在这个环境里自主运行。三人团队的核心实践可以拆成几个具体动作他们写了一份叫 AGENTS.md 的文档只有 100 行。这不是使用手册而是索引——里面存的是架构图、设计规范和执行计划的入口类似代码库的 README但服务对象是 Agent 而不是人类。规则很严格关键知识只能活在代码库里禁止散落在 Slack 消息或口口相传的讨论里。他们给 Agent 装上了眼睛。通过集成 Chrome DevToolsAgent 可以自己截图验证 UI 渲染结果不需要人类反复确认页面对不对。Agent 写完代码、运行测试、看截图、发现问题、自己修形成一个闭环。他们刻意选择“无聊”的技术栈。这条实践看起来反直觉但逻辑很清晰训练数据里出现越多的库和框架Codex 对它的理解就越准确出错率越低。用冷门的新库等于让 AI 在没有地图的地方开车。还有一个被他们称为“垃圾回收”的机制后台运行一个周期性 Agent定期扫描代码库里的技术债——过时的依赖、被注释的死代码、违反架构约束的模块——自动提交修复 PR。人类工程师不需要主动触发这件事它就在那里自动跑着。Cursor 的对照实验几乎在同一时期Cursor 团队做了一个更极端的实验用数百个 Agent 并行运行整整一周从零开始用 Rust 写一个浏览器引擎最终产出超过 100 万行代码。这个实验一开始并不顺利。第一版架构让所有 Agent 地位平等通过共享状态文件协调工作。结果 20 个 Agent 的吞吐量退化到相当于 1 至 3 个 Agent。原因是典型的“风险厌恶”在没有明确分工的情况下每个 Agent 都倾向于只做安全的小修改真正复杂的任务没有人敢碰。后来他们试过流水线Planner-Executor-Worker-Judge又试过让 Executor 同时承担规划职能——每次都有改进也有新的瓶颈。最终跑通的方案是“递归 Planner 加独立 Worker”根 Planner 持有全局视野当任务可以继续分解时递归生成子 Planner每个 Worker 只接触自己负责的那份代码副本互不感知完成后提交交接报告。Cursor 自己总结这个实验的核心发现时说高吞吐量 Agent 开发需要接受“不完美但快速迭代”的哲学而不是追求一次性完美。允许一个稳定的低错误率让后续 Agent 快速修复反而比强制 100% 正确率更有效。两个团队两套实验在同一个时间节点独立得出了基本相同的结论人类工程师的核心价值正在从写代码转向设计 AI 的工作环境。爆火的“龙虾”成为这套方法论最佳实例Harness Engineering 发布的两周前另一件事刚刚发生。奥地利开发者 Peter Steinberger 在2025年11月某个周末写了一段脚本让 Claude 通过 WhatsApp 控制电脑。这个项目最初叫 Clawdbot发布当天在 Hacker News 上走红随即遭到 Anthropic 的商标律师函“Clawd”与 Anthropic 产品名“Claude”冲突。几小时内改名 MoltbotTwitter 账号立即被加密货币骗子抢注。三天内第三次定名 OpenClaw同步完成商标检索和 34 个安全加固提交。这场品牌危机意外带来了更大的曝光。2026年1月底OpenClaw 的 GitHub Stars 突破 20 万成为有记录以来增长最快的开源 AI Agent。对比Linux 达到 10 万 Star 用了 12 年React 用了 8 年。Steinberger 后来在博客里写OpenClaw 的核心使命是“让我妈妈这样的普通用户也能用上 AI Agent”。它的架构设计和 Harness Engineering 的底层逻辑高度吻合不是构建一个复杂的 AI 模型而是设计一套让人类能够安全、灵活驾驭 Agent 的接入层——标准化的技能接口、细粒度的权限控制、本地化部署支持。2026年2月15日Sam Altman 宣布 Steinberger 加入 OpenAI负责“下一代个人智能体”研发。项目本身移交独立基金会MIT 协议不变OpenAI 作为赞助方。Steinberger 写道加入 OpenAI 是实现这个愿景的“最快路径”而且他本质上是一个建造者不是一个想经营大公司的人。一个月后的 GTC 大会NVIDIA CEO 黄仁勋在主会场演讲中将 OpenClaw 与 Linux、Kubernetes 并列发布基于它的企业级安全层 NemoClaw——运行在 OpenClaw 之下提供内核级沙箱、进程外策略引擎和隐私路由三项能力。目标是让企业能在自有硬件上安全部署 Agent同时满足数据主权要求。TechCrunch 的标题直接点破了这件事的逻辑“NVIDIA 的版本能解决 OpenClaw 最大的问题安全。”Harness Engineering 谈的是工程师如何“驾驭”AINemoClaw 回答的是企业如何把这套驾驭建立在可信的基础设施上。两件事拼在一起完整描述了 2026 年上半年硅谷 AI 工程实践的演变方向。一个悖论这套方法论的传播速度很快质疑也随之而来。Anthropic 做了一项调查数据显示 Harness Engineering 风格的工作方式让工程师生产力提升了 50%。但调查同时发现了一个问题工程师依赖 AI Agent 的时间越长独立判断 AI 输出质量的能力就越弱。换句话说你驾驭得越熟练你对“马”的理解反而越模糊。OpenClaw 社区自己也给这个隐忧提供了具体注脚。CVE-2026-25253 漏洞让约 4 万台 OpenClaw 实例暴露于远程代码执行风险ClawHub 技能平台遭遇恶意投毒ClawHavoc事件Bitdefender 和微软相继发出警告称不应直接在企业工作站上运行未经审查的 OpenClaw Agent。“驾驭”并不只是效率问题也是对风险的感知与控制能力。真正的问题或许不是这套方法论是否有效而是当工程师越来越擅长设计 AI 的工作环境却越来越难以直接审计 AI 的工作结果这中间的那段信任究竟该落在哪里。这个问题Harness Engineering 的博文里没有答案OpenClaw 的代码库里也没有。参考来源https://openai.com/index/harness-engineering/https://cursor.com/blog/self-driving-codebaseshttps://steipete.me/posts/2026/openclawhttps://techcrunch.com/2026/03/16/nvidias-version-of-openclaw-could-solve-its-biggest-problem-security/https://investor.nvidia.com/news/press-release-details/2026/NVIDIA-Announces-NemoClaw-for-the-OpenClaw-Community/default.aspxhttps://www.cnbc.com/2026/02/15/openclaw-creator-peter-steinberger-joining-openai-altman-says.html