最新问题发现：私聊用户和群聊加载SKILL存在问题

[ailunbolinkenasi]

📝 问题描述

标题： 技能在私聊中可自动加载，但在群聊中无法自动加载（飞书渠道）

简述：
我发现 OpenClaw 在同一渠道（飞书）的不同会话类型中，Skill 加载行为存在严重不一致：

会话类型	Skill 自动加载	行为表现
私聊 (DM)	✅ 正常	Skill 自动加载，AI 可主动调用 intent-approval-workflow 等技能
群聊 (Group Chat)	❌ 异常	Skill 不会自动加载，AI 处于"空白状态"，除非显式告知加载技能

这导致：

1. 安全保护不一致 - 删除/修改操作在私聊中有保护，但在群聊中没有保护
2. 用户体验混乱 - 同一 OpenClaw 实例、同一技能配置，仅因会话类型不同而行为不同
3. 安全漏洞 - 用户可能误以为群聊和私聊有同样的安全保护

---

🔄 复现步骤

测试 1：私聊（工作正常）

# 1. 在飞书中与 OpenClaw 机器人开启私聊
# 2. 开启新对话（删除之前的会话）
# 3. 发送命令，无需任何技能声明：
"删除文件 /tmp/test.txt"
# 4. 观察：✅ intent-approval-workflow 自动触发

[AlexAnys]

你好！这个问题的根因已定位，是官方插件的访问控制层与命令授权层存在设计不一致。

根因

官方插件有两层独立的判断逻辑：

层	作用	未配置时默认值
Gate 层（是否响应消息）	控制 bot 是否处理群聊消息	open（响应所有消息）✅
Command Auth 层（是否加载 Skill）	控制 commandAuthorized 标志	allowlist 空数组 → false ❌

源码位置：handler.ts 中 configuredGroupAllowFrom IIFE——当无 groupPolicy、无 groupAllowFrom 配置时，返回空数组 []，导致 commandAuthorized = false，SDK 不加载 Skill。

结果：消息能正常收到（Gate 放行），但 Skill 不加载（Command Auth 拒绝）。私聊不受影响，因为已配对用户天然在 allowFrom 中。

解决方案

在 openclaw.json 中添加：

{
  "channels": {
    "feishu": {
      "groupPolicy": "open"
    }
  }
}

配置后 configuredGroupAllowFrom 返回 ["*"]，commandAuthorized 恢复为 true，群聊 Skill 正常加载。

局限性

• 此方案将群聊命令权限开放给所有成员，如需精细控制可改用 groupAllowFrom 配置白名单
• 此问题已在最新版本（2026.3.14）中确认仍存在，无上游修复
• 建议上游将 Gate 层和 Command Auth 层的默认行为对齐——无显式配置时，两者都应默认 open