夜雨聆风这是「OpenClaw 教程课程」第 6 课。 从这一课开始，我们正式进入第二模块：核心概念。
图：Session 不是普通聊天记录，而是 OpenClaw 组织上下文、隔离对话和维持连续性的关键结构。
前面几课里，你其实已经不断碰到一个词了：
/new上下文延续 会话切换 群聊隔离 私聊连续性
这些东西背后，都指向同一个核心概念：
Session。
很多新手刚开始用 OpenClaw 时，会把它理解成：
我说一句 它回一句 然后下一句继续接着聊
这个理解只停留在表面。
因为在 OpenClaw 里，真正被系统管理的不是“聊天气氛”，而是：
一条消息到底进入哪个 Session。
而这件事，会直接决定：
它记不记得你前面说过什么 这次对话和别人的对话会不会串 群里和私聊是不是互相影响 cron、webhook、不同入口的上下文是不是隔离
所以今天这课要解决的问题非常核心：
Session 是什么？它和普通聊天到底有什么本质区别？
一、先说结论：Session 不是“聊天记录”，而是“上下文容器”
这是这一课最重要的一句话。
很多人第一反应会把 Session 理解成：
一段聊天历史
这不能说错，但不够准确。
更准确的理解应该是：
Session 是 OpenClaw 用来承载一段上下文、维护连续性、隔离不同对话来源的运行容器。
也就是说，它不只是“记住你说过的话”，而是在告诉系统：
这条消息属于哪段持续中的对话 这一段对话应该复用哪些上下文 它是不是该和别的消息来源隔开
所以你以后不要再把 Session 理解成单纯的“聊天历史”。
它更像是：
一个上下文房间 一个对话容器 一个运行中的语境盒子
二、为什么 OpenClaw 必须有 Session？
如果没有 Session，OpenClaw 很快就会变得混乱。
你可以想象一种没有 Session 的状态：
你上午在 Telegram 私聊里问它写作问题 下午别人也在 Discord 里问它另外一件事 晚上群里又有人让它总结会议 第二天还有 cron 定时任务推来一条系统消息
如果这些东西全混在一起，会发生什么？
上下文乱掉 回答串台 隐私混乱 任务边界不清晰
所以 Session 的本质意义就是：
给不同来源、不同场景、不同持续状态的对话划清边界。
没有这层隔离，你就几乎不可能把 OpenClaw 稳定地用于真实场景。
三、普通聊天和 Session 的区别到底在哪？
这是最关键的认知切换。
普通聊天的直觉理解
很多人天然会觉得：
对话就是连续的 只要模型记得上一句就行
这是“聊天产品视角”。
Session 的系统视角
而在 OpenClaw 里，系统真正关心的是：
这条消息来自哪里？ 它该进入哪个上下文桶？ 这个上下文是否应该和别的来源共享？ 什么时候该重置？
也就是说：
普通聊天看见的是“连续交流”，Session 看见的是“上下文归属”。
这两者不是一个层面的东西。
四、OpenClaw 是怎么根据来源路由 Session 的？
根据当前文档，OpenClaw 会按消息来源来决定 Session 归属。
一个最基本的理解表可以先记住：
这张表特别重要，因为它说明了一件事：
OpenClaw 不是“所有消息都放在同一条聊天记录里”，而是根据来源自动决定隔离方式。
这就是它和普通聊天产品非常不同的地方。
图：不同来源的消息会被路由到不同的 Session 容器中，而不是天然混成一个对话池。
五、为什么“所有私聊默认共用一个 Session”这件事要特别小心？
当前文档里有一个很重要的默认行为：
Direct messages（私聊）默认共享一个 Session。
这在单人使用时通常没问题。
比如你自己在 Telegram 私聊 bot，那它一直延续你的上下文，反而是你想要的体验。
但如果出现多用户都能私聊你的 Agent，就会出大问题。
文档里明确提醒了一个风险：
如果多个不同的人都能私聊这个 Agent，而你没有做 DM isolation，那么他们可能会共享同一个对话上下文。
这意味着什么？
简单说就是：
Alice 私聊说的话 可能间接进入 Bob 的上下文语境
这在真实使用里当然是不能接受的。
所以你以后只要一想到“多人能私聊这个 Agent”，就必须立刻想到：
DM isolation 要不要开？
六、dmScope 是干什么的？
这就是 OpenClaw 为了解决私聊隔离问题给出的关键配置。
当前文档里最推荐你先记住的是：
{ session: { dmScope: "per-channel-peer" }}它的意义是：
按渠道 + 发送者维度隔离私聊 Session。
你可以把它理解成：
不同人私聊我，不共用上下文 同一个人从不同渠道来，也可以分开处理
文档里给出的几个主要选项是：
main
默认值。
所有私聊共享一个 Session
per-peer
按发送者隔离 跨渠道复用同一人的上下文
per-channel-peer
按渠道 + 发送者隔离 是更推荐的通用做法
per-account-channel-peer
按账户 + 渠道 + 发送者进一步隔离 更适合多账户场景
对于大多数真实使用，尤其是多人环境，先记住一句话就够了：
如果不止你一个人能私聊它，优先考虑
per-channel-peer。
七、Session 为什么会“延续”？
因为 Session 的设计目的之一，就是保持连续性。
也就是说，在同一个 Session 里，OpenClaw 会默认把之前的对话看作这次对话的上下文组成部分。
这就是为什么你会看到这种现象：
你前面讲过一件事 过一会儿再继续问 它还能接得上
这不是“它突然很聪明”，而是因为：
你还在同一个 Session 里。
所以你以后再遇到“它为什么还记得刚才的话”，不要只说“上下文还在”。
更准确的说法是：
当前消息仍然进入了同一个 Session。
八、那 /new 到底在做什么？
这个命令你前面已经见过了。
/new很多人知道它能“开新对话”，但不知道它本质上在干嘛。
它本质上做的是：
让你当前的后续交互，不再继续复用原来的 Session，而是进入一个新的会话上下文。
所以 /new 的意义不是简单的“清屏”，而是：
结束旧的上下文延续 开始一段新的上下文容器
这就是为什么你有时候会觉得：
之前它一直带着某个话题跑 /new之后，世界突然清净了
因为旧 Session 的语境不再继续影响新一轮交互了。
九、Session 会一直存在吗？不会
Session 不是永远不变的。
根据当前文档，它通常会以几种方式结束或切换：
1）日常重置（daily reset）
默认情况下，OpenClaw 会在网关主机的本地时间 每天凌晨 4:00 开新 Session。
这意味着：
并不是一段对话永远无限延续 系统会定期切断旧上下文
2）空闲重置（idle reset）
如果你配置了 session.reset.idleMinutes，那在一段时间没活动后，也会进入新 Session。
3）手动重置
也就是你主动发：
/new或者：
/reset所以 Session 是“可延续的”，但不是“永久无限延续的”。
十、Session 状态存在哪里？
这一点也很重要。
当前文档里很明确：
所有 Session 状态都归 Gateway 持有。
也就是说，不是前端页面自己记住，不是 Telegram 自己记住，也不是某个客户端单独记住。
而是 Gateway 统一管理。
文档里给出了两个很关键的位置：
Session store
~/.openclaw/agents/<agentId>/sessions/sessions.json对话转录文件（transcripts）
~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl这个信息很有用，因为它告诉你：
Session 不是抽象概念 它在系统里是有真实存储结构的
十一、为什么理解 Session 以后，很多现象 suddenly 就解释通了？
因为很多你之前觉得“玄学”的现象，本质上都是 Session 行为。
例如：
现象 1：它为什么还记得我上次说的话？
因为还在同一个 Session 里。
现象 2：为什么群里和私聊像两套脑子？
因为它们本来就是不同 Session。
现象 3：为什么 /new 一下，刚才的话题就不继续了？
因为你切换到了新 Session。
现象 4：为什么多人场景下要强调隔离？
因为 Session 决定了上下文边界，如果不隔离，内容就可能串。
所以这节课真正值钱的地方，不只是学了一个名词，而是：
你终于知道 OpenClaw 是怎么管理“对话边界”的。
十二、你现在最该记住的 Session 观念
如果你只记一句话，记这句：
Session 决定的不是聊天有没有历史，而是这条消息属于哪段上下文。
这个理解一旦建立起来，后面你学这些内容就会顺很多：
Agent Loop Memory 多渠道路由 Cron Webhook Multi-agent
因为它们最终都会碰到同一个问题：
这条输入应该落到哪个 Session 里？
十三、总结
今天这节课，你只要真正记住下面 5 句话，就够了：
Session 不是普通聊天记录，而是上下文容器。 OpenClaw 会根据消息来源，把消息路由到不同 Session。 私聊默认共享 Session，但多人场景下这很危险。 dmScope是解决私聊隔离问题的关键配置。/new的本质不是清屏，而是开启一个新的上下文会话。
下一课预告
下一课我们会学：
第 7 课：Agent Loop 解析——每条消息是怎么被处理的
也就是把今天你已经摸到边的那个问题再往前推一步：
一条消息进入 Session 后 Gateway 和 Agent 是怎么协同工作的 工具调用是在哪个阶段发生的
🦞 本文由八条撰写，持续更新中。
