Cursor首度揭秘：强化学习如何让AI编程效率提升四倍的秘密武器！

在编程时，AI助手的表现总是让人纠结：要么慢得让人烦躁，要么聪明却无法写出合格的代码。Cursor 最近推出的 Composer 模型完美解决了这一难题，它通过强化学习（RL）技术实现了“智能和速度的双重巅峰”—— 编程效率是同类智能模型的四倍，还能精准适应实际的代码规范。

你有没有觉得，AI编程助手总是让人感觉少了点什么？要么反应慢得让人抓狂，要么速度快但写出的代码总是有问题。这个矛盾困扰了我很久，直到我在 Ray Summit 2025 上听到了 Cursor 的 AI 研究员 Sasha Rush 的分享。他们推出了一个叫 Cursor Composer 的新模型，采用了一种全新的思路，利用强化学习（RL）来训练一个既聪明又快速的 AI 助手。

听完分享，我最大的感触就是：这不仅仅是技术上的进步，还是思维方式的转变。Cursor 团队并不是单纯追求高分的 benchmark，而是专注于解决现实编程中的实际问题。他们通过强化学习让模型在真实的代码环境中学习，理解代码规范，掌握各种工具的使用，还能知道什么时候并行完成任务。更重要的是，他们把整个产品的基础设施融入到训练过程中，让 AI 在训练时的表现就像真实用户在使用 Cursor 一样。这种“训练即产品”的理念让我重新思考了 AI 工具的构建方式。

为何我们需要一个又快又聪明的编程 AI

Sasha Rush 在分享的开场就指出，Cursor Composer 在他们的内部 benchmark 中表现几乎与最顶尖的 Frontier 模型相当，甚至优于去年夏天发布的所有模型。它的表现明显超越了最好的开源模型和那些标榜为“快速”的模型。而最让人印象深刻的是，这个模型的 token 生成效率是同类智能模型的四倍。这意味着它不仅智能，而且速度惊人，甚至比那些专门设计为快速编程的产品还要快。

我一直相信，AI 工具的“快”不仅是一项技术指标，更是影响用户体验的关键。想象下，当你在编写代码的时候，突然需要重构一个复杂的函数。如果 AI 助手要等30秒才给出建议，这段时间会打断你的思路，影响专注。而如果 AI 能在2秒内给出答案，你就能保持思维的连贯性，继续沉浸在编程的状态中。这样的“快不打断思路”的体验，才是真正的价值所在。

Cursor 团队深刻理解这一点。他们的灵感来源于 Cursor 应用中最受欢迎的功能之一：Cursor Tab。这个快速、智能的模型在用户使用时带来了非常流畅的体验。Sasha Rush 表示，让模型快到足以支持交互式使用，能够帮助开发者更容易地保持思维的连贯性，始终处于工作状态。于是，他们构建了一个原型模型，代号 Cheetah（猎豹），专门为 agentic coding（代理式编程）提供快速体验。这个原型发布后，用户反馈非常好，很多人表示这感觉“完全不一样”，甚至像是“外星科技”。这让他们坚信，如果能打造一个更聪明但保持同样效率的模型，将会带来颠覆性的用户体验。

我非常赞同 Sasha Rush 提到的一点：他们并不是在追求随便的 benchmark 分数，而是想要构建一个在实际编程工作中感觉良好的模型。他们基于自己的代码库建立了一个内部 benchmark，专门评估模型在大型代码库中的工作能力，以及它是否能遵循代码库本身的规范。这些智能因素才是日常软件工程中真正重要的。很多时候，AI 模型在标准测试中表现优异，但在实际应用中却表现平平，因为它们并没有针对真实的工作流程进行优化。

Cursor团队：让AI像开发者一样聪明又迅速

Cursor团队的目标其实很简单：既要智能，也要快。这里的“快”不仅指的是生成代币的速度，还包括在编辑器里的运行效率。为了实现这一点，模型需要能够快速进行编辑，同时还要借助并行工具调用等技术迅速产出结果。当这两个目标结合时，你会发现这个模型在实际使用中与众不同。在他们的演示视频中，用户一提交查询，模型便能立刻调用多个工具，执行终端命令、在代码库中搜索、进行编辑、编写待办事项……然后只需一两秒，你就能看到完整的编辑结果和代码变动总结。这种体验和我们平常用的编辑器完全不一样。

Agent RL：让AI像真实开发者一样工作

Sasha Rush花了不少时间跟我们讲解他们是如何利用强化学习（agent RL）来训练Composer的。这部分我觉得特别有趣，因为它展示了要构建真正有用的AI工具需要什么样的思维方式。

从用户的角度看，Cursor的使用流程其实很简单：用户把查询提交给Cursor的后端，agent就会读取这个查询并调用一系列工具。Sasha Rush提到，我们可以把agent视为在“工具空间”中进行互动。它可以从多个能够改变用户代码的工具中选择，Cursor目前大约使用了十种工具，简单来说就包括读取文件、编辑文件、搜索代码库、进行代码检查和运行终端命令等。agent可以串行或并行调用这些工具，只要认为这样能得到好的效果。

从底层来看，这个agent其实还是一个大型语言模型，主要的工作就是生成代币。你可以把某些代币看作是形成XML模式，用于调用工具及其参数。但是从强化学习的角度来看，我们可以把它理解为在工具调用的组合空间中采取行动。当你查看Cursor的前端时，你会看到的执行过程就是各种工具调用组合后的改变过程。对于读取操作，前端只是总结一下；而对于编辑，你能实时看到所有变化；至于终端调用，你会看到工具调用的结果，以及终端的输出。这就是agent在你IDE中进行操作的方式。

最吸引我的是他们进行强化学习训练的方法。Sasha Rush强调，他们尽量模拟Cursor在真实生产环境中的运行方式。也就是说，他们把训练数据视为用户的查询，然后agent会调用一系列工具来达成目标。强化学习的独特之处在于，他们会从同一个起点进行多次不同的执行。你可以想象成同时并行运行多个Cursor。在其中一次执行中，模型可能读取一个文件并进行编辑；而在另一次执行中，由于LLM的概率性，它可能选择不同的工具顺序，走出另一条路径。之后，他们会对这两种选择的输出进行评分，判断哪种更好，并据此更新模型参数。

挑战与机遇：让 AI 更智能的三大难题

听起来是不是挺简单的？但 Sasha Rush 提到，真正有趣的挑战在于把这个基本流程推向极致，而这个过程中的每个环节都充满了挑战。其实，很多时候，技术的基本理念往往很简单，但难点在于如何把它执行到位，做到真正能用的程度。

三大挑战：训练与推理的匹配、超长 Rollout 和一致性

Sasha Rush 深入探讨了在这种 agent 式强化学习中所面临的三个关键挑战。我觉得这些问题非常具代表性，不仅能用于编程 AI，还适用于几乎所有需要在真实环境中训练 AI agent 的场景。

第一个挑战是训练与推理的匹配。为了实现最佳的并行性能，他们需要训练一个混合专家语言模型，这个过程要在数千个 GPU 上进行分布式训练。如果只是进行预训练或监督微调，已经够麻烦了，但当涉及到强化学习时，难度就翻倍了，因为你得同时管理训练版本和采样版本，而且它们还得协同工作。我觉得这个挑战揭示了一个更深层次的问题：在实际产品中使用的模型和训练时使用的模型，必须在架构、行为和性能上保持高度一致，否则训练出来的模型在应用时可能完全失效。

第二个挑战是超长的 rollout。当他们用真实代码变动进行训练时，rollout 过程比展示中要困难得多。在现代模型中，rollout 涉及到 10 万到 100 万个 token，并且在过程中需要进行数百次不同的工具调用。更让人头疼的是，不同的 rollout 可能会用到不同数量的工具调用，也需要花费非常不同的时间。这让我想起了，现实世界的任务往往比我们想象的复杂得多。比如，一个看似简单的“重构这个函数”请求，可能要求 AI 读取十几个相关文件、查找代码库中的使用示例、运行测试、检查代码风格，然后才能做出正确的修改。如果训练时只用一些简单的玩具例子，模型根本无法学会应对这种复杂性。

基础设施：让不可能变为可能的关键

一致性问题是第三个挑战。他们的目标是通过生产产品进行训练，努力让一个名为 Cursor 的代理在强化学习中尽可能接近真实的使用情况。这其实意味着他们希望在更大规模的环境中，使用与实际产品完全相同的工具和响应方式。这个挑战特别有意思，因为它打破了传统的机器学习框架。一般来说，我们通常会把训练环境和实际应用环境分开，但 Cursor 团队却选择尽量让这两者保持一致。这样做的好处在于，模型在训练过程中学到的每一个技巧和工具的使用方法，都能直接应用到真实的产品中。

Sasha Rush 提到，这三个问题都反映了机器学习系统扩展过程中的难题，但解决这些问题的关键往往在于基础设施的选择。我非常赞同这个看法。很多时候，我们把机器学习当成是算法和数学的游戏，但实际上，能否将一个创意转化为真正有效的产品，往往取决于你基础设施的强大和灵活性。

Sasha Rush 花了不少时间来详细讲解他们的基础设施架构，我觉得这部分内容相当重要，因为它展示了构建一个真正可扩展的 AI 系统需要具备的条件。

在整体架构上，他们有三种不同的服务器：训练器、推理服务器和环境服务器。训练器主要基于 PyTorch，结构上看起来像是一个扩展到大规模的标准机器学习栈。推理服务器则主要使用 Ray 来管理 rollout，而环境服务器则利用微虚拟机来启动这些环境的有状态版本，这样他们就能进行文件修改、运行终端命令和执行代码检查。你可以把这个过程想象成运行一个迷你版的 Cursor。这三部分需要相互配合，才能形成一个完整的训练循环。

优化训练过程的秘密：Cursor团队的创新之道

在训练器的优化方面，Cursor团队真是下了一番功夫。他们开发了一个特别的内核库，能够支持低精度训练，这不仅加快了整个训练的速度，还让采样变得更高效，完全不需要后续的量化处理。他们用的叫做MXFP8的微缩放格式，实际上是希望通过FP8精度加上额外的缩放因子，来实现更高的精度和训练质量。Sasha Rush提到，这个微缩放格式的自定义内核是专为最新的NVIDIA架构设计的，结果在Blackwell芯片上，混合专家层的速度提升达到了3.5倍！

我觉得这种对底层技术的追求真是太重要了。很多AI团队可能会满足于用现成的训练框架和标准精度，而Cursor团队却选择深入到内核层面进行改进。这种投入不仅让他们的训练速度快了很多，还能处理更大更复杂的模型，同时确保训练和推理过程的高效性。这种“不满足现状”的精神，真是顶尖团队的共同特征。

推理服务器面临的主要问题就是拖慢进程的现象。如果你不仔细控制这个过程，放任agent自己去做事情，就会遇到麻烦。因为rollout可能会调用终端命令，甚至安装整个库，随心所欲，这样一来，运行10个rollout时，它们返回的时间可能会天差地别。Cursor团队通过使用Ray和单一控制器接口来解决这个问题，这样能够在多个线程和进程之间实现负载均衡，提升了整个过程的效率。

真实世界中的AI系统复杂得让人惊讶。理想情况下，所有的rollout应该花费差不多的时间，但实际上，它们的时间差异可能很大。有的可能只需读取几个文件就搞定了，而有的则需要进行复杂的构建流程。如果不能有效应对这种异构性，整个训练过程就会被最慢的rollout拖累，导致资源浪费和效率低下。

将训练与产品完美结合的理念

Sasha Rush特别强调，他们的目标是通过生产Cursor产品来进行训练。这真是个有趣的切入点，因为Cursor可以在设计产品的同时进行机器学习训练。幸运的是，在构建强化学习栈的过程中，他们推出了一个叫做云agent的产品。这让用户可以离线使用agent，Sasha Rush表示，他常常在地铁上使用它来检查模型的表现。作为这个产品的一部分，他们会启动用户环境的虚拟机，让agent可以修改代码并执行终端命令。这样一来，他们就能利用同样的基础设施进行强化学习训练。

这意味着他们的生产agent服务器在运行云agent和强化学习训练时是完全一致的。这可是个聪明的设计决策！很多公司往往将训练环境和生产环境分开，这导致训练出来的模型在真实应用中表现不如预期。但Cursor选择让这两者完全一致，模型在训练时就已经在学习如何在真实环境中更好地表现。

不过，这也带来了挑战。在强化学习训练高峰期的工作负载往往比标准产品运行时要突发得多。因此，他们必须妥善处理当启动大量环境进行训练时所产生的这种突发性，确保产品的良好运作。Sasha Rush还展示了一个他们用Composer编写的仪表板，实时显示后端的利用率情况。这一点特别有意思，说明他们已经开始利用自己开发的工具来优化工作流程。

真实环境下的AI训练：为何如此重要？

你可能会好奇，为什么要花费这么多时间在真实的生产环境中进行训练呢？其实，他们完全可以通过模拟不同的结构来测试各种情况。但Sasha Rush给出的理由非常有说服力：他们可以引入一些对智能代理极具价值的工具。其中一个亮点就是他们自己训练的嵌入模型，能够进行强大的语义搜索。当你使用Cursor时，它会自动索引你所有的文件，这样代理就能用自然语言方便地查找想要编辑的内容。

他们发现，这种语义搜索的能力对于Cursor中使用的各种代理都非常有帮助，尤其是对Composer。原因在于，他们能够使用与实际生产中相同的模型和结构来训练Composer，从而使模型成为这个工具的高手。这让我意识到，AI工具不仅要聪明，还得会有效地利用手头的工具。就像一个优秀的开发者，除了懂编程语言外，还得熟悉IDE、调试器和版本控制系统等工具，一个出色的AI代理也要学会充分利用自己的工具箱。

Composer上线一周后的表现：强化学习的成效

Sasha Rush分享了Composer发布后第一周的一些观察，这些数据让我对强化学习的潜力有了更深的理解。

他们认为强化学习有效的主要依据，就是随着运行越来越多的rollout-check-update循环，模型的表现不断提升。最初模型的表现大致与业界最好的开源模型相当，但经过训练后，在基准测试上的表现却以稳定的速度上升。图中的x轴是对数刻度，这显示他们在强化学习过程中投入了大量的计算资源，而模型的表现也因此得到了显著提升。

我觉得这对强化学习的可扩展性是个很好的信号，尤其是在复杂专业任务上的应用。尽管有很多人对强化学习能否在复杂的真实世界任务中发挥作用表示怀疑，但Cursor的经验表明，只要拥有足够的计算资源和合适的基础设施，强化学习确实能让模型在特定领域达到顶尖水平。

此外，他们还发现可以训练模型按他们认为对产品有用的方式来运行。Sasha Rush提到，他们希望模型在生成token时既要快，在整体用户体验上也要快。关键在于让模型能够调用并行工具。随着训练的深入，模型能够利用更多的并行工具，更迅速地响应用户的请求。他们认为在未来的训练中还可以进一步提升这一点。

这个发现特别有意思，因为它表明强化学习不仅能提升模型的“智能”，还能影响它的行为模式。通过合理的奖励设计，你可以让模型学会更高效的工作方式，比如并行任务、优先处理重要步骤等。这种行为层面的优化是传统的监督学习所难以实现的。

### AI模型构建的全新思考

最近有个有趣的发现，模型在学习的过程中不仅变得更聪明，还掌握了一些更好的操作方式。一开始，这个模型编辑得有些过于积极，甚至没有充足的依据就开始修改。可是，经过一段时间的训练，它开始更仔细地分析更多文件，进行深入的查找，以便准确找到需要修改的地方并作出合理的调整。这让我想到，编程不仅仅是写代码，更在于理解上下文，找到合适的切入点，做出明智的选择。通过强化学习，Composer学到了这些“软技能”。

更让人兴奋的是，用户们似乎对这个工具非常满意。Composer刚发布一周，大家普遍反馈它的速度和智能让编程方式发生了变化。现在，程序员们不再是启动一个代理后就去刷Twitter等待结果，而是能迅速获得反馈，接着就能处理下一个问题。作为程序员，我觉得这实在是太酷了。Sasha Rush提到，团队中很多开发者已经把它融入到日常工作中。我认为，这正是一个产品成功的最好证明：连开发工具的人都在日常使用它。

对专业化AI模型的深度思考

听完Sasha Rush的分享，我有一些感受想和大家聊聊。

首先，我觉得强化学习真的是打造专业化模型的绝佳选择。这在过去几年大语言模型的发展中已有所体现。强化学习让我们能够构建出专注于特定领域的高效模型。以前我们总是追求那种通用型的模型，但Cursor的经验表明，针对特定任务进行深度优化的模型，往往在该领域的表现要好得多。这让我想到，未来可能会有更多这样的专业模型出现，比如专注于数据分析、前端开发或系统架构的模型，每个领域都能做到极致。

另一个让我着迷的地方是，AI系统是如何改变研究和开发过程的。Sasha提到，他和他的团队现在的日常工作都依赖于他们自己正在开发的这些代理。他们用这些代理来构建仪表盘、后端等各种东西，这让小团队能快速行动。我觉得这真是个有趣的自我强化过程：你打造的AI工具不仅是为了服务用户，同时也在帮助你自己，促进工具的改进。这种良性循环可能会加速AI工具的演变。

最后，尽管Sasha Rush表示自己不是基础设施的专家，但他意识到，强化学习的进步实际上是由基础设施的提升所驱动的，这让他警醒。整合产品、规模和机器学习训练的过程是非常复杂的，几乎涉及到了现代软件系统的方方面面。我对此完全认同。在我看来，未来的AI公司不仅需要优秀的机器学习研究人才，还需具备顶尖的基础设施工程师。那些能将这两者结合得当的公司，将在竞争中占据巨大的优势。

从更广阔的视角来看，Cursor Composer的故事让我重新审视了AI工具的构建方式。传统方法是先训练一个通用模型，之后通过微调或提示工程让它适应特定任务。而Cursor则采用了完全不同的策略：从一开始就围绕特定任务（编程）来设计整个系统，包括模型架构、训练方法、基础设施和产品集成。这种端到端的思考方式，或许才是构建真正有用的AI工具的正确路径。

当然，我也在思考这种方法的局限性。强化学习需要大量计算资源，建立复杂的基础设施，并且要求产品与训练紧密结合。这意味着并不是每家公司都有能力采用这种方法。但对那些拥有资源和决心的公司来说，这可能是开发行业领先AI产品的最佳方案。Cursor已经证明了这条路径的可行性，我相信未来会有更多公司沿着这条路走下去。

此外，另一个值得思考的问题是，专业化模型的未来会是什么样子。Cursor Composer专注于编程，但同样的方法是否能运用到其他领域？比如，数据分析、内容创作、客户支持等领域会不会有专门的模型出现？我认为这肯定是有可能的，但每个领域都需要独特的基础设施、工具生态系统和训练方法。这并不是一件容易的事情，但对于能够做到的公司来说，回报将是巨大的。

### 创新源于理解用户需求

说到Cursor Composer的成功，这让我想起一个重要的道理：真正的创新其实不是跟着潮流走，而是要深入挖掘用户的真实需求，然后全力以赴去满足这些需求。Cursor团队没有被“大模型越大越好”的说法所迷惑，而是专注于解决开发者们的实际问题：如何让AI编程助手既聪明又迅速。他们采用了强化学习、自定义基础设施和产品集成等多种方法，最终交出了一款用户真心喜欢的产品。这种以用户为核心、以解决问题为导向的思维方式，我觉得是每个产品开发者都应该借鉴的。

本文由人人都是产品经理的作者【深思圈】发布，原创/授权，转载请联系原作者。

题图来自Unsplash，基于CC0协议。