机器人循环保护

OpenClaw 可以在支持 allowBots 的渠道上接受由其他机器人发送的消息。Discord 和 Slack 默认在常规提及和访问规则下接受它们；显式设置 allowBots: false 仍会禁用由机器人触发的轮次。机器人消息可以独立于轮次准入而作为对话上下文保持可见。

配对循环防护限制两个机器人身份之间的快速交换。它是一种滑动窗口速率防护，因此低于预算的较慢交换可以继续。

该防护由核心入站回复运行器执行。每个支持的渠道将其入站事件映射为通用事实：账户或作用域、会话 ID、发送方机器人 ID 和接收方机器人 ID。核心在两个方向上跟踪参与者配对（A 到 B 和 B 到 A 视为同一配对），应用滑动窗口预算，并在预算超出后的冷却期间抑制该配对。

默认值¶

只要渠道允许机器人发送的消息到达分发，配对循环防护就会处于活动状态。内置默认值：

该防护不影响人类发送的消息、单机器人部署、自消息过滤，或未超出预算的机器人回复。

配置共享默认值¶

只需设置一次 channels.defaults.botLoopProtection，即可为所有支持的渠道提供相同的基线。渠道也可能暴露更细粒度的覆盖项；Feishu 有意仅使用此共享基线。

{
  channels: {
    defaults: {
      botLoopProtection: {
        maxEventsPerWindow: 20,
        windowSeconds: 60,
        cooldownSeconds: 60,
      },
    },
  },
}

仅当你的渠道策略有意允许机器人之间的对话且不进行自动抑制时，才设置 enabled: false。

按渠道、账户或房间覆盖¶

支持的渠道会在共享默认值之上逐键叠加其自身配置。优先级，从最窄范围开始：

1. channels.<channel>.<room-or-space>.botLoopProtection，当渠道支持按会话覆盖时
2. channels.<channel>.accounts.<account>.botLoopProtection，当渠道支持账户时
3. channels.<channel>.botLoopProtection，当渠道支持顶层默认值时
4. channels.defaults.botLoopProtection
5. 内置默认值

{
  channels: {
    defaults: {
      botLoopProtection: {
        maxEventsPerWindow: 20,
      },
    },
    discord: {
      botLoopProtection: {
        maxEventsPerWindow: 8,
      },
      accounts: {
        secondary: {
          allowBots: true,
          botLoopProtection: {
            maxEventsPerWindow: 5,
            cooldownSeconds: 90,
          },
        },
      },
    },
    googlechat: {
      allowBots: true,
      groups: {
        "spaces/AAAA": {
          botLoopProtection: {
            maxEventsPerWindow: 5,
          },
        },
      },
    },
    matrix: {
      allowBots: "mentions",
      groups: {
        "!roomid:example.org": {
          botLoopProtection: {
            maxEventsPerWindow: 5,
          },
        },
      },
    },
    slack: {
      allowBots: "mentions",
      botLoopProtection: {
        maxEventsPerWindow: 8,
      },
    },
  },
}

渠道支持¶

• Discord：原生 author.bot 事实，以 Discord 账户、渠道和机器人配对为键。
• Feishu：针对已准入的机器人发送的群消息，使用原生 sender_type=bot 事实，以 Feishu 账户、聊天和机器人配对为键。Feishu 仅使用 channels.defaults.botLoopProtection。
• Google Chat：针对已接受的机器人发送消息，使用原生 sender.type=BOT 事实，以账户、空间和机器人配对为键。
• Matrix：已配置的 Matrix 机器人账户，以 Matrix 账户、房间和已配置的机器人配对为键。
• Slack：针对已接受的机器人发送消息，使用原生 bot_id 事实，以 Slack 账户、渠道和机器人配对为键。

未暴露可靠入站机器人身份的渠道应继续使用其常规的自消息和访问策略过滤器。在能够识别机器人配对中的双方参与者之前，它们不应启用此防护。

有关插件实现细节，请参阅 SDK 运行时。

内部智能体群组轮次¶

智能体群组线程 为共享同一条入站消息的参与者使用单独的协调器预算。符合条件的 broadcast 条目最多允许 4 轮和 32 个参与者轮次。maxRounds 包含初始轮次；maxTurns 统计已启动的智能体运行次数，并在并行启动前预留槽位。任何参与者通过、任一限制或取消都会停止后续轮次。

一个参与者轮次可能通过分块、预览或消息工具发送产生多条物理消息。协调器不会统计这些消息。其内存中的预算范围限定于渠道、账户、会话、线程和根消息，并且在 Gateway 重启后无法恢复。

内部延续具有不同的身份，因此常规入站去重不会抑制它们。它们不会更改传输配对防护的阈值，也不会替代渠道的机器人准入和自消息策略。对于从平台到达的机器人发送消息，请保持这些防护启用。