Skip to main content
Session 支持 Agent 状态的持久化存储和恢复,让对话能够跨应用运行保持连续性。

核心特性

  • 持久化存储:保存 Agent、Memory 等组件状态
  • 简洁 API:直接通过 Agent 调用 saveTo() / loadFrom()
  • 多种存储:支持 JSON 文件、内存等后端
  • 灵活标识:使用简单的字符串会话 ID 或自定义 SessionKey

快速开始


Session 实现

AgentScope 提供两种 Session 实现:

JsonSession(推荐)

将状态以 JSON 文件存储在文件系统中。
特性
  • 目录格式:每个会话一个目录 {sessionId}/
  • 单值状态:{key}.json 文件
  • 列表状态:{key}.jsonl 文件(JSONL 格式,增量追加)
  • UTF-8 编码,自动创建目录
⚠️ 安全提示JsonSession 会直接将 sessionId 作为会话目录名。如果 sessionId 来自不受信任的来源(例如 HTTP Cookie 或查询参数),攻击者可能会注入路径遍历字符(如 ..)或路径分隔符,从而在预期的会话目录之外读写文件。请务必在使用前验证和清理 sessionId - 仅允许安全字符(字母、数字、下划线、连字符),并拒绝包含路径分隔符或 .. 序列的值。

InMemorySession

将状态存储在内存中,适合测试和单进程临时场景。
注意
  • 应用重启后状态丢失
  • 不适合分布式环境
  • 内存使用随会话数量增长

Agent 状态管理 API

保存操作

加载操作

Session 管理操作


完整示例


自定义 Session

实现 Session 接口创建自定义存储后端:

数据格式与迁移

新旧数据格式对比

新版 Session API 采用了全新的存储格式,与旧版 SessionManager 不兼容:

旧版格式示例

文件内容:

新版格式示例

memory_messages.jsonl 内容(每行一条消息):

数据迁移

由于格式不兼容,旧版数据无法直接被新版 API 读取。如需迁移,请按以下步骤操作:

方案一:重新开始(推荐)

如果旧数据不重要,直接删除旧的会话文件,使用新 API 创建新会话:

方案二:手动迁移

如果需要保留历史对话数据,可以编写迁移脚本:

方案三:双版本并行

在过渡期间,可以保留旧代码用于读取历史数据,新会话使用新 API:

数据库后端迁移

MySQL 表结构变更

新版 API 使用了不同的表结构。如果之前使用过 MysqlSession,需要迁移表结构: 旧表结构
新表结构
item_index 列实现了真正的增量列表存储:
  • 单值状态:使用 item_index = 0 存储
  • 列表状态:每个元素单独存储一行,item_index = 0, 1, 2, ...
迁移步骤
  1. 备份旧数据
  1. 删除旧表
  1. 重新创建(使用 createIfNotExist=true 自动创建):
或手动执行上述新表结构 SQL。

Redis 存储结构变更

新版 API 使用了不同的 Redis key 结构: 旧结构
新结构
迁移步骤
  1. 清除旧数据(如果不需要保留):
  1. 新数据会自动使用新结构存储。

更多资源