OpenClaw Agent 工具权限配置详解:从 gateway 权限管控到 tools.deny / alsoAllow / profile 最佳实践
一文讲透 OpenClaw 工具权限体系的每个字段、优先级关系与生产配置模式

在 OpenClaw 的多 Agent 生产环境中,工具权限管理是保障系统安全的核心机制。每个 Agent 能调用哪些工具、不能调用哪些工具,直接决定了它的行为边界和能力范围。本文结合生产环境的真实配置,系统讲解 OpenClaw 工具权限体系的每一个字段、优先级关系与最佳实践。
为什么需要精细的工具权限控制?
OpenClaw 支持多 Agent 并存,每个 Agent 有不同的职责定位:
- kb-writer(知识归档员):需要文件读写、会话管理,但不需要发消息
- oc-engineer(运维工程师):需要完整运维能力(exec、gateway 操作),但受沙箱约束
- design-yuntianguang(视觉设计师):需要图片生成工具,不需要网关管理权限
- editor-blog-yuntianchen(总编):只需编辑审核,不需要执行命令
如果所有 Agent 都使用全局默认配置(tools.profile: "full"),每个 Agent 都拥有全部工具权限,这显然不符合最小权限原则。OpenClaw 提供了多层次的权限控制机制,让你可以精确到每个 Agent、每个模型提供商、甚至每个请求发送者。
工具权限体系架构概览
OpenClaw 的工具权限控制分为 9 个层级,按优先级从低到高依次作用:
┌─────────────────────────────────────────────────────────────┐
│ 层级 9: Subagent 工具策略 tools.subagents.tools │
├─────────────────────────────────────────────────────────────┤
│ 层级 8: 沙箱工具策略 tools.sandbox.tools │
├─────────────────────────────────────────────────────────────┤
│ 层级 7: Agent 提供商策略 agents[].tools.byProvider │
├─────────────────────────────────────────────────────────────┤
│ 层级 6: Agent 工具策略 agents[].tools.allow/deny │
├─────────────────────────────────────────────────────────────┤
│ 层级 5: 全局提供商策略 tools.byProvider │
├─────────────────────────────────────────────────────────────┤
│ 层级 4: 全局工具策略 tools.allow / tools.deny │
├─────────────────────────────────────────────────────────────┤
│ 层级 3: 提供商工具集 tools.byProvider[provider]. │
│ profile │
├─────────────────────────────────────────────────────────────┤
│ 层级 1-2: 基础工具集 tools.profile / agents[]. │
│ tools.profile │
└─────────────────────────────────────────────────────────────┘核心原则:deny 始终优先于 allow,每一层只能进一步限制,不能恢复上一层已拒绝的工具。
[ILLUSTRATION: 工具权限 9 层级架构图,从底层基础工具集到顶层 Subagent 策略,每层用不同颜色区分,深色科技风背景]
字段详解
1. tools.profile — 基础工具集模板
tools.profile 设置工具权限的基准白名单。它定义了"默认情况下这个 Agent 有哪些工具可用"。
内置 Profile 及其包含的工具
| Profile | 包含内容 | 适用场景 |
|---|---|---|
minimal | 仅 session_status | 最严格的只读监控 Agent |
coding | group:fs、group:runtime、group:web、group:sessions、group:memory、cron、get_goal、create_goal、update_goal、update_plan、skill_workshop、image、image_generate、music_generate、video_generate | 代码/文件操作型 Agent(kb-writer 默认) |
messaging | group:messaging、sessions_list、sessions_history、sessions_send、session_status | 纯消息通信型 Agent(oc-engineer 默认) |
full | 无限制(所有工具) | 全功能主 Agent(main 默认) |
生产实测:OpenClaw 本地部署时,新配置文件默认使用
tools.profile: "coding"(除非显式设置了其他值)。
工具组(Tool Groups)速查
Profile 中的工具通常以组的形式引用:
| 组名 | 包含工具 |
|---|---|
group:runtime | exec、process、code_execution |
group:fs | read、write、edit、apply_patch |
group:sessions | sessions_list、sessions_history、sessions_send、sessions_spawn、sessions_yield、subagents、session_status |
group:memory | memory_search、memory_get |
group:web | web_search、x_search、web_fetch |
group:ui | browser、canvas |
group:automation | heartbeat_respond、cron、gateway |
group:messaging | message |
group:nodes | nodes |
group:agents | agents_list、get_goal、create_goal、update_goal、update_plan、skill_workshop |
group:media | image、image_generate、music_generate、video_generate、tts |
group:openclaw | 除 fs/runtime/canvas 外的所有内置工具 |
group:plugins | 所有插件工具(含 MCP 服务器) |
生产配置示例
// 全局默认使用 coding profile
{
"tools": {
"profile": "coding",
"agentToAgent": { "enabled": true },
"sessions": { "visibility": "all" }
}
}2. tools.deny — 显式拒绝工具列表
tools.deny 是最高优先级的拒绝机制。只要工具在 deny 列表中,无论其他配置如何,该工具都不可用。
字段规格
| 属性 | 值 |
|---|---|
| 类型 | string[](字符串数组) |
| 默认值 | [](空数组,无拒绝) |
| 匹配规则 | 大小写不敏感,支持 * 通配符 |
| 作用范围 | 全局或 per-agent |
生产配置示例
生产环境中几乎所有非主 Agent 都统一拒绝 gateway 工具:
// kb-writer:拒绝 gateway 管理工具
{
"agents": {
"list": [
{
"id": "kb-writer",
"tools": {
"profile": "coding",
"alsoAllow": ["message"],
"deny": ["gateway"]
}
},
// 所有其他非主 Agent 统一模式
{
"id": "design-yuntianguang",
"tools": {
"alsoAllow": ["exec", "image", "read", "write", "edit", "web_fetch"],
"deny": ["gateway"]
}
},
{
"id": "editor-blog-yuntianchen",
"tools": {
"deny": ["gateway"]
}
}
]
}
}为什么统一 deny gateway?
gateway工具允许 Agent 管理 OpenClaw Gateway 本身(重启、配置变更等),这是高权限操作。非运维类 Agent 不应有此权限,统一 deny 可以避免误操作。
拒绝整个工具组的技巧
{
"tools": {
"deny": ["group:runtime", "group:fs"]
}
}这会同时拒绝 exec、process、code_execution(runtime 组)和 read、write、edit、apply_patch(fs 组)。
3. tools.allow — 显式允许工具列表
tools.allow 定义白名单。当 allow 列表非空时,不在列表中的工具全部被拒绝。
字段规格
| 属性 | 值 |
|---|---|
| 类型 | string[](字符串数组) |
| 默认值 | [](空数组 = 不限制,跟随 profile) |
| 匹配规则 | 大小写不敏感,支持 * 通配符 |
| ⚠️ 互斥 | 与 alsoAllow 不可同时设置在同一作用域 |
与 alsoAllow 的互斥规则
这是最容易踩的坑:allow 和 alsoAllow 不能在同一个作用域中同时使用。
// ❌ 错误:allow 和 alsoAllow 不能共存
{
"tools": {
"allow": ["read", "write"],
"alsoAllow": ["message"] // 配置校验会直接拒绝
}
}
// ✅ 正确:二选一
{
"tools": {
"allow": ["read", "write", "message"] // 合并到 allow
}
}
// ✅ 正确:用 profile + alsoAllow 替代 allow
{
"tools": {
"profile": "coding",
"alsoAllow": ["message"] // 在 coding 基础上追加
}
}4. tools.alsoAllow — 增量允许工具列表
tools.alsoAllow 在 profile 基准之上追加允许的工具,不覆盖 profile 的默认设置。这是生产环境中最常用的扩展方式。
字段规格
| 属性 | 值 |
|---|---|
| 类型 | string[](字符串数组) |
| 默认值 | [] |
| 与 allow 的关系 | 互斥,不可同域共存 |
| 语义 | “在 profile 允许的工具之外,额外允许这些工具” |
生产配置示例:oc-engineer 的 alsoAllow
// oc-engineer:messaging profile 基础上追加运维工具
{
"agents": {
"list": [
{
"id": "oc-engineer",
"tools": {
"alsoAllow": [
"exec", "read", "write", "edit",
"web_fetch", "process", "gateway",
"cron",
"feishu_calendar_calendar",
"feishu_chat", "feishu_oauth",
"feishu_sheet", "feishu_task_task",
"feishu_task_agent", "feishu_task_attachment",
"sessions_spawn"
],
"profile": "messaging"
}
}
]
}
}这个配置的含义是:
- 基准:
messagingprofile(message+ session 工具) - 追加:运维所需的 exec、文件读写、网关管理、飞书集成等
生产配置示例:kb-writer 的 alsoAllow
// kb-writer:coding profile 基础上追加 message 工具
{
"agents": {
"list": [
{
"id": "kb-writer",
"tools": {
"profile": "coding",
"alsoAllow": ["message"],
"deny": ["gateway"]
}
}
]
}
}这是 kb-writer 的经典配置:coding profile 提供了文件读写和会话管理能力,alsoAllow 追加了 message 工具用于飞书通道交互,deny 排除了 gateway 防止误操作。
5. tools.byProvider — 按模型提供商细化权限
tools.byProvider 允许对不同模型提供商设置不同的工具权限。这对于"某些模型能力强应开放更多工具,某些模型能力弱应限制工具"的场景非常有用。
字段规格
| 属性 | 值 |
|---|---|
| 类型 | Record<providerKey, { profile?, allow?, deny? }> |
| providerKey 格式 | "provider-id" 或 "provider/model-id" |
| 默认值 | 无(继承上级配置) |
配置示例
{
"tools": {
"profile": "coding",
"byProvider": {
// 所有 google 提供商的模型使用 minimal profile
"google-antigravity": {
"profile": "minimal"
},
// 仅 openai/gpt-5.4 使用扩展权限
"openai/gpt-5.4": {
"allow": ["group:fs", "sessions_list"]
}
}
}
}生产中的 byProvider 应用
虽然当前生产配置中没有直接使用 byProvider,但这是一个强大的功能。典型应用场景:
- 强模型 vs 弱模型:对 GPT-4/Claude 开放更多工具,对轻量模型限制工具
- 成本敏感场景:对低价模型减少工具调用,降低 token 消耗
- 安全分级:对不可信模型提供商限制敏感工具
6. tools.sandbox.tools — 沙箱工具策略
当 Agent 运行在 Docker 沙箱中时,tools.sandbox.tools 提供第二层工具过滤。这是独立于主工具策略的额外约束。
关键字段
| 字段 | 类型 | 说明 |
|---|---|---|
tools.sandbox.tools.allow | string[] | 沙箱内允许的额外工具 |
tools.sandbox.tools.deny | string[] | 沙箱内明确拒绝的工具 |
tools.sandbox.tools.alsoAllow | string[] | 沙箱内追加允许的工具 |
沙箱工具策略的 MCP 特殊处理
当沙箱模式开启且 Agent 使用了 MCP 服务器时,需要在沙箱工具策略中显式放行:
{
"tools": {
"sandbox": {
"tools": {
"alsoAllow": [
"web_search", "web_fetch",
"memory_search", "memory_get",
"bundle-mcp" // 放行所有 MCP 工具
]
}
}
}
}常见排障:MCP 服务器配置正确但工具不可用 → 检查
tools.sandbox.tools是否包含bundle-mcp或对应 MCP 服务器的工具名。
优先级与协作关系
权限评估完整流程
当一个工具调用请求到达时,OpenClaw 按以下顺序评估:
1. 加载基础 Profile(tools.profile / agents[].tools.profile)
2. 加载提供商 Profile(tools.byProvider[provider].profile)
3. 应用全局 deny(tools.deny)
4. 应用全局 allow(tools.allow)
5. 应用提供商 deny/allow(tools.byProvider[provider].allow/deny)
6. 应用 Agent 级 deny/allow(agents[].tools.allow/deny)
7. 应用 Agent 级提供商策略(agents[].tools.byProvider[provider].allow/deny)
8. 应用沙箱工具策略(tools.sandbox.tools / agents[].tools.sandbox.tools)
9. 应用 Subagent 工具策略(tools.subagents.tools)关键规则:
- 每一层只能进一步限制,不能恢复上一层已拒绝的工具
deny始终优先于allow- Agent 级配置优先于全局配置
- 沙箱工具策略是额外的独立约束层
优先级可视化
全局配置 Agent 配置
───────────────── ─────────────────
tools.profile ──────────┐
tools.byProvider ───────┤
▼
tools.allow / alsoAllow ──┼──► 合并 ──► 最终可用工具集
tools.deny ──────────────┘ │
▼
agents[].tools.profile
agents[].tools.byProvider
agents[].tools.allow/deny
agents[].tools.sandbox.tools
tools.subagents.tools生产环境完整配置示例
场景 1:全功能主 Agent(main)
{
"id": "main",
"tools": {
"profile": "full", // 全部工具
"alsoAllow": [
"feishu_calendar_calendar",
"feishu_chat",
"feishu_oauth",
"feishu_sheet",
"feishu_task_task",
"exec", "read", "edit",
"write", "sessions_history",
"sessions_spawn", "sessions_send"
],
"deny": ["gateway"] // 不允许管理网关(避免自操作冲突)
}
}场景 2:代码/文件操作型 Agent(kb-writer)
{
"id": "kb-writer",
"tools": {
"profile": "coding", // 文件读写 + 会话管理 + 媒体生成
"alsoAllow": ["message"], // 追加飞书消息能力
"deny": ["gateway"] // 禁止网关操作
}
}场景 3:运维工程师 Agent(oc-engineer)
{
"id": "oc-engineer",
"tools": {
"profile": "messaging", // 消息 + 会话基础
"alsoAllow": [
"exec", "read", "write",
"edit", "web_fetch",
"process", "gateway", // 运维核心能力
"cron",
"feishu_calendar_calendar",
"feishu_chat", "feishu_oauth",
"feishu_sheet",
"feishu_task_task",
"feishu_task_agent",
"feishu_task_attachment",
"sessions_spawn"
]
// 无 deny → 所有工具均可用(除被 sandbox 限制的)
}
}场景 4:纯审核型 Agent(editor-blog-yuntianchen)
{
"id": "editor-blog-yuntianchen",
"tools": {
"deny": ["gateway"] // 极简配置:仅禁止网关
// 继承全局 coding profile
}
}场景 5:图片生成型 Agent(design-yuntianguang)
{
"id": "design-yuntianguang",
"tools": {
"alsoAllow": [
"exec", "image",
"read", "write", "edit",
"web_fetch"
],
"deny": ["gateway"]
// 继承全局 coding profile
}
}常见误区与排障指南
误区 1:allow 和 alsoAllow 混用
[ILLUSTRATION: alsoAllow vs allow 对比图,左侧显示 alsoAllow 在 profile 基础上增量追加,右侧显示 allow 覆盖整个白名单,用箭头和对比色清晰展示两者的区别]
误区 2:只修改了配置文件但忘记重启 Gateway
// ❌ 错误:配置校验会拒绝
{
"tools": {
"allow": ["read", "write"],
"alsoAllow": ["message"]
}
}
// ✅ 正确:统一使用 alsoAllow + profile
{
"tools": {
"profile": "coding",
"alsoAllow": ["message"]
}
}
// ✅ 正确:统一使用 allow(显式列出所有工具)
{
"tools": {
"allow": ["read", "write", "message"]
}
}排障:运行 openclaw config validate 检查配置,错误信息会明确提示 allow/alsoAllow 互斥冲突。
误区 2:只修改了配置文件但忘记重启 Gateway
修改 ~/.openclaw/openclaw.json 后,必须重启 Gateway 才能生效:
# 验证配置语法
openclaw config validate
# 重启 Gateway(热加载)
openclaw gateway restart排障:运行 openclaw doctor 检查工具权限状态:
openclaw doctor 2>&1 | grep -A5 "kb-writer"输出示例:
kb-writer │ ✓ tools.message available (alsoAllow)
kb-writer │ ⚠ tools.browser not available (denied by tools.deny)误区 3:认为 allow 列表中的工具一定可用
tools.allow 只设置了白名单,但如果同时存在 tools.deny,deny 优先:
{
"tools": {
"allow": ["read", "write", "exec"],
"deny": ["exec"] // exec 虽然在了 allow 中,但仍然不可用
}
}误区 4:沙箱模式下 MCP 工具消失
当 Agent 运行在 Docker 沙箱中时,MCP 工具需要通过 tools.sandbox.tools.alsoAllow 额外放行:
# 排查:检查沙箱工具策略
openclaw sandbox explain --agent kb-writer
# 修复:在 sandbox.tools 中添加 bundle-mcp
{
"tools": {
"sandbox": {
"tools": {
"alsoAllow": ["bundle-mcp"]
}
}
}
}误区 5:工具名大小写错误
工具名称大小写敏感:
// ❌ 错误:大小写不匹配
{
"tools": {
"alsoAllow": ["Message", "EXEC"]
}
}
// ✅ 正确
{
"tools": {
"alsoAllow": ["message", "exec"]
}
}误区 6:deny write 不会自动 deny apply_patch
write 和 apply_patch 是两个独立的工具 ID:
// ❌ 错误:只 deny write,apply_patch 仍然可用
{
"tools": {
"deny": ["write"]
}
}
// ✅ 正确:同时 deny 所有写操作工具
{
"tools": {
"deny": ["write", "edit", "apply_patch"]
}
}
// ✅ 更简洁:deny 整个文件系统组
{
"tools": {
"deny": ["group:fs"]
}
}最小权限实践
设计原则
- 从最小开始:默认使用
profile: "minimal"或"coding",按需追加 - alsoAllow 优于白名单:优先使用
alsoAllow+ profile 而非全量allow - 显式拒绝敏感工具:非运维 Agent 统一 deny
gateway - 沙箱 + 工具策略双重保险:对高风险 Agent 同时启用沙箱和工具限制
各角色推荐配置模板
| Agent 类型 | 推荐 Profile | 建议 alsoAllow | 建议 deny |
|---|---|---|---|
| 主 Agent | full | 按需追加 | gateway(可选) |
| 代码/文件操作 | coding | 业务所需工具 | gateway |
| 消息/通信 | messaging | 额外需要的工具 | gateway + exec |
| 运维管理 | messaging | exec、gateway、cron、process | 无 |
| 只读审核 | minimal | read、web_fetch | exec、write、edit、apply_patch |
| 图片生成 | coding | image_generate、exec、web_fetch | gateway |
回滚建议
- 配置备份:每次修改前备份
~/.openclaw/openclaw.json - 渐进变更:一次只改一个 Agent 的配置,验证后再改下一个
- 使用 doctor 验证:修改后立即运行
openclaw doctor确认权限状态 - 保留变更记录:在知识库中记录每次权限变更的 rationale
# 备份当前配置
cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date +%Y%m%d-%H%M%S)
# 验证并重启
openclaw config validate && openclaw gateway restart
# 验证权限状态
openclaw doctor总结
OpenClaw 的工具权限体系是一个多层、可组合的精密系统。理解其优先级关系(profile → provider profile → allow/deny → sandbox → subagent)是正确配置的基础。
核心记忆点:
profile设基准,alsoAllow做增量,deny做最终拦截allow和alsoAllow互斥,不可同域混用deny始终优先,每一层只能限制不能放行- 沙箱模式下需要额外配置
tools.sandbox.tools - 使用
openclaw doctor和openclaw sandbox explain排障
掌握了这套体系,你就能为每个 Agent 精确配置"够用但不超额"的工具权限,既保障功能完整性,又遵循最小权限的安全原则。
参考来源
- OpenClaw Tools and Custom Providers 文档
- OpenClaw Sandbox vs Tool Policy vs Elevated 文档
- OpenClaw Multi-Agent Sandbox & Tools 文档
- OpenClaw GitHub 仓库
- OpenClaw 配置说明
关联阅读
- [[2026-07-03-1628-openclaw-alsoallow-guide|OpenClaw Agent 工具权限配置:alsoAllow 实战指南]]
- [[2026-05-10-2343-openclaw.json逐行分析与优化决策|OpenClaw.json 逐行分析与优化决策]]
- [[2026-06-25-1949-配置知识归档员双模式工作流与飞书渠道|配置知识归档员双模式工作流与飞书渠道]]
- [[2026-07-26-2227-ComfyUI集成与智能体配置全记录|OpenClaw ComfyUI 集成与智能体配置全记录]]
梦行志