作者余慧清https://www.bilibili.com/video/BV1XKg96PEL6/7月26日Elastic 在深圳腾讯滨海大厦办了一场 MeetupElastic 和腾讯云的工程师们从不同角度讲了同一件事Elasticsearch 正在从搜索引擎变成 Agent 的基础设施。四个主题依次覆盖了 Agent 基础设施的三个核心层面AI 驱动的搜索能力混合搜索如何让 Agent 精准找到答案千亿级向量数据的工程突破毫秒级响应如何在规模化场景下落地Agent 三大工程的设计取舍从 Prompt 到 Harness 的完整框架知识库架构实战腾讯 KInfra 团队的真实落地经验混合搜索解决 找得到 的问题长期记忆解决 记得住 的问题工程化框架解决 跑得稳 的问题。从检索能力到记忆架构再到工程落地四个主题串联起来恰好勾勒出 Elasticsearch 向 Agent 基础设施转型的完整路径 ——这 也是这篇文章标题的由来。01 混合搜索Agent 怎么 找 到正确答案Agent 回答问题时答案质量往往不取决于模型能力而取决于检索质量。模型再强如果从知识库里召回的内容不对输出的答案就会 差那么一点——方向对了但关键细节有误或者漏了最重要的那条信息。传统的关键词搜索BM25擅长精准匹配。搜Elasticsearch 8.x它能找出所有包含这几个词的文档。但 BM25 不理解语义——问怎么让搜索更聪明它找不到标题叫语义检索实践的文档因为字面不匹配。向量搜索解决了这个问题。它把文本转换为一组数值向量语义相近的内容在向量空间中距离也近。问怎么让搜索更聪明它能找到语义检索的文档——因为含义接近。但纯向量搜索也有盲区。当需要精确匹配一个产品型号、一个错误码、一个人名时向量检索反而会把语义相近但不相关的结果混进来。混合搜索的思路是BM25 负责精准匹配向量负责语义理解然后用 RRFReciprocal 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 采用 BBQBetter Binary Quantization量化技术将向量从浮点压缩到二值内存占用大幅下降同时通过多路召回 重排序保证精度不丢。检索准确率。用户问上个季度的营收数据如果返回的是三年前的财报就是检索出了问题。解法仍然是混合搜索——BM25 负责关键词精准匹配向量负责语义理解RRF 融合排序。架构层面的优化分片策略按租户维度切分避免大租户的查询拖慢小租户索引设计区分热数据和冷数据热数据放 SSD冷数据下沉到对象存储这些都是朴素的工程决策没有花哨的概念。但组合在一起就是一个能支撑千万级用户的知识库系统。ima 的实践恰好验证了前面三个层面的技术逻辑混合搜索是检索地基记忆工程是数据骨架编排框架是运行神经系统。三层结构在真实产品中得到了印证。写在最后Elasticsearch 正在从一个搜索引擎变成 Agent 的基础设施。它曾经的工作模式是输入关键词返回文档列表。现在它要做的是理解语义、记住上下文、支持复杂检索、支撑 Agent 的长期运行。搜索只是入口后面还接着记忆、编排、工具调用。搜索引擎的下一站是 Agent 基础设施。这不只是 Elastic 一家的方向。当 AI Agent 成为应用的新形态它需要的后端不再是一个返回链接列表的搜索框而是一个能理解语义、记住上下文、支持复杂检索的系统。Elasticsearch 正在这个方向上快速演进 —— ELSER、Semantic Text、BBQ 量化、三层记忆架构、Harness 工程框架每一项都是搜索引擎向 Agent 基础设施转型的具体落点。如果你正在搭建 AgentElasticsearch 值得重新评估。它可能比你以为的能做的更多。你们团队用什么方案做 Agent 的检索和记忆来评论区聊聊。原文Elasticsearch 转型为 Agent 基础设施混合搜索、长期记忆与工程化框架
作者余慧清https://www.bilibili.com/video/BV1XKg96PEL6/7月26日Elastic 在深圳腾讯滨海大厦办了一场 MeetupElastic 和腾讯云的工程师们从不同角度讲了同一件事Elasticsearch 正在从搜索引擎变成 Agent 的基础设施。四个主题依次覆盖了 Agent 基础设施的三个核心层面AI 驱动的搜索能力混合搜索如何让 Agent 精准找到答案千亿级向量数据的工程突破毫秒级响应如何在规模化场景下落地Agent 三大工程的设计取舍从 Prompt 到 Harness 的完整框架知识库架构实战腾讯 KInfra 团队的真实落地经验混合搜索解决 找得到 的问题长期记忆解决 记得住 的问题工程化框架解决 跑得稳 的问题。从检索能力到记忆架构再到工程落地四个主题串联起来恰好勾勒出 Elasticsearch 向 Agent 基础设施转型的完整路径 ——这 也是这篇文章标题的由来。01 混合搜索Agent 怎么 找 到正确答案Agent 回答问题时答案质量往往不取决于模型能力而取决于检索质量。模型再强如果从知识库里召回的内容不对输出的答案就会 差那么一点——方向对了但关键细节有误或者漏了最重要的那条信息。传统的关键词搜索BM25擅长精准匹配。搜Elasticsearch 8.x它能找出所有包含这几个词的文档。但 BM25 不理解语义——问怎么让搜索更聪明它找不到标题叫语义检索实践的文档因为字面不匹配。向量搜索解决了这个问题。它把文本转换为一组数值向量语义相近的内容在向量空间中距离也近。问怎么让搜索更聪明它能找到语义检索的文档——因为含义接近。但纯向量搜索也有盲区。当需要精确匹配一个产品型号、一个错误码、一个人名时向量检索反而会把语义相近但不相关的结果混进来。混合搜索的思路是BM25 负责精准匹配向量负责语义理解然后用 RRFReciprocal 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 采用 BBQBetter Binary Quantization量化技术将向量从浮点压缩到二值内存占用大幅下降同时通过多路召回 重排序保证精度不丢。检索准确率。用户问上个季度的营收数据如果返回的是三年前的财报就是检索出了问题。解法仍然是混合搜索——BM25 负责关键词精准匹配向量负责语义理解RRF 融合排序。架构层面的优化分片策略按租户维度切分避免大租户的查询拖慢小租户索引设计区分热数据和冷数据热数据放 SSD冷数据下沉到对象存储这些都是朴素的工程决策没有花哨的概念。但组合在一起就是一个能支撑千万级用户的知识库系统。ima 的实践恰好验证了前面三个层面的技术逻辑混合搜索是检索地基记忆工程是数据骨架编排框架是运行神经系统。三层结构在真实产品中得到了印证。写在最后Elasticsearch 正在从一个搜索引擎变成 Agent 的基础设施。它曾经的工作模式是输入关键词返回文档列表。现在它要做的是理解语义、记住上下文、支持复杂检索、支撑 Agent 的长期运行。搜索只是入口后面还接着记忆、编排、工具调用。搜索引擎的下一站是 Agent 基础设施。这不只是 Elastic 一家的方向。当 AI Agent 成为应用的新形态它需要的后端不再是一个返回链接列表的搜索框而是一个能理解语义、记住上下文、支持复杂检索的系统。Elasticsearch 正在这个方向上快速演进 —— ELSER、Semantic Text、BBQ 量化、三层记忆架构、Harness 工程框架每一项都是搜索引擎向 Agent 基础设施转型的具体落点。如果你正在搭建 AgentElasticsearch 值得重新评估。它可能比你以为的能做的更多。你们团队用什么方案做 Agent 的检索和记忆来评论区聊聊。原文Elasticsearch 转型为 Agent 基础设施混合搜索、长期记忆与工程化框架
