Cursor 2.0重磅发布:自研Composer模型提速4倍,携8大智能代理并行编码!

Cursor 2.0 发布,自研Composer模型与多智能体并行,代码开发提速4倍,开启AI编码新范式。

原文标题:Cursor 2.0发布:自研代码模型 Composer 上线,8 个代理并行,速度提升 4 倍

原文作者:AI前线

冷月清谈:

Anysphere发布了Cursor 2.0,更新了UI界面,并推出了其首个自研、商用闭源代码大模型Composer。Composer主要亮点是其速度设计目标,官方宣称其速度“比同等智能的模型快4倍”,并专为Agentic工作流训练,支持规划、编写、测试与代码审阅等自主编码代理协同进行的工作。Anysphere研究科学家Sasha Rush介绍,Composer是经强化学习(RL)训练的混合专家(MoE)模型,旨在实现真实世界编码中的强大与快速。尽管团队对模型与开发环境进行了协同设计以确保高效运行,但关于Composer是完全从零训练还是基于现有开源权重训练的问题,团队并未直接给出答复,只强调其主要精力放在强化学习的后训练阶段。

Cursor 2.0还提供多代理界面,最多支持8个代理并行在隔离工作区中运行。它在底层代码智能栈做了大量优化,如LSP加速诊断与导航,尤其针对Python和TypeScript,以降低处理大型仓库或多文件改动时的延迟。该版本的设计理念也弱化了“手动查看/编写代码”的过程,转而强调通过提示词让代码代理来替用户执行工作,但部分用户可能仍偏爱终端编程的简洁高效体验。此外,Cursor 2.0新增了内置浏览器和语音模式,前者允许用户在IDE内运行和测试代码并将DOM信息反馈给模型,后者则提供了语音转文字控制功能,方便用户启动或管理代理会话。

怜星夜思:

1、Composer 模型到底是不是基于开源模型微调的?Cursor 团队对这个问题一直语焉不详,Sasha Rush 说主要精力放在强化学习后训练阶段。大家觉得这种“犹抱琵琶半遮面”的做法是商业策略还是技术上不便透露?对我们用户选择和信任这些闭源模型有什么影响?
2、Cursor 2.0搞了个“炼蛊模式”,可以支持8个代理并行工作。听起来很酷,但真实开发中,同时并行这么多代理去写代码,大家觉得是会提高效率还是反而会带来更多的管理和冲突问题?有没有人担心这种模式下,开发者最终会失去对代码的“掌控感”?
3、文章提到Cursor 2.0的设计理念是弱化手动写代码,强调用提示词驱动代理。这跟现在很多AI编程助手的发展方向一致。大家觉得未来编程真的会变成一种“提示词工程”吗?如果真是这样,我们这些“敲键盘”的码农,技能栈需要怎么调整才能不被淘汰?

原文内容

左右滑动查看更多图片

Cursor 2.0发布:自研代码模型Composer上线,8个代理并行,速度提升4倍
Anysphere今天发布了Cursor 2.0,更新了UI界面,并在这个版本中推出了其首个自研、商用闭源的代码大模型Composer。
 
Composer的最大亮点在于其速度设计目标。他们在公告中称其速度“比同等智能的模型快4倍”。模型还专为Agentic工作流训练,支持由自主编码代理协同进行的规划、编写、测试与代码审阅。
 
Cursor 研究科学家 Sasha Rush 在X上介绍:Composer 是一款经强化学习(RL)训练的混合专家(MoE)模型,“我们用RL训练了一个大型MoE,让它在真实世界编码中既强又快。”团队对模型与开发环境进行协同设计,使之能在生产规模下高效运行。
 
但他们的表述里有个关键细节始终不清楚:究竟是从零训练,还是基于已有的开源权重(如Qwen、GLM)继续训练?Sasha Rush一直在Hacker News回答提问,但至今都回避了关于底座模型的直接问题。有人直问“Composer是否只是对开源基础模型的微调?”她的答复是:“我们的主要精力放在强化学习的后训练阶段。我们认为,这是让模型成为强互动智能体的最佳路径。”
 
另外,Cursor 2.0提供多代理界面,最多支持8个代理并行(简直是炼蛊模式),每个代理在隔离工作区(git worktree或远程机器)中运行。并且在底层代码智能栈做了大量优化(如LSP加速诊断与导航,尤其面向Python、TypeScript),降低Composer处理大型仓库或多文件改动时的延迟。
 
尽管如此,Cursor 2.0的界面却让人联想起Web端的Codex。它延续了大约半年前由Claude Code带来的趋势:弱化了“手动查看/编写代码”的过程,转而强调通过提示词让代码代理来替你执行工作。不过,对于一位Claude Code的重度用户来说,他可能更青睐于在终端中编程那种简洁高效的体验。
 
Cursor 2.0还带来了内置浏览器和语音模式两大新功能。内置浏览器允许用户直接在IDE内运行和测试代码,同时将DOM信息反馈给模型。(这简直是“套娃”!Cursor本身是Electron架构,现在又在其中嵌入了一个Chromium浏览器。)而语音模式则提供了语音转文字控制功能,方便用户启动或管理代理会话。

哈哈,这就是AI界的“祖传秘方”呗!就像我家传的烧菜秘诀,你说我用的是不是市面上买的盐和酱油?是啊!但我用得巧啊!他不说清楚,大概是怕我们学去了自己也“炼蛊”吧。不过说实话,总觉得有点玩文字游戏的感觉,要是真的从零开始,肯定大张旗鼓宣传了。现在这样,反而让人有点好奇是不是有什么小秘密呢~

从技术角度看,Sasha Rush强调的“强化学习后训练阶段”确实是优化模型性能的关键步骤,尤其是在特定任务上。但如果它确实是基于某个强大的开源基础模型(如Qwen, GLM)进行的,那么在商业宣传上,故意模糊这一点可能旨在突出Anysphere自身的创新和投入,避免给用户留下“仅仅是微调”的印象。不过,用户在选择闭源服务时,确实会考量其底层技术的透明度,这涉及信任和长期依赖的问题。毕竟,开源基座模型的更新迭代,可能会间接影响到上层服务的性能上限和稳定性。

关于编程是否会变成提示词工程: 我觉得“提示词工程”肯定会越来越重要,但要说完全取代手动写代码,可能还为时尚早,或者说至少在可预见的将来不太可能。AI生成的东西,哪怕是GPT-4这种顶级的,你还是要review,还是要理解代码逻辑,甚至修修补补。如果自己完全不会写代码,怎么判断AI给的是不是最佳方案?怎么处理AI解决不了的复杂边界情况?所以,底层编程能力依然是基础,只不过我们要学会如何更好地与AI协作,用提示词加速常规工作,把精力放到更有挑战性的设计和解决难题上。

关于8个代理并行: 8个代理并行?我光是协调两个外包都够头疼的了,还要管理8个AI?想想就觉得大脑要冒烟。万一它们之间吵架了,或者跑去挖了一个没人知道的坑,最后让我来擦屁股,那不是更惨?我个人认为,初期肯定是噱头大于实用,除非真的有很智能的协调机制,否则我还是老老实实一个一个来吧,至少出锅的每一行代码我都认识,更安心。

关于8个代理并行: “炼蛊模式”听起来热血沸腾,但实际操作中,8个代理并行最大的挑战在于任务分解、状态同步和冲突解决。当多个代理独立在隔离工作区工作时,如何确保它们的目标一致性,以及最终的合并集成如何规避代码冲突和逻辑错误,会是一个巨大的工程难题。如果缺少一个强力的协调机制或智能仲裁系统,这种并行可能会把原本简单的问题复杂化,甚至带来难以预料的副作用,导致“1+1<2”的效率。

关于编程是否会变成提示词工程: 编程无疑正在向更高层次的抽象迈进。从汇编到高级语言,再到各种框架和库,每一次进步都在减少底层细节的关注,提升了生产力。现在AI的介入,无疑是将这一趋势推向极致,使“提示词工程”成为新的接口。这意味着,未来程序员的核心竞争力将不再是记忆API或敲代码速度,而是如何清晰地定义问题、设计系统、评估AI生成方案的质量,以及进行高效的调试和优化。理解业务需求和系统架构的能力会变得尤为重要,而不仅仅是“实现”能力。

我倒是觉得没必要太纠结。商业公司肯定都有自己的商业秘密,微软的Copilot也不是完全开源的,大家不也用得很开心?只要模型好用、效果显著,能真正解决我编码中的痛点,管它是从零训练还是微调的呢。关键是看最终的生产力提升。至于信任嘛,哪个闭源的服务不是在赌?用着用着觉得不好就换呗。

关于8个代理并行: 我觉得这绝对是未来的方向!设想一下,一个代理负责前端,一个代理负责后端API,一个代理负责数据库模型,一个代理进行单元测试,一个代理做文档生成,还有两个代理互相review代码。如果AI真的能做到智能协调和沟通,那开发效率简直是指数级提升。至于掌控感,我们人类开发者未来可能更多的是充当“项目经理”和“架构师”的角色,而非具体的“码农”,任务从写代码变成审视和指导代理,掌控的是更高层面的设计和方向。

关于编程是否会变成提示词工程: 嘿!要是真的变成提示词工程,那可太好了!以后再也不用天天盯着屏幕敲代码敲到颈椎病了!我可以躺在沙发上,对着AI说:“喂,给我实现一个带动态库存管理和多语言支持的电商后端!”然后AI就开始辛勤工作,我只需要时不时哼唱几句“加油,打工人,打工魂!”就行。当然,我也得学着怎么把需求说得更“AI友好”,搞不好以后面试题变成“请用最简洁的提示词让AI完成以下功能!”哈哈!