为了在编程和其他任务中发挥最高效率，智能体需要具备适度的自主性。这意味着它们应能独立运行、灵活应对，并在不过于频繁停下来请求许可的情况下完成工作。

然而，如果智能体采取了非预期的操作，更高的自主性也会带来安全风险。对本地智能体尤其如此，因为它们通常直接接触文件、凭证、环境变量和 MCP 工具，并且能够访问生产系统。

一个简单的做法是在任何操作发生前都先询问用户，但过于频繁地请求许可本身也会带来安全问题。反复提示多了之后，人们就不会再认真阅读，批准流程也会变得越来越没有意义。

本周，我们发布了 Auto-review，让围绕智能体自主性的决策不再像开关一样非开即关，而更像一个可以细致调节的旋钮。其核心理念是：当风险较低时，智能体应能自由行动；但当下一步操作跨越关键边界时，就应放慢节奏。

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

#在上下文中判断风险

智能体的操作是否存在风险，取决于具体情境。同一条命令在一种工作流中可能无害，但在另一种工作流中却可能不可接受。关键在于，这个操作与用户请求之间的关系，以及判断出错会带来什么后果。

这一认识促使我们着手开发一个“分类器”智能体，用来控制智能体整体的自主性。我们希望它是一个小模型，这样既能保持运行速度快、成本低，又仍能细致判断下一步操作是否符合用户意图。

我们为 分类器 设定的核心规则是：当安全风险较低时，它应当更宽松；当风险较高时，它则应当更加谨慎。在这一总体思路明确后，我们开始将 分类器 构建为一个快速、具备上下文感知能力的审查者，使其能够直接处在智能体的执行路径上。

#构建分类器

第一个技术决策是模型选型。分类器会在工具调用执行前运行，因此它直接处在智能体循环中，既要快，也要准。作为一家支持多模型的公司，这一点给了我们很大帮助，因为我们可以尝试各种模型和推理模式，然后选出在速度与裁决能力之间取得最佳平衡的那个。

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

我们还让分类器具备智能体能力，因为有些操作无法仅凭命令本身来裁决。像 python script.py 这样的命令，究竟安全还是不安全，取决于文件里的内容，因此分类器可以先使用 ReadFile、Grep、Glob 和 ListDir 等工具检查工作区，再做决定。

我们没有单独设置一个分类端点，因为额外的一次往返会直接给每一次经过审查的工具调用增加前置延迟。相反，分类器与父智能体运行在同一条 RPC 流中，采用了类似子智能体的架构。

#设计反馈循环

接下来的问题是，拦截后该怎么处理。我们不希望分类器变成另一个生成审批提示的工具。当它拦截某个操作时，会向父智能体返回一段解释；而父智能体通常可以利用这些反馈选择一条更安全的路径，而无需打断用户。

让这些反馈真正实用的关键，在于用户意图。问题不在于某个操作孤立来看是否存在风险，而在于这个操作是否符合用户让智能体执行的任务。正因如此，常规开发工作才能继续推进，而后果更严重的操作则需要用户发出更明确的信号。

这种设计只有在分类器针对它应当放行和应当阻止的操作进行调优时才成立，因此我们需要同时覆盖这两类情况的评估。

#测试分类器

我们的第一组评估来自内部使用数据，用来了解智能体工作的常见模式。分类器必须在不拦截日常开发工作的前提下发现高风险操作，而内部会话正是观察这一基线的最佳方式。我们先收集了大约 12 小时的内部开发者会话，随后对数据进行精简，并将常见操作去重，整理成 6,122 行带标签的数据。

我们还需要合成数据，因为最糟糕的情况在正常使用中出现得不够频繁。我们生成了一些案例，例如智能体可能会读取密钥、接触生产数据、遵循不可信的指令，或执行带来较大副作用的操作。这些示例让我们覆盖了最希望分类器发现的失败项。

随着我们的认识不断加深，策略也在变化，这让数据工作变得更加复杂。当我们调整分类器应识别的行为类别时，就必须重新标注或重新生成评估集。否则，我们测试的就是当前分类器对一个已经过时的问题定义的理解。

我们通过与生产环境相同的后端分类器流程来运行这些评估。这样我们就能测试完整链路，包括工具使用、最终分类、模型覆盖以及解析失败。评估会检查最终的允许或拦截决策，以及分类器在需要先检查工作区再做决定时所使用的上下文。

我们还会查找结果反复波动的情况。如果同一个案例有六次被允许、四次被拦截，通常就意味着策略或提示定义得不够充分。重复运行让我们能够找出这些不稳定的案例，并不断收紧分类器，直到它的行为更加一致。

#尽量减少直接拦截

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

当分类器确实运行时，目前大约会拦截 4% 的操作，但一次拦截并不会立刻变成向用户发出的提示。分类器会将原因反馈给父智能体，而父智能体通常可以缩小操作范围、改用其他工具，或完全避开这个高风险步骤。

分类器做出的部分拦截最终会变成对用户的打断，但从整体来看，目前我们观察到，在 Auto-review 模式下，只有大约 7% 的全部对话会导致至少一次打断。作为对比，我们合作过的一些企业客户此前在其组织内，大约有 40% 的操作会被拦截。

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

#优化智能体自主性

Auto-review 仍处于早期阶段。随着智能体能力不断提升，我们对自主性连续体的理解也会持续演进。目前，它主要聚焦于桌面应用中的本地智能体；我们也预计，随着时间推移，这些理念同样会影响我们在更多场景下管控智能体自主性的方式。

我们希望智能体具备真正的自主性，同时让是否对其放缓节奏的判断取决于具体上下文，而不是依赖单一的全局权限设置。分类器让我们能够在不让自主性重新沦为一连串审批提示的前提下提升安全性。它会发现需要进一步审查的操作，向父智能体提供反馈，并在存在更安全的执行方式时让智能体继续工作。

Auto-review 现已成为新用户的默认设置。对于现有用户，您可以在设置 > 智能体中启用它。