Cursor、Claude Code 和 Codex 都在运行前沿模型，但为何结果完全不同？

作者：AI拉呱（Errol Yan）
定位：AI领域深度内容与实战方法分享

你的 AI 编程助手在你乘坐火车时刚刚交付了一个 PR。它附加了一段视频，展示自己点击 UI 来证明功能有效。它解决了自己的合并冲突，并压缩为单个提交。这不是演示。Cursor 自己已合并的 PR 中，有 35% 是这样产生的。但这是大多数工程师看到这一点时所忽视的：该代理内部的模型（GPT-5、Claude、Gemini）是堆栈中最不有趣的部分。让它工作的是围绕模型的一切：VM 隔离、代码库入门、平行编排、视频工件捕获和多模型路由。Cursor 称之为云代理。更准确的术语是代理框架。

为什么这很关键

• Cursor 云代理在隔离的 Linux VM 中运行自主编码任务，拥有完整的开发环境。每个用户可并行运行 10 到 20 个代理。
• 突出功能：代理构建、测试，并使用他们创建的软件，然后在 PR 中附加视频证明。这不是自动补全。这是委托工程。
• Cursor 自己已合并的 PR 中有 35% 来自代理。Cursor 3“Glass”围绕代理编排重新构建了整个 IDE。
• 模型是商品输入。Cursor 路由 GPT-5、Claude Opus、Gemini 和自己的 Composer 2。周围的框架才是你付费的对象。
• Claude Code 和 OpenAI Codex 用根本不同的框架解决相同问题，证明了模型层是可互换的，但框架层不是。

从“AI 建议代码”到“AI 从端到端交付测试功能”的转变

这种转变正在发生，而且比大多数工程团队预期的要快。2025 年 10 月，Cursor 推出云代理作为后台工作者。到 2026 年 2 月，这些代理可以控制自己的计算机：打开浏览器、点击 UI，并录制工作证明的视频。到 2026 年 4 月，Cursor 3 完全去掉了聊天面板，围绕一个代理窗口重新构建了 IDE，开发者在这里可以像项目经理一样调度和监控自主任务。

这超越 Cursor 很重要，因为代理框架模式无处不在。Claude Code 使用 worktree 隔离来交付后台代理。OpenAI Codex 从 GitHub issue 运行沙盒任务。GitHub Copilot 添加了自己的编程代理。每个工具汇聚到同一个承诺：AI 在工作时你做别的。但实现完全不同。理解 Cursor 的框架，能帮你看懂为什么差异永远不只在模型，而是在模型外面的系统。

引擎 vs. 汽车

你不会单为引擎买车。你买的是底盘、悬挂、变速器、安全系统和把它们联系在一起的仪表板。引擎是可互换的：用电机换掉 V6，汽车照样跑。云代理也是这样。LLM 是堆栈底部的一个组件。框架是上面所有使原始模型能力对交付代码真正有用的东西。

Cursor 的框架有五层。顶部是界面层：任务进入的地方（Slack、GitHub、移动端、IDE）。下面是编排层：如何规划工作、选择哪个模型以及有多少代理并行运行。然后是执行层：代码实际运行的地方（隔离的 VM，不是你的笔记本电脑）。接着是验证层：代理如何证明其输出有效（计算机使用、视频、截图、日志）。最后是输出层：开发者收到什么（带工件的 PR，而不是聊天消息）。

模型位于所有五层下方。你可以交换 GPT-5、Claude、Gemini 或 Composer 2，框架表现仍然可以保持一致。Cursor 真正定价的，不只是模型能力，而是把模型组织成可交付生产结果的整套系统。

框架的五层

1. 代码库入门：在写第一行代码前理解你的项目

代理在写任何代码前先阅读仓库。Cursor 构建了专门面向大型代码库检索的嵌入模型。云代理启动时，子代理会并行探索代码库不同部分：有人索引前端组件树，有人梳理 API 路由，还有人读取数据库 schema。最终形成一张上下文地图，让代理在动手前就具备工作级理解。

对于新仓库，还可以先做 onboarding。代理会自己配置环境、安装依赖，并录制一个可运行应用的演示视频。你看这个视频，就能判断代理是否真的理解了项目。

2. VM 隔离：无限平行代理，零资源竞争

每个云代理获得一个隔离的 Linux VM，带完整开发环境：文件系统、终端、浏览器和运行中的应用实例。你的笔记本不再承担代理运行负担，因此代理之间、代理和人之间都没有资源抢占。

这也是并行化真正成立的前提。你可以同时跑 10 到 20 个代理，每个都在自己的沙盒里，处理不同任务和不同分支。

3. 编排：计划模式、模型路由和竞速模式

复杂功能通常分两步：先在本地与模型一起把计划敲实，再把计划发给云代理执行。你去做下一件事，代理在后台持续工作。

模型路由则发生在框架层，而不是开发者层。Cursor 会根据任务性质自动选择合适模型：GPT-5 适合长时间跨度任务，Claude 擅长重推理子任务，Gemini 适合处理大上下文，Composer 2 处理常规编码工作。

更有意思的是竞速模式：同一个问题交给多个模型并行求解，然后选择结果最好的那一个。这个机制本身说明，模型并不是唯一壁垒，决定质量的是谁来组织模型、如何组织模型。

4. 验证：计算机使用、视频和日志证明

最关键的一步，是代理不只会“写代码”，还会“用代码”。它会构建应用、打开浏览器、访问 localhost、点击按钮、填写表单、切换页面，并验证 UI 是否如预期渲染。

如果它在验证时发现问题，不会停下来报告失败，而是返回代码继续修复、重建、再测试。直到通过为止。随后，它还会记录演示视频、截图和日志，并把这些工件附在 PR 上。

5. 输出：带有工件的 PR

云代理交付的 PR 不只是 diff，而是diff + 视频演示 + 截图 + 日志 + 干净提交历史。这让审查行为从“读代码并脑补是否能跑”变成“看证据判断这是不是我们真正想要的结果”。

对采用这种工作流的团队来说，代码审查的重心从“它能不能跑”转移到了“这是不是对的产品决策”。这是一种很大的注意力再分配。

将框架映射回工作流

现在再把整条链路映射回五层结构：

• 界面层：Slack、GitHub、移动端、Web 和 IDE，负责把任务送进系统。
• 编排层：计划模式、模型路由、竞速、多代理分派，负责决定怎么做、由谁做。
• 执行层：VM 隔离与自托管方案，负责决定代码在哪里运行、信任边界如何划分。
• 验证层：计算机使用、视频录制、截图与日志，负责把“看起来完成了”变成“有证据证明完成了”。
• 输出层：最终交付给开发者的带工件 PR。

这个结构的重点不在概念，而在结论：模型可以换，框架不能随便换。

为什么这对 AI 编程工具竞争力关键

当所有厂商都能调用 GPT-5、Claude 或 Gemini 时，模型本身不再足以构成长期壁垒。真正的竞争点，是谁能构建出更强的代理框架。

具体看，至少有四个维度：

1. 代码库理解能力：能否快速、稳定地建立项目上下文。
2. 隔离能力：能否在不干扰用户机器的前提下大规模并行运行代理。
3. 验证能力：代理能否自己运行并验证结果，而不是只吐出代码。
4. 路由能力：能否把不同模型组织成更高质量、更低成本的执行系统。

这些能力大多都不是模型本身提供的，而是系统工程问题。

这对开发者意味着什么

如果你正在选择任何云代理工具，你实际上不是在选择一个模型，而是在选择一个框架。评估时，至少要看这些问题：

• 它理解代码库的速度和方式是什么？
• 它是在你的机器、本地 worktree，还是隔离云 VM 中运行？
• 它会不会自己验证结果？有没有视频、截图或日志证据？
• 它是否支持多模型路由，而不是被单一模型绑定？
• 代码和执行环境由谁托管，信任边界在哪里？

这些问题的答案，决定了这个代理工具在现实工作中到底有多大价值。

底线结论

Cursor、Claude Code、Codex 都可以运行前沿模型，但它们交付出的结果仍然会完全不同。根本原因不在于它们选的是哪一个模型，而在于它们给模型搭建了哪一层系统。

换句话说，模型是引擎，框架才是整辆车。

接下来几年，真正决定 AI 编程工具胜负的，不是谁先接入下一个大模型，而是谁更早把代码库理解、执行隔离、结果验证、工件交付和多模型协同这五层能力做成稳定可扩展的产品。

---

关注 AI拉呱

如果这篇内容对你有启发，欢迎关注「AI拉呱」，获取更多 AI 前沿洞察、实战教程与趋势解读。

下期在看

下期将继续带来该主题的进阶拆解与实操案例，建议先收藏本文，避免错过更新。