OpenSearch 不再试图成为更好的 Elasticsearch

Source: Dev.to

如果你接手了一个 OpenSearch 部署，并且现在被要求在其上运行代理，2026 年第一季度的消息格外振奋人心。OpenSearch 3.5（2 月）和 3.6（4 月）并非只是增量的搜索改进——它们是一次明确的意图宣示。

“OpenSearch 并不是想成为更好的 Elasticsearch；它专注于成为 AI 应用构建的数据层。”
— 作者、从日志分析迁移到语义检索团队的工程师

实际发生了什么变化

• 更好的二进制量化（BBQ）已在 3.6 中落地 – 来自 Lucene 项目的集成，BBQ 将高维浮点向量压缩为紧凑的二进制表示，约可实现 32 倍的内存缩减。在 Cohere‑768‑1M 基准测试中，BBQ 在 100 条结果下的召回率为 0.63，而 Faiss Binary Quantization 为 0.30。配合过采样和重打分后，在大规模生产数据集上可超过 0.95。项目正努力将其设为默认方案。

• 稀疏向量搜索获得了生产级工具 – SEISMIC 算法实现了神经稀疏近似最近邻搜索，无需全索引扫描。大多数生产 AI 检索流水线现在采用混合模式（密集语义召回 + 稀疏神经精确），而 3.6 正是围绕这一模式构建的。

• 代理记忆现在是平台层面的功能，而非 DIY 问题 – 在 3.5 之前，多轮代理记忆需要外部会话存储和自定义上下文接线。3.5 将对话记忆迁入 ML Commons，提供基于 Hook 的 API。3.6 新增语义和混合搜索 API，使代理能够通过向量相似度或关键词匹配检索上下文相关的历史对话，而不局限于最近一次轮次。

• 令牌使用跟踪，终于来了 – 代理执行期间的每一次 LLM 调用现在都会自动记录（每轮、每模型的令牌计数），无需任何配置。支持 Amazon Bedrock Converse、OpenAI v1 和 Gemini v1beta。这样即可即时看到代理的成本。

• MCP 支持已落地 – 3.6 中的 opensearch-agent-server 增加了多代理编排，并集成了 Model Context Protocol。MCP 已成为 AI 系统与外部工具、数据源通信的标准，表明 OpenSearch 的目标是成为代理工具生态的完整参与者，而不仅仅是向量存储后端。

为什么重要

OpenSearch 正在系统性地吸收团队过去在平台外解决的问题——代理记忆、令牌成本可观测性、多步代理执行的分布式追踪（通过 OpenTelemetry 的 APM 已内置在 Dashboards 中）。每吸收一个问题，都会提升切换成本，使 OpenSearch 在 AI 应用栈中的黏性增强。

MCP 集成是最具战略意义的部分。它不仅是功能对齐，更是将 OpenSearch 与更广泛的代理生态系统连接起来的“粘合剂”。

该怎么做

• 已经在使用 OpenSearch 做日志或普通搜索？ 升级到 3.6 并基准测试 BBQ——仅凭内存节省就可能值得升级。
• 正在构建代理，却还未决定记忆层？ 在自行部署向量库之前，先阅读 3.5/3.6 的 ML Commons 文档。
• 在生产环境运行代理但看不到成本？ 3.6 的令牌跟踪零配置，只需升级即可。
• 在你的代理栈中使用 MCP？ 评估 opensearch-agent-server 的集成，以便在 OpenSearch 持有的数据上为代理提供 grounding。

Source: Inside OpenSearch’s bid to become the default AI data layer — The New Stack