核心特性
- 持久化存储:保存 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, ...
- 备份旧数据:
- 删除旧表:
- 重新创建(使用
createIfNotExist=true自动创建):
Redis 存储结构变更
新版 API 使用了不同的 Redis key 结构: 旧结构:- 清除旧数据(如果不需要保留):
- 新数据会自动使用新结构存储。
更多资源
- 完整示例: SessionExample.java
- State 文档: state.md
- Agent 配置: agent-config.md