Cursor 的 Agent 模式：编辑器里的人和机器

Cursor 卖的不是模型，而是"改动发生在你眼前"这件事。同样一句需求，终端 Agent 给你一段执行日志，Cursor 给你一片可以逐行接受或回退的 diff。这个差别决定了它适合什么活。

上下文从你正在看的东西长出来

Cursor 是编辑器，所以它的上下文天然来自编辑器状态：当前打开的文件、光标位置、项目索引、你手动 @ 进来的文档或目录。Tab 补全处理"下一行"，Agent 模式处理"这一片"——两者共用同一套代码理解，但介入的粒度不同。

这个设计的直接后果是上下文效率高。你不需要在提示词里描述"我要改的是哪个函数"，光标就在那儿。对于改一个组件、调一段样式、重构一个模块这类工作，省掉的描述成本相当可观。

代价是上下文边界也跟着编辑器走。跨仓库、跨服务的改动，或者需要读大量非代码资料的任务，编辑器能提供的视野有限，还是得靠命令行 Agent 主动去读。

放权分三层，别一次拉满

第一层是补全。它几乎不需要监督，错了按一次 Esc 就没了，风险最低。

第二层是 Agent 模式的本地执行。这里的关键配置是运行模式与终端命令白名单：哪些命令可以直接跑、哪些必须确认，写在项目级的权限文件里，跟着仓库走。默认应该是"读随便、写要问、危险命令一律拦"，等团队的测试覆盖够了再逐步放开。

第三层是云端 Agent。任务被放到隔离的 worktree 或云端环境里跑，不占用你的本地工作区，回来是一份待审的变更。它适合那些"想让它跑一会儿，但我还要继续改别的"的场景。

这三层的分界不是功能多少，而是"出错之后好不好收拾"。补全出错，一行代码；本地 Agent 出错，一个未提交的工作区；云端 Agent 出错，一份没人看过的 diff。放权程度应该跟回滚成本成反比。

图 1　放权越深，收拾起来越贵

审查是它的隐形工作量

Cursor 把 Agent 的产出摊开在你面前，好处是掌控感，代价是审查成本被显性化了。

一个跨十个文件的改动，逐条接受意味着你要读十处 diff，并且判断它们之间的关系——单看每一处都合理，合起来可能逻辑冲突。这种"局部正确、整体错误"的问题，是编辑器内 Agent 最容易漏掉的一类。

实操上有两个缓解办法。一是要求 Agent 先给计划再动手，计划阶段否掉比改完再否掉便宜得多。二是把验证交给测试和类型检查，而不是靠眼睛看 diff；能自动判定的东西不要占用人注意力。

另一个容易被忽略的成本是索引。项目索引让补全和问答更准，但索引范围和隐私边界需要明确，尤其是仓库里有客户数据、密钥样例或未公开方案时。

它适合的工作形态

适合：UI 与交互迭代（改完立刻能看效果）、中等规模的跨文件重构、需要频繁在"看代码"和"问模型"之间切换的日常开发。

不适合：需要跑几十分钟甚至几小时的无人值守任务；需要同时推进多个互不干扰的任务；以及完全在终端里工作的流水线场景。

一句话概括：Cursor 的最佳位置是"人机交替"——你改一段、它改一段，节奏由你控制。让它长时间自己跑，反而丢掉了它最大的优势。

和另外三条路线的分工

如果你的日常是"打开编辑器就开始干活"，Cursor 的摩擦最小，因为它不需要切换窗口，上下文已经在手边。

如果任务是"这个模块整体重写"，终端 Agent 更合适：它可以自己 grep、自己读依赖、自己跑测试，不必等你把文件一个个打开。

如果任务是"把这个 issue 处理掉"，那应该走 GitHub 那条线，让 Agent 在仓库流程里完成，而不是在本地改完再手工对齐。

如果任务是"同时推进五件互不依赖的事"，云端并行才是答案，编辑器只有一个前台，装不下五个任务的等待。

这四条不是互斥的。常见组合是：用 Cursor 做日常开发，用云端任务清积压，用仓库 Agent 处理流程化的维护工作。工具之间的边界，本质上是你把"注意力"分配给了谁。

关于"注意力"这件事还有一层：Agent 一次改得越多，人越容易跳过审查。这不是工具的问题，是流程的问题。Agent 成本那篇讲的是钱，但同样的逻辑适用于注意力——按"完成一次任务的总消耗"算，审查时间必须计入。

选它之前先问一句

你希望 Agent 是"替你写完"，还是"和你一起写"？前者应该看云端任务和终端 Agent，后者才是 Cursor 的地盘。它把过程留在屏幕上，这既是它最好用的地方，也是它最容易被低估的成本。