模型之上
模型之上
我经常和别人开玩笑说：
“Vibe Coding 的时候，模型当前写的代码虽然是屎，只要模型的迭代速度比当前 Bug 生成的速度快，问题就不大。”
但这个玩笑背后有一个很少被追问的问题——
如果模型的迭代速度，没有那么快呢？
等待是真实的成本
Claude 4，GPT-5，Gemini 2.5……这些名字每隔几个月就会出现一次，每次都带着”这次真的不一样”的气氛。但两次发布之间，你还是得用现在这个模型干活。
而现在这个模型，确实有它的能力边界。
你让它重构一个复杂的状态管理模块，它可能在第 12 次迭代之后还在绕圈子。你让它处理一个跨越七个文件的 Bug，它也许永远找不到真正的根因。你坐在那里，看着它自信满满地输出新的错误，心里清楚——这不是 prompt 写得不好，这是模型本身的天花板。
这时候你能做什么？
Agent = 模型 + Harness
LangChain 最近有一篇文章，题目叫 The Anatomy of an Agent Harness，把这件事说得很清楚：
Agent = Model + Harness。如果你不是模型，你就是 Harness。
Harness 是围绕模型的一切——系统提示、工具调用、文件系统、沙盒环境、内存管理、编排逻辑……所有让”一个会说话的大脑”变成”一个能干活的工程师”的东西，都属于 Harness。
模型是智能的容器，Harness 是让这个智能真正有用的系统。
这个定义的意义在于：它把”如何榨干模型能力”的问题，变成了一个工程设计问题。
模型的限制，是 Harness 的设计空间
一个原始的模型，有很多它天生做不到的事情：
- 它没有持久记忆，每次对话都是失忆开始
- 它不能自己执行代码
- 它不知道你的代码库里昨天发生了什么
- 它的 Context Window 会满，满了之后它开始变蠢（有个术语叫”Context Rot”）
- 它会在任务进行到一半时放弃
这些限制，逐条都可以被 Harness 工程弥补：
没有持久记忆？ 给它一个文件系统，让它把关键信息写进 AGENTS.md，下次启动再注入进去——这是一种低技术含量的”连续学习”。
不能执行代码？ 给它一个 bash 工具。它就可以自己写脚本、自己跑测试、自己看报错、自己修。这是它设计自己工具的能力。
Context 会满？ Harness 层做压缩（Compaction）：把对话历史智能总结，把大型工具输出截断并存入文件系统，必要时再读取。
会提前放弃？ 有一个叫 “Ralph Loop” 的 Harness 模式——在模型试图停下来的时候，拦截它，重新注入原始目标，用新的 Context Window 继续干。
不知道外部世界？ 接入搜索工具、MCP 服务器，让它实时拉取文档、调用外部 API。
所以，等待模型迭代的时候，你可以做什么？
答案是：去做 Harness 工程。
模型迭代是 Anthropic 和 OpenAI 的事，Harness 设计是你的事。
具体说，有几个方向值得投入：
一、给模型一个更好的工作台。 你的 Agent 用的是什么文件系统结构？它能访问哪些工具？工具的描述写得清不清楚？很多时候模型”不行”，只是因为它不知道该用哪个工具，或者工具描述写得太烂。
二、管理 Context 质量，而不只是数量。 往模型里塞更多 token 不代表它表现更好。哪些信息应该在 Context 里？哪些应该存入文件等待按需读取？哪些 MCP 工具应该按需加载而不是一口气全塞进去？这是 Harness 层的核心设计问题。
三、建立自验证回路。 让模型写完代码就自动跑测试，跑失败了把错误回传，重新修。这个循环本身就是一个强大的 Harness 特性，用的模型可以是同一个，但完成任务的能力提升非常明显。
四、研究任务分解与子 Agent 编排。 一个复杂任务，一个模型 + 一个线性对话很难搞定。把它拆成子任务，用多个 Agent 并行干，共享文件系统作为协作界面——这是下一代编码工作流的样子。
模型是上限吗？
LangChain 在 Terminal Bench 2.0 的排行榜上做了一个有趣的实验：
同样是 Opus 4.6，在 Claude Code 里跑，和在他们自己优化的 Harness 里跑，成绩差距巨大——从前 30 名一路爬到前 5 名。
模型没变，Harness 变了。
所以，模型不是能力的上限，Harness 才是当下真正的战场。
最后一句话
我那个玩笑里有一个隐藏的假设：你只能被动等待模型变好。
但实际上，你有另一条路——主动设计让模型更有用的系统。
模型是智能，Harness 是系统。智能很重要，但在同等智能下，系统的差距决定了一切。
等模型迭代的时候，先把 Harness 做好。