Cursor：别在任务中途切模型——《Continually improving our agent harness》精读②

2026 年 4 月，Cursor 发布了一篇关于 Agent Harness 持续改进的工程博客。前半部分讲上下文窗口的演进和评估体系，后半部分则藏着一个容易被忽视但极其关键的判断：别在任务中途换模型。

这个判断不是情感偏好，而是一系列真实工程问题的收敛结论。

一、Cursor 做 Harness 的方法论：愿景 → 假设 → 实验 → 迭代

Cursor 构建智能体框架的方式，和构建任何有野心的软件产品没有本质区别：

1. 愿景驱动：先对"理想的智能体体验"形成判断
2. 假设验证：围绕"如何更接近愿景"提出具体假设
3. 实验迭代：通过评估和真实用量中的定量/定性信号持续迭代
4. 观测基建：构建合适的在线和离线观测机制，判断改动是否真的让框架变好

这套方法论在新模型接入时尤为关键。Cursor 会花上几周时间，围绕模型的优势和怪癖定制框架，直到同一个模型在专门调优过的 harness 中，明显变得更快、更聪明、更高效。

有时会发现跃迁式提升，但更多时候是近乎执着地叠加小优化，合在一起让智能体更擅长构建软件。

这个底层逻辑比任何具体技巧都值得记住：模型能力是基础分，harness 设计是加成系数。同样是 Claude Opus 4.6，在不同 harness 下的 SWE-bench 分数可以差出 15 个百分点。

二、上下文窗口的演进：从"塞满护栏"到"按需拉取"

与大模型交互的核心在于上下文窗口。Cursor 在 2024 年末首次开发编程智能体时，模型自行选择上下文的能力还很弱，因此他们在上下文工程上投入了大量护栏：

• 每次编辑后都提供 lint 和类型错误信息
• 如果模型请求读取的行数过少，就改写它的文件读取请求
• 限制单轮最多可调用的工具数量
• 提供大量静态上下文（代码库布局、语义匹配的代码片段、压缩版的手动附加文件）

如今，这些做法大多已经淡出。

随着模型能力提升，Cursor 的策略转向：减少护栏，提供更多动态上下文，由智能体在工作过程中按需获取。静态上下文只保留最基础的信息（操作系统、git 状态、当前和最近查看的文件），其余全部改为动态拉取。

这个转变的启示很直白：不要为模型能力不足而建的脚手架，模型变强后要敢于拆掉。很多团队花了大量精力设计的复杂上下文管道，本质上是在补偿去年模型的短板。当模型进步后，这些管道从资产变成了负债。

三、评估框架：离线 + 在线，两条线缺一不可

Cursor 的评估体系分两层：

离线：CursorBench

公开基准测试，快速、标准化地了解质量水平，支持跨时间对比。但即使是最好的基准测试，也只能近似反映真实使用情况——完全依赖它们会错过重要信号。

在线：A/B 实验

同时部署两个或多个框架变体，在真实使用中对它们进行 A/B 测试。衡量指标分两类：

直接指标：延迟、token 效率、工具调用次数、缓存命中率——对判断趋势有用，但回答不了"智能体是否真的把事情做好了"。

质量指标：

• Keep Rate（保留率）：智能体提出的代码变更中，固定时间间隔后仍保留在代码库中的比例。保留率低说明用户需要手动调整，或继续迭代让智能体修复问题——即初始响应质量低。
• LLM Judge：用另一个语言模型读取用户对智能体初始输出的回应，从语义层面判断用户是否满意。用户继续下一个功能是强正信号；用户粘贴堆栈跟踪是强负信号。

这套评估体系的精妙之处在于：它不迷信 benchmark 分数，也不盲目相信用户反馈，而是用"代码是否被保留"这个硬核指标作为 north star。一个框架变体可能在 benchmark 上得分更高，但如果 Keep Rate 下降，它就不会被全面部署。

一个典型案例：Cursor 试过用更强的模型做上下文摘要，发现对智能体质量的改善微乎其微，不值得额外成本。没有这套评估体系，这个决策会被"更贵应该更好"的直觉带偏。

四、工具可靠性：预期错误 vs 未知错误

随着加入更多模型和功能，框架复杂度增加，潜在状态更多，缺陷的暴露面也更大。工具调用是最容易出现缺陷的界面。

Cursor 将错误分为两类：

预期错误：

• InvalidArguments：模型传错参数
• UnexpectedEnvironment：上下文窗口中的矛盾
• ProviderError：外部工具服务中断（GenerateImage、WebSearch 等）
• UserAborted、Timeout：用户中断或超时

未知错误：任何未被分类的错误都意味着框架中存在缺陷，按缺陷处理。

工具调用错误的影响不只是"一次失败"。失败的调用会留在上下文中，浪费 token，并导致**"上下文腐坏"**——累积的错误会降低模型后续决策的质量。有时一次失败的工具调用会让智能体卡住，或者完全失控。

这个洞察对自建 Agent 的团队同样适用：不要只关注"工具调用成功率"这个表层指标，要关注"失败调用是否残留在上下文中继续污染决策"。

五、多模型定制 Harness：同一套框架，不同方言

Cursor 支持在 Claude、GPT、Gemini 等多个模型间切换。但这不是"换引擎、其他不变"的简单操作——不同模型的行为、提示和工具接口形式各不相同。

最具体的例子是文件编辑格式：

Cursor 为不同模型定制 tool format 和 prompt，甚至在同一模型的不同版本之间也做微调。这意味着"模型切换"不只是推理引擎的替换，而是整个 harness 的重新配置。

新模型接入的流程是：

1. 从最接近的现有模型 harness 起步
2. 跑 offline eval
3. 让内部团队试用
4. 调整 prompt
5. 直到有信心推到线上

每一步都在问同一个问题：这个"模型 + harness"的组合是否比现有的好。论文里的 benchmark 分数只能给一个起点，真正回答这个问题的是自身 evaluation suite 的读数。

六、别在任务中途切模型：三个工程陷阱

这是整篇文章最值得精读的部分。

用户可能在对话中途切换模型——比如用 Claude 写完核心逻辑，改用 GPT 继续开发另一个功能。Cursor 花了大量精力支持这个功能，但结论是：除非你有明确的切换理由，否则尽量保持同一模型。

陷阱一：Out-of-Distribution 的对话历史

切换时新模型要接管旧模型生成的对话历史。对 GPT 来说，Claude 生成的 tool call 格式、 reasoning 风格、甚至错误恢复方式都是训练时没见过的分布。模型被迫处理一段"不是它写的"上下文，理解成本和出错概率都会上升。

Cursor 的缓解方案：添加 custom instructions 告知模型"你现在是在聊天中途从另一个模型手中接管对话"，并引导它避免调用那些虽然出现在对话历史中、但不属于自身工具集的工具。

陷阱二：工具集错位

不同模型使用的工具集可能不同。如果对话历史中出现过当前模型不支持的工具调用，新模型会困惑——"这个东西在我工具箱里没有啊"。

缓解方案同上：custom instructions 明确告知模型忽略历史中的不兼容工具。

陷阱三：缓存失效

缓存是提供商和模型特定的。切换模型意味着缓存完全失效，第一轮响应更慢、成本更高。

Cursor 试过一种缓解方案：切换时总结对话，给新模型一份清晰的摘要，降低 cache penalty。但这个方法在复杂任务中有一个致命弱点——summary 可能丢失重要细节。如果你已经深入处理一个涉及 20 个文件、5 轮迭代的重构任务，任何细节丢失都可能导致后续步骤偏离正确轨道。

七、更好的替代方案：Subagent 用新上下文

Cursor 推荐的替代方案是：用子智能体（subagent）。

Subagent 从一个全新的上下文窗口开始，不需要继承主对话中积累的历史包袱。Cursor 最近还为框架添加了一项能力：让用户可以直接请求用特定模型运行一个子智能体。

这意味着：

• 主对话保持同一模型，维持上下文连贯性
• 需要换模型的任务，拆成独立的 subagent，用最适合该任务的模型执行
• 完成后，subagent 的结果回到主对话，但 subagent 的内部思考过程不会污染主上下文

这不是限制用户的选择权，而是用架构设计把"模型切换"从"上下文内的操作"变成"上下文间的边界"。

八、给开发者的实操建议

如果你在用 Cursor

1. 一个复杂任务尽量保持同一模型。除非你有明确的理由（比如需要 GPT 的特定编码风格做某一段），否则不要中途切换。
2. 需要换模型时，优先考虑 subagent。让新模型在新上下文中工作，不要把它的思考过程塞进已有对话。
3. 关注 Keep Rate。如果你发现 Cursor 生成的代码你总是需要手动调整，说明当前模型/harness 组合对这个任务不是最优解——尝试换一个模型或调整 Rules。

如果你在建自己的 Agent 系统

1. 设计 harness 时假设用户会切模型，但推荐架构上阻止这种做法。给切换做技术支撑，但在产品层面引导用户用 subagent 或新建会话。
2. 为不同模型定制 tool format。不要假设"同一套 tool schema 适合所有模型"。OpenAI 和 Anthropic 在训练数据上的差异会直接体现在工具调用行为上。
3. 建立 Keep Rate 式的 north star 指标。不要只看"任务完成率"，要看"输出被保留的比例"。这才是用户是否真正满意的硬指标。
4. 敢于拆除为旧模型建的护栏。定期审视上下文工程中的"补偿性设计"——模型进步后，这些设计可能从必要变成了累赘。

九、结语：Harness 的进化方向

Cursor 这篇文章的核心判断可以浓缩为三句话：

1. 模型能力在快速商品化，竞争优势从"用最强的模型"转向"把同一模型用得最好"。
2. 多模型支持是用户选择权，不是架构最优解——切换模型的工程代价真实存在，应该用 subagent 隔离而非在对话中硬切。
3. 评估体系比任何具体技巧都重要——没有 CursorBench + Keep Rate + LLM Judge 这套观测系统，所有 harness 改进都只能凭直觉。

Cursor 能做出这些判断，不是因为它比别人更聪明，而是因为它有足够大的用户基数和足够长的观测时间。这些洞察只有在百万级真实对话数据中才能浮现。

对大多数开发者来说，这篇文章最大的价值不是"知道 Cursor 怎么做"，而是理解"为什么 Cursor 这样做"背后的工程逻辑——然后用这些逻辑审视自己的 Agent 系统设计。

参考来源：

• Cursor 官方博客 — https://cursor.com/blog/continually-improving-agent-harness
• yage.ai 精读分析 — https://yage.ai/share/cursor-agent-harness-evaluation-first-20260501.html
• juejin.cn Cursor SDK 解析 — https://juejin.cn/post/7635874903253991439
• atou.cc Cursor Harness 解读 — https://www.atou.cc/articles/continually-improving-our-agent-harness/

#深度研究 #Cursor #AgentHarness #模型切换 #多模型适配 #AI编程 #小凯