同一工具如何按场景控制权限，OpenClaw 的工具策略管道如何分层？

核心回答

同一工具的权限应由可信的身份和场景决定：先限制这次任务允许使用哪些工具，再在执行时检查具体参数、资源和调用者权限。 模型可以提出调用，但不能通过填写“我是管理员”给自己授权。

OpenClaw 把工具策略分成基础工具集、全局与 Agent 配置、渠道会话与发送者、沙箱与子 Agent 等层，逐层过滤候选工具。普通策略中 deny 优先，各层允许范围共同约束结果；后层写了 allow，不会恢复前层已经移除的工具。owner 权限还会作用于当轮执行，模型看见工具定义，不等于本轮能够调用。

例如，本地开发者可以用 exec 调试，群聊助手则可通过群组策略禁止 exec、process 以及文件修改工具。这里解决的是工具准入；命令在哪运行、能写哪些目录，以及业务接口能操作哪个对象，仍分别由执行环境和具体工具检查。

工具策略管道怎样分层？

固定版本的 buildDefaultToolPolicyPipelineSteps() 按以下顺序使用已经解析好的策略：

1. 基础工具集：profilePolicy、providerProfilePolicy，分别对应通用和模型供应方的工具 profile。
2. 全局与 Agent：globalPolicy、globalProviderPolicy、agentPolicy、agentProviderPolicy。
3. 当前会话与发送者：groupPolicy、senderPolicy。同一个 Agent 在不同群组、不同发送者的请求下，可以得到不同工具范围。

会话管道随后追加 sandboxPolicy、subagentPolicy、按需要纳入的 runtimeToolPolicy，以及 inheritedToolPolicy。未配置的层跳过；已配置的层继续收窄当前候选。沙箱层只在相应沙箱场景生效，子 Agent 层与继承限制也不是每次普通聊天都凭空产生。默认层次、会话附加层。

applyToolPolicyPipeline() 保存当前工具数组，每经过一层，就对上层结果执行 filterToolsByPolicy()。匹配器先检查拒绝规则，再检查允许规则，支持工具组和通配模式。alsoAllow 是向相应层已有允许集合补充条目，不是跨层的授权通行证。逐层过滤、名称匹配。

渠道、插件与子 Agent 各影响什么？

渠道策略约束请求所处的对话。 群组、账号与发送者信息应由宿主解析，不能信任模型自报的身份。当前实现通过请求者策略解析群组和发送者范围；子 Agent 还会携带持久化的继承限制，不能换一个会话就丢掉来源约束。请求者策略解析。

插件扩展工具来源，不自动扩大权限。 管道按插件元数据把插件 ID、group:plugins 展开成具体工具名，再应用策略。已加载插件的工具仍可能被全局、发送者或沙箱层排除；配置了 MCP 服务，也不代表当前沙箱会话可以调用它。插件工具组展开。

子 Agent 另受子任务限制与继承范围约束。 例如控制平面、直接跨会话投递等工具存在额外限制。显式的跨 Agent 工具委派是运维配置授予的能力，不能由模型在 sessions_spawn 参数里自行声明；普通 allow 也不能消除其它来源的拒绝。子 Agent 工具策略。

owner 权限为什么不能只靠隐藏工具？

这个版本会区分提供给模型的工具定义与当轮真正可调用的工具。resolveTurnToolSurface() 对未获 owner 权限或超出当轮请求者权限的工具，保留定义并包装执行入口；调用会被拒绝，同时从本轮 callableTools 和后代继承的 exportedTools 中排除。这既保持会话工具前缀稳定，也避免把“定义仍在”当成有效授权。具体工具仍可以拥有动作级和对象级检查。当轮工具权限处理。

工具策略能保证什么，不能替代什么？

工具策略回答“允许调用哪个工具”，沙箱回答“工具在哪里运行、能接触什么”。允许 exec 后，即使拒绝 write、edit，命令仍可能修改文件，因此不能据此宣称整个 Agent 只读。elevated 也不增加工具集合，不能绕过已经拒绝的 exec。

对同一个被允许的工具，执行层仍应依据真实身份检查目标、参数和当前状态。例如允许调用发消息工具，不等于可以向任意群组投递；允许执行命令，也不等于获得所有主机或目录的访问权。实际系统需要把工具准入、具体动作授权与执行隔离分别落实。沙箱、工具策略与 elevated 的区别。