首次揭秘：Cursor技术团队内部深度分析如何训练出超越人类的编程AI agent

你有没有想过，让 AI 写出优秀代码的关键到底是什么？在我看来，这不仅仅是技术问题，更是一个关于如何定义"优秀"、如何获得反馈、以及如何让机器真正理解人类意图的深层思考。大家都知道Cursor的使用体验就是比绝大多数其他的AI IDE好很多，这里很重要一个点就是他们有自己train的小模型。但这背后究竟是怎么样的设计，其实一直都还是个谜，

而就在几小时前，Cursor放出了一个接近1小时的内部团队讨论视频，深度分析了他们用到的技术和思考，使得我们有机会深入了解了 Cursor 团队内部关于训练超人级编程模型的讨论，他们的观点让我重新思考了 AI 辅助编程的未来。这些来自一线研究者和工程师的见解，揭示了当前 AI 编程领域最前沿的挑战和突破方向。我发现，他们正在解决的问题远比表面看起来复杂得多，涉及从强化学习的稀疏奖励到长上下文处理，从多步骤工具调用到实时用户反馈的方方面面。

这也让我意识到，我们正处在 AI 编程能力发生质变的关键节点。传统的训练方法已经遇到瓶颈，而新的解决方案需要在计算效率、训练稳定性和实际效果之间找到平衡。更重要的是，这些技术突破将直接影响每一个开发者的日常工作体验。我快速把视频的内容做了整理，分享给大家，让我们来深入了解这些技术专家是如何思考和解决这些挑战的，以及这些努力将如何塑造编程的未来。

编程 AI 的强化学习为什么如此困难

在这个视频中提到训练编程 AI 面临的挑战远比我之前想象的复杂。他们指出，编程领域的强化学习与数学或写作等其他领域有着根本性的差异。最关键的问题在于动作空间的巨大性。在数学推理中，答案通常很短，推理过程可以帮助模型逐步到达正确答案。但在编程中，推理本身就嵌入在答案里，代码既是思考过程也是最终结果。

更复杂的是，编程任务往往需要多步骤的工具调用过程。不像简单的生成任务那样"生成推理令牌，生成答案，获得奖励"，编程任务的流程更像是"生成一些令牌，调用工具，获取工具响应，然后可能需要迭代多次"。这种多步骤的特性使得强化学习的形状发生了根本变化，因为现在需要优化整个多步骤工具调用过程，而不是单一的输出。

我觉得最有趣的一点是，Cursor 团队特别重视那些无法通过传统方式验证的场景。虽然数学问题有标准答案，编程问题可以通过测试来验证，但在实际应用中，很多时候用户并不会明确告诉系统某个解决方案是否有效。这就需要在没有明确反馈信号的情况下进行强化学习，这是一个前所未有的挑战。

对于写作等其他领域，团队认为当前的后训练方法往往让模型写出僵硬正式的内容，但这并不是模型的固有局限，而是训练方式导致的结果。他们提出了一个有趣的想法：为什么不能训练模型预测整个章节，而不是下一个词？让模型根据当前章节预测整个下一章节的内容，然后使用某种相似性度量来评估预测章节与真实章节的相似度。这种方法将困难的下一词预测问题转化为更长序列的预测，并允许使用语义奖励进行优化。

然而，编程和写作之间存在一个关键差异：代码的好坏有相对客观的标准，主要是功能性是否正确，而写作的质量很大程度上取决于个人品味。即使是经验丰富的专家，对同一篇文章的好坏也可能持完全不同的观点。不过在编程中也存在类似的主观性问题，比如代码质量。一旦代码通过了测试，要进一步提升其质量就变得相当困难，因为"通过测试"这个标准并不能捕捉到模型为了通过测试而采取的具体方法。

测试驱动训练的局限性与创新奖励机制

在深入了解 Cursor 的训练方法后，我发现他们对测试作为奖励信号既认可又保持谨慎的态度。测试的优势很明显：它提供了接近真实情况的信号，如果测试覆盖充分，就能给出代码是否有效的可靠反馈，可以基于这个信号进行长期的强化学习，并从模型中学习到一些有趣的行为模式。但测试无法捕捉到所有重要的方面，这就需要放宽条件，寻找其他获得奖励的方式。

一个创新想法是使用真实变更的对比数据。比如某个功能变更的真实 diff，虽然可能有多种实现同样变更的方法，这不是完美的信号，但可以作为验证信号的有用信息。我认为这种方法的价值在于它更接近真实的开发场景，因为实际开发中很少有完美的测试覆盖。

奖励稀疏性是另一个重大挑战。可能需要采样大量的 rollout，但只有少数能通过测试，这就产生了典型的稀疏奖励问题：是否通过所有测试只有 0 或 1 这样的二元反馈。这种稀疏性使训练在计算上变得昂贵，虽然有一些技术可以缓解这个问题，比如从每个 token 开始以分支方式进行 rollout，但这会变得非常昂贵。

团队提到了一个有趣的观察：模型实际上看到的不是原始奖励，而是优势值，这是相对于同一提示的其他 rollout 的相对奖励。通常情况下，如果任务太困难，模型只能在一千次尝试中成功一次，那么稀疏奖励就会成为真正的问题。如果成功率能达到百分之一或稍高一些，那么这个信号就是可以使用的。

我发现他们对于分解大任务的思考很有价值。对于完整的 PR（拉取请求），除非投入大量计算资源，否则会非常困难且稀疏，因为以目前模型的能力水平，很少能够通过完整 PR 的所有测试。但如果能够将完整的 PR 分解为更小的部分，并对每个部分进行测试，这可能会带来显著的改进。这种分解方法可以将千分之一的成功率提升到更容易处理的水平。

在某些情况下，可能需要通过分解为组成部分来减少稀疏性的程度，希望每个部分都能做对。从某种程度上说，理想的目标是功能上等同于真实情况或良好变更的变更，并且要简洁。问题在于，这不仅是一个困难的目标，甚至评估候选解决方案是否满足这个目标就等同于停机问题，这在理论上是不可能解决的。但如果能找到接近这个目标的方法，也许就是一个好的方向。

工具选择的智慧：从简单到复杂的权衡

Cursor 团队讨论工具选择时，我发现了一个有趣的现象：不同的研究实验室正在选择不同的工具集来训练强化学习模型。比如 OpenAI 的 o3 模型专门针对终端进行了高度优化，它是一个相当奇特的模型，只倾向于使用 grep 和 sed 命令，除了终端之外不愿意使用任何其他工具。而 Claude 模型则倾向于围绕搜索和编辑进行设计。这种差异反映了不同团队对工具复杂性与效果之间权衡的不同理解。

团队认为终端工具受到青睐的主要原因是其简单性。你不需要构建复杂的测试框架来运行 agent，只需要给它一个 shell 访问权限，它就可以在那里完成所有工作。简单性可能是最大的原因。但他们也指出，可以在核心工具集的基础上做得更好。

一个很好的例子是 linter 错误。Linter 错误提供了大量信号，但获取这些信号很困难，因为需要运行语言服务器。而让语言服务器在任意代码上运行实际上是相当困难的。但这是 Cursor 的一个有趣优势，因为 Cursor 自带预安装语言服务器的扩展，用户会设置这些，所以可以获得像 linter 这样的工具信号。

他们还提到了语义搜索工具。虽然语义搜索在静态代码文件上可能无法提供 GPT 通过足够多的跳转无法获得的信息，但它能更快地到达目标，这意味着成本更低，使用的上下文窗口更少，速度也更快。这揭示了一个重要的权衡：你既想要高质量的工具，又要考虑简单性，因为可以选择最小描述，比如仅使用终端，但也可能想要越来越高质量的工具。

一个特别有意思的观点是，可以使用工具来建模模型本身的行为。比如，很多推理模型喜欢进行大量推理，即使在不需要推理的情况下也会过度思考。缓解这个问题的一种方法是添加一个"思考工具"，当模型意识到任务需要一些推理时，就可以调用这个工具来启用推理过程。这种方法让我想到了元认知的概念，AI 系统开始具备对自身认知过程的认知。

我发现推理模型与工具调用交互的方式确实有些奇特。它们往往在提交用户消息后、甚至还没有看到任何内容之前就开始思考，然后调用所有这些工具。团队建议模型应该在每个工具调用之后进行思考，而不是在所有工具调用之前。这种观察让我思考：当我们只是要求模型进行编辑时，是否真的需要"推理"这个独立概念？也许在训练时，我们应该让它在工具调用中做任何它想做的事情，而不是限制它必须有一个专门的推理部分。

长上下文与代码理解的未来

在讨论代码和长上下文的交互时，Cursor 团队的观点让我对这个问题有了全新的认识。他们指出，在某种程度上，长上下文确实非常重要，因为如果将所有内容限制在 8K token 内，那么现有的模型（比如 GPT-4 原始版本）基本上是等效的。你需要比临界上下文长度更多的内容，可能需要至少 50-60k token 的最小上下文长度才能看到显著改进。

长上下文的趋势一直是越来越长，注意力机制在使用长上下文方面表现很好，但成本也越来越高。在技术层面，长上下文研究中一个非常有趣的方向是如何保持成本增长缓慢，如何在多个提示中重用缓存的上下文。这对于最新的、比以前更强大但总费用也可能相当高的模型来说尤其重要，如果在缓存和使用上下文方面不够智能的话。

我认为代码在某种意义上是特殊的。当开始查看专业代码库时，与你可能想要做的任何事情相关的上下文量都非常大。这与聊天应用不同，比如 ChatGPT 或 Claude 应用，在大多数情况下用户带来的上下文并不多。用户有一个问题，通常只有 100 个 token。所以主要关注点是如何将人类知识的总和压缩到权重中，然后用它来回答问题。相比之下，你不太关心如何处理一百万个 token 并从中获取有用信息，因为这不是大多数用户关心的问题。

对于需要多长的上下文窗口这个问题，团队认为更长更好，但也存在递减效应。根据查询即时检索相关 token 的方法不是唯一需要的方法，但也相当不错。长期来看，最有意义的可能是使用混合机制的方法，比如具有某种可以消费 1 亿个 token 但可能从每个 token 获得较少信息的机制，使用它来获得对代码库的一般理解。但当确切知道要做什么时，它可以记住哪些部分是相关的，并刷新对这些部分的记忆。

团队对新架构的讨论也很有见地。他们提到了 DeepSeek 的 Multi-head Latent Attention（MLA）机制，这是一种相当优雅的方法，能够很好地扩展。它的工作原理是将注意力分为三个部分：一个进行滑窗注意力，关注短期发生的事情（比如最近的 4000 个 token）；另外两个部分进行块状注意力，每隔一定数量的 token 将其存储为键和值，然后查询会关注这些块，从中获得最相关的前 k 个块，然后对这些块进行完全注意力。这种方法很酷，因为它应该能够很好地在长上下文窗口中进行检索。

我发现他们对长上下文机制评估的观点很实用。评估长上下文机制的困难之处在于需要真正了解基线，因为所有方法在某种程度上都有效。你可以进行稀疏注意力，可以让一些头进行局部注意力，一些头进行全局注意力，这些都会使性能稍微降低一点，但使速度更快。所以必须非常严格地评估这些方法。

内存工具与状态管理的挑战

在讨论更复杂的状态工具时，Cursor 团队提出了一个非常有趣的概念：内存工具。这种工具允许模型存储信息片段，并希望稍后能够检索它们。但问题在于如何鼓励模型实际存储对以后有用的好记忆。这个问题比看起来要复杂得多，因为它涉及到跨时间序列的信用分配问题。

我发现内存工具实际上包含两个不同的工具。第一个工具是"我想存储这个特定交互的记忆"，第二个是"检索记忆"。检索记忆相对简单教会模型，如果检索到的记忆实际上在对话中有帮助，就可以给予奖励。但存储记忆要复杂得多，因为奖励不依赖于当前轨迹，而是依赖于不同的轨迹。这也增加了训练期间的计算量，因为这意味着要从存储记忆中获得良好信号，必须在一堆完全不相关的随机其他轨迹中进行多次 rollout。

一旦进行写入操作，就是在向状态中存储一些将在未来轨迹中使用的东西。所以在进行训练时，既要进行存储的 rollout，也要进行检索并应用奖励的后续 rollout，然后将奖励反向传播到写入步骤。这种跨轨迹的信用分配问题使得用模型训练的方式变得极其困难。

团队认为，可能用非模型训练的方式生成和检索记忆会更容易，而是使用 Federico 描述的评估系统，尝试生成、使用和抓取记忆的所有不同方式。他们建议不使用梯度反向传播到记忆存储机制，而是获得一个基准，比如 500 个 agent 应该做的事情的例子，以及检查它是否完成的方法，然后试验不同的规则、启发式方法和提示，用于何时存储记忆和何时遗忘，然后测量每种方法的效果如何。

这种方法很有趣，因为虽然没有足够的例子来反向传播到某个东西（因为它会很快学会在这些例子上进行奖励黑客攻击），但如果有一个启发式系统，也许可以帮助找到最佳的一个。我觉得这种评估驱动而非训练驱动的方法反映了当前 AI 系统的一个重要特点：有时候传统的梯度下降并不是解决所有问题的最佳方法。

我也思考了记忆工具与长上下文机制的关系。短期内记忆工具可能是有意义的，但长期来看，可能会被某种更强的长上下文机制取代，比如 Jacob 描述的那种可能看到所有以前聊天记录的机制。这让我想到一个有趣的问题：是以前的聊天记录更重要，还是用户以前的所有 PR 更重要？这两者提供了不同类型的信息。以前的聊天让你看到实际做事情和环境如何反应的过程，然后可以从中更新，这是从 PR 中无法获得的。PR 只是演示。但从以前的 PR 中也可以获得某种类似的个性化信息。

GPU 架构与长上下文的技术突破

在讨论硬件对长上下文处理的影响时，Cursor 团队展现了对底层技术的深刻理解。他们提到，新一代 GPU 确实让长上下文处理变得更加容易，GB200 和 NVL72 架构通过两种方式支持超长上下文。首先，由于拥有 72 个通过 NVLink 网格互连的 GPU，可以进行超越传统 8GPU 网格的张量并行。这允许减少每个设备上存储 KV 的注意力头数量。

其次，类似 Grace 的 CPU 允许拥有统一内存，可以在其上存储 KV，因此允许每个设备存储更多数量的 KV。这种架构创新的一个特别酷的应用是，实际上不需要将 KV 存储在 GPU 内存中，可能几乎不会产生任何速度下降，因为基本上可以将计算与从 CPU 加载下一次注意力需要的内容交错进行。

我觉得这种方法的技术细节很有意思：当到达第零层时，开始从 CPU 卸载第一层需要的 KV。所以基本上是免费的，除非实际到达该层，否则永远不需要完整的 KV 在 GPU 内存上。这种方法可能只能扩展到大约一百万个上下文，但仍然必须支付二次成本，这总是会有很大的开销。

不过，如果并行化做得正确，成本应该仍然会便宜 72 倍，因为如果正确分片注意力头，成本会降低 72 倍。但这仍然是针对大规模 N 平方爆炸的 72 倍降低。所以也许需要与所有这些人们正在添加的常数因子改进结合，比如滑窗、偶尔共享等。MLA 是另一个很好的改进，虽然是一个大的常数因子，但仍然是常数因子。

他们特别喜欢的一个概念是"文档级注意力"，他们称之为"squid attention"（章鱼注意力），因为他们将其想象为章鱼，每个文档就像一个不同的触手。这个名字是 Lucas 想出来的，虽然看起来不太像 Lucas 会起的名字。squid attention 的想法是基本上想要独立地关注每个文档，每个文档将独立地关注自己，然后在最后关注所有内容。

这种方法的好处是现在可以交换文档。如果关心 10、20、30 个文档，可以独立缓存每个文档的键和值，永远不必重新支付预填充成本，可以在推理时替换它们。这对产品中的各种功能都非常有用，比如对标签页很有用，当检索内容并希望快速完成时很有用。对于 agent，当使用语义搜索、读取文件时，这将非常有用。

真实世界反馈与训练方法的革新

当谈到如何优化真实世界使用而非仅仅是测试用例时，Cursor 团队的思考让我看到了当前 RL 方法的一个重要局限。他们指出，目前大多数强化学习都是为了完成一堆测试用例，但我们真正关心的并不是模型在测试用例上的表现。我们希望它能很好地处理各种更以人为中心的任务，比如在文件中添加 console log，或者其他各种比完成特定小任务和通过测试更贴近人类需求的工作。

要获得这些更贴近人类的奖励信号，似乎需要从真实环境中的真实人类那里获得真实信号。比如用户是否喜欢 agent 所做的更改，或者基于用户是否接受编辑的某种代理指标。我认为这种方法的价值在于它直接针对了我们真正关心的结果，而不是代理指标。

团队提到了一个很有价值的想法：观察用户实际做出的真实更改，然后从中获得良好的感觉。如果当重新运行 agent 时它做了类似的事情，因为用户会进去，如果它是错误的，他们会做一些不同的事情。还有一些很酷的事情可以在后台运行时做，比如可以让它对问题进行三到四次尝试，尝试一堆不同的模型，尝试一堆不同的参数设置，提高温度，然后选择 Cursor 提供的所有选项中有效的那个。这为训练奖励模型提供了非常好的信号。

我发现一个特别有趣的现象是 pass@k（在 k 次尝试中正确的比例）比 pass@1（第一次尝试就正确的比例）要高得多。即使没有很好的预言机或奖励模型，也有一些技巧可以做到，也许无法完全达到 pass@k，但可以稍微缩小差距。比如如果采样多次，可以进行多数投票，或者可以有一个奖励模型来选择最好的一个，这样可以稍微缩小差距。

如果确实有奖励信号，比如有很多关于奖励信号的数据，用户总是在三个选项中选择其中一个，那么如何以不同的方式进行 RL？团队认为可以仅针对该信号训练奖励模型，并专注于此。另一个好处是，如果奖励模型看到真实情况，它比原始模型或策略知道得更多，无法让它饱和，因为关于奖励模型的一般问题是，在大约 200 步之后基本上就完成了。奖励会持续上升，但模型实际上并没有改进。

为什么不能让看到真实情况的奖励模型饱和？虽然在某个时候肯定会让它饱和，但由于它基于某种现实，假设是它会晚得多地饱和。奖励模型的问题是，奖励会永远上升，但你关心的真实奖励会下降。但如果我们更接近我们关心的东西，也许人们在循环中做出真正的决定，而不是...我觉得如果可以重新训练奖励模型，那么基本上没有问题。

RL 基础设施的技术挑战与创新

在构建 RL 基础设施方面，Cursor 团队分享了一些非常深入的技术见解。RL 基础设施的一个有趣之处在于它天然地比训练基础设施更复杂，因为它建立在训练基础设施之上。用于 SFT 或预训练的前向和反向传播的所有内容都需要在这种情况下具有良好的性能。另一个有趣的方面是现在还有推理组件，推理组件也必须在这种情况下进行优化，在这种情况下你并不真的关心延迟，而是关心吞吐量，关心大规模获得尽可能多的 rollout。

对于像 GRPO 这样的算法，情况甚至更有趣，因为你有一个提示，要为这一个提示生成很多很多完成，然后最终要对这一个提示的所有这些完成进行反向传播。对于数学问题，开源社区的人并不太关心这个事实，因为在数学中，大多数开源优化的数学任务，你有这些非常小的提示，所以你可以在不关心一直重新计算提示的情况下，对所有序列进行前向和反向传播。

但对于他们的情况，当有 agent 时，他们有这些庞大的提示，所以无法承担对所有共享相同提示的 rollout 进行反向传播的成本。所以开始做优化，与推理服务器重叠更多，开始可能从数据加载器中已经有提示，并在推理服务器已经在处理 rollout 时开始从该提示获取 KV。rollout 回来时，已经有了 KV，所以只需要通过回来的 rollout 进行前向传播。然后当到达反向传播时，已经为提示准备了 KV，所以可以重用这些，只在这些 KV 上反向传播一次。

还需要能够快速在训练节点和推理节点之间同步参数，这是另一个大挑战。对于生成这些 rollout，有不同的情况，很多人异步进行，基本上在当前 rollout 进行反向传播的同时，模型已经在用过时的权重为下一批生成 rollout。所以生成 rollout 的模型总是落后一步。但这种方式使训练更快，因为在下一次迭代时不必等待 rollout 完成就可以开始反向和前向传播。当需要同步权重时，基本上必须停止一切，进行这种同步，这通常通过 RDMA 或直接通过 InfiniBand 或 Rocky 等内存读取来实现。

我觉得一种有趣的做 RL 的方式是重用你为用户做的推理作为你实际为 RL 做的推理，这在某些方面简化了事情，在某些方面使其更复杂。Jacob 正在为 tab 功能研究这个问题。只要你不需要为提示进行多个完成，如果你只关心你实际做了什么，然后你只是想要强化或不强化你所做的，你实际上不需要为 RL 训练过程提供单独的推理组件。你可以只看实际与真实用户发生的事情。

这与重新采样然后使用奖励模型比较它们的方法相比，是一套不同的权衡，因为它非常依赖于能够非常快速地推出新策略。但它确保了你正在优化的策略和实际生成轨迹的策略之间的良好匹配。他们正在为 tab 功能研究这个，因为每当有人在使用 Cursor 时显示 tab 建议时，他们就会获得反馈，这是一个非常大的反馈量。所以他们有很多数据，认为在这种情况下这可能是有意义的。

编程 AI 的未来：超长序列与智能缓存

当聊到编程 agent 的未来时，Cursor 团队的回答让我重新思考了计算资源使用的问题。他们认为未来的模型将使用更多的 token，特别是在输出上下文方面。如果看 o3 这样的模型，它是一个与其他模型非常不同的 agent，它会一直生成内容直到建立起正确的上下文，然后知道如何解决问题。他们预期会看到能够进行非常长的工具调用序列的模型，然后才开始实际应用它们学到的东西来解决问题。

但这样做似乎很浪费，因为它可能做类似的事情，然后这些内容在下次进入时就被丢弃了。对于大多数事情，你可能不需要做那么多思考，你可以重用之前发生的思考。团队认为应该能够摊销其中一些成本，基本上让 agent 查看轨迹或查看在代码库中之前做过的事情，并对此做出有用的推断，并将其存储在某个地方。

如果世界看起来像你必须使用最好的 agent，或者使用足够好的 agent，你必须使用 o3 的速度和成本，那就太糟糕了。应该能够重用其中一些知识积累，在后台进行，然后当你问问题时，应该能够非常快速地完成。我认为长上下文或某种代码库专业化将非常重要，能够重用它在过去所做的工作，能够大致了解这个代码库如何工作。它不必每次都重新做理解如何进行类似更改的工作，这只会使它在实际生成答案所需的输出 token 方面更加高效。

能够扩展输出 token 的事实使训练变得更加样本高效。通常在 SFT 中，我们有这些大提示，模型真正只从输出 token 获得信号。这也使它变得相当低效，如果它是一个超长输出，你需要进行信用分配，找出哪些是重要的 token，然后使用 GRPO，如果我们按我们的方式进行，你只是在这个庞大序列中每隔几个 token 采样一次。我想这使它变得数据高效，但不是计算高效的。

我觉得我们正在接近这样一个制度，对于 LM 训练来说，相对于可用的计算量，最高质量的数据变得更加稀缺。最好的数据比计算要稀缺得多。所以如何使用所有这些计算？潜在地，看起来计算成本很高的方法实际上是可以的。我认为这个观察反映了整个 AI 行业当前面临的一个根本性转变：从数据受限转向计算优化。

在这种情况下，那些传统上被认为"太昂贵"的方法可能变得可行，甚至是必要的。这让我想到，也许我们需要重新审视那些因为计算成本而被搁置的想法，比如更复杂的搜索算法、更深入的推理过程，或者更精细的反馈机制。

从 Cursor 团队的讨论中，我看到了一个清晰的未来图景：编程 AI 将变得更加智能，不仅能够理解当前的任务需求，还能够从历史经验中学习，建立对代码库的深入理解，并且能够高效地重用这些知识。这种发展将彻底改变我们与代码的交互方式，让编程变得更加直观和高效。

最终，我相信我们正站在编程范式转换的临界点。传统的编程方式——手动编写每一行代码，逐步调试，反复测试——将逐渐被 AI 辅助的协作式编程所取代。在这种新模式下，开发者将更多地专注于高层次的设计和创意，而将具体的实现细节交给能够理解上下文、学习偏好、并且能够持续改进的 AI agent。这不仅会提高开发效率，更会降低编程的门槛，让更多人能够参与到软件创造的过程中来。

文章来自微信公众号 “ 深思圈 “，作者 Leo