作者：余慧清
www.bilibili.com/video/BV1XK...
7月26日，Elastic 在深圳腾讯滨海大厦办了一场 Meetup，Elastic 和腾讯云的工程师们从不同角度讲了同一件事：Elasticsearch 正在从搜索引擎变成 Agent 的基础设施。
四个主题依次覆盖了 Agent 基础设施的三个核心层面：
-
AI 驱动的搜索能力：混合搜索如何让 Agent 精准找到答案
-
千亿级向量数据的工程突破：毫秒级响应如何在规模化场景下落地
-
Agent 三大工程的设计取舍：从 Prompt 到 Harness 的完整框架
-
知识库架构实战：腾讯 KInfra 团队的真实落地经验
混合搜索解决 "找得到" 的问题，长期 记忆 解决 "记得住" 的问题，工程化框架解决 "跑得稳" 的问题。从检索能力到记忆架构再到工程落地，四个主题串联起来，恰好勾勒出 Elasticsearch 向 Agent 基础设施转型的完整路径 ------这 也是这篇文章标题的由来。
01 混合搜索：Agent 怎么 "找" 到正确答案
Agent 回答问题时，答案质量往往不取决于模型能力，而取决于检索质量。模型再强，如果从知识库里召回的内容不对，输出的答案就会 "差那么一点"------方向对了，但关键细节有误，或者漏了最重要的那条信息。
传统的关键词搜索（BM25）擅长精准匹配。搜"Elasticsearch 8.x"，它能找出所有包含这几个词的文档。但 BM25 不理解语义------问"怎么让搜索更聪明"，它找不到标题叫"语义检索实践"的文档，因为字面不匹配。
向量搜索解决了这个问题。它把文本转换为一组数值（向量），语义相近的内容在向量空间中距离也近。问"怎么让搜索更聪明"，它能找到"语义检索"的文档------因为含义接近。
但纯向量搜索也有盲区。当需要精确匹配一个产品型号、一个错误码、一个人名时， 向量检索 反而会把语义相近但不相关的结果混进来。
混合搜索的思路是：BM25 负责精准匹配，向量负责语义理解，然后用 RRF（Reciprocal Rank Fusion，倒数排名融合）将两路结果合并排序。BM25 保证精确性，向量保证召回率，RRF 做融合排序，三者各司其职。
Elastic 把这套能力做成了开箱即用的功能。自研的 ELSER 模型（稀疏向量编码器）可以在索引阶段自动生成向量，开发者不需要自行搭建 embedding 管道。Semantic Text 字段类型更进一步------写入文本即可自动完成分块、向量化、索引，一行配置完成从原始文本到可检索向量的全流程。
规模化场景下还有另一层挑战。千亿级向量数据意味着内存无法全部容纳，磁盘 IO 成为瓶颈。腾讯云 ES 在这个场景下采用了 DiskBBQ（磁盘级 BBQ 量化）技术，将向量从 32 位浮点压缩到 1 位二值，存储占用降低一个数量级，同时检索精度损失可控。
混合搜索解决了"找得准"的问题，量化压缩解决了"扛得住"的问题。两者结合，才构成 Agent 检索环节的完整能力。
02 长期记忆：Agent 的记忆不该住在 SQLite 里
当前大多数 Agent 框架的记忆系统，底层实现就是一个 SQLite 文件。
SQLite 本身没有问题------单机够快，零配置，本地验证完美。但 Agent 一旦进入生产环境，局限性就暴露了：多个 Agent 实例之间无法共享记忆，重启后记忆可能丢失，记忆数据无法水平扩展，也无法做复杂的语义检索 ------ 只能按时间戳翻聊天记录，无法按 "上次关于向量检索的那段对话" 来检索。
将 Agent 记忆从 SQLite 迁移到 Elasticsearch，是一个合理的工程选择。ES 天然支持全文检索和向量检索的混合查询，可以按语义检索历史对话；ES 是分布式的，支持水平扩展；ES 有成熟的租户隔离机制，不同用户、不同 Agent 的记忆可以隔离存储。
一个可行的三层记忆架构：
- Chat Memory（对话记忆）：短期工作记忆，记录当前会话的上下文
- Workflow Memory（流程记忆）：中期技能记忆，记录 Agent 学会的操作流程和工具使用方式
- Knowledge Memory（知识记忆）：长期知识记忆，记录从所有对话中沉淀的事实和洞察
这三层对应不同的记忆生命周期和检索需求。对话记忆频繁读写、快速过期；流程记忆中等频率更新、跨会话复用；知识记忆低频写入、长期积累、需要语义检索。用 ES 的不同索引承载不同层级的记忆，配合不同的保留策略和检索方式，可以构建一个结构化的 Agent 记忆系统。
将记忆从 SQLite 搬到 ES，本质上是让 Agent 从 "重启后丢失所有上下文" 的临时状态，转变为能跨会话积累经验的持久状态。 对生产环境的 Agent 来说，这是一个基础能力。
03 工程化框架：从 Prompt 到 Harness 的三道关
Agent 在演示中表现惊艳，进入生产环境后却往往不稳定------这是行业内的普遍现象。问题的根源在于，从演示到生产之间有三道工程关卡需要跨越。
第一关：Prompt Engineering（提示词工程）
让 Agent 理解任务意图。提示词模板、 few-shot 示例、思维链技巧等方法已经积累了大量实践，但这只是起点 ------ 它解决的是 "Agent 能不能听懂你要什么"。
第二关：Context Engineering（上下文工程）
给 Agent 正确的信息，而不是所有信息。Agent 的 上下文窗口 有限，塞太多无关内容会干扰判断，塞太少又不够用。核心问题是如何从海量数据中精确选出"这一刻 Agent 需要的那几段"。
混合搜索在这一环节发挥作用 ------ 用 BM25 + 向量 + RRF 从知识库召回最相关的内容，再经过重排序和 截断 ，控制进入上下文窗口的信息量和质量。上下文工程做不好，Agent 的回答要么跑题，要么信息不足。
第三关：Harness Engineering（编排工程）
让 Agent 的行为可控、可观测、可纠错。Agent 不是直线执行的脚本，它会在运行过程中做决策、调用工具、处理异常。Harness 就是控制层------管理自由度和控制权的平衡。
生产级 Agent 的结构需求可以概括为三个维度：
- 看得见：Agent 的状态可观测------在做什么、调用了什么工具、消耗了多少 token、卡在哪一步，对开发者透明
- 会干活：Agent 能真正执行任务------不只生成文本，还能调用 API、操作数据库、读写文件
- 选得对：Agent 能在多个工具和路径中做出合理选择------根据当前上下文动态决策，而不是每次走同一条路径
这三道关不是递进关系，而是同时存在。只过第一关的 Agent 停留在演示阶段，过了前两关的是半成品，三关都过了才能进入生产环境。
04 落地样本：腾讯 KInfra 怎么用 ES 做知识库
腾讯 ima 知识库是一个面向 C 端用户的 AI 知识管理产品，底层架构由腾讯 KInfra 团队负责。用户将自己的文档、笔记、网页收藏导入知识库，通过对话进行检索和问答。
场景看似简单，但规模一大就全是工程问题。
向量存储成本。 文档量增长后，向量存储的内存开销难以承受。KInfra 采用 BBQ（Better Binary Quantization）量化技术，将向量从浮点压缩到二值，内存占用大幅下降，同时通过多路召回 + 重排序保证精度不丢。
检索准确率。 用户问"上个季度的营收数据"，如果返回的是三年前的财报，就是检索出了问题。解法仍然是混合搜索------BM25 负责关键词精准匹配，向量负责语义理解，RRF 融合排序。
架构层面的优化：
-
分片策略按租户维度切分，避免大租户的查询拖慢小租户
-
索引设计区分热数据和冷数据，热数据放 SSD，冷数据下沉到对象存储
这些都是朴素的工程决策，没有花哨的概念。但组合在一起，就是一个能支撑千万级用户的知识库系统。
ima 的实践恰好验证了前面三个层面的技术逻辑：混合搜索是检索地基，记忆工程是数据骨架，编排框架是运行神经系统。三层结构在真实产品中得到了印证。
写在最后
Elasticsearch 正在从一个搜索引擎变成 Agent 的基础设施。
它曾经的工作模式是：输入关键词，返回文档列表。现在它要做的是：理解语义、记住上下文、支持复杂检索、支撑 Agent 的长期运行。搜索只是入口，后面还接着记忆、编排、 工具调用 。
搜索引擎的下一站，是 Agent 基础设施。
这不只是 Elastic 一家的方向。当 AI Agent 成为应用的新形态，它需要的后端不再是一个返回链接列表的搜索框，而是一个能理解语义、记住上下文、支持复杂检索的系统。Elasticsearch 正在这个方向上快速演进 ------ ELSER、Semantic Text、BBQ 量化、三层记忆架构、Harness 工程框架，每一项都是搜索引擎向 Agent 基础设施转型的具体落点。
如果你正在搭建 Agent，Elasticsearch 值得重新评估。它可能比你以为的能做的更多。
你们团队用什么方案做 Agent 的检索和记忆？来评论区聊聊。