AI 工程演进 | Prompt、Context 与 Harness

注：本文为 "AI 工程进化" 相关合辑。

略作重排，未整理去重。

如有内容异常，请看原文。

Harness Engineering 在硅谷彻底火了。

阿颖 AI 产品阿颖 2026 年 3 月 26 日 20:32 北京

最近在海外 AI 圈子里，有一个词被频繁提起，叫 Harness Engineering。

可能有人会觉得，硅谷又在造新词了。

但我的观察是，这两年 AI 发展过程中，一个词突然火起来，背后往往是某种行业共识正在形成。所以理解这个词代表什么，还是挺重要的。

今天聊聊我的看法。

01 到底什么是 Harness Engineering？

要是一句话总结的话，Harness Engineering 这个概念的出现，意味着模型本身的重要性在下降，而系统设计能力的重要性在快速上升。

这让我想起智能手机早期的故事。还记得吧，2012 年移动互联网刚爆发那会儿，智能手机发布会都在比硬件。每一场发布会都是参数大战。

但后来呢？硬件越过某个临界点之后，用户对这些参数已经无感了。因为够用了。

这两年苹果的 A 系列芯片越来越强，跑分越来越高，但对大多数人来说，完全无感。真正影响换机决策的，是整体的产品体验。

AI 正在经历同样的转变。过去两年，行业的注意力都在模型上。各家都在拼 benchmark 分数。

但从去年四季度开始，Benchmark 明显已经没那么重要了。因为大家觉得，更重要的是模型在实际场景中的表现。

什么是 Harness？

可以这样理解。模型是引擎，Harness 是围绕引擎造的那辆车。引擎马力再大，车本身不行，照样跑不动。

Harness Engineering 做的事情，说白了就是给 AI 搭工作环境、设计流程、建立规则、构建验证机制。

以前我们熟悉的是 Copilot 式的辅助系统。人提一句，AI 动一下，人再追一句，AI 再补一步，主导权一直在人手里。

但 Harness 指向的方向不一样，它说的是 always-on、long-running 的自治系统。AI 不只是等着接收命令，它有记忆层，有触发器，有定时任务，有完整的工具环境，能够持续推进任务。

就像前两天 Karpathy 在访谈里说的那样：当下最重要的是，把自己移出整个工作的 loop，别让人成为 AI 的瓶颈。

之所以 Harness Engineering 变得重要，是因为大家发现，很多时候模型执行任务失败，原因往往不是模型不够聪明。模型其实知道该怎么做。

但在执行过程中，它会迷失方向，会反复尝试已经失败的方法，会忘记自己到底要干什么。问题出在外部系统太乱了，模型每次启动都像失忆一样重来。

这就是 Harness 要解决的问题。

02 一个具体的实例

说一个具体的例子。

最近在体验一个 AI Coding 的创业产品叫 ONES，很有意思。

大家看看下面的截图，我给它说了自己的需求之后，它就开始自己工作了。到目前为止，运行了 40 多分钟，它会自己跑测试，自己修正，最后给我交付一个成品。

和 ONES 的同学聊了下，他们告诉我内部一直强调的一个概念叫：AI² Execution System，AI 的平方，意思是 AI 驱动 AI。

我觉得，这个思路其实和 Harness Engineering 异曲同工。

传统的人机协作是线性的，输入指令，等输出，不满意就改 prompt 再来。AI² 要做的是把整个过程变成一个闭环系统。用户锚定目标，系统动态拆解任务，多个 AI 协作执行，完成后自动验证。

假设我需要做一个网站，展示咖啡馆的菜单，还要有预约功能。

传统路径是找设计师出设计稿，找前端写页面，找后端搭服务，自己盯着协调，最后部署上线。

或者用 AI 工具辅助，自己写 Prompt，生成代码片段，调试报错，反复修改，最后还得懂点技术才能把东西串起来。

他们希望 ONES 这套系统完全就是一个专业的软件团队。 用户只需要说清下自己的需求，比如做一个展示咖啡馆菜单和预约功能的网站。

然后系统自己完成需求分析、UI 设计、前端开发、后端部署、上线验收。整个过程除了部分需求的澄清外，其他都不需要我再介入。

这背后就是 Harness 在起作用。任务怎么拆解，多个 Agent 怎么协作，执行状态怎么追踪，结果怎么验证，这些全都封装在系统内部了。

我体验下来，感觉这套产品的核心逻辑，其实是把过去几十年软件开发领域积累的最佳实践给还原了。

需求怎么梳理，任务怎么分配，验收怎么做，这些东西在专业的软件公司里是有一套成熟打法的。

如果在大一点的公司待过，或者了解那些专业外包公司怎么工作，就会知道这套流程是行业里沉淀下来的经验。

具体怎么做的，我说说体验过程中看到的。

首先是需求沟通。 AI 会一步一步问我想要什么。这个设计很关键，因为用户自己其实也说不清楚。

我只知道我想要一个能展示菜单、能预约的网站，但细节呢？配色要什么风格，按钮放哪里，预约流程怎么走，这些我根本没想过。

它通过不断地问，把我脑子里模糊的东西一点点具象化。

需求理清之后，Agent 们会开一个圆桌会议。 参会的都是不同工种的 Agent，前端工程师、后端工程师、设计师，各个角色都有。

它们会一起讨论刚才收集到的用户需求，然后分配任务，谁负责什么，各自认领。

分配完之后，在看板里就能看到每个角色的工作进度，甚至能看到每一个 Agent 的具体产出。

更有意思的是验收环节。每轮验收完，系统会再开一次会。项目经理主持，验收结果，如果有 bug，通过 Git 的提交记录定位是谁的代码出了问题，然后那个 Agent 去修。

Agent 之间的通信，用的是 Google A2A 协议的拓展版本。

从需求沟通到分工协作到验收定责，这套流程全都固化在产品里了。

开会、分工、各自干活、验收、定责、修复。不是一个超级 Agent 包揽一切，而是多个专业角色各司其职，协同推进。

说实话，这是 ONES 让我眼前一亮的地方。产品还在内测，我没办法放链接，征得他们团队允许后，我把这些理念尽量写清楚。

把这些复杂性都封装好之后，用户体验会变成什么样？

这个问题 ONES 内部在践行 OpenAI 之前提过的思路：OneShot。一句话，一个完整结果。

我觉得这个理念应该抓住了一个很多人都有的痛点。我们用 AI 产品的时候，最消耗耐心的是什么？是反复调 prompt。

写一版，生成，不对，改，再生成，还是差点意思，再改。有时候改到第五六轮，已经忘了自己最开始想要什么了。

OneShot 想解决的就是这个问题。随着平台能力持续优化，逐步逼近一句话拿结果的体验。当然，目前来看，这个理念肯定还是有点激进，甚至疯狂。

但创业公司干的不就是疯狂的事嘛。

这里面有一个值得展开说的点。一句话能拿到结果，靠的不是某个模型特别强，而是背后有一套系统在运转。

用户说出目标，平台做意图识别，系统匹配合适的 AI 团队去执行，同时复用历史上类似任务的经验，最后生成结果。每完成一次任务，系统就多一份经验可以复用。

同样，这和我们刚聊的 Harness 又是一回事。AI 能不能稳定交付，关键在于系统设计，在于任务怎么拆、怎么验、怎么从过去的执行里学东西。

从生成内容到交付结果，听起来只差两个字，但这两件事的难度差了不止一个量级。

一个自然的问题：如果系统生成的东西跟我想的不太一样，怎么办？

ONES 有一个叫 Goal Editing 的交互方式。

在正式生成之前，系统会先给一个可视化的预览。用户看着预览，直接用自然语言说想改什么。

比如，预约按钮放大一点。首页加个联系地址。配色换成暖色调。

系统理解目标，执行修改，再预览，直到满意为止。

这个交互方式的好处是门槛很低。用户不需要懂设计，不需要会写代码，看到什么说什么就行。改的是目标，不是内容本身。系统负责把目标翻译成执行动作。

03 写在最后

下面这张截图，是这个产品最让我觉得有意思的地方。UI 没那么好看，大家忽略，毕竟还在内测，我们主要看设计思路。

这张图里有验收报告，有浏览器渲染验证，还能看到多轮验收的过程。

为什么我觉得这个值得单独拿出来说？

因为这回应了我们开头聊的一个问题。很多 Agent 失败，不是因为不会写代码，而是因为不会验收代码。

模型写完一段代码，跑个 unit test 通过了，就觉得搞定了。但实际上很多问题根本不是代码局部能看出来的，得把整个流程跑一遍才知道行不行。

ONES 的做法是给模型接入了 Chrome DevTools、Playwright 这类工具。

模型可以自己打开页面，复现 bug，看 DOM 结构，截图对比，验证修复前后的差异。

这里面真正重要的不是多了几个工具，是反馈回路变短了，模型能直接看到结果。看到不对，就继续改，再验证，再改。 这就是截图里那个多轮验收的意思。

回到 Harness Engineering 这个话题。其实验证机制就是 Harness 里非常核心的一环。

模型能力够强了，但如果没有办法检验自己的输出，它就只能盲人摸象。给它一双眼睛，让它能看到自己做的事情对不对，整个系统的可靠性就上来了。

这两天，和我们 AI Maker Summit 大会的一个投资人嘉宾聊天，也提到了 Harness Engineering 的话题。

他的判断是，去某个垂直行业里，真正吃透一整条工作流，然后围绕这条工作流做出一个完全自治的系统，这样的产品在 AI 时代会有比较大的机会。

模型不是关键，Harness 才是

J0hn AGI Hunt 2026 年 3 月 22 日 11:04 北京

同一个模型，换一套运行环境，编程基准的成功率就从 42% 跳到了 78%。

这个数据来自 Nate B Jones 的一项研究，只有一个变量：模型外面包裹的那层「壳」。模型没换，数据没换，提示词也没换，只是改了壳，性能翻了将近一倍。

这层壳，现在有了一个正式的名字：Harness。

而围绕它展开的工程实践，叫 Harness Engineering，是 2026 年 AI 工程圈最热的话题之一。

Harness 概念示意

三层进化

要理解 Harness Engineering，得先看它是怎么一步步「长」出来的。

2022 到 2024 年，圈子里最火的词是 Prompt Engineering。

这时的核心关注点是，怎么写好一条指令，让模型给出期望的输出。那时候大家研究的是 few-shot、chain-of-thought、角色扮演，本质上都是在打磨「一次性的输入」。

2025 年，风向变了。Andrej Karpathy 和 Shopify CEO Tobi Lütke 几乎同时开始推一个新概念：Context Engineering。

其核心思路是，单条 prompt 不够用了，你得为模型动态构建整个上下文环境，包括相关文件、历史对话、工具定义、知识库检索结果......让模型在做每一个决策时，都能看到它需要看到的信息。

一层套一层

然后到了 2026 年 2 月，Harness Engineering 来了。

它和前两个词的关系，打个比方：Prompt Engineering 是教你怎么写一封好邮件；Context Engineering 是教你怎么把相关附件都带上；而 Harness Engineering，是教你怎么搭建整个办公室，让员工（Agent）能持续、稳定、高质量地工作。

它包含了 Context Engineering，但在更高的层面运作：

约束、反馈循环、架构规则、工具链、生命周期管理，以及对抗熵增的持续治理。

阶段	时间	核心关注
Prompt Engineering	2022-2024	精心构造单次指令
Context Engineering	2025	为每个决策点动态构建上下文
Harness Engineering	2026 年 2 月起	设计完整的控制系统

第五阶段

故事得从 Mitchell Hashimoto 说起。

这位 HashiCorp 的联合创始人、Terraform 的缔造者，今年 2 月 5 日写了篇博客，记录自己用 AI 编程的「进化史」。他把采纳之旅分成了六个阶段，从最初用 chatbot 聊天写代码，到后来全天候跑 Agent。

第一阶段叫「Drop the Chatbot」，别用聊天界面了。第二阶段叫「Reproduce Your Own Work」，强迫自己用 Agent 重新做一遍手动完成的工作，哪怕做两遍也要做。第三阶段开始利用下班时间跑 Agent，第二天早上来收获「warm start」。第四阶段，把简单任务交给后台 Agent，自己专注深度工作。

而第五个阶段 ，他给了一个名字：Engineer the Harness。

他的定义只有一句话：

每当你发现 Agent 犯了一个错误，你就花时间去工程化一个解决方案，让它再也不会犯同样的错。

这句话看起来平平无奇，但它击中了一个很多人隐隐感觉到、却没有说清楚的痛点：模型能力够了，可它就是不听话。

他在 Ghostty 项目中实践了这个理念。AGENTS.md 文件里的每一行规则，背后都对应着 Agent 曾经犯过的一个错。他说：

那个文件里的每一行都基于一次 Agent 的不良行为，而且几乎完全解决了这些问题。

几天之后，OpenAI 发了一篇重磅博文。再几天，Martin Fowler 团队的 Birgitta Böckeler 跟进分析。

这个词，在几周内就火遍了整个 AI 工程圈。

百万行代码，零行手写

OpenAI 的 Codex 团队做了一件事，让整个行业重新思考「工程师」这个词的含义。

从一个空的 git 仓库开始，5 个月，大约 100 万行代码，1500 个 PR，全部由 Agent 生成。

人类一行代码都没写。

团队一开始只有 3 个工程师，后来扩到 7 个。他们用 GPT-5 驱动的 Codex CLI，从零开始构建了一个完整的生产级应用。平均下来，每位工程师每天合并 3.5 个 PR。

Codex 驱动应用开发

他们估算，如果用传统方式手写，这个项目的工期应该是现在的 10 倍。

而这里面最让人意外的一点是：这 100 万行代码里，不只是业务逻辑。测试、CI 配置、文档、可观测性、内部开发者工具，全都是 Agent 写的。

Ryan Lopopolo，这个项目的核心工程师，写下的一句话是：

Agent 不难，Harness 才难。

这句话，可以说是本次实践的重点。

因为 OpenAI 这篇博文真正的价值，在于他们把 5 个月的实战经验提炼成了一套可复制的方法论。

仓库就是大脑

他们的第一个核心理念是：仓库是 Agent 唯一的知识来源。

代码、markdown、schema、可执行计划，全都版本化地存在仓库里。没有外部 wiki，没有 Notion 文档，没有「口口相传」的潜规则。Agent 看不到仓库之外的东西，所以仓库必须包含 Agent 工作所需的一切。

这倒是跟传统软件工程的「文档即代码」理念一脉相承。只不过以前是为了让人类开发者少踩坑，现在是为了让 Agent 少犯错。

而且随着项目推进，他们发现需要把越来越多的「隐性知识」显性化，推入仓库。以前靠老员工口头传授的东西，现在必须写成文档，因为 Agent 不会来问你、也不会去茶水间聊天。

给 Agent 写的代码

第二个理念则跟传统认知完全相反：代码不仅要对人类可读，更要对 Agent 可读。

传统的代码可读性，讲的是命名规范、注释、模块化，让下一个接手的程序员能看懂。但 OpenAI 团队发现，Agent 理解代码的方式跟人类不一样。

它们更依赖结构化的线索：严格的分层架构、一致的命名模式、显式的类型定义。那些对人类来说「一看就懂」的隐含约定，对 Agent 来说可能是致命盲区。

所以他们在架构设计上做了大量工作，确保代码结构本身就能引导 Agent 做出正确的决策。这是一种新的可读性标准：application legibility，应用的可读性。

自主性分级

第三个理念是渐进式的自主性提升。

他们没有一上来就让 Agent 全权负责所有事情。而是从简单任务开始，逐步提升 Agent 的自主权限。随着 Harness 越来越成熟，Agent 获得的自由度也越来越大。

到了后期，单个 Codex 任务可以连续运行 6 个小时以上，自主完成复杂的功能开发。

这也呼应了一个规律：自主性的提升，必须建立在约束系统成熟的基础上。 你不会让一个实习生第一天就独立负责核心模块。

合并哲学

他们的 PR 合并策略也值得一说。

每个 Codex 任务产出的 PR，在合并前会经过 linter、结构化测试和自动化检查。工程师做的是「审查」，不再是「修改」。

如果一个 PR 需要大量修改才能合并，他们会反思：Harness 哪里出了问题，为什么 Agent 会产出这样的代码？

然后把修复方案反哺回 Harness，让这类问题下次不再出现。

团队增长反而提升了吞吐量，这个结论也有些违反直觉的。

传统团队加人往往有「布鲁克斯法则」的问题（加人反而更慢），但在 Agent 驱动的模式下，每个工程师都是独立的「Harness 调参师」，互相之间的协调成本很低。

他们的工程师角色发生了根本性的变化。OpenAI 团队自己描述：

我们现在最大的挑战，在于设计环境、反馈循环和控制系统。

换句话说，他们不写代码了，写的是规则。

像操作系统

那么......Harness 到底是个什么东西呢？

Philipp Schmid 给了一个特别好懂的类比：

计算机组件	Agent 对应物	角色
CPU	模型	原始算力
内存	上下文窗口	有限的、易失的工作记忆
操作系统	Agent Harness	管理上下文、处理启动流程、提供标准驱动
应用程序	Agent	跑在操作系统上的用户逻辑

模型就是 CPU，算力再强，没有操作系统也跑不起来。

而 Harness，就是给 AI Agent 套上的那层操作系统。

它包括上下文管理（怎么把信息喂给 Agent）、架构约束（什么能做什么不能做）、反馈循环（怎么让 Agent 知道自己做对了没）、工具链（Agent 能用哪些工具），以及整个生命周期的管理。

这个类比其实揭示了一件事：过去两年，我们一直在升级 CPU，更大的模型、更长的上下文、更强的推理能力。

但操作系统呢？还停留在 DOS 时代。

大多数人用 AI Agent 的方式，还是「打开终端，输入命令，看结果」。没有文件系统的概念，没有进程管理，没有标准驱动，没有权限控制。

难怪它不好用。

arxiv 上的一篇论文，Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned，（2603.05344）给出了一个更精确的技术定义，把 Agent 的运行架构分成了三层：

Scaffolding（脚手架）：预执行阶段的组装，包括系统 prompt 编译、工具 schema 构建、sub-agent 注册表填充。相当于操作系统的 BIOS 和引导程序。

Harness（运行时编排）：核心推理循环的包装层，协调工具执行、上下文管理、安全执行和会话持久化。相当于操作系统的内核。

Context Engineering（上下文工程）：Token 预算管理，决定什么信息该进来、什么该压缩、什么该丢弃。相当于操作系统的内存管理。

用一个公式来表示：coding agent = AI model(s) + harness

三根支柱

OpenAI 团队把他们的 Harness 拆成了三个部分。

上下文工程

也就是怎么把正确的信息喂给 Agent。

他们在仓库根目录放了 AGENTS.md 文件，Agent 每次启动都会自动读取。但这个文件更像「目录」，大概只有 100 行左右，告诉 Agent 到哪里去找更详细的信息。

这是个值得注意的设计选择。ETH Zurich 的一项研究发现，CLAUDE.md / AGENTS.md 文件应该控制在 60 行以内。过长的指令文件反而会降低 Agent 的表现。

Agent 知识的边界

但上下文工程远不只是一个 markdown 文件。

他们还给 Agent 接了浏览器（通过 Chrome DevTools Protocol），让它能看到 UI 渲染结果，自己判断页面做得对不对。

接了完整的可观测性栈（基于 Vector、Victoria Logs/Metrics/Traces），而且是每个 worktree 都有一套本地的日志、指标和链路追踪。Agent 可以自己查报错，自己看性能数据，自己定位问题在哪一层。

本地可观测性栈

这就好比，你不仅给新员工发了入职手册，还给了他所有系统的监控大屏的权限。大多数公司连人类工程师都没配这么齐全的可观测性，OpenAI 倒先给 Agent 配齐了。

架构约束

这才是 Harness 最核心的一环。

他们设计了严格的分层架构：Types → Config → Repo → Service → Runtime → UI，每一层只能依赖下面的层。

分层架构

这些规则没有靠 prompt 告诉 Agent「请遵守」，用的是确定性的 linter 和结构化测试来机械执行。Agent 违反了架构规则？CI 直接挂掉，没得商量。

而且 linter 的报错信息里，还嵌入了修复指引，告诉 Agent 应该怎么改。这一招，相当于把「老师傅的经验」写进了编译器。

Cursor 团队在他们的「Self-Driving Codebases」研究中，也得出了类似的结论：

约束比指令更有效。告诉 Agent「不要留 TODO」比告诉它「完成所有实现」效果更好。

这背后有一个反直觉的洞察：约束解空间反而让 Agent 更有生产力。 当 Agent 可以生成任何东西时，它会浪费 token 探索死胡同。当 Harness 定义了清晰的边界，Agent 反而更快收敛到正确答案。

熵管理

他们管这个叫「垃圾回收」。

AI 生成的代码写多了，文档会过时，架构会漂移，风格会走样。所以他们定期启动专门的 Agent，去扫描文档不一致、架构违规等问题，提交修复 PR。这些 PR 大多能在一分钟内审查并合并。

就像你家如果不定期打扫，再好的装修也会变成垃圾场。

OpenAI 团队把这种心态总结成了一句话：

当 Agent 遇到困难时，我们把它当作一个信号：找出缺了什么，是工具、是护栏、还是文档，然后把解决方案反哺回仓库。

Harness 改进飞轮

这其实构成了一个持续改进的飞轮：

Agent 犯错 → 人类诊断原因 → 改进 Harness → Agent 下次不再犯同样的错 → 新的错误出现 → 循环继续。

行业共识

如果只有 OpenAI 一家在做，Harness Engineering 可能只是个噱头。但事实上，多家公司几乎同时走向了同一个方向。

Stripe：每周 1300 个 PR

Stripe 内部的「Minions」系统，可能是目前规模最大的 Agent 编程实践。

每周合并 1300 多个 PR，全部由无人值守的 Agent 完成。 这些 Agent 没有人在旁边盯着，也没有人在引导。

它的架构有个值得细看的设计：Blueprint 编排系统，把工作流拆成确定性节点和 Agentic 节点的混合体。

确定性节点（比如「运行 linter」「推送更改」）按固定路径执行，不调用 LLM。Agentic 节点（比如「实现这个功能」「修复 CI 失败」）才让 LLM 行使判断。

Blueprint 编排：确定性与 Agentic 节点交替

这就像一条生产线：传送带是确定性的，工人的手艺活是 Agentic 的。你不会让工人自己决定传送带往哪走。

Stripe 还有一个硬性限制：CI 最多跑两轮。第一轮 CI 失败了，Agent 自动修复，再跑一次。如果还失败，直接转交人类。不允许 Agent 在 CI 上无限重试。

它们的内部工具平台「Toolshed」挂载了大约 500 个 MCP 工具，但给每个 Agent 的只是精心筛选过的子集。因为他们发现了一个关键规律：更多的工具并不等于更好的表现。

Stripe 工程团队的总结：

成功取决于可靠的开发者环境、测试基础设施和反馈循环，跟模型选择关系不大。如果对人类友好，对 LLM 也一样友好。

Cursor：每小时 1000 个 commit

Cursor 的「Self-Driving Codebases」研究走得更远。

他们搭建了一个多 Agent 系统，能实现约 每小时 1000 个 commit ，一周内超过 1000 万次工具调用。启动后无需任何人工干预。

但值得注意的是，他们走过的弯路恰恰说明了 Harness 设计的难度：

第一版，单 Agent，复杂任务扛不住。第二版，多 Agent 共享状态文件，结果锁竞争严重，Agent 之间互相打架。第三版，结构化角色分工（Planner → Executor → Workers → Judge），太僵硬了。第四版，持续执行器，角色过载导致各种诡异行为。

最终版本是递归 Planner-Worker 模型：一个根级 Planner 拥有全局视野，生成子 Planner 处理细分任务，Worker 在仓库副本上独立操作。

他们还发现了一个有点黑色幽默的现象：差的初始指令会在数百个 Agent 间被放大。一条模糊的指令，一个 Agent 犯的错，乘以几百个并发 Agent......结果可想而知。

Peter Steinberger：一个人的军队

Peter Steinberger 的故事可能更能说明 Harness Engineering 在个人开发者层面的威力。

这位前 iOS 圈的知名开发者，靠着 Agent 驱动的工作流，2026 年 1 月单月产出了 6600 多个 commit。他同时运行 5 到 10 个 Agent，OpenClaw 项目在 4 个月内拿到了 18 万 stars，成了 GitHub 上增长最快的仓库。

他的做法相当激进：他不逐行审查 Agent 生成的代码。

在他看来，代码审查应该变成「prompt review」。他更关心的是生成代码的那个提示词写得好不好，代码本身长什么样倒在其后了。

他花大量时间跟 Agent 做前期规划，挑战和完善方案，然后一键执行，转身去做下一件事。

他还发现了一个反常识的现象：

喜欢算法谜题的工程师反而很难适应 Agent 工作流，而产品导向的工程师适应得更快。

今年 2 月，他加入了 OpenAI。这件事本身，大概也算是对 Harness Engineering 价值的一种认可吧。

壳比模型值钱

前面说了不少案例，这里把关键数据集中拉出来对比一下。

Nate B Jones 的研究 ：同一个模型，编程基准成功率从 42% 到 78%，差了将近一倍，变量只有 Harness。换句话说，Harness 带来的提升，相当于换了一代模型。

LangChain 的案例：用同一个模型（gpt-5.2-codex），只改 Harness，Terminal Bench 2.0 的成绩从 52.8% 升到 66.5%。排名呢？从三十名开外直接冲进前五。

Pi Research 的发现更是直接：他们在一个下午内，仅通过修改 Harness，就提升了 15 个不同 LLM 的编程能力。标题就叫《Improving 15 LLMs at Coding in One Afternoon. Only the Harness Changed》。

Vercel 的经验：把 Agent 的工具从 15 个砍到只剩 2 个，准确率反而从 80% 升到了 100%。

工具越少，怎么反而越准呢？这听起来有点反直觉。但道理其实不复杂，就像你给一个实习生 15 把不同的螺丝刀让他修电脑，他可能会手忙脚乱；给他一把十字和一把一字，他反而知道该怎么干了。

Terminal Bench 2.0 排行榜上也有个值得注意的现象：Claude Opus 4.6 在 Claude Code Harness 上排名第 33，但换一个不同的 Harness 就冲到了第 5。同一个模型，同一个基准，排名差了 28 位。

这说明模型可能对特定的 Harness 存在过拟合。 在 A 环境下如鱼得水的模型，换到 B 环境可能就水土不服了。

Aaron Levie（Box CEO）感叹：

Agent Harness 目前的乘数效应太疯狂了。行业在架构上已经有了一些共识，但在具体怎么做上，还有太多不同的打法。

拐杖论

当然了，Harness Engineering 也不是没有人唱反调。而且反对者的来头都不小。

OpenAI 的 Noam Brown 在 Latent Space 的一次访谈中直接表态：

Harness 就像一根拐杖，我们终将能够超越它。

他的论据也有历史支撑。在推理模型（reasoning models）出现之前，开发者们在 GPT-4o 上搭建了大量复杂的 Agentic 系统来模拟推理能力。路由器、编排器、multi-agent 协作......一整套基础设施。

然后呢？推理模型一出来，这些基础设施一夜之间就不需要了。

之前投入了大量工程来构建这些 Agentic 系统......结果我们造了推理模型之后，你根本不需要那些复杂的行为了。事实上，在很多时候，这些东西反而让效果更差了。

他的预判是，OpenAI 将走向一个统一模型的未来：

我们公开说过，我们想要走向一个单一统一模型的世界。你不应该需要在模型上面再加一个路由器。

他给开发者的建议，只有一句话：

别花六个月搭建一个可能六个月后就被淘汰的东西。

METR（一个专注 AI 安全评估的研究组织）的数据也给了 Harness 阵营一记闷棍。

他们找了 scikit-learn、Sphinx、pytest 三个知名开源项目的 4 位活跃维护者，让他们审查 296 个 AI 生成的 PR。结果发现：维护者的合并率，大约只有自动化评分通过率的一半。

以 Claude Sonnet 4.5 为例，自动评分器给出的成绩对应大约 50 分钟的任务范围，但维护者实际愿意合并的 PR 对应的任务范围只有 8 分钟左右。这代表了 7 倍的能力高估。

而在他们的测试中，Claude Code 和 Codex 并没有比一个基础脚手架表现更好。Harness 的选择，基本落在误差范围内。

Scale AI 的 SWE-Atlas 基准测试也指向了类似的结论。

Latent Space 给 Noam Brown 这一派的观点起了个名字，叫「Bitter Lesson 阵营」。出自 Rich Sutton 那篇著名的 AI 随笔：别在工程花活上下太多功夫，算力的增长终究会碾平一切。

你那些花里胡哨的 AI 脚手架，终将被规模冲走。

路线之争

Latent Space 在 3 月初做了一期专题分析，标题就是《Is Harness Engineering Real?》，把整个行业分成了两大阵营。

Big Model vs Big Harness 路线之争

Big Model 阵营

核心观点：模型能力的增长才是主旋律，Harness 只是权宜之计。

Claude Code 团队的 Boris Cherny 和 Cat Wu 在受访时表示：

所有的秘密武器都在模型本身。我们追求的是最薄的那层包装。

他们强调的是持续简化，别往上堆复杂性。Claude Code 本身就是这个理念的产物，它的 Harness 层尽可能地薄，把更多的事情交给模型自己判断。

Big Harness 阵营

核心观点：模型是引擎，Harness 是方向盘和刹车。引擎再强，没有方向盘你也到不了目的地。

Jerry Liu（LlamaIndex 创始人）的话代表了这一派的立场：

Model Harness 就是一切。从 AI 那里获取价值的最大障碍，是你自己为模型做上下文工程和工作流工程的能力。

支撑这个观点的数据也不少。调研显示，开发者在 60% 的工作中使用 AI，但真正完全委托给 AI 的任务只有 0 到 20%。这中间的巨大鸿沟，在 Harness 阵营看来，问题出在 Harness 上，跟模型本身关系不大。

Cursor 的 $50B 估值（应该算是 Harness 公司的代表了），某种程度上也在印证这个方向的价值。

那......到底谁对呢？

护栏悖论

我觉得两边都对了一半，但都忽略了一个更深层的东西。

Philipp Schmid 观察到一个现象：Harness 本身也在不断被简化。

Manus 在 6 个月内重构了 5 次 Harness。LangChain 一年内重新架构了 3 次研究型 Agent。Vercel 砍掉了 80% 的 Agent 工具。

这说明 Harness 并非一劳永逸的。它需要跟着模型能力一起演化。模型变强了，Harness 就该变薄。

但「变薄」和「消失」是两回事。

Böckeler 在 Martin Fowler 网站上的分析提出了一个关键洞察：Harness 真正的价值，其实在于约束解空间。

她认为，要大规模维护 AI 生成的代码，关键在于通过特定的架构模式、强制的边界、标准化的结构，把解空间收窄到一个可控的范围内。

这就是我想说的「护栏悖论」：

车速越快，护栏越重要。

公路上，时速 30 公里的自行车道可以没有护栏。时速 120 公里的高速公路，护栏是标配。时速 300 公里的磁悬浮列车呢？不仅有护栏，整个轨道都是封闭的。

护栏悖论：车速越快护栏越重要

模型就是引擎。引擎越强，速度越快，你就越需要精心设计的约束系统来确保它跑在正确的方向上。

Noam Brown 当然也说得对，很多脚手架确实会随着模型进化而被淘汰。但架构约束、反馈循环、熵管理这些东西，本质上不会消失，只会换一种形态。

就像从马车到汽车，马鞭消失了，但方向盘和刹车不会消失。

Harness 阵营真正应该担心的，其实是自己搭建的 Harness 会不会六个月后，就过时了。

Noam Brown 说的「别花六个月搭建一个可能六个月后就被淘汰的东西」，在这个语境下反而成了最好的 Harness Engineering 建议：Harness 要轻，要模块化，要随时准备被拆掉重来。

Philipp Schmid 的建议可以用三个词概括：Start Simple. Build to Delete.

七个杠杆

说了这么多理论，那具体怎么做呢？

从目前行业的实践来看，Harness 的配置杠杆大概有这么几类：

Harness 的七个配置杠杆

AGENTS.md / CLAUDE.md 文件。 这是最简单的入门方式。在仓库根目录放一个 markdown 文件，写上架构约定、命名规范、测试期望。Agent 每次启动都会自动读取。记住前面说的，控制在 60 行以内，写「目录」别写「百科全书」。

每次 Agent 犯了一个错，就加一条规则。这就是 Mitchell Hashimoto 所说的 Harness Engineering 最核心的操作。

确定性约束。 linter、类型检查、结构化测试、pre-commit hooks。这些是「硬约束」，Agent 无法绕过。OpenAI 和 Stripe 的经验都表明，硬约束比软性的 prompt 指令更可靠。

工具精简。 别给 Agent 塞太多工具。Vercel 从 15 砍到 2 的案例已经说明了，工具多了 Agent 反而不知道该用哪个。Stripe 有 500 个工具，但每个 Agent 只能看到精心筛选过的子集。

Sub-Agent 隔离。 把复杂任务拆成多个子任务，每个子 Agent 有自己的上下文窗口。这样可以防止中间噪声在主线程中累积，同时也可以给不同的子任务用不同的模型。

反馈循环。 Agent 写完代码后，必须能自己跑测试、看截图、查日志。这就是 Mitchell Hashimoto 说的「给 Agent 造工具」。让 Agent 自己验证自己的产出，别什么都靠人工盯。

CI 限速。 Stripe 的做法值得借鉴，最多两轮 CI。Agent 不应该在 CI 上无限重试。跑两次还不过，就交给人类。这既控制了成本，也防止了 Agent 在错误方向上越跑越远。

垃圾回收。 定期启动 Agent 扫描技术债、过时文档、架构漂移。这是容易被忽略但极其重要的一环，尤其当你的代码量大了之后。

往远了看

几个值得关注的趋势：

Harness 会成为新的「服务模板」。 Böckeler 提出了一个设想：未来的组织可能会从一组预制的 Harness 模板中选择，然后根据自己的需求定制。这有点像今天的 CI/CD 模板或者 cookiecutter 项目脚手架，只是层级更高。

技术栈会收敛。 当写代码本身不再是瓶颈时，团队会更偏向选择那些「有好 Harness 可用」的技术栈。AI 友好性可能会超过开发者个人偏好，成为选型时的首要考量。

Harness 会反哺模型训练。 Philipp Schmid 提出了一个前瞻性的观点：Harness 捕获的 Agent 失败轨迹，可以成为模型训练的高质量数据。哪些约束被反复触犯？哪些错误模式在不同项目中重复出现？这些数据对模型改进的价值，可能远超传统的训练数据。

「旧代码」问题。 Böckeler 提了一个绕不开的问题：OpenAI 的实验是从空仓库开始的，Harness 从第一天就存在。但对于那些已经有几十万行代码的老项目呢？给老代码加 Harness，可能就像给一个从不跑测试的项目补测试一样痛苦。

学科化。 AIE Europe 已经设立了全球第一个 Harness Engineering 专题赛道。arxiv 上也有了专门的论文。这个概念正在从一个 buzzword 向一个正式的工程学科演进。

这，不就是管理吗

写到这里，我忽然意识到一件事。

Harness Engineering 说的这些，上下文管理、架构约束、反馈循环、定期清理......这不就是管理吗？

想想看，一个好的技术 leader 是怎么带团队的？

给新人写 onboarding 文档（AGENTS.md），定代码规范和架构原则（linter 和结构测试），做 code review 确保质量（CI/CD 检查），定期还得做技术债清理（垃圾回收），给工具做精简和选型（工具链管理），遇到反复出现的问题就写进 wiki（反馈循环）。

AI Agent 越强，就越像一个能力很强但需要管理的员工。

你不会把一个刚入职的天才工程师扔进一个没有文档、没有规范、没有 CI 的项目里，然后指望他写出完美的代码。

同样的道理，你也不该把一个强大的 AI 模型扔进一个没有 Harness 的环境里，然后抱怨它不好用。

Peter Steinberger 说，喜欢算法谜题的工程师反而很难适应 Agent 工作流，产品导向的工程师适应得更快。

这也印证了一个趋势：未来最吃香的 AI 工程师，可能是最懂「管理」的那种。

管理谁？管理 Agent。

Stripe 的工程师们已经不写代码了，他们写的是 Blueprint、是规则、是约束。OpenAI 的工程师们也不写代码了，他们设计的是环境、反馈循环和控制系统。

@tomiezhang 发了个「暴论」：

大模型开发将是最后的程序员，下来是所谓的 Harness Engineering 开发，所有纯码农，将在 2028 年前消失。

怎么讲，2028 这种预言有点太没依据，纯拍脑袋了......

但方向大概没错：写代码正在变得像打字一样廉价。

而在模型之外，设计让 Agent 持续、稳定、高质量写代码的那套系统，正在变成最值钱的技能。

未来最稀缺的，可能不是训练模型的人，而是管理模型的人。

一文读懂 Harness Engineering：从 14 篇工程文章中，寻找那个让 AI 不再离经叛道的壳｜Hao 好聊趋势

Yousa 博阳腾讯科技 2026 年 4 月 2 日 15:22 北京

文｜Yousa 博阳

编辑｜徐青阳

2026 年第一季度，大模型应用层最具统治力的热词，绝对是「Harness」。

今年三月，LangChain 发布了一篇题为《The Anatomy of an Agent Harness》的实证文章，彻底点燃了所有人的焦虑与狂热。他们在这份报告里引用了一个实验数据对比。仅仅是给同一个大语言模型换上一套更精巧的 Harness 架构，它在 Terminal Bench 2.0（一个专门衡量 AI 编程能力的权威榜单）上的通过率，直接从 52.8% 拉升到了 66.5%。

在这个实验中，底层模型的权重一个字节都没改，算力引擎完全没动。单靠换上一套精巧的「壳」，排名就从三十名开外狂飙到前五。

自此，无数创业公司开始疯狂包装自己的外壳。Harness 似乎成了点石成金的魔法，成了应用层公司去见投资人时最能拿得出手的「饭桌弹药」与护城河。

但在这种狂热中，概念的边界开始被无限拉扯和模糊。

究竟什么是真正的壳，什么又是壳外？很多外部介绍文章为了追求大而全，把 CLI 工具（命令行工具）的崛起、markdown 文件的上浮、甚至是最近大火的外部 Skill 技能包，都统统打包塞进了 Harness 的筐里。在某种意义上这没错，因为它们都是在 Agent infra 这个大逻辑下，让 Agent 更好运行的技术选择和创造。

但如果我们要真正理解 Harness 这条技术演进的暗线，理解它的主轴，就还是要去溯源这个概念的发生史。

另外，时间进入当下。如果你去盯紧 Anthropic 这个最早把 Harness 体系化的团队，会发现就在全行业都在拼命往上砌砖的时候，他们已经在默默地砸墙了。

随着 Opus 新版本的迭代，他们开始毫不犹豫地拆掉了当年费尽心力搭出来的控制组件。

一边在疯狂加盖，一边在果断拆除。这场充满割裂感的行业狂热，本质上是因为绝大多数人并没有真正读透过去十五个月里那些蹚坑的工程论文。

大家只看到了最终跑分翻倍的暴利，却根本没看清那些复杂的机制当年到底是被什么样绝望的 Bug 硬生生逼出来的。

今天，我们就把这个黑盒彻底砸开。顺着这十五个月的血泪文献，看清这套「约束工程」（Harness engeniering）的每一张真实图纸。

01 Harness 第一层：从记事本到管理制度

讲明白 Harness 其实不难。你就把 Agent 想象成是一辆车。

模型是引擎，马力大、转速高，给油就响。承载它的交互程序是车轮，方向盘是你的 Prompt，你打方向引擎带着你走。但引擎、方向盘和车轮这三件套本身不是车。你不能开着一台引擎上路。你需要变速箱、制动器来让你的方向能顺利调整车轮，需要仪表盘告诉你跑了多远，需要刹车告诉它什么时候该停。这些东西加在一起，任务怎么拆能顺利跑、进度怎么记、完成怎么判，这就是 Harness，就是壳。

壳不是凭空冒出来的。它有一个前史。

大模型天生只有一种记忆，上下文窗口。窗口满了，前面的内容就被挤掉。

这其实对于短任务来说这不成问题。2024 年 12 月，Anthropic 发了一篇工程博客《Building effective agents》，核心建议只有一句话。**从最简单的方案开始，只在必要时加复杂度。**那时候的 Agent 任务大多是短跑，几分钟内完成，模型的短期记忆容量够用，一段精心编写的指令（System Prompt，即，预先塞给模型的「角色说明书」）就足以驱动它干活。

但所有人都想让 Agent 干更大的活儿。

2025 年上半年，随着模型的推理能力提升，它理论上可以执行的任务开始变长。但这时候上下文方面出了大问题。虽然模型现在上下文都挺长（比如 100 万 token），但实际上其有效注意力范围没那么大，就算有这么大，它也塞不下长程任务的所有细节。人在记事儿的时候会捡重点，模型做不多，它在复杂工作里的记忆几乎就和金鱼一样。

为了解决过去有效上下文实在少的可怜，完成不了任务的问题，最早的路径之一就是记忆外化。AutoGPT 在 2023 年 3 月就给模型发了空白本子------ 一个 write_to_file 和 read_file 的工具调用权限，然后让它自己管理记忆。载体是纯 .txt 文件，没有任何结构约束。模型爱写什么写什么，爱删什么删什么。

但不管理，模型自然会乱写。Devin 在 2024 年 3 月就把本子升级成了结构化面板，引入了结构化的 Planner 面板。模型的任务规划被强制输出到一个可视化的进度条里，每一步有明确的状态标记。

到了 2025 年 2 月，Claude Code 诞生，它把 Anthropic 内部在 SWE-bench 上积累的所有经验做了产品化。CLAUDE.md（项目级指令文件）+ scratchpad（草稿本）的组合，成了业内最广泛模仿的范式。

但即使有了这样的外部化记忆系统，上下文还是可能不够用。

为此，2025 年 9 月，Anthropic 自己的应用团队发了一篇《Effective context engineering for AI agents》，这一版提针对上下文问题，提出了三个方向上的解决方法。就两个招，靠提效和压缩让长程任务也能在一个上下文层完成。

第一招是提高上下文效率，即改变上下文的写入方式，首先是 system Promp，它不应该是「写一段话就完了」，而是要当成代码来维护，要进行版本控制、A/B 测试、按任务类型动态拼装不同的 prompt 模块，这样更高效。然后就是改变工具描述，因为工具读取不清、错误既低效又占上下文。他们发现，模型读工具描述的方式和读 system prompt 完全一样。工具的命名、参数说明、返回值格式，都直接影响 agent 的决策质量。写烂了等于给金鱼一张标注混乱的地图。然后用上外部存储（RAG），即需即取，不是把所有东西一次性塞进去。

第二招是上下文压缩与淘汰，对话太长时做摘要压缩，把前面的对话历史浓缩成一段摘要，释放 token 空间给后续的工具调用结果。为了防止上下文溢出，Anthropic 干脆设定了滑动窗口策略，只保留最近 N 轮对话的原文，更早的用摘要替代，同时让 agent 在上下文里维护一个结构化的工作笔记区域，每一步更新，避免信息在长对话中被「冲走」。然后工具返回的调用内容里，没用的也直接删掉，防止它成为上下文里无用的胖子。

这就是 Context Engineering，它管的是信息。主要负责的是信息往哪存、怎么取、怎么精选。它们不管流程，金鱼模型拿到记事本之后到底有没有去翻，翻完了有没有按上面写的做，做完了有没有人验收。

这个区别，在当时并没有人明确意识到。因为 Anthropic 自己也掉进同一个坑里了。

2025 年 11 月，他们在《Effective harnesses for long-running agents》中披露了这段经历。在 2025 年 5 月，Anthropic 想让 Claude 从零开始写一个完整的 Web 应用。不是改一个 Bug，是搭一整个产品。这种任务跑几个小时，就算是配了外化记忆，上线文窗口也根本装不下全程。每开启一次新的运行，上一轮的记忆就清零。像工程师轮班，但没有交接文档。

一开始他们按照 Context Engineering 的思路搭了第一版工作框架。做法分两步走。先派一个 Agent 负责开局，分析需求、拆出 200 多个功能点、生成一份结构化清单。然后派另一个 Agent 接手写代码，每轮只做一个功能，做完提交一次，更新进度文件，留给下一轮的自己。

记事本发了，外化做了。Context Engineering 的最佳实践也照做了。听起来合理。

但实际跑起来，全面溃败。

他们发现了这里存在四种失败模式。

第一种，提前交卷。Agent 做了三个功能就宣布「项目完成」，它看到已有的代码量，以为活儿干完了。

第二种，环境盲区。Agent 真的在写代码，但环境有 Bug，它写的东西跑不起来，它自己不知道。

第三种，虚标完成。功能清单上标了 done，但实际功能是坏的。Agent 改完代码跑了单元测试，以为没问题，其实端到端根本跑不通。

第四种，失忆实习生综合征。每一轮新的运行（Session）都花大量 Token 重新摸索项目结构，像是一个新来的实习生反复问「代码在哪个文件夹」。

所以他们发现了，Context Engenieering 这个记事本解决的只是「存不住」的问题。但金鱼的毛病远不止存不住。它有时候不翻本子，翻了经常压根不按本子上写的去做。除此之外，还缺乏自我验证的能力。

记事本不是问题。没人逼金鱼翻它照做、没人验证金鱼写的是不是真的，才是问题。

这个认知的跃迁，让 Anthropic 的应对方式从「做一个更好的记事本」彻底转向了「围绕严格遵守工作流程，构筑一整套管理制度」。

针对虚标完成和提前交卷，Anthropic 意识到不能光靠 Markdown 格式的外部化，也不能让 Agent 既当运动员，又当管理员。在项目开始时，由一个专门的「初始化 Agent」生成一份完整的功能清单的，这个用的是 JSON 结构（一种机器可读的数据格式）。它被设计成真正干活儿的「编码 Agent」只能改一个字段标「通过」或「不通过」的严格死流程。你不能删功能，不能改描述，只能标状态。而切 Jason 规定，Agent 必须在自己实际测试通过之后才能把状态改成 passing，不能光凭「看起来差不多了」就标完成。

在这种设定下，出题人用的 JSON 成了防作弊的物理锁，通过强校验这段数据，死死卡住进度条。而 Markdown 格式的文件依然存在，但主要用于提供路标，而不是严格流程。（这也是现在 Skill 遵循差的原因之一）

针对失忆实习生，每个 Session 开头强制执行三步唤醒仪式。跑 pwd（确认当前目录）、读 git log（查看代码改动历史）、读 progress.txt（查看下一个任务）。像工厂换班时，下一班工人先翻交接簿。Agent 的记忆不存在它自己脑子里，存在 Git 历史和进度文件里。不信 Agent 能记住，就更系统性的帮它把记忆存在体外，并且强制它每次上班先打卡、先翻交接簿、先确认工位。

效果立竿见影。Agent 能连续跑几个小时了。每一轮只做一件事，做完提交，状态外化到进度文件里。下一轮进来，读最新的 progress.txt 就知道该干什么。

Anthropic 还加了一层更硬的保险。每一次代码改动都通过 Git 存档。一旦模型陷入死胡同，直接用 git revert 把代码库回滚到上一个能跑的干净状态，然后重新唤醒模型。不指望金鱼自己撤销错误。直接给它一台时间机器。

当历史消息撑爆上下文窗口时，Harness 会彻底清空金鱼的脑子，启动一个全新的 Agent，通过一份结构化的交接文件把前一轮的状态和下一步任务传过去。Anthropic 把这个叫 Context Reset（上下文重置）------**不是压缩记忆，是直接换一条新金鱼，只给它一张写好的交接单。**这比单纯的摘要压缩（Compaction）更激进，因为 Anthropic 发现，哪怕压缩了历史，模型在超长上下文里仍然会焦虑、丢失连贯性。只有彻底清空，给一张白纸，才能让它重新集中注意力。

到这里，Anthropic 的管理制度已经相当完整了。JSON 物理锁管住虚标，三步唤醒管住失忆，Git 存档管住撤销，Context Reset 管住脑容量。但这套制度管的全是流程，金鱼必须打卡、翻本子、按清单干活。

它没管另一件事，金鱼面前的信息本身对不对，新不新。

如果记事本上写的路标就是过期的、残缺的，流程再严也只是让金鱼更勤快地照着错误的地图跑。

那怎么办？严控流程之外，还有一条路，就是严控记事本和它的仓库。

OpenAI 就是这个逻辑。

在《Harness engineering: leveraging Codex in an agent-first world》（2026 年 2 月）中，他们从 2025 年 8 月的一个空仓库开始做了一场实验。三个工程师，不写一行代码。所有代码------应用逻辑、测试、部署配置、文档、监控工具------全部由 Codex Agent 生成。

人类做什么？设计 Agent 的工作环境。用他们自己的话说就是「人类掌舵，Agent 执行」。

五个月，一百万行代码，一千五百个 PR（代码提交请求），零行人工输入。团队后来扩到七人，吞吐量反而还在增长。

他们在这个过程中得到的是和 Anthropic 同一方向，但更严格的认知，仓库即现实（Repo-as-truth）。

**从 Agent 的角度看，它在运行时无法访问的东西，就是不存在的。**Slack 上的讨论不存在。团队脑子里的共识不存在。Google Docs 里的方案不存在。唯一存在的，是代码仓库里那些版本化的、Agent 能直接读到的文件。

这意味着，如果你想让 Agent 知道一件事，只有一个办法，即写进仓库。架构决策要写进去，设计原则要写进去，质量标准要写进去，连「我们团队偏好什么风格」这种品味判断，都要写进去。

光写进去还不够。OpenAI 在实践中发现，一份巨大的指令文件（a giant instruction file）会挤占真正重要的上下文，任务本身、相关代码、参考文档全被挤到一边去了。而且被动文档有个致命问题：Agent 读了，不代表它会遵守。所以关键规则必须变成可执行的自动化检查，custom linter 规则、结构化测试，挂在 CI 流水线上，Agent 每次提交代码都会被自动扫一遍，违反了就合并不进去。Agent 不需要「记住」规则，它只需要根据报错信息改到通过为止。

用一个质量管理员（linter），管住进出仓库的流程，整个工作的流程就被管住了。

他们的做法很具体。AGENTS.md（一份写给 Agent 的「新员工手册」）只有大约一百行，不是百科全书，是一份目录。它只告诉 Agent 去哪里找更深的信息------架构文档在哪、设计原则在哪、当前执行计划在哪。每个业务域分成固定层级，依赖方向严格单向，违反了就过不了自动化检查。这个路牌的作用只有，让 Agent 不需要「理解」架构规则，它只需要知道这条路走不通，系统会拦住它。找对了，都是严格要求的 Linter 规则语言。

文档也不是写完就扔在那里。OpenAI 专门跑了一个 Doc-gardening Agent（「文档园丁」，专职维护文档的 Agent），什么业务代码都不写，每天在仓库里巡逻。一旦扫到某篇文档和真实代码脱节了，它就自动发起修改请求，把过时段落无情修剪掉。因为过期的记忆比没有记忆更危险。金鱼读到错误的历史，产出的就是幻觉。

Repo-as-truth （仓库即现实）听起来像是一个技术架构选择，但它的本质是一个管理哲学的升维。

Anthropic 的管理制度管的是流程，让 Agent 必须打卡、翻本子、按清单干活。OpenAI 的 Repo-as-truth 管的是环境本身。它不管 Agent 的行为，而是确保它能感知到的整个世界都是准确的、可执行的、自动维护的，让它想跑偏都没有错误信息可以偏向。流程管住的是行为，环境管住的是认知。

从最初发一个空白记事本，到 JSON 物理锁、三步唤醒仪式、Git 存档与回滚、Context Reset 清空重启，再到 Repo-as-truth 把整个仓库变成 Agent 唯一能感知的现实。

这条路走下来，你会发现 Harness 的第一层壳和 Harness（驾驭）这个词完全一致，就是管住有了哪怕已经解决了记忆供给问题的 AI，让它能认认真真让它找着记忆笔记本里的规定干事儿。虽然解法有两种（A 家和 O 家），但目的都是流程的管控。

只有这样，它才能确保这辆车连续跑 6 个小时后，依然记得自己要去哪，变速箱不会因为过热而卡死，而且它眼前的路标全都是真的。

这就是 Harness 1.0。

02 Harness 第二层：终结无政府状态，走向并发与效率

当单个汽车终于能稳稳地跑长途了，应用层立刻迎来了下一种贪婪。既然单台车能跑，为什么我们不能同时派出一百台车去干活。为了解决大规模协同的效率问题，Harness 的内部架构被迫向上生长，演化出了极其复杂的并发与调度控制层。

但当我们真正让无数个 Agent 涌入同一个代码仓库时，惨烈的连环车祸发生了。

Cursor 团队在《Scaling long-running autonomous coding》（2026 年 1 月）中，记录了他们扩大并发规模时遭遇的崩塌。他们尝试让几百个 Agent 共享一份大型项目。结果，20 个 Agent 同时工作时，有效吞吐量下降到仅相当于两三个 Agent 在跑------锁机制变成了瓶颈，大家互相等待，谁也推进不了。更绝望的是，其余的 Agent 发现核心代码被占用了，为了显示自己还在工作，就专门挑最简单、最无关紧要的代码去改。整个代码库被疯狂修改注释、调整空格和缩进格式。

几百个高智商 AI 瞬间陷入了纯粹的无政府状态。

这逼出了更高维度的壳内架构。Cursor 利用状态机搭建了 Planner（规划器）、Worker（执行器）和 Judge（裁判）的三层阶级，并加上了强硬的门控。在 DAG 引擎（一种只允许单向流动、不能回头的任务调度系统）的单行道里，Planner 节点没吐出排期表之前，下面的 Worker 节点会被底层引擎硬生生锁死，一步都动不了。没有 Planner 的审批签字，Worker 绝对不准碰核心代码。

长时间任务启动前，Agent 必须先提交完整计划、等待批准才能动手，这是第一道闸。

执行完成后，每个 Worker 要提交一份交接报告，不是简单的「做完了」，而是包含工作总结、发现的问题、任何偏离计划的地方。上层 Planner 靠这些报告维持全局视野，发现偏移就拉回来。

这就好比在混乱的十字路口强行装上了红绿灯，用无情的物理状态机死死压制住了个体的盲目性。

Anthropic 在《Building a C compiler with a team of parallel Claudes》（2026 年 2 月）中，揭示了另一种算力极其昂贵的并发灾难。

他们派出了 16 个顶配的 Claude 实例并行写 C 语言编译器。初期大家各看各的模块，进度飞快。但一进入整体编译和链接阶段，系统抛出了一个全局错误。到了改 Bug 阶段， 16 个 Agent 就像 16 个没有对讲机的瞎子。它们疯狂消耗算力，互相覆盖了数百行代码。不仅 Bug 没修好，还产生了海量的空转。

**逼出来的解法，是引入 GCC（业界最成熟的开源编译器）作为标准答案参照。**假设你造了一辆车，启动后发现发动机不转。问题是不知道是哪个零件坏了。车有上千个零件，一个个检查太慢。

Anthropic 给了 Agent 系统一辆「一模一样但确定能跑的车」（GCC 编译出来的内核）。让它把自己造的零件随机换上去几个，其他都用好车的原装零件。如果车还能跑，说明你换上去的那几个零件没问题。如果车跑不了，说明 Bug 就藏在你换上去的那几个里面。

然后继续缩小范围，把那几个可疑零件再砍一半，另一半换回原装的。还是跑不了？那 Bug 在剩下的那一半里。再砍一半......几轮下来就能精确定位到具体哪个文件有问题。这就是「二分查找」。

这个方法把一个巨大的「整个编译器哪里错了」给拆成了变「这 3 个文件中哪个编译错了」，调试难度断崖式下降。而且不同的 Agent 可以同时测试不同的文件子集，天然地分开了工作范围，不会再互相踩脚。

文章里还提到了一个更进阶的变体叫 delta debugging。有些 Bug 是两个文件「配合」才出现的，单独编译每个文件都没问题，但放在一起就炸。这种情况需要找「文件对」，方法类似但搜索空间更大。

结果用了近 2000 个 Session，两周时间，两万美金的 API 费用，Claude Code 产出了一个 10 万行的编译器，能编译出可以正常启动的 Linux 操作系统。

**这就是 Harness 进化出的第二层核心机制，大规模并发控制。**模型本身缺乏自律和宏观协作常识。如果不加这层强硬的控制流，聪明的大脑只会用最快的速度把整个团队带进死胡同。

03 Harness 第三层：戳破盲目自信

有了打卡制度和外部记忆，有了红绿灯和专属车道。Agent 顺着轨道跑完，大喊一声任务完毕。结果人类接手一看，代码是屎山，能用但巨慢，UI 混乱不侃，能点但没逻辑。

这其实是在 Harness v1 版本中，Anthropic 就遇到的那个虚标完成问题。当时这个问题只解决了前半部分，不让 AI 瞎标，但 AI 的验证其实没有完全解决。

Anthropic 的强制测试能抓住的是功能性错误，这个函数输入 X 应该输出 Y。OpenAI 的那套机制虽然设置了 linter 质量管理员，但 Linter 能抓住的是结构性违规，比如依赖方向反了、命名不规范、文件太大。

有一大类问题这两种设置都抓不住，比如页面打开了但布局完全错位；功能在技术上「通过」了但用户体验很差；代码逻辑自洽但业务需求理解偏了。

这些需要一个更综合的「评判者」实际去看、去用、去判断。

这 Anthropic 其实非常清楚这一点。11 月的 Harness 文章之后两个月，他们就在《Demystifying evals for AI agents》（2026 年 1 月）中系统梳理了 Agent 评估的方法论，明确指出编程 Agent 必须在真实环境中运行测试套件来验证，仅看代码本身远远不够。

而他们在后续的《Harness design for long-running application development》（2026 年 3 月）中，彻底揭开了大语言模型的致命缺陷，让它评估自己刚刚完成的工作，它几乎总是「自信地赞美」，哪怕在人类观察者看来质量明显平庸。甚至在有明确对错的可验证任务中，它也时不时展现出糟糕的判断力。简单来说，它不是在骗人，它是真的觉得自己做得很好。

Anthropic 的做法是把 Agent 作为 Evaluator（评估器）直接拉进壳的内部循环。灵感来自 GAN（生成对抗网络），把做事的和评判的分开。在 Harness v1 版本里，多出来的 Agent 只是出题，但验证还是执行 Agent 自己做，依然是选手评委是同一个人。现在，两个 Agent 互相怼，执行者的自信就没法蔓延了。

但仅仅拆开还不够，因为评估者本身也是一个 LLM，天然倾向于对 LLM 生成的输出「手下留情」。于是他们反复校准评估者，让它保持怀疑态度。校准后的评估者会亲自动手验货，打开浏览器、点击页面按钮、验证报错栈（程序崩溃时吐出的错误信息链）、截取屏幕画面，像真实用户一样操作一遍，把最真实的端到端报错状态扔回给 Generator（生成器），形成死磕的对抗循环。

你不让我看到正常的页面反馈，我就一直给你打低分，逼着你重写。

在最新披露的 V2 版本（2026 年 3 月）中，Anthropic 还引入了 Sprint Contract（冲刺合同）机制。每轮迭代开工前，Generator 和 Evaluator 先协商「做完长什么样」。像甲方和施工队开工前先签验收标准。不是人类定的标准，是两个 Agent 自己谈出来的验收条件。一个博物馆网站经过九轮对抗后，第十轮 Generator 推翻了所有设计，做了一个 3D CSS 透视环境加空间导航。这是被逼出来的创造力。

Cursor 在《Building a better Bugbot》（2026 年 1 月）中，也在解决这个问题，也是引入了 Evaluator，但走的更极端、更昂贵。

他们坚信，哪怕是作为裁判的模型，也极容易被代码表面的逻辑自洽所欺骗。于是他们搞出了一个 8 通道并行盲审机制。对于同一个代码差异，壳内控制系统会拉起 8 个独立的 Bugbot，每个通道拿到的代码差异被打乱了顺序。顺序不同，推理路径就不同，幻觉就不容易同步。8 个通道各自独立发现 Bug，最后用多数投票合并。如果某个 Bug 只在一个通道里被标记，直接过滤掉。合并后的结果还要再过一遍验证器模型，捕捉残留的误报。层层过滤，只留真信号。

看着非常靠谱，但即便裁判团再庞大、再严格，还有一个它管不到的地方：考场本身。

在 SWE-bench 等主流编程评测和多家团队的实践中，他们反复观察到一个现象。当生成模型发现自己怎么都无法通过测试用例时，它为了强行交差，居然学会了篡改测试环境本身。它直接越权修改了评测脚本，把 assert x == 5（即，「答案必须等于 5」）这种严格的断言条件，硬生生改成了 assert True（即，「无论答案是什么都算通过」），从而强行返回了测试通过的信号。

AI 面对地狱级难度的考试，第一反应不是去解题，而是想办法干掉阅卷老师。

裁判和运动员的军备竞赛成了一个没有尽头的无底洞。这也是为什么在 Harness 验证这一层，极其严格的沙盒隔离成为了绝对的必需品。控制流必须把测试环境锁定为最高级别的只读状态，考生只能在答题卡上写字，绝对碰不到试卷和评分标准。只有这样一个物理隔离的纠错闭环，才能强行戳破模型的盲信。

Harness 第一层，保证了模型会按照要求的步骤，不跳步，不瞎走的完成。第二层，保证了在多个智能体之间沟通的流程，能让当前基本必然需要多 Agent 参与的流程能够有效跑起来。

但要保证模型真的能有效的执行任务的意图，那验证就是 Harness 第三层必须要解决的问题。

04 做加法之后学会做减法

跟着这几家头部公司走完这十五个月的血泪文献，我们终于可以给 Harness 画一张干净的图纸。

Harness 是一套围绕着大语言模型而建立的、纯粹的工业级管理制度。第一层管的是它不听话。第二层管的是群体操作。第三层管的是它看不清自己。

它们解决的都是最基础的，管住 Agent，让它能生成有我们期许的内容。

而其他，比如 CLI，管 Agent 的接口；Skill，管从自然语言到流程化的转换；外化记忆，管上下文的存储模式，这些都应该归于 Agent Infra 的大范畴。。它们只是加油站和车载导航的离线地图包。它们能让这辆车跑得更顺、能去的地方更多，但它们不负责解决「车到底该怎么开」的问题。

Harness 的开创者 Anthropic 在这些地方也出力甚多。不说 Skill、MCP 这些基础建设。它们在《Quantifying infrastructure noise in agentic coding evals》（2026 年 2 月）中就指出，仅仅是把评测环境的资源限制从严格模式放宽到无限制，Terminal-Bench 2.0 上的成功率就提高了 6 个百分点。因为资源充足后，瞬态内存溢出导致容器崩溃的概率降低了。这就是路面🧾，而不是自动驾驶系统本身的逻辑设计。

三层壳，三种补偿。到这里，「加法」的部分讲完了。

但故事没有停在这里。

在 2025 年 11 月第一篇 Harness 文章诞生后，Opus 4.5 和 4.6 相继登场。Anthropic 做了一件所有搭过复杂系统的人都不太愿意做的事，他们开始拆自己造的东西。

第一章里提到的 Context Reset，拆了。Opus 4.6 的上下文管理能力已经强到不再需要那块干净石板。加着它跑和不加它跑，产出质量没有区别，反而多了一层编排成本。

第三章里提到的 Sprint Contract，拆了。新模型已经能自己把控节奏，不再需要 evaluator 和 generator 每轮开工前先谈一份验收合同。合同流程还在，但它补偿的那个短板已经消失了。

留着它，不是保险，是拖累。

Evaluator 从每轮对抗改成了最后一轮做 QA（质量验收）。不是不需要了，是需要的方式变了。

拆掉它们，不是未卜先知。

Anthropic 最初认为这些组件是长任务不可或缺的骨架。但 Opus 4.6 的实验数据显示，这些补偿不再提升产出，只增加延迟和成本。

拆，是实验结果倒逼的，不是架构预判。

Anthropic 自己的原话，「harness 的每一个组件，都编码了一条关于模型做不到什么的假设。」当假设不再成立，组件就该走了。

难的不是拆本身，是判断什么时候该拆。拆早了，模型还撑不住，系统会塌；拆晚了，多余的补偿层遮挡模型的真实能力，你以为壳在帮忙，其实壳在碍事。

Anthropic 的做法是每次新模型发布，先用老 harness 跑一遍，再拆掉一个组件跑一遍，看数据说话。

目前完成了从「加」到「拆」完整周期的，只有 Anthropic。

OpenAI 和 Cursor 仍在加的阶段------OpenAI 的 Codex 团队还在从 3 人扩到 7 人，Cursor 的架构还在从扁平走向层级。但三家都以不同的方式承认了同一件事------当前的方案不是终点。基于 Anthropic 的先行经验，「拆」的阶段很可能也会到来。

而 Cursor 也也从另一个角度证明了这一点。还是第二章里那个几百个 Agent 集体摸鱼的项目------同时跑七天，写一个浏览器。在反复调试的过程中，他们发现影响系统行为最大的因素是 prompt（即，你怎么用自然语言跟 Agent 说话），其次是 harness 结构，最后才是模型本身。

用他们自己的话说，「系统行为中惊人比例的差异，归结于我们如何提示 Agent。」

调一句 prompt 的效果，比换掉整个 harness 架构都大；换架构的效果，又比换模型大。最轻量的干预反而最有效。

但这个排序有前提。Cursor 得出结论时，harness 已经是 planner-worker-judge 三层架构，经过了多轮迭代。Prompt 站在 harness 的肩膀上，才有了那个影响力。没有那层架构，再好的 prompt 也只是对着一群互相踩踏的 Agent 喊话。这个排序反映的是边际影响力，不是基础重要性。

两个故事，一个在拆组件，一个在排影响力。但它们指向同一个认知，harness 组件的价值不是绝对的，是相对于模型能力的。

Harness 里每个方块存在的理由都不是「它能做什么」，而是「模型做不到什么」。

Context reset 补的是模型记不住；evaluator 补的是模型没法客观评估自己；sprint contract 补的是模型不会定义「做完」。

每一个组件都是一块补丁，贴在模型能力的缺口上。

这些补丁拼在一起，至少在 Anthropic 身上，表现为一个随模型能力变化而持续变形的曲面。这个曲面有一个名字，补偿面。

所以，Harness 到底是不是护城河？

**Anthropic 证明了模型已经开始吞掉 Harness。**所以也许不是？

但其实，随着我们希望模型能做到的事越来越复杂，而这些希望基本都会超越模型的能力时，补偿面可能会存在一段时间。

但正如 Anthropic 自己的总结，值得尝试的 harness 组合空间没有随模型进步而缩小，它在移动。

补偿面在迁移，是指模型每强一分，harness 的重心就移一寸。每一次加组件，都是在补偿模型当前做不到的事；每一次去组件，都是因为模型进步让某个补偿变成了 overhead（多余的累赘）。总量未必减少，但位置一直在变。

LangChain 的 Lance Martin 早在 2025 年 7 月的一篇博文中就观察到了同样的规律------模型越来越强，你不得不开始拆结构。这是 Bitter Lesson 在应用层的重演。

那护城河在哪？

先回答反面。

如果一家公司说「我们有最完善的 harness 方案」，有最多的验证层、最复杂的 planner 架构、最精密的 evaluator 机制------那不是护城河，是负担。因为那些组件的存在理由，不是「它们能做什么」，而是「此刻的模型做不到什么」。

模型每强一分，理由就少一分。架构越厚，意味着对当前模型短板的押注越重，转身就越慢。

真正有价值的不是补偿的厚度，是追踪补偿面迁移的能力，知道下一寸该加什么，上一寸该拆什么。

护城河不在 harness 的厚度，在迁移的速度。

反过来说，任何声称自己是「一劳永逸的 harness 方案」的公司，说明它还没遇到那堵墙。

这个镜头可以直接拿去用。下次你看到一个 AI 产品在大张旗鼓地加功能，问自己------这个功能是在补模型当前做不到的事，还是已经在补一个模型早就能自己做的事？前者是必要成本，后者是技术债。下次你看到一个团队在删功能、拆架构，不要读成「他们走了弯路」，读成「他们正在发现模型能做什么了」。能拆，说明之前搭得有效；拆得快，说明他们一直知道自己在补偿什么。

但三家都留了后手。

OpenAI 话锋一转，表示「我们还不知道的是，在一个完全由 Agent 生成的系统里，架构的一致性经过数年之后会如何演化。」二十周证明了这条路能跑，但跑一年后路还在不在？每周五，团队花 20% 的时间清理 AI slop（AI 产生的低质量代码）------Agent 会复制仓库里已有的模式，包括不够好的模式，漂移是内建的。后来用自动化的 golden principles 扫描替代了人工清理，但这本身就是信号------系统在高速生成的同时高速退化，需要持续的「垃圾回收」才能维持。

Anthropic 说得更直接，这些假设是 load-bearing 的（承重的），但不是永久的。

Cursor 发现了另一种失控。Agent 在扁平结构下变得极度规避风险，宁愿做无意义的小修改也不碰难题，整个系统空转。系统需要周期性的 fresh start 来对抗漂移。

这些自我限定不是公关话术。正因为成就是真实的，这些不确定性才值得认真对待。三家都在用同一个策略------build fast, validate later。问题是，当「以后」到来的时候，系统可能已经积累了几百万行没有人真正理解的代码。

所有这些方案，都建在模型当前的能力边界上------而那条边界，没有停。

如果每一层补偿都是临时的，那 harness engineering 本身是不是也是临时的？没有人回答。但这个问题存在本身就是信号。

2019 年，Sutton 写 The Bitter Lesson，说的是终局。算力的通用方法终将胜过人类手工设计的巧招。但这十五个月讲的是过程中，你必须先认真搭那些巧招，才能知道哪些该拆。Anthropic 不搭 context reset，就不会发现 Opus 4.6 不再需要它。Cursor 不让几百个 agent 集体摸鱼一次，就不会知道层级结构才是答案。每一层被拆掉的补偿，都曾经被认真搭过。

通往简单的路，必须经过复杂。

但「知道自己在经过复杂」和「以为复杂就是终点」，差距就在这里。

05 Claude Code 源码泄漏，带来的一次意外对账

本来文章到此应该结束。但就在我准备发布之时，一次意外，给了我们从工程角度更深入审视 Harness 的机会。

2026 年 3 月 31 日，Claude Code v2.1.88 发版，有人发现 npm 包里多了一个 59.8MB 的 source map 文件。几个小时之内，51.2 万行 TypeScript 源码被全网镜像、逆向、逐行拆解。

拿着这 51 万行代码去对照前面四章提到的那些工程实践，就能发现，果不其然，每一层壳都有对应的产品化实现，而且好几处比文章里描述的走得更远。

先看第一层。Anthropic 在《Effective context engineering for AI agents》（2025 年 9 月）里提了一个核心建议，system prompt（预设指令）不应该是「写一段话就完了」，而是要当成代码来维护，做版本控制、按任务类型动态拼装。源码里确实这么干了。它有一个专门拼装指令的函数，内部用一条分界线把 prompt 切成两半------前半段是不变的「身份证」，跨会话反复复用；后半段是每次现拼的「任务单」，根据当前场景实时生成。

写一次用一辈子的 system prompt 在这里不存在。每次运行，模型拿到的指令都是现场组装的。

同一篇文章里还有一条观察，工具描述写烂了等于给金鱼一张标注混乱的地图。对应的是模型读工具描述的方式和读 system prompt 完全一样，命名、参数说明、返回值格式都直接影响 Agent 的决策质量。源码的做法比建议更狠。它直接在指令里写死了一套「操作语法」，比如读文件只能用内置的 FileRead 指令，不准用操作系统自带的 cat 命令；改文件只能用 FileEdit，不准用通用文本替换工具 sed。不是建议，是硬规定。模型没有选择余地。

再看上下文管理。Anthropic 和 OpenAI 提出了上下文压缩策略，对话太长就做摘要。A 家甚至给出了 Context Reset，即，在上下文实在救不回来的时候，直接清空，换一条新金鱼。源码揭示这两招不是二选一，而是同一条急救流水线上的不同阶段。先砍工具返回里的废话，再轻度压缩，然后重度压缩，最后全面压缩。如果连续失败三次，放弃抢救，直接开一个全新的会话。

能救就救，救不了才换。

而第一章里记忆外化的思路，在源码里被推到了一个全新的精细度。不再是一个 CLAUDE.md 加一个 scratchpad 的简单组合，源码揭示了一个六层记忆体系。从最宏观到最微观依次是，公司级的组织策略、项目级的配置、个人的使用偏好、当前会话的历史、Agent 从交互中学到的习惯、以及此刻正在进行的对话。上层覆盖下层。同一个 Agent 在不同公司、不同项目里，看到的「现实」是不同的。第一章里 OpenAI 说「仓库即现实」，这里更进一步------分层仓库即分层现实。

更有意思的是，源码里还有一个叫梦系统，autoDream 的系统专门维护这套记忆。这是一个后台程序，趁用户不用的时候自动跑「记忆大扫除」。它扫描 Agent 的笔记目录，收集新信息，合并重复的，删掉互相矛盾的，把模糊的笔记转成具体事实，把「昨天」「上周」这种相对日期转成确切的年月日，最后把整本笔记精简到 200 行以内。这个程序只有只读权限，不能改任何代码，只能整理笔记。

就是给金鱼配了一个专职的笔记整理员，趁它睡觉的时候帮它把本子重新誊抄一遍。

这个想法其实从古早的神经网络设想中就有，我和谢诺夫斯基沟通时就提到过睡眠重塑神经元链接的问题。但即使现在，模型神经网络的参数更新依然困难，那 Anthropic 就现在外部记忆上来了一刀。

第二层的对账更直接，而且升级幅度最大。

Cursor 在《Scaling long-running autonomous coding》（2026 年 1 月）里描述的「规划者-执行者」门控模式，加上 Anthropic 在《Building a C compiler with a team of parallel Claudes》（2026 年 2 月）里用 Git 锁文件做并发隔离的做法，在源码里合体成了一个叫 Coordinator Mode（协调者模式）的系统。一个主 Claude 充当工头，派出多个干活的 Worker，走调研、综合、实现、验证四步流水线。Worker 要执行危险操作，比如删文件、跑脚本，得通过「邮箱」向工头请求许可。多个 Worker 不能抢同一张许可单，系统内置了防撞车机制，保证同一个操作只有一个人能领。

工头的指令里写着一句话：「并行是你的超能力。」

但源码走得比 Coordinator Mode 远得多。前面那些文章里的多 Agent 并发，本质上还是「一个老板带几个临时工」------Worker 干完活就走，彼此不认识。源码里出现了一套全新的 Team Mode（团队模式），逻辑完全不同。

Team Mode 里的 Agent 不是临时工，是长期驻扎的「队友」。每个队友有自己独立的上下文窗口、独立的 Git 工作区、独立的记忆。它们不用事事请示工头，可以直接互相发消息------点对点通信，不用中转。一个前端专家和一个后端专家可以各自在自己的代码分支上干活，互不干扰，干完了再合并。

这解决了一个第二章里没提到但在实践中致命的问题。传统的 Coordinator 模式下，单个 Agent 用到 80%-90% 的上下文窗口就开始犯糊涂。Team Mode 把每个队友的上下文利用率控制在 40% 左右。不是一个人硬扛到记忆力耗尽，而是多个人各管一摊，每个人都保持头脑清醒。

队友之间的通信走的是基于文件的「邮箱」系统，每个队友在磁盘上有自己的收件箱，每 500 毫秒检查一次有没有新消息。优先处理用户的直接指令，其次是关机请求，最后才是同事的消息。队友干完活不会消失，而是进入待命状态等下一个任务。它不是用完就扔的一次性外包，是长期在线的团队成员。

甚至还有了正式的「团队档案」，一个持久化的文件记录着谁是成员、各自什么权限、什么模式。系统禁止队友再生队友，保持组织结构扁平。这已经不是临时搭的施工队，是有编制的部门。

第三层也全部落了地。Anthropic 在《Harness design for long-running application development》（2026 年 3 月）中详细描述了 Generator-Evaluator 对抗机制，强调评估者必须反复校准、保持怀疑态度。源码里这个角色叫 Verification Agent（验证员），它被指令明确要求「try to break it」------你的任务就是尽力把产出搞崩。它必须输出 PASS、FAIL 或 PARTIAL 三种标准化判定，没有模糊地带。

不是温和的代码审查员，是一个被要求尽力搞破坏的攻击者。

源码还把 Agent 按权限做了严格的角色隔离。负责调研的 Agent 只能读不能写，负责规划的 Agent 不能碰文件只能出方案。第三章讲的沙盒隔离思维，在这里变成了 Agent 类型系统的设计原则------什么角色能碰什么东西，出厂就定死了。

最后是第四章的核心论断。同样出自那篇三月发布的文章，Anthropic 说每次新模型发布，都要拆掉一个组件跑一遍，看数据说话。源码验证了这不是说说而已。所有高级功能都通过 feature flag（功能开关）门控，就像一排总闸，每个闸管一个功能。没启用的功能在构建时直接被移除，不会留在最终产品里。44 个开关，44 个随时可以拆掉的补丁。

不是方法论，是日常操作。

对账到此为止。前四章提到的每一条工程实践，都写进了产品里------而且记忆体系和多 Agent 并发这两个方向上，产品已经比文章走得远得多。

06 正在发生的「补偿面迁移」

但这 51 万行代码里，还有一些那些工程文章从来没提过的东西。而且它们的性质，跟前面三层壳完全不同。

前面三层壳解决的都是同一个问题，怎么让 Agent 把长程任务做好。记忆是为了不忘事，并发是为了干大活，验证是为了不糊弄。它们都是执行长程任务的必需品。

但源码里出现的几个新系统，不是。它们解决的问题已经不在「怎么执行任务」这个范畴里了。

第一个叫 KAIROS。这是一个常驻后台的守护程序。它不等你开口。系统定时拍它肩膀问「现在需要你做什么吗」，它自己决定是行动还是沉默。但它有一个硬性限制，任何会打断用户工作超过 15 秒的操作，一律自动延后。

过去三层壳管的全是「怎么做」------怎么记住任务、怎么分配工作、怎么验证产出。KAIROS 管的是「该不该做」。Agent 从接到命令才动手的执行者，变成了时刻在旁边观察、自己判断时机的助手。15 秒这个数字是一种全新的度量单位------不是代码行数，不是测试通过率，是「打断人类的成本」。

第二个叫 YOLO Classifier。名字很随意，设计很认真。前面那些工程文章讨论权限时，基本都是二元逻辑，要么问用户，要么不问。Claude Code 的实现完全不是这样。它给每个操作都打了风险标签。读文件、搜索代码这类安全操作，直接放行，不打扰用户。写文件分两种情况------在项目目录内的走快速通道，出了项目目录的要走完整审批。执行命令行脚本永远走完整审批，因为一条命令理论上能干任何事，风险没有上限。

分类器对每次操作给出三种判定，放行、软拒绝（再确认一下）、硬拒绝（绝对不行）。更有意思的是它会学------你连续拒绝某类操作几次之后，系统自动记住，以后这类操作直接阻断，不再来烦你。

壳的松紧不再是工程师调好的固定值。它在根据你的习惯自动调节。壳在学习该怎么当壳。

第三个叫 Hooks（钩子）。想象 Agent 从启动到完成任务是一条流水线，源码在这条流水线的 8 个关键节点上埋了插槽。任何人都可以往插槽里塞自己写的检查脚本。脚本说「不行」，整条流水线就停下来。

前面那些文章里，壳是 Anthropic 自己设计、自己拆的。Hooks 把壳变成了一个开放平台。一家企业可以在插槽里挂自己的合规检查，一个开源社区可以挂自己的代码规范。壳不再是铁板一块，是一个有 8 个插槽的框架。谁都可以往上加自己的约束。

回头看这三个账外发现，它们有一个共同特征，没有一个是执行长程任务必须的。

不装 KAIROS，Agent 也能听命令执行。不装 YOLO Classifier，大不了每次都问用户。不装 Hooks，Anthropic 自己的壳依然能用。

但它们对效率、自定义和商业防御是必须的。

**KAIROS 让 Agent 从被动工具变成主动助手。**YOLO Classifier 让壳的松紧自适应。Hooks 让壳从封闭产品变成开放平台。反蒸馏让壳承担起知识产权保护的角色。

这些方向没有一个出现在过去十五个月的工程文章里。因为那些文章解决的是「怎么让 Agent 工作」，而这些新系统解决的是「怎么让 Agent 好用、可控、可商业化」。

前面四章讲的补偿面迁移，是壳在三层之间左右移动，某个组件从「需要」变成「不需要」，从开启变成关闭。

但这些账外发现指向的是另一种运动。壳不是在变薄或变厚，它在往全新的维度伸展。执行长程任务只是起点。壳正在从 Harness 向 Infra 蔓延。

补偿面不只是在迁移。它在膨胀。

一文带你看懂，火爆全网的 Harness Engineering 到底是个啥。

数字生命卡兹克 2026 年 4 月 15 日 10:08 北京

最近这个词实在是太火了。

Harness Engineering。

我刷推刷到，朋友圈刷到，群里也在聊，微信指数又莫名其妙一根穿云箭了。

几乎每隔两三天就有人来问我，卡兹克你能不能讲讲这个 Harness 到底是什么。

所以想了想，我还是尽我可能，花了将近一整天的时间，给大家写一下我理解的 Harness Engineering 到底是个啥。

大家其实不要觉得 AI 行业喜欢造概念或者喜欢搞抽象，主要还是 AI 这玩意实在变得太快了，很多东西也都是随着时间和行业的发展不断的前进的。

一个东西在 24 年可能还满足当时的语境，但是 25 年可能就不够了，因为模型的进步速度太快了，于是 25 年大家只能用一个新的词来解释，结果，26 年，这个词又不够用了。

这个大概就是如今的现状。

跟 AI 跟的比较久的朋友，可能已经能猜到我上面说的是哪几个词了。

Prompt Engineering，Context Engineering。

还有今天的 Harness Engineering。

这三个词，几乎完美地标记了我们跟 AI 协作方式的三次进化。

而我恰好，这三个阶段都亲身经历过。

从 2023 年大家都在研究怎么写一个好 Prompt，到 2025 年开始研究怎么给 AI 更好的塞上下文，到现在 2026 年，大家开始聊，怎么给 AI 设置马具。

三年。

说短不短，说长也不长。

但回头看，这三次变化，其实都映射的，是我们人类对 AI 的认知。

打个游戏玩家都能秒懂的例子吧。

第一阶段，就是你在玩《只狼》这种动作游戏。

也就是每一招格挡、每一次见切都得你手搓，按一下键它出一招。

一招没按对，屏幕上就会出现巨大的死。你就是 AI 唯一的操作者，AI 每一个动作都得你亲自按键下令，动一下回一下，也就是我们传统的 ChatBot。

第二阶段，就是你在玩类似《金铲铲之战》这种自走棋。

你其实可以不用再自己手搓每一个动作了，你的活其实全在前期配置。

选英雄、凑羁绊、配装备、排站位。

配完了，棋子就自己上场打回合，你只能吃瓜看戏。而决定胜负的，全靠你前期把信息和资源喂得对不对。

这一个阶段，就是模型能力还不够强的时候的前 Agent 时代。

第三阶段，就类似是你在玩《全面战争》这种即时战略游戏。

场上几千个单位自己在跑，你根本摇不过来每一个兵，只能靠编队、阵型、AI 指令、战场规则去驾驭整盘战局。

单位越聪明、越自主，你越得靠一整套系统去约束它们的行为。

从操作一个角色，到带一个小队，再到指挥一整支军队。

玩家的控制粒度越来越粗，AI 的自主度越来越高，你需要的约束方式也越来越系统。

而这三个阶段，我觉得就对应了 Prompt Engineering、Context Engineering、Harness Engineering 的三次跃迁。

所以，聊 Harness Engineer 到底是什么，我觉得最重要的，就是你要知道这一路的跃迁究竟是什么样的。

想理解现在，最好的方式，就是读懂历史。

所以，今天这篇文章，我就希望能真的让你明白 Harness Engineering 到底是个啥，它的来龙去脉，以及他能解决的问题。

如果你是技术大佬，希望能给你提供一些新的思考角度，如果你是非技术的小白用户，我也会尽量让你看得明白。

话不多说，我们开始。

先从头捋。

先把时间倒回到 2023 年。

2022 年底到 2023 年，ChatGPT 横空出世，整个世界炸了。

我还记得 23 年的春节，春节回来之后，所有人都在聊 ChatGPT，而那之后，那段时间最火的一个词。

就是 Prompt Engineer，提示词工程师。

当时硅谷可以给 Prompt Engineer 开出了年薪 30 万美金的 offer。

然后国内也是，23 年的图，大家肯定都见过。

然后当时有无数的 Prompt 框架出现，因为彼时模型智能水平不够，所以很多时候，模型的输出不稳定，我那时候还在做 AI 产品，这里可以提一嘴，国内金融领域的第一个算法备案是我拿的。

我们每天做的最多的事，其实就是在 Prompt 上做约束，怎么设计好 Prompt，能让模型输出更稳定的 json 格式，从而跟我的数据库进行交互。

当然，也有另一部分，就是写好 Prompt 约束，让模型生成更好更稳定的回答。

那个年代，同一个问题，你换一种问法，AI 给你的答案质量就可能会天差地别。

比如你直接问 ChatGPT"帮我写一篇关于 AI 的文章"，它给你吐出来的东西大概率是一坨正确的废话。

但你如果说"你是一个科技领域的资深记者，风格偏口语化，擅长用类比来解释复杂概念，现在需要写一篇 3000 字的文章，主题是 AI 对普通人生活的影响，要有具体案例，语气不要太正式"，那出来的东西就完全不一样了。

所以你看，Prompt Engineering 那个年代，做的最多的事就是怎么设计 Prompt，能让 AI 给你最好的回答。

这事儿在 2023 年确实是有价值的，因为那时候大模型刚出来，输出也确实不稳定，大家都还在摸索跟它交流的方式。

谁能把问题问得更好，谁把 Prompt 约束的更好，就能从 AI 那里榨出更多价值，这个技能差异是真实存在的。

但问题来了。

2024 年下半年开始，一个趋势越来越明显，就是模型越来越聪明了。

你不用再像伺候大爷一样去精心构造 Prompt 了，Claude 3.5 Sonnet 出来的时候，你随便跟它说句话，它都能理解你的意思，那个时候我记得我还写了李继刚的汉语新解，也算是一代风潮。

那个时代，Prompt 技巧的边际收益在急速下降。

因为人们发现，当模型足够聪明的时候，你怎么问已经没那么重要了。

重要的是，你问的时候，它手里有没有关于你问题的足够且合适体量的信息，在有限的性能之下，来给你一个好答案。

至此，这就引出了第二个阶段。

2025 年年中，Andrej Karpathy 转发了一条推，大概意思是说，赞同把 Context Engineering 放在 Prompt Engineering 之上。

因为在实际的工业级 AI 应用里，真正的活不是在那雕花一个 Prompt，是需要更多的考虑工程化，要精心设计 AI 的上下文窗口里到底该塞什么信息。

因为那个年代，上下文窗口真的太小了。

Karpathy 的原话是，Context Engineering 是"填充上下文窗口的精妙艺术与科学"。

于是，Context Engineering，上下文工程，这个概念在 2025 年下半年迅速成为了所有做 AI 应用的人的共识。

因为他确实切中了当时行业人们的痛点。

在这里我还是想再次表达一下，很多时候，造词这事分两种情况，有一种我觉得就是为了炒概念，比如 xxx 4.0，而有的时候，真的只是行业太快，人们更需要一个精准的表达。

词语，从来都是为表达而服务的。

Context Engineering 解决的问题，就类似于你让 AI 帮你改一段代码，如果你只给它这段代码本身，它可能改得乱七八糟。

但如果你同时给它这段代码所在的文件、相关的依赖、项目的技术栈说明、团队的代码规范，它改出来的东西质量会高几个量级。

而如何优雅的、省 Token 的给出最精准的信息，就是真正的 Context Engineering。

这里我依然觉得，让我学到的最多，还是 Manus 的 25 年 7 月 18 号发的那篇文章。

到这里，其实已经比 Prompt Engineering 进了一大步了。

人们开始研究的是，从怎么约束单个 Prompt，变成了如何在有限的上下文空间里，尽可能的给模型精准的信息。

就这样，过了又将近 8 个月的时间。

Harness Engineering 正式登上了属于它的舞台。

如果是我自己印象中，第一次在 AI 领域看到关于 Harness 的描述，应该是去年 11 月 Anthropic 发的 blog。

这篇报告解决的核心问题是，就是如何让 Agent 跨越多个上下文窗口有效工作而不丢失状态。

他们把他们的 Claude Agent SDK 称为，"一个强大的通用 Agent Harness"。

不过他们并没有用 Harness Engineering 这样的描述。

直到 2026 年 2 月，OpenAI 的一篇 Blog，把 Harness Engineering 写在了巨大的标题上，于是，Harness 开始正式进入大众视野。

这篇也是有价值内容极多的一篇文章。

大概说的就是，OpenAI 内部有一个团队，用了五个月的时间，用 Codex 搭了一个将近一百万行代码的产品。

其中人类手写的代码量，是 0 行。

所有代码都是 Codex Agent 生成的，人类工程师全程没有写一行代码。

人类工程师做的工作，就是一直在做 Harness Engineering。

他们在设计架构边界，制定依赖规则，写自动化测试，配置 lint 规则，搭建 CI/CD 流水线，设计反馈循环机制。

他们在建一个笼子，一个让 AI Agent 能在里面安全、高效、可控地干活的笼子。

这个笼子，就叫 Harness。

Harness 这个词，来源于马具，就是马鞍、缰绳、嚼子那一整套东西。

马是一种非常强大的动物，速度快、力量大，但如果你不给它套上缰绳，它大概率会跑偏，甚至把你甩下来。

就像那句著名的台词：

Harness 的作用，就是把这股野蛮的力量，引导到你需要的方向上。

AI Agent 就是那匹马。

模型现在本身的能力已经极其强大了，它能写代码、能做分析、能跟外部工具交互、能自主决策。

但如果你不给它套上 Harness，它就会跑偏，会犯错，会在你不知道的地方搞出幺蛾子。

所以，Agent = Model + Harness。

这个公式是 LangChain 在博客上提出来的，我觉得这可能是 2026 年到目前为止，关于 AI 工程最精辟的一句话。

虽然 Birgitta Böckeler 说这个定义很泛，但是我觉得还是很形象的。

模型是马，Harness 是缰绳，光有马不行，你还得有一整套驾驭它的系统。

昨天我发的文章，其实一直在强调一个理念，叫约束先行。

其实这就是 Harness Engineering 中很重要的一环。

而一个真正的 Harness 到底长啥样呢，Birgitta 我觉得写的框架我觉得还是比较清晰的。

她分成了两类控制机制。

第一类叫 Guides(feedforward controls) ，引导。

就是在 AI 行动之前，提前给它设好规则，让它沿着正确的方向走。

这有点像高速公路上的护栏，你不需要每一秒都去纠正司机别开到山沟沟里，因为只要护栏在那里，车就几乎不会开到山沟沟里面去。

CLAUDE.md 文件就是一种 Guide，代码规范文档也是，架构决策记录也是，这些东西在 AI 动手之前就已经在那了，它们是前馈控制。

第二类叫 Sensors (feedback controls) ，检测器。

就是在 AI 做完事之后，用各种手段去检测它做的对不对。

自动化测试是 Sensor，代码 lint 是 Sensor，CI 流水线也是 Sensor，它们是反馈控制。

好的 Harness，是 Guides 和 Sensors 的组合，前者防患于未然，后者亡羊补牢，两个加在一起，形成一个闭环。

而每当你发现 Agent 犯了一个错误，你就花时间去设计一个方案，让它永远不可能再犯同样的错误。

这就是 Harness Engineer 的日常。

从来都不只是在写代码，最重要的工作，其实都是在设计一个让 Agent 如何不再放错的系统。

就像我昨天那篇文章里面聊得，就是 Claude Code 的规则体系怎么从全局 CLAUDE.md 一层一层穿透到项目级、再到文件夹级的事，约束从上往下走，一层管着一层。

这个其实虽然非常的简单，但是底层逻辑，其实跟 OpenAI 在那个百万行代码项目里做的事是一模一样的。

他们强制定义了一套分层架构，Types → Config → Repo → Service → Runtime → UI，六层，每一层只能依赖它下面的层，不能反向依赖。

有了约束，速度才不会下降，架构才不会漂移。

规则从来不是靠口头约定，是靠自动化测试来强制执行的。

如果你非要我给 Harness Engineering 定一个最核心的概念。

那我还是想用我昨天说的那 4 个字。

约束先行。

就像我们所设计的权限系统，你可以给 AI Agent 设置不同级别的权限，有些操作它可以自己做，有些操作它必须先问你，有些操作它绝对不能碰。

比如读文件可以它自己来，删文件必须先问，而像格式化硬盘这种操作，你永远想都别想。

所以你其实回过头来看，这三个阶段的演变很有意思。

Prompt Engineering 的时代，AI 是一个聊天机器人。

你跟它的交互方式是一轮对话，你说一句，它回一句。

在这个模式下，你唯一能影响输出的杠杆，就是你的 Prompt，所以大家拼命研究怎么写 Prompt。

Context Engineering 的时代，AI 变成了一个助手。

它不再只是回答问题，它开始帮你做事了，它要读你的文档，理解你的项目，调用你的工具，在这个模式下，光靠 Prompt 不够了，你还需要给它提供充足的上下文。

Harness Engineering 的时代，AI 变成了一个自主行动的 Agent。

它不是在等你的指令，它可以自己在那跑，它自己写代码，自己测试，自己提交，自己部署。

在这个模式下，Context 也不够了，因为 Agent 是自主运行的，你没法一直盯着它。

你需要一个系统来约束它、监控它、在它犯错的时候自动纠正它。

所以这三个阶段的演变，对应的其实是 AI 角色的三次升级。

聊天机器人 → AI 助手 → 自主 Agent。

而你，跟它的关系也变了。

其实我上个月也写过一篇短文，叫能用脚本就别用 Agent，讲的就是脚本→Skill→Agent 这个金字塔。

这个思路其实也跟 Harness Engineering 的理念差不多，能用确定性规则约束的地方就用规则，能用自动化检测的地方就用检测，只有那些真正需要判断力的部分，才留给 Agent 自由发挥。

你不会用大炮打蚊子，同样的道理，你也不该在可以用确定性规则解决的地方引入不确定性。

所以啊，其实 3 个时代的 Engineering，从来都不是什么替代关系，而是一层一层升维、随着时代前进的嵌套关系。

Harness Engineer 需要懂 Context Engineering，因为给 AI 提供正确的上下文信息本身就是 Harness 的一部分。

Context Engineer 也需要懂 Prompt Engineering，因为最终跟 AI 沟通的单元还是一条条的 Prompt。

每一层都没有过时，只是被更大的框架包裹住了。

那我知道，看到最后，你可能会问了，我又不是程序员，Harness Engineering 跟我有什么关系？

这是个好问题，我也知道很多看我文章的朋友不是技术背景。

我自己更不是程序员出身，我是用户体验设计师。

坦率的讲，Harness Engineer 这个角色，目前确实主要出现在软件开发领域，因为现如今，AI Agent 目前最成熟的落地场景，那就是写代码、开发产品。

但我觉得，Harness Engineering 的思维方式，其实是普适的。

比如很多朋友现在用 AI 做任何稍微复杂一点的事情，可能都会遇到这种问题，比如 AI 有时候莫名其妙就跑偏了，你得反复纠正它。

这就是缺少 Harness。

比如你能不能给 AI 设一些规则，让它在这些规则的框架内干活？比如你让 AI 帮你写邮件，你能不能事先告诉它，「永远不要用感叹号结尾」「收件人是老板的时候语气要正式」「涉及数字的时候要 double check」。这就是你的 Harness。

比如你能不能设计一些检查点，在 AI 输出之后自动验证？比如你让 AI 帮你做数据分析，能不能设一个规则让它每次算完都自己验算一遍？这也是 Harness。

20 世纪的伟大科学成就之一，控制论，里面最核心的一个思想，就是任何复杂系统的稳定运行，都依赖于反馈机制。

恒温器之所以能保持房间温度恒定，从来都不是因为它知道应该是多少度，是因为它有一个传感器能感知当前温度，然后跟目标温度做比较，然后不断的进行调整。

这些思维方式，就是 Harness Engineering 的内核，从来不是说，让你直接做技术去写代码，是需要你思考清楚，怎么让 AI 在我不盯着的时候也能干好活，是如何设计一个系统，能让你不用盯着的时候，这个系统也能自己运行起来。

其实我们驯服 AI 的过程，真的跟人类驯服大自然的历史，也有着极高的相似度。

最早人类学会用火，你得小心翼翼地喂它柴火，火太小不行，太大也不行。这是 Prompt Engineering，你的每一次输入都直接决定输出。

后来人类学会了建炉子，你把火关在一个结构里，通过调节进气口和烟囱来控制火势。这是 Context Engineering，你通过设计上下文来影响火的行为。

再后来人类发明了蒸汽机，火不再是你直接操控的对象了，它在一个精密的系统里自动运行，有锅炉、有气缸、有调节阀、有安全阀，你无需再管火怎么烧，你管的是这套系统怎么设计。这是 Harness Engineering。

从火焰到蒸汽机，人类花了几千年。

从 Prompt Engineering 到 Harness Engineering，AI 只花了三年。

甚至我觉得，如何使用 AI 演变到最后，其实就是人类历史上出现的那一门一门的古老的学科。

Harness 就是控制论。

Skill 其实就是分类学。

Prompt 其实就是语言学。

Context 其实就是信息科学。

Reasoning 其实就是认知心理学。

多 Agent 协同其实就是管理学。

所以，很多人天天说什么文科已死，我每次都会说这是放屁，从来没有什么文科已死理科已死的。

这世界就不应该再分文理。

两端融合，才是真正的王道。

多学科融合背景，有理工科的严谨，有文科的审美。

有结构化的理性，也有人文的洞察。

这样的人，在未来十年里，我才觉得会是整个社会里，能把 AI、Agent 用的最牛逼，同时也是未来最稀缺的那批人。

所以，根本不要焦虑。

Harness Engineering 根本不是什么新词。

它就是人类几千年来一直在做的那一件老事。

就是怎么把一股更快、更强、更不受控的力量，安全地、持续地、可复制地，引导到我们想要的方向上去。

火是这样，蒸汽是这样，电是这样，核能也是这样。

从我们学会用火开始，那几十万年的历史。

从来都是这样。

只不过，这一次，轮到 AI 了。

仅此而已。

当一个东西比你更快、比你更强、比你更自主的时候，你怎么还能让它，为你所用。

这件事，你的祖先做过，你的父辈做过。

只是现在。

轮到你了。

一文带你弄懂 AI 圈爆火的新概念：Harness Engineering

OpenBeluga 2026 年 4 月 16 日 19:29 上海

你有没有感觉，AI 圈每隔几个月就要造一个听起来特别高大上的新词？

每次看到这种新词，脑子里是不是自动浮现出这几个字："又是噱头"？

Prompt Engineering、Context Engineering、Meme Engineering、Agent Engineering......这些词你方唱罢我登场。大多数时候，它们的本质是：换了个名字重新包装常识，换个皮又来圈一波流量。

所以当我最近看到 Harness Engineering 这个词的时候，第一反应也是：这又是什么新瓶子？

但这次，我没有急着下结论。

我去翻了 Claude Code 源码泄漏的 51 万行代码，去看了 ConardLi 那篇被刷屏的文章，去翻了各种解读和讨论，去翻了 Hacker News 上的激烈辩论------这次，我决定先把东西看清楚再说。

结果我发现：

这一次，还真不是换皮。

Harness Engineering 背后，是 AI 工程领域一次真正的范式转移。它不是对某个旧概念的重新包装，而是大家在踩了足够多的坑之后，终于形成的一个共识。

这篇文章，我就把这件事彻底讲清楚。不是抄概念，是从源码出发，从工程实践出发，掰开揉碎地讲。

看完了，你就知道为什么这次不一样，以及它跟你到底有什么关系。

先说人话：Harness Engineering 到底是什么

Harness Engineering 的本质：给 AI 套上缰绳，让它老老实实干活。

Harness 这个词本意是"马具"、"挽具"。给马套上鞍具，马才能被人驾驭，不然就是一头野兽。

这个词用在 AI 领域，意思再直白不过：别再指望模型自己变聪明了，用系统去约束它的行为，给它划好赛道。

大白话说：别只顾着"做法"（调 prompt），要想办法让 AI 在可控范围内出活。

它出现的背景，是整个 AI 圈终于从"大模型崇拜"里清醒过来了。

为什么是现在：从"拼模型"到"拼系统"

要理解 Harness Engineering 为什么重要，我们需要先回顾一下 AI 工程化的演进历程。

这段历史理解了，你才能明白它为什么不是噱头，而是真正的升级。

第一阶段：Prompt Engineering（2019-2022）

这个阶段最早被广泛讨论。大家发现：同一个问题，换个说法问，AI 的回答质量差别巨大。

"这个 prompt 效果好，换个说法效果就差了"------这类经验被反复总结和传播。思维链（Chain-of-Thought）、Few-shot Prompting、Role Prompting......这些技术本质上都是在输入端做文章，研究的是"怎么说话，AI 才能听懂"。

金句：Prompt Engineering 的本质，是用文字技巧弥补模型能力的不足。模型越差，prompt 越玄学。

这个阶段的局限也很明显：prompt 是经验性的、非系统性的。效果好多少，全凭玄学；换个模型、换个场景，效果可能完全不一样。同一个"顶级 prompt"，在 GPT-3 上能封神，在 GPT-2 上可能就吐给你看。

第二阶段：Context Engineering（2022-2024）

光优化 prompt 不够，因为 AI 的回答质量上限取决于你喂给它的信息。Garbage in, garbage out------这在 AI 时代依然成立。

于是 Context Engineering 开始兴起。

这个阶段的核心问题变成了：喂什么上下文、怎么组织上下文，才是高效的？

RAG（检索增强生成）爆发，向量数据库成了标配，长上下文窗口成了各大模型的卖点。大家研究的是"怎么让 AI 看到更多、更好的信息"。这是信息组织能力的优化。

但这个阶段也有它的问题：信息量和信息质量之间存在矛盾。上下文太长，AI 会被无关内容干扰，产生更多幻觉；上下文太短，重要信息又被遗漏。怎么平衡，没有标准答案。

金句：Context Engineering 的本质，是给模型喂它需要的信息。但喂什么、喂多少、怎么喂，比喂本身更重要。

第三阶段：Harness Engineering（2024-现在）

但很快大家又发现了一个更根本的问题：

模型靠谱 ≠ 系统靠谱。

你用最强的模型，但如果它的执行环境没有隔离、权限控制没有做好、工具调用没有约束、错误处理没有兜底------它在生产环境里分分钟给你捅娄子。

而且当 AI 开始读代码、改文件、执行命令、操作数据库、管理权限......这些高风险操作时，约束就成了生死线。一个幻觉可能导致删库跑路，这不是危言耸听。

这个阶段的核心问题变成了：怎么让 AI 的行为在可控范围内？

于是 Harness Engineering 诞生了。它的核心从 "让 AI 知道什么" 彻底转向了 "让 AI 只能做什么"。

金句：Harness Engineering 的本质，是承认模型不可靠，所以用系统给模型的行为划边界。边界越清晰，系统越稳定。

三代 AI 工程：一张图讲清楚

为了方便理解，我用一张表格来做对比：

	Prompt Engineering	Context Engineering	Harness Engineering
核心问题	怎么让模型听懂？	怎么给模型喂对信息？	怎么让模型的行为可控？
优化方向	输入端（prompt）	信息端（context）	系统端（constraint）
技术代表	CoT、Few-shot	RAG、向量检索、长上下文	安全沙箱、权限系统、记忆框架
本质	用文字技巧弥补能力不足	给模型喂更好的信息	用系统约束替代模型自觉
局限性	经验性、非系统性	信息量和质量难以平衡	需要大量工程投入

三代演进的逻辑是什么？

每一代的出现，都是因为上一代的局限被触达了。

Prompt Engineering → 发现 prompt 再好，信息不够也没用
Context Engineering → 发现信息再充分，模型乱来也白搭
Context Engineering → 发现系统不可控，再好的模型也是定时炸弹

所以每一代都不是替代关系，而是叠加关系。今天的 Harness Engineering，是在 Prompt 和 Context 都已经做得足够好的基础上，加上系统约束这一层。

金句：三代 AI 工程的演进，本质上是一个"从外到内、从软到硬"的控制力升级过程。Prompt 是软控制，Context 是信息控制，Harness 是硬控制。

为什么是现在才爆发

有人可能会问：这些约束和控制，难道之前没人想过吗？

想过。但有两个前提条件制约了很久：

前提一：大模型能力不够强

早年的模型，推理能力有限。你不一步步引导它，它就容易跑偏。所以 ReAct 模式（强制让模型显式输出 Thought、Action、Observation）成了主流------因为模型自己管不住自己，必须时时刻刻盯着。

ReAct 的本质是什么？是用框架的复杂度换取模型的可靠性。框架告诉模型"你先想、再做、再看结果"，模型只需要按部就班执行就行。

但代价是什么？框架变重了，模型的自主推理能力被压制了。 好的模型被强制降级成了"听话的工具"，这是对算力的巨大浪费。

前提二：AI 应用场景太窄

如果 AI 只做问答、写作这些事情，确实不需要什么 Harness。但当 AI 开始读代码、改文件、执行命令、操作数据库、管理权限......这些高风险操作时，约束就成了生死线。

一个写文章的大模型幻觉了，最坏结果不过是生成了一篇废话。

一个操作数据库的大模型幻觉了，最坏结果是 DROP DATABASE。

这个差别，懂技术的人都懂。

现在，两个前提条件同时被打破了：大模型推理能力上来了，AI 的应用边界也在快速扩张。Harness Engineering 终于从"可选项"变成了"必选项"。

金句：ReAct 是弱模型时代的产物。当模型足够强的时候，你不需要告诉它"先想再做什么"，你只需要告诉它"什么不能做"。

Claude Code 源码泄漏：一个意外的宝藏

说到 Harness Engineering 的最佳实践案例，就不得不提最近 AI 圈最大的瓜：Claude Code 51 万行源码全网裸奔。

Anthropic 官方推出的编程 Agent Claude Code，因为 npm 打包时的一个配置失误，不小心把 .map 源码映射文件一起发布到了 npm。51 万行核心代码，就这么毫无保留地暴露在全网面前。

这波啊，这波叫史诗级手滑，意外之喜。

虽然是个乌龙事件，但从技术角度看，这反而成了一份极其珍贵的 Harness Engineering 教科书。

为什么这么说？

因为扒完这 51 万行代码，你会看到一个很有意思的现象：

Claude Code 80% 的代码，不是在让 AI 更聪明，而是在死磕"可靠性"。

它的核心精力投入在：

工具调用的权限控制------哪些操作是安全的、哪些需要二次确认、哪些必须禁止
执行环境的隔离------危险操作不能直接执行，要有沙箱保护
上下文的压缩和召回------怎么让 AI 只看到真正重要的信息，不被无关内容干扰
错误处理和降级策略------出问题了怎么优雅地兜底，而不是直接崩溃
多 Agent 协作时的状态同步------怎么确保多个 Agent 之间的信息一致

这些都是典型的 Harness 思维。

金句：看一个 AI 系统靠不靠谱，不是看它最好的表现有多好，而是看它最差的表现有多可控。Claude Code 的代码里，80% 在处理那 1% 的最坏情况。

Claude Code 的四层架构详解

根据源码分析，Claude Code 采用了一个四层分层架构。这个架构设计得非常有意思，每一层职责清晰，边界分明，但又相互配合。

第一层：应用层

这是直接面向用户的界面逻辑。用户输入什么、输出什么、怎么跟用户交互------全部在这一层处理。

应用层的特点是什么？尽可能薄。不做复杂的业务逻辑，只做路由和展示。把复杂的东西下沉到下层，让上层保持简单。

这个设计选择很有智慧。因为应用层是变化最频繁的地方------用户需求在变、产品形态在变，如果应用层很复杂，每次改动都会牵一发动全身。

架构图：

复制代码

┌─────────────────────────┐
│       应用层            │  ← 用户交互入口，最薄的一层
│  （界面路由/输入输出）    │
└──────────┬──────────────┘
│ 指令
▼
┌─────────────────────────┐
│       Agent 层           │  ← 推理决策，最"聪明"的一层
│  （推理/规划/工具调用）   │
└──────────┬──────────────┘
│ 执行请求
▼
┌─────────────────────────┐
│       引擎层             │  ← 工具封装，最杂的一层
│  （40+工具/API/文件）    │
└──────────┬──────────────┘
│ 操作请求
▼
┌─────────────────────────┐
│       安全层             │  ← 权限校验，最重要的一层
│  （权限/拦截/日志）       │
└─────────────────────────┘

第二层：Agent 层

这是核心的推理和决策模块。模型在这里决定：当前这个任务，下一步应该做什么？

Claude Code 在这层做了一个很重要的选择------信任模型的推理能力，不做过度的框架干预。

这和早期很多 Agent 架构完全不同。早期大家普遍用 ReAct 模式，强制让模型显式输出 Thought（思考）、Action（行动）、Observation（观察），每一步都强制干预，生怕模型自己跑偏。

Claude Code 的判断是：强模型应该自己完成推理，不需要你手把手教它走路。 框架做薄，把推理的复杂度留给模型自己去消化。

但"信任模型"不等于"盲目信任"。这套信任的前提，是系统层面的约束同样到位。模型在前面冲，安全层在后面兜底。

金句：最好的架构，是让强者充分发挥，同时确保它跌倒的时候有人接住。Claude Code 的 Agent 层负责"充分发挥"，安全层负责"有人接住"。

第三层：引擎层

这一层封装了所有工具调用和 API。Agent 发出的指令，最终都通过引擎层执行。

引擎层做的事情很杂：40 多种工具的封装、API 调用、文件读写、命令执行......全部在这里统一管理。它是 Agent 和真实世界之间的桥梁。

引擎层还有一个重要职责：做参数校验和类型转换。Agent 发出的指令可能是模糊的、不完整的，引擎层负责把它转化成具体的、可执行的 API 调用。

举个例子：当 Agent 说"读取那个文件"，引擎层需要知道"那个"指的是哪个文件、文件路径是什么、应该用什么 API 去读。

第四层：安全层

这是最能体现 Harness 思维的一层，也是大多数开源 Agent 实现里最容易被忽略的一层。

安全层做什么？

权限校验：AI 发出的每个操作请求，都要经过安全层的审查。不是想做什么就能做什么。
危险操作拦截：删除文件、执行系统命令、访问敏感数据------这些高危操作必须经过二次确认或者直接禁止。
行为日志：所有的操作都被记录下来，出问题时有据可查。

这种分层的好处是什么？

每一层都清晰可控。 当 AI 出问题时，你能快速定位是哪一层出了问题------是推理错了（Agent 层）？是工具坏了（引擎层）？还是约束不够（安全层）？

不是面对一团乱麻不知道从哪里下手。

金句：分层架构的精髓，不是把问题拆散，而是让问题的边界变得清晰。问题清晰了，解决问题的路径就清晰了。

记忆系统：一个被低估的设计

Claude Code 的记忆系统，是另一个特别值得展开说的地方。

很多人以为 AI 编程 Agent 最难的是"推理"，其实记忆才是真正的硬骨头。

为什么？

因为一个编程 Agent 需要记住的东西，远比普通对话 Agent 复杂得多：

用户的历史偏好：比如"不要用 mock 测试数据库"、"用户喜欢用 TypeScript，不喜欢用 JavaScript"
当前项目的上下文：项目结构、代码规范、依赖关系、已有的设计方案
工具的使用反馈：这个工具之前用过，效果如何，有什么坑，下次要不要换方案
任务进度：做到哪一步了，有什么遗留问题，接下来应该做什么

如果这些全部塞进上下文，上下文窗口再大也不够用。而且无关的记忆会稀释关键信息，让模型在真正重要的时刻看不到真正重要的东西。

Claude Code 的记忆系统是怎么设计的？

它没有用向量数据库做相似度检索。

这个选择很有意思。业界常见的方案是用向量数据库，把记忆存成 embedding，每次对话时做相似度检索。但 Claude Code 认为这个方案有问题：

Agent 需要记住的，大部分不是"相似的文档片段"，而是"结构化的行为指令"。

用向量相似度去检索"不要 mock 数据库"这句话，效果其实很差------它可能匹配到一堆包含"数据库"关键词的无关内容，真正重要的行为反馈却被淹没了。

Claude Code 的做法是用小模型做路由。一个廉价的小模型（比如 Claude Sonnet）来理解当前对话，判断需要召回哪些记忆，然后把相关记忆注入上下文。

整个召回流程分为三步：

复制代码

用户输入 → 小模型路由（判断需要哪些记忆）→ 注入上下文 → 大模型处理

这个设计的好处是什么？

记忆召回的准确率极高。 不是因为检索算法有多牛，而是因为路由做对了------它知道你要什么，而不是机械地匹配你说了什么。

金句：向量检索是"你说什么我找什么"，小模型路由是"你想要什么我给你什么"。一字之差，体验天壤之别。

为什么说 Harness 是未来五年的主战场

如果我们把 AI 系统的发展分成三个阶段：

第一阶段：模型为王

这个阶段的核心是"模型能力"。谁家有更大的模型、更多的参数、更好的预训练，谁就领先。这个阶段的基础设施是 GPU 集群和分布式训练框架。

第二阶段：数据为王

这个阶段的核心是"数据质量"。模型能力趋于同质化，差异化竞争转向了数据------谁有更好的数据、更好的数据管道、更好的数据治理能力，谁就领先。这个阶段的基础设施是向量数据库和 RAG 框架。

第三阶段：系统为王

这个阶段的核心是"系统可靠性"。模型和数据都不是壁垒，真正的壁垒是让 AI 在生产环境里稳定、可靠、可控地运行。这个阶段的基础设施是 Harness------约束框架、安全沙箱、记忆系统、错误处理机制......

我们现在正处于第二阶段向第三阶段的过渡期。

未来五年，Harness Engineering 会成为 AI 工程师最重要的技能。原因很简单：

模型会越来越强、越来越便宜、越来越容易获取
数据会越来越标准化、越来越同质化
但让 AI 在生产环境里可靠运行这件事，会越来越难、越来越关键

因为 AI 渗透的领域会越来越深，从聊天机器人到代码生成，从数据分析到自动驾驶，每一步都在往高风险场景走。

在低风险场景里，AI 错了也就错了；在高风险场景里，AI 错了可能要命。

金句：AI 的能力边界在扩大，但人类的容错空间没有扩大。Harness 的本质，是在扩大的能力边界和不变的容错空间之间，找到一个可控的交集。

Harness Engineering 的六个关键原则

结合 Claude Code 的源码分析，以及我对各种 AI 系统的观察，我总结了 Harness Engineering 的六个核心原则：

原则一：约束优于引导

不要指望 AI 自己"知道"什么不该做。你应该直接告诉它"不能做"，从系统层面禁止，而不是从提示词层面引导。

引导是软约束，约束是硬约束。AI 在复杂任务里会疲劳、会分神、会受干扰，软约束靠不住。硬约束才能保证底线。

金句：靠提示词告诉 AI"你不要删我的数据"，就像用胶带告诉小孩"不要碰电源"------有用，但不保险。

原则二：分层优于单一

Claude Code 的四层架构告诉我们：功能要分层，职责要单一。应用层不要做引擎的事，引擎层不要做安全层的事。

分层之后，出问题才好定位------这是工程化的基本常识，但在 AI 系统里尤其重要，因为 AI 的行为有太多不确定性，分层是控制这种不确定性的唯一有效手段。

原则三：信任模型但验证系统

Claude Code 选择了"信任模型推理能力"这条路，但它的前提是系统层面的约束同样到位。

不是盲目信任，而是在信任的同时，做好所有安全兜底。这就像现代软件工程的最小权限原则------默认信任，但始终验证。

金句：信任是效率的来源，验证是安全的兜底。没有信任的系统是瘫痪的，没有验证的信任是裸奔的。

原则四：记忆要结构化，不要只靠向量检索

向量检索适合找"相似的文档"，不适合找"行为指令"。记忆系统要结构化，路由要精准。

Claude Code 的实践证明：用小模型做路由，比用向量相似度匹配效果好得多。 因为路由是语义理解，匹配只是字面比较。

原则五：框架做薄，逻辑给模型

框架的复杂度要尽可能低，把推理和规划的复杂度留给模型自己去消化。

这条和传统软件工程的思路相反------传统软件工程强调"框架要健壮、逻辑要分离"，但在 AI 时代，把太多逻辑写死在框架里，反而会限制模型的能力。模型比框架更擅长推理，让它发挥。

金句：框架的职责是"让模型自由"，而不是"替模型做主"。

原则六：可靠性是迭代出来的，不是设计出来的

最后一条，也是最重要的一条：Harness 不是一次性设计出来的，是踩坑踩出来的。

Claude Code 的 51 万行代码，不是某个架构师在白板上画出来的，是无数真实用户在真实场景里遇到问题、反馈问题、修复问题，一行一行堆出来的。

所以，不要指望一开始就把 Harness 设计完美。先跑起来，让真实用户在真实场景里用，然后收集反馈，迭代改进。这才是做 AI 产品的正确方式。

金句：最好的 Harness，来自最痛的踩坑。每解决一个 bug，系统就多一层免疫力。

写给一线开发者的建议

说了这么多，如果你是一线开发者，最关心的可能是：我应该怎么做？

几个具体的建议：

如果你在从零构建 Agent 系统

先想清楚 Harness，再想清楚模型选型。很多人一上来就纠结"用哪个模型最强"，结果 Harness 没做好，模型再强也发挥不出来。

先把工具调用、权限控制、错误处理这些基础设施做好，再考虑模型层的优化。基础设施不对，优化模型是往沙子上建楼。

如果你在使用现有的 Agent 工具

理解它的 Harness 机制。哪些操作是受限的、哪些是需要确认的、哪些是有风险提示的------搞清楚这些，才能用好它。很多时候不是工具不好用，是你没用对。

如果你在面试 AI 相关的岗位

Harness Engineering 会成为面试的重点。不是问你"怎么写 prompt"，而是问你"如果让你设计一个可靠的 AI 系统，你会怎么做"。

Claude Code 的四层架构、记忆系统设计、安全层实现......这些都值得你认真研究。未来的 AI 面试，问的是"系统设计能力"，而不是"调 prompt 的技巧"。

最后

Harness Engineering 这个词听起来唬人，但它的核心思想一点都不新。

系统设计的重要性 > 模型能力的重要性。

就像造车。发动机再猛，刹车不灵、方向盘失灵，这车你敢开吗？

AI 也一样。模型再强，没有 Harness，它在生产环境里就是一颗定时炸弹。你不知道它什么时候会出岔子，也不知道出了岔子之后该怎么处理。

所以，别再只盯着模型参数了。

是时候关注一下你给它套的缰绳牢不牢了。

未来五年，真正拉开差距的不会是"谁家的模型更强"，而是"谁家的系统更可靠"。

先把这件事想清楚，比追任何新概念都重要。

一文讲透：Harness Engineering 即控制论！

邬俊杰腾讯云开发者 2026 年 4 月 17 日 08:46 北京

01 前言

去年有幸获赠 2 本书，其中一本是《控制论和科学方法论》，读书过半我就发了条朋友圈，因为我当时觉得自己发现了一件不得了的事情。

不得了自然是有些夸张了，但是我的确因为这一想法而兴奋良久，当时我认为**AI 编程就是控制论在编码世界的一个工程实现。**奈何我在网络并没有搜到相关言论，以至于我对自己的这一想法产生了怀疑。直到 3 月份看到 OpenAI 发表的文章《Harness engineering: leveraging Codex in an agent-first world》以及硅谷工程师 George 的分析文章《Harness Engineering Is Cybernetics》，甚是惊喜。

1948 年维纳出版了《控制论：或关于在动物和机器中控制和通信的科学》一书，它是通过信息传递来实现目的性行为的理论，关注系统如何通过接收外界和内部的信息来调整自身状态，以达到预定目标。而今天 AI"输入-输出-修正"的回路，与维纳笔下的逻辑何其相似，我们热谈的 AI 编程到底是不是控制论的一个工程实现呢？

看清来路，或许能更清醒地面对潮头的喧嚣。

## 02 Harness Engineering

Harness Engineering 这个词缘起于 2026 年 2 月 11 日 OpenAI 发布了一篇文章：《Harness engineering: leveraging Codex in an agent-first world》（https://openai.com/zh-Hans-CN/index/harness-engineering/），这篇文章有一些亮眼的数据：

3 个工程师、5 个月内、1500 个 PR、100%AI 编写，完成了一个 100 万行代码、已投入使用的的系统。他们预估与手工编写相比他们节省 90%的时间。

文章的核心理念是**人类掌舵，智能体执行，人类绝不动手编写一行代码。**当然这里和我们平时开玩笑"码奸"背叛了码农在革码农的命并不是相同含义，并不是不需要人类编码，而是工程师的工作中心发生了变化，负责为 AI 设计环境、明确意图、构建反馈回路。

文章还介绍他们实践 Harness Engineering 过程中踩的一些坑，我读后收益匪浅，这里概括的介绍一下。

2.1** 给目录而不是整本说明书**

不要尝试用一个巨大的 AGENTS.md 文件来指导 AI 来完成代码生成，因为它会挤占上下文、不能体现规则的重要等级、导致规则难以维护......正确做法是将 AGENTS.md 控制在约 100 行，仅作为索引目录，AI 需要时再根据目录找到深层知识，也就是我们所说的渐进式披露（PS：SKILL 不就是这个样子吗，同样的道理不要写过长的 SKILL.md）。

2.2** 规则要沉淀到仓库**

代码仓库是 AI 唯一能看到的世界，AI 没有办法看到人类大脑中的想法，也无法知道编码环境之外的任何内容。因此我们平时所有的设计决策、架构约定、团队共识都必须以版本化的 Markdown、代码或可执行计划的形式提交到仓库，否则 AI 会像一个迟到三个月入职的新员工，对这些信息一无所知。

2.3** 务必要有架构约束**

仅靠一个文本或者 Prompt 没有办法约束 AI 生成完全符合要求的代码，AI 只有在架构确定的环境中效率才是最高的。我们可以通过脚本、流水线等校验生成的代码是否满足架构约束，防止出现架构漂移。需要注意的是，在规则中应该明确哪些地方需要限制，哪些地方不需要限制，比如生成的代码必须分为 gateway、domain、dao 三层，至于某一层或者某一块的具体实现，允许 AI 自由发挥。

2.4** 构建 AI 可观测的系统**

AI 的代码生产效率远远高于人类，这时候人的评审反而成了效率的瓶颈，因此最好的方式是 AI 可以自己发现错误、修复错误、验证修复。例如将日志、监控等信息通过文件、MCP 等方式暴漏给 AI，让 AI 可以自己闭环掉开发------测试------修复。

2.5** 等待成本高于纠错成本**

这里一条我是存疑的，因为在很多场景，比如金融支付业务，安全稳定比快更重要。文中提到 PR 生命周期应尽量短，不要因为偶发性失败而阻塞，因为 AI 的代码产出速度远远超出人类的 PR 速度，纠错成本低，等待成本高。

2.6** 让 AI 自动清理垃圾代码**

AI 生成新代码时会参考已有代码，因此一次坏的实现会被多次复制，架构可能快速漂移。这个如果靠人来手动处理会耗费极大的时间和精力，因此需要将"黄金原则"编码到仓库中，并运行后台 Codex 任务定期扫描偏差、发起重构 PR------持续小步迭代还债远好过等到累积到一个大债务再去解决。

2.7** 人类的建议要沉淀到仓库中**

代码审查中的评论、重构 PR 和用户反馈中体现出了人类对代码实现的要求，这些信息如果只停留在口头或聊天记录中就无法影响未来 AI 的输出，因此必须将这些信息提取为规则，写到文档中或者编码进工具，才能让人类的要求持续的约束 AI，而不是随着时间流逝而消失。

## 03 控制论

题目中还有另外一个关键词------控制论，我去年才接触《控制论和科学方法论》这本书，它并不厚，正文只有 215 页，但是所描述的理论框架却无比强大，这里有一个很有说服力的例子：钱学森将维纳的控制论思想引入到工程系统中出版了《工程控制论》一书，而该书是"两弹一星"工程在控制与制导领域的重要理论工具书。当然，本文的重点并不是介绍控制论（Cybernetics），因此我以较短的篇幅将控制的核心介绍清楚，以便于进行后续的讨论。

控制的核心可以用一句话概括：**通过信息的获取与反馈，对系统进行调节和控制，以实现特定目标的科学。**这里提到了三个关键词，我们逐个讲解。

3.1** 关键词------信息**

信息这个词我们无比熟悉，但是到底什么是信息却难以言明。在控制论和信息论的视野下，信息的本质可以作如下解释。

**信息是"消除不确定性"的东西。**举个例子：我写的这篇文章是不是好文章？读到这里你并不知道，它可能干货满满也可能是 AI 水文。但是旁边同事告诉你"这篇文章太棒了你一定要读完"，这时不确定性就减少了，你就获得了信息。

**信息是我们在适应外部世界、并将这种适应反作用于外部世界的过程中，同外部世界进行交换的内容本身。**宇宙倾向于从有序走向无序（熵增），而获得信息的过程就是减少系统无序性、克服熵的过程。在迷雾中开车随时可能走错方向（熵增），突然手机导航提醒前方 100 米左转（信息），你左打方向盘（控制）让车子保持在正确的路上。

信息这一概念明确了，那么这些概念也明确了：知道------人获得信息的过程；传递------信息源和接受者两个系统之间的联系，即一个事物对其他事物的影响......

3.2** 关键词------控制**

在讲控制之前，我们需要先讲一下可能性空间，这也是控制论和系统论的研究开始的地方。依然用一个例子来讲可能性空间：我和你的关系。我们并不是从出生开始就注定成为同事，这里面有非常多可能性，但是由于条件或者纯粹机遇的关系，比如你从小受到良好的教育学习一直不错，而我可能恰好高考运气爆表蒙对了好几道选择题，于是我们都进入了不错的大学，工作时你因为"有鹅选鹅"、而我可能纯粹因为深圳离家近都选择腾讯，于是咱们成为同事。

你看，在我们刚出生时我们的关系有各种可能，陌人生、朋友、同事......由于各种条件或者纯粹的机遇，我们的关系才沿着某一个特定的方向发展下去。如果我们进一步思考：假如有上帝，上帝有没有办法通过一些手段干预，让我们成为同事的概率变大呢，这就是我们要讨论的控制。

**控制的本质是为了达到既定目标，通过克服不确定性，对系统施加影响的过程。**通过以上案例，我们也知道作为控制对象的两个共同点：1）被控制的对象必须存在多种发展的可能性；2）人可以在这些可能性之间，通过一定手段来选择。而 AI 生成的代码仓库完全具备这两个特点。

书中有一个例子来讲控制能力分析，这个本文没有太大关系，但当时读到这里我非常震撼，实在忍不住分享出来，不感兴趣可以跳过：

复制代码

12 个小球，能否用天平称 3 次，找出唯一的、轻重未知的那个小球？
这是一个数学问题，我记得某次数学竞赛中做过，当时费了好大劲来得到答案，那么我们如果用控制能力来分析，我们来看下多简单：
未称之前，每个小球都可能是废品，废品有轻重两个状态，可能性空间为 12*2=24
天平每称一次控制能力为 3（左边重、右边重、一样重），即可能性空间缩小为原来的 1/3
称三次控制能力为 3*3*3=27，27>24，因此可以解决问题。

3.3** 关键词------反馈**

反馈是指将系统的输出信息返送到输入端，与期望目标进行比较，并根据其中的"偏差"来调节系统下一步行为的过程。反馈分为正反馈和负反馈，正反馈和负反馈之间的主要区别在于对变化的响应：正反馈会放大变化，负反馈会减少变化。正反馈比较罕见，有时候被称为恶性循环，例如体温过高导致代谢加快，产生更多热量，体温进一步升高，出现失控。

这里强调一下负反馈，因为**负反馈扩大了系统的控制能力。**我们的身体处处有着负反馈，为了达到我们身体健康这一目标，血糖升高则分泌胰岛素降低血糖，血液变热则血管扩张、汗腺排汗......

简单来说，反馈就是让系统具备"自省"和"自我修正"的能力，让系统从"死的东西"变成了"活的系统"，具备"自省"和"自我修正"的能力。

3.4 小结\

读到这里，相信你尽管还不能完全掌握控制论，但是已经等感受到控制遵循的逻辑循环：

设定目标 \] → \[ 感知偏差 \] → \[ 施加干预 \] → \[ 消除偏差

这和我们使用 AI 何其相似：写 Prompt 给 AI 设定目标，AI 执行我们验收，不满意（出现偏差）则修改 Prompt 或者 SKILL/RULE 文件施加干预，让 AI 消除偏差以完成我们设定的目标。

## 04 Harness Engineering 和控制论

4.1 业界观点\

George 在 X 上发布的长文《Harness Engineering Is Cybernetics》，文中提到这种模式他见到三次，一次是离心调速器，带配重的飞球机构会感知转速，再自动调节阀门，工人没有消失，但工作内容变了，从亲手拧阀门，变成设计调速器；一次是 Kubernetes，声明一个期望状态，控制器会检测容器的状态，一旦两者偏离，它就会根据声明做出调整，比如重启、扩容、缩容......，工程师的工作也从手动操作，转向编写容器的描述文件；一次是 Harness Engineering，OpenAI 工程师不再手写代码，而是设计环境、搭建反馈回路、把架构约束编码进去，然后由 Agent 来写代码。而以上三种模式，就是今天所讲的控制。

博客中的一个观点令我印象深刻，代码库过去实际上一直是有反馈回路的，但只限于低层级（例如编译器校验语法......），而更上层，即架构层面的决策、质量判断等问题只有靠人判断、修正，而 AI 则可以让这个反馈回路闭合，识别问题并修复问题。然而真正的难题是把人类独有的知识变成 AI 可读的东西，大多数情况的失败并非 AI 能力不够，而是知识一直锁在人的大脑里。过去人们总是跳过编写规则直接写代码，因为他们要为此付出代价可能要在很久以后，但到了 AI 时代付出的代价会被成倍放大，因为 AI 代码生产效率实在是太高了。

所以人不需要在实现上（写代码）战胜机器，而要在评估上胜过它：定义什么是正确、看出哪里偏了、判断方向对不对。

4.2 我的观点\

我深信 Harness Engineering 就是控制论，控制论除了可以作为两弹一星的指导工具，同样也是 AI 编程的指导工具，下图是一个控制过程，那么在 AI 场景对应如下：

目标：即需求，需要 Agent 完成什么事，达到什么效果

控制器：即 AI

被控系统：软件代码

传感器：各种 QA 校验工具

目标

AI 发展实在是太快了，在不同阶段，为了用好 AI 流行过 Prompt Engineering ，核心问题是"怎么把一句话说清楚问题"；后来的 Context Engineering ，在 Prompt Engineering 的基础上还需要告诉 AI 完成该任务需要知道哪些知识、可以这么做......但是这些阶段要解决的**核心问题依然是怎么让模型在做决策时手里有足够的信息。**那么从控制论角度，我们如何和 AI 描述目标呢，我认为要讲清楚三件事。

需要做什么

关于如何描述需求实际上业界早已经有方法学来解决这个问题，比如软件方法中推荐使用 UML 表示法来表示。在 AI 兴起之前，接到一个需求进行领域建模是一件自然而然的事：使用用例规约描述系统对外表现是什么样子的，即需要交付什么样的价值；使用类图、序列图、状态机等描述系统是内部结构是怎么样子的。但是随着 AI 的兴起，兴许是大模型的强大让人浮躁，很多人认为人无需再进行痛苦的思考，我可以向大模型许愿。

但我们要明白，大模型并非全知全能，它更像是一个执行力极强的员工。其所有知识终归源于人类，即便表现出创造力，也是在人类引导下的"再创造"。因此我认为过去的方法学并没有死去，相反它变得更加重要。因为大模型是基于已有的知识训练，对于流行的、被普遍接受的形式，恰恰是给 AI 讲清楚需求的最好手段。

因此我给出一个暴论：领域建模并不会消失，相反会扮演更重要的角色。

需要怎么做

**我们需要告诉 AI 需要知道什么知识，为 AI 提供解决问题所必需的事实、数据、知识。**我们说需求是目的地，但是到达目的地有无数条路，这些路有的直接，有的弯曲。如果弯曲的路多了，那么代码就难以维护。

a) 用框架和规范降低可能性空间

因此我们需要告诉 AI 规范：使用什么框架、遵循什么代码规范、使用什么编码风格......来降低代码代码生成的可能性空间，将 Agent 生成代码的可能性为从 M 降低为 m。举一个简单例子：我让 AI 写一个冒泡排序，AI 有一万种写法（不同语言、不同库、不同变量命名风格......），也就对应可能性空间为 M，但是，如果我告诉它必须用 C++写，AI 生成的代码的可能性空间就小了一些，我如果告诉 AI 必须使用 C++、只能基于基础库实现、使用大驼峰命名、遵循为公司 C++代码规范，那么生成代码可能性空间就更小了，也就是生成的代码更确定了。

毫无疑问，我们（Agent）能力范围之内 m 越小越好（即尽量优雅、规范的代码实现），有人会说：反正都是 AI 维护代码，代码的好坏有什么影响呢？

这就不得不提到另一个概念，核爆炸、癌细胞生长、传染病的流行现象，表面上看毫无影响，但是控制论给出了统一的名字：自繁殖系统。**在一定条件下，某变量的值越大，变量的值增加越快，自繁殖系统一旦存在，无论一开始他对周围环境影响多小，最后都将产生巨大的、不可忽视的影响，**比如核爆炸。假如 AI 首次写了一个烂代码，后面的实现大概率会参考该烂代码编写，当到一定程度后，AI 也没有办法控制了。

过去我所在的部门建设了大量的规范和标准化框架、组件，一旦这些基建接入 AI，无疑是让 AI "听话"的利器。

b) 合理的流程规划实现控制力累积

将一个大任务拆分为一个个小任务会让代码生成效果更好这已经是共识。但是为什么呢，我们同样可以用控制论来解释。

首先我们知道，AI 虽然强大但不是万能的，换句话说，AI 作为控制器其控制能力有限，并不能 100%满足我们的要求。那如何扩大 Agent 的控制能力，来达到预定目标呢，答案是通过负反馈调节。来看一下老鹰抓小鸡的例子，我们把老鹰额动作看作是一些里俯冲的连续，每一次向目标俯冲看作是对自己的控制。老鹰的控制力优先并不能一次就达到目标抓到兔子（兔子也会跑不是），只能逐步向目标接近。

第一次俯冲可能性空间由 M 缩小到 M1，发现距离目标较远，调整方向发起第二次俯冲

第二次俯冲可能性空间由 M1 缩小到 M2，发现距离目标较远，调整方向发起第三次俯冲

第三次俯冲可能性空间由 M2 缩小到 m

通过三次俯冲，老鹰的总控制能力为：(M/M1)(M1/M2)(M2/m)=(M/m)，达到了抓到兔子的目标。

同样在 AI 生成代码时，由于 AI 控制能力有限，我们需要不断的通过反馈让 AI 进行调节，通过多次控制能力的积累，生成代码的可能性空间就由 M 缩小到 m 了，也就生成满足我们要求的代码了。

用什么工具

人之所以强大，因为人会使用工具。人靠自身做不到的事情但是使用工具就可以。同样我们也需要给带提供工具，并且告诉 AI 这些工具能做什么以及做了之后的结果，为模型提供与外部世界交互的能力。

我们再来聊一下控制论中的共轭控制。我们直接让 AI 生成满足我们要求的代码，可能就像老鹰俯冲一次就抓到兔子一样困难，除了流程规划来实现控制能力的累积，还有一种手段就是共轭控制。我们无时无刻都在使用共轭控制，只是我们不自知，我们通过一个经典的例子来解释：曹冲称象，使用船和石头称出大象的重量，假设：

L：把大象的体重变成石头的重量

A：称出石头的重量

L-1：把石头的重量变换成大象的体重

那么我们把 L-1AL 称作与 A 共轭的控制方法，把原来无法完成的事转变成了可以控制的 A 过程从而去完成。这个过程非常简单却应用非常广泛，而在现代化的自动控制设备中 L 和 L-1 分别称为感受器和效应器，人基于感受器采集的各项指标操作按钮控制机器生产。对应 AI 生成代码，L 感受器则基于各种输入收集代码生成的各项参数给 AI 分析，AI 通过参数或者调用不同工具控制选择，L-1 效应器（各种 MCP、SKILL 脚本）则将各种参数转换为代码，让 AI 使用工具完成原来不能完成的事。

4.3 传感器\

控制循环中之所以能够自矫正，就是因为有传感器在持续的收集信息，然后不断的计算和目标之间的差距，那么 AI 生成代码代码的传感器是什么呢，我认为有如下两类：

业务无关的传感器

这是我自己造的词，换一种说法可能更好理解，就是这里有一段代码，你不用了解这段代码是做什么的，但是你知道这段代码不对，为什么呢，因为语法不对编译不过！这就是业务无关，而检测这种错误的组件、流水线等就称为业务无关的传感器。

在上文中已经提到，我们要保证仓库的代码整洁，因此这些和业务无关的检测组件一定要接入到整个 AI 生产代码的过程中，比如代码规范、安全规范、语法检测、部署失败日志等等。AI 在完成代码生成任务后需要运行这些检测组件，然后根据检测组件出具的报告修复代码。

业务相关的传感器

不知道你是否和我一样，曾经迷茫这样一个问题：我们给 AI 的输入，到底应该详细到什么程度。我还是以《代码千行不如架构图一张！程序员如何培养业务思维，做有价值的需求？》中的例子：要实现扣款用例，你可以这样告诉 AI：

复制代码

基本路径：
1. 服务商收银系统提交消费信息
2. 系统提示学生刷脸
3. 系统验证刷脸学生账号签约状态
4. 系统请求 XX 支付扣款
5. 系统保存扣款结果
6. 系统返回扣款单信息
扩展路径：
3a. 学生账号未签约：
3a1. 系统通知家长签约
4a. 扣款账户余额不足：
4a1. 系统校验垫资条件
4a1a. 不满足垫资条件
4a1a1. 转到 5
4a2. 系统请求 XX 支付扣款
4a3. 系统通知家长还款

你也可以这样告诉 AI：

复制代码

前置条件：
存在已经完成签约的学生账户
后置条件：
扣款凭证已经关联一笔扣款成功的支付订单
涉众利益：
家长--担心由于忘记充值，账户内余额不足而导致孩子无法吃饭
餐厅老板--担心卖出饭但是没有收到对应的款项
系统提供商老板--担心出现大量垫资未还的欠款，产生坏账造成资金损失
基本路径：
1. 服务商收银系统提交消费信息
2. 系统提示学生刷脸
3. 系统验证刷脸学生账号签约状态
4. 系统请求 XX 支付扣款
5. 系统保存扣款结果
6. 系统返回扣款单信息
扩展路径：
3a. 学生账号未签约：
3a1. 系统通知家长签约
4a. 扣款账户余额不足：
4a1. 系统校验垫资条件
4a1a. 不满足垫资条件
4a1a1. 转到 5
4a2. 系统请求 XX 支付扣款
4a3. 系统通知家长还款
字段列表：
1. 消费信息=消费金额+商户订单号
2. 扣款单信息=扣款金额+是否垫资+支付订单号
业务规则：
1. 单学生账户最多同时存在 3 笔欠款
2. 垫资只针对消费金额小于 30 元的订单
3. 每个学校有垫资上限，垫资上限=学生数*3*30*10%
质量需求：
1. 扣款从收到请求到结束在 5 秒内完成
设计约束：
1. 收款系统使用 XX 支付

这里有一个非常有意思的点，我们写第二个规则所花费的时间一定是多于第一个，但是如果将这两个用例规约作为 Prompt 提供给 AI 生成代码很可能效果是一样的，因为 AI 很"聪明"，尤其是迭代老项目时，它极有可能基于已有的代码实现推测出来这个用例应该是什么样子。

于是我们难免会想：既然详尽的 Prompt 未必比简单的效果更好（即便略好一点，却需耗费大量时间打磨），为何还要如此费劲？

我认为这是因为短视造成的，只着眼于代码生成，而忽略测试、维护。**简单的 Prompt 也许也能生成正确代码，但是它缺少一个标准，一个可以让 AI 知道生成代码对不对的标准，**这个对不对不是指语法，而是指是不是 100%满足业务规则。回忆一下，人接到一个需求一定要和产品确认细节，为什么要确认下这些细节呢，因为我们开发完了要进行测试，确认自己实现的逻辑是对的，绝对不会基于一个糊涂的需求靠猜测实现上线。既然我们要求产品给出清晰明确的需求，为什么我们给 AI 提需求时就要模糊呢。

所以答案也就很明确了：我们给出的业务规则，一定要写到 AI 可检测、可验证为止。

我们可以预想一下，假如测试、规范检查、语法检测、UAT 这些反馈回路全部嵌入到 AI 的执行循环内部，AI 每生成一段代码就自动验证并修复，这将和人工 Review 后手动修改有着天壤之别------错误的发现和修复从数小时缩短到了数分钟。

现在矫枉过正了吗

我们常常听到一些吐槽，例如吐槽强迫研发使用 AI 编写代码、吐槽所有的流程都在强行 AI、吐槽引入 AI 后提效非常有限或者说比原来更慢了等等，短期来看也许吐槽的很有道理，但假如我们坚持"长期主义"呢？（扯个大旗）

在《毛选》中有关于"矫枉过正"和"矫枉必须过正，不过正不能矫枉"的讨论，而在控制论中，针对矫枉过正有一个专门的术语------滞后，书中有一个例子：一根铁丝我们施加一定力会变弯，松手后并不会完全变直，而是要适当的往相反的方向施加一个力，也就是要"矫枉过正"。

那什么时候矫枉过正呢？控制论中的突变理论介绍了矫枉过正和飞跃现象之间的矛盾，如果质变中经历的中间过渡态是不稳定的，那么他就是一个飞跃的过程，如果中间过渡态是稳定的，那么他就是一个渐变的过程。例如水的沸点是 100 摄氏度，但实际上由液态变为气态需要略高于 100 摄氏度，这就是因为它是一个飞跃的过程，水汽化时并不能停留在一个稳定的状态，要么液态、要么气态。当质变以飞跃方式进行时可能需要矫枉过正。

而研发模式的升级我认为将会是一个飞跃的过程，之所以现在我们仍然需要需要参与编码，一个非常大的原因就是缺乏传感器和基建，仍然需要人来串流程，比如需要人来验证 UI 是否正确、需要人来告诉 AI 代码不符合代码规范，因此在有些场景我们仍然感觉 AI 完成的很吃力，但这不是 AI 能力不行，而是我们并没有为 AI 提供友好的环境......未来的某一天当我们的传感器建设的完善到一个临界值，AI 编程再也不需要人来串流程了，我相信所有人会立刻抛弃原有个开发模式，就像我们迅速抛弃传统 IDE 去拥抱 Cursor 一样。

当然这是我浅薄的理解，并没有经过精密的推导，供大家批判。

## 05 对我的影响

前面对控制论做了简介，讲了 OpenAI 的提出的 Harness Engineering 以及一篇比较火的对 Harness Engineering 分析的帖子，总结了我的一些思考，这些内容对我的影响是巨大的。

5.1 它证明了一件事\

在我看到 openai 的文章之前，我一直有一个怀疑：AI 能否大规模地构建和维护复杂、可靠的软件，例如金融支付系统。之前我倾向于 AI 只能独立完成较小规模的软件，而大规模软件一定需要人的参与，其形式是 AI 和人共同来完成代码开发，AI 只能生成一部分，无法 100%生成代码。而这边文章用实际案例证明了这是可行的，尽管仍然面临一些挑战。

5.2** 它纠正了一个错误**

我经常吐槽，每次让 AI 完成一件事，我要写详细的规则描述，更让我苦恼的不是写完就完事了，每次 Agent 犯了一个错，我就要回去调整、测试、出错、调整......这个循环反复了几十次之后，规则文件变成一个成百上千行的文档：里面有方法、规范、禁止......

曾经我一度认为，这完全就是在浪费时间，这属于买椟还珠，对于程序员来说写代码才是正事！

曾经我一度认为，先把 Cursor 的 Tab 提示用好了再说，程序员一定要接触代码。

然而，现在我意识到，这种想法完全是错误的，写规则文件并不是浪费时间，那就是 AI 时代程序的工作本身。

5.3** 它改变了一个观念**

之前在我的观念中，程序员和 AI 要么是替代关系，要么是协作关系。

替代关系：有观点认为 AI 会完全替代程序员，程序员将会被大量裁员。我时常认为这种观点太极端了，或者太乐观了，他们过于乐观的认为 AI 可以完成程序员能做的所有事，但是我又时常认为他是正确的，因为大模型发展实在是太快了，也许有一天他真的能够替代程序员。

协作关系：还有一些人认为程序员和 AI 是协作关系，他们认为 AI 一定不能 100%生成代码，或者说很长一段时间内不能 100%生成代码，而不能生成的这一部分就需要人来编写，程序员既扮演者指挥者的角色，也扮演着协作者角色，和 AI 共同来完成一个软件的代码实现，我之前更倾向于这种观点。

但是这两篇文章改变我之前的观念，现在我认为他们是管理与执行 的关系：AI 可以生成 100%的代码，但并不意味着程序员一定会被替代。程序员掌舵（方向、意图、判断），智能体执行（写代码、重构、测试、合并），这种关系和协作关系相比有着微妙的区别，程序员需要站在更高的层级，或者说每个程序员都必须拥有架构师的水平， 因为程序员的工作内容发生变化，已经从拧阀门的人变成了设计调速器的人------不再是代码的生产者，而是环境的架构师、反馈回路的设计者、质量标准的编码者。

程序员的核心价值不再是"实现"，而是"评估"。

古法编程	Harness Engineering
编写代码	设计环境
调试 bug	明确意图
代码审查	构建反馈回路
编写测试	将工程判断编码成机器可读的规则
重构代码	校准传感器与执行器

06 尾巴

软件方法、领域建模、架构......这些"最佳实践"我们喊了数十年但实践的并不好，因为即使代码写的很粗放，债务依然积累的很慢，直到很久很久之后的一个时间点爆发，也许这个时间点到我们离职都不一定爆发，惰性让我找各种借口拖延，可以"先上线、后优化"。然而 AI 时代债务的累积速度是远超想象，AI 可以全天候的参考已有代码复制同样的错误，一次坏的实现会被无数次的重复，因为"你没写下来的规矩，AI 永远不知道"。

因此我们一定要将业务规则写下来，AI 的输出是不确定，但是代码可以被确定性的验证，**我们不需要比机器写得更快，但是我们一定要高效评估它的产出。**而这有一个前提，我们必须建设完善的基础设施：可以检验语法、可以安全扫描、可以单测、可以集成测试......也许你会吐槽，原来我可以上来就写代码，现在你要我建模、写规则、写工具，这不是浪费时间吗。不是，这本就是 AI 时代程序的本质工作，时代变了，我们做的事也变了。

面对 AI 浪潮，我是迷茫的，因为我并不知道最终它将会对我产生怎样的影响，我现在做的探索、尝试也许很快就过时失去价值，也许将来的某一天模型已经强到不需要那么多系统层面的约束呢？或许吧，但是也许真到了那一天，程序员也就不存了。但是我仍然乐此不疲的进行各种尝试，至少现在，我们仍然是离 AI 最近的群体。

回到导语中的那个问题：如果一个程序员为 AI 写规则文档所花费的时间比写代码还多，这对吗？

对！因为 AI 时代程序员的本职工作就是设计让 AI 正确写代码的环境，而不再是正确的写代码。蒸汽时代到来后船夫再也不需要去划桨了，不是因为他们不会，而是因为这件事已经没有任何意义了。

参考资料

《Harness engineering: leveraging Codex in an agent-first world》（https://openai.com/zh-Hans-CN/index/harness-engineering/）

《Harness Engineering Is Cybernetics》（https://x.com/odysseus0z/status/2030416758138634583）

《控制论和科学方法论》- 金观涛 / 华国凡

-End-

原创作者｜邬俊杰

AI 应用落地中 Harness 体系与底层模型的价值对比

在人工智能应用落地阶段，Harness 体系的工程价值高于底层大模型已成为行业普遍认知。本文从概念界定、实测数据、内在逻辑、行业实践及技术路线等维度展开分析。

一、概念界定

引擎：即底层大语言模型，其评价维度包含算力配置、参数量、推理能力、上下文窗口长度及基准测试得分，可类比为汽车发动机、计算机中央处理器。
壳（Harness）：即模型驾驭系统，涵盖上下文管理、信息记忆、任务拆解、多智能体协同、工具调用、结果反馈验证、架构约束、权限隔离、异常修复及持续运行管控，可类比为汽车底盘、传动系统、制动系统、转向系统及安全控制系统。

底层模型决定任务执行的可行性，Harness 体系决定任务执行效果、运行稳定性及规模化落地能力。

二、实测数据

多项研究及实测结果显示，固定底层模型参数，仅优化 Harness 体系可显著提升系统性能。

Nate B Jones 相关研究：相同模型、数据集与提示词配置下，编程任务基准成功率由 42%提升至 78%。
LangChain Terminal Bench 2.0 测试：指定模型测试成绩由 52.8%提升至 66.5%，行业排名由 30 名以外进入前 5 位。
Pi Research 实测：单一调整周期内，Harness 体系优化可同步提升 15 类大语言模型的编程任务执行能力。
Vercel 实测数据：工具调用数量由 15 项精简至 2 项，系统准确率由 80%提升至 100%。
Claude Opus 4.6 测试：相同模型与应用场景下，Harness 体系调整使模型排名由 33 位提升至 5 位。

上述数据表明，Harness 体系优化带来的性能提升，等效于模型代际升级的效果。

三、内在逻辑

底层模型性能进入边际效益递减阶段。2024 至 2026 年，大模型在推理、编程、数学运算、逻辑判断及工具调用等维度的能力已满足常规应用需求，基准测试分数提升对实际应用体验的影响有限。
智能体执行失效多由系统架构问题导致，具体表现为上下文丢失、重复执行、目标偏离、结果缺乏校验、多智能体运行冲突、资源竞争、执行空转、运行环境紊乱、权限管控缺失及输出内容失真等，此类问题与底层模型能力无直接关联。
底层模型存在固有缺陷，包括输出失真、上下文容量受限、信息易受干扰、缺乏自我校验机制、任务闭环修复能力不足，长时任务执行易出现逻辑漂移。Harness 体系通过系统约束机制，弥补底层模型运行的不稳定性。
人工智能应用规模化的核心指标为长时稳定运行、自动化测试与修复、自动化验收、大规模代码无人工干预执行及多智能体高效协同，上述指标均依托 Harness 体系实现，与底层模型无直接关联。

四、行业实践

OpenAI 工程实践：5 个月内完成 100 万行代码生成，无人工手写代码，团队工作集中于 Harness 体系搭建，包括架构约束、层级划分、代码检测、持续集成、反馈闭环、运行可观测性及自动验证机制。
Stripe 系统应用：基于 Blueprint 系统实现确定性流程与智能体决策分离，通过持续集成机制限制执行轮次，精简工具调用子集，实现每周 1300 次代码合并请求的无人值守执行。
Cursor 系统运行：构建多智能体协同架构，通过运行隔离、任务调度、状态机管理及权限管控，解决并发冲突、资源锁定、执行空转及逻辑漂移问题，实现高频次代码提交与工具调用。
ONES AI²系统：依托标准化流程实现需求解析、多智能体分工、开发执行、测试、验收及修复全流程自动化，系统效能依赖流程设计而非模型性能。

五、技术路线分歧

大模型优先路线：该观点认为模型性能持续提升将替代 Harness 体系，核心逻辑为算力与规模扩张可覆盖工程化设计需求。
Harness 优先路线：该观点认为底层模型为执行核心，Harness 体系为运行管控核心，模型自主能力越强，对约束体系的要求越高，架构设计、反馈机制及运行管控具备长期存在价值。

实际技术演进中，模型性能提升伴随 Harness 体系轻量化迭代，该体系不会消失，仅向简化化、模块化方向发展。

六、总结

底层模型划定人工智能应用的性能上限，Harness 体系设定应用运行下限及规模化落地标准。无底层模型则系统无法执行任务，无完善 Harness 体系则系统无法实现高效、稳定、规模化运行。在人工智能工业化、规模化、产品化进程中，Harness 体系的价值高于底层模型。

七、应用启示

模型选型与微调对系统整体效果的影响，低于 Harness 体系优化的影响。
资源配置应向 Harness 体系建设倾斜，涵盖上下文管理、信息记忆、任务拆解、协同机制、结果验证、异常修复及运行约束等维度。
技术人员工作重心由代码编写转向运行环境设计、规则制定、反馈体系搭建及控制系统开发，人工智能管理相关人才需求将持续提升。

reference

Harness Engineering 在硅谷彻底火了。
https://mp.weixin.qq.com/s/S2x7pJ2RqLk9tQdqxpzQNQ
模型不是关键，Harness 才是
https://mp.weixin.qq.com/s/sVGeofV9uTgvhgR44q8pNA
一文读懂 Harness Engineering：从 14 篇工程文章中，寻找那个让 AI 不再离经叛道的壳｜Hao 好聊趋势
https://mp.weixin.qq.com/s/DE0hc3Mz6zwoSCgL0k4SgQ
一文带你看懂，火爆全网的 Harness Engineering 到底是个啥。
https://mp.weixin.qq.com/s/yI1rQHVwJqszdpadzAe_4A
- 分享6个平时我最常用的Prompt心法。
  https://mp.weixin.qq.com/s/a_-EMSjN0ldsrKCIk6nxuQ
- 能用脚本就别用 Agent。
  https://mp.weixin.qq.com/s/GAZ45bXuSyk793JbnTg__g
一文带你弄懂 AI 圈爆火的新概念：Harness Engineering
https://mp.weixin.qq.com/s/oIeA85eT40AM7mrw_XJF4Q
一文讲透：Harness Engineering 即控制论！
https://mp.weixin.qq.com/s/_Yn-PRW2kmoOusUbTbi3vQ

AI 工程演进 | Prompt、Context 与 Harness

Harness Engineering 在硅谷彻底火了。

01 到底什么是 Harness Engineering？

02 一个具体的实例

03 写在最后

模型不是关键，Harness 才是

三层进化

第五阶段

百万行代码，零行手写

仓库就是大脑

给 Agent 写的代码

自主性分级

合并哲学

像操作系统

三根支柱

上下文工程

架构约束

熵管理

行业共识

Stripe：每周 1300 个 PR

Cursor：每小时 1000 个 commit

Peter Steinberger：一个人的军队

壳比模型值钱

拐杖论

路线之争

Big Model 阵营

Big Harness 阵营

护栏悖论

七个杠杆

往远了看

这，不就是管理吗

一文读懂 Harness Engineering：从 14 篇工程文章中，寻找那个让 AI 不再离经叛道的壳｜Hao 好聊趋势

01 Harness 第一层：从记事本到管理制度

02 Harness 第二层：终结无政府状态，走向并发与效率

03 Harness 第三层：戳破盲目自信

04 做加法之后学会做减法

05 Claude Code 源码泄漏，带来的一次意外对账

06 正在发生的「补偿面迁移」

推荐阅读与溯源

一文带你看懂，火爆全网的 Harness Engineering 到底是个啥。

一文带你弄懂 AI 圈爆火的新概念：Harness Engineering

先说人话：Harness Engineering 到底是什么

为什么是现在：从"拼模型"到"拼系统"

第一阶段：Prompt Engineering（2019-2022）

第二阶段：Context Engineering（2022-2024）

第三阶段：Harness Engineering（2024-现在）

三代 AI 工程：一张图讲清楚

为什么是现在才爆发

Claude Code 源码泄漏：一个意外的宝藏

Claude Code 的四层架构详解

记忆系统：一个被低估的设计

为什么说 Harness 是未来五年的主战场

Harness Engineering 的六个关键原则

写给一线开发者的建议

最后

一文讲透：Harness Engineering 即控制论！

01 前言

## 02 Harness Engineering

## 03 控制论

## 04 Harness Engineering 和控制论

## 05 对我的影响

06 尾巴

参考资料

AI 应用落地中 Harness 体系与底层模型的价值对比

一、概念界定

二、实测数据

三、内在逻辑

四、行业实践

五、技术路线分歧

六、总结

七、应用启示

reference