先搞清楚一件事:session 是什么
OpenClaw 里你跟 AI 的每一次对话,都会被固化成一个 session(会话),它有:
- 一个稳定 ID(形如
agent:main:main) - 一份完整的消息历史(你说了什么、AI 说了什么、调了哪些工具)
- 一个归属(属于哪个 agent、哪个通道、哪个分组)
这意味着:关掉窗口 ≠ 对话消失。只要 session 还在,你随时可以把它捞回来接着聊,或者让另一个 AI 去读它的历史。
很多人用 OpenClaw 半年,从来没有翻过自己的历史会话,等于手里攒了一座矿却从不挖。
四个命令,覆盖 90% 的场景
1. sessions_list —— 看看你有哪些会话
openclaw session list
常用组合:
# 只看最近 3 天有活动的
openclaw session list --active-minutes 4320
# 按名字搜
openclaw session list --search "养虾"
# 顺便带上最后一条消息预览
openclaw session list --include-last --message-limit 3
我自己的用法:每天早上先跑一次带预览的 list,一眼扫完昨晚哪些定时任务跑过、跑成什么样。
2. sessions_history —— 读某个会话的完整历史
openclaw session history --session-key agent:main:main --limit 50
几个好用的开关:
--include-tools:把工具调用也拉出来(排查"AI 到底执行了什么"时必开)--message-id <id>:从某条消息往后读,不用从头翻--offset N:翻页
真实场景:某天我发现网站少了一篇文章,第一反应不是重写,而是去翻凌晨 03:00 那个 cron 会话的历史 —— 结果发现它报错退出,错误信息一句话写得很清楚。五分钟定位,而不是重造轮子。
3. sessions_search —— 全历史全文检索
openclaw session search "发布静态站"
这条是我用得最多的。它搜的是 所有可见会话的用户 + 助手文本,返回 sessionKey / sessionId / messageId 三元组,拿到之后再用 history 定位上下文:
openclaw session history --session-key <key> --message-id <id> --limit 10
不要凭记忆找东西。 你记不清"上次那个 nginx 配置改在哪次对话里",搜一下就有。
4. sessions_send —— 让另一个会话继续干活
openclaw session send --session-key <key> "继续把刚才那篇稿子发出去"
这是 session 机制的杀手锏:会话是地址,不是窗口。你可以从手机上的微信通道,给服务器上某个后台会话发一条指令,它在那边的完整上下文里继续执行。
同理,sessions_spawn 开出来的子智能体也是一个个 session —— 所以它们可以被查看、被追问、被续跑,而不是"发出去就黑盒了"。
sessionKey 的三段式,别搞混
agent:main:main
│ │ └─ 会话标识(主会话)
│ └────── agent id
└───────────── 固定前缀
- agent id:哪个智能体(
main、draw这类) - 最后一段:主会话是
main;cron 任务会带cron:<jobId>:run:<runId>;子智能体是自己的 key
注意:UI 上显示的标签(label)不是 sessionKey。要用 sessions_list 拿真实 key,别拿显示名去 send,会找不到。
上下文会超限,超限不等于丢
每个会话的上下文长度有上限。聊到某个点会触发压缩/超时,新会话接手。
应对办法(我自己在用的):
- 写一个
HANDOFF.md,里面放"当前项目、阻塞点、关键路径、已知坑"; - 在 AGENTS.md 里写死一句:上下文超时后先读 HANDOFF.md;
- 真正需要长上下文的任务,拆成多个 session,用文件而不是聊天记录传递状态。
原则:状态写在文件里,不写在对话里。 对话会被压缩,文件不会。
权限与可见性:别在群里翻主会话
有两条要记牢:
- 共享上下文(群聊、Discord、有外人的会话)里不要加载个人记忆文件。MEMORY.md 存的是私人上下文,只该在主会话读。
sessions_list只能列到"可见"的会话,可见性由配置(tools.sessions.visibility)控制。看不到不是坏了,是权限。
三条实践建议
- 给重要会话起 label。定时任务、长期项目都起个名字,后面 list / send 都靠它,不用记 ID。
- cron 任务的会话要留着。它们的运行结果、报错信息全在历史里,是所有"静默失败"唯一的证据链。
- 定期清。纯粹一次性的会话(临时查个东西)accumulate 起来会拖慢检索,该归档就归档。
一句话总结
OpenClaw 的 session ≠ 聊天窗口。list 看全局、history 看细节、search 做检索、send 做续跑。把这四条用熟,你的 AI 才有"记忆连续体",而不是每天早上失忆重来。
扫码关注公众号,获取更多 OpenClaw 实操技巧:
