目录

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包含内容适用场景
minimalsession_status最严格的只读监控 Agent
codinggroup:fsgroup:runtimegroup:webgroup:sessionsgroup:memorycronget_goalcreate_goalupdate_goalupdate_planskill_workshopimageimage_generatemusic_generatevideo_generate代码/文件操作型 Agent(kb-writer 默认)
messaginggroup:messagingsessions_listsessions_historysessions_sendsession_status纯消息通信型 Agent(oc-engineer 默认)
full无限制(所有工具)全功能主 Agent(main 默认)

生产实测:OpenClaw 本地部署时,新配置文件默认使用 tools.profile: "coding"(除非显式设置了其他值)。

工具组(Tool Groups)速查

Profile 中的工具通常以组的形式引用:

组名包含工具
group:runtimeexecprocesscode_execution
group:fsreadwriteeditapply_patch
group:sessionssessions_listsessions_historysessions_sendsessions_spawnsessions_yieldsubagentssession_status
group:memorymemory_searchmemory_get
group:webweb_searchx_searchweb_fetch
group:uibrowsercanvas
group:automationheartbeat_respondcrongateway
group:messagingmessage
group:nodesnodes
group:agentsagents_listget_goalcreate_goalupdate_goalupdate_planskill_workshop
group:mediaimageimage_generatemusic_generatevideo_generatetts
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"]
  }
}

这会同时拒绝 execprocesscode_execution(runtime 组)和 readwriteeditapply_patch(fs 组)。

3. tools.allow — 显式允许工具列表

tools.allow 定义白名单。当 allow 列表非空时,不在列表中的工具全部被拒绝

字段规格

属性
类型string[](字符串数组)
默认值[](空数组 = 不限制,跟随 profile)
匹配规则大小写不敏感,支持 * 通配符
⚠️ 互斥alsoAllow 不可同时设置在同一作用域

与 alsoAllow 的互斥规则

这是最容易踩的坑:allowalsoAllow 不能在同一个作用域中同时使用。

// ❌ 错误: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"
        }
      }
    ]
  }
}

这个配置的含义是:

  • 基准:messaging profile(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,但这是一个强大的功能。典型应用场景:

  1. 强模型 vs 弱模型:对 GPT-4/Claude 开放更多工具,对轻量模型限制工具
  2. 成本敏感场景:对低价模型减少工具调用,降低 token 消耗
  3. 安全分级:对不可信模型提供商限制敏感工具

6. tools.sandbox.tools — 沙箱工具策略

当 Agent 运行在 Docker 沙箱中时,tools.sandbox.tools 提供第二层工具过滤。这是独立于主工具策略的额外约束。

关键字段

字段类型说明
tools.sandbox.tools.allowstring[]沙箱内允许的额外工具
tools.sandbox.tools.denystring[]沙箱内明确拒绝的工具
tools.sandbox.tools.alsoAllowstring[]沙箱内追加允许的工具

沙箱工具策略的 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

writeapply_patch 是两个独立的工具 ID:

// ❌ 错误:只 deny write,apply_patch 仍然可用
{
  "tools": {
    "deny": ["write"]
  }
}

// ✅ 正确:同时 deny 所有写操作工具
{
  "tools": {
    "deny": ["write", "edit", "apply_patch"]
  }
}

// ✅ 更简洁:deny 整个文件系统组
{
  "tools": {
    "deny": ["group:fs"]
  }
}

最小权限实践

设计原则

  1. 从最小开始:默认使用 profile: "minimal""coding",按需追加
  2. alsoAllow 优于白名单:优先使用 alsoAllow + profile 而非全量 allow
  3. 显式拒绝敏感工具:非运维 Agent 统一 deny gateway
  4. 沙箱 + 工具策略双重保险:对高风险 Agent 同时启用沙箱和工具限制

各角色推荐配置模板

Agent 类型推荐 Profile建议 alsoAllow建议 deny
主 Agentfull按需追加gateway(可选)
代码/文件操作coding业务所需工具gateway
消息/通信messaging额外需要的工具gateway + exec
运维管理messagingexecgatewaycronprocess
只读审核minimalreadweb_fetchexecwriteeditapply_patch
图片生成codingimage_generateexecweb_fetchgateway

回滚建议

  1. 配置备份:每次修改前备份 ~/.openclaw/openclaw.json
  2. 渐进变更:一次只改一个 Agent 的配置,验证后再改下一个
  3. 使用 doctor 验证:修改后立即运行 openclaw doctor 确认权限状态
  4. 保留变更记录:在知识库中记录每次权限变更的 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 做最终拦截
  • allowalsoAllow 互斥,不可同域混用
  • deny 始终优先,每一层只能限制不能放行
  • 沙箱模式下需要额外配置 tools.sandbox.tools
  • 使用 openclaw doctoropenclaw sandbox explain 排障

掌握了这套体系,你就能为每个 Agent 精确配置"够用但不超额"的工具权限,既保障功能完整性,又遵循最小权限的安全原则。


参考来源

关联阅读

  • [[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 集成与智能体配置全记录]]