Cursor 2.0 最容易被注意到的是速度。官方更新称，Composer 在“同等智能水平”下速度提升 4 倍；智东西 2025 年 10 月的报道写到，多数回合可在 30 秒内完成 [1][2]。
更直接影响代码审查的，是并行。Cursor 2.0 对同一个提示最多可运行 8 个 Agent，并通过 git worktrees 或远程机器给它们分配独立的代码库副本，避免文件冲突 [1]。InfoQ 引述 Cursor 工程负责人 Jason Ginsberg 的说法：工程师已经开始同时给多个 Agent 派活，让它们修改和调试代码，自己等结果出来后再集中检查 [3]。
瓶颈也就换了位置。代码出得更快，同一时间等待检查的 diff 会更多。一篇相关报道提到，BugBot 每月扫描 200 万个 PR [4]。这个数字不能直接套到每支团队，但至少能看出，自动审查工具面对的代码吞吐量已经很高。
要防的不是一个抽象的“Agent 会不会犯错”，而是未经独立检查的改动能不能直接进入主分支。
本地这一关，只做确定性检查
Pre-commit Hook 适合快、稳定、可重复的任务：运行仓库已有的 lint、格式化检查、类型检查和受影响测试，再检查暂存区 diff。它不负责判断需求是否实现，只负责拦住确定能判错的内容。
可以先搭一个很薄的命令骨架：
#!/bin/sh
set -e
<项目现有的 lint 命令>
<项目现有的类型检查命令>
<受影响测试命令>
git diff --cached --check
尖括号里的内容需要替换为仓库已有脚本。完整测试如果太慢，就留在 CI；Pre-commit 只跑能快速返回的部分。未定义变量、语法错误和明显违反项目规则的改动，能在这里发现，就不要拖到 PR 阶段。
Hook 也不需要判断代码是不是 Cursor 生成的。它只看已经暂存的内容，规则对人工代码和 Agent 代码一视同仁。
团队若已有稳定的本地模型或云端审查接口，可以让它读取 git diff --cached，做一次提示性检查。但不建议让每次提交都依赖外部模型：网络失败、响应延迟和误报都会打断本地节奏。模型要参与阻断，更适合放到 PR 的 CI 中。
PR 阶段，只让审查 Agent 读
在 GitHub Actions 中单独增加一个审查 Job。它接收 PR diff 和必要的文件上下文，只输出审查结果，不修改代码，也不自动提交修复。
这里要把两个概念分开：Cursor 2.0 支持多 Agent，不等于它一定提供了可直接接入 GitHub Actions 的通用审查 API。现有资料确认的是 Composer 和多 Agent 界面 [1]。CI 具体调用哪个模型或 Agent 服务，应以团队已有接口为准。
配置可以先按下面的逻辑搭骨架，尖括号部分再按仓库替换：
name: pr-agent-review
on: pull_request
jobs:
model_review:
runs-on: <团队使用的 runner>
steps:
- run: <检出仓库代码>
- run: <导出 PR diff>
- run: <调用只读审查 Agent>
- run: <发布评论并按结果设置检查状态>
审查提示词不必写得很宏大，边界越清楚越好：
你只负责审查，不修改代码。
输入：
- PR diff
- 为理解 diff 提供的必要上下文
重点检查：
- 空指针异常
- 资源泄漏
- SQL 注入风险
- 并发安全问题
- 能从代码中定位的性能问题
规则：
- 只报告输入中有证据的问题
- 证据不足时写明无法确认，不要补写上下文
- 忽略普通命名和格式问题，除非已经影响理解
- 返回 JSON，字段包括 issue_type、severity、file、line、description、suggested_fix
PR diff：
{{ diff_content }}
CI 收到 JSON 后，还要校验输出格式。只有能够定位、并被标为高风险的问题才让 Job 失败，同时把说明写进 PR 评论；普通风格问题或证据不足的怀疑，只做提醒。
不要让这个 Agent 在同一个 Job 里边审边改。否则生成者和审查者又混在了一起，所谓二次校验只剩下自我确认。
如果生成和审查使用同一段上下文、同一个目标提示，审查也容易顺着原来的思路走。这里说的“独立”，至少包括任务分离、上下文收缩和只读权限。是否更换模型，则看团队现有条件。
哪些结果应该挡住合并
阻断规则要写清楚，否则模型多报几次，团队很快就会绕过它。
- lint、类型检查或测试失败：直接阻断。
- Agent 找到可定位的高风险问题：检查失败，交给开发者确认或修正。
- 命名、格式和一般可读性意见：不阻断，必要时留评论。
- Agent 没有发现问题：不能替代人工 Review，也不能自动证明改动正确。
模型可以先替 Reviewer 圈出可疑位置，但需求是否实现、业务语义是否正确，仍要由人判断。如果审查服务运行在云端，还应先确认仓库代码是否允许离开组织环境，不能为了检查安全问题，反而引入新的代码暴露风险。
整个流程可以压成一行：
Agent 生成 → Pre-commit 确定性检查 → PR 测试 → 只读 Agent 审查 → 人工确认 → 合入
Cursor 2.0 可以让最多 8 个 Agent 同时产出候选改动，合入权限却没必要跟着加速。生成可以快，进主分支前还是要慢一点。
