模型越强，外面的「壳」为什么反而要变薄

前一篇讲 Harness 的文章在说一个判断：模型不够强的时候，外面需要一层壳——管住工具调用、拦住越界操作、补上模型自己判断不了的逻辑。模型越强，这层壳越重要。

那篇写完之后，事情翻了一面。

Anthropic 做了一次内部对谈。主题是：Harness 那套外壳流程，正在被拆掉。 模型强到能自己想步骤，套在它外面的编排就成了枷锁。

这不是在否定前一篇。Harness 确实重要。但当模型能力越过某条线之后，你往里堆的每一层规则都需要重新验收：它现在还在保护用户，还是已经在替模型做它能自己做的决定？

护栏留下，替它做决定的绳索慢慢松开。

Harness 里的三种代码，只有一种该拆

Harness 里的东西可以分成三类：

第一类：安全边界。 不能删文件、不能访问特定目录、不能执行某些命令。这些规则不管模型多强都不能拆。模型擅长判断对错，但它判断不了”丢了用户数据”这个后果对用户意味着什么。安全边界不交给模型判断，跟模型能力强弱无关。

第二类：可验证反馈。 编译、类型检查、测试、lint——这些产生的是确定性的「通过」或「不通过」。它们独立于模型，有独立的存在价值。模型升级之后，这类检查依然需要。引擎灯亮了就是亮了，不需要模型自己判断引擎灯是什么意思。

第三类：替模型规划的编排。 早期为了弥补模型规划能力不足而写死的步骤——“先做 A、再做 B、最后检查 C”——属于这一类。当模型能自主判断先做什么后做什么的时候，这些步骤就从”必要的引导”变成了”替它做它自己能做的决定”。

应该拆的是第三类。而且最危险的事情不是”有些旧规则还留着”，是旧补丁继续假设模型不会做某件已经会做的事，导致模型被一条活在过去假设里的规则按住。

一个具体的例子：变成死重的那个补丁

对谈里提到一个例子——一个补丁，原本是修一个能力缺口。某代模型在某个场景下会误判，需要一条硬规则兜底。那个补丁在当时的代码里是必要的。

模型升级之后，那个缺口消失了。但补丁还在。新模型明明不会犯那个错了，补丁仍然在拦截它的”疑似误判”——把正常的判断当成风险拦住。

没有人专门去删它。因为当模型跑得好的时候，你不会想到去追查一条旧规则是否在干预它。你只会觉得”这轮输出比预期慢”或”为什么它这次没做我以为它会做的那件事”。

这就是 Harness 积累的隐藏成本：不是代码多，是这些代码的假设已经过期，而它们永远不会自己标记自己为过期。

每次换模型，重新验收整套环境

这件事在模型升级时尤其危险。你从 Opus 4 换到 Fable 5，旧 Harness 里的编排是为上一代模型写的。你不知道哪一条规则在假设”模型这一块不太行”，而新模型这一块已经很行了。

验收清单不复杂：

1. 你现在有多少条规则是替模型提前规划步骤的？
2. 其中哪些是因为旧模型自己不会规划才写的？
3. 新模型这一块还会犯错吗？

第三条不要用直觉回答。拿一个典型任务跑一遍，关掉那条规则看结果。如果新模型自己规划的结果不比硬编码规则差，那条规则就可以拆了。

拆的时候小心一件事：别把安全边界和编排一起拆。 安全边界是”不能做的事”——不能删文件、不能提交代码。编排是”应该按这个顺序做的事”——先审查再修改。前者是锁，后者是建议。拆建议之前确认模型自己能处理好，锁不拆。

Harness 变薄和 Context Engineering 的关系

这两件事是同一道命题的两个方向。

Context Engineering 是从输入端把不需要的信息请出窗口。Harness 变薄是从执行端把过期的编排拆掉。两者都指向同一个判断：系统不是在变简单，是在把决定权交还给更适合做这个决定的主体。 模型判断力不够时，上下文和 Harness 替它判断。模型判断力够了之后，继续替它判断就是限制。

Harness 不会消失。但它的目标从来不是越厚越好——是在每一个时刻，刚好补足模型缺失的能力。多一条是干涉，少一条是空缺。什么时候该加、什么时候该拆，靠的不是原则，是每换一次模型时重新跑一遍验收。

壳的重量，应该刚好够护住它能护的东西。多余的部分表面上是安全垫，实际上是在替一个不需要它的人做决定。