Cursor 推出 Auto-review：让 AI 编程 Agent 学会"看情况"再行动
基于已整理草稿生成的网页版文章，适合先稳定落地，再做局部润色与发布检查。
6月11日，Cursor 发布了一项名为 Auto-review 的新功能，专门解决 AI 编程 Agent 的自主权难题：让 Agent 在低风险操作时自由行动，在可能出问题的时候自动减速。核心做法是在每次工具调用之前，插入一个轻量级分类器做风险评估——不是简单弹窗问用户"允许吗"，而是根据上下文智能判断。
老问题：自主和安全的两难
AI 编程 Agent 越来越能干，但也越来越"危险"。本地 Agent 能读写文件、执行命令、访问环境变量和 MCP 工具，甚至可能触达生产系统。传统的安全做法是在每个关键操作前弹窗确认，但实际体验很糟糕——弹窗太多，用户就不认真看了，确认变成了无脑点击。Cursor 自己的观察是：反复的权限请求反而降低了安全性，因为用户会"确认疲劳"。
另一个极端是完全不限制，Agent 想干什么就干什么。这对个人项目也许还行，但在企业环境里完全不可接受。
Auto-review 的思路是：把"开关"变成"旋钮"。低风险操作直接放行，高风险操作拦截后给 Agent 解释，让 Agent 自己换一个更安全的路径——尽量不打断用户。
怎么做到的
Auto-review 的核心是一个小型分类器 Agent，它运行在主 Agent 的执行循环里。每当主 Agent 准备执行一个工具调用，分类器先审查一遍。
几个关键设计：
模型选择。 分类器需要在速度和判断力之间找平衡。Cursor 尝试了多种模型，发现低推理能力的模型反而更慢——因为看不懂策略，会在错误方向上浪费 token。最终选择了一个"足够理解策略、但不会过度推理"的小模型。
主动检查工作区。 有些操作光看命令本身无法判断风险。比如 python script.py，安不安全取决于脚本里写了什么。分类器可以主动用 ReadFile、Grep、Glob、ListDir 等工具检查工作区，再下结论。
无额外延迟。 分类器没有用独立的 API 端点，而是在同一个 RPC 流中运行，架构类似子 Agent，避免了一次额外往返。
反馈而非弹窗。 当分类器拦截一个操作时，它返回一段解释给主 Agent。主 Agent 可以根据这个反馈选择更安全的方式完成任务，而不是直接弹窗让用户决定。只有当 Agent 确实找不到安全路径时，才会请求用户介入。
为什么这很重要
Agent 安全治理是整个 AI 编程工具行业都在面对的问题。Cursor 不是唯一一个在想办法的，但 Auto-review 的"分类器+反馈循环"方案是目前最系统化的尝试之一。
对普通开发者来说，这意味着 Agent 可以更自主地完成工作——写代码、跑测试、改文件，大部分操作不会被频繁打断。但当 Agent 真的要执行一个可能删除重要文件或访问生产环境的操作时，它会自动踩刹车。
对企业来说，这种方案比"全量审计日志"更实用——问题操作在执行前就被拦截了，而不是事后发现。
测试方法
Cursor 用了两组数据来训练和评估分类器：
- 真实数据：约 6,122 条标注行，来自内部开发者的实际使用记录，去重后覆盖了日常 Agent 操作的各种模式。
- 合成数据：专门构造的"危险场景"，包括读取密钥文件、触碰生产数据、跟随不受信任的指令、执行大范围副作用操作等。这些最坏情况在日常使用中很少出现，但必须能拦住。
值得注意的是，分类器的策略在开发过程中不断调整，数据标注工作也随之变化。Cursor 没有公布具体的拦截率或误报率数据。
局限与待观察
Auto-review 目前只适用于 Cursor 自有的 Agent 系统。对于通过 MCP 接入的第三方工具，分类器的覆盖范围还不清楚。分类器的准确性也需要在更大规模的真实用户场景中验证——内部 6,000 多条数据是一个好的起点，但远不够覆盖所有边缘情况。另外，企业合规要求（如金融、医疗行业）是否认可这种"智能拦截"方式，还需要时间检验。
---
*基于 Cursor 官方博客整理。*
参考来源
说明：该页面由基础模板稳定生成，后续可继续局部润色样式或补充模块，再进入发布检查。