子智能体工具策略

工具策略¶

子代理首先使用与父代理或目标代理相同的配置文件和工具策略管道。之后，OpenClaw 应用子代理限制层。

当已结算的子代理在 sessions_yield 之后恢复请求方时，继续执行保留在生成时捕获的请求方策略。交接仍必须属于当前请求方会话和已结算批次，并且该批次中的每个子代理都必须携带相同的已验证请求方策略。冲突或缺失的子代理策略会使继续执行保持其普通的受限策略。当前工具限制和实时撤销检查在执行时仍然适用；交接不会授予额外工具，也不会推断发送方身份。

对于 Claude CLI 后端上请求方的自动完成轮次，保留相同的已捕获策略。工具仅通过 OpenClaw 的策略过滤 MCP 表面到达 CLI，因此原生 CLI 工具在该轮次保持禁用，并且每个继承的拒绝仍然适用。其他 CLI 后端、节点托管的 Claude CLI 会话和结算批次不会重新获得请求方工具。仅消息工具回复保留其现有的源绑定 message 授权。

子代理无论深度或角色如何，始终失去 gateway、agents_list、session_status、progress_card、cron、message、sessions_send 以及 conversations_* 工具（系统级/交互式工具、父代理拥有的进度卡片、直接交付表面，或主代理应协调的工具）。此硬拒绝层在每一轮都从持久化的子代理会话信封派生，包括已恢复和可见仪表板会话；普通 allow/alsoAllow 条目无法覆盖它。隐藏启动还会在工具构建前禁用 message，作为纵深防御。达到配置深度上限的子代理还会失去 subagents、sessions_list、sessions_history 和 sessions_spawn，因此其通信保持在公告链上。

sessions_history 在这里仍然是有界的、脱敏的回忆视图——它既不是原始转录转储，也不是仅散文渲染。

默认情况下，深度低于 5 的子代理会收到 sessions_spawn、subagents、sessions_list 和 sessions_history，以便它们可以管理其子代理。

通过配置覆盖¶

{
  agents: {
    defaults: {
      subagents: {
        maxConcurrent: 1,
      },
    },
  },
  tools: {
    subagents: {
      tools: {
        // deny wins
        deny: ["gateway", "cron"],
        // if allow is set, it becomes allow-only (deny still wins)
        // allow: ["read", "exec", "process"]
      },
    },
  },
}

tools.subagents.tools.allow 是最终的仅允许过滤器。它可以缩小已解析的工具集，但无法添加回被 tools.profile 移除的工具。例如，tools.profile: "coding" 包含 web_search/web_fetch，但不包含 browser 工具。要让 coding 配置文件的子代理使用浏览器自动化，请在 profile 阶段添加 browser：

{
  tools: {
    profile: "coding",
    alsoAllow: ["browser"],
  },
}

当只有一个代理应获得浏览器自动化时，使用按代理的 agents.entries.*.tools.alsoAllow: ["browser"]。