Harness 完全指南：六层框架、三个案例、一场争论

如果你在2024年问一个工程师：harness是什么？多数人会一脸茫然。到了2026年，这个词突然变成AI圈最热的概念之一。

Harness在英文里大体可以理解为「驾驭」或「约束框架」。软件工程里早就有test harness（测试框架），但harness本身一直不是行业核心词。它突然爆火，是因为大家集体在问同一个问题——

模型之外，究竟要搭一套什么样的系统，才能让AI稳定地干活？

但就在前几天，Anthropic Claude Code负责人Boris Cherny抛出了一句话：「Harness will disappear.」（harness会消失。）

那为什么还要写这篇文章？因为Cherny这句话有上下文（后面会拆解），而我的判断是：harness将是一切工作的核心。

这篇文章会先把harness是什么、内部分哪六层讲清楚，再回到Cherny那句话——看他说的「消失」到底指什么。

过去几年，AI工程大概经历了三次重心变化。

第一阶段是prompt engineering（提示词工程）。

那时的核心问题是：模型能不能听懂我？所以大家研究提示词模板、角色设定、few-shot（给几个例子让模型照着学）示例，研究怎么把话说得更清楚。

第二阶段是context engineering（上下文工程）。

模型能力上来以后，问题开始变成：他不是不聪明，而是不知道。他不知道你的代码库结构，不知道你的业务规则，不知道上周讨论过什么，不知道这个接口为什么不能改。于是大家开始做RAG（检索增强）、记忆、文档检索、上下文压缩、MCP（模型上下文协议）。

第三阶段是harness engineering（harness工程）。

这时，问题又变了。

AI不只是「知道什么」，也不只是「回答什么」。他开始行动。他会改文件，会运行命令，会查数据库，会连内部工具，会发起PR，会在一个任务里连续调用几十次工具。

一旦AI开始行动，你面对的就不再是一个聊天框，而是一个带有不确定性的执行系统。

这就是为什么harness现在变重要。

Harness这个词本身也很有意思。

它最早在英语里和盔甲有关，后来变成马具，再后来发展出「驾驭某种力量为我所用」的意思。人类先是试图控制战场上的危险，后来控制马，再后来控制水力、蒸汽、电力。每一次都是同一种动作：

遇到一种比自己更强、更快、更不可预测的力量，然后想办法把它变成可用的生产力。

现在轮到AI。

所以harness这个词流行起来，不是偶然。它暴露了AI工程师面对新一代智能体时的真实心理：

这东西太能干了。我得想办法让他在正确的轨道里能干。

不是因为大家突然喜欢一个新词。而是因为模型已经强到值得给他建围栏了。

早期模型的主要问题是跑不远、跑不稳。你还没来得及担心马失控，马已经自己卡住了。但当模型能连续跑半小时、几个小时，甚至跨多个上下文窗口接力完成任务时——他能创造的价值变大了，能犯的错误也变多了。

这时，真正的问题不再是「让他更聪明」。而是：

这些问题加在一起，就是harness engineering。

先给一个定义：

这个定义看起来有点长，但它可以把三个概念干净地区分开：

有人把这件事概括成一个非常简单的公式：

模型是大脑。Harness是大脑之外的一切。

这个加号不是装饰。LangChain做过一个直观的实验：同一个模型不变，只调整模型外面的运行环境，他们的编码智能体在Terminal Bench 2.0上的得分从52.8跳到66.5。13分的差距，完全来自harness那一项。

同一个模型，放在不同harness里，可以是两个不同的智能体。

但「一切」这个词太大了。真要落到工程上，可以拆成六层。

后面这六层是这篇文章的脊柱。你可以把它当成一张地图——后面无论讨论什么，都会回到这六层来定位。

指令层是最容易理解的一层。它包括系统提示词、项目规则文件、AGENTS.md、CLAUDE.md、skills，以及各种任务说明。

很多人第一次配置AI编程工具时，最容易犯的错就是写一份很长的规则文件。什么代码风格、目录结构、命名偏好、项目背景、部署方式、数据库约束，全都塞进去。看起来很完整。但实际效果往往不好。

因为模型的注意力不是无限的。规则太多，真正重要的规则反而会被淹没。

Hashimoto在自己的Ghostty项目（他用Zig写的开源终端模拟器）里维护AGENTS.md，他的做法很值得学：每一条规则都对应一次智能体真实犯过的错。

它不是一份「最佳实践大全」，更像一份踩坑记录。智能体用错了命令，加一条。跳过了必须跑的检查，加一条。误解了项目结构，加一条。每条规则都有来历。

OpenAI的百万行代码实验也经历过类似过程。他们一开始也想把很多规则都塞进AGENTS.md。后来发现不行，于是把它压到一百行左右，让它更像一张地图：告诉智能体应该去哪里查设计文档、架构说明和执行计划。

这里有一个值得留意的对比。我仔细看过OpenAI和Anthropic两家的指令风格，二者的取向其实不太一样。OpenAI更多在告诉AI「应该做什么」，Anthropic更多在告诉AI「不能做什么」。

我个人更赞同Anthropic这条路。原因很简单——人对自己需要什么往往说不清，对自己不接受什么倒是清楚得多。把「红线」讲明白，剩下的留给模型发挥，既给了空间，也守住了底线。可能这也是为什么不少人觉得Claude比ChatGPT「更有人味」——不一定是模型本身的差异，而是规则风格让模型保留了更多发挥空间。

手册太厚，他会忘。地图清楚，他知道该去哪里找。

指令层相对静态。上下文层是动态的。

每一次模型调用之前，系统都要决定：这次应该把哪些信息放进上下文窗口？

这听起来像「塞信息」。但真正难的不是塞更多信息，而是塞更干净的信息。

信息太少，AI不知道情况。信息太多，AI被噪音淹没。

Anthropic在研究长任务智能体时发现，单纯压缩对话历史并不够。一个任务如果要跨很多个上下文窗口继续执行，下一个会话不能只拿到一团被压缩过的聊天摘要。它需要的是结构化的工作状态：当前完成到哪里，接下来要做什么，哪些问题已解决，哪些决策不能改。

所以他们引入了类似 claude-progress.txt 这样的进度文件，让新会话像接班的工程师一样，先读交接记录，再继续做事。这比「把前面所有对话压缩一下」更可靠。

子智能体（sub-agent）也可以从这个角度理解。

很多人以为子智能体的价值是分工：一个前端，一个后端，一个测试。但更重要的价值其实是隔离噪音。

搜索资料、读日志、翻文档、查历史讨论，这些过程会产生大量中间信息。如果全部塞回主对话，主智能体反而会变笨。更好的做法是：让子智能体完成这些嘈杂任务，只把干净摘要交回来。

所以上下文层有两句对称的话——不在上下文里的东西，对AI来说就不存在；不该进上下文的噪音，也会让AI做错判断。

上下文是AI能看见什么。工具是AI能做什么。

工具层包括文件读写、命令行、Git、浏览器、数据库、内部API、MCP服务器等。

直觉上，很多人会觉得工具越多越好。但实际不是。工具越多，系统提示越长，选择空间越大，智能体越容易分心。

一个智能体接了十几个MCP服务器，看起来能力很强，但每个工具的描述都要进入上下文。很多工具根本用不上，却持续消耗注意力。

Stripe的做法很典型。他们有一个集中式工具系统，覆盖很多内部工具。但不是每个智能体都加载全部工具，而是根据任务给他一组相关工具。

这才是关键。智能体需要的不是「以防万一」的全家桶，而是和任务精确匹配的一组工具。工具不是越多越好，而是越清楚越好。

一个好工具要有明确边界、明确输入、明确输出。最糟糕的是「超级工具」：什么都能做，参数复杂，结果含糊。人类可以凭经验猜。AI很容易在这里跑偏。

工具层定义AI能调用什么。边界层定义他在什么条件下能调用。

这一层包括权限、沙盒、网络隔离、文件系统隔离、密钥管理、审批规则。

Claude Code的权限系统就有类似三档：允许、询问、拒绝。其中最重要的是拒绝优先。只要命中拒绝规则，就直接停下，不会被其他允许规则覆盖。这是一种「故障即安全」的设计。

Stripe Minions的边界更偏基础设施：每个智能体跑在独立开发环境里，只能访问测试或QA环境，不能碰生产服务和真实用户数据。

这件事的意义不是「限制AI」。恰恰相反。

边界设计得越清楚，人类越敢把更多事情交给AI。

没有边界，你永远不敢给他真正有用的权限。有边界，你可以放心让他在安全范围内充分行动。

人类写完代码，可以自己运行、观察、判断。AI不一样。他对现实的感知，主要来自反馈系统。

测试、类型检查、linter（代码风格检查）、CI、运行日志、代码review、另一个模型的评估，都是反馈层。

OpenAI在百万行代码实验里有一个很具体的发现：错误消息应该写得像给智能体看的修复提示。

不要只说「类型不匹配」。要说「这里应该用 string[]，不是 string」。

这看起来是一个很小的改变，但意义很大。错误消息从「报错」变成了「教学」。AI看见错误，不只是知道失败了，还知道该往哪个方向修。

这也解释了为什么传统软件工程里的很多好习惯，在AI时代突然价值翻倍。

强类型语言、严格linter、完善测试、稳定CI，过去是给人类工程师的质量保障。现在，它们变成了AI能感受到的现实。

没有反馈，AI只能猜。有反馈，他才能修正。

这一层后面我们还会再回来。因为它正好是「harness是否会消失」这个争论里，最难被消化掉的部分。

前五层让AI能干活。治理层决定AI怎么被管理。

它包括成本监控、运行日志、审计记录、人工升级、失败复盘、组织级模板、回归评估。

这一层最容易被忽略。因为个人开发时，你可能觉得跑一次多花几美元无所谓。但到了组织级，智能体可能并行跑几十个、几百个任务。一个失败循环如果不被及时终止，可能烧掉很多钱，也可能产生大量错误改动。

所以成熟系统一定要回答几个问题：

这就是治理层。

它说明harness不是一个人的prompt文件。它会慢慢变成组织资产。一个团队积累出的规则、工具、测试、流程、权限和模板，应该能被下一个团队继承，而不是每个人从头开始摸索。

如果只看六层会有点散。真正把它们串起来的，是一个非常古老的工程动作——

前半是「行动前的引导」：AGENTS.md规则、目录结构、类型系统、权限设置——这些告诉AI该往哪走。后半是「行动后的检查」：测试、CI、linter、运行日志、代码review——这些告诉AI刚才那步有没有偏。两类必须组合。只有引导没有检查，规则写了也不知道有没有用；只有检查没有引导，AI反复犯同样的错。

还有一条原则：能用代码强制的，就不要写成「请记得」。 Hook会执行，自然语言会被忘。这条原则后面会反复出现——它解释了为什么AI时代的工程不会消解，反而会更工程化：你能用确定性骨架兜住的地方越多，留给模型自由发挥的空间就越精准。

这其实就是1948年维纳提出的控制论的核心——前馈给方向，反馈看偏差。AI没有让「控制」这件事过时，只是把它的对象从机器换成了一个比机器更不确定、行动空间更大的系统。所以harness才会从一句prompt，扩展成六层。

理解了harness是什么，还要再往前看一步。

如果harness变成AI工程的核心工作，工程师这个角色会发生什么变化？

我觉得至少有三个转移。

OpenAI那个百万行代码实验，是最极端的样本。三位工程师从空仓库开始，让Codex生成代码、测试、CI、文档和内部工具，人类不直接写代码。

他们做的是：

这不是传统意义上的写代码的人。更像平台工程师、架构师、产品经理、质量工程师的混合体。

我自己的体感也非常明显。

以前我做一个新功能，想的是这个功能是什么样子，应该用什么方法，什么技术栈，实现的顺序。现在我更常做的是反着走——先把问题本身想清楚：要解决什么、有哪些边界条件、需要哪些工具、什么算「做完」。然后让AI去拆步骤、写实现、跑检查。注意力从「每一行怎么写」，换成了「方向对不对、边界清不清、反馈够不够」。

换句话说，我大量时间在做的事，不是写代码，而是给AI建一个能稳定干活的环境。

这就是第一个转移：

Hashimoto对harness engineering的定义非常直接：

这句话看起来像经验建议。但它背后是一种工作方式的变化。

传统调试是：发现bug，定位原因，修掉这一次。

Harness engineering是：发现bug，修掉这一次，然后继续追问——为什么AI会犯这一类错？

答案可能是一条规则。可能是一个测试。可能是一个hook。可能是一个更清楚的工具描述。可能是一个更短的上下文。也可能是一个必须交给人的升级规则。

这和软件工程里写测试防止回归，是同一个逻辑。

以前你给代码写测试。现在你给AI建围栏。

每一次失败，都应该让系统变得更稳一点。

Stripe Minions的故事最容易被误读。

很多人看到的是：AI每周能写超过1000个PR。但真正重要的是：Stripe已经有一套很强的工程基础设施。

标准化开发环境、内部工具系统、CI、测试、代码review文化——这些都不是为AI临时搭的。它们原本是给人类工程师用的。

智能体只是接入了这套基础设施。

这说明一件事：

这句话特别重要。

如果一个团队没有测试，没有清楚文档，没有稳定CI，没有标准化环境，没有内部工具接口——买再多AI账号，也很难跑出Stripe那种效果。

模型这一层会越来越普及。但模型外面的工程基础设施，短时间内不会自动普及。

这会让组织之间的差距变大。这就是为什么我说，harness的含金量还在上升。

一个工程化成熟的团队，AI会放大它的能力。

一个工程化混乱的团队，AI也会放大它的混乱。

那这套系统在真实场景里长什么样？下面看几个具体案例。

下面看几个真实案例。我不会把它们写成「资料汇编」。每个案例只回答一个问题。

Anthropic专门研究过长任务智能体。他们关心的是：如果让一个智能体连续工作几个小时，甚至跨多个上下文窗口继续工作，他怎么保持进度？

一开始，他们发现两个常见失败模式。

第一，AI想一口气做完所有事。结果写到一半，上下文快满了，留下半成品。

第二，新会话接手时，不知道前面发生过什么，只能猜。

Anthropic的方案不是简单换更大窗口。他们设计了一个更像「换班交接」的harness。

先由一个初始化智能体把任务拆清楚，写出需求、任务列表和进度文件。后面的编码智能体每次只推进一小部分，并且留下清楚的交接记录。新会话不是读一大段压缩聊天记录，而是读结构化的进度文件。

这个设计很像人类工程师接手项目：先看README，读任务列表，看git历史，再继续干。

需要。

Anthropic的Research（深度研究）功能就是一个非编码场景。他要做的是深度研究：拆问题、查资料、比较来源、生成带引用的报告。

这不是写代码。但他遇到的问题和编码智能体很像。单个上下文窗口装不下太多搜索过程。

所以Anthropic用一个主智能体来拆解问题，再创建多个子智能体并行搜索。每个子智能体都有明确目标、输出格式、工具范围和任务边界。他们独立探索，然后把结果压缩成摘要交回主智能体。

主智能体拿到的是干净摘要，而不是一大堆原始网页和中间过程。

这再次说明：

凡是任务复杂度超过单个上下文窗口能稳定承载的场景，都开始需要类似harness的设计。

研究、客服、数据分析、运维、交易——不只是写代码。

Stripe Minions的关键，不是让AI自由发挥。恰恰相反，这套系统把自由度放在少数真正需要推理的节点上。

一个典型流程是：智能体写代码。确定性脚本跑检查。失败了，智能体修。再跑测试。还失败，就交给人。

这里最重要的不是「智能体很聪明」，而是流程被拆成了两类节点：

这就是企业级harness的关键：

这也是为什么测试、CI、权限和沙盒如此重要。没有这些确定性骨架，智能体的自由行动很快会变成自由失控。

把三个案例放在一起看，它们解决的问题不同——长任务、研究、企业流程——但它们做的是同一件事：

这就是harness engineering。

读到这里，应该有读者想问一个问题——

如果模型越来越强，这套「可控、可观测、可复盘的系统」是不是会越来越不需要？

类似的疑问其实出现过一次。两年前「prompt engineer」（提示词工程师）还是个大热概念，被当成独立职业，公开招聘、年薪百万的报道满天飞。今天它几乎不再作为单独岗位存在——并不是写提示词没用，而是模型本身变强之后，那些大段结构化的提示词技巧不再必要，「怎么哄模型听懂」这件事的难度，被模型本身吃掉了大半。

那harness会不会也是同一条路？模型再强一些，它是不是也会被消化掉？

恰好，这正是2026年5月AI圈最热的一场争论。

如果你最近刷过技术圈的内容，大概率看到过这么一句话——

「Harness will disappear.」（harness会消失）

说这话的人不是别人，是Anthropic的Claude Code负责人Boris Cherny——可能没有几个人比他更懂harness。说这话的场合也不是普通采访，而是2026年5月的Sequoia AI Ascent大会。

这个发言被中英文圈广泛转载。腾讯新闻的标题是「编程已经结束、harness将消失」。

如果你只读这个标题，你会觉得harness可能要消失了。但深入去看Cherny真正表达的内容，你会发现——这是harness的胜利，而不是harness的终结。

Cherny在Sequoia现场抛出的不止「harness will disappear」一条。他铺开了一整组同样激进的判断，下面逐条拆开看。

「Coding is solved.」（编程问题已经解决了） 这是被截图最多的一句。但他原话有一个关键限定——对他个人写的代码100%，对整个工程行业大约50%；且仅在TypeScript、React等模型熟悉的技术栈成立。冷门语言、复杂老代码库，他给的答案是「wait for the next model」（等下一代模型）。这条限定语在二手报道里经常被砍掉，但它是理解整个论断的关键。

「Harness will disappear.」 模型变强后，提示词注入防御、静态命令校验、人工介入审批（human-in-the-loop）这些「为弥补模型缺陷而存在的壳」，会被模型本身的推理消化掉。

「一年后Claude Code可能只剩100行代码。」 产品层会被模型内化吃掉。配套的判断是「Loop就是未来」——用 /loop 加cron（定时任务）让智能体自主跑：自动修CI、做rebase、维护间歇失败的测试（flaky test）、定时从社交媒体抓反馈做聚类。一次维持5到10个会话，每个会话下几十个子智能体，加起来「几百个」白天跑，过夜跑「几千个」。

印刷术类比。 1400年代欧洲识字率约10%，抄写员（scribe）替不识字的精英读写；印刷术让书的成本降到原来的百分之一，50年内欧洲出版的书超过了过去整个千年。Cherny由此推断：「最好的会计软件作者不会是工程师，是懂业务的会计师。」

这是一个很强的判断组合——有宣判式论断（coding is solved）、有产品判断（100行Claude Code）、有历史类比（印刷术）。而且发言人是Claude Code的亲爹。

这就是最关键的拆解。

回到Cherny原话的语境，他举的「消失」的例子非常具体——

这些都有一个共同点：它们是为弥补模型当下能力不足而存在的「壳」。

提示词注入防御之所以要硬编码，是因为模型分不清楚什么是可信指令、什么是注入指令。静态命令校验之所以存在，是因为模型不一定能判断哪个命令在当前环境下安全。简单的人工介入审批之所以存在，是因为模型在低风险动作上也会犯人类一眼能看出的错。

模型变强，这些「壳」确实可能被吸收。

但harness不只是这些壳。

回到前面的六层框架，可以把Cherny说的「消失」映射得很精确——

这张表读完，Cherny的论断和这篇文章的框架不再冲突——它们在讲不同的层。

可以用一句话总结：

或者换个说法：

它意味着harness把「弥补模型缺陷」那部分工作完成了，所以这部分可以收起来。而harness真正持久的价值——为非确定性系统设计反馈、治理、上下文、合规——会上移，不会消失。

Cherny个人30天259个PR的数据非常有说服力。但放到更大样本里，AI编程的整体效果是另一幅图景。

Google Chrome团队的Addy Osmani在《The 80% Problem in Agentic Coding》里给出最锋利的反驳——高AI渗透团队PR合并量翻了98%，但review时间膨胀了91%。他造了个词叫comprehension debt（理解债）：AI写完一个功能、测试都过、人扫一眼合并，三天后自己都解释不清那段代码怎么工作。Osmani的结论一句话——摩擦没有消失，只是搬家了：从写代码搬到了review和verify。

另一边AI评测机构METR在2025年7月做过一个实验，资深开发者自以为用AI后快了20%，实测慢了19%——感知和现实差39个百分点。HN上的反应也类似：有人挨个给Cherny那句话加限定括号，还有人直接问——既然编程已经解决了，Anthropic为什么还在大规模招工程师？

这些声音不构成「AI没用」。但它们指向同一个判断——AI把代码生成的速度推到了新水平，但代码生成的速度，并不是软件工程真正的瓶颈。理解、验证、维护、协作、责任——这些才是，而这些恰好是harness反馈层、治理层、上下文层负责的部分。模型越快，这几层不是越不重要，而是越重要。

如果你觉得这场争论似曾相识，那是因为它在制造业里演过一遍。

1980年代，美国汽车业被日本丰田打得很狼狈。面对竞争，通用汽车做出的判断是——自动化更多。

通用在1980到1990年代投入了数百亿美元追求高度自动化，「灯灭工厂」（lights-out factory）是当时最激进的愿景——理想状态是机器人替代工人，连灯都不用开。

同期丰田在做相反方向的事：增加机器没错，但更大量地训练工人在系统里识别异常、做「安灯停线」（andon cord，在异常时拉绳子停整条产线）、做根因分析。 andon cord是丰田的招牌制度——任何工人发现异常，都可以拉绳子打断整条自动化产线。流程被设计成「任何人都有权打断自动化」。

20年后回看，丰田全胜，通用差点破产。

不是因为通用的机器人不够好，而是在完全自动化的复杂系统里，最稀缺的不是「执行」，是「在异常状态下做出正确判断」。

这恰好对应了Cherny和Osmani的争论——

Cherny说：「the model will just do the right thing.」（模型自己会把正确的事做对。）这是1985年通用的逻辑：相信自动化能解决一切。

Osmani说：review时间膨胀91%，因为模型生成代码后，辨识异常、停线、做根因分析的人类负载反而上升了。这是1985年丰田的逻辑：自动化越多，「在异常状态下做正确判断」越值钱。

谁会赢？历史已经给过一次答案。

这不是说Cherny错了。他个人30天259个PR是真的，Claude Code团队大量编码工作交给智能体也是真的。但这些样本有一个共同特征：他们在一个反馈层极其完善、治理层极其成熟的环境里跑。Anthropic内部的CI、测试、代码review文化、工具基础设施，都不是为AI临时搭的——它们是给世界一流的人类工程师准备的。

智能体只是接入了这套基础设施。

换句话说，Cherny不是证明了harness会消失。他证明的是：当harness的反馈层和治理层足够强时，模型可以发挥出惊人的产能。

这恰好是这篇文章的论点。

把上面所有东西收拢一下。

Cherny说「harness will disappear」——他指的是补丁层。模型变强会吃掉一部分今天为弥补模型能力不足而存在的工程结构。

Osmani说「the shift relocated friction」——他指的是基础层。代码生成不是软件工程的瓶颈，理解、验证、维护、协作才是。这些是harness反馈层、治理层、上下文层负责的事。模型越快，这几层越重要。

这两个判断不冲突。它们描述了同一件事的不同侧面——

如果你回头看这篇文章的六层框架，会发现这个判断有个直接推论——

未来真正值钱的harness投资，不是写更长的AGENTS.md（那是补丁层，可能会被模型吸收），而是把反馈层、治理层、上下文层做成组织的基础设施。

测试是不是健全？CI跑得稳不稳？代码review文化在不在？错误消息写得是不是机器友好？任务状态有没有结构化？跨会话接力有没有标准协议？成本和审计有没有系统？

这些问题2024年问，是软件工程的卫生标准。
2026年问，是AI时代的护城河。

模型这一层会越来越普及。但模型外面的工程基础设施，不会自动普及。

Cherny自己也承认了这点。他公开的工作流里写——CLAUDE.md大约100行（行业平均500到1000）；每次Claude做错事，就往里加一条；这个文件提交进git，团队共享。

这哪是harness在消失？这是harness在最讲究的人手里运行良好的样子。

补丁层薄了。基础层在。

讨论清楚了「消失论」，我们就可以放心进入下一节——

你自己怎么搭这套harness？

讲了这么多，最后要落到自己怎么做。

你不需要一上来就学Stripe，也不需要先搭一个组织级平台。对大多数个人开发者和小团队来说，最重要的是先搭一个最小harness。

这也是我看Learn Harness Engineering这个项目后，觉得最值得吸收的一点。它没有把harness讲成一个很玄的概念，而是落到几个非常具体的东西：规则文件、启动脚本、功能状态表、进度日志、验证流程和会话收尾。

换句话说，harness不是「写一个更好的提示词」，也不只是「放一个CLAUDE.md」。它是一套让AI每次开工、执行、验证、收尾都更稳定的工作流程。

很多人配置AI编程工具，第一反应是写一份CLAUDE.md或AGENTS.md。这当然有用，但它只是入口，不是完整的harness。

一个更实用的最小组合，至少应该有四样东西：

这四个文件各管一件事。

AGENTS.md / CLAUDE.md 管规则。它告诉AI这个项目是什么、用什么技术栈、哪些命令必须跑、哪些地方不能碰、什么算完成。它最好短一点，像地图，不像百科全书。

init.sh 管开工前的环境检查。每次AI开始工作前，先跑一遍初始化脚本：安装依赖、检查环境、跑基础验证、确认项目能启动。这样可以避免他在一个坏掉的环境里继续瞎改。

feature_list.json 管任务状态。它不是给人看的待办清单，而是给AI看的状态机：哪些功能没开始，哪些正在做，哪些被阻塞，哪些已经验证通过。AI每次只应该选一个未完成任务，不要同时开三个坑。

progress.md 管跨会话记忆。它记录上一轮到底做了什么、哪些检查通过了、哪里还没验证、下一轮应该从哪里继续。这样下一次会话不用靠压缩聊天记录接力，而是读一个干净的交接文档。

这四样东西合在一起，才是一个真正的最小智能体工作环境。

单独一个规则文件，解决的是「怎么提醒AI」。
四件套解决的是「怎么让AI每次都按同一套流程工作」。

规则文件不要一上来写成200行。我更建议控制在50到80行以内。

最重要的不是写全，而是写准。

一条规则最好对应一次真实失败。如果没有真实失败，就先别写。

值得提一个对比——Cherny公开过自己的工作流，他的CLAUDE.md大约100行，行业平均是500到1000行。他的原则也是「每次Claude做错一件事，就往里加一条」。

一个最小模板可以长这样：

这份文件不是一劳永逸的。

每次AI犯了可复现的错，你就想：这是写一条规则，写一个测试，还是写一个脚本？

如果只是偶发失误，不一定要进规则文件。如果他反复犯，就应该沉淀成harness的一部分。

很多人会给AI一个待办清单：做A，做B，做C。

问题是，待办清单对AI来说太松了。他不知道哪个任务正在做，不知道什么叫完成，也不知道哪些东西只是「写了代码」但还没验证。

所以更好的方式是做一份机器可读的功能状态表。比如：

状态可以很简单：not_started、in_progress、blocked、passing。

真正重要的是两条纪律。

第一，同一时间最好只有一个任务处于 in_progress。

AI很容易高估自己，一边做A，一边顺手改B，再顺手重构C，最后三个都半成品。功能状态表的作用，就是把他的行动范围收窄。

第二，没有验证证据，不要把状态改成 passing。

代码写完不是完成。测试通过、构建通过、关键路径检查过，才是完成。

evidence 字段可以记录跑过哪些命令、结果是什么、还有哪些边界没覆盖。这样下一个会话接手时，不需要猜。

对AI来说，功能清单不是备忘录。它是任务调度表、完成判定表和交接记录的共同源头。

最小harness的核心，不只是几份文件，而是一个固定的会话生命周期。

每一轮AI工作，都应该大致走四步：开始、选择、执行、收尾。

开始阶段，先读规则文件，跑 init.sh，看 progress.md，读 feature_list.json，再看最近的git记录。他要先知道项目现在是否健康、上一轮做了什么、当前还有哪些任务。

选择阶段，只选一个未完成任务。不要让AI自己发散成「顺便把相关模块都重构一下」。如果任务太大，先拆小，再开始写。

执行阶段，写代码、跑验证、失败就修。这里的关键不是让AI「感觉差不多了」，而是让他必须跑明确的命令：typecheck、lint、test、build，至少要有一套最小验证。

收尾阶段，更新进度日志，更新功能状态表，记录哪些检查通过了，哪些风险还没处理，哪些地方需要人类判断。只有在项目处于可恢复状态时，才提交或交给下一轮。

这个流程看起来有点笨，但它解决了AI编程最常见的几个问题：开局不知道项目状态，中途做太多，结尾提前宣布完成，下一轮接不上。

一个稳定的harness，就是用固定流程把这些不确定性压下去。

init.sh 可以很简单，不需要一开始就做得很复杂。

它的目标是让AI开工前先确认：这个项目能启动、依赖是好的、基本检查能跑。

比如：

真实项目里，你可能会把它拆得更细：本地开发用一套，CI用一套，快速检查用一套。但一开始不需要复杂。

关键是让AI知道：每次开工前先跑入口脚本，不要在一个已经坏掉的项目上继续叠bug。

如果项目检查太慢，也可以准备两个命令：一个快速检查，一个完整检查。快速检查用于中途迭代，完整检查用于收尾。这样既不浪费时间，也不让AI完全没有反馈。

很多AI协作失败，不是失败在开头，而是失败在结尾。

上一轮AI改了一半，说「完成了」。下一轮打开项目时，发现测试没跑、文档没更新、功能状态没改、还有几个临时文件。于是他先花半天猜前面发生了什么。

所以每次会话结束前，应该有一个简单的干净收尾检查：

这件事很重要。

你不是只要求AI完成任务，还要要求他留下一个下一轮能接手的现场。

对长任务来说，干净收尾本身就是harness的一部分。

MCP很诱人。数据库、浏览器、Slack、GitHub、Notion、Jira，什么都能接。但个人项目里，不要一开始就接一堆。

只接确定有用的。不用的就关掉。

每个工具都会增加选择空间，也会增加安全风险。如果一个工具可以用简单命令行解决，未必需要完整MCP。

重试也一样。

很多人用AI会陷入一个坑：让他一直修。第一次修不对，再修。第二次还不对，再修。然后越改越乱。

所以要设上限。比如：同一个测试失败，最多自动修两次。两次还不行，停下来总结问题，交给人判断。

这不是不信任AI。这是治理。

最简单的验证方法，是拿同一个小功能做两轮。

第一轮，只给普通prompt。告诉AI要做什么，不给规则文件、不跑初始化、不准备功能状态表。记录他花了多久、漏了什么、有没有提前宣布完成、最后你花了多少时间收拾。

第二轮，给他最小四件套：AGENTS.md / CLAUDE.md、init.sh、feature_list.json、progress.md。让他按固定会话流程工作。

然后比较几个指标：

这个对照实验比空谈有用。

因为harness的价值不在于文件看起来多专业，而在于它是否真的减少返工、误判和交接成本。

如果要更系统一点，可以把harness分成三层。

Level 1：个人级。

适合独立开发者。核心是四件套、常用命令、最小反馈循环、失败日志和干净收尾。目标是让AI在你的项目里少犯重复错误，也让每次会话都能稳定接上。

Level 2：团队级。

适合3到20人团队。核心是共享规则、统一目录结构、CI必跑项、PR模板、共享脚本、共享子智能体。目标是把团队共识变成AI也能执行的工程环境。

以前团队靠口头约定和代码review传递的东西，现在要尽量变成规则、脚本、模板和测试。

Level 3：组织级。

适合大公司或生产级智能体。核心是工具注册中心、权限系统、沙盒环境、运行日志、成本监控、人工升级、回归评估。目标是让智能体成为组织基础设施的一部分。

大多数人停在Level 1或Level 2就够了。不要过早追求Level 3。

Harness不是设计出来的，是迭代出来的。

每一次真实失败，都是下一版harness的材料。

讲到这里，harness看起来像一个很完整的答案。

但它不是终点。它只是把问题提高了一层。

MCP让智能体可以连接外部工具、数据库和服务。这是能力扩展，也是攻击面扩展。

比如间接提示注入：工具返回的内容里藏了恶意指令，模型把他当成可信上下文，进而做出越权动作。

再比如工具投毒：一个看起来正常的工具，描述或参数里藏了对模型可见、对人类不明显的指令。

Claude Code官方安全文档也提醒，Anthropic不管理、不审计第三方MCP服务器，用户要自己判断是否可信。

说一个最近遇到的事。

我让智能体去抓取一些数据。抓取结束后，Claude在汇报里flag了一件事：好几个网页的工具返回里冒出了形似 <system-reminder>...</system-reminder> 的特殊标签，他怀疑是被注入了恶意指令。

听起来挺吓人。但我事后查证，这不是真攻击——那些标签其实是Claude Code的harness自己注入的系统提示，用来在工具调用之间提醒模型某些事。下游智能体不知道这是harness自家的格式，看到工具返回里突然冒出特殊标签，按「宁可错杀」的原则就flag了。

这是误报。但误报本身就证明了harness在工作—— <system-reminder> 这个格式之所以专门用来防注入，正是因为攻击者不知道精确格式，塞进网页里的伪指令长得不像。下游智能体一看到「奇怪的标签」就警觉。误报的代价，远小于漏报的代价。

这也正好印证了第五章那个争论。Cherny那句「prompt injection防御会消失」听起来漂亮，但落到工程里要慎重——今天宁可警觉过头；等模型自己能精准辨识「用户意图 vs 网页伪指令」那天，这层防御才会真的不必要。

这件事说明：

这已经很重要。但它不是万能。

你控制的是AI在你设计的系统里的行为。可整个系统是否真的按你设想的方式运行，是另一个问题。

研究技术风险的Andrew Maynard专门写过一篇文章，讨论harness这个比喻的问题。

他的提醒可以概括成两点。

第一，它默认控制者和被控制者之间有清晰边界。

但使用AI时，这条边界很快会模糊。

你让Claude Code重构一个模块，他提出的结构比你原来想得更好。你采纳了他的方案。这时你是在指挥他，还是在接受他的判断？

第二，它默认这是一种工具关系。

锤子不会挑战你。发电机不会反问你。但AI会。

他会说：这个设计可能有问题，要不要考虑另一个方案？

当一个工具能理解意图、提出反对意见、改变你的判断方式时，他还是传统意义上的工具吗？

我没有确定答案。但我觉得，继续只把他当工具，可能会让我们错过一些重要变化。

回到第五章那个争论——Cherny说harness会消失，Osmani说摩擦只是搬家。

如果你信Cherny，会担心今天的工程经验过时。
如果你信Osmani，会担心模型生成代码的速度毁掉代码库长期质量。

但还有一层更基础的问题，两边都没正面回答——

当AI写了越来越多代码，我们对代码本身的理解会发生什么？

Osmani那条「三天后我自己都解释不清这段代码怎么工作」，其实暗示了一件更深的事情：代码可能不再是工程师的「作品」，而是工程师的「采纳物」。

这件事在历史上也出现过。工业革命之后，木匠不再亲手做家具，工厂工人也不再理解整条生产线。专业知识被基础设施吸收了——这让人类整体产能上升，但也让单个人的「完整理解」变得稀薄。

软件可能在重演这条路。

Harness是这条路上的工程响应。但工程响应之外，还有更长远的问题——团队怎么传承理解？组织怎么避免成为黑箱？职业教育该教什么？

这些问题不在这篇文章的范围里。但它们会越来越大。

这篇文章很长。其实只在回答一个问题——

当我们说「控制AI」时，我们到底在说什么？

提示词时代的答案是：把话说清楚。
上下文时代的答案是：把信息给对。
Harness时代的答案是：设计一个让AI能持续做对事情的环境。

这个答案比前两个更接近工程。

但它也不是绝对控制。它只是把控制问题从提示词层，移到了系统设计、权限设计、组织流程和人类判断层。

问题没有消失，只是变得更结构化，也更值得认真对待。

过去几年，我们一直问：模型会不会替代程序员？

Harness engineering给了另一个角度：模型会替代越来越多的执行动作。但它同时制造出一个新的工程对象——AI的工作环境。

Cherny说得对，最好的会计软件可能不会由工程师写。但写出能让会计师持续产出可靠软件的那个harness环境的人——他们才是新一代的工程师。

未来真正重要的工程师，不一定是写最多代码的人，而是能把目标、边界、上下文、工具、反馈和质量标准组织成一个系统的人。

AI时代真正值钱的，不是你会不会命令模型。

而是你能不能设计一个让模型持续做对的环境。