AI工程领域正经历一场激烈的范式之争：随着模型能力的快速进化，那些精心设计的系统框架究竟是资产还是负债？本文深入剖析‘底模派’与‘Harness派’的核心分歧，揭示两种工程哲学背后关于智能本质的深层思考，并指出从业者如何在技术迭代中构建真正持久的价值。

一、这个争论正在你的工位上发生

故事是这样开始的。

团队刚刚上线了一套 Agent 系统，花了三个月时间：RAG pipeline、记忆模块、任务拆解框架、错误重试机制，外加一套精心调试过的 prompt 模板。每一个组件都是在模型一次次出错之后打出来的补丁，整套系统跑起来磕磕绊绊，但至少在跑。

然后新模型发布了。

有人打开 Playground，把之前那个需要五个节点才能完成的任务，直接扔给裸模型，一次就过了。

会议室里沉默了三秒。

然后两种声音同时出现——

“你看，我早说了，等模型变强，这些东西迟早要被淘汰。”

“那是因为我们的框架给它铺好了路，换个真实场景试试？”

同一个 demo，两种归因，两套世界观。这就是”底模派”和”Harness派”的分歧起点。它不是哲学讨论，是每一个 AI 工程师每天都要面对的工程决策：我现在搭的这套东西，到底是资产还是负债？

二、底模派：让他们说话

底模派的核心主张，用一句话概括就是：工程复杂度是模型能力不足的临时补偿，不是长期资产。

他们的历史证据是充分的。

三年前，让模型做多步推理，你需要手写 Chain-of-Thought 的模板，一步步引导它”先想，再想，然后回答”。现在你不需要了，模型自己就会想。两年前，检索增强生成（RAG）是标配，因为模型记不住太多东西，也不知道最新的信息。现在长上下文窗口动辄几十万 token，很多 RAG 场景开始被直接替代。一年前，Function Calling 需要精心设计 schema，还要写大量 few-shot 示例。现在模型对工具的理解已经接近直觉。

底模派看到的是一条清晰的曲线：每隔一段时间，一批精心设计的 Harness 就会失效。 不是因为设计得不好，而是因为它解决的问题已经不再是问题了。

他们还有一个更尖锐的观察，但通常不会在公开场合说：很多 Harness 工程师，在无意识地给自己制造护城河。 系统越复杂，他们越不可替代。这不是阴谋论，是一种自然发生的组织动力学。但问题在于，这条护城河会被填平，只是时间问题。

底模派的终极信念是：智能是通解。 足够聪明的模型，会知道什么时候该追问，什么时候该停下来，什么时候该调用哪个工具。就像一个足够优秀的人类工程师，你不需要给他画每一步的流程图，他自己会搞定。

三、Harness派：让他们反击

Harness 派不是不相信模型能力。他们只是见过太多事。

他们的核心主张是：可预期性比能力上限更重要，而可预期性需要环境来保证。

“你见过几个裸模型直接上生产的？” 这是 Harness 派最常说的一句话。不是质问，是真的在问。

模型再强，它不知道你的业务上下文——你的数据在哪里，你的下游系统是什么接口，你的用户期望什么格式的输出，你的业务逻辑里哪些边界是不能碰的。这些东西不在训练数据里，也不会从 scaling 里自动涌现出来。

模型再强，它也不知道”犯了这个错误之后怎么办”——是重试，还是降级，还是告警，还是直接返回 fallback？错误处理不是智能问题，是系统设计问题。

更重要的是，Harness 派见过太多”Playground 演示很完美，生产环境全崩溃”的案例。那不是模型变笨了，是因为真实环境的输入分布、延迟、并发、异常路径，和演示时的情况完全不同。演示的是能力上限，生产考验的是稳定下限。

Harness 派的核心观点是：你用架构告诉模型”什么叫做好”——什么格式是可接受的，什么结果需要验证，什么情况需要人工介入。这不是在限制模型，而是在定义任务本身。没有这个定义，再强的模型也是在瞎猜你想要什么。

他们对底模派的反驳也很直接：你们赌的是一个还没到来的未来，我们解决的是今天的问题。等模型真的强到那个程度，我们再聊。

四、裁判入场：两派都踩了一个坑

讲到这里，如果你觉得这是一场旗鼓相当的辩论，那两派都成功了。但作为旁观者，我想指出一件事：

这两派都有一个盲点，而且是不同的盲点。

底模派的盲点：把”能力”和”意图”混为一谈

底模派默认，随着模型能力提升，它自然会”想做对的事”。但这是两个独立的维度。

能力，是模型能不能完成一件事。意图，是模型在没有明确指令的情况下，会朝哪个方向走。这两者之间没有必然联系。一个能力极强但目标模糊的模型，会非常高效地做出你不想要的事。

Harness 在这个层面上的作用，不只是”弥补能力不足”，更是意图的载体。你的系统 prompt、你的任务描述、你的评估标准，都是在告诉模型什么叫”做好了”。这件事不会因为模型变强而变得多余，恰恰相反——模型越强，意图的对齐就越重要，因为它的影响范围越大。

Harness派的盲点：没有区分”能力补丁”和”结构性资产”

Harness 派的问题不是方向错了，而是有时候把所有 Harness 都等同对待了。

实际上，现有的 Harness 可以分成两类：

第一类是能力补丁——因为模型当时做不到，所以用工程手段绕过去。比如手动的 CoT 触发、细粒度的 few-shot 示例、复杂的检索前处理逻辑。这类 Harness 会随着底模进化而坍缩，这是底模派说对了的地方。

第二类是结构性资产——不是因为模型不行才需要它，而是任何智能体运行于真实世界都需要它。比如：任务的上下文定义、输出的格式与验证、错误的处理路径、人工干预的触发条件、业务规则的显式约束。这类 Harness 不会消失，只会变薄、变得更精简。

如果认不清自己手上的是哪一类，当底模进化的浪打过来，两类资产会一起被认为该扔掉——结果把真正有价值的东西也丢了。

五、一个让双方都不舒服的预判

综合来看，我对未来趋势的判断是这样的：

底模派在预测方向上是对的，但错估了“消失”的边界。

Harness 的复杂度确实会持续下降。那些用来弥补模型能力短板的工程层，会一层层被剥落。这个趋势已经在发生，未来只会加速。任何赌”当前 Harness 复杂度会永久存在”的工程师，都在和历史的方向对赌。

但”环境”本身不会消失，只会变得更薄、更隐形。

打一个类比：操作系统没有因为硬件变强而消失。恰恰相反，随着硬件越来越强，操作系统变得越来越透明——你不再需要手动管理内存，不再需要写汇编来调硬件——但它还在那里，定义着程序能做什么、不能做什么，隔离着资源，处理着异常。

Harness 的最终形态不是消失，而是从“弥补能力不足”演化为“定义边界与意图”。这是一个角色的迁移，不是一个职业的消亡。

对底模派的警告是：如果你的结论是”等模型变强，什么都不用做”——这不是洞见，是放弃思考。你仍然需要回答：模型在你的系统里，目标是什么？边界在哪里？错了怎么办？这些问题不会被更强的底模自动解答。

对 Harness 派的警告是：现在花大力气维护的那套东西，有哪些部分是在给模型补课，有哪些部分是真正的结构性价值？如果你说不清楚，当下一代模型出来，你可能会既保不住该保的，也丢不掉该丢的。

六、对从业者的实践含义

如果你是做工程的，最实用的建议是：构建“可以随模型能力升级而简化”的架构。

具体来说，每一个 Harness 组件在设计时，都要问自己：这个东西存在是因为模型当前做不到，还是因为它本来就应该由系统来定义？前者要标记为”临时”，后者才是核心。前者简化的速度越快越好，后者要设计得足够稳健。

如果你是做产品的，你的核心竞争力不是 prompt，也不是那套 RAG 流水线，而是对任务的结构化理解——你知道这个任务的输入是什么样的，输出什么叫合格，中间哪个环节最容易出错，用户真正在意的是什么。这种理解，才是底模进化替代不了的东西。

如果你是投资人或决策层，判断一个 AI 产品的护城河，最关键的问题是：它的 Harness 是资产还是负债？ 如果这套系统的核心壁垒，是靠复杂的 prompt 工程和 workflow 堆出来的，那它的护城河随着底模进化会越来越浅。真正的壁垒，是数据、是业务理解的深度、是对特定场景”什么叫做好”的定义能力。

七、结尾：底模是天花板，Harness是地基

让我用一个判断来收尾：

底模是天花板，Harness 是地基。两者不是竞争关系，而是共演化的关系。

随着底模变强，地基会越来越薄，越来越隐形——就像我们不再感知重力，但它从未离开。真正危险的不是选错了队，而是没有意识到这场演化正在发生，还在用三年前的思维框架做今天的工程决策。

最后，把这个问题留给你：

> 你现在手上的 Harness，哪些部分你认为会随底模进化而消失？哪些你认为会永远存在？

如果你能清晰地回答这个问题，你就已经超越了这场争论本身。

如果你说不清楚——那可能才是真正值得担心的事。