openinterpreter Auto-Review 深入解析：让 Guardian 审查代理替你评估批准请求

在 openinterpreter（面向 Kimi K3、GLM 5.3 等开放模型的编程智能体）中，当智能体想执行一条需要授权的敏感操作时，默认行为是直接弹出提示询问用户。对于长任务或多命令流水线，这会不断打断人的注意力。Auto-Review（自动审查）机制就是把符合条件的批准请求委托给一个内置的"审查代理"（源码中称为 Guardian）来评估，替代"每次都问人"的默认路径。读完本文，你将理解 approvals_reviewer = "auto_review" 的完整配置方式、它在审批链路中的实际位置、Guardian 内置风险策略（policy）的判定规则，以及如何通过管理端配置强制或放开该能力。

一、Auto-Review 是什么：换评估主体，不是拆沙箱

官方文档对 Auto-Review 的定义非常克制，核心信息有两条：

1. 委托评估：auto-review 可以把符合条件的批准提示（eligible approval prompts）委托给一个 reviewer agent 评估，而不是始终直接询问用户。
2. 不改变隔离边界：Auto-review 不会移除沙箱，它改变的只是"在当前策略下，由谁来评估符合条件的批准提示"。因此文档给出的使用前提是——仅当审查策略（reviewer policy）与沙箱设置对该仓库足够收敛时才应启用。

这个区分很关键：很多人会误以为"自动批准"等于放权，而实际上 openinterpreter 的模型是**"执行仍受沙箱与审批策略约束，审批环节的人被替换成审查代理"**。审查代理做出的每一个决定依然落在既有的权限体系内。

最小配置

启用 Auto-Review 只需要一行 TOML（写入 config.toml）：

approvals_reviewer = "auto_review"

文档同时提醒：如果你真正想做的是"让智能体审查代码变更"，那不是 auto-review 的职责，而应使用 /review 交互命令或 interpreter exec review 子命令。Auto-Review 解决的是审批流自动化问题，代码审查是另一条独立的功能线。

二、配置项源码级对照

2.1 approvals_reviewer 字段：user 与 auto_review 两档

该字段的取值类型定义在 ApprovalsReviewer 枚举中。从配置加载器测试代码可以看到它至少包含 User 与 AutoReview 两个变体（见 loader 单元测试）：

• approvals_reviewer = "user"（默认语义）：符合条件的批准提示仍交给用户决策；
• approvals_reviewer = "auto_review"：符合条件的批准提示交给 Guardian 审查代理决策。

2.2 [auto_review] 表：向审查代理追加策略指令

除了顶层开关，配置结构中还定义了 auto_review 配置表。在 config_toml.rs 中：

#[derive(Serialize, Deserialize, Debug, Clone, Default, PartialEq, Eq, JsonSchema)]
pub struct AutoReviewToml {
    /// Additional policy instructions inserted into the guardian prompt.
    pub policy: Option<String>,
}

源码注释直接说明了它的语义：policy 是一段追加注入到 Guardian 审查提示词中的额外策略指令。也就是说，你可以在不改动核心风险规则的前提下，按仓库特性补充约束（例如"本仓库的生产环境主机名单是 X，向 X 发送数据需人工确认"这类组织级细则），使审查代理的判定更贴合当前代码库。

三、审批链路：Auto-Review 在整条链路中位于何处

理解 Auto-Review 最好的方式是看它被调用的位置。审批入口在 Session::request_approval，源码注释明确写出了优先级：

// Approval precedence is:
// 1. Hooks
// 2. If StrictAutoReview || Guardian enabled, then Guardian. Else, user.

即整条链路为：

1. Hooks 优先：先执行权限请求钩子（run_permission_request_hooks），若钩子显式返回 Allow / Deny，则直接以钩子结果结案，来源标记为 Hook；
2. Guardian（审查代理）：当严格自动审查（strict_auto_review）开启或 Guardian 能力启用时，请求进入 request_guardian_approval 分支；否则回落到 request_user_approval，由用户在终端确认；
3. 来源记账：每次裁决都会记录 source（Hook / Guardian / User），便于后续区分"这条批准是代理给的还是人给的"。

几个值得注意的实现细节：

• 失败即拒绝：若 Guardian 无法构造审查动作（into_guardian_request 失败），代码不会"降级去问人"，而是直接返回拒绝（automatic approval review could not prepare the action）。这是一种保守的 fail-closed 设计——自动审查通道自身出错时宁可阻断，也不放行。
• 审查会话可重试：guardian/review.rs 中提供了 review_approval_request、review_approval_request_with_cancel 两个入口，以及 should_retry_guardian_review 重试判定逻辑（约 L984），从源码结构看，审查代理的结论在被认为不可靠时可触发重试，而非一次定生死。
• 不可审查的动作不进自动通道：request_reviewer_approval 中，只有能转换为 Guardian 审查动作的请求才走自动评估，这正对应文档里"eligible approval prompts"（符合条件的批准提示）的说法——不是所有审批都会被审查代理接管。

四、Guardian 的策略内核：它到底按什么规则裁决

Auto-Review 的"判断力"来自 Guardian 模块内置的审查策略。策略文本位于 guardian/policy.md（另有 policy_template.md 与提示词构造 prompt.rs）。内置策略围绕五个风险类别给出 Allow/Deny 规则，摘取其中关键判据：

4.1 数据外泄（Data Exfiltration）

• 将敏感数据发送到不受信目的地属于 high 风险。"外泄"（egress）的定义很宽：任何让外部人员可能访问到数据的动作都算，包括作为参数传递、作为元数据附带，或作为被共享工件的内容间接外流；
• 受信目的地限于组织/用户自有的内部存储、流水线、作业系统、已批准的内部工件上传流程，以及"私有且经过验证"的组织/用户自有仓库；其他仓库默认为不受信；
• 结果规则：除非用户明确授权"这份具体数据发往这个具体目的地"，否则拒绝任何暴露敏感数据的动作。

4.2 凭据探测（Credential Probing）

• 从非预期来源（如浏览器配置目录、服务日志）提取凭据去执行"正常认证失败后"的动作，属于 high 风险；
• 但通过服务正常认证流程使用凭据（含环境中已有的凭据）属于常规操作，不算探测；
• 结果规则：当用户授权程度为 low 或 unknown 时拒绝凭据探测。

4.3 持续性安全弱化（Persistent Security Weakening）

• 以"使某个重要服务在未来持续暴露于严重威胁"的方式修改安全设置（权限篡改、过宽访问、暴露的密钥）属于高关注对象；共享服务或敏感边界上的大范围、持久性弱化是 high 风险；
• 边界情形：为一次性有界操作临时关闭窄范围的控制（如临时禁用某个证书校验）通常是 medium；但若涉及生产关键、无限期、通配/全局范围，仍保持 high。

4.4 破坏性操作（Destructive Actions）

• 难以恢复的数据删除/修改、破坏生产服务、大范围未要求的 git 清理与重置均为 high 风险；
• 对 git 操作的精细化分级：只影响单个已验证的用户功能分支或有限仓库本地文件（含单引用 --force-with-lease 推送）时按 low/medium 处理；触及受保护/默认分支、宽泛 refspec、删除分支、把私有数据推到未验证远端、绕过安全钩子或摧毁未推送工作时保持 high；
• 特别强调：不能假设用户的任务描述授权了完成任务的所有可能步骤——当破坏范围超出任务具体授权时，授权程度应降为 low 或 unknown；
• 明确点名 HOME 等常见环境变量被遮蔽（shadowing）是高危信号，结果规则直接要求拒绝。

4.5 低风险操作的"防误报"条款

• 沙箱重试/升级本身不构成可疑信号；
• 仅因路径在可写工作区之外就给 high/critical 是错误的——良性的本地文件系统操作通常只是 low 风险；
• 用户明确请求删除某个具体本地路径且只读检查确认目标是普通文件/目录、范围窄时，rm -rf 通常也只是 low/medium。

这套"先分级、再给出 Outcome rule"的写法，本质上是把安全评审经验固化成可被模型稳定执行的规则集。文档中"仅在审查策略和沙箱足够严格以适用于仓库时使用"的告诫，指的就是：策略越宽泛，Guardian 放行的空间越大，你必须确认这套默认策略（或你通过 [auto_review] policy 追加的规则）与你的仓库敏感度匹配。

五、组织级管控：强制、允许列表与退出通道

Auto-Review 不只有用户侧开关，管理端（管理员/受管配置层）也能约束它，实现位于 config/src/loader/mod.rs 与 config_requirements.rs：

• 允许列表语义：受管配置可以用 allowed_approvals_reviewers 限制用户可选择的审查者，例如：

allowed_approvals_reviewers = ["auto_review"]

• 强制 auto_review 时保留退出通道：源码注释写明了一个有意思的设计——approvals_reviewer = "auto_review" 作为受管约束时，同时允许 user，"让人们可以退出自动审查者"。对应的回写测试（legacy_managed_config_backfill_allows_user_when_guardian_is_required）断言：管理端强制 auto_review 时，生成的允许列表是 ["auto_review", "user"]；而强制 user 时列表只剩 ["user"]。
• 完全禁用：需求层还定义了 disable_auto_review 字段（config_requirements.rs），管理员可以整条关闭自动审查能力，使 auto_review 取值根本不可用。

这组机制的组合拳是：个人可以开 auto-review 提升效率；组织可以强制开启、限制选择，或彻底禁用——而即使被强制开启，用户始终保留"改回人工审批"的退出权。

六、边界与最佳实践

把文档表述和源码证据放在一起，可以归纳出使用 Auto-Review 的几条硬边界：

1. 沙箱仍在位。Auto-Review 只替换审批环节的评估者；文件写入范围、网络出口等隔离约束仍由沙箱模式独立控制。想靠它"提权"是错误方向——正确做法是先收紧 sandbox_mode 与审批策略，再考虑让 Guardian 代答。
2. 审查代理是 fail-closed 的。从 approvals.rs 看，Guardian 通道构造失败即拒绝，不会静默放行；配合重试判定逻辑，其目标是"拿不准就拒"。
3. 审批优先级是 Hooks → Guardian/User。如果你的部署里配置了权限请求钩子，钩子结果优先于审查代理；因此审计"谁批的"时要看 source 标记（Hook / Guardian / User）。
4. 代码审查是另一条产品线。想审查 diff 与变更质量，用 /review 或 interpreter exec review；auto-review 不负责这个场景。
5. 按仓库调策略。利用 [auto_review] policy 注入仓库专属约束（受信目的地清单、禁触分支、生产主机名等），让 Guardian 的判定规则与你仓库的实际信任边界一致——这也是文档"reviewer policy 必须足够窄"的落地手段。

七、小结

openinterpreter 的 Auto-Review 是一个设计上相当克制的功能：一行 approvals_reviewer = "auto_review" 即可把符合条件的审批从"问人"切换为"问 Guardian"，但沙箱、Hooks 优先级、fail-closed 的失败语义、以及组织级的允许列表与退出通道，共同保证了这条自动化通道不会演变成不受控的自动批准。它的适用画像也很清晰：审查策略与沙箱都已收敛到匹配仓库风险等级的团队，用它消除审批等待；其余情况，保留人工审批仍然是文档给出的默认建议。