会话管理
OpenClaw 通过 DM 配对、白名单和群组规则三层机制识别用户身份，并在 Session 层面隔离不同来源的上下文，确保隐私安全与数据独立。
身份认证
DM Pairing Policy（默认认证策略）
当一个未知用户首次通过私聊（DM）联系 Agent 时，OpenClaw 会启动一次性配对流程：
未知用户发送私聊消息
│
▼
┌─────────────────────────────┐
│ 1. Agent 回复一次性配对码 │
│ （6位数字，如 482917） │
└────────┬────────────────────┘
│
▼
┌─────────────────────────────┐
│ 2. 消息不被处理 │
│ Agent 进入等待状态 │
└────────┬────────────────────┘
│
▼
┌─────────────────────────────┐
│ 3. 主人在已配对渠道中 │
│ 输入配对码批准 │
│ 或直接拒绝 │
└─────────────────────────────┘安全设计
配对码是一次性的，每次新用户请求都会生成不同的码。主人必须在已经配对的渠道中确认，确保只有授权用户才能与 Agent 建立会话。
白名单机制（allowFrom）
对于已知的可信用户，可以在 AGENTS.md 中预先配置白名单，跳过配对流程直接授权：
allowFrom:
- telegram:123456789
- whatsapp:+8613800138000
- discord:user#1234格式说明
白名单条目的格式为 平台:用户标识，支持所有已接入的消息渠道。用户标识需要使用对应平台的唯一 ID（而非显示名称）。
群组规则（requireMention）
在群组场景中，Agent 默认只响应 @Agent名称 的消息，避免对无关对话产生干扰。
| 模式 | 行为 | 适用场景 |
|---|---|---|
mention（默认） | 仅响应 @提及 的消息 | 多人群组，减少噪音 |
always | 响应群内所有消息 | 小型专属群组，Agent 全程参与 |
切换命令：
/activation mention # 仅响应 @提及（默认）
/activation always # 响应所有消息注意
在活跃的大群中启用 always 模式会导致 Agent 对每条消息都作出响应，可能产生大量回复和 token 消耗。建议仅在小型、专属群组中使用。
Session 隔离
不同场景下，Session 的创建和隔离策略有所不同：
| 场景 | Session 行为 | MEMORY.md | 说明 |
|---|---|---|---|
| 私聊（DM） | 所有已配对的私聊折叠到共享的 main session | 加载 | 无论来自哪个渠道的私聊，都共享同一上下文 |
| 群组 | 每个群组默认使用独立的隔离 session | 不加载 | 群组对话与私聊完全隔离，保护隐私 |
| 跨渠道 | 同一用户在 Telegram 和 WhatsApp 的私聊共享 main session | 加载 | 已配对用户的身份跨渠道统一 |
核心概念：Main Session
Main Session 是用户与 Agent 之间最核心的会话。它：
- 汇聚所有私聊渠道的对话
- 加载
MEMORY.md长期记忆 - 加载
USER.md用户信息 - 是唯一会触发 Pre-Compaction 记忆保存的 session 类型
隔离示意
用户 Alice
├── Telegram DM ──┐
├── WhatsApp DM ──┼──→ Main Session（共享上下文，加载 MEMORY.md）
├── Discord DM ───┘
├── 群组 A ───────────→ Group Session A（隔离，不加载 MEMORY.md）
└── 群组 B ───────────→ Group Session B（隔离，不加载 MEMORY.md）会话生命周期
用户发送消息
│
▼
身份认证（配对/白名单/群组规则）
│
▼
查找或创建 Session
│
▼
加载上下文（历史消息 + 记忆层）
│
▼
Agent 处理并回复
│
▼
更新 Session 记录 → 写入 sessions.json会话持久化
所有会话数据存储在工作区的 sessions.json 文件中，网关重启后自动恢复。
workspace/
└── sessions.json ← 会话状态持久化Context 压缩机制
OpenClaw 会自动压缩 context（删除旧的对话和工具结果），保持 context 在合理大小。这不是 bug，是正常机制——context 窗口有限，对话太长就会自动压缩。
什么时候触发
- Context 超过一定大小（如 150K tokens）时自动触发
- 自动触发，不需要手动操作
压缩时会删除什么
- 旧的对话记录
- 旧的工具调用结果
压缩时会保留什么
- 系统提示、AGENTS.md、MEMORY.md、SHARED.md 等核心文件
- 最近的对话消息
如何应对
重要任务状态不要只存在 context 中。有两种解决方案：
- 计划文件模式 — 用文件持久化任务状态（见下一节）
- Hook 自动保存 — 用
session:compact:before/after事件自动保存和恢复关键信息（详见 Hooks 钩子）
计划文件模式
当任务复杂（预计 >30 tool calls 或跨 session）时，应启用计划文件模式，将任务状态持久化到文件中。
使用流程
1. 收到复杂任务（>30 tool calls 或 >10 分钟）
│
2. 先写计划文件到 temp/任务名-plan.md
│
3. 每完成一步，更新计划文件（打勾 [x]）
│
4. Context 压缩时，计划文件保留
│
5. 新 session 开始时，读取计划文件继续
│
6. 任务完成后，删除计划文件或移到 archive/计划文件模板
# [任务名] 执行计划
创建时间：2026-03-12 10:30
## 目标
[一句话描述最终交付物]
## 步骤
- [ ] Phase 1: 调研现有工具
- [ ] Phase 2: 测试各工具优缺点
- [ ] Phase 3: 建立决策树
- [ ] Phase 4: 写入 SHARED.md
- [ ] Phase 5: 广播通知
## 当前进度
正在执行：Phase 2
已完成：Phase 1
## 遇到的问题
- Agent Reach 需要 Python 3.10+，系统是 3.9
- 解决：用 uv 安装
## 下一步
- 测试 Agent Reach 的 B站功能
- 记录特殊情况好处
- Heartbeat 检查时能发现进行中的任务
- 可以主动汇报进度
- 用户随时知道 Agent 在做什么
- 跨 session 不丢状态
重置会话
用户可以通过以下命令管理会话：
/reset # 清除当前会话的历史消息，开启新对话
/clear # 同 /reset重置不会清除长期记忆
/reset 只清除当前 Session 的对话历史。MEMORY.md 中的长期记忆和 memory/ 目录下的 Daily Log 不受影响，它们是独立的持久化存储。