GolemBot 多群交互架构：从私聊到公群，AI 助手如何保持一个大脑

如果 DM 消息和群消息启动的 Claude Code 进程有相同的 session ID，说明修复成功。修复后，GolemBot 使用用户 ID 作为 session key 的核心标识。如果你正在部署 GolemBot，现在就可以应用这个修复，让你的 AI 助手真正"活起来"。：GolemBot 的 Feishu 适配层在生成群消息的 session key 时，观察日志中的 session

arvin_xiaoting

176人浏览 · 2026-03-13 00:32:07

arvin_xiaoting · 2026-03-13 00:32:07 发布

GolemBot 多群交互架构：从私聊到公群，AI 助手如何保持「一个大脑」

作者：Arvin
发布日期：2026-03-13
技术栈：GolemBot + Claude Code + Feishu

引言

想象这样一个场景：

你在私聊中和 AI 助手讨论了一个复杂的技术方案，有完整的对话历史
然后你把这个 AI 助手拉进一个团队群聊
在群里，同样的 AI 助手却表现得像"新手"，完全不记得私聊中讨论过的内容

这就是传统多渠道 AI 架构的"分裂人格"问题——同一个 AI 在不同通道上像两个人一样工作。

本文将详细解析 GolemBot 如何解决这个问题，实现真正意义上的"一个大脑、多个渠道"的 AI 助手架构。

第一部分：问题根源——Session Key 的设计缺陷

1.1 传统架构中的"两个人"现象

当你部署一个 GolemBot 实例连接 Feishu 时，架构是这样的：

┌─────────────────────────────────────────────────────────┐
│                    Feishu 消息来源                        │
├──────────────┬──────────────────────────────┬───────────┤
│   私聊消息    │      群聊消息                 │  其他渠道  │
│ (P2P Chat)   │   (Group Chat)               │            │
└──────────────┴──────────────────────────────┴───────────┘
       │                 │                        │
       ▼                 ▼                        ▼
  ┌────────────────────────────────────────────────┐
  │         GolemBot 消息分发层                     │
  │  (读取消息 → 生成 Session Key → 调用 Agent)   │
  └────────────────────────────────────────────────┘
       │
       ├─ DM 消息逻辑：session key = "feishu:p2p:ou_xxx"
       └─ 群消息逻辑：session key = "feishu:group:oc_yyy"  ← 问题出在这里

问题在于：

消息来源	GolemBot 生成的 Session Key	Claude Code 进程	结果
你 DM 私聊	`feishu:p2p:ou_arvin`	Session A（记得所有历史）	✅ 连贯
你在群里发送	`feishu:group:oc_群ID`（不含用户ID！）	Session B（全新进程）	❌ 分裂

根本原因：GolemBot 的 Feishu 适配层在生成群消息的 session key 时，遗漏了用户 ID。

// 错误的实现（原始 GolemBot）
const sessionKey = msg.chatType === 'group'
    ? `${msg.channelType}:${msg.chatId}`           // ❌ 缺少 senderId
    : `${msg.channelType}:${msg.chatId}:${msg.senderId}`;  // ✅ 包含用户ID

结果：

你的 DM 消息 → session key 包含 ou_arvin → Claude Code 会话 A
你的群消息 → session key 只有 oc_群ID → Claude Code 会话 B（全新的！）

两个 session 互不相知，Claude Code 在群里就像失忆了。

1.2 为什么这个设计会出现

从 GolemBot 的架构考虑，这个设计可能出于以下假设：

隔离考虑：群聊消息不应该共享用户的私人上下文
权限考虑：群聊是公共空间，需要不同的访问控制
性能考虑：每个群用一个 session，减少 session 数量

但这些假设都忽视了一个核心需求：用户希望 AI 助手在所有渠道上是同一个"人"。

第二部分：解决方案——修复 Session Key 生成逻辑

2.1 修复的核心原则

统一使用"用户 ID"而不是"渠道+群ID"来生成 session key。

新的逻辑应该是：

// 修复后的实现（一个大脑逻辑）
const sessionKey = buildSessionKey(msg);  
// 无论 msg.chatType 是什么（'p2p' 或 'group'），都用相同的方式生成

function buildSessionKey(msg) {
    // 关键改动：始终包含 senderId（用户唯一标识）
    return `${msg.channelType}:${msg.senderId}:${msg.chatId}`;
    //       ↑ 渠道          ↑ 用户ID       ↑ 聊天ID
}

修复后的效果：

你的每一条消息（无论在 DM 还是在群里）
  ↓
GolemBot 读取消息
  ↓
生成 session key: "feishu:ou_arvin:oc_xxx"（统一的！）
  ↓
调用 Claude Code --resume feishu:ou_arvin:oc_xxx
  ↓
Claude Code 恢复同一份对话历史
  ↓
AI 助手无论在 DM 还是群里都记得你说过的话 ✅

2.2 实施步骤

第一步：定位源代码

GolemBot 的 Feishu 适配层通常在：

node_modules/golembot/dist/engines/feishu-adapter.js

第二步：修改 session key 生成逻辑

找到这段代码：

// 原始代码
const sessionKey = msg.chatType === 'group'
    ? `${msg.channelType}:${msg.chatId}`
    : buildSessionKey(msg);

改为：

// 修复后的代码
const sessionKey = buildSessionKey(msg);  // 统一逻辑

其中 buildSessionKey 确保始终包含用户 ID：

function buildSessionKey(msg) {
    return `${msg.channelType}:${msg.senderId}:${msg.chatId}`;
}

第三步：重启 GolemBot

golembot gateway restart

2.3 验证修复是否生效

在修复后，做以下测试来验证一个大脑的有效性：

方法 1：共享记忆测试（推荐）

步骤 1：在 DM 中告诉 AI 助手
  你：请记住，我的项目名叫 "ProjectX"
  AI：记住了，你的项目名是 ProjectX

步骤 2：进入群聊，问 AI 同一个问题
  你：@AI 我的项目名叫什么？
  AI：你的项目名是 ProjectX

如果 AI 在群里回答正确，说明修复成功！✅

方法 2：技术验证

查看 Claude Code 的进程列表：

ps aux | grep "claude --resume"

如果 DM 消息和群消息启动的 Claude Code 进程有相同的 session ID，说明修复成功。

方法 3：日志验证

启用 GolemBot 的 debug 日志：

DEBUG=golembot:* golembot gateway

观察日志中的 session key，应该看到相同的 key 被用于 DM 和群消息。

第三部分：多群交互——一个大脑对话多个群

3.1 多群场景的工作流程

一旦修复了单渠道问题，GolemBot 自然就支持多群交互了：

┌─────────────────────────────────────────────────────────┐
│                   Feishu 多个群                          │
├─────────────┬─────────────────────┬──────────────────────┤
│  群 A        │      群 B           │      群 C            │
│ (oc_群A)    │    (oc_群B)         │    (oc_群C)          │
└─────────────┴─────────────────────┴──────────────────────┘
      │                 │                    │
      └─────────────────┼────────────────────┘
                        ▼
            你的消息 (senderId: ou_arvin)
                        │
                        ▼
        ┌───────────────────────────────┐
        │   GolemBot Feishu 适配层       │
        │  生成 session key:             │
        │  "feishu:ou_arvin:oc_xxx"   │
        └───────────────────────────────┘
                        │
                        ▼
        ┌───────────────────────────────┐
        │   Claude Code 进程             │
        │  --resume feishu:ou_arvin:... │
        │                               │
        │  （同一个记忆库，无论消息     │
        │   来自哪个群）               │
        └───────────────────────────────┘

3.2 多群交互的实际用例

用例 1：跨群同步知识

群 A（技术讨论）：
  你：@AI 帮我解释一下 REST API 的最佳实践
  AI：[详细解释]

群 B（项目管理）：
  你：@AI 我在技术群里问过 REST API 吗？
  AI：是的，在技术讨论群里，我给你解释了 REST API 的最佳实践...

AI 能跨群回忆和关联信息。

用例 2：持续上下文

私聊：制定了一个复杂的系统设计方案（完整对话历史）

群 A：
  你：@AI 那个我们在私聊里讨论的系统设计，能帮我在群里总结一下吗？
  AI：[直接引用私聊中的方案细节，完全连贯]

无需重复解释，因为 AI 记得所有历史。

3.3 多群交互的配置建议

虽然修复了 session key 后会自动支持多群，但推荐的配置实践：

# golembot 配置文件
engine:
  type: claude-code
  
channels:
  feishu:
    # 所有 Feishu 群聊共用一个 session key 策略
    sessionKeyStrategy: "user-centric"  # 基于用户ID，而不是渠道
    
    # 可选：针对特定群组的覆盖配置
    groups:
      - chatId: "oc_群A"
        name: "技术讨论"
        sessionShareEnabled: true  # 与其他群共享 session
      - chatId: "oc_群B"
        name: "项目管理"
        sessionShareEnabled: true

第四部分：架构深度分析

4.1 Session Key 的设计权衡

修复后，GolemBot 使用用户 ID 作为 session key 的核心标识。但这引出了新问题：

问题：是否存在隐私泄露风险？

答案：No，原因如下

群聊隔离：虽然 session key 相同，但 Claude Code 进程本身是无状态的
- 记忆存储在文件系统上（~/.openclaw/memory/）
- 文件系统级的权限控制
- 群 A 的用户无法直接访问群 B 的用户消息

上下文隔离：AI 的回复基于上下文窗口，不是基于 session key

群 A：AI 可以看到群 A 的消息历史
群 B：AI 可以看到群 B 的消息历史
⚠️ 但 AI 可以"记得"私聊中的内容（这是特性，不是 bug）

显式权限：用户可以配置 GolemBot 对不同群的访问权限

// 示例：只在群 A 中引用私聊内容
if (msg.chatId === 'oc_群A') {
    // 可以访问用户的私聊历史
    const dmHistory = getUserMemory('ou_arvin');
} else {
    // 群 B 中只能看到群内消息
    const groupHistory = getChatMemory('oc_群B');
}

4.2 Session Key 的可扩展性

随着用户量和群组数增加，该架构的性能考虑：

Session 数量计算

Old（按群计算）：
  1 个用户 × 10 个群 = 10 个 session

New（按用户计算）：
  1 个用户 = 1 个 session

优势：

Session 数大幅减少
Claude Code 进程复用，内存占用降低
同一用户的所有对话共享一个历史加载周期

考虑：

如果一个用户加入 100 个群，所有群共享 1 个 session
需要在 GolemBot 中添加"当前上下文"过滤器，确保 AI 不会混淆不同群的内容

第五部分：高级话题——多 Bot 协作

5.1 Bot 之间的通信通道

在多 bot 架构中（如 OpenClaw + GolemBot），bots 之间需要通信。GolemBot 提供了 HTTP API：

# GolemBot 在 localhost:3000 提供 HTTP 服务
POST http://127.0.0.1:3000/chat

请求体：
{
  "message": "你的问题",
  "sessionId": "可选，用于恢复历史对话"
}

响应：
Server-Sent Events (SSE) 流

Bot A 主动联系 Bot B 的例子：

# Bot A 想问 Bot B 一个问题
curl -X POST http://127.0.0.1:3000/chat \
  -H "Content-Type: application/json" \
  -d '{
    "message": "帮我分析一下这个数据",
    "sessionId": "bot-a-session-123"
  }'

这就是多 bot 协作的基础——HTTP 接口 + Session ID。

5.2 OpenClaw 与 GolemBot 的协作模式

在实际部署中，可能有这样的拓扑：

┌────────────────────────────────────────┐
│           Feishu（飞书）                │
│  DM          群 A          群 B         │
└─────┬─────────────┬──────────┬─────────┘
      │             │          │
      ▼             ▼          ▼
┌────────────────────────────────────────┐
│    OpenClaw Gateway（中央消息总线）    │
│  - 路由消息                            │
│  - 权限控制                            │
│  - 日志记录                            │
└────────────────────────────────────────┘
      │
      ├─────────────────────┬──────────────────┐
      ▼                     ▼                  ▼
  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
  │ GolemBot     │  │ OpenClaw     │  │  其他服务    │
  │ (Feishu)     │  │ Agent        │  │              │
  │ Port 3000    │  │ Port 3001    │  │              │
  └──────────────┘  └──────────────┘  └──────────────┘

通信流程：

用户在 Feishu 群聊发送消息
OpenClaw Gateway 接收并分发
可以路由到 GolemBot（处理 IM 集成）或其他服务
如果需要跨 bot 协作，通过 HTTP API 通信

第六部分：部署最佳实践

6.1 完整部署清单

## 部署前检查清单

### 1. 代码修改
- [ ] 修改 GolemBot 的 Feishu 适配层
  - 位置：node_modules/golembot/dist/engines/feishu-adapter.js
  - 改动：统一使用 buildSessionKey(msg)
  
### 2. 配置调整
- [ ] 创建 golembot 配置文件
- [ ] 设置 sessionKeyStrategy: "user-centric"
- [ ] 配置 Feishu 群组权限

### 3. 文件系统准备
- [ ] 确保 ~/.openclaw/memory/ 目录可写
- [ ] 确保足够的磁盘空间（session 和历史记录）
- [ ] 配置文件备份

### 4. 测试
- [ ] 单渠道测试（DM）
- [ ] 单群测试（一个群）
- [ ] 多群测试（多个群）
- [ ] 跨渠道记忆测试

### 5. 监控
- [ ] 启用日志
- [ ] 监控进程 session 数量
- [ ] 监控内存占用
- [ ] 设置告警规则

6.2 性能调优

# 1. 限制并发 session 数
GolemBot 配置：
max_concurrent_sessions: 100

# 2. 设置 session 过期策略
session_ttl: 3600  # 1小时无操作后过期

# 3. 启用消息缓存
cache_enabled: true
cache_size_mb: 512

# 4. 定期清理老旧会话
cleanup_interval_hours: 24

6.3 故障排查

问题 1：AI 在群里仍然表现得像"新手"

# 检查 session key 是否包含用户 ID
DEBUG=golembot:* golembot gateway 2>&1 | grep "sessionKey"

# 应该看到：
# sessionKey: feishu:ou_arvin:oc_群ID （正确）
# 而不是：
# sessionKey: feishu:oc_群ID （错误）

问题 2：多群混淆（一个群的内容出现在另一个群）

# 检查上下文隔离过滤是否启用
# 确保 GolemBot 的消息路由规则正确

# 验证每个群是否只接收自己的消息：
golembot debug channels

问题 3：Session 不释放，内存持续增长

# 启用 session 过期机制
# 在 GolemBot 配置中设置 session_ttl

# 手动清理：
golembot session cleanup --older-than 24h

第七部分：真实案例——OpenClaw + GolemBot 多群架构

案例背景

一个开发团队使用飞书，有多个工作群：

技术讨论群：讨论架构和代码
项目管理群：跟踪任务进度
知识沉淀群：保存经验和最佳实践
私聊：个人与 AI 的深度对话

修复前（问题现象）

私聊：
  用户：分析一下我们的系统架构，有什么改进空间？
  Claude Code：[详细分析，2000+ 词]

一天后，在技术讨论群：
  用户：@AI 还记得我们私聊里讨论的架构改进方案吗？
  Claude Code：对不起，我不记得我们讨论过什么。你能重新描述一下吗？
  
  ❌ 用户失望：为什么要重新描述，你应该记得！

修复后（预期效果）

私聊：
  用户：分析一下我们的系统架构，有什么改进空间？
  Claude Code：[详细分析，2000+ 词]

一天后，在技术讨论群：
  用户：@AI 还记得我们私聊里讨论的架构改进方案吗？
  Claude Code：当然记得。基于我们之前的讨论，系统架构的改进方案包括：
    1. 模块化重构...
    2. 缓存策略优化...
    3. 异步处理改进...
  
  ✅ 用户满意：完全连贯，省去了重复工作！