Cursor 推出 Composer 2.5，也就是被称作 “编程新王” 的 Agent 编程模型，宣传核心是在主流编程评测上逼近 Claude Opus 4.7，但 Token 成本大约只有后者的 1/10；它并不是全新基座，底层基于月之暗面 Kimi K2.5，Cursor 把大部分算力投入到长任务强化学习、合成数据后训练，专门针对 Cursor 编辑器内的 Agent 工作流优化，擅长长时间持续改代码、读仓库、执行终端命令、网页调试，解决 Claude Code、Opus 4.7 跑 Agent 循环时 Token 账单太贵的痛点。
一、基础信息与跑分
- 发布：2026-05-18，Cursor 内置模型
- 基座：Kimi K2.5，85% 的算力用于后续 RL 与专项训练
- 两个版本：标准版、Fast 快速版（默认开启）
- 定价：标准版输入 0.5 美元 / 百万 token，输出 2.5 美元 / 百万 token；Fast 版输入 3 美元 / 百万 token，输出 15 美元 / 百万 token
- 发布福利：上线首周双倍赠送额度
| 评测 | Composer 2.5 | Opus 4.7 | GPT-5.5 | Composer 2 |
|---|---|---|---|---|
| SWE-Bench Multilingual | 79.8% | 80.5% | 77.8% | 73.7% |
| Terminal-Bench 2.0 | 69.3% | 69.4% | 82.7% | 61.7% |
| CursorBench v3.1（高难任务） | 63.2% | 64.8%(max)/61.6%(默认) | 64.3%(xhigh)/59.2%(默认) | 52.2% |
数据说明：Composer 2.5 在 SWE-Bench 几乎追平 Opus 4.7；在 Cursor 自家的高难 CursorBench，默认档位下 Composer 2.5 反而优于 Opus 4.7 默认档，只有 Opus 拉满最高算力档位才小幅领先。
二、Composer 2.5 和 Opus 4.7 路线差异
| 项目 | Composer 2.5（Cursor） | Claude Opus 4.7 |
|---|---|---|
| 定位 | Cursor 编辑器内闭环 Agent 编程 | 通用大模型，编程只是其中一个能力 |
| 上下文 | 200K | 1M |
| 优势 | 长任务 Agent 性价比高、持续迭代稳定、价格低 | 综合能力更强、超大上下文、多模态更强 |
| 短板 | 脱离 Cursor 编辑器生态后优势下降 | 跑 Agent 循环成本昂贵，长任务账单容易失控 |
| 适合场景 | 仓库重构、批量改代码、持续调试、终端自动化 | 复杂综合任务、长文档阅读、多模态 + 编程混合场景 |
三、核心优化方向
- 长程任务强化学习：Composer 2.5 的合成训练任务量是 Composer 2 的 25 倍，重点优化 “做一半不跑偏、记住之前的修改、正确执行测试”，适合持续几轮的 Agent 工作流。
- 工具链深度绑定：原生支持读文件、批量搜索、编辑代码、执行 shell、浏览器截图测试，是为 Cursor 的 IDE 环境量身调优。
- 成本效率优先：不是单纯堆能力，而是控制每一轮 Agent 调用的 Token 消耗，降低开发者跑自动化编码的门槛。
✅ 优势
- 性价比突出，对于高频 Agent 编码、仓库重构这类重度场景，账单压力显著降低
- 在 CursorBench 这类贴近真实开发的测试里，表现接近前沿模型
- 对长周期迭代任务的稳定性比前代 Composer 2 提升很大
⚠️ 客观局限
- “1/10 成本” 是同任务对标下的宣传口径，不是所有场景都严格刚好 10 倍差距；Terminal-Bench 这类专项 Opus/GPT 依然有优势
- 底层是 Kimi K2.5 二次调优，不是从零自研基座，脱离 Cursor 生态之后，能力优势会弱化
- 上下文窗口 200K，小于 Opus 4.7 的 1M，超大仓库一次性全量读取场景受限
四、适合和不适合场景
✅ 适合：前端 / 后端项目重构、批量修复 bug、自动化测试脚本、在 Cursor 内持续迭代的 Agent 编码工作流
❌ 不适合：一次性超大文档通读、多模态复杂需求、需要脱离 Cursor 独立调用模型的场景
五、行业意义
Composer 2.5 代表 AI 编程赛道的一个方向：不再只比拼纯基准跑分，而是针对 IDE 闭环 Agent 做 “性价比调优”。之前 Claude Code、Opus 虽然强，但持续跑 Agent 很容易出现天价账单；Composer 2.5 的打法，就是用更低 Token 成本，把长周期自动化编码变成可以常态化使用的工具。
【相关 FAQ】
问题 1：Composer 2.5 是哪个产品的模型，它的基座是什么？
回答 1：Composer 2.5 是 Cursor 编辑器内置的 Agent 编程模型，底层基座是月之暗面 Kimi K2.5，Cursor 投入大量算力做编程专项强化学习调优。
问题 2：Composer 2.5 逼近 Opus 4.7，跑分差距有多大？
回答 1：在 SWE-Bench 只差 0.7 个百分点；CursorBench 上 Composer 2.5 默认档优于 Opus 4.7 默认档，Opus 只有开到最高算力档位才小幅领先 Composer 2.5。
问题 3：Composer 2.5 成本仅为 Opus 4.7 的 1/10 是什么意思？
回答 3：指在 Cursor 官方测试的同类编程 Agent 任务上，Composer 2.5 完成同样任务的 Token 开销和总价大约只有 Opus 4.7 的十分之一，是对标场景下的效率对比，不是所有场景都严格固定 10 倍。
问题 4：Composer 2.5 有两个版本，Fast 版和标准版区别是什么？
回答 4：Fast 版是默认开启，速度更快、单价更高；标准版更便宜，适合不追求极致响应速度、优先控制账单的重度任务。
问题 5：Composer 2.5 和 Claude Code（Opus 4.7）该怎么选？
回答 5：如果你长期在 Cursor 里面跑长周期 Agent、重构代码、在意预算，优先 Composer 2.5；如果你需要超大上下文、多模态、跨场景综合能力，Opus 4.7 更合适。
【参考资料】
[2026-05-18] Cursor 官方博客 Composer 2.5
[2026-05-19] 36 氪《不换 Kimi 底座，1/10 成本追平 Opus 4.7?Cursor 用 Composer 2.5 反击 Claude Code》
[2026-05-19] 36 氪《编程新王 Composer 2.5 来了，逼近 Opus 4.7！成本仅为 1/10》
【免责声明】
本内容基于 Cursor 官方公开评测与媒体报道解读；“1/10 成本” 是官方对标测试场景下的宣传结论，实际账单受提示词、任务复杂度、上下文长度影响；Composer 2.5 能力绑定 Cursor 编辑器生态，跨环境使用效果会变化；选型时建议结合自己的开发场景、预算实测对比，内容提供方不对 Token 账单、开发效果承担责任。