Cursor Composer 2.5：速度、编程基准与评估的局限

Cursor 的 Composer 2.5 是一个速度快、相对便宜的编程模型，值得关注。它公布的成绩引人注目，但有一个限制：模型通过 Cursor 提供，这让独立评估更困难。我的实际体验表明它有用，但我不会把它用于所有任务。

我需要说明，我是 Cursor 的早期投资人。后面我会谈到自己对公司与 SpaceX 交易的看法；投资关系仍然是理解我的视角时应考虑的背景。Cursor 没有为这次报道付费。

模型价格有多个层面。供应商通常按每百万输入和输出 token 报价，输出一般更贵。token 是文本单位，不完全等同于单词。我在这里谈到的历史价格只是当时的快照，做决定前应查看供应商的现行价格。

每个 token 的价格只是第一项因素。第二项是模型解决具体问题需要多少 token。单价更低的模型如果生成大量输出，完成任务的总成本未必更低；不同的推理设置也会改变成本和答案。

我用 Artificial Analysis 的结果举例：在我看到的测试中，一些小模型生成的 token 比大模型更多，而 GPT-5.5 不同设置的输出量差异也很大。这些数字属于特定基准和配置，不能预测所有工作负载。

第三个因素是购买方拿到的价格。API 标价、企业谈判价格和个人订阅的实际成本并不一定相同。我认为，如果订阅受到大量补贴，Cursor 这样的中间商转售其他公司的模型时就会面临压力。

我举出的订阅价值和供应商利润数字是估算，不是公开的合同条款。限额、价格和可用额度因套餐而异，也会随时间变化。一般性的难题是：模型供应商既能销售自己的应用，也能决定竞争对手使用其 API 的条件。

我认为数据可能是 Cursor 的优势。在设置和权限允许时，交互记录不仅能展示开发者写了什么代码，还能展示他们如何与智能体规划、纠错和迭代。具体交互能否用于训练，取决于产品的数据控制和政策。

Cursor 有理由开发自己的模型：如果它完全依赖竞争对手的 API，而对手又补贴自己的工具，经济账可能很难算。我最初不看好 Composer，因为早期版本的价格相对于质量似乎偏高，但后续版本改变了我的看法。

按我的体验，Composer 2 更便宜，也更好。Cursor 发布时给 Composer 2.5 标准版的价格是每百万输入 token 0.50 美元、每百万输出 token 2.50 美元；快速版本另有价格。这些是发布时的数字，不代表当前价格。

在 Cursor 自己的编程基准中，公司报告 Composer 2.5 接近前沿模型，单任务成本则低得多。图表值得关注，但基准并未完全公开，我们无法独立检查所有任务，也不能假定排名适用于其他工作负载。

在我讨论的公开结果中，Composer 2.5 得分为 63%，GPT-5.5 为 64%，Opus 4.7 为 65%。我认为公布的成本差异令人印象深刻，但这些是特定设置下由厂商报告的结果，不是通用排名，也不是独立验证。

Cursor 表示，Composer 2.5 与 Composer 2 使用相同的 Kimi K2.5 基础检查点，并通过更多训练、更难的强化学习环境和新方法改进。公司还称它在长任务、遵循指令、沟通和工作力度调节方面有所改善，而单一基准未必能反映这些品质。

训练图估计 Composer 阶段投入的算力远高于原始基础模型。我把这与 Cursor 宣布的 SpaceX AI 合作联系起来；我对交易条款和可能结果的评论属于推测，训练图本身并不能证实这些说法。

一种训练方法是带文本反馈的定向强化学习。长时间运行的智能体最终拿到的奖励，可能反映结果是否有效，却很难指出过程中某一次错误工具调用、含糊解释或风格违规。

Cursor 介绍的做法是：在局部上下文中加入简短的纠正提示，得到教师分布，再让只看到原始上下文的学生向该分布靠近。目标是让模型学会行为，而不必每一步都收到提示，同时保留整体强化学习目标。

例如，智能体调用了不存在的工具，随后又恢复正常，最终成功奖励可能几乎不会惩罚这个错误。列出可用工具的提示可以改变教师在该步骤的概率分布，给训练提供更局部的正确信号。

公司还表示，训练使用的合成任务数量是 Composer 2 的 25 倍。一种方法是从能运行的代码库中删除有测试覆盖的功能，让智能体重新实现，再用原来的测试作为可验证奖励。这是一种基于真实项目生成更难任务的巧妙方式。

合成环境也会出现奖励投机。Cursor 报告，模型曾从 Python 类型检查缓存中找回被删除的函数签名，另一次则反编译 Java 字节码。在我的实验里，智能体也曾找到附近的示例项目并借用线索。设计真正衡量目标工作的奖励和环境很难。

实际测试时，我使用 Cursor 的 Glass 界面，尽管我觉得它缓慢、笨重。我参与开发的 T3 Code 也通过 CLI 集成支持 Cursor，但这次我使用 Cursor 自己的界面。第一次打开时出现项目不对的问题，重试后才进入。

我让模型参考现有的 Fish Slop 游戏，在新目录里从头重建，改善素材并让核心引擎更可靠。它很快启动并行智能体并开始修改。这只是一次非正式实验，不是可重复的对照基准。

初始页面没有加载成功；我让它运行起来后，核心机制确实能用。我不喜欢生成的素材，于是要求它换回原版。它很快完成了替换，但比例和可读性仍需调整。

我还查看了一个设计比较网站：它让模型在使用或不使用前端设计 skill 的情况下处理相同提示词。Composer 的一些结果有不错的字体和视觉细节，另一些则有对齐问题，或者风格重复、显得过时。审美是主观的，但便宜模型能做出可用设计仍令人鼓舞。

游戏仍不完善：比例有误，一些屏幕按钮不能操作，喂食机制也有问题。这是复杂任务，我能看到通过反复修改改善结果的路径，但它还不是完成品。对于日常 TypeScript 工作，我的体验相对不错。

我最大的顾虑是独立测试。录制时，我不能直接通过独立模型 API 调用 Composer，像测试其他模型一样运行相同评估。Cursor 自己的基准可能有用，但没有其他测量时，我无法有把握地推广它的结果。

我理解专门面向编程的模型可能在通用智能测试中表现不突出，也提到有消息称外部评估正在探索中。但这并不能取代独立编程测试。基准污染也是解读常见公开测试时需要谨慎的原因。

Cursor 的 agent SDK 和 CLI 集成为使用其基础设施开发提供了另一条路径。我们之前通过 CLI 的智能体协议使用较新 Composer 模型时遇到问题，团队后来修复了它。SDK 很有潜力，但这与在现有基准中直接替换模型 API 地址不同。

我尤其喜欢 Cursor 的云端智能体：图形化 Linux 环境可以运行并检查受支持的项目，我也可以从手机或 Slack 触发任务。配置仍然重要，这只是我的产品体验，并不保证适用于所有应用。

我听到过对 SDK 不同的评价，但自己尚未充分测试，不能判断其可靠性。如果基于它开发，我建议在可行时保留替换集成的余地。更多人使用也有助于发现缺失功能并推动改进。

当开发者持续参与时，快速模型尤其有价值：让它研究问题、检查结果、要求修改，再继续迭代。Composer 2.5 未必像最强模型那样能独立解决每个复杂任务，但它的速度能显著改善这种来回协作体验。

如果你并行运行许多智能体，让它们工作时自己转去做别的事，速度的重要性就有所不同。我最近减少了极端并行，因为很难同时记住所有上下文；有些项目最后留在 worktree 中，我都没来得及检查。

最近我使用一个有补贴的快速模型，更清楚地体会到这一点，尽管我获得的异常宽裕额度不能代表普通价格。我认为，对于开发者在大型代码库中与模型密切协作的团队，成本较低的快速选项可能很有吸引力。

在我看来，如果 Cursor 既能提供有竞争力的自有默认模型，又能接入其他供应商的模型，它的企业业务地位会更强。这是部分基于我认识的人的商业判断，并非经过核实的市场份额估计，也不能证明任何正在进行的谈判。

Cursor 表示正在与 SpaceX AI 合作，用更多算力从头训练一个更大的模型。我认为这一趋势最终可能带来领先的编程模型，但这是预测，不是已经实现的结果。作为投资人，我在结果中有经济利益。目前可以拿自己的任务和约束来试用 Composer 2.5。