背景
Hermes Agent 目前有三大持久化机制：memory（用户偏好/环境事实）、knowledge base（gbrain 知识网络/Trilium 笔记库）、以及 session（会话记录）。前两者已有成熟的"载体"（carrier）和管理生命周期（整理、归档、推送、拉取、加载），而 session 仍停留在 SQLite 数据库的行记录级别，缺少类似的知识管理能力。
当前 Session 的存储载体 & 操作
Hermes session 目前存储在 state.db（SQLite WAL 模式），核心 schema：
sessions (id, source, user_id, model, title, parent_session_id,
started_at, ended_at, message_count, tokens, cost...)
messages (id, session_id, role, content, tool_calls, timestamp...)当前支持的操作：
- list / browse — 列表/交互式挑选
- rename — 改名
- export — 导出 JSONL（session + messages 的 dict 结构）
- delete / prune — 按时间清理
- search — FTS5 全文搜索 message 内容
- resume — 按 ID 或标题恢复
对标 memory / gbrain 的能力差异
| 操作 | memory 机制 | gbrain 知识库 | session 现状 |
|---|---|---|---|
| 整理 organize | 分类（memory / user） | 标签、类型、链接 | 只有 source 标签（cli/telegram） |
| 归档 archive | HRR 持久存储 | soft-delete + 72h 恢复 | 只有 hard delete |
| 推送 push | — | MCP 工具对外暴露 | 无 |
| 拉取 pull | — | 从外部 repo 导入 source | 无 |
| 加载 load | 每次自动注入 context | MCP query / search | 仅 resume 到当前 CLI |
| 版本管理 version | — | version history + revert | 无 |
| 结构化 metadata | 实体 + 信任分 | YAML frontmatter + tags + links | 只存原始字段 |
核心设计问题：Session 应该以什么载体管理？
不同粒度的管理需求对应不同的 carrier 方案：
方案一：SQLite 行（现状）
- 特点： 数据库内部，queryable 但不便携
- 适用： 运行时操作（搜索、恢复、续聊）
- 局限： 不能导出、不能版本化、不能跨实例迁移
方案二：Markdown + YAML Frontmatter（推荐）
这是最合适的通用 carrier，兼具 machine-readable metadata 与 human-readable narrative：
---
id: "20260526_115100_a1b2c3"
title: "重构 tgfw 数据提取流程"
source: telegram
model: deepseek-v4-flash
provider: opencode-go
started_at: 2026-05-26T11:51:00+08:00
ended_at: 2026-05-26T13:20:00+08:00
message_count: 47
input_tokens: 285000
output_tokens: 12000
parent_session: "20260526_103000_x1y2z3"
tags: [tgfw, data-extraction, web-scraping]
projects: [hermes-oracle-at]
---
## 目标
重构 tgfw.csc108.com 的数据提取脚本...
## 会话摘要
### 阶段 1: 分析 WAF 保护机制
...
### 阶段 2: 设计浏览器自动化方案
...
## 关键决策
- 采用 context.on("response") + 动态 token 捕获方案
- 放弃 HAR 导入方式（token 时间戳过期问题）
## 产出文件
- `scripts/tgfw.csc108.com/update_json.py`MD + YAML 为什么是最优 carrier：
- 人类可读 — 转录内容可被浏览、搜索、引用
- Git 原生 — diff、版本管理、PR 协作
- 与 gbrain 兼容 — 同一格式，可直接
put_page到知识库 - 与 Obsidian/Trilium 兼容 — 知识双链系统无障碍消费
- 可索引 — YAML frontmatter 天然支持 tags、aliases、dates
- 可结构可叙事 — 既有结构化 metadata（tokens、cost、model），又有可读的摘要/决策记录
方案三：SKILL.md 格式（特定场景）
对某些模式高度重复的 session（如"debug 数据库连接"、"提取某个新平台的 WAF 数据"），提取为可复用的 skill。
方案四：gbrain page（可检索归档）
将 session 摘要 + 关键结论沉淀到 gbrain，以持久实体暴露，融入知识网络。
理想架构：Session 的分层管理模型
| 层次 | 载体 | 生命周期 | 接口操作 |
|---|---|---|---|
| Layer 1 运行时会话 | state.db SQLite 行 | 短期，API 操作（search/resume） | create / read / list / resume |
| Layer 2 持久化归档 | MD + YAML 文件 | 中期，Git 版本管理、可查阅 | archive / export / import / tag |
| Layer 3 知识沉淀 | gbrain page / skill | 长期，融入知识网络可复用 | push / pull / link / query |
关键生命周期操作设计
| 操作 | 语义 | 实现方式 |
|---|---|---|
| 整理 tag / categorize | 给 session 打标签 | YAML frontmatter 的 tags / 项目字段 |
| 归档 archive | 从热存储移到冷存储 | SQLite → MD 文件导出，可压缩 |
| 推送 push | 将 session 共享到其他 context | 写 gbrain page / 发送到 Telegram 附件 |
| 拉取 pull | 从外部源导入 | 从 MD 文件 / gbrain 反向恢复 session 上下文 |
| 加载 load | 将归档 session 注入当前对话 | 按需读取 MD 的摘要 / 关键决策段 |
| 快照 checkpoint | 重要 session 的里程碑版本 | Git commit + YAML frontmatter 的 version 字段 |
| 关联 link | 跨 session 引用 | parent_session_id / MD 中 wikilink |
结论
最合适的 carrier = Markdown + YAML frontmatter。
理由简而言之：它兼具机器可读的元数据结构和人类可读的叙事体，兼容已有基础设施（Git、gbrain、Trilium、Obsidian），从现有 SQLite → MD 的导出成本极低（export_session 已有 dict 输出，转 MD 只是一个 template 渲染任务）。标签、分类、版本控制天然支持——这是"知识管理"视角的 session，而非"运行时日志"视角的 session。