打开 Cursor 3.0 的那一刻，我下意识去找熟悉的扩展面板和文件树，却发现整个界面重心变了。聊天窗不是缩在侧边的一个补丁框，而是占据了工作区最核心的位置，旁边整齐排列着多个正在运行的代理任务。一个还在生成仪表板组件，另一个刚刚定位到身份验证模块的异常，第三个已经开始扫描项目的无障碍访问问题。三条进度条各自推进，互不打扰。
这不是一次界面的小修小补。Cursor 3 把原本散落在终端、聊天、编辑器里的代理交互，全部收敛到一个控制中心里。我不必再频繁切屏去查看某个任务的进度，不用在十几条对话记录里翻找某个代理的响应，也更少因为等待一个任务跑完而干等。原本串行的开发流程，被一种更接近项目管理的状态取代：布置任务、跟踪执行、审阅结果，只在关键时刻介入。
过去几年，我一直是 VS Code 的深度用户。它的灵活性在手动编码时代几乎无可替代——打开工作区，在文件间跳转，打开多个终端，扩展市场里有应有尽有。GitHub Copilot 和 Agent Mode 的加入，让这套体系明显变得更聪明，但这些能力始终像一层附加在旧骨架上的增程器。编辑器最底层的交互模型仍然是针对逐行编码设计的，哪怕你正在指挥一个代理，也难免在聊天窗、终端、编辑区之间做五六个跳转。这种感觉就像在一辆燃油车里操作自动驾驶软件，能用，但总觉得隔着一层。
微软显然清楚未来的方向在哪里。最新测试版里，VS Code 推出了全新的 Agents 视图，把代理管理从附庸位置提升到独立入口。这个组件还很粗糙，交互细节和稳定性都有欠打磨，但至少表明这个庞大的编辑器不再把代理当作聊天插件来对待了。我挺兴奋能看到开发者工具巨头的这一步，方向对了，剩下就是执行力的问题。
Cursor 3 走的更彻底。它直接把自己从“带 AI 助手的代码编辑器”改成了“代理型开发的控制中心”。启动任务时，我可以直接把目标描述写进代理指令，比如“新增一个用户分析仪表板”，再起另一个去排查 JWT 鉴权失效，同时让第三个代理检查整个项目的 ARIA 属性缺失。三条线并行推进，互不阻塞。进度条、状态标签、已完成审查的标记，全部在同一视图下流动。这层信息的密度，让开发节奏从“写代码－问 AI－再写代码”变成了“定义目标－审核实现方案－做高层决策”。
这不仅仅是观感上的整洁。当独立任务可以并行时，我花在手动定位代码和切换上下文上的时间明显下降了。更多精力转向了任务拆解和方案评估，代理则承担起组合、生成、检查的密集工作。一旦有多个任务同时完成，我就集中时间审阅结果，把注意力从文件树转向决策流。这种主控位置的迁移，是 Cursor 3 彻底拉开差异的地方。
我还特别关注接下来在新工作流里测试 Grok 4.5 的表现。根据目前披露的信息，这个模型是 Cursor 与 SpaceXAI 联合训练的，训练语料包含了大量开发者交互和来自 Cursor 的编码数据，尤其针对长时间运行的软件项目和知识密集型工作做了优化。它的加入可能让代理执行长时间任务的表现再上一个台阶。当然，具体效果还得与 Claude Code Fable 5 和 GPT-5.6 Sol 同台竞技后才能判断。Anthropic 把 Fable 5 定位为面向雄心勃勃编码项目的旗舰，而 OpenAI 的 Sol 则主打编程、研究和长时间代理任务。这三家的路线之争已经渗透到编辑器内部的代理质量上了。
放在一年前，编辑器之争还在比拼插件数量和界面自定义深度。现在衡量一个编辑器是否跟得上时代，只看它怎么管理 AI 代理。从这种视角再看 VS Code 和 Cursor 的分岔口，路径就很清楚了：一个正在补课，一个已经把代理放到了中心。我仍然尊重 VS Code 的生态系统，但它正从一种灵活的工具箱，变成需要重新思考底层交互逻辑的遗产平台。而 Cursor 3，至少在这一刻，更贴近开发者实际指挥代理时的真实状态。
热门跟贴