# 精读 Cursor《Continually improving our agent harness》：一个 agent 产品团队的工程方法论全景
**作者**: 艾略特
**日期**: 2026-05-03T02:00:01.000Z
**来源**: [https://x.com/elliotchen100/status/2050757239364002193](https://x.com/elliotchen100/status/2050757239364002193)
---
> 原文：Continually improving our agent harness · Cursor作者：Stefan Heule & Jediah Katz，2026 年 4 月 30 日
前两天看了 Cursor 这篇《Continually Improving Our Agent Harness》，我觉得这篇文章写得非常好，所以在这里做一下精读解读。
如果你在做 AI agent 产品，这篇 11 分钟的博客值得逐段读。它没有讲什么"颠覆性"的新点子，但把 Cursor 在 agent harness 上的一整套工程方法论摊开来讲了——从 context 管理、线上线下评估、错误治理，到为不同模型定制 harness、支持中途切模型，再到对多 agent 未来的判断。
对国内做 agent 的团队来说，这篇文章最大的价值不是某个具体技巧，而是它告诉你**"做 agent 产品"和"做任何其它复杂软件产品"在工程方法上其实是同构的**：你需要假设、实验、指标、监控、回归告警、版本化定制——这些都是软件工程的常规武器，只不过被装上了对 LLM 的认知。
下面按原文章节做精读，并在每节末尾给一些可以落到自己产品里的引申。
## 一、什么是 "harness"，为什么它是产品的核心
文章开头给了一个精确定义：harness = 系统提示词 + 工具描述 + 对话状态 + 用户请求 的组装与管理逻辑。换句话说，它是夹在"用户"和"模型"之间那一整层工程系统——上下文怎么填、工具怎么定义、状态怎么推进、错误怎么处理，全是 harness 的事。
Cursor 团队的核心观点是：harness 和模型一起决定了 agent 的好坏。模型变强了，harness 也得跟着进化；新模型来了，harness 要为它专门调一遍。最有冲击力的一句话是——
> "We spend weeks customizing our harness to a model's strengths and quirks until the same model inside our specially tuned harness is noticeably faster, smarter, and more efficient."
同一个模型，套一个调过的 harness 和一个没调的 harness，体验上可以差出"明显更快、更聪明、更省"。这意味着对 agent 产品公司来说，harness 是真实可积累的工程壁垒，不是套壳。
## 二、Context window 的演进：从堆护栏到放手
这一节是我整篇最喜欢的部分，因为它把"context engineering"的时代变迁讲得很具体。
2024 年的 Cursor 是怎么做 context 的：模型能力还不行，所以塞了大量静态上下文+护栏：
- 每次编辑后把 lint 和类型错误回灌给 agent；
- agent 读文件时如果只读了几行，就强制改写它的请求让它读多一点；
- 限制单轮 tool call 的最大次数；
- session 开始时直接把目录结构、语义匹配的代码片段、用户附件的压缩版全塞进 context。
2026 年的 Cursor 把绝大部分这些都拆掉了。现在留下的静态上下文只剩"操作系统、git status、当前/最近查看的文件"这些"廉价但高价值"的元信息。其它都换成了dynamic context——让 agent 自己在干活的过程中按需拉取。
这件事的工程涵义很清楚：模型能力提升 → 你应该主动拆护栏，而不是死守原来的脚手架。Cursor 自己之前还专门写过一篇 dynamic context discovery 的深度文章，他们承认很多技巧已经被其它 coding agent 抄走了，但他们仍然把"给 agent 更多动态拉取上下文和与世界交互的方式"当成主战场。
对其它 agent 团队的引申：定期审视自己的 prompt 和 pipeline，问一下"这条护栏当年是为什么加的、模型现在还需要它吗"。我见过很多 prompt 里塞了大量"请你不要……""请你务必……"的负担，本质上是早期模型不靠谱时留下的疤，应该周期性地剥掉重测一遍。
## 三、评估方法论：四层指标 + 两个杀招
"good" agent 是个模糊词，Cursor 用四层指标把它逼出来：
第一层：公开 benchmark + 自家 CursorBench。离线 eval，能跑得快、能纵向对比。但他们明确说："最好的 benchmark 也只是真实使用的近似"。
第二层：线上 A/B。两个 harness 变体并行投放真实流量，看常规指标——延迟、token 效率、tool call 数量、cache 命中率。这些指标"有方向性意义但够不到核心问题"。
真正有意思的是后两个杀招——
第三层：Keep Rate。把 agent 提交的代码改动跟踪一段时间，看在固定时间间隔后还有多少留在用户的 codebase 里。改动被改回去 / 被覆盖 / 被回滚，都是质量信号。这个指标厉害在它直接量化了"agent 干的活够不够好用"——不是基于用户主观打分，是基于他们的真实行为。
第四层：用 LLM 读用户回复，做语义级满意度判断。
> "A user moving on to the next feature is a strong signal the agent did its job, while a user pasting a stack trace is a reliable signal that it didn't."
用户跳到下一个功能 = agent 干成了；用户把 stack trace 粘回来 = agent 没干成。这个洞察特别朴素，但落到工程上是把"用户后续行为的语义"作为质量信号——而判断这个语义本身又交给 LLM。这是一个很优雅的递归。
文章还分享了一个反直觉的失败实验：他们试过用更贵的模型做 context 摘要，线上发现质量提升微乎其微，不值那个成本——直接 shelve 掉。这正是有指标的好处：能放心地说"不"。
对其它 agent 团队的引申：尽早定义一个属于自己产品的 Keep Rate 类指标。客服 agent 可以是"对话结束后是否走到人工"；写作 agent 可以是"生成内容被保留的比例"；数据分析 agent 可以是"生成的查询是否被复用"。指标必须能从用户真实行为里被动捕获，不是问卷。
## 四、Tool error 治理：把 agent 当生产系统来运维
这一节读起来像一篇 SRE 文章，把"agent 工具调用错误"当成线上事故来对待。
Cursor 把 tool error 分两类：unknown（未知错误，永远是 bug，超阈值就告警）和 expected（预期错误，再分子类）：
- InvalidArguments —— 模型自己写错了参数；
- UnexpectedEnvironment —— context 里互相矛盾、模型基于错误前提调用；
- ProviderError —— 第三方 API 挂了（如 GenerateImage、WebSearch）；
- UserAborted —— 用户主动中断；
- Timeout —— 超时。
关键设计：unknown 错误用固定阈值告警；expected 错误用异常检测告警，而且基线是 per-tool × per-model 的——因为不同模型搞砸不同工具的频率不一样。
为什么这么细致？文章给了一句很值得抄的话：
> "errors remain in context, wasting tokens and causing 'context rot,' where accumulated mistakes degrade the quality of the model's subsequent decisions."
错误不会随手消失，它们留在 context 里继续污染后续推理——所谓 context rot（上下文腐烂）。所以 tool 可靠性不仅是工程洁癖，是直接影响后续每一步质量的因素。Cursor 在一次专项冲刺里把所有 tool call 的可靠性拉到了 2 个 9 甚至 3 个 9。
更有意思的工程细节：他们跑一个每周 Automation（用 Cloud Agent + 一个专门教模型怎么搜日志的 skill），自动从日志里挖新出现或最近暴增的问题，自动建/更新 ticket，再用 Cloud Agent 批量启动修复，甚至直接从 Linear 触发。他们把这套流程称为"software factory"——agent 自动维护 agent 的 harness。
对其它 agent 团队的引申：tool error 不是只看"对不对"，要看分布——什么模型在什么 tool 上出什么类型的错。基线告警比阈值告警更适合 LLM 系统，因为底层模型在升级，绝对值会漂。
## 五、Per-model 定制：harness 不该是模型无关的
这一节戳破了一个常见迷思："抽象一层让模型可换"。Cursor 说：harness 抽象层是模型无关的，但每个模型都被深度定制。
具体例子：
- OpenAI 模型训练时用 patch 格式编辑文件，Anthropic 模型用字符串替换——两边都能用对方的，但用不熟的格式会多花 reasoning token、更容易出错。所以他们给每个模型配它训练时见过的 tool 格式。
- Prompt 风格也按模型甚至按版本调。OpenAI 模型偏字面、精确指令跟随；Claude 偏直觉、对模糊指令更宽容。
- 拿到新模型早期访问时，他们从最相近的现有模型 harness 出发开始迭代——离线 eval 找模型困惑点、内部 dogfooding 发现问题、调 prompt、再测，循环到觉得能上为止。
文章还讲了一个让人印象深刻的现象，叫"context anxiety（上下文焦虑）"：某个模型在 context window 越填越满时，会开始拒活、说"这任务太大了"。他们靠 prompt 调整压住了。这个观察很值得记下来——LLM 也会有自己的"工作压力反应"，而 harness 工程师的工作之一就是识别这些行为模式并对症下药。
对其它 agent 团队的引申：抵制"做一个模型无关的 prompt 模板，所有模型共享"的诱惑。抽象边界放在调用层和数据结构层是合理的，但 prompt 文本和 tool schema 应该按模型版本独立维护。维护一份"模型 quirks 笔记"会非常有用，比如"模型 X 在 context 70%+ 时容易 hedge"、"模型 Y 在多 tool 并行时会漏一个"。
## 六、Mid-chat 切模型：一个被低估的工程难题
这一节我没在其它公司的文章里见过类似深度的讨论。当用户在对话中途切换模型，Cursor 要面对两个问题：
1. 新模型在 OOD 状态下接手对话。它要在另一个模型生成的对话历史上继续工作，而这个历史的 tool 调用形态可能跟它训练时见过的不一样。Cursor 的解法是加一段"接班指令"：告诉新模型它在中途接管，并且明确禁止它调用历史里出现过但不在自己工具集里的工具。
2. Cache miss。Prompt cache 是 provider/model 特定的，切换 = 第一轮缓存全废 = 慢且贵。Cursor 的缓解方式是切换时摘要——给新模型一个干净的总结，避免它重读全部历史。但摘要会丢细节，所以他们的官方建议是没必要别切。
3. 用 subagent 绕开。最近他们让用户可以直接指定用某个模型起一个 subagent，绕开切换问题——subagent 一开始就是新 context，没有 OOD 问题。
对其它 agent 团队的引申：如果你的产品支持多模型，"切模型"这件事的体验设计要单独考虑。最朴素的版本是不让切；中等的版本是切了之后做摘要+加接班 prompt；高级版本是引导用户在新任务前用 subagent。
## 七、未来：multi-agent 是 harness 的胜利
文章结尾给了一个明确的判断：未来的 AI 软件工程是 multi-agent 的——一个 agent 做规划、一个做快速编辑、一个做调试，各司其职。而协调这一切的能力会落在 harness 里，不在任何单个 agent 里。
这个判断对产品定位很关键。它意味着 agent 公司不是在比哪个模型套得更聪明，而是在比哪个团队的 harness——"调度系统、任务分配、工作流编排"——更成熟。
## 收尾：可以抄回去的几个动作
如果你只想从这篇文章抄走几件具体的事，我会按价值排序推荐：
1. 定义自己产品的 Keep Rate 类指标——能从用户行为被动捕获、能纵向比较、能让你拒绝看起来美好但其实没用的实验。
2. 建立 tool error 分类学和 per-model 异常基线——把 agent 当生产系统运维，而不是当 demo 调。
3. 给每个模型独立的 prompt + tool schema 维护版本——别共享，别"抽象"。
4. 搞一份 "模型 quirks 笔记"——观察到的小毛病（像 context anxiety 这种）写下来，对治方法版本化记录。
5. 周期性审视护栏——模型能力提升后，老 prompt 里的负担应该被剥掉重测，不要留作"以防万一"。
Cursor 这篇文章读完最强的感受是：他们没把 agent 工程当成一门玄学，而是当成了一门带 LLM 特异性的软件工程。如果你的团队也想长期在 agent 这件事上积累工程壁垒，这套方法论的复用价值远高于任何具体的 prompt 模板。
注意，此文章是我同 AI 共同创作
## 相关链接
- [艾略特](https://x.com/elliotchen100)
- [@elliotchen100](https://x.com/elliotchen100)
- [Continually improving our agent harness · Cursor](https://cursor.com/blog/continually-improving-agent-harness)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:00 AM · May 3, 2026](https://x.com/elliotchen100/status/2050757239364002193)
- [2,095 Views](https://x.com/elliotchen100/status/2050757239364002193/analytics)
---
*导出时间: 2026/5/3 11:50:12*