以天为单位革新的AI圈，Harness早已不算什么新词

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 DevTools，Agent 可以自己截图验证 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”冲突）。几小时内改名 Moltbot，Twitter 账号立即被加密货币骗子抢注。三天内第三次定名 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 谈的是工程师如何“驾驭”AI；NemoClaw 回答的是企业如何把这套驾驭建立在可信的基础设施上。两件事拼在一起，完整描述了 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-codebases
  

• https://steipete.me/posts/2026/openclaw
  

• https://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.aspx

• https://www.cnbc.com/2026/02/15/openclaw-creator-peter-steinberger-joining-openai-altman-says.html