自主性级别
自主性是位于命名风险配置文件上的逐代理设置:[risk_profiles.<alias>].level。每个代理通过 agents.<alias>.risk_profile = "<profile-alias>" 引用一个风险配置文件。共三种设置;默认为 supervised。
readonly / supervised / full 是仅有的可接受值;read_only(带下划线)在加载配置时会被拒绝。有关该配置文件如何嵌入完整配置,请参阅规范的最小可运行示例。
三个级别
readonly
智能体可以观察,但不能更改任何内容。允许使用的工具是那些没有副作用的工具:
file_read,file_listmemory_searchhttp(仅支持 GET;POST 被阻止)web_searchtime
适用于:面向公众的问答代理、仅分析部署,或在允许其写入任何内容之前,用于验证新工具配置的方式。
supervised(默认)
低风险工具会自动运行。中等风险工具会触发操作员审批提示。高风险工具将被阻止。
风险分类:
| 风险 | 示例 | 行为 |
|---|---|---|
| 低 | file_read、http GET、memory_search、web_search、time | 运行 |
| 中等 | 工作区内的 file_write,具有允许命令的 shell,以及向允许域发送的 http POST | 询问操作员 |
| 高 | shell 中未知/被拒绝的命令、file_write 超出工作区范围、破坏性模式 | 块 |
审批通道: 审批提示通过发起对话的通道送达。Telegram 使用内联键盘按钮;Slack Socket Mode 使用 Block Kit 按钮;Discord、Signal、Matrix 和 WhatsApp 会在提示中嵌入一个简短的令牌,并等待 <token> approve|deny|always 形式的回复。在 CLI 中,它是一个内联提示。在 ACP 中,agent 会从 agent 向 client 发起一个 session/request_permission JSON-RPC 请求(而非 session/update 通知);client 通过返回 {"outcome": {"outcome": "selected", "optionId": "allow-once|allow-always|reject-once"}} 或 {"outcome": {"outcome": "cancelled"}} 来执行批准、始终批准或拒绝操作。参见 ACP → session/request_permission。
超时: 未响应的审批请求会在通道的 approval_timeout_secs 后过期(大多数通道默认为 120;请参阅各通道的配置块)。超时将被视为拒绝。
full
无审批关卡;所有标记为低/中/高风险的工具调用都会直接运行,无需询问。workspace_only 被隐式禁用(代理可以访问工作区之外的路径);forbidden_paths 仍然生效拦截;操作系统级沙箱(sandbox_enabled + sandbox_backend)仍然适用。
这适用于可信的本地开发、CI 或需要端到端运行且无需人工干预的标准操作流程(SOP)。如果你需要 full 模式 + 无工作区限制 + 无沙盒,请参阅 YOLO 模式。
每个工具的覆盖设置
auto_approve、always_ask 和 excluded_tools 在风险配置文件中以工具名称的扁平列表形式存在(而非嵌套表)。excluded_tools 也可按通道使用(channels.<type>.<alias>.excluded_tools),用于在不更改配置文件的情况下从特定界面隐藏工具。
跨渠道审批路由
默认情况下,审批提示会通过发起会话的那个通道传递。若要改为将某个 profile 的工具审批发送到一个独立的审批者通道(例如,由公共通道驱动的 agent,其风险操作必须由单独的 ops 通道批准,或由不同的主体批准),请在风险 profile 上设置 approval_route:
[risk_profiles.frontline.approval_route]
approver_channel = "matrix.ops" # 一个渠道注册表键,不是发起者
on_no_approver = "deny" # 默认值;或 "inherit-originator"
timeout_secs = 120 # 默认值;限制审批人的响应时间窗口
approver_channel是接收审批请求的通道注册表键。键带有平台限定,格式为<channel>.<alias>(例如matrix.ops或telegram.default);仅写平台名(例如matrix)时,只有在该平台只有一个通道时才会解析成功。单独的别名不是注册表键,并且会失败并关闭。设置路由后,审批门禁只会询问该通道,不会询问发起通道。on_no_approver决定当审批人未明确回答、无法联系、不是已注册频道,或超时后会发生什么:deny(默认值)会在关闭状态下失败,并拒绝该工具调用。inherit-originator回退到 originating-channel 提示(当前行为)。
timeout_secs(默认 120)限制闸门在应用on_no_approver之前等待审批者的最长时间,因此卡住的审批者通道不会阻塞一次轮转。
当 approval_route 缺失时(默认情况),审批的行为与上文所述完全一致:通过发起对话的那个渠道交付。默认的 fail-closed 行为意味着,配置错误或不可达的审批者会拒绝,而不是静默地自我批准。
范围。
approval_route在两种 turn 路径上都会生效:交互式、由 channel 驱动的路径(携带 live channel handle 的 turn,例如流式 agent chat)以及不带原始 channel 的非交互式路径(gateway chat/webhook 分发和 agent-to-agent peer 消息)。在非交互式路径上,审批者必须是运行中的 daemon 里一个 live、已注册的 channel(通过 daemon 的 channel registry 解析);如果该 registry 不可用(例如没有启动任何 channel 的一次性 CLI 运行),或者所命名的审批者不是 live 的,则该 gate 会回退到 profile 的非交互式默认值,而该默认值在默认on_no_approver = "deny"下会 fail closed(拒绝)。
命令允许列表
对于 shell 工具来说,特别需要注意:如果 allowed_commands 非空,则采用严格模式:任何未列出的命令都会被阻止。shell 策略验证器会在此白名单之上进行破坏性模式检测。
路径规则
workspace_only = true 会将读取和写入限制在 <workspace>/** 内,此外还包括针对所请求访问模式配置的任意 allowed_roots。绝对路径形式的工作区、允许根目录和 forbidden_paths 条目使用路径组件前缀。当多个条目匹配时,最具体的前缀优先;深度相同时,禁止条目优先。因此,禁止子树可以阻止访问工作区或允许根目录的一部分,而范围较窄的操作允许规则仍可在 /home 或 /tmp 等宽泛的默认禁止根目录下使用。
解析后的文件检查会在解析文件系统别名后比较所有匹配的条目,因此通过符号链接表示被禁止的子树也无法绕过拒绝规则。这些是绝对前缀规则:不支持 glob 匹配或相对于工作区的忽略模式语义。
沙盒
操作系统级沙箱字段位于同一风险配置文件中。有关各操作系统的后端选择,请参阅 Sandboxing。
环境透传
shell 工具默认在最小化环境中运行;请通过风险配置文件公开特定的环境变量。机密信息(API_KEY、_TOKEN、_SECRET、_PASSWORD 模式)_永远不会_被自动传递;请显式列出它们,或在命令内部从机密存储中获取。
每个渠道更严格的自主权
自主级别是针对每个 agent 的,而非针对每个渠道。若要让面向公众的渠道以比主 agent 更严格的级别运行,请定义绑定到更严格风险配置的第二个 agent,并将该渠道路由到它。当你只需要隐藏个别工具时,按渠道配置 excluded_tools(channels.<type>.<alias>.excluded_tools)是更省事的选项,无需第二个 agent。
可观测性
审批请求、授权、拒绝和超时均通过 infra crate 发出结构化事件:
INFO autonomy:approval_requested 工具=file_write 路径=/tmp/foo.txt 频道=discord 用户=alice
INFO autonomy:approval_granted 工具=file_write 路径=/tmp/foo.txt 频道=discord 用户=alice
WARN autonomy:approval_timeout 工具=shell 命令="git push" 频道=telegram 用户=bob
WARN autonomy:blocked 工具=shell 命令="rm -rf /tmp" 原因="forbidden pattern"
阻塞调用、拒绝和超时都值得审计,但它们不是工具回执。它们会发出可观测性事件;tool receipts 会在启用回执时附加到成功的工具结果上。
为什么不直接使用二进制的“安全模式”?
因为有用的中间地带很大。如果一个用户希望让代理自动运行脚本,但不能推送到 master 分支,那么就需要介于“全部允许“和“全部禁止“之间的方案。三级自主权限 + 按工具覆盖 + 命令白名单提供了这样的调节能力,同时又不会让配置变得碎片化。