想象一个场景：你正在和你的 OpenClaw 聊代码审查，它帮你分析了几个 PR 的问题，上下文很到位。然后你切换到另一个话题——规划下周的旅行路线。AI 的回答里，突然开始引用刚才 PR 里的代码片段来建议你带什么行李。

这不是 AI 变蠢了，而是它的上下文被污染了。

如果你在使用 OpenClaw 的飞书 Bot，你可能也遇到过类似的问题。明明想聊不同的话题，结果 AI 的回复总是带着上一个话题的残影。

这背后有一个被大多数人忽略的关键问题：大语言模型的输出质量，严重依赖于上下文的纯粹程度。

LLM 的注意力，比你想象的更脆弱

我们都知道 LLM 有 “上下文窗口”（context window）这个限制。但大多数人只关心窗口的大小——1M tokens 够不够大？128K 够不够？

但一个被严重低估的问题是：上下文窗口里装的内容质量，比窗口大小更重要。

LLM 的注意力机制决定了，模型并不是均匀地 “读完” 所有上下文，而是在上下文中寻找相关信号。当你的上下文中混杂了三个不同主题的对话，模型的注意力会被分散到不相关的内容上。它需要花一部分 “认知资源” 去分辨哪些内容是和当前问题相关的，哪些不是。

这就是为什么：同样一个 128K 的上下文窗口，装着 10 条集中的代码讨论，和一个装着”代码+旅行+育儿+股票”混杂的 128K 上下文，输出的质量天差地别。

更小的、聚焦的上下文，几乎总是产生更好的结果。

OpenClaw 的上下文管理机制

OpenClaw 的工作方式是：一个 Channel（比如一个飞书 Bot 的聊天窗口）中的所有聊天内容，会作为上下文发送给 LLM。

这意味着，如果你用同一个飞书 Bot 既聊代码、又聊写作、又聊投资，那么这些话题的对话历史会累积在同一个会话（session）里。当你开始一个新话题时，旧话题的对话仍然占据着上下文窗口。

OpenClaw 当然有 session 管理机制——你可以通过 /reset 手动重置、或者设置每日/空闲自动重置。但这些方案都比较粗暴：要么手动操作麻烦，要么干脆一刀切丢掉了所有上下文。

有没有更优雅的方式？

隔离的两种粒度：Agent vs Session

在 OpenClaw 的架构中，隔离有两种粒度：

1. Agent 级别的隔离

每个 Agent 拥有独立的：

工作空间（workspace）

会话存储（session store）

身份配置文件（SOUL.md、USER.md、MEMORY.md）

工具权限

Agent 级别的隔离是最彻底的。两个 Agent 之间完全看不到对方的任何数据。

但反过来，对于个人用户来说，Agent 级别的隔离可能又太重了。因为一旦拆成多个 Agent，你的身份配置、记忆文件、知识库也会被隔离，无法共享。你用一个 Agent 学到的知识，另一个 Agent 不知道。而且管理多个 Agent 的配置也额外增加了运维成本。

2. Session 级别的隔离

Session 级别的隔离，隔离的是对话历史本身，但保留了 Agent 级别的共享（workspace、记忆文件、工具权限等都在一个 Agent 下）。

对于日常个人使用来说，Session 粒度的隔离更适合：不同的主题有不同的对话上下文，但你的身份、知识库、工具配置是共享的。

方案：同一个 Agent，多个飞书 Bot

如果你也在使用飞书 Bot 作为 OpenClaw 的 Channel，一个比较优雅的方案是：为同一个 Agent 配置多个飞书 Bot，不同的 Bot 之间实现聊天上下文的隔离。

这听起来是不是有点矛盾？多个 Bot 分别聊不同的话题，但用的是同一个 Agent 的 workspace？

其实这正是 OpenClaw 多账号机制的精妙之处。

配置方式

你需要在 openclaw.json 中配置飞书 Channel 的多账号：

{  channels: {    feishu: {      accounts: {        default: {          appId: "cli_xxx",          appSecret: "xxx",          name: "代码助手",        },        writing: {          appId: "cli_yyy",          appSecret: "yyy",          name: "写作助手",        },        reading: {          appId: "cli_zzz",          appSecret: "zzz",          name: "阅读助手",        },      },    },  },}

每个 account 对应一个飞书自建应用（即一个独立的飞书 Bot）。你的用户也可以在飞书中找到这些 Bot 并分别和它们对话。

Key point：这些 Bot 都属于同一个 Agent，共享同一份 workspace、SOUL.md、记忆和工具配置。

隔离是怎么实现的？

关键配置在 session 管理上：

{  session: {    dmScope: "per-account-channel-peer",  },}

当 dmScope 设置为 per-account-channel-peer 时，OpenClaw 会为每个（account + channel + sender）组合创建一个独立的会话。也就是说：

你和代码助手 Bot聊的内容 → 一个独立的 session

你和写作助手 Bot聊的内容 → 另一个独立的 session

你和阅读助手 Bot聊的内容 → 又一个独立的 session

这些 session 之间完全隔离，彼此不知道对方的存在。你在代码 Bot 里聊的 PR review 不会被带到写作 Bot 里。

这种方案的好处

你甚至可以根据不同 Bot 的场景，给它们设置不同的名字和头像，让用户对 Bot 的”角色”有一个直觉认知，从而形成自然的分工习惯。

对比多 Agent 方案

对于大多数个人用户来说，多 Bot Session 隔离是性价比最高的方案——既解决了上下文污染的问题，又不需要引入额外的工作量。

举一个实际案例

我现在就在这样用：

Bot A（default）

→ 工作日常、代码讨论、日程管理、日志记录

Bot B（kimi）

→ 学习阅读、知识收集、笔记整理

使用了一周后，最直观的感受是：两个 Bot 的回复边界清晰了很多。聊技术话题时，Bot A 不会突然引用阅读笔记里的内容。聊整理笔记时，Bot B 也不会突然冒出来一句”你的代码审核还没看完”。

上下文窗口的利用率明显更高了——因为不再需要在一个 session 里塞五个话题的对话历史。

一些补充的注意事项

飞书创建多个 Bot 是免费的。

每个 Bot 对应一个飞书自建应用，在飞书开放平台创建并配置即可

每个 Bot 需要的权限相同。

如果你已经配好了一个 Bot 的事件订阅和权限，第二个 Bot 按同样的方式配置即可

Session 的每日重置仍然有效。

每个 Session 独立受每日重置影响，所以如果你长时间不使用某个 Bot，它的上下文会被自动清理，不会造成资源浪费

不是只有飞书能用。

OpenClaw 支持的所有 Channel 都可以配置多账号，Telegram、Discord、WhatsApp 同理

小结

大语言模型的输出质量，不只由模型能力决定，更由你给它的上下文质量决定。

通过 OpenClaw 的多 Bot 配置实现 Session 隔离，是一个不需要改代码、不需要改配置结构、只需要添加几个飞书应用就能见效的优化手段。

它的核心思路其实很简单：不要让 AI 知道它不该知道的事情。对于不同的话题，给 AI 干干净净的上下文。