Harness 会被大模型吃掉吗——一个被混淆的问题
一个常见的反对声
上一篇聊完”基建复利”之后，有朋友看完直接问了一句：
“模型迟早能自己干这些事。你现在搭这么多 Harness，不是在给未来的自己挖坑吗？”
这个问题值得正面回答。但回答之前，得先把”Harness”这个词讲清楚——因为大部分讨论里，反对的人和支持的人，根本不在说同一个东西。
很多人以为 Harness 就是”给 AI 写一堆补丁脚本”。如果只是这层，那大模型确实会把它一点点吞掉。但 Harness 真正的范围比这大得多——它甚至不只是一种工程实践，而是一个思想。把这个思想看清楚之后再回到那个问题，答案会变得很不一样。
💡 Harness 不是工具集，是个思想
先把概念厘清。
简单说：除了模型输出之外的所有东西，都可以叫 Harness。
这句话听起来很宽，但正是它的宽，才让很多人讨论时讨论的不是同一件事。展开一下，Harness 跟另外两个常被提起的词——Prompt Engineering 和 Context Engineering——其实是层层包含的关系：
- Prompt Engineering（提示词工程） 关心的是：你给模型那一句话怎么写、用什么措辞、给不给示例。
- Context Engineering（上下文工程） 关心的是：你的上下文里有什么——而上下文本身就包括了提示词。所以 Context 包含 Prompt。
- Harness Engineering 关心的是：除了上下文和提示词之外，整个系统怎么自主运行。怎么编排、怎么验证、怎么从错误里恢复、怎么把零散的步骤串成一条端到端的流水线。所以 Harness 包含 Context、也包含 Prompt。
这不是严格的集合论包含关系——比如有些 Harness 把约束直接编进 linter，连显式 prompt 都不走。但层级感是清楚的：抽象层一层比一层高。换个画面感更强的说法：模型像一个引擎，Prompt 是你点火时按的按钮，Context 是燃料和油路，Harness 是整辆车——底盘、刹车、方向盘、安全带，以及让它能上路的那套交通规则。
为什么先讲清楚这一层？因为后面要回答”模型会不会吃掉 Harness”这个问题——讨论时必须知道你说的 Harness 到底指哪一层。把”补丁脚本”那一小角当成全部 Harness 来反驳，是大部分误会的源头。
顺带说一下广义和狭义的区别。广义的 Harness 包含上面三层：Prompt + Context + 外层。狭义的 Harness 单指最外层——除了 Prompt 和 Context 之外的那部分工程化工作。但奔着外层去做的时候，里面那两层一定是有的——你没法搭一个”只有外层、没有 Context”的 Harness，那等于在搭一个空壳。
而且这一层是 AI 时代特有的。AI 出现之前的工程实践不需要这层——因为没有”模型输出稳定性”这种东西要管，没有”上下文窗口太小要分段”这种问题要解。Harness 是 AI 出来之后才作为一个独立工程方向被命名的，不是给老的工程纪律换个新名字。
讨论 Harness 之前，先看清楚自己在说哪一层。
🏗️ Harness 真正在沉淀什么
讲清楚定义之后，再看 Harness 真正有价值的部分在哪。
提 Harness 的时候，意味着你不只关心”这次让模型做对一件事”，还关心”这件事要做的过程里，Prompt 和 Context 应该怎么沉淀下来”。这两件事恰恰是 Harness 真正有价值的地方——因为你找到并沉淀的 Prompt 和 Context，是别人复制不了的。模型大家都能调，开源的、闭源的、自己跑的，能力越来越接近。但你这个领域里、这个流程里、长期摸索出来的那些上下文和提示词，别人很难凭空抄走。
具体一点，Harness 在沉淀的东西，大致可以拆成三层。
第一层是有价值的 Prompt 和 Context。 这层最贴近”私有资产”。你这个行业、这个团队、这个具体场景下，什么样的提示词组合能让模型输出稳定的结果？什么样的背景信息一定要在上下文里出现，模型才不会跑偏？这些都是要在实战里反复试错才能拿到的，写在文档里、嵌进流程里、变成可复用的模板，就成了你的 Context 资产。
第二层是任务能端到端跑完，且每次跑都接近稳定。 Harness 的工程性体现在这里——它不是某次跑通就算赢，而是”跑十次八次都能完成、不要每次都靠人盯”。Hashimoto 给 Harness 一个特别精炼的描述，大意是：每当发现 Agent 犯错时，花时间工程化解决方案，防止它再次出现。¹ 这个定义不是在描述某种架构，是在描述一种持续迭代去抹平错误的工程姿态。每抹平一次，下次就不再犯同一个错；积累几个月之后，整个系统的稳定性会肉眼可见地往上爬。
第三层是自动反省和自动纠错。 这是更进阶的部分。系统不只是机械执行，而是能在过程中察觉”这一步好像不对”、“这次输出和上一次差太多”，然后自己回头修。OpenAI 那个百万行代码案例最让人印象深的部分，不是”AI 写了一百万行”，而是 5 个月之后，Agent 之间能互相审查 PR、人工审查的占比一直在降²。这种自纠能力不是一开始设计出来的，是 Harness 跑了几个月之后自然长出来的——因为前两层做得好，反馈数据足够多，第三层才有可能浮现。
有价值的 Harness，本质是把”每次的成果都变成下一次的起点”。
🌐 Harness 不止编程——内容、调研、研究都该有
一旦把 Harness 看成思想而不是工具集，它能用的地方就远远超出编程。
举个具体的例子。做内容的人，如果用 Harness 思想去搭流程，大致是这样：
- 热点采集与分析：每天定时从特定信源里抓内容，按标签归类，把”值得展开”的部分标出来。
- 标题、内容、图片构建：基于筛选过的素材，用一套你磨过几十次的提示词去生成草稿，再走一遍图片生成流程。
- 多平台发布：草稿成型之后，按各平台的格式自动适配——微信公众号、X、小红书、博客，每个平台的字数限制、配图规范、标签体系都不一样。
- 数据收集与迭代：发出去之后，把每个平台的阅读量、互动率、留言主题收回来，反过来喂给前面的”采集”和”构建”环节。
这中间沉淀出来的东西——你的选题判断标准、你的标题模板、你的图片风格描述、你对每个平台用户口味的理解——几乎都是模型厂商触达不到的资产。OpenAI 不会知道你的选题偏好，Anthropic 也不会知道你公众号读者爱看什么开头。但这些东西又恰恰决定了你输出内容的差异化。
不止内容。同样的逻辑放在调研、研究上也站得住：
- 调研流程：怎么从一个模糊的题目出发，先穷举可能的子问题，再决定从哪个信源切入，再用什么方式收敛——这套流程一旦沉淀，每次新的调研都能省下大块”启动摩擦”。
- 开发流程：怎么从需求到设计到实现到测试，每一步该让 AI 介入哪些部分、人审核哪些部分——这部分上一篇已经聊过 OpenAI 的案例。
- 发布流程：怎么把成果（不管是代码、文章、还是产品功能）从”做完”变成”被用上”——这中间的打磨、审核、推广、监控，都是值得编进 Harness 的环节。
这些流程的共同特征是：它们是必经的步骤——每个项目都要走，每次走都很类似。 既然必经又类似，就有沉淀的空间。沉不沉淀的差别，会随着项目数量被指数级放大。
还有一类 Harness 工作经常被忽略，但同样重要：不是从零设计新流程，而是把已有流程里没跟 AI 打通的环节改造一下。
很多公司的流程是”单线”的——一个环节做完才能进下一个，每个环节都依赖人手动衔接，整条线走下来非常慢。这种慢不是模型能力不够导致的，而是流程操作上的速度本身就上不去。把这类流程拆开来看，会发现真正卡住时间的那些点，恰恰是那些可以被 AI 接手或半接手的——信息整理、格式转换、跨系统传递、初步审核、版本对齐。
把这些点一个一个挑出来，用 Skill / Tool / 简单的自动化串起来，整条线的速度可以快好几倍。这种”存量改造型”的 Harness，价值不比”无中生有型”那种小——很多时候反而更值得做。因为存量流程已经被验证过了，知道每一步都是必要的，剩下要做的只是让它跑得更快。
但要分清楚边界：改造的对象是”衔接环节的人工搬运”，不是业务约束本身。 审批必须走完才能放款、合规必须确认才能上线——这些是业务的内在逻辑，不能为了快而砍掉。能改的是审批人之间传递材料、整理证据、跨系统查信息这些衔接动作。业务约束保留，衔接成本压缩。
🪜 还没全自动？最小 Harness 也是 Harness
讲到这里要补一个常见误解：很多人觉得 Harness 必须是一个全自动跑起来的系统，没到那个水平就不配叫 Harness。
不是的。Harness 是个连续光谱，不是一个二元状态。
最小的 Harness，可能就是你把一些能力封装成 Skill 或 Tool——比如 Claude 的 Skill、自己写的几个 .md 提示词模板——然后在中间用人工审核串起来。比如这样的工作流：
- 第一步用 Skill A 把需求结构化
- 第二步人看一眼，调一下框架
- 第三步用 Skill B 出初稿
- 第四步人审核一遍内容
- 第五步用 Skill C 走发布流程
每一步都有 AI 在干活，但人在中间几次决策点上介入。这就已经是 Harness——只是还没做到全自动那一步。
为什么强调这个？因为如果你以”我的流程能完美跑通才开始搭”为门槛，那基本不会有开始的那一天。而真正起效的 Harness，几乎都是从这种”人 + Skill 拼图”的最小形态开始的——先把可复用的部分抽出来变成 Skill，再把 Skill 之间的串联流程画清楚，再一步步把人做的决策点替换成自动判断或验证。每替换一个，Harness 就成熟一点。
最小的 Harness，是把你做事的流程画在纸上、把提示词归到一个文件夹、给每个步骤起好名字。 从这一步开始，比什么都不做强。
⚖️ 那大模型会不会一锅端？
讲到这里，可以正面回答开篇那个问题了。
这个反方论点其实有它的道理：别人说的 Harness，可能指的是 Context 更外面那一层。 那一层确实可能会被大模型慢慢吞掉。
什么是”Context 更外面那一层”？比如：
- 因为模型上下文窗口有限，你写一堆切分逻辑、压缩逻辑、检索逻辑去喂它——上下文窗口变大、模型注意力变好之后，这些工程量很多就可以扔掉。
- 因为模型不稳定，你写一堆 retry、fallback、check 的脚手架——模型变稳之后，这些也可以减薄。
- 因为模型不擅长某种特定任务，你专门搭一个 sub-agent 去补这个洞——模型能力提升之后，这个洞自己就补上了。
这些 Harness 的存在理由，本质是在补偿当前模型的弱点。模型变强，弱点消失，补偿就没意义了。
但这不等于”Harness 不该做”。要看清楚一件事：Harness 是分层的，不是均质的。 把它拆成两层来看，结论会清楚很多。
内层：模型吃不到的东西
内层是你私有的 Context、方法论、流程沉淀，加上那些”模型越强越值钱”的能力。
- 你这个领域的”最后一公里”数据——上一篇已经聊过，这部分是模型训练数据覆盖不到的。
- 你长期沉淀的提示词模板和思维链——它们记录的是你对这个问题的判断路径。
- 评估层、可观测性层、安全约束层——模型变强之后，反而需要更强的评估才能让你敢用、敢放手让它跑高风险任务。
这层很难被模型吃掉。模型越强，这层反而越有价值——因为更强的模型能在更精准的上下文里发挥更大的杠杆。
外层：会被模型逐步吃掉的东西
外层就是前面说的那些”补偿型”工程——切分、压缩、retry、补洞的 sub-agent。这层会被吃掉。承认这一点，不是放弃 Harness，而是看清楚 Harness 设计该怎么做。
那既然外层会被吃掉，现在还做不做？
做。三个理由。
第一，时间窗口。 你不知道模型是 3 个月后还是 6 个月后才能达到那个效果。如果你 1 个月能搭出这套外层、模型 6 个月之后才追上——那中间 5 个月，就是你比别人跑得快的速度优势。这 5 个月里你能多迭代多少次产品、多服务多少用户、多沉淀多少内层资产，决定了模型追上来的时候你已经站在哪里。
第二，业内的人自己跑得最快——靠的就是 Harness。 Anthropic 自己专门写了一篇 Harness Design for Long-Running Agent Applications³，公开了他们怎么给长任务搭 Harness。这不只是给开发者看的指南——观察一下他们自己的发布节奏：从 Claude Code 到 Skills 到 Sub-Agents 到 Hooks，新功能出得让人跟不上。这种迭代速度有相当一部分跟模型本身的能力没关系，而是流程上能多快地衔接、多快地放出去。最有动机”让模型自己干掉一切”的公司，自己反而是把 Harness 搭得最齐的。 这个反差本身就是一个信号。
第三，外层投入有具体的回报数据可参考。 HumanLayer 做过一个实验：Claude Opus 4.6 这个模型本身没换，仅仅调整 harness 配置（CLAUDE.md、MCP、Skills、Sub-Agents、Hooks、Back-Pressure 这六个杠杆），在一个评测里的排名从第 33 名跃升到第 5 名⁴。当然这是单一评测的单一案例——METR 也做过研究，得出 harness 对 benchmark 增益不显著的结论；两边数据其实是冲突的。但即便保守看，“模型固定的前提下，Harness 的优化空间比直觉要大”这个方向上的证据是有的。短期回报真实存在，只是别指望它每次都能跨 28 个位次。
但这三个理由是有条件的。要让外层投入”被吃掉”的时候不至于太亏，外层 Harness 自己得满足几个设计原则：
- 不在工程上打太多补丁，避免 Harness 重到搬不动。
- 保持轻、保持薄，让人工介入还能介入得进去。
- 当模型能力提升时，这套体系本身能跟着往上抬，而不是反过来被新模型淘汰。
按这套原则做出来的外层 Harness，被吃掉的时候你不会觉得心疼——因为它一开始就被设计成”用一段时间就该退场”的形态，而不是”耗你半年工时去支撑一个永久存在”。
外层的真正选择：做薄还是做厚
把”做不做”这个问题换成”做薄还是做厚”，问题反而清楚了。
做薄：外层只搭最薄的那一片——把流程画清楚、把可复用的提示词归一起、把人工介入点固定下来。这种 Harness 难被模型吃掉，因为它本身就薄到不构成”模型能替代”的工作量。
做厚：明知道某些环节模型可能下一代就能自己解决，但你今天反复要做、每次手动做都很耗时——那就把它包出来。这种 Harness 是用来换”当下窗口期的速度”的，赌的是它在被吃掉之前的每一天，都在帮你比别人跑得快。
哪些薄、哪些厚，看两件事：
- 当下要不要反复用 —— 要反复用就值得做厚，哪怕未来被吃，当下已经回本
- 核心是不是私有 Context —— 是私有 Context 就做薄、聚焦在沉淀那部分；这部分模型怎么强都吃不到
按这两条对照一下，每次要不要在 Harness 上投入工程量，答案会清楚很多。
真正的核心是复用性沉淀
但前面说的”内层 vs 外层”，其实只是个分类工具。再往后退一步看，会发现真正的核心不是”哪一层会被吃掉”，而是另一件事——
复用性沉淀。
不管做什么项目，如果有些步骤是必经的——调研、开发、发布——那就一定要看到它们的可复用性，然后花时间把可复用的东西沉淀下来。沉淀进流程、沉淀进 Skill、沉淀进文档、沉淀进 Harness 的某一层。
如果不沉淀会怎样？会出现一个反常识的结果：AI 用了，效率提高了，但人反而变得更累。
为什么？因为 AI 在中间环节其实并没有提升那么多——它能省掉的是那部分能模式化的体力活，但不能省掉判断、不能省掉决策、不能省掉验收。如果你没有把这些判断和决策的”标准答案”沉淀下来，每次跑流程，AI 都会在每个决策点把你叫回来：这一步该走 A 还是 B？这个标题哪个更好？这段代码要不要重构？
你被叫回来一次，就要重新装载一次上下文、重新做一次判断。次数多了，疲劳感比纯人工还重。AI 没有让你脱离决策——它只是把决策点切得更细，频率打得更高。
基本上只有一个解法：把决策标准本身沉淀下来。让流程在大部分决策点上有自己的判断依据——可能是一份明确的判断 checklist、可能是几个对照样本、可能是一段自动化的验证脚本——这样 AI 就能自己往下走，只在真正高风险的节点把你叫回来。这个”沉淀决策标准”的过程，就是 Harness 在做的事。
所以”会不会被模型吃掉”这个问题问错了。真正该问的是：这件事我做完之后，下次还能用吗？还是要重新来一次？
如果答案是”重新来”，那就是你应该往 Harness 上花时间的地方。至于这部分 Harness 未来会不会被模型自己内化——那不是优先要担心的问题。
沉淀的产物未来可能被吃，但沉淀的动作在当下已经省回时间了。 你今天写一份决策 checklist，未来某天模型可能强到能从你的工作记录里自己反推出来——但在那之前，你已经用这份 checklist 跑了几十次甚至几百次流程。省下来的时间是真实的，沉淀过程中练出的判断也是真实的。即便最终被模型吃掉，那一段时间的回报已经收下了。
优先要担心的是：今天就开始沉淀，比明天才开始沉淀，差距会随时间放大。
🔚
Harness 不是为了”让 AI 替你干活”，是为了让你做的每件事都能被复用、被积累、被往前推。
外层会被模型逐步吃掉一些，但内层很难吃掉。即便外层全被吃掉，沉淀过程中你拿到的那些 Context 和判断标准，也已经长在你的工作流里了。
至于具体怎么把一个流程的”可复用部分”识别出来、怎么把它变成 Skill 或 Harness 的一环——那是另一个话题了。