OpenSearch isn’t trying to be a better Elasticsearch anymore

OpenSearch 不再试图成为更好的 Elasticsearch

If you inherited an OpenSearch deployment and you’re now being asked to run agents on it, Q1 2026 has been unusually good news. OpenSearch 3.5 (February) and 3.6 (April) aren’t incremental search improvements — they’re a clear declaration of intent. “OpenSearch isn’t trying to be a better Elasticsearch; it is focused on being the data layer on which AI applications are built.” That’s from the article’s author, an engineer who’s been migrating teams from log analytics to semantic retrieval. It also captures the entire roadmap.

如果你接手了一个 OpenSearch 部署，并且现在被要求在其上运行智能体（Agents），那么 2026 年第一季度的消息对你来说格外利好。OpenSearch 3.5（2 月）和 3.6（4 月）版本并非简单的搜索功能增量改进，而是一个明确的意图声明。“OpenSearch 不再试图成为更好的 Elasticsearch；它正专注于成为构建 AI 应用的数据层。” 这段话出自本文作者，一位一直致力于将团队从日志分析迁移到语义检索的工程师。这也概括了其整个路线图。

What actually changed? Better Binary Quantization (BBQ) landed in 3.6. Integrated from the Lucene project, BBQ compresses high-dimensional float vectors into compact binary representations — 32x memory reduction. On the Cohere-768-1M benchmark, BBQ recall at 100 results hits 0.63 vs. 0.30 for Faiss Binary Quantization. With oversampling and rescoring, it exceeds 0.95 on large production datasets. The project is working to make this the default.

具体有哪些变化？Better Binary Quantization (BBQ) 在 3.6 版本中正式落地。BBQ 集成自 Lucene 项目，能将高维浮点向量压缩为紧凑的二进制表示，内存占用减少了 32 倍。在 Cohere-768-1M 基准测试中，BBQ 在 100 个结果下的召回率为 0.63，而 Faiss 二进制量化仅为 0.30。通过过采样和重排序，在大规模生产数据集上，其召回率可超过 0.95。该项目正致力于将其设为默认配置。

Sparse vector search got production-scale tooling. The SEISMIC algorithm enables neural sparse approximate nearest-neighbor search without a full index scan. Most production AI search pipelines land on the hybrid pattern — dense semantic recall + sparse neural precision — and 3.6 is explicitly built around that.

稀疏向量搜索获得了生产级工具支持。SEISMIC 算法实现了无需全索引扫描的神经稀疏近似最近邻搜索。大多数生产级 AI 搜索流水线都采用混合模式——即“稠密语义召回 + 稀疏神经精确匹配”——而 3.6 版本正是围绕这一模式构建的。

Agent memory is now a platform concern, not a DIY problem. Before 3.5, multi-turn agent memory meant maintaining a session store outside OpenSearch and wiring context management yourself. 3.5 moved conversation memory into ML Commons with hook-based APIs. 3.6 went further: new semantic and hybrid search APIs let agents retrieve contextually relevant prior exchanges via vector similarity or keyword matching — not just the most recent turn.

智能体记忆现在已成为平台关注的问题，而非需要自行解决的难题。在 3.5 版本之前，多轮智能体记忆意味着必须在 OpenSearch 之外维护一个会话存储，并自行编写上下文管理逻辑。3.5 版本通过基于钩子（hook-based）的 API 将对话记忆引入了 ML Commons。3.6 版本更进一步：新的语义和混合搜索 API 允许智能体通过向量相似度或关键词匹配来检索上下文相关的过往交流，而不仅仅是最近的一轮对话。

Token usage tracking, finally. Every LLM call during agent execution is now instrumented — per-turn, per-model token counts, no configuration required. Supports Amazon Bedrock Converse, OpenAI v1, and Gemini v1beta. If you’ve been flying blind on what your agents cost to run, this is a free upgrade.

Token 使用量追踪功能终于上线了。智能体执行过程中的每一次 LLM 调用现在都会被监测——无需任何配置，即可获得每轮、每个模型的 Token 计数。支持 Amazon Bedrock Converse、OpenAI v1 和 Gemini v1beta。如果你之前对智能体的运行成本一无所知，这是一个免费的升级。

MCP support landed. The opensearch-agent-server in 3.6 adds multi-agent orchestration with Model Context Protocol integration. MCP has become the standard for how AI systems communicate with external tools and data sources. Its inclusion signals that OpenSearch wants to be a full participant in agentic tooling ecosystems, not just a backend that happens to store vectors.

MCP 支持已落地。3.6 版本中的 opensearch-agent-server 增加了通过 Model Context Protocol (MCP) 集成的多智能体编排功能。MCP 已成为 AI 系统与外部工具及数据源通信的标准。它的加入表明 OpenSearch 希望成为智能体工具生态系统的全面参与者，而不仅仅是一个恰好存储向量的后端。

Why it matters: OpenSearch is systematically absorbing problems that teams were solving outside the platform — agent memory, token cost observability, distributed tracing for multi-step agent execution (APM on OpenTelemetry is now built in via Dashboards). Each absorbed problem raises the switching cost and makes OpenSearch stickier in the AI application stack. The MCP integration is the most strategic piece. It’s not feature parity. It’s connective tissue.

为什么这很重要：OpenSearch 正在系统性地吸收那些团队过去需要在平台之外解决的问题——智能体记忆、Token 成本可观测性、多步智能体执行的分布式追踪（通过 Dashboards 内置了基于 OpenTelemetry 的 APM）。每一个被吸收的问题都提高了切换成本，并使 OpenSearch 在 AI 应用技术栈中更具粘性。MCP 集成是其中最具战略意义的部分。这不仅仅是功能对齐，更是连接组织。

What to do: Already running OpenSearch for logs or search? Upgrade to 3.6 and benchmark BBQ — the memory savings alone may justify the upgrade. Building agents and haven’t picked a memory layer? Read the 3.5/3.6 ML Commons docs before you spin up a separate vector store. Running agents in production without cost visibility? Token tracking in 3.6 requires zero config. Just upgrade. Using MCP in your agentic stack? The opensearch-agent-server integration is worth evaluating for grounding agents in OpenSearch-held data.

建议：已经在用 OpenSearch 处理日志或搜索了吗？升级到 3.6 并对 BBQ 进行基准测试——仅内存节省一项就足以证明升级的价值。正在构建智能体但还没选定记忆层？在启动独立的向量存储之前，请阅读 3.5/3.6 的 ML Commons 文档。在生产环境中运行智能体却缺乏成本可见性？3.6 中的 Token 追踪无需任何配置，直接升级即可。在你的智能体技术栈中使用 MCP？值得评估 opensearch-agent-server 的集成，以便让智能体基于 OpenSearch 中存储的数据进行落地（Grounding）。

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