概述
Permission system 拦截 agent 的每一次工具调用,给出三种决策之一:允许(allow) 执行、拒绝(deny) 执行,或者询问用户(ask) 确认。 它把静态配置与动态运行时分析组合起来。三个组件共同决定结果:- Rules —— 针对每个 tool 与命令的显式 allow / deny / ask 模式,最高优先级。规则有两种来源:在
PermissionContext中静态预配置,或在 ASK 提示中由用户接受建议规则而动态加入。建议规则由本次工具调用自动生成 —— 一旦接受,将来相同的调用便会被自动处理,不再询问。 - Mode —— 配置阶段设定的全局静态策略;决定所有不命中任何规则的调用的默认行为(例如
EXPLORE让 agent 进入只读;DONT_ASK静默拒绝未命中的调用)。 - Built-in Checks —— 由 tool 自身在运行时基于真实输入做的动态分析:只读命令检测(在调用时解析 bash 命令)、危险路径保护(检查实际文件路径或命令目标)。工具可以通过
PermissionDecision.bypass_immune=True将一次 safety ASK 标记为不可绕过;引擎会在DEFAULT、ACCEPT_EDITS、DONT_ASK下尊重该标记(allow rules 也无法将其静默)。BYPASS模式是唯一例外 —— 它按设计明确跳过所有 safety ASK。
- DEFAULT
- EXPLORE
- ACCEPT_EDITS
- BYPASS
- DONT_ASK
Deny 规则与显式 ask 规则在每个 mode 下都始终生效(包括
BYPASS)。工具发出的 safety ASK(bypass_immune=True)在 DEFAULT、ACCEPT_EDITS、DONT_ASK 下被尊重 —— allow 规则也无法将其静默。BYPASS 模式按设计跳过:BYPASS 的语义是”用户已主动放弃 safety 提示;只剩 deny / ask 规则作为护栏”。Permission Mode
AgentScope 支持以下模式,分别适配不同的部署场景:
可以在创建 agent 时通过
AgentState.permission_context 设置 mode,也可以在运行时更新:
Permission Rule
PermissionRule 把某个 tool 与具体的调用模式映射到三种行为之一:ALLOW、DENY、ASK。
每条规则由下述字段组成。当权限引擎评估一条规则时,它会用 rule_content 与实际调用入参调用该 tool 的 match_rule() 方法,判断规则是否命中。
str
必填
规则适用的 tool 名:
"Bash"、"Read"、"Write"、"Edit",或任意自定义 tool 名。str | None
必填
匹配模式 —— 语义随
tool_name 变化:- Bash:通配前缀模式(
npm run:*命中npm run build、npm run test) - Read / Write / Edit:glob 模式(
src/**/*.py命中src/下任意.py) - 其他 tool:对 JSON 序列化后的参数做精确匹配
PermissionBehavior
必填
ALLOW、DENY 或 ASKstr
必填
规则来源:
"userSettings"、"projectSettings"、"session" 等。模式示例
rule_content 由各 tool 的 match_rule() 方法消费,并由 ToolBase.generate_suggestions() 自动生成。由于这两个方法都属于 tool 接口的一部分,每个 tool 可以独立定义自己的模式语法与匹配逻辑。
AgentScope 内置工具的模式约定如下:
- Bash
- 文件类工具(Read / Write / Edit)
针对
command 参数做匹配。模式格式为 COMMAND_PREFIX:* —— 前缀是命令的首段 token,* 匹配后续任意参数。配置规则
初始化时 —— 在创建 agent 时把规则传入PermissionContext:
UserConfirmResultEvent.rules 中回传,agent 会自动写入引擎:
Built-in Checks
每个 tool 都实现了一个check_permissions() 方法,在运行时基于真实调用入参执行检查。AgentScope 内置工具覆盖三类检查:
- 危险路径保护 ——
Write、Edit、Bash检查目标文件或命令是否触及敏感路径。返回一个 bypass-immune 的 safety ASK,在DEFAULT/ACCEPT_EDITS/DONT_ASK下被尊重(allow 规则无法静默)。BYPASS模式按设计跳过。 - 只读命令检测 ——
Bash解析命令字符串识别只读操作,在所有 mode(包括DEFAULT)下自动放行。对于像Bash这种结果依赖于输入的工具,这一判定通过check_read_only()方法暴露(详见下文)。 - ACCEPT_EDITS 模式 ——
Write与Edit自动放行已配置工作目录内的文件操作。Bash额外要求 filesystem 命令(mkdir/touch/rm/cp/mv/sed等)的所有目标路径都在某个工作目录内。
自定义 tool
自定义 tool 可以重写check_permissions() 添加工具特定的权限逻辑。如果工具的只读状态取决于输入(比如 Bash —— ls 是只读,rm 不是),还应该重写 check_read_only()。
Safety check 契约
Safety check 是工具自己发出、认为太危险不能被静默放行的 ASK —— 例如Write 到 ~/.bashrc、Bash 执行 rm -rf /。在决策上设 bypass_immune=True,即使命中了 allow 规则或处于会自动放行的 mode,引擎也仍然把 ASK 浮到用户。
适用于”一次错误调用就会造成用户几乎肯定不想发生的破坏”的场景。例如:自定义的 DeployTool 在目标是 prod-* 时返回 bypass_immune=True,那么为 staging 配的 allow_rules["DeployTool"] = ["*"] 也不会意外授权生产部署。
各 mode 下的具体处理:
普通 ASK(
bypass_immune=False,默认值)可以被 DEFAULT/ACCEPT_EDITS 下匹配的 allow 规则覆盖,在 BYPASS 下被兜底放行。
只读命令
常见的只读 bash 命令在没有任何规则的情况下也会被自动放行,在所有 mode(包括DEFAULT)下都生效。复合命令(&&、||、;、|)只有在所有子命令都只读时才视为只读。输出重定向(>、>>)会让命令立即失去只读属性。
完整只读命令列表
完整只读命令列表
危险路径保护
常见场景
下面的示例展示了如何为常见部署场景配置AgentState.permission_context。每个示例把一种 mode 与一组规则结合,匹配特定的使用场景。