DeepSeek Harness 会话存在哪怎么查？DSH plugin 的会话日志与持久化模型

DeepSeek Harness 的一个逻辑会话由一份 header 加一段有序的事件日志组成，每条事件带 seq、type 与时间戳；查询时可使用与提供方无关的过滤器、全文搜索、会话谱系与有界事件读取，且 live 数据优先于持久化数据（来源）。 会话既是模型下一轮的上下文来源，也是你事后回看整条链路的依据——正因为它同时承担「喂给模型」和「给人看」两种角色，它的数据模型才被设计成事件日志而不是一段流水账。这篇讲这套数据模型怎么组织、怎么查、插件该从哪读；在哪看、怎么搜见《DeepSeek Harness 会话记录在哪》，会话如何接入链路见《DeepSeek Harness 一轮对话怎么跑》。

为什么会话要做成「事件日志」

把会话做成有序事件日志，而不是一整段拼好的对话文本，是为了让「顺序、检索、增量读取、后续加工」这四件事都成为可能（来源）。 把两种做法摆在一起对比：

1. 顺序需要显式标定：如果只存一段文本，先后只能靠位置猜；事件日志给每条事件一个单调序号，顺序是确定的。
2. 检索需要结构化：按类型筛、按范围取、按关键字搜，都要求事件可被单独寻址；一段纯文本做不到这些。
3. 增量读取需要边界：新事件不断追加，只有带序号的事件才能「只取上次之后的部分」。
4. 后续加工需要稳定形态：插件想在会话数据上做文章，必须有一份稳定的、与存储后端无关的读取接口，否则每种后端都要写一遍。

因此，事件日志不是存储细节，而是这套会话机制的核心抽象；下面所有的查询能力，都建立在这个抽象之上。

DeepSeek Harness 的一个逻辑会话由什么组成

DeepSeek Harness 的一个逻辑会话由一份 header 加一段有序的事件日志组成，事件日志按 seq 给出确定顺序（来源）。 三个要点：

1. header 是基础信息：SessionHeader 记录这条会话的身份与元数据，与日志一起构成逻辑会话；它是「这条会话是谁」的答案。
2. 日志是有序的：每条事件带单调递增的 seq，顺序不靠时间戳猜——时间戳可能相同、可能乱序，序号不会。
3. 逻辑会话与存储解耦：查询以逻辑会话为单位，底层以哪种后端存放不影响你按同一套词汇取用；这正是抽象的价值所在。

事件里有什么：seq、type 与时间

DeepSeek Harness 的每条会话事件带有单调递增的 seq、事件类型 type 与时间戳，这三个字段共同支撑排序、过滤与回放（来源）。 逐个看它们的用途：

1. seq 管顺序：它标定事件在会话中的先后，也是「按范围有界读取」的坐标——取 seq 落在某区间的事件，就是取会话的某一段。
2. type 管分类：它标明这是什么事件，于是「只看某一类事件」成为一次过滤操作，而不需要读完再筛。
3. 时间管时刻：它给出事件发生的实际时间，用于人类视角的排序与展示，但不作为顺序依据。
4. 三者合起来可回放：按 seq 排序、按 type 筛选、按时间呈现，就能重建这条会话里发生过什么、以什么次序发生。

查询这套会话数据的词汇

在 DeepSeek Harness 里查询会话，可用与提供方无关的过滤器、全文搜索、会话谱系与有界事件读取（来源）。 逐项理解：

1. 与提供方无关的过滤器：数组内各项按「与」组合、单项列表内各值按「或」组合、范围含两端。所谓「与提供方无关」，是指这套过滤词汇不绑定某个具体的搜索或存储后端，换后端不必改查询写法。
2. 全文搜索：对提取出的语义文本做扫描，同样不绑定具体搜索提供方；因此「搜到某段内容」这件事不依赖外部服务。
3. 会话谱系：用于追踪会话之间的关系，比如派生或关联——这让「这条会话是从哪来的、又派生了什么」有据可查。
4. 有界事件读取：按 seq 范围取一段事件，而不是一次拉全量；事件是不断追加的，能按边界取就能只拿需要的那部分。
5. 原子观测：读取以快照形式给出，便于恢复预检与校验——你看到的是一个一致的断面，而不是读到一半还在变的集合。

live 优先意味着什么

当 live 数据存在时，DeepSeek Harness 的会话查询优先采用 live 数据；逻辑会话的语料库以实时数据优先、持久化数据兜底的方式组织（来源）。 三点含义：

1. 还在跑的会话也能被查到：会话不必等落盘才可观察，因此「当前这轮进行到哪了」是可见的。
2. 新鲜度优先于完整性：优先读实时数据，意味着查询拿到的是此刻最新的状态，而不是上一次持久化的旧快照。
3. 持久化负责不丢：实时数据在内存里跑，持久化数据负责兜底与长期保存；两者各司其职，查询层替你把优先级处理掉。

插件怎么用它：ctx.sessionQuery

DSH plugin 通过 ctx.sessionQuery 这个抽象的会话查询引擎入口来访问会话数据，由它负责精确读取、来源优先级、关系追踪与语义提取（来源）。 两点理解：

1. 插件不碰底层文件：会话存在哪里、用什么格式、怎么合并 live 与持久化，都由服务层处理；插件只按查询词汇取用，因此不会因后端变化而失效。
2. 接入点是服务而非格式：想在会话数据上做插件（比如统计、检索、汇总），入口是 ctx.sessionQuery；现成实现可在「设置 → 插件市场」即 DSH Plugin Hub 里找。

理解会话持久化的注意事项

把「逻辑会话」「事件日志」「live 优先」三件事记住，会话这块就清楚了。

1. 先有逻辑会话，再谈存储形式：查询词汇不随后端变化，插件也别依赖具体文件布局。
2. 顺序看 seq 不看时间：时间只表示发生时刻，排序一律以序号为准。
3. 能按范围读就别拉全量：有界读取更高效，也更符合事件不断追加的实际形态。
4. 过滤词汇可组合：项间「与」、值间「或」、范围含两端，组合起来能表达精确的筛选意图。
5. 还在跑的会话也可能被查到：这得益于 live 优先。
6. 插件走 ctx.sessionQuery：不直接碰底层文件，也不自己实现来源优先级。
7. 操作向教程见《DeepSeek Harness 会话记录在哪》，会话如何接入链路见《DeepSeek Harness 一轮对话怎么跑》。

来源：DeepSeek Harness 官方文档 - 会话查询、官方文档 - 核心子系统。