主文把 Cursor 博客的后半部分拆解得很清楚，这里补充几个值得深挖的角度。
---
一、用户为什么想切模型？四种深层动机
Cursor 说"别在任务中途切模型"，但用户切模型的冲动从哪来？理解了动机，才能设计更好的产品策略。
动机一：对当前输出的即时不满 "这个模型写这段代码风格不对，换另一个试试。"这是最常见也最不合理的切模型理由——任务还没完成就换将，等于让新模型接手一段它没参与思考的半成品。
动机二：成本焦虑 "Claude Opus 太贵了，后半段用 GPT 省钱。"这是合理的经济计算，但 Cursor 的解决方式不是阻止切换，而是提供更优的替代路径（subagent）。用 subagent 运行轻量模型处理子任务，成本同样可控，但避免了上下文污染。
动机三：能力迷信 "听说 GPT 在某某场景特别强，换过去试试。"社区里的"某某模型擅长某某任务"的说法大多基于小样本轶事，不具备统计显著性。Cursor 的评估体系（Keep Rate）可以帮用户做更理性的判断：如果当前模型的 Keep Rate 已经很高，切换的预期收益可能被工程代价抵消。
动机四：惯性操作 "换个模型刷新一下，就像重启电脑一样。"这完全是人类行为模式的投射，和技术无关。Cursor 的应对是 clear conversation 按钮，让用户能在同一模型内"重启"，而非跨模型切换。
---
二、缓存失效的代价：不只是慢一点，而是贵很多
Cursor 提到"切换会导致缓存未命中"，但缓存失效的经济代价常被低估。
以 Claude API 为例，prompt caching 的价格是标准输入的 1/10。一个已经积累了 50K tokens 上下文的复杂任务，如果缓存命中，续写的成本几乎是免费的；如果切换模型导致缓存失效，同样的 50K tokens 需要按全价重新输入。
在重度使用场景下（比如一天运行 100 次复杂 Agent 会话），缓存策略的设计差异可能带来 10 倍以上的成本差距。Cursor 用"切换时总结对话"来缓解，但 summary 本身也需要 token 成本——而且如果 summary 丢失了关键细节，后续步骤的 token 消耗反而会增加（因为模型需要更多轮次来恢复正确方向）。
这个账算起来：切换模型的隐性成本 = 缓存失效的重复输入成本 + summary 的生成成本 + 因信息丢失导致的额外迭代成本。三者叠加，可能比"坚持用原模型"贵得多。
---
三、维护多套 tool format 的工程负担
Cursor 为不同模型定制 tool format（OpenAI 用 patch-based，Anthropic 用 string replacement），这听上去很合理，但维护成本是真实的。
每新增一个模型支持，就需要： 1. 分析该模型在训练数据中的工具调用偏好 2. 设计对应的 tool schema 和 prompt 模板 3. 跑 offline eval 验证格式兼容性 4. 处理同一模型不同版本之间的行为漂移 5. 维护文档和示例
当支持的模型数量从 3 个增加到 10 个，这个维护矩阵的复杂度不是线性增长，而是接近指数级。Cursor 目前支持 Claude、GPT、Gemini，未来如果加入 Grok、DeepSeek、Llama 等开源模型，tool format 的多样性会进一步膨胀。
一个潜在的缓解方向是：让模型自己适配统一的 tool schema，而不是为每个模型定制 schema。但 Cursor 的实践表明，训练数据中的格式偏好是顽固的——强行统一反而会降低模型表现。这个矛盾短期内没有完美解。
---
四、"拆除旧护栏"的团队动力学
Cursor 提到"随着模型能力提升，敢于拆除为旧模型建的护栏"。这个建议知易行难。
在大多数工程团队中，上下文工程的复杂管道是花了数月时间建立起来的。团队成员对这些管道有情感投入（"这是我设计的"），也有功能依赖（"没有它模型会出错"）。当模型进步后，要论证"这些管道现在不需要了"需要大量实验数据——而这正是许多团队缺少的。
Cursor 能做这个决策，是因为它有 CursorBench + Keep Rate + LLM Judge 的完整评估体系。没有这套系统，"拆还是不拆"的争论会永远停留在主观判断层面。
对自建 Agent 的团队来说，这是一个警示：在设计补偿性机制时，应该同时设计"机制退役条件"——明确写下"当模型达到某某指标时，这个机制可以移除"。否则，临时补丁会变成永久架构。
---
五、Keep Rate 的盲区
Keep Rate 是一个聪明的指标，但它有盲区。
盲区一：用户懒 如果用户只是接受了 Agent 的输出但从不 review，Keep Rate 会虚高。Cursor 用 LLM Judge 来补充——读取用户的后续行为来判断是否真正满意。
盲区二：短期保留 vs 长期质量 代码在 1 小时后还在代码库里，不代表 1 周后不会被重构掉。Keep Rate 的"固定时间间隔"设计（比如 24 小时）是一个工程折中，而非质量真理。
盲区三：删除也是正确的 有时用户删掉 Agent 生成的代码，不是因为 Agent 做错了，而是因为需求变了。Keep Rate 无法区分"质量差导致的删除"和"需求变更导致的删除"。
这些盲区说明：Keep Rate 作为 north star 指标是合理的，但需要配套其他信号来校准。Cursor 的 LLM Judge 就是用来做这件事的。
---
六、一个开放追问
Cursor 说"未来软件开发会走向多 Agent 编排"。如果多 Agent 是方向，那么"多 Agent 每个用不同模型"和"多 Agent 统一用一个模型"哪个更好？
Cursor 的当前答案是：subagent 可以指定模型，但主对话保持同一模型。这是一种"局部灵活、全局稳定"的策略。
但这里有一个更深的问题：当 Agent 编排变得复杂（比如 5 个 subagent 并行工作，每个用不同模型），主对话的上下文如何整合这些异构输出？不同模型的输出风格、错误模式、假设前提都不一致，主模型能否有效消化？
这个问题 Cursor 还没有给出完整答案。也许下一个版本的博客会讲这个。
---
#Cursor #AgentHarness #多模型适配 #深度研究 #千寻