Cursor核心成员访谈：我们对AI编程的几个关键判断

推荐语

深入解析AI编程领域的最新进展和挑战。

核心内容：
1. AI编程Agent面临的关键问题和挑战
2. 编程模型瓶颈与反馈机制设计
3. 强化学习在编程领域的应用与难点

杨芳贤

53A创始人/腾讯云(TVP)最具价值专家

这两天，我听了一期 Cursor 团队的播客，信息量非常密集，也非常值得一听。

团队几位核心成员围绕 “AI 编程” 这个主题，聊了很多当前他们在产品和研究中的一线观察和思考，涵盖范围从模型训练、工具链设计，到反馈机制、记忆系统、长上下文的处理方式等等，几乎把现在 AI 编程 Agent 遇到的关键问题都过了一遍。

对我来说，这期最有启发的几个点，一个是他们提到目前编程模型的瓶颈不只是模型能力本身，而是 “反馈机制” 设计得还不够好。比如过去经常提到 Evals 测试评估，但如果没有真实有效的反馈信号（比如用户有没有保留这段代码、有没有采纳模型建议），模型其实很难真正学会什么是 “好” 的修改。

另一个是他们对 RL在编程里的应用方式也有很多新看法。跟数学或写作不同，编程任务往往涉及多轮工具调用和代码迭代，reward（奖励信号）很稀疏、很难定义。你不能只看 “测试过没过”，而是要综合考虑代码结构、可读性、是否优雅，甚至有没有 “投机取巧” 地通过测试。

整期对话虽然涉及不少技术细节，比如 GRPO、NSA 注意力、文档级上下文缓存等，但讲得非常透彻，也很坦率，看完之后基本能理清目前行业在 AI 编程上的关键挑战和可能的演进方向。

这场对话让我们得以一窥 Cursor 团队在 AI 编程领域的前沿探索和深刻思考。

上图中的嘉宾，从左到右分别是：Sualeh Asif 联合创始人兼 CPO、Charlie Snell 研究员、Aman Sanger 联合创始人、Federico Cassano 研究员、Jacob Jackson 研究员。

下面是我和团队同学借助工具完成的全文翻译，希望也能带给你一些启发。

Federico Cassano（研究员）：首先，每一步都能写各种不同的语句、调用不同的工具。拿数学举例，推理在数学中效果很好，因为最后的答案很短。推理过程可以有很多步骤，但最后的答案就那几步。而编程则不一样，推理的内容本身就包含在最终的答案里。

Charlie Snell（研究员）：对，还有就是，为了得到答案，你需要调用多个工具。所以不像数学那样 “生成推理过程、生成答案、获得奖励” 就结束了。编程要 “生成一些代码，调用一些工具，收到工具的反馈”，有时候还要多次迭代。也就是说，RL 的过程变成了多步骤的工具调用和优化。

Jacob Jackson（研究员）：而且对我们来说，RL 特别有意思的地方在于，模型给出的结果，很多时候我们没办法判断它到底有没有解决用户的问题、满足用户的需求。比如数学或者编程题，你可以有一个标准答案来对比。但有些场景，用户不会明确告诉我们 “结果对不对”。

Aman Sanger（联合创始人）：你觉得像写作这种领域会怎样？是不是根本就不会用 RL，或者只能靠基础模型预训练？你觉得 RL 有可能让写作模型更好吗？

Jacob Jackson（研究员）：现在大模型的后训练，通常会让模型写出来的东西比较死板和不自然。但我觉得这不是模型本身的限制，只是因为训练时就是这么教它的。

Federico Cassano（研究员）：对啊，为什么不能训练模型去预测 “下一章节”，而不是每次只预测下一个词？你想改变学习方式，让模型开始预测整个片段。比如给它一本书的当前章节，让它预测接下来整章的内容，然后用用某种相似性指标来评估生成的章节和真实章节有多像。

Aman Sanger（联合创始人）：这其实是把原来那种让模型只预测 “下一个词” 的写作方式，改成让模型生成一整章内容，然后通过比较模型生成的章节和真实章节的相似程度，来给模型打分。

Charlie Snell（研究员）：最好是用 “语义上的奖励”。

Federico Cassano（研究员）：因为现在的 “下一个词预测” 目标，并不能完全表达我们真正想要的东西——我们其实想让模型能生成整段高质量的内容。

Aman Sanger（联合创始人）：其实这里面有两点：一是让模型生成下一个词前能用更多的算力 “想一想”；二是，它不一定要精确预测下一个词，而是要能生成和目标章节类似的整段内容。

Jacob Jackson（研究员）：写作难的地方在于，最终内容好不好，很大程度是 “品味” 的问题，而不是像编程那样有标准答案。编程就是能不能跑，写作就算是很有经验的人，也会对好坏有不同看法。

Aman Sanger（联合创始人）：但你不觉得编程其实也有 “品味” 这种因素吗？比如通过测试之后，后面想再进一步优化，可能就很难了。

Jacob Jackson（研究员）：是的，代码质量确实是个难题。

Federico Cassano（研究员）：但 “通过测试” 有时候也不靠谱，因为有的模型只是靠 “投机取巧” 让测试通过，真正做的事和任务完全没关系。也就是说，模型可能用一些完全不相关的办法，通过测试，而且奖励还很高。

Aman Sanger（联合创始人）：这其实就看你的测试设计得好不好。

Jacob Jackson（研究员）：关于代码质量，其实我们希望的是 “优雅的代码”，不要冗余，最好越短越好，能最简洁地描述。像数学一样，最漂亮的证明，通常也是最简洁的。虽然不是完全一样，但有相似的地方。

Aman Sanger（联合创始人）：在优化代码时，你是不是更愿意精简，把不必要的部分删掉，让代码更简洁？

Jacob Jackson（研究员）：如果你能做一次代码合并，把不必要的代码删掉，一下子减少了 100 行，而且还没有影响原来的功能，我会觉得非常棒。

Aman Sanger（联合创始人）：对，是这样。

Aman Sanger（联合创始人）：你们都有哪些想法？用测试作为奖励，有哪些优点？

Charlie Snell（研究员）：测试其实很接近 “标准答案”，就像刚才说的，测试覆盖面不够时，模型可能 “钻空子”，并没有真正解决问题。但如果测试做得好，就能作为判断代码是否工作的接近标准信号，你可以用 RL 针对这个信号优化很久，模型就能学到有趣的行为。

但并不是所有东西都能用测试来衡量，所以我们可能还得考虑别的奖励方式。比如，你可以把用户真正做出的代码修改当作模型训练时的反馈信号。一项新功能可能有多种实现方法，这不是绝对标准，但可以作为验证模型输出的辅助信息。

Aman Sanger（联合创始人）：那测试做奖励的另一个问题是：奖励太稀疏。你可能跑很多次，只有一次通过，奖励只有 “通过/没通过” 这种一刀切的反馈。

Charlie Snell（研究员）：是的，这会让训练成本很高。即使你有很多服务器，让模型多跑几遍，最终获得有用反馈的机会还是很少，这样训练既花时间又花钱

Federico Cassano（研究员）：因为模型其实看不到 “奖励” 本身，它拿到的是 “优势（advantage）”，也就是和同一批其他采样相比的相对奖励。

Aman Sanger（联合创始人）：那有意思的是，如果你对整个 PR 跑测试，反馈很稀疏、难度很高，模型现在很难通过全部测试。如果能把 PR 拆成更小的部分，各自跑测试，能更快拿到反馈，这是不是就是一种改进？

Charlie Snell（研究员）：是的，我觉得应该是这样。就是说，如果任务太难，模型每采样 1000 次才对一次，那奖励信号就会特别稀疏。如果能达到 1/100 或者更高的成功率，那就还可以。但如果是 1/1000 这种情况，就得考虑把任务进一步拆分。

Aman Sanger（联合创始人）：你觉得我们现在是不是正处在这种 “奖励太稀疏” 的阶段？

Jacob Jackson（研究员）：是的，在有些情况下，确实需要通过把任务拆分成更小的部分，让模型每一部分都做对，这样才能减少奖励稀疏的问题。

从本质上讲，我们想要的是模型能做出跟 “标准答案” 功能完全一样、而且尽量简洁的代码修改。难点在于，这本身就是一个很难的目标，甚至连判断一个候选答案是否达标，都几乎和完成整个任务一样难。

所以这很难做到，但如果有办法朝这个方向努力，也许会更好。

而 Claude 模型可能更倾向于用 “搜索” 和 “编辑”。你们觉得还有哪些有趣的工具，是除了这些传统工具之外，可以用来给模型配备的？

Aman Sanger（联合创始人）：我觉得其实完全可以做得比 “核心工具集” 更好。终端之所以有优势，就是因为它很简单，你不需要给代理搞一套复杂的运行环境，只要让它能访问 shell（命令行）就什么都能做。

简单其实是最大的优势。举个例子，比如 Linter（代码检查工具）能提供很多有用的信号，但用起来挺麻烦的，因为你得让语言服务器跑起来，而让语言服务器在任意代码上跑其实挺难的。

不过像 Cursor 这种编辑器就很有意思，因为它自带扩展和语言服务器，用户愿意自己去配置，这样你就能拿到 Linter 的信号。我们还有语义搜索之类的工具。我个人觉得语义搜索不一定能比 “grep 多跳搜索” 查代码查得更多，但它能查得更快、更省资源，更高效。

Sualeh Asif（CPO）：所以可能问题是，你到底想提高工具质量，还是更看重简单易用？你可以选极简的工具，比如终端。也可以慢慢提高工具的 “档次”。你们怎么看这种权衡？

Federico Cassano（研究员）：其实有个很有意思的做法，就是可以用一些工具来帮模型 “管理” 自己的行为。比如我们发现，很多推理类模型很容易陷入过度思考，哪怕有时候根本不用复杂推理，它也会硬要多想一会儿。

所以可以给模型加一个 “思考工具”，让模型自己意识到当前任务到底需不需要推理，如果需要，它再调用这个工具。

Aman Sanger（联合创始人）：是的，我一直觉得推理模型和代理工具的互动挺奇怪的。拿 o3 来说，可能是我用得还不够多，但我发现它经常在你刚发完消息，还没收到任何内容时，就已经开始 “思考” 并调用工具了。

Sualeh Asif（CPO）：你的意思是，你觉得模型应该在每次调用工具之后再去 “思考”？

Aman Sanger（联合创始人）：不是每次都要。其实，大家一开始训练推理模型的理由是什么？我觉得，o1 最早的版本就是训练做算法竞赛和数学题。

这样做的想法就是最后给出一个漂亮的答案，不管是展示给用户，还是交给系统验证。之前需要先花大量 Token 让模型自己 “思考”。

我很好奇，Agent 执行了一连串操作后，最后给用户展示的内容到底要不要单独验证？有时候用户只是想让模型修改一下代码，比如编辑文件，就是用工具直接改了就行。那这样是不是根本就不需要 “推理过程”，只要模型直接编辑就可以，训练时也不用单独加什么推理过程。

Jacob Jackson（研究员）：我们现在在考虑的另一个很有意思的工具，就是去分析 PR（Pull Request）和团队成员最近都在做什么。

你可以把模型想成一个很能干的工程师，但他刚入职第三天，前两天都在快速了解代码库，第三天就要上手干活了。如果在这种情况下，你肯定会先看看同事们都在改哪些代码、为什么这么改。

目前模型主要还是看大块的代码，然后去找相关内容，这和训练数据来源其实是对应的，也是很重要的一部分。但如果能让模型去看 PR，也许会有新收获。

Sualeh Asif（CPO）：你觉得代码和长上下文之间的关系怎么样？比如现在有种说法，长上下文很重要。像 Sonnet、GPT4 这些模型，如果只能用 8K Tokens 就有点太少了，可能至少得有 50K、60K Tokens 的上下文才行。你觉得上下文长度越长，RL 就会越好吗？这两者的关系怎么理解？

Jacob Jackson（研究员）：目前的趋势确实是上下文越来越长，注意力机制对长上下文的利用很强大。但这样成本也越来越高。技术上，一个很有意思的方向是怎么在长上下文下控制成本，比如怎么让缓存的上下文在多轮对话里复用。尤其是最近这些新模型能力越来越强，但如果不用巧办法控制，上下文的花费会很高。

在看专业代码库的时候，和你要做的事相关的上下文信息量非常大。代码这点挺特别的。比如 ChatGPT、Claude 这种模型，用户的上下文其实很少，最多就是一个简单问题，最多也就一百个 Token。

也就是说，模型平时主要的任务是提前把人类知识学到脑子里，遇到问题直接答出来，而不是专门为了处理超长输入做复杂设计，因为普通用户用不到那么长的输入。

Sualeh Asif（CPO）：你觉得我们以后需要 100 万、1000 万、还是 1 亿的 Token 上下文？

Jacob Jackson（研究员）：我觉得肯定是越长越好，但也有 “边际收益递减” 的问题。现在大家普遍的做法是，等模型需要用到某些信息时，才把这些相关内容 “检索” 出来给它用，而不是一开始就把所有内容都塞进去。

这不是唯一的方法，但也挺好用的。未来比较合理的方向可能是多种机制结合，比如有一种机制能一次性消化 1 亿 Token，虽然每个 Token 得到的信息不多，但能大致了解代码库。然后等到你真的要做某件事时，模型能记得哪些内容相关，再去重点刷新记忆，这种方式可能最有前景。

Aman Sanger（联合创始人）：NSA（注意力机制）确实很优雅。

Sualeh Asif（CPO）：对吧？你怎么看 NSA？

Aman Sanger（联合创始人）：其实说优雅可能也不太准确。

Sualeh Asif（CPO）：比如 DeepSeek 的注意力机制已经公开发表了。

Aman Sanger（联合创始人）：希望他们下一个模型能用上。这种注意力机制的可扩展性很好，据说效果比传统注意力更好。

核心原理是把注意力分成三部分。一部分是滑动窗口注意力，主要关注最近发生的内容，比如最近 4000 个 Tokens。剩下两部分则是分块注意力。

它会每隔一段 Token，把那段内容作为一个 “块” 的 key 和 value 保存下来，然后 query 会去关注这些块。之后再从这些块里选出最相关的前 K 个，最后对这些块做全局注意力。我觉得这种做法很酷，因为它确实能很好地在很长的上下文里做检索。

Sualeh Asif（CPO）：你们怎么看这种，比如我们内部其实更关注 “文件级别的注意力”？

Aman Sanger（联合创始人）：你怎么看？

Jacob Jackson（研究员）：我觉得这其实是把 Mixture-of-Experts（MoE，专家混合模型）的思路用在了注意力上。我们有一套在梯度下降训练中引入稀疏性的 “套路”：就是先算出值，然后做 top-K，再对选出来的做 Softmax。MoE 就是这么训练的。

这样一来，虽然不是所有地方都有梯度，但这种稀疏机制能让 “门控权重” 更关注和当前样本最相关的 “专家”，在 NSA 里就是关注最相关的上下文块。所以本质上就是把 MoE 的方法扩展到了别的领域。

Sualeh Asif（CPO）：你还有其他喜欢的注意力机制吗？

Jacob Jackson（研究员）：其实长上下文机制最大的问题是如何判断基线效果，因为各种机制多多少少都有效，比如稀疏注意力，有的头关注局部，有的关注全局，结果就是稍微慢一点、但快一点，或表现好一点。所以评测一定要非常严谨。我也没有特别想推荐的论文。

Aman Sanger（联合创始人）：这很有意思，现在方向越来越偏向 “不是把所有信息都放在模型里”，而是模型学会用检索工具（比如语义搜索）来查找信息。

Federico Cassano（研究员）：“记忆工具” 其实包含两步。第一步是 “我要把某次交互存成记忆”；第二步是 “我需要的时候把记忆取出来”。

第二步很容易教会模型，只要取出来真的有帮助就给奖励。但 “存储记忆” 复杂多了，因为奖励要看后面一系列动作的表现，而不是当前这一步。所以训练时得做很多完全不同情境下的采样，才能给到信号。

Charlie Snell（研究员）：对，就是你训练时既要让模型学会 “写入记忆”，又要做后续采样，去 “读取记忆” 并根据效果回传奖励。

Aman Sanger（联合创始人）：其实如果只用“ 非情感” 方式训练，生成和检索记忆会简单很多。你之前也说过，现在更多是靠各种规则和评测方式反复试，看看哪种效果好。

Sualeh Asif（CPO）：那你们觉得应该怎么评估 “记忆” 效果？

Aman Sanger（联合创始人）：对，你有啥想法？还是 Luke 提出来的？

Jacob Jackson（研究员）：我觉得就是 Luke 提出来的，因为像 Federico Cassano 说的，记忆存储机制很难直接反向传播，最好的办法就是做个基准测试。

比如拿 500 个 Agent 该做的任务，看它们做得怎么样，然后用不同规则、启发式方法或提示词实验，什么时候存记忆、什么时候忘记，最后直接比较效果。数量少不能做反向传播，不然很容易学会“奖励作弊”，但规则法能帮你找到最优方案。

Aman Sanger（联合创始人）：我也挺好奇 “短期记忆” 会不会一直有用，还是像 Jacob Jackson 说的，最后会变成长上下文机制，模型能看到你所有历史对话并自动 “强化记忆”。

Sualeh Asif（CPO）：你们怎么看 “历史对话” 比 “历史 PR（代码合并请求）” 更重要？

Aman Sanger（联合创始人）：其实是两回事。历史对话有一个特点：你能看到自己操作后环境怎么变，比如代码格式化工具怎么反馈、Linter 有什么反应。这些在 PR 里看不到，PR 更像是单纯的演示。我觉得两者各有用处。

Charlie Snell（研究员）：其实通过历史 PR 也能个性化，比如在某个代码库里，你能发现大家改动的风格、顺序，比如先改哪个文件，再改哪个文件，模型可以学会这种习惯。

Aman Sanger（联合创始人）：最酷的是，现在其实有不少人试过，KV 不一定要都放在 GPU 上，只要把运算和加载交错，几乎不会变慢，每次用到注意力时再加载到 GPU 就行。

Federico Cassano（研究员）：比如你在第 0 层开始，就可以从 CPU 加载你第 1 层需要的 K 值。只有用到的时候才要放到 GPU 上，完全不用全程占用 GPU 内存。

Aman Sanger（联合创始人）：不过，这也只能支持到一百万 Token 这种级别吧。你还是得为 “二次方” 的计算成本买单，不能完全靠大内存来解决。

Federico Cassano（研究员）：但并行度高的话，理论上会便宜 72 倍，只要注意力头分配得合理。

Aman Sanger（联合创始人）：是的，会便宜 72 倍，但 n² 的暴涨还在，可能还需要各种常数优化，比如滑动窗口、分块、NS 状态等，这些都是大常数优化，但本质还是常数项。

Federico Cassano（研究员）：我们非常喜欢 “文档级注意力”。

Aman Sanger（联合创始人）：我们叫它 “鱿鱼注意力”，就像鱿鱼的每根触手是一份文档。

Jacob Jackson（研究员）：这是为什么？

Aman Sanger（联合创始人）：你怎么看？

Jacob Jackson（研究员）：我也不知道。

Aman Sanger（联合创始人）：我也不知道名字是谁起的，好像不像 Lucas 会起的名字。“好” 的注意力机制就是让每个文档都能独立 “关注自己”，最后再一起全局关注。

好处是你可以把多个文档的 key 和 value 各自缓存起来，推理时随时替换，无需重新预填。这对各种产品都很有用，比如 Tad，可以快速创建内容，对 Agent 来说，做语义搜索、读文件也特别方便。

Aman Sanger（联合创始人）：你指的是什么意思？

Sualeh Asif（CPO）：其实现在的大多数 RL（强化学习）训练，都是为了让模型能通过一堆测试用例。

但我们其实并不是真的只关心模型能不能过测试。我们希望它在人类实际需求上表现更好，比如让模型能在文件里加上 console log，或者能完成很多更加 “以人为中心” 的事情，而不仅仅是完成一个很小的任务、通过一堆测试。这也是为什么 SWE-Bench 之类的测评方法有点问题，Federico Cassano 也有类似看法。

Charlie Snell（研究员）：是啊，如果我们想让模型有更多 “以人为本” 的奖励，比如代码质量或者输出是否合理，最关键的其实是要获得真实用户的反馈信号。比如用户到底喜不喜欢模型做的改动，或者用用户是否接受了这次编辑作为反馈信号的 “代理”。

Aman Sanger（联合创始人）：对，还有一种思路，就是直接看用户实际改了什么，然后根据这个判断模型做得像不像。如果用户觉得不对，自己会改。

其实只要能让模型多尝试几种做法，比如后台让模型尝试 3、4 种不同方案、用不同模型、Temperature 调高，然后用户最后挑一个用，哪个被选中就是很好的奖励信号，可以用来训练奖励模型。

Federico Cassano（研究员）：很神奇的是，Pass@K（模型 K 次尝试里有几次成功）的数值，往往比 Pass@1（第一次就成功的比例）高很多。

Aman Sanger（联合创始人）：即使没有很完美的 “神谕” 或者奖励模型，其实还是有办法提高成功率。

Charlie Snell（研究员）：对，可以缩小差距。比如你采样多次，用投票法或者别的选优办法，能提升通过率。我们现在就在做类似的选择机制。

Aman Sanger（联合创始人）：是的，如果我们有足够的数据，能看到 “用户每次都在多个选项中选了哪个”，那我们就能针对这个信号来训练奖励模型。更棒的是，奖励模型能看到 “标准答案”，它就比原始模型知道得更多。

Federico Cassano（研究员）：不过你不能让奖励模型 “饱和” 吧？通常奖励模型过 200 步就没法继续提升，奖励分数还在涨，但模型本身已经没进步了。

Aman Sanger（联合创始人）：那为什么 “看到标准答案” 的奖励模型就不会那么快饱和？

Federico Cassano（研究员）：迟早会饱和，但我的假设是，因为它是基于真实情况的，所以会更晚才饱和。

Charlie Snell（研究员）：可能奖励分数一直涨，但你真正关心的 “真实奖励” 会下降。如果我们用的奖励更接近 “我们关心的目标”，可能会好很多，因为那样人们是在现实里真正做决策。

Federico Cassano（研究员）：如果把用户直接 “放进循环”……

Aman Sanger（联合创始人）：那你觉得，这样做会更差吗？比如只用很干净的奖励信号和用能看到标准答案的奖励模型，两种方案哪个更好？

Federico Cassano（研究员）：如果你能不断重新训练奖励模型，那其实就没什么大问题。

Aman Sanger（联合创始人）：如果我们能一直重训奖励模型，比如做成成对比较的奖励模型，这比只看标准答案会更好吗？

Federico Cassano（研究员）：其实我们现在有人类反馈几乎是 “无限多”，所以这是很理想的状态。

Jacob Jackson（研究员）：对，我们现在有趣的地方是，对于很多模型来说，我们就是模型和现实世界之间的接口，至少在代码相关的应用上。所以我们的职责，就是让模型尽可能贴合真实用户的需求。

Charlie Snell（研究员）：我觉得这里有个权衡：如果你能从真实世界无限采样反馈，你当然可以一直优化，效果会很好。但如果采样成本高，就要想别的办法，比如用 “标准答案” 为基础的奖励，做更多离线优化。

Aman Sanger（联合创始人）：你觉得让模型经常上线，直接从用户那里拿奖励信号，现实可行吗？有没有什么不能这么做的理由？Jacob Jackson，你怎么看？

Jacob Jackson（研究员）：我觉得完全可以这么做。

Aman Sanger（联合创始人）：你觉得我们该这么做？

Jacob Jackson（研究员）：对，我的观点是，新模型上线到实际环境、开始和真实世界互动，这个周期越短，模型效果就越好。

Federico Cassano（研究员）：我个人更看好 “用奖励模型”，而且更频繁地重训。

Charlie Snell（研究员）：如果你每隔几天就重训一次，数据够多就行。

Jacob Jackson（研究员）：你们看到 OpenAI 的博客没？他们有篇反思 “sycophancy（拍马屁）” 现象，说模型学坏是因为训练时用了 “点赞/点踩” 这种信号。

Aman Sanger（联合创始人）：点踩（thumbs down）这种信号确实很糟糕，因为它会让模型只关注会经常点赞、点踩那批用户的分布。

Federico Cassano（研究员）：我也有同感。

Aman Sanger（联合创始人）：这其实是个评测问题。

Federico Cassano（研究员）：你觉得会不会有用户就是故意乱点赞和踩，纯粹捣乱？

Aman Sanger（联合创始人）：“拍马屁”现象就说明确实存在这种问题，但也不是说完全没用。

Federico Cassano（研究员）：所以说，反馈一定要和真实用户需求一致。你得找到用户真心愿意给你反馈的场景。

Charlie Snell（研究员）：对，要尽量贴近真实需求。

Federico Cassano（研究员）：最终的理想就是 “让用户满意，让用户笑出来”。

Aman Sanger（联合创始人）：对，我们要的就是这种效果。

Federico Cassano（研究员）：我也会这么认为。

Jacob Jackson（研究员）：OpenAI 那篇文章提到，这可能是模型变成 “拍马屁型”一个重要原因之一，当然也有别的因素。

Charlie Snell（研究员）：我们可以用一个真实的用户行为信号，比如我们有 “模型选择器”。如果用户切换到了别的模型，这就能说明他们对我们模型的结果不满意。

Aman Sanger（联合创始人）：不，我其实最喜欢 Jacob Jackson 提的信号。你说的那个对吧？

Jacob Jackson（研究员）：哦，我说的是 “代码有没有被保留”。

Aman Sanger（联合创始人）：对，这其实是你最想要的长期信号。

Jacob Jackson（研究员）：或者说，如果他们不用 Cursor 了，我们也不要去强化这种行为。我们希望用户一直留在平台上。能不能用这个信号做点什么？

Aman Sanger（联合创始人）：“流失”（churn）其实也可以当做奖励信号。流失率其实就是我们要优化的 “终极目标”。我们能不能用短期的行为预测流失，把这些作为奖励信号？

Jacob Jackson（研究员）：就是“偏差-方差”权衡的问题。

Aman Sanger（联合创始人）：各种 tradeoff（权衡）永远都存在。

Sualeh Asif（CPO）：还有一个类似的问题，我感觉我们所有的讨论都围绕着 “结果导向”（outcome-based）的奖励展开。其实很早以前，大家也很热衷 “过程奖励模型”（process reward models）。

Aman Sanger（联合创始人）：是的。

Sualeh Asif（CPO）：那这些过程奖励模型现在去哪儿了？Charlie，你怎么看？

Charlie Snell（研究员）：过程奖励模型的问题是，你把整个动作轨迹丢给模型，每一步都打分，其实模型对中间过程的评分不太准，尤其是对那些 “这一动作会不会导致最终正确结果” 的判断。当你对这种奖励模型施加优化压力时，只能优化一点点，就和我们前面讨论的一样。

但如果有真实的 “标准答案” 信号，就能一直优化，比如数学题答案。像 DeepSeek 的 R1 做了一万步 RL，大多数 RLHF 管道只做一百步。能做一万步，模型就能学到完全不同的新能力。所以关键在于你能对奖励信号优化多少步，ground truth（标准答案）能一直优化，而过程奖励只能优化有限步数。

Federico Cassano（研究员）：而且步数越多，这个问题越严重。比如你做 50 步工具调用，value model（价值模型）会成为瓶颈，所以很多人用 PPO 的变体，比如 GRPO、RLU，因为价值模型难以准确评估整个过程。

Charlie Snell（研究员）：对于难题，指望模型给出准确的 “价值评估” 其实很难。所以 GRPO 就是直接暴力多采样几次，把最终结果平均，这样更接近标准答案。

Aman Sanger（联合创始人）：我可能漏听了前面一部分，但这确实解释了 “过程奖励模型” 与 “结果奖励模型” 的区别。但两者比起来呢？

Charlie Snell（研究员）：过程奖励模型如果和单纯只在最后一步打分的 reward model 对比，其实多一步中间评分在某些搜索场景下会有优势。但还是老问题，两者都只能优化有限步。

Aman Sanger（联合创始人）：那我们还要不要训练 “过程奖励” 模型？比如说，我们是不是应该把重心放在反复重训 reward model，而不是过程奖励？

Charlie Snell（研究员）：其实是可以考虑的。如果我们想最大程度用好每一轮用户数据，过程奖励模型可能会有一些增益。

Federico Cassano（研究员）：我们这套基础设施的一个有趣点是，它天然比普通训练复杂。因为它要在原有前向、反向（SFT 或预训练）基础上做更久。另一个点是它还要包含推理环节，而且推理不是为了用户低延迟，而是为了高吞吐量、大规模跑 rollouts（采样）。

像 GRPO 这种算法，更有意思，因为你要对同一个 Prompt 生成非常多的结果，最后再一起反向传播。在数学领域，很多开源项目不太在意这个问题，因为数学任务通常 Prompt 很短，可以直接前后传播。但我们做 Agent 的话，Prompt 很大，就不能把所有采样都全量反向，得优化。

比如你有了 Prompt，从数据加载器拿到 Prompt 时，就开始拉取 KV（键值对）。推理服务器在 rollouts 的同时，key 已经拉好了。等 rollouts 回来，只需要把相关 KV 再 forward 一遍。反向传播时也能直接用之前准备好的 KV，避免重复计算。这里有很多没被充分利用的优化点。

Charlie Snell（研究员）：你还要能快速同步训练节点和推理节点的参数，这也是一大挑战。

Federico Cassano（研究员）：另外，实际做强化学习训练时，会遇到不同的采样方式。比如，很多人会采用 “异步采样”——就是说，你这边还在用上一次的数据进行反向传播（训练模型），模型那边已经开始用旧的参数生成下一批数据了。这样虽然有一点点滞后，但整体训练速度会更快。

当我们需要把所有机器上的参数都同步为最新时，就要进行一次 “全局同步”，这时候大家会暂停一下，把最新的参数用最快的方式同步到所有机器。常用的同步方式有 RDMA、Infiniband、RoCE 等，这些都是高效的服务器间内存传输技术。

Aman Sanger（联合创始人）：关于吞吐量，你们觉得还能怎么优化？

Jacob Jackson（研究员）：像 DeepSeek 的核心架构就是为吞吐量优化的。虽然每秒 Tokens 不高，但每个 GPU 的采样量非常大。其实这套架构也很适合 RL 训练。

Aman Sanger（联合创始人）：用在 NVL 72 设备上。

Federico Cassano（研究员）：还有 PD（参数分离）也很重要。你只需要对 Prompt 做一次 prefill，之后所有 decoder worker 就能开始工作、帮你处理。

Aman Sanger（联合创始人）：其实有一种做 RL（比如 URL）的方法挺有意思的，一方面它简化了流程，一方面又让事情更复杂。就是直接把用户实际用模型推理（inference）的数据，当做 RL 的推理。Jacob Jackson 正在 CAT 上做类似的事。

Jacob Jackson（研究员）：只要你不需要对同一个 Prompt 采样多种结果、只关心模型实际做了什么，然后是 “强化” 还是 “不强化” 这个动作，其实你根本不需要 RL 训练时的额外推理组件。只要看用户真实发生了什么就行。

这种方式和 “重新采样并用奖励模型比较” 是两套权衡，它更依赖于能不能非常快地上线新策略。这样做的好处是，优化的策略和实际生成数据的策略完全一致。

我们在 Tab 这个场景上就这么做，因为我们每单位时间都能收集到大量反馈，比如 Cursor 用户每次看到 Tab 建议都会有反馈。所以我们数据量巨大，这种方案就很合理。

Charlie Snell（研究员）：RL 里的梯度估计本来方差就很大，如果你有很大的 batch，强化单个 rollout 轨迹也没问题。但如果 batch 不大，就得用别的办法降方差，这就是 GRPO 的用武之地，或者你可以加上 value function（价值函数）基线。大 batch 理论上就行。

Jacob Jackson（研究员）：大 batch、短轨迹就很适合。像 Tab，轨迹也就几百个 Token，而 Agent 这种动不动就一万 Token。

Charlie Snell（研究员）：Agent 每次 rollout 都特别长。

Federico Cassano（研究员）：我们怎么能把 Tab 的动作空间变大一点？

Jacob Jackson（研究员）：让 Tab 能给出更多不同类型的建议。

Federico Cassano（研究员）：对，如果 Tab 只生成一行代码，你得多采样很多次才会有新建议。让它更适合 RL 的做法是给它增加更多 “动作”，比如 “跳转” 操作。

Jacob Jackson（研究员）：是的，“跳转” 让 Tab 有更多动作。如果没有跳转，它经常不得不停下来。如果能跳转，就可以继续采样，并根据你是否接受这个跳转给出反馈。

Aman Sanger（联合创始人）：对，那 GRPO 和其他 RL 算法比呢？

Charlie Snell（研究员）：GRPO 和 PPO 最大区别是 PPO 有个 value function（价值函数）。这对于显存不多的人有好处，因为不用额外存 value function 权重，但用 GRPO 你要多跑几轮，计算量更大。

其实你可以用 GRPO 训练模型，但会花很久。特别是在数学、代码这类任务上，value function 通常不准，用 forward pass 算出来的 value 意义不大。还不如多采样几次取平均，效果更好。实际也是这样。

Federico Cassano（研究员）：GRPO 之前其实有类似算法叫 AReLU，没什么人关注。

Charlie Snell（研究员）：对，其实 GRPO 已经出来很久了，DeepSeek 的数学论文里就用过，我记得是一年多前，大概 2024 年初。

Federico Cassano（研究员）：我记得 2019 年也有了。

Charlie Snell（研究员）：对啊，那更早。RL 热起来主要还是 DeepSeek R1 后才被关注，其实 GRPO 在 R1 之前一年就有了。

Federico Cassano（研究员）：他们那时候用的是奖励模型。

Charlie Snell（研究员）：对，他们那会就用 RL，ground truth 也有，还试过对 PRM 做 RL。很有意思，为什么以前没出现和 R1 一样的效果。

Aman Sanger（联合创始人）：你觉得为什么？

Charlie Snell（研究员）：其实有相关研究。可能和基础模型能力提升有关，比如预训练数据变了，或者模型本身足够好了，哪怕采样一百次才有一次做出合理回溯，但有了 RL 后就能把这些好行为放大出来。大模型能力变强也有影响。

Aman Sanger（联合创始人）：现在有人能复现 R0、R1 吗？

Charlie Snell（研究员）：R0 只有很小规模的复现，主要在玩具任务上。

Aman Sanger（联合创始人）：真的很难。

Federico Cassano（研究员）：难点就是要在类似 QwQ 32B 这种大模型上复现，基础设施难度太高了，还有数据，DeepSeek 拿到了大量真实数据，开源社区只有十几万、二十万的数据集。

Aman Sanger（联合创始人）：现在很多结果都是一千条数据，然后靠 CPU 离线加载。

Jacob Jackson（研究员）：会用越来越多的 Token。

Charlie Snell（研究员）：我们一直讨论输入上下文，其实输出上下文也很重要。比如 o3 这种 Agent 会一直抓取内容，直到构建出正确的上下文再解决问题。我预计未来的模型会在做决定前连续调用工具很久。

Aman Sanger（联合创始人）：但感觉这样有点浪费，因为下次又得重新算一遍，大多数情况其实没必要每次都推理那么多，能不能复用之前的推理过程？

Charlie Snell（研究员）：对，你应该能把之前的推理过程沉淀下来，Agent 看历史轨迹或代码库的历史，学到有用信息并存储起来。

Aman Sanger（联合创始人）：对，如果要用最好的 Agent，或者足够好的 Agent，都要忍受 o3 这种慢速高成本，其实很不理想。

Charlie Snell（研究员）：对，其实你应该能在后台慢慢做知识积累，等你真正提问时，能很快用起来。

Aman Sanger（联合创始人）：我觉得 “长上下文” 或者 “代码库专用模型” 会很重要。只要能复用之前积累的知识、理解代码结构，不用每次都重新理解，模型就会高效很多，生成答案时只需要输出关键信息。

Federico Cassano（研究员）：还有一点是，输出 Token 数能大幅提升，训练也会更 “采样高效”。现在 SFTP 训练时，只有输出 Token 能带来信号。

Aman Sanger（联合创始人）：但这样也有缺点，比如生成很长的输出，要做 credit assignment（分配奖励）会很难。像 GRPO，我们是每隔几 Token 采样一次，很长的序列就变得数据高效，但不是计算高效。

Charlie Snell（研究员）：是的，现在大模型训练正进入一个阶段，高质量数据比算力更稀缺。最好的数据很有限，怎么把算力用足？或许那些看起来 “很烧算力” 的办法反而是方向。

Sualeh Asif（CPO）：好，今天就到这里