Cursor Agent Review 机制：改动在合进去之前过了哪一道

2026-08-18

先把问题问具体：你让 agent 连着改了七八个文件，改完准备提交。这批改动在进主干之前，到底被谁看过一遍？看的是最后一次编辑，还是整批？它依据的规则从哪来？看完之后产生的那段对话，你转给同事时对方能看到什么、看不到什么？

这几个问题在 Cursor 官方文档里分散在两处：cursor.com/docs/agent/agent-review（Agent Review 本体）和 cursor.com/help/ai-features/shared-transcripts（对话分享）。前者管「过哪一道」，后者管「过完之后这份记录怎么流出去」。下面按这条路走一遍，途中把能核到的配置项和字段标出来。核不到的地方我会直说文档没写——本文只复述官方文档写明的内容，不推断实现。

第一步：这一道跑在什么范围上

官方文档写明 Agent Review 是「在 Cursor 内部针对你的本地改动跑一次专门的代码评审」。注意这句里的两个限定：本地改动，以及专门的一次评审——它不是 agent 干活顺手带的，是另起的一趟。

文档列出三种启动方式，这三种最关键的区别不在「怎么触发」，在它拿什么去比：

启动方式	官方文档写明的行为
Automatic	在设置里开启后，每次 commit 之后运行
Slash command	在 agent 窗口输入 `/agent-review` 按需触发
Source Control tab	从 Source Control tab 运行，把全部本地改动与你的主分支比对

文档对第三种额外补了一句：这样能覆盖你整批改动里的问题，而不只是最近一次编辑。这句话反过来读更有用——前两种的覆盖范围文档没有写得这么明确，尤其是 Automatic 那一档，文档只说「每次 commit 之后运行」，至于它比的是这一次 commit 的 diff 还是累积改动，Agent Review 这一页没有说明。所以如果你在意的是「这一批改动整体有没有互相打架」，文档里能明确对应上这个诉求的只有 Source Control tab 那条路径。

这也是我建议不要只靠 Automatic 的原因：文档对自动档只写了触发时机（每次 commit 之后），没有写它拿什么范围去比。你如果习惯把一个功能拆成十几个小提交，又想确认这十几个提交合在一起没有互相打架，那么在文档层面有明确依据的路径只有 Source Control tab 这一条——自动档究竟覆盖到哪里，文档没有给答案，也不该由我们替它补一个。

第二步：开关在哪，以及它搬过一次家

配置路径官方文档写明是：打开 Cursor Settings → 进入 Agents → 找到 Agent Review 配置偏好。同一页紧接着写了一句迁移说明：从 Cursor 3.11 起，这项设置移到 Git & PRs > Pull Requests 下。

这种「设置项搬家」是翻文档时最容易被坑的地方——你按旧路径找不到就以为功能没了，其实只是挪了位置。文档把新旧两处路径并列写在同一段里，并用版本号划了分界；至于为什么这样调整，文档没有说明，我们也不替它解释。你自己那台机器归哪一档，对着版本号找即可。这类路径随版本变动，以官方文档最新内容为准。

设置里能定的是「跑不跑自动档」：文档写明你可以让它在每次 agent 任务之后自动运行，也可以保持手动、由你自己触发。

第三步：两档深度，文档只给了相对量

Agent Review 支持两档深度，官方文档给的是这张表：

Depth	Speed	Cost	Best for
Quick	Fast	Low	小 diff、格式改动，或者快速过一眼
Deep	Slow	High	复杂逻辑、涉及安全的代码，或者大型重构

这张表怎么读，得先看清楚它给的是什么：Speed 和 Cost 两列全是相对描述，没有任何绝对数值，也没有说 Deep 一定比 Quick 多发现多少问题。所以能从这张表里拿走的结论只有一条——档位是你手动选的，选择依据是这次改动的性质，不是文件数量。文档把「涉及安全的代码」单独列进了 Deep 那一行，这是文档自己的取舍，值得照做。

顺带一提，同为 Cursor 评审侧的 Bugbot，在 cursor.com/docs/bugbot 里给的是另一套档位命名（Default / High / Custom 三档 effort level），而且文档写明 effort level 只在按用量计费的 Bugbot 方案上可用。两套档位不是一回事，别把名字记串了。

第四步：它照着什么规则挑刺

这一步是整条链路上最容易被忽略的：Agent Review 会读仓库里的 BUGBOT.md 规则文件。Agent Review 这一页只写了这一句，并把规则文件怎么建指向了 Bugbot 文档。

Bugbot 文档里写明的规则文件机制是：在仓库里创建 .cursor/BUGBOT.md，根目录那一份总是被包含，此外从被改动的文件向上遍历目录，沿途找到的 BUGBOT.md 也会被带上。文档给的目录示例是这样：

project/
  .cursor/BUGBOT.md          # Always included (project-wide rules)
  backend/
    .cursor/BUGBOT.md        # Included when reviewing backend files
    api/
      .cursor/BUGBOT.md      # Included when reviewing API files
  frontend/
    .cursor/BUGBOT.md        # Included when reviewing frontend files

有一条反直觉的、值得单独记下来的规定：Bugbot 文档明确写着，Cursor 的 project rules（.cursor/rules/ 下的 *.mdc 文件）不适用于 Bugbot 运行，要用 .cursor/BUGBOT.md 或在 Automations 里配置的规则。也就是说你辛辛苦苦写的那套 .mdc 规则，在评审这条链路上是不起作用的——至少 Bugbot 侧文档是这么写的。Agent Review 那一页没有说明本地评审是否同样排除 .mdc，这一点我们没有依据，不替它补。

多来源规则同时命中时，Bugbot 文档写明会合并成一个 review-rules 块，包含顺序是四段：Team Rules → 项目 .cursor/BUGBOT.md（含嵌套文件）→ learned rules → manual rules。文档还写明单条规则超过一定字符数会被截断，合并后的规则总量也有上限，超出时部分规则可能被省略，且必需的团队规则优先于非必需的——具体阈值属于会变的数值，这里只记机制，要用时回官方文档查当时的值。

第五步：可见信息——你能看到它用了哪些规则吗

规则一旦有合并和截断，就必然出现「我以为生效了其实被丢了」的情况。Bugbot 文档给了一个可见性手段：在 pull request 上评论 bugbot run verbose=true 或 cursor review verbose=true，Bugbot 会贴出这次运行包含的全部规则表格，并标出哪些被截断或省略了。

请注意这条命令的适用场景：它写在 Bugbot 的 PR 流程里，是往 PR 上发评论。Agent Review 的本地评审有没有等价的规则清单展示，官方文档没有说明这一点。 这两条链路在文档里是分开写的，别默认本地也能这么查。

第六步：这段评审记录交出去，什么会跟着走

评审跑完，接下来的现实动作往往是把这段对话甩给同事看。Cursor 帮助文档里对应的功能是 shared transcripts，写明的流程是：打开要分享的会话 → 点击会话头部的 Share 图标 → 选择 Team（只有登录的团队成员可见）或 Public（任何拿到链接的人可见）→ 复制链接。公开链接的格式文档给的是 cursor.com/s/abc123。收到链接的人可以用 Fork to Cursor 把这段对话接到自己的编辑器里继续。

真正需要盯住的是「什么会跟着走」这一段。文档写明分享的是完整会话历史，包括代码片段、工具调用及其结果。请把「工具调用及其结果」这半句读重一点：跟着走的不只是你和 agent 说过的话，还有这次评审过程里工具产生的输出本身。

紧接着是文档自己写明的一条限度：分享前 Cursor 会对已知的密钥模式做尽力而为（best-effort）的脱敏，比如常见的 API key 格式、token 和密码；但文档明说脱敏不保证有效，可能漏掉密钥，尤其是自定义值或者没有可识别前缀的值。文档给出的处置很直白：分享前自己先过一遍，不能外泄的东西别分享。这句我原样转达，不加任何「所以是安全的」这类结论。

不会跟着走的东西文档也列了：本地文件、认证凭据、你的身份不包含在内。

这里有两句话值得并排放在一起看：同一页既写了「工具调用及其结果」会被分享，又写了「本地文件」不包含在内。这两条各自是明确的，但当一次工具调用的结果里恰好嵌着某个本地文件的内容时，这份内容算在哪一边，官方文档没有说明这一点。我们把这个空白原样指出来，不替它推一个答案——你要做的判断也很简单：分享前自己把这段记录从头翻一遍，别指望文档替你划这条线。

管理入口官方文档写明在 cursor.com/dashboard 的 Shared Transcripts 标签页，可以改可见性或删除；团队管理员可以删除任何成员的记录。团队链接也是从这个页面进入查看的。

边界有三条必须照实标出来：其一，文档写明 shared transcripts 只在 Teams 与 Enterprise 方案上提供，Individual 与 Pro 方案没有；其二，Enterprise 默认只有团队链接，Teams 才是团队链接与公开链接都有；其三，在 “No Storage” 隐私模式下不可用。此外文档还写了每天的分享次数上限，属于会变的配额，这里不抄数值，要用时回官方页面查。

关于平台差异

这两页文档里没有写任何 Windows 与 macOS/Linux 的行为差异。唯一和路径沾边的是 .cursor/BUGBOT.md，它是仓库内的相对路径，文档给的目录示例用的是正斜杠写法；Windows 上你在 <你的项目目录> 里建这个文件，仓库里的路径写法与示例一致。除此之外的平台差异，官方文档没有说明，本文不做推测。

把这一道理顺后剩下什么

回到开头那批改动：能确定的是，触发方式决定了比对范围（只有 Source Control tab 那条明确写了「与主分支比全部本地改动」），深度档位由你按改动性质手选，规则来自 BUGBOT.md 而不是 .cursor/rules/ 下的 .mdc，而这段记录一旦分享出去，工具调用结果会一起走、脱敏不保证。

不能确定的也得记牢：自动档的比对粒度、本地评审能否列出生效规则、.mdc 在 Agent Review 侧是否同样被排除——这三处官方文档都没有写。遇到这类空白，靠猜的成本远高于回官方文档确认一次。

本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。