Cursor花几周磨的那层壳，让模型少跑6轮对话省一半token

---

我试了三年，才搞懂 Cursor 真正牛X的地方

先讲个事儿。

上周三晚上，我盯着 Cursor 那三篇技术博客看了整整四个小时。不是走马观花地扫，是真的一句一句啃。看到一半的时候，我突然想起 2023 年 11 月的一个深夜——那会儿我正在给一个 agent 框架调上下文管理，调试到凌晨两点，气得差点把键盘摔了。

当时我觉得是模型不行。

现在回头看，是我蠢。

说实话，这个观点可能会得罪人

大家都在追新模型，Cursor 却在死磕那层"壳"。

我先说个可能会挨骂的观点——SOTA 模型之间的差距，远没有你想象的大。真正拉开产品体验的，是包在模型外面那层东西。

我知道，这话说出口，做模型的朋友想顺着网线来打我，做应用的朋友也觉得我在说废话。但你先别急，听我讲完。

你想想，这事儿其实挺反直觉的。咱们这个圈子现在卷到什么程度了？Claude 出了新版本，全网都在测；GPT 更新了，立刻有人做 benchmark 对比。差两个百分点，大家就急吼吼地切模型。

但 Cursor 这帮人在干嘛？

他们在磨 harness。

同一个模型，套不同的壳，表现天差地别

Cursor 在博客里说了一个细节，我反复看了三遍，真的。

他们每拿到一个新 SOTA 模型，不会直接丢给用户用。而是花好几周时间，针对这个模型的"脾气"重新调 harness。调完之后，同一个模型明显更快、更聪明、更省 token。

好几周。

你品品这个投入。现在模型迭代速度是按月算的，甚至有按周算的趋势。他们每次都要花好几周去适配一个模型。这要是没效果，早被砍了，对吧？但他们不仅没砍，还越做越深。

那什么是 harness？

说白了，就是模型外面那层壳。系统提示词怎么写、工具怎么定义、上下文怎么管、工具调用怎么编排、出错怎么处理、不同模型怎么切换——这些东西加在一起，决定了同一个模型在你的产品里到底能跑多顺。

这东西看着不起眼，但——怎么说呢——就像你买了一台法拉利的发动机，然后配了个拖拉机的变速箱。发动机再好，开起来也是灾难。

我做过一个对比实验，去年年底的事儿。同一个 Claude 模型，分别接了俩不同的 agent 框架跑代码重构任务。一个框架的 harness 设计得……讲真，挺糙的。工具描述写得很随意，上下文管理基本就是"全塞进去"。另一个框架明显打磨过，工具描述精确到参数级别的约束，上下文有明确的优先级和裁剪策略。

结果呢？

前者平均要 12 轮对话才能完成任务，token 消耗 80k 左右，中间还经常跑偏，我得不停纠正。后者平均 6 轮搞定，token 消耗 40k，很少需要我中途插手。

同一个模型。

这事儿让我彻底信了。模型是发动机，但 harness 是变速箱、悬挂、转向系统——你用个烂变速箱，发动机再好也白搭。

从"喂饱它"到"让它自己找"

这三篇博客里，我最有体感的一个变化，是关于上下文管理的。

2024 年那会儿，模型还比较"笨"——也不能说笨，就是不太会自己挑上下文。所以 Cursor 的策略是各种"护栏"，跟照顾小孩儿似的：

• 编辑完文件就主动把 lint / type 错误塞回去
• 模型读文件读太少？自动改写它的请求，多读一些
• 一轮里能调几个工具都给你限死
• session 一开始就把目录结构、语义匹配的代码片段、用户附件的压缩版……一股脑全塞进 system prompt

翻车了。

我去年用 Cursor 的时候，确实能感觉到这些"过度保护"。有时候我只是想改一个函数名，它上来就读了七八个文件。感觉像是"我怕你不够用，所以全给你"。有一次我让它修一个类型错误，它读了一堆不相关的文件之后，开始"顺手"重构起别的模块来了。我赶紧喊停，但 token 已经烧掉好几千了。

现在呢？

这些护栏基本被拆掉了。现在 Cursor 的做法特别克制——静态上下文只留一点点：操作系统、git 状态、当前打开和最近看过的文件。剩下的全都改成"让 agent 自己按需去拉"。

他们管这个叫 Dynamic Context Discovery，动态上下文发现。

我觉得这名字起得挺好。本质就是：别一上来全摊在桌上，让模型自己翻抽屉。

这个变化背后，其实是模型能力的跃迁。以前的模型需要你"喂"，现在的模型会自己"找"。那你的 harness 设计就得跟着变——从"大包大揽"变成"给手脚不给拐杖"。

我在自己的项目里试了一下这个思路。之前我的 agent 初始化时会加载一堆项目文档和代码索引，大概 15k token 的静态上下文。后来我砍到只剩 3k，剩下的改成让 agent 用搜索工具按需获取。

效果出乎意料。

token 消耗降了 40%，任务完成率反而提升了。因为模型不再被一堆可能无关的信息干扰，它每次只拿自己真正需要的。

真的。

模型越强，harness 越要"克制"

这里有个反直觉的点，你细想。

很多人觉得，模型越强，harness 就可以越简单——反正模型聪明了，随便给点工具它就能干活。不是不行，就是太天真了。

Cursor 的经验恰恰相反。模型越强，harness 设计越要精细。因为强模型对提示词更敏感，对工具定义的边界更清楚，对上下文的噪音更不耐受。

它就像一个很聪明但很有主见的同事。你给他模糊的指令，他会按照自己的理解去干——干出来的东西可能跟你想要的不一样。你得把边界、约束、预期都讲清楚，他才能发挥出真正的能力。弱模型反而好伺候，你塞一堆东西进去，它乖乖照做，不会想太多。

这个观察——不对，应该叫教训——是我踩了无数次坑才总结出来的。

去年我用一个早期版本的 agent 框架，提示词写得特别详细，恨不得把每一步都规定好。那时候模型弱，效果还不错。后来模型升级了，我偷懒没改提示词。结果 agent 开始各种"自作主张"，因为它觉得我那些详细规定限制了它的发挥。

绝了。

后来我把提示词从"告诉它怎么做"改成"告诉它要什么结果、有什么约束"，效果好了一大截。大概是 2024 年夏天的事儿，具体几月忘了，但那感觉记忆犹新。

为什么我觉得这事儿重要

现在圈子里有个风气，就是追模型追得很紧。哪个模型在 benchmark 上高两个点，大家就赶紧切过去。但很少有人愿意花时间打磨 harness。

我理解为什么。

因为调 harness 很枯燥。没有 benchmark 可以刷，没有论文可以发，就是反复试、反复改、反复看 agent 的对话记录找问题。而且效果很难量化——你怎么证明是 harness 改好了，而不是模型本身变强了？这种活儿，说白了，吃力不讨好。

但 Cursor 这帮人显然不在乎这些。他们在博客里很坦诚地说，这就是个"持续打磨"的过程，没有银弹，没有一招鲜。

我挺佩服的。

写了快十年东西，我见过太多产品死在"重模型轻工程"上。模型一换，整个产品体验就崩了，因为 harness 没跟上。然后团队开始怀疑模型不行，又去追下一个模型——恶性循环。讲真，这种事儿我见过至少五六次了。

其实说白了，模型是别人训练的，harness 才是你自己的。模型会越来越强，但 harness 不会自动变好。它只能靠你一点一点磨。

扯远了，说回正题。

我得承认一个局限性——我上面说的这些，主要适用于 coding agent 这个场景。别的场景，比如客服、写作、数据分析，harness 的设计重点可能完全不同。而且 Cursor 有大量用户数据可以指导他们优化，小团队可能没这个条件。

但大方向应该是对的。模型只是发动机，真正决定体验的，是整套工程系统。

这事儿，大概是今年我最大的认知刷新吧。

你追了三年模型，最后发现：真正拉开差距的，是你愿意花多少时间去磨那层别人看不见的壳。