Cursor 推出 Auto-review 机制：用分类器智能体动态管控智能体自主权限

要让智能体在编程和其他任务中发挥最大生产力，它们需要适度的自主性。这意味着它们应该能够独立运行、发挥创造力并完成工作，而不是频繁停下来请求许可。

然而，更高的自主性会带来安全风险，因为智能体可能会执行意想不到的操作。本地智能体尤其如此，它们通常在文件、凭据、环境变量和 MCP 工具附近运行，并可能访问生产系统。

简单的做法是在任何操作发生前先询问用户，但过于频繁地请求许可本身也会造成安全问题。在反复弹出足够多的提示后，人们就不再仔细阅读，审批流程也就失去了意义。

本周我们发布了 Auto-review，让围绕智能体自主性的决策更像一个旋钮而非开关。其核心理念是：智能体在风险较低时应能自由行动，而当下一步操作跨越重要边界时则应放慢速度。

我们通过一个专门的分类器智能体来判断某个操作在这条连续谱上的位置，它会在操作执行前结合上下文进行审查。构建它意味着我们要把关于“智能体自主性应如何治理”的直觉，转化为一个可用的模型，涵盖后果、意图和反馈，并能够对照真实的智能体行为进行测试。

在上下文中判断风险

智能体操作是否构成风险取决于具体情境。同一条命令在一个工作流中可能无害，在另一个工作流中却不可接受。关键在于操作本身、用户请求以及出错后果之间的关系。

这一认识促使我们开发一个"分类器"智能体来管控智能体的整体自主权。我们希望它是一个小模型，从而保持运行快速且成本低廉，同时仍能对下一步操作是否符合用户意图做出细致的判断。

我们给这个分类器设定的核心规则是：安全风险较低时应更宽松，风险较高时应更谨慎。有了这个总体思路后，我们开始构建这个分类器，把它做成一个快速、具备上下文感知能力的审查者，直接嵌入智能体的执行路径中。

第一个技术决策是模型选择。分类器在工具调用执行之前运行，因此它直接位于智能体循环之中，既需要快速也需要准确。作为一家多模型公司，这一点帮了我们大忙：我们可以尝试各种模型和推理模式，然后选择一个在速度与判断力之间处于恰当平衡点的模型。

一个早期的意外发现是，推理能力较低的模型并不总是更快。当模型难以理解策略或工具调用时，它可能会花费更多时间和 token 去搜索，最终得到的答案反而更差。更好的权衡是选择一个小模型，具备足够的推理能力来干净利落地做出决策。

我们还将分类器做成了智能体式的，因为有些操作无法仅凭命令本身来判断。像 python script.py 这样的命令可能安全也可能不安全，取决于文件里的内容，因此分类器可以在做出决定之前，使用 ReadFile、Grep、Glob 和 ListDir 等工具检查工作区。

我们没有采用单独的分类端点，因为额外的一次往返会在每次被审查的工具调用之前直接增加延迟。取而代之的是，分类器在与父智能体相同的 RPC 流中运行，其架构类似于子智能体。

下一个决策是拦截动作应该做什么。我们不希望分类器变成另一个批准提示生成器。当它拦截某个操作时，它会向父智能体返回一条解释，父智能体通常可以利用这条反馈选择一条更安全的路径，而不必打断用户。

用户意图是让这条反馈发挥作用的关键。问题不在于某个操作单独看起来是否有风险，而在于该操作是否与用户要求智能体做的事情相符。正是这一点让正常的开发工作得以继续推进，而后果更严重的操作则需要用户给出更明确的信号。

这种设计只有在分类器经过调优、既能放行应放行的操作、又能拦下应拦下的操作时才有效，因此我们需要覆盖这两方面的评测。

我们的第一批评测数据来自内部使用数据，用以了解智能体工作的正常形态。分类器必须在不阻碍日常开发工作的前提下捕捉有风险的操作，而内部会话是观察这一基线的最佳途径。我们从大约 12 小时的内部开发者会话开始，然后对其进行删减，并将常见的重复操作去重，最终得到 6,122 行标注数据。

我们还需要合成数据，因为最糟糕的案例在正常使用中出现得不够频繁。我们生成了智能体可能读取机密信息、触碰生产数据、遵循不可信指令，或执行副作用巨大的操作等场景。这些示例为我们最希望分类器捕捉的失败情况提供了覆盖。

策略随着我们的学习不断变化，这让数据工作变得更加复杂。每当我们更改分类器应识别的行为类别时，都必须对评测集进行重新标注或重新生成。否则，我们就是在用过时的问题理解去测试当前的分类器。

我们通过生产环境中使用的同一套后端分类器流程来运行评测。这让我们能够测试完整路径，包括工具使用、最终分类、模型覆写以及解析失败的情况。评测检查最终的允许或拦截决策，以及当分类器需要在做决定前检查工作区时所使用的上下文。

我们还关注结果抖动。如果同一个案例被允许六次、被拦截四次，这通常意味着策略或提示词定义得不够明确。重复运行让我们能够找出这些不稳定案例，并收紧分类器，直到其行为更加一致。

在实践中，只有一小部分智能体操作需要由分类器审核。许多命令已经被允许列表或沙箱机制覆盖，因此分类器大多只在操作需要结合上下文判断时才运行。

当分类器真正运行时，它目前会拦截大约 4% 的操作，不过被拦截并不意味着立即弹出用户提示。分类器会把解释说明发回给父智能体，后者通常可以缩小操作范围、选择其他工具，或者完全避开有风险的步骤。

分类器的部分拦截会变成对用户的打断，但从全局来看，Auto-review 模式下的所有会话中只有约 7% 导致至少一次打断。作为对比，我们合作的一些企业客户此前在其组织内曾出现约 40% 的操作被拦截的情况。

这一早期数据与我们期望的主要产品行为一致。分类器很少直接打断用户，而且在大多数被拦截的情况下，父智能体都能利用反馈以更安全、更收窄的方式继续执行。

Auto-review 仍处于早期阶段，随着智能体能力不断提升，我们对自主性连续谱的理解也会持续演变。目前它聚焦于桌面应用中的本地智能体，我们期待同样的理念今后能在更多场景中指导我们对智能体自主性的治理。

我们希望智能体拥有真正的自主性，同时让“是否要拖慢它们”的决策取决于上下文，而不是单一的全局权限设置。这个分类器让我们在不把自主性变回一连串审批弹窗的前提下提升安全性。它会拦截需要更严格审查的操作，向父智能体提供反馈，并在存在更安全的推进方式时让智能体继续工作。

Auto-review 现已成为新用户的默认设置。现有用户可以在 Settings > Agents 中启用它。