作用
让 agent 能在跨请求、跨进程、多用户场景下恢复状态。会话持久化由 agent 运行时自身负责:对话进展会追加进一份 native session journal——无损的、hash 链式的结构化事件序列。journal 永不压缩、永不重写;压缩只收缩上下文窗口。- Native session journal —— 完整历史:消息、带完整入参/结果的工具调用、推理事件,以原子 commit 存储
- 读时投影 ——
agent.sessionTranscript(ctx)与session_search/session_list工具按需把 journal 投影成扁平视图;不会再写任何对话副本文件
触发
关键逻辑
存储布局
- Journal:
JournalSessionLog把有序的、hash 链式的SessionEventcommit 落盘,payload 完整保留——工具入参/结果与推理内容不会被截断或丢弃。压缩摘要是普通事件,更早的事件从不删除。 - 后端:默认
LocalFilesystem把 journal 对象存在 workspace 的.agentscope-runtime/下;Windows 上使用 SQLite 后端,更大规模部署可以接入自定义SessionLogStore/AtomicSessionStorage(如远端存储)。 - 读取:
agent.sessionTranscript(ctx)把已提交事件投影成扁平Msg视图;session_search/session_list查询同一份 journal。
RuntimeContext 怎么路由 journal
RuntimeContext 决定这次调用读写哪份 journal:
- 键推导:
(agentId, userId, sessionId)映射到 journal 目录agents/<agentId>/sessions/<userId>/<sessionId>/。 - 隔离:不同的
userId/sessionId落在不同的 journal 目录,彼此没有共享可变状态。 - 恢复:每轮开始前按该身份重放已提交事件,状态跨重启可恢复。
- 应用侧读取:
agent.sessionTranscript(ctx)(扁平视图)或agent.sessionLog(ctx)(原始 journal)都不会触发推理。
默认与自定义存储
多用户隔离
- Journal 层:
userId+sessionId决定 journal 目录,不同用户的会话处于互不相交的命名空间。 - 文件层:
userId+NamespaceFactory决定文件操作路径前缀(默认LocalFilesystemWithShell会读每次调用的身份)。
列出会话
session_list / session_search 直接读 journal store——没有需要额外同步的索引文件。store 通过扫描 agents/<agentId>/sessions/ 下的会话头发现会话,所以凡是经运行时提交过的会话对两个工具自动可见。
相关文档
- 工具 —
session_search/session_list/session_history的入参 - 记忆 — 记忆提取如何与压缩配合,以及如何被
memory_search利用 - 文件系统 —
userIdRef+NamespaceFactory的多租户路径隔离 - Session log — journal 内部机制:后端、物理布局、自定义存储与导出