AI编程助手自己提PR、附视频?Cursor的“委托式工程”来了!

模型是商品，架构才是产品：揭秘 Cursor 云代理的真实架构

当你还在火车上时，你的 AI 编程助手已经提交了一个 PR。它附上了自己点击用户界面 (UI) 的视频，以证明功能正常。它还自行解决了合并冲突，并 squash 为一个单一的 commit。这不是演示。目前，Cursor 自身 35% 的已合并 PR 都是通过这种方式产生的。但大多数工程师在审视这一现象时，却忽略了关键一点：该代理内部的模型（如 GPT-5、Claude、Gemini）在整个技术栈中是最不值得关注的部分。真正让它发挥作用的是模型 之外 的一切：虚拟机 (VM) 隔离、代码库集成、并行编排、视频工件捕获以及多模型路由。Cursor 将其称为云代理，但更精确的术语是“支撑系统”（harness）。

核心要点

重要性

从“AI 建议代码”到“AI 端到端交付经测试功能”的转变正在加速发生，其速度远超大多数工程团队的预期。2025 年 10 月，Cursor 将云代理作为后台服务推出。到 2026 年 2 月，这些代理已能够操控自己的计算机：它们可以打开浏览器、点击用户界面 (UI)，并录制工作成果的视频证明。到 2026 年 4 月，Cursor 3 彻底移除了原有的聊天面板，并围绕一个“代理窗口”重构了整个 IDE，使开发者能够像项目经理审查工作一样，在此窗口中调度和监控代理的自主任务。

这不仅仅对 Cursor 至关重要，因为编排框架模式正在各个领域兴起。Claude Code 集成了支持工作区隔离的后台代理。OpenAI Codex 可针对 GitHub issue 执行沙盒化任务。GitHub Copilot 也新增了自己的编码智能体。所有工具都指向同一个核心承诺：AI 会在你处理其他事务时自行运作。然而，它们的实现方式却截然不同。理解 Cursor 的编排框架，能让你学会如何评估所有同类产品，因为决定其差异性的从来不是模型，而是包裹在模型之外的基础设施。

引擎与汽车之辩

人们购买汽车，并非只看重引擎本身，而是为了底盘、悬架、变速系统、安全系统以及将所有这些整合在一起的仪表盘。引擎是可互换的：即使将 V6 发动机替换为电动机，汽车依然能正常行驶。云智能体亦是如此。大型语言模型（LLM）只是技术栈底层的某个组件。编排框架则是其之上的一切，正是它让原始模型能力能够有效地用于交付代码。

Cursor 的编排框架有五层。最顶层是接口层：它是任务的入口（如 Slack、GitHub、移动设备和集成开发环境 (IDE)）。其下方是编排层：负责规划工作、选择模型以及决定并行运行的智能体数量。接着是执行层：代码的实际运行场所（在独立的虚拟机 (VM) 中运行，而非用户的笔记本电脑上）。再往下是验证层：智能体通过该层证明其输出有效性（通过模拟计算机使用、视频、截图和日志等方式）。最后是输出层：开发者将在此接收最终成果（一个包含工件的拉取请求 (PR)，而非简单的聊天消息）。

模型位于这五层之下。你可以用 GPT-5 替换 Claude，再替换 Gemini，乃至 Composer 2，而整个编排框架的行为模式依然保持一致。这并非纸上谈兵。Cursor 确实如此实践：它会在同一个智能体会话中，将不同的模型路由到不同的子任务；同时，它也能让多个模型并行执行同一任务，以选出最佳结果。模型是引擎，编排框架则是汽车。而 Cursor 高达 293 亿美元的估值，正是对这辆“汽车”的价值认可。

Cursor 云智能体内部探秘

代码库接入

代理在编写任何一行代码之前，会先读取你的代码库。Cursor 构建了一个定制化的嵌入模型，专门用于在大规模代码库中实现代码召回。当一个云代理启动时，子代理会并行展开，探索代码库的不同部分，每个子代理都使用最适合其子任务的模型。一个子代理可能负责索引前端组件树，另一个负责映射 API 路由，而第三个则读取数据库 Schema。最终形成一个上下文地图，使代理在接触任何文件之前，就能对项目有实际的工作理解。

对于新代码库，你可以在 cursor.com/onboard 启动引导流程。代理会自行配置环境，安装依赖项，并录制一份工作应用程序的演示视频。你可以观看演示，以验证代理是否正确理解了你的项目。这并非一个简单的 README 解析器，而是通过主动探索你的代码库，生成一个经过验证的基线。

VM 沙箱

每个云代理都拥有一个独立的 Linux 虚拟机 (VM)，其中包含完整开发环境：文件系统、终端、浏览器和正在运行的应用程序实例。你的笔记本电脑不会介入其中。代理之间不存在资源竞争，代理与你之间也不存在资源竞争。这种隔离正是实现并行性的基础。你可以同时运行 10 到 20 个代理，每个都在自己的沙箱中，每个都在完全不同的分支上执行完全不同的任务。

在云代理出现之前，本地代理模式意味着你的机器需要承担双重任务：运行编辑器、运行代理，以及运行正在测试的应用程序。一台笔记本电脑上运行三个代理，意味着内存压力、端口冲突以及类似喷气式飞机引擎的巨大风扇噪音。云虚拟机 (VM) 消除了所有这些问题。每个代理都获得一个纯净的环境，不会干扰其他任何事物。

2026 年 3 月，Cursor 为企业团队发布了自托管云代理。功能相同：独立的虚拟机 (VM)、完整的开发环境、多模型工具链 (harnesses)、插件。不同之处在于，你的代码库、构建输出和秘密数据永远不会离开你的网络。代理会在你的基础设施上本地处理工具调用。相同的工具链，不同的信任边界。

规划模式和模型路由

Cursor 处理复杂功能的工作流分为两个阶段。首先，用户在本地与模型协作迭代，创建一个详细的计划，包括功能应实现什么、涉及哪些文件以及具体的验收标准。一旦计划敲定，用户便将其发送给云代理进行实施。至此，用户可以继续处理下一个任务，云代理将在后台按照预设方案执行。

模型路由发生在 harness level，而非 developer level。Cursor 根据任务类型和复杂性，为每个子任务选择最合适的模型。其中，GPT-5 Codex agent harness 经过专门改造，以适应云端长时间跨度任务。Claude 负责处理推理密集型子任务，Gemini 则能高效处理大型上下文窗口。Composer 2 是 Cursor 自研的模型，通过用户交互进行强化学习训练，它能出色地完成常规编码，并在高难度任务中表现优异。

最有趣的编排模式是“竞赛”（race）。Cursor 会将同一个问题并行分发给多个模型，并从中选择最佳结果。团队报告称，这显著提升了最终输出质量，特别是对于那些需要少量精准修改的复杂 bug 而言。这也是为什么模型锁定（model lock-in）在 harness level 并不重要的原因。harness 负责运行这场“竞赛”，而模型则是参赛者。

计算机使用

2026 年 2 月 24 日，Cursor 发布了一项能力，使其云代理与以往任何系统都截然不同。现在，代理能够使用它们自己创建的软件。每个虚拟机（VM）都包含一个浏览器，代理可以构建应用程序、启动、导航到 localhost，并像人类一样与用户界面（UI）进行交互：点击按钮、填写表单、浏览页面，并检查元素是否正确渲染。

当代理在此验证过程中发现问题时，它不会停下来报告失败，而是会返回代码，修复问题，重新构建，然后再次测试。这一循环会持续进行，直到代理验证其更改确实有效为止。当验证通过后，代理会录制整个会话的视频，截取关键状态的屏幕截图，并收集日志。所有这些都将作为工件（artifacts）附在 pull request 中。

Cursor 内部一直在自研自用（dogfooding）这项功能。他们使用云代理为 Cursor Marketplace 构建源代码链接：该代理实现了相应功能，导航到导入的 Prisma 插件，点击每个组件以验证 GitHub 链接是否正常工作，然后变基（rebase）到 main 分支，解决了合并冲突，并压缩（squash）为一个单独的提交。在安全工作中，他们从 Slack 启动了一个云代理，用于分类处理剪贴板数据外泄漏洞。该代理构建了一个利用页面，启动后端服务器，在浏览器中加载，并记录了完整的攻击流程。总结报告随后显示在 Slack 线程中。

PR (Pull Request) 即为证明

云代理提交的拉取请求（PR）并非仅仅是代码差异（diff）。它不仅包含代码差异，还附带视频演示、截图、日志以及一份清晰的提交历史记录（其中包含变基、冲突解决和压缩）。在评审此类 PR 时，你无需逐行审阅代码并进行心智模拟以判断其是否可行。你只需观看代理演示功能的 30 秒视频。这从根本上改变了代码评审的瓶颈：你的重点是验证开发意图，而非执行细节。

对于已采用此工作流的团队，代码评审的讨论焦点也随之转变。评审人员不再关注“它是否能正常工作？”，而是开始探讨“这是否我们真正想要实现的效果？”。机械性的验证工作由代理自动处理，而人工的判断力则专注于产品决策。这无疑是对工程精力的一次有意义的重新分配。

对标 Harness 架构

既然你已经了解了实际运行情况，下面我们将阐述它如何与上一节中提及的 Harness 架构堆栈对应。Harness 的每一层都与你刚才所了解的工作流程的某个环节相对应。

接口层。 云代理可以从 Slack、GitHub、Linear、cursor.com/agents（网页版）、移动设备或桌面 IDE 触发。Cursor 3 中的代理窗口（Agents Window）用一个持久化编排面板取代了传统的聊天面板：任务卡片会显示“规划中”、“执行中”、“评审中”或“已完成”等状态，并附带文件差异（diff）和进度指示器。你可以分派多项任务，以卡片形式进行监控，并在结果就绪时进行评审。这种心智模型已从结对编程（pair programming）转向了项目管理。

编排层。 计划模式、模型路由、竞速模式和子代理分派等功能均在此层实现。本层负责决定工作如何完成以及由哪个模型来执行。如上图所示的竞速模式，Cursor 不局限于单一模型，而是通过在同一问题上同时运行多个模型并选择最优输出来采取对冲策略。

执行层。 本层涵盖虚拟机 (VM) 隔离和自托管选项，负责决定代码在哪里运行以及由谁控制运行环境。信任边界的划定也在此层：选择 Cursor 托管意味着代码将离开您的本地机器；选择自托管则表示代码将保留在您的网络内部。

验证层。 涵盖计算机使用、视频录制、屏幕截图捕获和日志收集等功能。这一层将代码差异转化为可验证的证据。若缺乏此层，云代理仅是远程代码生成器；而有了它，它们便成为能够展示其工作成果的自主工程师。

输出层。 以包含工件的 PR (Pull Request) 形式呈现。这是连接代理工作与开发者审查，从而形成闭环的交付格式。

整个工作框架 (harness) 由五层组成，底层是模型层。模型是可互换的，而工作框架本身则不可替换。

基于工作框架构建的平台

云代理工作框架是整个平台的基础。Cursor 在此之上构建了四项平台能力。

自动化。 事件驱动型代理可以在您无需在场的情况下，根据预设时间表或外部工具事件自动触发。一旦触发器被激活，Cursor 将启动一个云沙盒环境，并依照您的指令执行任务，调用您配置的任何 MCPs，并可选择性地记忆先前运行的结果，以便逐步优化改进。值得注意的一个限制是：目前自动化功能尚不支持模拟计算机操作，因此自动化代理无法进行视觉验证。

Bugbot 自动修复 (Autofix)。 Bugbot 最初是一个代码审查工具。现在，当它在你的拉取请求 (Pull Request, PR) 中发现问题时，它会在自己的虚拟机 (VM) 上启动一个云代理 (Cloud Agent)，测试一个修复方案，并直接将该修复方案作为建议提交到你的 PR。超过 35% 的 Bugbot 自动修复建议被合并到基础 PR 中。在六个月内，问题解决率（Bugbot 标记的问题在合并前得到修复的比例）从 52% 上升到 76%，而每次运行发现的问题平均数量几乎翻了一番。该工具不仅能发现更多问题，而且准确性也越来越高。

插件生态系统。 合作伙伴（包括 Atlassian、Datadog、GitLab、Glean、Hugging Face、monday.com 和 PlanetScale）提供了 30 多个插件。大多数插件包含 MCPs，云代理可以在手动启动或通过自动化方式启动时使用。这使得该系统成为一个集成平台：代理可以在单个任务中从 Jira 读取数据、向 Datadog 写入数据以及查询 PlanetScale。

Cursor 3 “Glass”。 该集成开发环境 (IDE) 于 2026 年 4 月 2 日发布，围绕代理编排 (Agent Orchestration) 进行了重构。代理窗口取代了聊天面板。多仓库布局 (Multi-repo layout) 允许代理在单个工作区中跨多个仓库进行读写操作。设计模式 (Design Mode) 提供了一个用于 UI 组件的可视化编辑器：在实时预览中点击一个元素，用自然语言描述更改，代理就会修改源代码，同时预览实时更新。Cursor 在发布时年化经常性收入 (ARR) 超过 20 亿美元，并占据了 AI 编程工具市场约 25% 的份额。

设计选择与权衡

Cursor 的成功之处

视频工件 (Video artifacts) 使审查速度提高 10 倍。 你验证的是意图，而非执行结果。一段 30 秒的视频就能捕捉到通过阅读代码差异 (diff) 无法发现的视觉回归问题 (visual regressions)。

并行代理 (Parallel agents) 为明确定义的任务成倍提高吞吐量。 当你专注于架构设计时，十个 Bug 修复任务可以同时运行。生产力计算很简单：如果每个代理在一个范围明确的任务上节省 30 分钟，那么十个代理在一次会话中就能节省五个小时。

多界面访问 (Multi-surface access) 让开发者在他们熟悉的现有工作环境中就能使用工具。 从 Slack 启动一个代理。在手机上审查拉取请求 (PR)。从 GitHub issues 分派任务。尽管界面层是该系统中最不引人注目的部分，但它消除了足够的摩擦，足以改变日常工作习惯。

自托管选项 (Self-hosted option) 消除了企业最棘手的顾虑。 “我们的代码不能离开我们的网络”曾是 Cursor Cloud 完全无法逾越的障碍。自2026年3月起，这一顾虑得到了解决：沿用相同的核心架构，部署在您的基础设施上。

Cursor 存在哪些不足（或尚未解决的问题）

隐式删除。 并行工作器 (Parallel workers) 偶尔会使用 // ... existing code ... 占位符注释，静默删除实际代码。您必须仔细审查代码差异。这并非罕见的边缘情况；多位独立评审员都曾指出此问题。

算力消耗。 繁重的代理式工作流 (Agentic workflows) 会迅速消耗算力配额。对于高度依赖并行代理的开发者而言，专业版套餐 (Pro plan) 的算力上限在月中便会触及。代理模式 (Agent mode) 每项任务会执行多次模型调用，每次大约花费0.04美元，其中 Claude Sonnet 的每次请求成本是 Gemini 的2.4倍。核心架构决定模型路由，而路由决策直接影响实际成本。

任务范围界定才是关键技能。 过于宽泛的任务（例如“重构认证模块 (auth module)”）会导致大规模改动，需要大量的审查工作。而过于狭窄的任务（例如“重命名此变量”）则显得杀鸡用牛刀。最佳实践是中等规模的离散任务，例如：“使用 /api/users 中现有的中间件模式 (middleware pattern)，为 /api/auth/login 路由添加限流 (rate limiting)。” 掌握这种范围界定需要数天的实践。

遗留代码库 (Legacy codebases) 面临挑战。 云代理最适用于结构良好、现代化、拥有统一约定和高测试覆盖率的代码库。如果将其应用于一个模式不一致的遗留单体 (legacy monolith) 项目，那么将需要更多的手动干预和更低的成功率。

代理恢复流程繁琐。 当代理 (Agent) 出现错误方向时，纠正工作流（暂停、描述错误、重新引导）相比于旧的对话式聊天模型 (conversational chat model) 增加了更多阻力。Cursor 3 的代理窗口 (Agents Window) 通过支持派生和重启的任务卡片 (task cards) 对此进行了改进，但其体验仍然不如 Cursor 2 的迭代式来回对话流畅。

影子代码 (Shadow code)。 对于 CTO 和工程经理而言，最大的运营担忧是 AI 自主编写的代码逻辑，人类开发者可能无法理解或进行适当审查。Cursor 的企业版套餐包含一个 AI 代码追踪 API (AI code tracking API) 和审计日志 (audit logs)，用于追踪哪些模型编写了哪些代码行。然而，审查的规范性必须源于团队，而非工具本身。

Claude Code 和 Codex 如何以不同方式应对

这并非对 Claude Code 或 OpenAI Codex 的产品评测。它是一场运行框架 (harness) 的对比。这三款工具解决的是同一个问题：让开发者在处理其他任务时，AI 能自主地交付代码。它们都采用了同级别的前沿模型。然而，由于运行框架截然不同，导致最终结果也大相径庭。

Claude Code 后台 Agent

Claude Code 在几乎所有维度上，都与 Cursor 采取了截然不同的架构策略。它采用终端优先（terminal-first）设计，代码始终保留在本地机器上，不涉及云虚拟机 (cloud VMs)。Claude Code 并未选择对大量 Agent 进行并行编排，而是专注于深度处理单个复杂任务：通过带有工作树隔离（worktree isolation）的子 Agent 生成机制，Claude 能够同时处理项目的多个分支而互不干扰，并且所有操作都在本地执行。

Claude Code 的优势体现在其强大的推理深度。凭借 Opus 模型和高达 20 万 token (tokens) 的上下文窗口，Claude Code 能够处理需要在大规模代码库中进行持续推理的架构重构和复杂的多文件变更。其 MCP 集成（MCP integration）是原生且深度融合的：Claude Code 通过一整套协议服务器生态系统，连接到本地工具、数据库和各种服务。

Claude Code 不具备的功能包括：视频记录 (video artifacts)、云虚拟机，以及图形用户界面 (GUI) 编排层。它的输出形式是代码差异 (diff) 和对话日志，而非附带视频证明的拉取请求 (PR)。其信任模型遵循“本地优先”原则：你的代码永远不会离开本地机器，这使得它成为那些对数据驻留有严格要求的团队的默认选择。

Dispatch 功能（已于 2026 年 3 月 17 日发布）增加了一个远程控制层：通过扫描二维码 (QR code)，你的手机就能成为与桌面端 Claude Code 会话进行“对讲”的设备。这解决了“AI 在你离开时也能工作”的问题，但其实现方式是单个 Agent 在一台机器上运行，而非通过并行的云虚拟机集群。

OpenAI Codex

==Codex 在云沙箱 (cloud sandboxes) 中运行任务，这些任务可以通过 Web 界面或 GitHub issue 触发。== 它的运行框架 (harness) 比 Cursor 更为简洁：一次处理一个任务，与 GitHub 紧密集成，没有视频记录，也不存在模型竞速。其核心设想是，大多数有价值的 Agent 工作都始于 issue 跟踪器中明确界定的 issue，并最终以 PR 告终。

Codex 的优势在于其简洁性。你只需指定一个 GitHub issue，它就会读取该 issue、创建分支、实现所需的更改，并最终发起一个 PR。整个工作流程是线性且可预测的。然而，其劣势在于缺乏验证机制（例如没有计算机操作记录，也没有视频证明）以及不支持并行处理。

运行框架对比

各产品适用场景

Cursor 的优势在于：当你需要并行处理 10 个以上明确定义的任务、希望为审阅者提供可视化证明、团队通过 Slack 和 GitHub 进行沟通，并且习惯在云虚拟机 (VM) 中处理代码（或可自行托管）时。

Claude Code 的优势在于：当你面临一个需要深度推理的复杂架构任务、代码必须保持在本地、需要与本地工具进行 MCP 集成，或者习惯终端优先的工作方式时。

Codex 的优势在于：当你的工作流程以 GitHub issue 驱动、任务范围明确，并且你希望实现从 issue 到 PR 的最简路径时。

前沿模型对这三款产品都开放。它们拥有截然不同的平台，提供截然不同的开发者体验。平台本身，就是产品。

定价：你所支付的真正价值

Cursor 采用基于积分的计费方式。每个付费计划都包含一个以美元计价的积分池。当你发出 AI 请求时，积分扣除会根据两个因素：你所使用的模型和任务的复杂程度。

了解积分消耗机制至关重要。20 美元的专业版积分池大约可支持 225 次 Claude Sonnet 请求、550 次 Gemini 请求或 500 次 GPT-5 请求。智能代理模式下，每个任务会调用多个模型，每次调用大约花费 0.04 美元。在 Claude Sonnet 上，一个包含 5 个智能代理的复杂并行会话可在数分钟内消耗数美元的积分。专业版计算配额在每月约 15 至 20 次复杂并行会话后便会达到上限。

核心洞察是：你支付的并非模型访问费用。你完全可以通过各自的 API 以更低的成本获得 Claude、GPT-5 和 Gemini。你所支付的，是平台服务：虚拟机基础设施、代码库索引、制品生成管道、插件生态系统以及将所有这些整合在一起的编排层。

总结与后续步骤

Cursor 云智能代理在隔离的虚拟机 (VM) 中执行自主编码任务，并提供视频记录作为证明。Cursor 自身 35% 的 PR 都是通过这种方式发布的。模型可以互换，而平台本身才是产品。

该工具链 (harness) 包含五个层级（接口、编排、执行、验证、输出），它们对开发者体验的影响远超底层模型本身。Cursor、Claude Code 和 Codex 的实践证明了这一点：相同的模型，迥异的工具链，却带来了截然不同的结果。

因此，关键不在于“哪个模型最佳”，而在于“哪种工具链能够契合团队的信任模型、并行处理需求和工作流”。