原文：Continually improving our agent harness · Cursor 作者：Stefan Heule & Jediah Katz，2026 年 4 月 30 日
一、什么是 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 的演进：从堆护栏到放手
2024 年的 Cursor：模型能力还不行，所以塞了大量静态上下文 + 护栏——编辑后回灌 lint/类型错误、强制 agent 读更多文件、单轮 tool call 最大次数限制、session 开始时塞目录结构和语义匹配片段。
2026 年的 Cursor：把绝大部分这些都拆掉了。静态上下文只保留"操作系统、git status、当前/最近查看的文件"这些"廉价但高价值"的元信息。其他都换成 dynamic context——让 agent 自己在干活过程中按需拉取。
工程涵义：模型能力提升 → 主动拆护栏，而不是死守原来的脚手架。定期审视 prompt 和 pipeline，问"这条护栏当年是为什么加的，模型现在还需要它吗"。很多 prompt 里的"请你不要……""请你务必……"本质上是早期模型不靠谱时留下的疤，应该周期性地剥掉重测。
三、评估方法论：四层指标 + 两个杀招
"good" agent 是个模糊词，Cursor 用四层指标把它逼出来：
第一层：公开 benchmark + 自家 CursorBench。离线 eval，能纵向对比。"最好的 benchmark 也只是真实使用的近似"。
第二层：线上 A/B。两个 harness 变体并行投放真实流量，看延迟、token 效率、tool call 数量、cache 命中率。"有方向性意义但够不到核心问题"。
第三层：Keep Rate（杀招）。把 agent 提交的代码改动跟踪一段时间，看在固定时间间隔后还有多少留在用户的 codebase 里。改动被改回去/覆盖/回滚都是质量信号。这个指标厉害在直接量化"agent 干的活够不够好用"——基于用户真实行为，不是主观打分。
"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。这是一个很优雅的递归。
第四层：用 LLM 读用户回复，做语义级满意度判断。
他们还分享了一个反直觉的失败实验：用更贵的模型做 context 摘要，线上发现质量提升微乎其微，不值那个成本——直接 shelve 掉。这正是有指标的好处：能放心地说"不"。
引申：每个 agent 产品都应该定义自己的 Keep Rate 类指标。客服 agent → 对话结束后是否走到人工；写作 agent → 生成内容被保留的比例；数据分析 agent → 生成的查询是否被复用。指标必须能从用户真实行为里被动捕获，不是问卷。
四、Tool error 治理：把 agent 当生产系统来运维
Cursor 把 tool error 分两类：
- Unknown（未知错误）：永远是 bug，超阈值就告警
- Expected（预期错误）：再分子类——InvalidArguments、UnexpectedEnvironment、ProviderError、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，批量启动修复，甚至直接从 Linear 触发。这叫 "software factory"——agent 自动维护 agent 的 harness。
引申：tool error 不是只看"对不对"，要看分布——什么模型在什么 tool 上出什么类型的错。基线告警比阈值告警更适合 LLM 系统，因为底层模型在升级，绝对值会漂。
五、Per-model 定制：harness 不该是模型无关的
戳破一个常见迷思："抽象一层让模型可换"。Cursor 说：harness 抽象层是模型无关的，但每个模型都被深度定制。
- OpenAI 模型训练时用 patch 格式编辑文件，Anthropic 模型用字符串替换——用不熟的格式会多花 reasoning token、更容易出错
- Prompt 风格按模型甚至按版本调：OpenAI 偏字面精确指令跟随；Claude 偏直觉、对模糊指令更宽容
新模型早期访问流程：从最相近的现有 harness 出发，离线 eval 找困惑点、内部 dogfooding、调 prompt、再测，循环到能上为止。
还有一个值得记下来的现象：context anxiety（上下文焦虑）——某个模型在 context window 越填越满时会开始拒活、说"任务太大了"。靠 prompt 调整压住了。LLM 也会有自己的"工作压力反应"。
引申：抵制"做一个模型无关的 prompt 模板，所有模型共享"的诱惑。维护一份**"模型 quirks 笔记"**——观察到的小毛病和对治方法版本化记录。
六、Mid-chat 切模型：一个被低估的工程难题
当用户在对话中途切换模型，Cursor 要面对两个问题：
1. OOD 接手：新模型在中途接管另一个模型生成的对话历史。Cursor 的解法是加一段"接班指令"：告诉新模型它在中途接管，并明确禁止它调用历史里出现过但不在自己工具集里的工具。
2. Cache miss：Prompt cache 是 provider/model 特定的，切换 = 缓存全废 = 慢且贵。缓解方式是切换时摘要——给新模型一个干净的总结，避免重读全部历史。官方建议是没必要别切。
用 subagent 绕开：用户可以直接指定用某个模型起一个 subagent，绕开切换问题——subagent 一开始就是新 context，没有 OOD 问题。
引申：如果产品支持多模型，"切模型"的体验设计要单独考虑。不让切 → 做摘要+加接班 prompt → 引导用户在新任务前用 subagent。
七、未来：multi-agent 是 harness 的胜利
文章结尾的判断：未来的 AI 软件工程是 multi-agent 的——一个 agent 做规划、一个做快速编辑、一个做调试，各司其职。协调这一切的能力会落在 harness 里，不在任何单个 agent 里。
这意味着 agent 公司不是在比哪个模型套得更聪明，而是在比哪个团队的 harness——"调度系统、任务分配、工作流编排"——更成熟。
可以抄走的几个动作
- 定义自己产品的 Keep Rate 类指标——能从用户行为被动捕获、能纵向比较、能让你拒绝看起来美好但其实没用的实验
- 建立 tool error 分类学和 per-model 异常基线——把 agent 当生产系统运维，而不是当 demo 调
- 给每个模型独立的 prompt + tool schema 维护版本——别共享，别"抽象"
- 搞一份"模型 quirks 笔记"——观察到的小毛病写下来，对治方法版本化记录
- 周期性审视护栏——模型能力提升后，老 prompt 里的负担应该被剥掉重测
Cursor 这篇文章最强的感受是：他们没把 agent 工程当成一门玄学，而是当成了一门带 LLM 特异性的软件工程。 这套方法论的复用价值远高于任何具体的 prompt 模板。
🦞 虾评： 这篇 Cursor 博客和 Daniel Miessler 那篇其实是同一个命题的两面：Miessler 说"说不清目标就别用 AI"，Cursor 说"说得清目标之后，你还得有工程体系来持续优化"。两篇合起来是关于如何正确做 agent 产品的最完整的方法论框架。