大模型会吃掉 Harness 吗？我改变了最初的判断

最近 AI 工程圈有一场争论越来越激烈，两派人马几乎势不两立。

一派认为，随着基座模型能力的持续提升，那些包裹在模型外面的工程脚手架迟早会消失——模型够强了，你写的那几万行编排代码就是历史遗产。另一派则认为，企业落地 AI 的真正难点从来不是模型够不够聪明，而是你有没有能力把业务上下文正确地组织并喂给模型，这件事模型永远替代不了。

这场争论有个专有名词：Big Model 派 vs Big Harness 派。

我在 AI 应用开发领域工作，过去一年多里参与过多个 Agent 项目的落地，亲眼见过 harness 设计的好坏对最终效果的影响有多大。我最初是偏向模型派的。但在深入研究这个问题之后，我的判断变了。

先说清楚：Harness 到底是什么

软件工程领域的权威 Martin Fowler 在他专门讨论 harness 的文章里给出了一个简洁的定义：

"The term harness has emerged as a shorthand to mean everything in an AI agent except the model itself — Agent = Model + Harness."

也就是说，harness 是 Agent 里除了模型本身之外的一切。

最直观的类比是马具。套在马身上的挽具不能替马奔跑，也不能替马拉车，但它可以把马的力量稳定地传递出来，控制方向和节奏。如果你想让马稳定地拉动一整辆马车，并且和其他马匹协作，这套挽具就变得非常重要。

换到 AI 语境里：模型是马，harness 是挽具。

具体来说，harness 包括：Prompt 模板、工具调用格式、重试逻辑、Agent 状态循环、多步骤编排、上下文管理……所有这些让模型能够稳定完成复杂任务的外围工程，都属于 harness 的范畴。

一个具体的例子：同样是让模型编辑代码，你可以用 str_replace 格式（指定旧内容和新内容），也可以用 write_file 格式（直接写入完整文件）。不同模型对这两种格式的响应质量差异显著——有的模型在 str_replace 格式下错误率低得多，有的则相反。这就是 harness 层面的工程决策，和模型本身的能力无关。

模型派的核心论据

模型派的代表性观点来自 Claude Code 的创造者 Boris Cherny。他在 Latent Space 的访谈里说得很直接：

"All the secret sauce, it's all in the model. And this is the thinnest possible wrapper over the model. We literally could not build anything more minimal."

这个观点有数据支撑。在 Scale AI 的 SWE Atlas 编程基准测试中，不同 harness 对同一模型的影响差异极小，基本在误差范围之内。换句话说，当模型足够强时，你选哪种脚手架来编排流程，对最终结果的影响可能只是环境噪音级别的差异。

OpenAI 推理模型的核心贡献者 Noam Brown 的判断更直接。他认为，在推理模型出现之前，工程师们在外围写了大量复杂的重试逻辑和 Prompt Scaffold 来模拟推理能力，但随着底层 Reasoning Model 能力的提升，"those scaffolds will just be replaced by the reasoning models becoming more capable"——那些脚手架会直接被更强的推理模型取代。

模型越强，需要的套壳代码就越薄。 这是模型派的核心逻辑。

Harness 派的核心论据

LlamaIndex 创始人 Jerry Liu 的反驳很有力：今天我们已经拥有很强的模型，也有很多优秀的工具，但企业真正难解决的问题从来不是模型够不够聪明，而是你有没有能力把业务里的上下文正确地组织并喂给模型。

举个例子：如果你想用 Claude Code 自动处理公司的客户流程，你必须先花大量时间把公司的业务类型、流程规范、权限规则全部写成清晰的文档。光是把规则描述清楚，往往就要反复修改几个小时。这件事模型很难自动帮你完成。

有一个实验很能说明问题。一位开发者维护着一个开源编程 Agent，有一天他只改了一件事：调整了 harness 里编辑代码的工具格式。没有换模型，没有重新训练任何东西。结果，15 个主流大模型在他的编程基准测试里全部获得了明显提升。

他的结论很形象：模型出问题很多时候不是因为它理解不了任务，而是因为它没有合适的语言来表达自己。你一直在怪飞行员，但其实是起落架坏了。

OpenAI 自己也在实践中验证了 harness 的价值。他们在官方博客里记录了一个实验：用 0 行手写代码、完全依靠 AI 和精心设计的 harness，构建并交付了一个内部软件产品。这篇文章本身就是对"harness 工程有没有价值"这个问题的一个回答。

我在意的不是两派谁对谁错

读完大量关于这个话题的讨论之后，我注意到一个被很多人忽视的角度。

有人提出了一个很尖锐的问题：harness 的商业模式是否可持续？

"模型升级一次，做 harness 的就要死一片。"这句话听起来很残酷，但逻辑上是成立的。你今天辛苦搭建的编排逻辑，可能在下一个模型版本发布之后就变成了冗余代码。harness 本质上是人设计的流程规范，一旦模型强到能自己理解这套规范，harness 就完成了它的历史使命。

还有一个更深的问题，是纯技术讨论很少触及的：如果模型派赢了，谁是最终受益者？

大模型公司在军备竞赛中欠下了巨量的资本债务，它们需要回报。如果模型强到什么都能干，它们的下一步必然是垂直整合——先做工具，再做应用，最后做行业解决方案。留给独立 harness 工程师和中小企业的空间会越来越小。

这不是技术问题，是结构问题。

一个被低估的观点：两者是循环关系，不是替代关系

在所有我看到的分析里，有一个观点我认为最接近真相：

不是模型逼近了某种极限，而是 harness 没有跟上模型。当 harness 跟上的时候，对模型的需求又会更高。两者就是这样一种循环关系。

这个视角解释了很多现象。为什么 Claude Code 的 harness 做得越薄，模型反而表现越好？因为薄的 harness 减少了对模型的干扰，让模型能力得以充分释放，然后又反过来推动了对更强模型的需求。

这也解释了为什么 Cursor 能在短短几年内从 4 亿美元估值成长到 290 亿美元（TechCrunch 报道），并仍在持续融资——它不是在和模型竞争，而是在和模型一起进化。

所以我现在的判断是：未来 AI 的竞争不是 Model vs Harness，而是 Model × Harness。

但这个结论对于正在做 harness 工程的人来说，并不完全是好消息。

做 Harness 工程的人，现在该怎么想

我在和一些做 Agent 工程的朋友聊这个话题时，听到一个让我印象很深的说法："我工作是 harness，但我非常悲观，我觉得未来是模型派的。"

这句话的价值不在于它是否正确，而在于它揭示了一个真实的行业情绪：即使是这个方向的从业者，也对自己的长期价值存疑。

我认为这种悲观有一定道理，但不完全准确。更准确的描述是：

今天的 harness 形态会消失，但 harness 这件事不会消失。

具体来说：

• 帮模型思考的 Prompt Scaffold，会被更强的推理模型取代
• 简单的重试逻辑和状态管理，会被模型内化
• 但把企业业务上下文结构化、把复杂工作流拆解成模型可理解的形式，这件事的难度不会因为模型变强而消失

Jerry Liu 的判断是：未来几乎所有 AI 产品本质上都在做两件事——提供上下文，或者提供工作流。这两件事都需要人来做，只是做法会随着模型能力的提升而不断演化。

我自己有过一次很直接的体验：同样的任务，换了工具调用的格式之后，模型的完成率有了明显提升。那一刻我才真正理解 harness 的价值不在于逻辑有多复杂，而在于有没有给模型一个它能顺畅表达的接口。

harness 工程师真正需要担心的，不是自己会不会被取代，而是自己有没有在随着模型一起进化。

最后

Latent Space 在讨论这个话题时提到了 AI 历史上著名的"苦涩的教训"（Bitter Lesson）：几乎所有人工设计的精巧策略，最终都会被更大的算力和更强的模型所取代。

但他们同时承认，随着越来越多企业 Agent 真正落地，那种认为所有套壳工程最终都会消失的判断，正在被市场慢慢挑战。

这场争论还没有结论。但有一点是确定的：在模型能力跨代升级之前，harness 工程的窗口期是真实存在的。问题只是，你有没有在这个窗口期里建立起真正属于自己的东西。