Harness
已死？

Harness 不是一个框架，是「模型之外的全部」“If you're not the model, you're the harness.”

这句话来自 LangChain 的 Vivek Trivedy，是行业里流传最广的一句定义：只要你不是模型本身，你就是 harness。它听上去像废话，但恰好说明了为什么这层东西总被低估——因为它没有固定形状，模型每变强一次，它的边界就往后挪一次。

换个更好懂的比喻：模型是发动机，harness 是底盘、变速箱、方向盘、仪表盘和刹车。同一台发动机装进不同的车，能跑多快、能开多远、会不会翻车，完全不是一回事。而发动机功率翻倍的时候，底盘不是「没用了」，是得重做。

它里面到底装了什么

讲者给出的分层和那张封面图一致，可以压缩成两张皮：运行时层管「在哪跑、断了怎么接上」，上下文与编排层管「模型此刻能看到什么、什么时候该换个人来干」。他自己管第二层叫「蛮荒西部」——规则最不清楚、迭代最快、也最吃经验的地方。

值得单独说一句的是 Compaction（压缩）和 Model Routing（模型路由）这两个词。前者决定长对话被怎样折叠成「还记得的部分」，后者决定哪一步该交给便宜模型、哪一步必须用贵的。这两件事模型自己都不做，但它们对最终体验的影响，往往比换模型大。

为什么这个人的话值得听Cursor → SpaceXAI → Grok Bot

Jediah Katz 于 2025 年初加入 Cursor，自述是在 agent harness 上工作时间最久的工程师之一。Cursor 被 SpaceX 收购（2026 年 6 月宣布，约 600 亿美元全股票交易）之后，他进入 SpaceXAI，参与 Grok Bot 的 harness 工作。

这个履历有意思的地方在于：他先后待过的两个 harness，一个是把编程任务做到极致的（Cursor），一个是把「替人办事」作为目标的（Grok Bot）。所以他能同时提供两种经验——一种关于「什么正在被模型吃掉」，一种关于「什么反而要加回来」。官方推文把这场演讲概括成一句话：inside Grok Bot, is the agent harness dead?

三年，三个头衔，每一次都是被吃掉一层之后往上游挪一格prompt → context → harness

演讲开头给了一条很干净的线索：同一个岗位在三年里换了三次名字。这条线索本身就是「模型吃掉中间层」的实测记录。

头衔不是营销词，是「哪一层还有真问题」的指示器。当某个头衔开始被大量嘲讽，通常意味着那层活已经被模型吸收得差不多了。

「harness 已经不再贡献编程智力」The harness no longer adds coding intelligence.

这不是修辞，是列了清单的减法。Cursor 删掉的东西包括：

• 负责「把模型给的 diff 应用到代码里」的小模型——以前需要一个专门的小模型干这件脏活，现在前沿模型自己就能稳稳地输出可应用的补丁。
• 教模型「怎么探索代码库」的指令——那些「先读这个文件、再搜这个符号」的提示词，正在变成模型的默认能力。
• 教模型「怎么自查」的脚手架——跑测试、看报错、回头改，这些原本要写在系统提示里的流程，模型自己会走了。

但这里有个容易被跳过的推论：减法成立的前提，是模型自己会了。所以删掉的东西是能力的证据，不是这层东西的死亡证明。一个中间层能持续删自己，恰恰说明它还在做判断——判断哪些活已经不该由人来教了。

说 harness 要死的人，论据其实相当硬Peak harness, and the backlash

演讲专门用一节处理反方观点，而且没有敷衍。两个被引用的说法都来自一线：

• Anthropic 的 Tariq 提到，Claude Code 删掉了绝大部分系统提示词——如果最强的那家都在删，那「写提示词」这门手艺看起来确实在缩水。
• YC 的 Garry Tan 更进一步：以后重要的只有 Skills。

这些声音的共同结构是：把「曾经必须写的东西」等同于「harness 本身」。而按第一性原理拆，harness 的定义是「模型之外的全部」，所以它的边界天然会随模型滑动。争论「harness 会不会死」，其实是在争论一个定义，而不是一个事实。

真正值得问的问题因此变了：在模型吃不到的地方，还剩哪些工作？这正是后半场的主题。

研究说了什么：分数在趋同，成本在拉开What the research says

演讲里最有说服力的一段不是观点，是数据。两组独立研究指向同一个结论：

这两份数据是「harness 已死」论最硬的弹药，而讲者没有反驳它们——他换了指标。

怎么读这份数据，决定了你是唱空还是继续投入

如果「harness 的价值 = 提升准确率」，那么 ±2 个百分点意味着这层东西确实该退场。但如果把视角换成工程视角，同一份数据说明的是另一件事：「分数」这个维度正在被模型吃掉，而成本、可靠性、可控性这几个维度没有。

这就是为什么他把 efficiency（效率）单独列进「模型吃不掉」的清单。两个系统 eval 分数相近，一个任务烧 2 毛、一个烧 2 块，选哪个不是模型决定的，是 harness 决定的——缓存命中率、token 使用效率、哪一步走便宜模型，全是外壳的选择。

数据飞轮：它让 harness 变强，也让它更快过时The data flywheel

飞轮的逻辑很朴素：用得越多 → 真实任务轨迹越多 → 越清楚模型需要看到什么 → 表现越好 → 用得更多。

但讲者点出了它的另一半：飞轮转得越快，说明模型吸收得越快。你今天写的最聪明的提示词，明年大概率是模型的内置能力。所以 harness 团队的日常不是「积累」，而是持续的自我否定——每半年回头审一遍，哪些东西现在该删了。

一个极端的案例：Grind Swarm

为了试长时运行 harness 的上限，Cursor 用一个叫 Grind Swarm 的 harness 从零写出了一个浏览器。这件事的看点不是「AI 能写浏览器」，而是它的代价：成本极高，而且据说把 Cursor 搞宕机过一两次。

这个案例的教训很工程化：长时任务里，harness 的瓶颈不是「够不够聪明」，而是扛不扛得住——状态会不会丢、能不能断点续跑、并发和资源会不会把自己打穿。这类问题不会随着模型变强而消失，反而会因为任务变长而放大。

在 Grok Bot 里，他们反而把提示词和护栏加了回来The harness unlocks the next frontier

这是整场演讲最有意思的反转。在 Cursor 里做减法的人，到了 Grok Bot 却在做加法：新的提示词、新的防护措施，一样样加回来。原因是任务类型变了。

• 关键网站流程——帮你订行程、填表、下单。这些流程没有 API，只有界面，且每一步都可能失败。
• 沟通——做完事要汇报，但汇报不能打扰人。什么时候发、发到哪、说多少，全是判断题。
• 动手还是先问（Acting vs asking）——最核心的一对矛盾。不问就做，容易铸成大错；什么都问，等于没帮上忙。
• 随时间学习——记住用户的习惯、偏好、上次的坑，而不是每次从零开始。

为什么这些任务需要把「旧东西」加回来？因为新任务不是靠更强的推理进入的，是靠更大的授权进入的：允许它碰你的账号、你的日程、你的钱，允许它反复来问你。授权一旦扩大，护栏就必须存在——这不是技术退步，是边界扩张的必然成本。

模型吃不掉的四件事What models can't absorb: new frontier / infra / trust / efficiency

如果整场演讲只能记一页，就是这一页。讲者把「不会被模型吸收的部分」归纳为四类，前三类是官方的章节名，第四类是他反复强调的隐性维度：

一句话总结这四件事：模型的进步把「能力」变成了商品，把「边界、基础设施、信任、经济性」留成了工程。而后者恰好都是无法被一次模型发布覆盖的东西。

六个月，九成的 Agent 工作会离开笔记本What's next for harnesses

讲者的预测很直接：六个月内，90% 的 agent 工作会离开笔记本电脑，在云端运行。

这条预测和「harness 不死」其实是同一件事的两面。任务一旦长到以「天」为单位，笔记本就是错误的执行环境：它会休眠、会断网、会被人合上。而把 agent 从本地搬到云上，本身就是一个纯粹的 harness 工程——状态怎么持久化、连接怎么恢复、权限怎么下发、成本怎么计量。

剩下那 10% 也很清楚：人在现场、需要低延迟、或数据不能出门的场景，会继续留在本地。

所以，Harness 会死吗Long live the harness

答案是：「替模型补短板」的那部分 harness 会死，而且死得很快；「替人立规矩、扛责任」的那部分不会。

这场演讲最值得带走的方法并不是某个结论，而是一种审阅习惯：把所有 harness 组件摊开，逐个问一句——这是在补模型不会的东西，还是在定义一件模型不该自己决定的事？前一类每半年清一次，后一类每半年加固一次。

来源与制作说明Sources & notes