当AI Agent遇到搜索——用LLM做搜索还是用数据库做搜索？Hermes Agent用一次完整重写给出了答案：4500倍提速、搜索成本归零。这对每位靠Agent挣钱的人来说，都是一个值得抄作业的降本样板。
事件回顾
5月18日凌晨，Hermes Agent核心开发者teknium1提交了commit abf1af5，用SQLite内置的FTS5全文搜索引擎彻底替代了原有的LLM搜索链路。
之前的方案看起来很"AI"：每次用户搜索历史会话时，LLM先生成摘要、存向量、做语义检索——全程约90秒，每次花费$0.30。如果每天搜100次，就是$30的账单加上2.5小时的等待。
新方案出奇地朴素：SQLite FTS5全文索引，200行代码，20毫秒完成搜索，成本为零。
三种调用模式覆盖所有搜索场景：Discovery（关键词全文搜索）、Scroll（基于锚点翻页）、Browse（最近N个会话列表）。不是渐进式优化，是架构选择带来的4500倍提速。
为什么重要
这件事对AI创业者有三个层次的启示：
第一，"能用SQL解决的，别用LLM"正在成为工程新圣经。 FTS5是SQLite从2015年就内置的功能——布尔查询、前缀匹配、短语搜索，覆盖95%的会话搜索场景。LLM搜索听起来很酷，但实际体验远不如一个成熟的全文索引。Hermes的这一改动不是特例，而是一个信号：AI产品的工程团队正在回归"先想清楚用户到底需要什么"，而不是"什么地方能用LLM"。
第二，Token成本的隐性陷阱比你想象的更深。 如果你在做面向B端的Agent产品，每个用户每天搜20次，就是$6/天、$180/月的纯搜索成本。100个客户就是$18,000/月。这个成本结构根本无法规模化。Hermes的做法本质上是一次成本审计——审计后发现85%的"AI功能"实际上可以用传统数据库技术替代，且体验更好。
第三，前缀缓存+去LLM化=降本组合拳。 Hermes同日还提交了系统提示词日期精度从分钟级改为日期级，让前缀缓存全天命中。两处修改加起来，重度用户每天可省$50-100。对一人公司创业者，这笔钱直接从利润里省出来的。
我们能学到什么
1. 审查你的Agent搜索实现。 如果每次搜索都在调LLM，先算一笔账：日搜索量×单次成本×30天，这个数字很可能让你睡不着觉。
2. FTS5几乎适用于所有"关键词搜索历史记录"场景。 无论你是做Agent产品还是内部工具，SQLite FTS5的部署成本近乎零，效果远超预期。
3. 建立"去LLM化"评估清单。 每个功能上线前问一句：这个真需要LLM吗？还是FTS5、正则表达式、Bloom filter能更便宜、更快地解决？
行动建议
- 如果你在用Hermes Agent v0.14.0+，只需在config.yaml中启用session_search即可体验FTS5搜索
- 如果你是Agent产品开发者，立即审查你的搜索/检索链路，计算LLM搜索的隐形成本
- 建立成本监控机制：将"每次LLM调用"视为有成本的资源，而不是免费能力
- 将这个案例分享给你的技术团队——去LLM化的降本路径正在成为AI产品的核心竞争力