SessionStore（会话存储）是日志服务面向 AI 应用提供的会话级存储与分析资源，适用于 Agent 故障排查、性能优化、效果评估、安全审计、成本分析等场景。它将用户多轮会话与应用日志、模型输入输出、执行轨迹及工具调用统一关联，支持从一次响应异常逐层追溯到具体执行环节，定位回答错误、工具调用失败和链路耗时等问题，并分析 Token 消耗、模型及工具使用情况，为 AI 应用的持续优化与运营提供数据支撑。
什么是 SessionStore
SessionStore 位于日志服务项目（Project）下。您可以在一个 Project 中管理不同应用的 SessionStore，并查看同一应用不同视图的数据。
数据视图 | 查看内容 | 典型问题 |
原始数据 | 接入或关联的原始日志 | 数据是否上报成功，原始字段是否正确？ |
单条轨迹 | 一次执行的输入输出、步骤及 Agent 关系 | 某次请求在哪里耗时，使用了哪些工具？ |
会话 | 按 Session ID 关联的多轮交互及执行轨迹 | 同一会话的前后文是什么，哪一轮出现异常？ |
轨迹特征 | 从执行过程中提取的工具、文件、技能或记忆事件 | 哪类工具频繁出现错误，哪些轨迹访问了某个文件？ |
基本概念
概念 | 说明 |
原始数据（Raw） | 应用、采集器或网关上报的日志，是排查采集与字段问题的依据。 |
轨迹（Trajectory） | 对执行过程的结构化表示，包含输入输出、执行步骤，以及数据中明确提供的 Agent 调用关系。不要把每个原始 Span 都当作一条独立轨迹。 |
会话（Session） | 使用同一 Session ID 关联的一组交互。一个会话可以包含多条执行轨迹。 |
轨迹特征（Trajectory Feature） | 对执行过程中某类行为的结构化记录，例如工具调用和文件读写。特征记录用于检索与统计，不等同于质量评分。 |
执行步骤（Step） | 轨迹中的一项事件，例如模型交互、工具调用或工具返回。 |
Trace ID | 用于关联一次链路执行的标识。是否具备该标识，取决于数据来源。 |
选择数据接入方式
SessionStore 支持直写和引用两种方式。
对比项 | 直写模式（managed） | 引用模式（reference） |
适用情况 | 新应用接入，或希望将数据直接写入 SessionStore | 应用数据已经采集到普通 LogStore |
数据写入位置 | 当前 Project 下的 SessionStore | 原来使用的源 LogStore |
创建时是否选择源 LogStore | 否 | 是，需要选择源 Project 和 LogStore |
数据来源范围 | 当前 SessionStore 的接入链路 | 同一阿里云账号、同一地域的普通 LogStore，可位于不同 Project |
采集配置管理 | 在 SessionStore 的数据接入入口管理 | 在源 LogStore 管理 |
原始数据索引 | 可在 SessionStore 中创建或修改 | 在 SessionStore 中只读查看，需要到源 LogStore 修改 |
调整 SessionStore 保留策略 | 调整 SessionStore 管理的数据 | 不改变源 LogStore 的保留策略 |
支持的数据格式
数据格式 | 适用来源 |
OpenTelemetry Trace | 以 OpenTelemetry Trace/Span 形式上报的执行链路及 GenAI 数据。 基于云监控 2.0 /ARMS 探针接入的 Trace 日志或者基于 Opentelemetry sdk 接入的 trace 日志 |
OpenTelemetry Log Ebpf | 按对应格式采集的 eBPF Agent 日志。 基于日志服务 Loongcollector input_agentsight 插件采集的日志。 |
OpenTelemetry Log AI Gateway | 阿里云 AI 网关日志 |
典型使用场景
排查单次响应异常
当 Agent 回答错误、工具调用失败或任务未按预期完成时，通过执行轨迹查看模型输入输出、工具参数与返回结果，定位异常发生的具体步骤，并关联原始日志核验回答依据。例如，在客服回答“订单未到账”时，追溯订单查询、到账流水和故障信息，判断回答是否有事实支撑。
分析多 Agent 协作过程
当任务由多个 Agent 协作完成时，通过轨迹中记录的主、子 Agent 关系，还原任务委托、分支执行和结果返回过程，分析问题发生在哪个 Agent，以及分支结果如何影响最终回答。例如，查看客服 Agent 委托诊断 Agent 排查故障后，是否正确使用了诊断结果。
追踪多轮会话与任务结果
当用户围绕同一问题连续追问时，通过 Session 关联各轮对话及执行轨迹，对照业务状态变化、每轮查询结果与 Agent 回答，检查 Agent 是否依据新证据更新判断。例如，在“付款后未到账—服务恢复—再次核验”的连续交互中，区分服务恢复与订单实际到账，定位沿用旧上下文或未经核验便宣称问题已解决的情况。
分析执行耗时与资源消耗
当 Agent 响应缓慢或 Token 消耗偏高时，按会话、轮次、模型和 Agent 分析调用次数、执行耗时与 Token 用量，下钻到具体模型调用、工具调用及协作分支，识别耗时集中环节和重复执行，为调整模型选择、上下文组织及协作流程提供依据。
审计 Agent 操作与执行依据
需要核查 Agent 是否遵循任务要求时，通过工具名称、调用参数、返回结果及原始记录，追溯实际执行的操作，并关联业务凭证核验结果。例如，在“仅查询订单”的任务中，检查已采集的执行记录是否包含补发或退款调用，以及“已到账”的回答是否具有到账流水支持。
沉淀评估与回归样本
需要验证模型、提示词或 Agent 版本调整后的效果时，将生产会话中的连续问答、执行轨迹及工具结果整理为评估样本，为 AgentLoop 等评估系统提供可复用的上下文与执行证据。例如，将“服务已恢复但仍无到账流水”的会话作为回归案例，检验新版本是否仍遵循“无凭证不宣称到账”的规则。