几年前我们开始构建 Cursor 时，大多数代码还是一次敲一个字符写出来的。Tab 自动补全改变了这一点，开启了 AI 辅助编程的第一个时代。

随后 Agent 出现了，开发者开始通过同步的“提示—响应”循环来指挥 Agent。那是第二个时代。现在，第三个时代正在到来，它的特征是：Agent 能够在更长的时间尺度上，更独立地完成更大的任务，并且需要更少的人为干预。

因此，Cursor 不再主要只是用来写代码，而是帮助开发者搭建那座“生产他们软件”的工厂。这座工厂由一支支 Agent 组成的“车队”构成，开发者像与队友一样与它们协作：给出初始方向，为它们配备能独立完成工作的工具，并审阅它们的成果。

Cursor 团队中的许多人已经在以这种方式工作了。现在我们合入的 PR 中，已有超过三分之一是由在云端独立机器上运行的 Agent 创建的。一年后，我们认为绝大多数开发工作都会由这类 Agent 完成。

#从 Tab 到 Agents

Tab 擅长识别哪些低熵、重复性的工作可以被自动化处理。在将近两年的时间里，它带来了巨大的效率杠杆。

随后，模型能力大幅提升。Agents 可以承载更多上下文、调用更多工具，并执行更长的操作序列。开发者的习惯开始改变：起初在整个夏天缓慢演进，接着在最近几个月里，随着 Opus 4.6、Codex 5.3 和 Composer 1.5 的发布而迅速转变。

这种变革如此彻底，以至于如今，大多数 Cursor 用户几乎不会再按 Tab 键。2025 年 3 月，我们的 Tab 用户数量大约是 Agent 用户的 2.5 倍。现在情况已经反转：Agent 用户数量是 Tab 用户的 2 倍。

但这场转变本身已经在为更大的变化铺路。Tab 时代持续了近两年。而第二个时代——大部分工作由同步 Agents 完成——可能撑不到一年。

#云端代理和工件

与 Tab 相比，同步代理在更高的抽象层上工作。它们处理需要上下文和判断力的任务，但仍然在每一步都让开发者始终参与其中。只是，这种实时交互形式，再加上同步代理会在本地机器上竞争资源这一事实，意味着在同一时间实际可用的代理数量只能是少数。

云端代理消除了这两种限制。每个代理运行在自己的虚拟机上，让开发者可以将任务交给它处理，然后转去做别的事情。代理会在数小时内持续工作，反复迭代和测试，直到对输出足够有信心，并以一种便于快速审阅的形式返回结果：日志、视频录像和实时预览，而不是 diff。

这使并行运行多个代理变得切实可行，因为工件和预览为你提供了足够的上下文来评估输出，而无需从零重建每个会话。人的角色也从逐行引导代码编写，转变为定义问题并设定评审标准。

#这种转变正在 Cursor 内部发生

我们在 Cursor 内部合并的 PR 中，已有 35% 是由在云端 VM 中自主运行的 agent 创建的。我们看到，采用这种全新工作方式的开发者通常具有以下三个特征：

1. 几乎 100% 的代码都由 agent 编写。
2. 他们把时间花在拆解问题、审查结果以及提供反馈上。
3. 他们会同时启动多个 agent，而不是手把手地引导单个 agent 直至完成。

在这种方式成为软件开发的标准实践之前，还有大量工作要做。在大规模的工业化场景下，那些单个开发者尚能绕过的不稳定测试或损坏的环境，会演变成导致每一次 agent 运行都被中断的故障。更广泛来看，我们仍然需要确保 agent 能尽可能高效地运作，并完整获取其所需的工具和上下文。

我们认为，Cursor cloud agents 的昨日发布是朝这一方向迈出的初步但重要的一步。