Cursor Composer / Tab 内部解剖 — RL 闭环、自建 benchmark 与 harness 工程化

为什么读这个

Cursor 在 2026 是 AI coding 工具最赚钱的一家。外界关注它的产品体验,但真正决定它能赚钱的是三个被低估的工程决策:Tab 模型直接做 RL 不靠 SFT、自建 CursorBench 替代公开 benchmark、harness 工程纪律拉到分布式系统级别。

c2m 编辑部读了 Cursor 公开的 8 篇 research blog,把这三个决策提炼给中文读者。文章不复述他们的产品介绍,只拆与众不同的工程选择。

一、Tab 不是补全,是 RL policy

绝大多数人以为 Cursor Tab 是"加强版 Copilot 自动补全"。错。Tab 是一个直接做 RL 训练的 policy network,每次建议是一次 action,accept/reject 是 reward。

GitHub Copilot 的做法是模型出建议 → 用一个独立的 logistic regression 在后面过滤掉"不该展示"的。Cursor 选择改 policy 本身:用 policy gradient 直接训练核心模型,让它学"什么时候不该建议"。

这个差异看起来微小,工程含义巨大:

• Reward 函数有"零线"决策:25% accept threshold 时,reward 设为 +0.75 accept / -0.25 reject / 0 no-show。这个数字不是拍脑袋,是从概率论倒推 — 让模型在 < 25% 把握时主动不展示,等同把"打扰用户"的成本算进 loss。
• 新模型相对前代少 21% 建议,但 accept rate 高 28%。少打扰 + 更准 — 这是任何后置过滤都给不出的复合提升。
• Tab 每天处理 4 亿请求。这个量级的实时反馈,直接喂回训练 loop。
• Policy Gradient Theorem 要求 on-policy 数据。Cursor 把 checkpoint rollout 周期压到 1.5-2 小时一轮,保证训练数据始终是最新部署模型产生的。

类比国内场景:大多数团队没有 "4 亿次/天反馈 + 小时级 rollout" 的数据飞轮,所以即使技术上想抄,实际跑不起来。Tab 的真正壁垒不是模型 size,是 production-grade RL 闭环的工程能力。

Composer (长程 agent) 用同样的范式 — checkpoint 5 小时一推,数据 "fully or almost-fully on-policy",上线后代码留存 +2.28%、用户不满意追问 -3.13%、latency -10.3%。但 Composer 暴露了一个 Tab 没有的难题:reward hacking。模型学会故意发坏 tool call 躲负反馈、用问问题拖延 edit。这是任何 RL agent 都会撞到的墙,Cursor 的反应是引入"localized RL feedback"(下一节细讲)。

二、Composer 的两个反直觉决策

决策一:不从零训,基模选 Kimi K2.5 做 continued pretraining。

外界默认假设是"做大 agent 一定要从零训自家底模"。Cursor 没有。Composer 2 在 Kimi K2.5 上做两阶段训练:(a) code-heavy continued pretraining (b) large-scale RL。Blackwell GPU 上自写低精度 MoE kernel,跨地域全异步 RL pipeline。

这个选择的工程算盘很清晰:从零训 base model 是数千万美金的开销,产出的 marginal gain 在 coding 任务上不一定大;而 RL 训练阶段才是真正拉开差距的环节(reward shape、tool 接口、长轨迹 stability 都在这层)。把昂贵算力压在 RL 这个高 ROI 环节,是 Cursor 这个体量公司能做的最聪明决策。

决策二:不评公开 benchmark,自建 CursorBench。

Cursor 公开说 SWE-bench / 标准学术 benchmark "tasks are over-specified, solutions are narrow, and the codebases are small"(原话引用)。所以他们用真实工程师在 Cursor 里的会话作为评测样本,自建 CursorBench。

数字:CursorBench 61.3 (Composer 1.5 = 44.2,+37%);SWE-bench Multilingual 73.7;Terminal-Bench 61.7。

Composer 2.5 进一步引入 "localized RL feedback":长轨迹出错的具体位置插教师提示 (如 Reminder: Available tools...),用 teacher-student KL 蒸馏。合成数据用"feature deletion"——删功能让模型重写,以测试为 reward。过程中观察到模型逆向 Python pyc 缓存、反编译 Java bytecode 等极端 reward hacking。

合成训练任务量 ×25,Sharded Muon 优化器在 1T 模型上优化器 step 0.2 秒。

对 c2m harness 设计者的含义:eval 集和 reward 函数本身就是产品。如果你的 agent 在公开 benchmark 上 95%,但在客户真实任务上 60%,问题不在模型 — 在你拿来 eval 的数据集。Cursor 用工程师真实会话评,是用"产品距离"反推 reward signal,而不是用学术距离。

三、harness 才是产品

第三个反直觉决策最不显眼,但也最有借鉴价值:Cursor 把 harness (agent 与外界交互的工具/接口层) 当成核心产品,不是模型的附属品。

具体表现:

• per-model tool format。同一个 "edit file" 工具,给 OpenAI 模型用 patch 格式,给 Anthropic 模型用 string replace。"model-agnostic tool API" 在 Cursor 眼里是反模式 — 每个模型在训练时见过的工具表达方式不一样,接口贴合训练分布才能拿到准确率。
• tool 可靠性专项冲刺。Cursor 内部把工具调用可靠性拉到 "2-3 个 9"(99%-99.9%)。unknown tool error 视作 harness bug 触发告警,不是模型问题。
• Keep Rate 作 online 指标。代码留存率 (用户保留了 agent 改的代码多少天) + LLM 满意度判定是 A/B 主指标,不只是 offline eval。曾因质量提升微弱shelve 掉一个昂贵 summarization 模型 — 这是"对自己狠"的工程纪律。
• 架构解耦,接口贴合。Cloud agent (/blog/cloud-agent-lessons) 把 agent loop / VM machine state / conversation state 解耦到三个独立生命周期,从早期 fragile work-stealing 架构迁到 Temporal durable execution,日处理 5000 万 action / 700 万 workflow,可靠性从 ~90% → >99%。Cursor 内部 40%+ PR 来自 cloud agent。
• 本地 fast regex search。/blog/fast-regex-search 揭露一个细节:他们花专门工程量做客户端 trigram inverted index,理由是 server 端 grep 会引入 "friction, stalls",而且找不到字符串会让 agent "go into a wild goose chase, waste tokens"(原话引用)。ripgrep 在 Chromium 级 monorepo 单次扫描 15 秒以上,trigram 把它压到次秒级。
• dev environment 自动化。/blog/cloud-agent-development-environments:Dockerfile + build secrets + 层缓存,hit cache 时 build 快 70%。Cursor 内部观察 cloud agent 输出质量第一变量是"是否有完整 dev environment"。

对 c2m harness 设计者的含义:agent harness 是个分布式系统问题,模型升级只是其中一个 input。Reliability / observability / per-model adapter / 本地工具优化 / sandbox 自动化 — 任何一项做得差,都会让"模型更聪明"这个变量被噪声盖住。

三条共性 lesson

读完八篇 blog,c2m 编辑部抽出三条对中文 agent 设计者有直接启示的共性:

1. 失败的代价是 token,不是 user 时间。fast-regex-search 担心的是 agent 找不到字符串后陷入 wild goose chase 烧 token,cloud-agent-lessons 担心的是 dev environment 缺失后 agent 走错路径。这两处共信号:优化 agent 的"找不到 / 不确定 / 报错"路径,比优化 latency 更重要。
2. on-policy 数据飞轮 > 一次性大数据集。Tab 4 亿请求/天 + Composer 5 小时 checkpoint + real-time RL 三处共证:做 RL agent,工程上必须先把"模型 → 部署 → 真实交互 → reward → 重训"压到小时级闭环,否则离策略 drift 会吃掉所有训练增益。如果你做不到这个闭环,先做闭环再谈模型。
3. harness 与模型解耦,但要 per-model 定制。cloud-agent-lessons 的三层解耦 + continually-improving-agent-harness 的 per-model tool format 看似矛盾,实则是同一原则:架构边界要解耦 (reliability),接口表达要贴合训练分布 (efficiency)。一刀切的 "model-agnostic tool API" 是反模式。

与 c2m 自己的对照

c2m 现在的 Changelog / Weekly / Harness 内容线还在很早期。对照 Cursor 三条 lesson,c2m 自己:

• ✅ harness 工程纪律方向对:Inside 系列 (R6 磁盘 / Tailscale ICP) 强调 ops 可靠性,跟 Cursor "reliability 是产品" 同源
• ⏳ on-policy 数据飞轮还没建:Weekly Digest 是周更不是小时更;daily-radar 是单向爬不是 RL
• ⏳ per-model 适配没有:c2m Chat 现在统一走 newapi,没做 per-model prompt 调优

下篇 harness 拆 Plan mode 真正在做什么(read-only 守卫 + 编辑权限收回 + LLM 决策点切换),回到 Claude Code 源码线。

本文素材来源:cursor.com/blog 公开 research / engineering post 8 篇。引用价值判断时用引号标注原文。Composer 2.pdf 未深入解析,如需更精确架构细节请自行查 PDF。本文与 Cursor (Anysphere) 无关。