★ FEATURED ARTICLE 1. 飞书会话把 state.db 撑到几百 MB问题出在哪Hermes 接入飞书之后会话数据膨胀几乎是必然的。飞书群聊、单聊、机器人回调都会生成 session每条 session 下面挂着完整的 messages 历史再加上 FTS5 全文索引的虚拟表一个活跃的飞书机器人跑上两三个月~/.hermes/state.db涨到几百 MB 很常见。我见过最夸张的一个实例state.db 主文件 480MBstate.db-wal还有 120MB 没 checkpoint 掉。这个问题的本质是Hermes 把所有平台的会话都塞进同一个 SQLite 库sessions表用source字段区分来源cli、telegram、discord、feishu 等messages表存完整消息历史messages_fts是 FTS5 虚拟表靠触发器自动跟随。飞书作为高频交互平台session 数量增长最快但 Hermes 默认的 prune 策略只清理「已结束」且超过 90 天的会话对活跃的飞书会话基本不动手。所以「清理飞书会话」这件事拆开看就是两步定位source为飞书的那批 session然后连同它们的 messages 一起删掉。听起来简单但实际操作里有几个坑——source 值可能是feishu也可能是lark删之前必须核对prune 命令默认--older-than 90不改成 0 就删不掉今天的会话messages 引用 sessions删除顺序不能反。这篇指南面向的是已经用 Hermes Agent 接入飞书、发现 state.db 体积异常、想按步骤完成清理和配置校验的开发者。我会从 SQLite 表结构讲起给出可复制的config.toml骨架和 SQL 清理语句最后用 TaoToken 统一 Key 通道验证 gateway 调用是否生效——这样你清完之后能立刻确认飞书链路还是通的不会出现「删完发现机器人不回消息」的尴尬。2. 清理前的前置准备停 gateway、备份、确认 source2.1 先停掉 gateway运行中直接改库会产生锁冲突而且正在跑的飞书会话不会正常结束prune 命令会跳过它们。所以第一步永远是停网关hermes gateway stop停完之后确认一下进程真的没了ps aux | grep hermes | grep -v grep如果还有残留进程kill掉再继续。这一步别省我试过在 gateway 运行状态下执行 SQL 删除结果 WAL 文件锁住sqlite3 直接报database is locked。2.2 备份三个文件SQLite 在 WAL 模式下数据分散在state.db、state.db-wal、state.db-shm三个文件里只备份主文件是不够的。三个一起拷cp ~/.hermes/state.db ~/.hermes/state.db.bak cp ~/.hermes/state.db-wal ~/.hermes/state.db-wal.bak 2/dev/null cp ~/.hermes/state.db-shm ~/.hermes/state.db-shm.bak 2/dev/nullHermes 自己也提供了快照式备份命令更省事hermes backup --quick注意备份文件别放在~/.hermes/目录下否则下次 Hermes 扫描目录时可能把.bak文件也当成数据库处理。放到~/backup/之类的独立目录更稳妥。2.3 确认飞书的 source 值这是最容易出错的一步。Hermes 里飞书的 source 值大概率是feishu但也可能是lark取决于你接入时用的 SDK 和配置。删之前必须查清楚sqlite3 ~/.hermes/state.db SELECT source, COUNT(*) FROM sessions GROUP BY source;输出大概长这样cli|12 telegram|8 feishu|347 discord|3看到feishu|347就说明飞书有 347 条会话。下文所有命令里出现feishu的地方都替换成你实际查到的值。如果输出里同时有feishu和lark那可能是两次不同接入方式留下的需要分别处理。3. 可复制的 config.toml 骨架与 gateway 路由配置清理会话之前先把 gateway 的配置理清楚这样清完之后能立刻验证链路。Hermes 的 gateway 配置在~/.hermes/config.toml飞书接入相关的核心字段如下[gateway] enabled true host 127.0.0.1 port 8787 [gateway.platforms.feishu] enabled true app_id cli_xxxxxxxxxxxx app_secret xxxxxxxxxxxxxxxxxxxxxxxx verification_token xxxxxxxxxxxxxxxx encrypt_key xxxxxxxxxxxxxxxx source_tag feishu [gateway.routing] # 飞书消息路由到哪个 agent default_agent hermes-main # 会话隔离策略per_user / per_chat / global session_scope per_chat # 会话过期时间小时超过后新消息开新 session session_ttl_hours 72 [gateway.llm] # 统一走 TaoToken 的 OpenAI 兼容通道 base_url https://taotoken.net/api api_key sk-你的TaoToken密钥 model claude-sonnet-4-20250514这里有几个关键点。source_tag决定了 session 写入sessions表时source字段的值如果你这里写的是feishu那数据库里就是feishu如果写的是lark数据库里就是lark。所以第 2.3 步查出来的值应该和这里的source_tag一致。session_scope和session_ttl_hours直接影响会话增长速度。per_chat意味着每个飞书群/单聊一个 sessionsession_ttl_hours 72表示 72 小时没新消息就过期。如果你发现会话膨胀特别快可以把 TTL 调小比如 24 小时让不活跃的会话更快进入可 prune 状态。gateway.llm这一段是走 TaoToken 统一 Key 通道的关键。TaoToken 提供 OpenAI 兼容接口base_url 填https://taotoken.net/apiapi_key 用你在控制台生成的密钥。这样 Hermes 的 gateway 调用模型时请求会经过 TaoToken 转发你可以在 TaoToken 的日志里看到每次调用的记录方便验证 gateway 是否真的在工作。配置改完之后重启 gateway 让配置生效hermes gateway restart4. 两种清理方式CLI prune 与直接 SQL4.1 方式 ACLI prune推荐最安全Hermes 自带的sessions prune支持按平台过滤这是最不容易出错的方式。先不加--yes预览一下会删多少条hermes sessions prune --source feishu --older-than 0这里--older-than 0是关键。默认值是 90只删 90 天前的会话今天的飞书会话根本不动。设成 0 表示包含今天也就是全部飞书会话。命令会输出「将删除 N 条会话」核对 N 和你第 2.3 步查到的条数是否一致。确认无误后加--yes正式执行hermes sessions prune --source feishu --older-than 0 --yesprune 的参数说明参数含义--source SOURCE只清理该来源的会话--older-than N删除 N 天前的会话默认 90填 0 表示全部--yes/-y跳过确认提示prune 的局限是只能删「已结束」的会话。如果飞书那边有会话卡在未结束状态比如 gateway 异常退出导致 session 没正常关闭prune 会跳过它们。这时候需要方式 B。4.2 方式 B直接 SQL最彻底直接操作 SQLite 能删掉所有飞书会话包括未结束的。关键是删除顺序先删messages再删sessions因为 messages 通过session_id引用 sessions。FTS5 索引messages_fts靠触发器自动跟随 messages 表变化不用手动维护。sqlite3 ~/.hermes/state.db SQL DELETE FROM messages WHERE session_id IN (SELECT id FROM sessions WHERE sourcefeishu); DELETE FROM sessions WHERE sourcefeishu; SQL执行完之后验证一下sqlite3 ~/.hermes/state.db SELECT COUNT(*) FROM sessions WHERE sourcefeishu;返回 0 就说明清干净了。再查一下 messages 表里有没有孤儿记录sqlite3 ~/.hermes/state.db SELECT COUNT(*) FROM messages WHERE session_id NOT IN (SELECT id FROM sessions);正常情况下应该是 0。如果大于 0说明有残留可以再跑一次删除语句。注意SQL 删除不会触发 VACUUMstate.db 文件大小不会立刻缩小。要回收空间需要手动执行sqlite3 ~/.hermes/state.db VACUUM;但这会重建整个数据库文件大库上耗时较长建议在 gateway 停止状态下做。5. 重启 gateway 并用 TaoToken 验证调用是否生效清理完成后重启 gatewayhermes gateway start然后确认 gateway 状态hermes gateway status输出里应该能看到feishu平台处于connected状态。接下来用 TaoToken 的模型对话通道验证一下 gateway 调用链路是否正常。先确认你的 TaoToken 密钥有效可以直接用 curl 测一下curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: ping}], max_tokens: 10 }返回里有choices字段就说明 TaoToken 通道正常。然后在飞书里给机器人发一条消息观察 gateway 日志hermes gateway logs --follow日志里应该能看到类似这样的记录[feishu] received message from userou_xxxx chatoc_xxxx [gateway] routing to agenthermes-main sessionnew [llm] request via https://taotoken.net/api modelclaude-sonnet-4-20250514 [llm] response received tokens45 latency1.2s [feishu] reply sent to chatoc_xxxx看到sessionnew说明清理后新会话正常创建request via https://taotoken.net/api说明 LLM 调用走的是 TaoToken 通道。如果日志里出现sessionexisting说明还有旧会话残留需要回去检查 SQL 删除是否彻底。你也可以在 TaoToken 控制台的调用日志里看到这次请求的记录包括时间、模型、token 消耗。这样双向验证既确认了 gateway 在工作也确认了 TaoToken 通道在正常转发。6. 本篇常见错误排查6.1database is locked这个错误几乎都是 gateway 没停干净导致的。确认hermes gateway stop之后进程真的退出了再执行 SQL。如果还有残留用fuser ~/.hermes/state.db查一下哪个进程占着文件。6.2 prune 删了 0 条最常见的原因是--older-than没设成 0。默认 90 天飞书会话基本都是近期的自然删不到。另一个原因是 source 值写错了比如数据库里是lark但你传了--source feishu。回去跑第 2.3 步的查询确认。6.3 删完之后飞书机器人不回消息先看 gateway 日志有没有报错。如果日志里出现no session found或者agent not configured检查config.toml里gateway.routing.default_agent是否指向了存在的 agent。如果日志里 LLM 调用报 401检查 TaoToken 密钥是否过期或额度是否用完。6.4 state.db 文件大小没变SQL 删除只是标记页面为可复用不会缩小文件。需要VACUUM才能回收空间。但 VACUUM 会重建整个数据库建议在 gateway 停止状态下执行并且确保磁盘有足够空间VACUUM 期间会临时占用约等于原库大小的空间。6.5 FTS 索引残留正常情况下messages_fts会跟随 messages 表自动清理。但如果之前手动改过触发器可能出现索引残留。检查一下sqlite3 ~/.hermes/state.db SELECT COUNT(*) FROM messages_fts;如果这个数字和SELECT COUNT(*) FROM messages;不一致说明索引和主表不同步。可以重建 FTS 索引sqlite3 ~/.hermes/state.db INSERT INTO messages_fts(messages_fts) VALUES(rebuild);7. 清理后的配置校验与长期维护清完飞书会话、验证完 gateway 链路之后建议把config.toml里的session_ttl_hours调小一点比如从 72 改成 24让不活跃会话更快过期减少下次清理的工作量。同时可以设一个定期任务每周跑一次 prunehermes sessions prune --source feishu --older-than 7 --yes这样只删 7 天前的飞书会话保留近一周的对话历史既控制了库体积又不会误删正在用的会话。如果你同时接了多个平台建议每个平台单独跑一次 prune别用全局 prune避免误删其他平台的数据。TaoToken 的调用日志可以帮你确认每个平台的 gateway 调用频率如果某个平台调用量异常高可能是会话膨胀的前兆提前处理比事后清理省事。最后提醒一句会话session和记忆memory是两回事。这篇指南清的是~/.hermes/state.db里的对话历史不影响~/.hermes/memory/下的MEMORY.md、USER.md等长期记忆文件。如果你要清记忆那是另一套操作别搞混了。
阅读完成 · 觉得有帮助？
