视频 · 前往原文观看

为了在编程及其他任务中实现最高效率，智能体需要具备适度的自主性。这意味着它们应当能够独立运作、发挥创造力，并在不频繁中断请求许可的情况下完成工作。

然而，更高的自主性也会带来安全风险——如果智能体执行了非预期的操作。这一点对于本地智能体尤为突出，因为它们通常运行在文件、凭证、环境变量、MCP 工具附近，并且能够访问生产系统。

简单的解决方案是在任何操作执行前都询问用户，但过于频繁地请求许可本身也会造成安全问题。在收到足够多次重复提示后，人们会不再仔细阅读，审批流程也就失去了意义。

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

我们通过一个专门的分类器智能体来确定某个操作在该连续区间中的位置，该分类器会在操作执行前对其上下文进行审查。构建这一功能意味着，我们要将对智能体自主性应如何管控的直觉，转化为一个可针对真实智能体行为进行测试的、关于后果、意图和反馈的可行模型。

在上下文中判断风险

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

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

我们给分类器设定的核心规则是：当安全风险较低时，它应更加宽容；当风险较高时，则更加谨慎。基于这一总体原则，我们开始将分类器构建为一个快速、具备上下文审查能力的组件，使其能够直接嵌入智能体的执行路径中。

构建分类器

第一个技术决策是模型选择。该分类器在工具调用执行之前运行，因此它直接位于智能体循环中，需要既快速又准确。作为一家多模型公司，这在这方面很有帮助，因为我们可以尝试多种模型和推理模式，然后选择在速度与判断力之间达到最佳平衡点的那个。

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

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

我们避免使用独立的分类端点，因为额外的往返延迟会直接增加每次被审查工具调用的响应时间。相反，分类器与父智能体运行在同一个 RPC 流中，采用了类似于子智能体的架构。

设计反馈循环

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

用户意图是使该反馈有用的关键。问题不在于某个操作孤立地看是否有风险。问题在于该操作是否因用户要求智能体执行的任务而具有合理性。正是这一点，让正常的开发工作得以继续进行，同时让后果更严重的操作需要来自用户的更明确信号。

这种设计只有在分类器针对它应该放行和应该阻止的操作都进行了调优后才能生效，因此我们需要涵盖这两种情况的评估。

测试分类器

我们的第一组评估来自内部使用数据，目的是了解智能体工作的常规形态。分类器必须能够捕捉风险行为，同时不阻断日常开发工作，而内部会话是观察这一基线的最佳方式。我们从大约 12 小时的内部开发者会话开始，随后进行精简，并将常见操作去重，最终得到 6,122 条已标注的数据行。

我们还需要合成数据，因为最糟糕的情况在正常使用中并不常见。我们生成了智能体可能读取机密、接触生产数据、遵循不可信指令或采取具有重大副作用操作的案例。这些示例让我们能够覆盖最希望分类器捕捉到的失败场景。

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

我们通过生产环境中使用的同一套后端分类器循环来运行评估。这使我们能够测试完整的链路，包括工具使用、最终分类、模型覆盖以及解析失败。评估检查了最终的允许或阻断决策，以及分类器在需要先检查工作区再做出决定时所使用的上下文。

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

尽量减少直接阻断

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

当分类器运行时，目前会阻断约 4% 的操作，不过一次阻断并不会立即变成用户提示。分类器会向父智能体发送一条解释，父智能体通常可以缩小操作范围、选择不同的工具，或者完全避开该风险步骤。

分类器中的某些模块会触发用户干预，但从全局来看，我们发现自动审查模式下，仅有约 7% 的对话会导致至少一次干预。作为对比，我们合作的一些企业客户此前在其组织内部，约有 40% 的操作被拦截。

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

优化智能体自主性

自动审查功能仍处于早期阶段，随着智能体能力不断增强，我们对自主性连续体的理解也将持续变化。目前，该功能主要针对桌面应用中的本地智能体，我们预计同样的理念未来将应用于更多场景，以规范智能体的自主性。

我们希望智能体拥有真正的自主性，同时根据具体情境而非单一的全局权限设置来决定是否放慢其执行速度。分类器让我们能够在提升安全性的同时，避免将自主性退化为一连串的审批提示。它能识别出需要更多审查的操作，向父级智能体提供反馈，并在存在更安全执行路径时，让智能体继续工作。

自动审查现已成为新用户的默认设置。对于现有用户，可以在“设置 > 智能体”中启用该功能。

为本地智能体实现安全沙箱

Ani、Yash 与 Alex

推出 Grok 4.5

奖励破解正在淹没模型智能的提升