为什么一个搜索功能值得花3天重写？因为每天100次搜索 = $30 的 LLM 费用 + 2.5小时的等待时间。而解决方案只是一个 200 行的 FTS5 SQLite 查询。
背景：Hermes 的搜索之痛
Hermes Agent 是一个持续运行的 AI 助手，每次会话（session）都会生成大量上下文——代码审查结论、错误栈、决策理由、中间产物。随着使用时间增长，你总需要回头找到"上个月那个 Bug 的根因分析"或"那个已经验证过的部署脚本"。
之前 Hermes 的做法是：每次搜索都调 LLM 生成摘要 → 存向量 → 语义检索。这是一个"看起来很 AI"的解决方案，但问题也很现实：
- 慢：每次搜索需要 LLM 推理 → 摘要 → 编码，全程 ~90 秒
- 贵：每次搜索调用一次 LLM，按 GPT-4 级别算，$0.30/次
- 不准：LLM 摘要本身可能遗漏关键信息，有幻觉风险
- 不可审计：你搜到的是 LLM "总结"后的结果，不是原文
对一人公司运营者来说，这意味着：一天搜 20 次历史会话 = 白白花掉 $6 + 干等 30 分钟。
新方案：FTS5 全文搜索 + 锚定窗口
5月18日凌晨，Hermes 核心开发者 teknium1 提交了 abf1af5，用 SQLite 内置的 FTS5（Full-Text Search 5）完全替代了 LLM 搜索链路。
核心架构
用户搜索关键词 → FTS5 全文索引（~20ms）
↓
返回匹配的会话片段 + 上下文窗口（锚定窗口）
↓
不需要 LLM、不需要 embedding、不需要向量数据库
三种调用模式：
| 模式 | 用途 | 类比 |
|---|---|---|
| Discovery | 关键词搜索 + 书签窗口 | Google 搜索 |
| Scroll | 基于锚点翻页浏览 | git log --follow |
| Browse | 最近 N 个会话列表 | Finder 最近打开 |
可复制的代码配置
如果你在用 Hermes Agent，这个功能已内置在 v0.14.0+ 版本中。在你的 config.yaml 中启用：
# config.yaml - Hermes session_search 配置
session_search:
enabled: true
engine: fts5 # 默认，替代旧的 llm_summary
max_results: 20 # Discovery 模式下返回的最大结果数
context_window: 512 # 每个匹配项前后的上下文字符数
index_fields:
- message_content
- tool_outputs
- system_events
使用方式（在 Hermes 对话中）：
/search 数据库连接池配置
/search --mode scroll --anchor session_abc123
/search --mode browse --limit 10
性能对比实测
| 指标 | 旧方案（LLM摘要搜索） | 新方案（FTS5全文搜索） |
|---|---|---|
| 单次搜索延迟 | ~90 秒 | ~20 毫秒 |
| 单次搜索成本 | $0.30 | $0 |
| 准确度 | LLM 摘要（有幻觉风险） | 原文精确匹配 |
| 可审计性 | 摘要不可溯源 | SQLite 逐字节原文 |
| 日100次搜索成本 | $30 | $0 |
| 日100次搜索等待 | 2.5 小时 | 2 秒 |
4500 倍的提速不是渐进优化，而是架构选择的胜利。
工程启示：去 LLM 化的降本路径
这个案例对 AI Agent 产品创业者有 3 层启示：
1. "能用 SQL 解决的，别用 LLM"
搜索就是搜索。FTS5 是 SQLite 从 2015 年就内置的全功能搜索引擎，支持：
- 布尔查询（AND/OR/NOT）
- 前缀匹配（prefix*）
- 短语查询（"exact phrase"）
- 近邻搜索（NEAR(token1 token2, 10)）
这些功能覆盖了 95% 的 AI Agent 会话搜索场景。LLM 搜索听起来很"高级"，但实际体验远不如一个成熟的全文索引。
2. 成本结构决定产品生死
如果你在做一个面向 B 端的 Agent 产品，每个用户每天搜索 20 次 = $6/天 = $180/月。100 个客户就是 $18,000/月的纯搜索成本。这个成本结构根本无法规模化。
Hermes 的做法是：先问"用户到底需要什么"，而不是"怎么用 LLM 解决"。用户需要的是快速找到历史会话中的某段对话——这本质上是一个全文检索问题，不需要语义理解。
3. 前缀缓存 + FTS5 = 完整降本方案
配合同日提交的 4a3f13b（系统提示词日期从分钟精度改为日期精度），Hermes 实现了：
- 提示词层面：前缀缓存全天命中，不再因分钟变化失效
- 搜索层面：FTS5 替代 LLM，搜索零成本
这两个改动加起来，一个重度用户每天可以省下 $50-100 的 Token 费用。对一人公司而言，这是真实可感的利润。
行动建议
- 检查你的 Agent 搜索实现：是否每次搜索都调 LLM？如果是，估算日/月成本
- 评估 FTS5 是否适用：如果你的搜索场景是"通过关键词找历史记录"，FTS5 大概率够用
- 建立"去 LLM 化"评估清单：每个功能上线前问一句——"这个真需要 LLM 吗？"
- 关注 Hermes 的 Provider 路由：结合多 Provider 架构，实现"简单任务用便宜模型 + 搜索用 FTS5 + 复杂推理用旗舰模型"的成本组合