公众号名称：AI 启蒙小伙伴

作者名称：邵猛

发布时间：2026-05-06 10:29

最近 Cursor 团队发表了一篇题为 _Continually improving our agent harness_的博客。文章不长，但信息密度极高，系统性披露了他们打造 AI Coding Agents 的工程方法论。

要理解这篇文章，先要建立一个核心概念：模型只是引擎，harness 才是底盘、传动和驾驶舱。 同样一个模型，装在不同的 harness 里，表现可以差出一大截。Cursor 与 OpenAI、Anthropic 拿到的是同一份模型权重，但通过 harness 调校出来的”更快、更聪明、更省 token”的体验，是属于 Cursor 自己的工程护城河。

关于 Harness Engineering 可以参考咱们的分享：

Claude Code 架构深度解读：Agent 系统的真正护城河不在模型，而在 Harness

一文看懂 Harness Engineering：OpenAI、Anthropic 们在谈什么，OpenClaw 如何用好 Harness 变得更强？

OpenAI 和 Anthropic 对 Harness Engineering 不谋而合：从编码到驾驭 Agent，重构 AI Agent 时代软件工程范式

今天把 Cursor 团队这篇文章深入拆解，一起学习。

把 harness 当作一个独立的软件产品

Cursor 把 agent harness 当作一款独立产品来做，而不是模型的附属物。他们的工作流是典型的产品工程节奏：

先有一个关于”理想 agent 体验”的愿景
围绕愿景提出假设
用实验验证假设
用线上和离线指标判断改动是否真的更好

每当拿到新模型的早期访问权限，他们会花数周时间针对该模型的强项和怪癖深度定制 harness，直到同样的模型在 Cursor 自己调校过的 harness 里”明显更快、更聪明、更高效”。

文章在开头就放了一句反”银弹叙事”的话：真正的阶跃式突破很少，更多是强迫症式地堆叠小优化，最终让 agent 真的会写软件。 这是整篇文章的基调。

上下文窗口的演化：从”重护栏”到”动态拉取”

这一节是文章里干货最多的部分，反映了 agent 工程理念的根本性转变。

2024 年末（早期）

模型选择上下文的能力差，Cursor 加了大量护栏：

每次编辑后强制把 lint 与类型错误回灌给 agent
当 agent 读文件读得太少时，自动改写它的 read 调用
限制单回合最大工具调用数
在 session 开头塞大量静态上下文：目录结构、语义匹配代码片段、用户附加文件的压缩版本等

2026 年（现在）

这些护栏”基本都没了”。保留的静态上下文只剩极少必要项——操作系统、git 状态、当前与最近查看的文件。主体已经转向动态上下文——让 agent 自己在工作过程中按需拉取。

这个转变背后的工程哲学是：模型变强之后，过度的静态预填充反而是噪音和成本浪费。 Cursor 早前那篇 Dynamic Context Discovery 已详述具体技术，他们也观察到这套思路被其他 coding agent 广泛借鉴。

这条路径的意义其实超出 Cursor 一家——它代表了过去一年 coding agent 整体的演进方向：模型能力提升后，工程脚手架的价值不再是”替模型做决定”，而是”给模型提供合适的拉取通道”。

如何衡量 harness 的好坏：两层指标体系

这是文章方法论上最值得借鉴的部分。“harness + 模型”共同决定 agent 的好坏，但”好”本身很难定义。Cursor 用两套互补的衡量方式来逼近它。

离线评估

公开 benchmarks
自家的 CursorBench，提供跨时间的标准化对比

但 benchmark 只是真实使用的近似，单独依赖会漏掉重要信号。

线上 A/B 实验

把多个 harness 变体并排部署在真实流量上做对比。指标分两层：

易测但浅层——延迟、token 效率、工具调用次数、缓存命中率。这些方向上有用，但回答不了”agent 到底做得好不好”这个核心问题。

真正回答质量问题的两个核心指标：

Keep Rate（保留率）——agent 生成的代码在固定时间窗口后还有多少留在用户代码库里。如果用户大量手动修改或反复让 agent 修，说明初始输出质量低。
语义满意度判读——用一个 LLM 去读用户对 agent 输出的回应。“用户继续做下一个 feature”是强正信号；“用户粘贴了一个 stack trace”是强负信号。

文章给了一个具体的”反例”：他们试过用更贵的模型做上下文摘要，A/B 结果显示对 agent 质量几乎没有提升，于是搁置。好的实验体系最大的价值，是阻止你做不值得做的事。

这套 Keep Rate + 语义判读的组合，绕开了 benchmark 的天花板，直接拟合”用户是否真的满意”，值得任何做 agent 产品的团队参考。

把 harness 当作生产软件来运维

随着支持的模型与能力增多，harness 状态空间膨胀，bug 面积扩大，很多 bug 只在规模化使用下才暴露。

工具调用是其中最大的 bug 面：失败的工具调用不仅当下报错，错误还会留在上下文里浪费 token，造成 **“context rot”（上下文腐化）**——累积的错误污染模型后续决策。严重时，agent 会因一次失败的工具调用而彻底跑偏。

Cursor 对此的应对相当系统化。

错误分类体系

InvalidArguments、UnexpectedEnvironment —— 模型自身错误或上下文矛盾
ProviderError —— 外部服务（如 GenerateImage、WebSearch）故障
UserAborted、Timeout 等

分层告警策略

未知错误（unknown error）一律视作 bug，超阈值即告警
已知错误难以判定是 harness bug 还是合理行为——比如 grep 超时既可能是工具性能问题，也可能是模型查询太蠢——所以使用按工具、按模型分别建立基线的异常检测告警

按模型分桶建基线这个细节尤其重要：不同模型把工具调坏的方式与频率本来就不同，用一个总基线监控会把信号淹没。

自动化”软件工厂”

更值得注意的是工程组织层面的做法：

每周跑一个 Automation，让一个带”日志检索 skill”的 agent 自动扫描日志、识别新增或激增的问题、在 backlog 创建或更新工单
大量使用 Cloud Agents 并行修 bug，并支持从 Linear 直接触发

他们把这套流程称为**“自动化软件工厂”**，并且声称在一次专项冲刺里把意外工具错误率压低了一个数量级。

这部分的核心启示是：agent 产品的可观测性、错误分类、按模型分桶的基线监控，是把它真正运维成”生产软件”而非”demo”的关键。 大多数团队还停留在”看错误率总数”的阶段。

为不同模型深度定制 harness

Cursor 的所有 harness 抽象都是模型无关的，但每个支持的模型都被深度定制。文章给出了几个具体差异：

OpenAI 模型训练时用 patch 格式编辑文件；Anthropic 模型训练时用字符串替换。两者都可以用对方的工具，但用陌生格式会消耗更多推理 token、出更多错。所以 Cursor 给每个模型配它训练时见过的工具形态。
OpenAI 模型指令遵循更字面、更精确；Claude 更直觉、更宽容模糊指令。所以 prompt 也要按 provider、甚至按版本分别调。

新模型接入流程也很务实：从最相近的已有 harness 起步，跑离线 eval 找混乱点，团队人肉使用挑问题，针对性调 harness，迭代到满意为止。

一个有趣的模型怪癖：context anxiety

文章披露了一个平时不太会公开讲的细节——某个模型在上下文窗口逐渐填满时，会开始拒绝任务、对冲说”任务太大了”。Cursor 把这个现象命名为 **“context anxiety（上下文焦虑）”**，并通过 prompt 调整缓解了这个行为。

这类细节揭示了一个本质：harness 工程在很大程度上是在”代偿”模型的人格弱点。

中途切换模型的难题

用户在对话中途换模型，会同时引发三类问题：

新模型要在另一个模型生成的对话历史上继续工作，这历史对它是 OOD（分布外）
历史里出现了新模型工具集中没有的工具调用
缓存按 provider/model 分别构建，切换必然 cache miss，第一回合更慢更贵

Cursor 的应对：

自动切换到目标模型对应的 harness（prompts + tools）
注入”你正在中途接手另一个模型的对话”的指令
引导它不要去调历史里出现但自己工具集中没有的工具
实验过”切换时做对话摘要”以缓解 cache miss，但发现复杂任务下摘要会丢细节

最终他们的官方建议是：没特殊理由就不要中途换模型；要换，可以用 subagent。 Subagent 从全新上下文开始，反而绕开了所有上述问题。这是一个把工程难题转化为产品形态的典型案例——他们没强行做”完美的中途切换”，而是引导用户走绕路。

对未来的判断：多 agent 是 harness 工程的舞台

文章结尾给出了 Cursor 对方向的判断：

“AI 辅助软件工程的未来是多 agent 的。”

不是单个 agent 跑所有子任务，而是学会跨多个专业化 agent/subagent 分派：一个负责规划，一个负责快速编辑，一个负责调试，各司其职。

而让这套协调机制工作好，本质上是 harness 的问题——决定派谁、如何为该 agent 重塑任务上下文、如何把结果缝合进连贯工作流。

所以文章的落点是一个有点强势的结论：harness 工程的重要性只会增加，不会减少。 这其实是 Cursor 在向行业（和投资人）说明——模型会持续被商品化，但 harness 是产品差异化的长期阵地。

Cursor内部分享：AI编程智能体5条核心经验

Cursor 智能体编程最佳实践

Cursor 原文地址：https://cursor.com/blog/continually-improving-agent-harness

cover_image

Original 邵猛 AI 启蒙小伙伴

作者提示: 内容由AI生成

内容效果不满意？点此反馈

LLM 只是引擎，Harness 才是底盘：Cursor 官方首次系统披露 AI Coding Agents 工程方法论