Cursor Auto-review：把"审批疲劳"从智能体开发里抠出去

6 月 11 日，Cursor 官方博客上线了一篇题为 Auto-review 的工程实践长文。表面上讲的是"给 Agent 加一道分类器"，背后在讲的是：当智能体能调本地工具、能读文件、碰得到生产系统时，"允许 / 拒绝"这种二元开关已经不够用了。

设计哲学：从"开关"到"旋钮"

Cursor 工程团队抛出的核心问题是：本地 Agent 接触文件、凭证、环境变量、MCP 工具、生产系统——给它高自主性有风险，给它低自主性又效率极差。

更关键的一个观察是"审批疲劳"：传统做法是让用户在每个危险操作前点确认，结果用户很快就不再认真读弹窗——这反而把安全网磨穿。Cursor 的解法是引入一个专门的分类器智能体（Classifier Agent），在工具调用真正执行前做上下文审查：

• 低风险、符合用户意图 → 放行
• 高风险、偏离意图 → 拦截，但不是问用户，而是把"为什么拦截"的解释返回给父智能体
• 父智能体根据反馈自动换工具、缩小范围、甚至完全绕开高风险步骤
• 只有在父智能体自己收敛不到安全路径时，才打断用户

架构细节

• 分类器跑在 Agent 主循环内（不是独立的端点），避免每次工具调用多一次网络往返
• 分类器自己也是一个轻量 Agent，可以调用 ReadFile、Grep、Glob、ListDir 来理解上下文——例如「python script.py」这条命令本身无害，但脚本内容可能改生产库
• 拒绝"低推理小模型"路线：Cursor 工程团队明确说，推理能力不足的小模型反而会更慢更贵，因为它会反复"想"然后给差答案
• 当前分类器运行拦截率约 4%；触发过打断的对话占比约 7%；作为对比，部分企业客户此前的全拦截方案高达 40%

工程团队自陈了训练这套分类器的方法论：

• 内部开发会话去重整理出 6,122 行带标签数据
• 合成数据补齐危险场景：读密钥、碰生产数据、遵循不可信指令、副作用大的操作
• 评估时跑的是与生产同款的"分类器全链路"，包括工具使用、最终分类、模型覆盖、解析失败
• 关键指标之一是"决策稳定性"——同一案例跑 6 次必须结果一致，否则说明策略或 prompt 还没写稳

把这篇博客和 Cursor 上一个动作（Bugbot 速度提升 3 倍、成本降低 22%、多发现 10% bug）放一起看，Cursor 在走的是一条 「Agent 时代的安全基础设施」 路线：让 Agent 越来越能、越来越快、越来越便宜的同时，把"它会不会出事"这件事系统性地管起来。

这件事在 Agent 越来越普及的当下非常重要——很多团队已经在用 Claude Code、Codex、Cursor、Cline、Roo Code 等工具直接改生产代码，但"Agent 出问题怎么办"几乎都靠用户自觉。Cursor 把这套机制产品化、公开了实现细节，等于在给整个行业立标准。

原文链接

• 官方博客：https://cursor.com/blog/auto-review
• Bugbot 更新：https://cursor.com/blog/bugbot-updates-june-2026