作者：来自 Elastic Greg Crist
能够记忆的 AI agents。比 Prometheus 快 30 倍。一个索引覆盖所有媒体。以下是 Elastic 在 2026 年发布的内容。
到目前为止，Elastic 在 2026 年已经发布了四项进展，这些进展改变了你的搜索能力以及我们的 AI 技术栈所能实现的功能。
Elastic 推理服务（ Elastic Inference Service，EIS ）现已支持 jina-embeddings-v5-omni，它可以将文本、图像、视频和音频统一存储在同一个 Elasticsearch 索引中，并支持近 100 种语言。
Elastic Agent Builder发布了上下文管理（ context management ）、技能（ skills ）以及企业连接器（ enterprise connectors ），使 AI agents 能够在长对话中保持准确性并可扩展运行。
重构后的指标引擎（ metrics engine ）以每个数据点 3.75 字节的方式存储 OpenTelemetry（ OTel ）数据，并且查询速度比早期 Elasticsearch TSDS 快 160 倍。
Elastic Security Labs 开源了一个CI/CD 流水线检测器（ CI/CD pipeline detector ），可以在 GitHub Actions 和 Azure DevOps 攻击者进入生产环境之前将其捕获。
通过这篇博客了解我们在 2026 年发布的全部内容。
2026 年 Elastic 成为 Azure 开发者平台的 4 个原因
1. Elasticsearch 现已成为 Azure AI Foundry 构建的 agents 的检索层
AI agents 在生产环境中最常见的失败原因是上下文问题 —— 在推理时刻传递给 agent 的数据是错误的、过时的，或者根本不存在。Elastic 9.4 通过 Agent Builder 的三项生产级能力解决了这一问题，目前已正式可用：
Skills（技能）：
指令包可以按需由 agent 加载，使其具备领域专业能力，而无需膨胀每个上下文窗口。目前已发布五个面向安全运营的专用 skills，五个面向 SRE（站点可靠性工程）工作流的 skills，并且还有更多正在开发中。
原生 Microsoft 365 连接器：
SharePoint 和 Drive 的内容通过语义元数据层直接进入 agent 上下文。企业语料库成为检索基础设施，而 Elasticsearch 成为索引层。
大规模上下文管理（ context management ）：
查询结果卸载、压缩（ compaction ）与摘要（ summarization ）机制，使长时间、多轮对话中的 agent 在生产环境中保持准确性与成本效率。
GPU 加速索引与向量性能优化
通过 NVIDIA cuVS 实现的 GPU 加速索引在 Elastic 9.4 中已正式可用，使索引吞吐量提升 12 倍。DiskBBQ（ Elastic 的向量索引算法）在带有严格过滤条件的查询中，将查询延迟至少降低 3 倍。
对于在 Azure 上运行高基数 embedding 工作负载的 AI 应用，这种基础设施优势会直接体现在延迟与成本上。
Azure AI 深度集成
Microsoft Azure AI 集成在 Elasticsearch Labs 生态中是一级能力（ first-class citizen ）。如果你使用 Azure OpenAI Service 或 Azure AI Foundry 模型，Elasticsearch 已经可以作为检索骨干层使用，内置 hybrid search（BM25 + 向量）、reranking 和上下文工程（ context engineering ）能力。
ES|QL TypeScript / JavaScript 开发体验升级
对于 Azure 生态中的 TypeScript 和 JavaScript 开发者，Elastic 在 2026 年 4 月发布了一个类型安全的 ES|QL 查询构建器（ fluent ES|QL query builder ）。
它带来：
类型安全的查询构建体验
不再需要原始字符串拼接 SQL/ES|QL 查询
消除字段名拼写错误导致的运行时问题
const query = esql .from('logs-*') .where('event.category', '==', 'authentication') .stats('count(*)', { by: ['user.name', 'host.name'] }) .sort('count(*)', 'desc') .limit(10);你 agent 接触的所有媒体类型，一个索引统一处理
Microsoft 365 内容不仅仅是文本。SharePoint 文档库中包含 PDF、演示文稿以及扫描图像。Teams 记录会议录音。Azure Blob Storage 存放产品图片、培训视频，以及客户通话音频文件。直到现在，为每一种数据类型建立索引都需要单独的模型和独立的处理管道。
jina-embeddings-v5-omni 由 Elastic 推理服务（ Elastic Inference Service ）托管，它将文本、图像、视频和音频统一到同一个 Elasticsearch 索引中。一次查询就能跨所有媒体类型同时检索语义相关内容，并覆盖近 100 种语言。该模型提供 small 和 nano 两种尺寸版本，均针对标准 GPU 硬件进行了优化。
对于已有文本索引的开发者，jina-embeddings-v5-omni 生成的文本 embedding 与 jina-embeddings-v5-text 完全一致。这意味着你可以在不重建索引的情况下，将现有文本索引扩展为支持图像、音频和视频。通过启用 Elasticsearch BBQ 量化，在嵌入性能损失不到 3% 的情况下，可以节省 93% 的存储空间。
注意：jina-embeddings-v5-omni 仅在 CC-BY-NC-4.0 许可下可用于非商业评估。商业部署请联系 Elastic 销售。
2. Elastic 现在已进入 VS Code、Cursor 和 GitHub Copilot
在 2026 年 4 月，Elastic 发布了 MCP Apps —— 一种可在 AI 对话中直接渲染的交互式 UI，它基于 MCP App 标准构建，该标准由 Anthropic 和 OpenAI 共同制定。三款 MCP Apps 同时发布：安全（security）、可观测性（observability）以及搜索（search）。这三者均可在VS Code Copilot、Cursor和Claude Desktop中原生运行。
Elastic Security MCP App 在编码环境中无需离开聊天界面，即可内联渲染六个交互式安全运营中心（SOC）仪表盘：
- 交互式 UI：告警分诊（ Alert Triage ）：获取、过滤并分类安全告警。提供严重性分组、AI 判断卡片、进程树以及网络事件。
- 攻击发现（ Attack Discovery ）：基于 AI 的攻击链关联分析，并支持按需生成。包含攻击叙事卡片、置信度评分、实体风险以及 MITRE 映射。
- 案例管理（ Case management ）：创建、搜索并管理调查案例。提供案例列表（包含 alerts、observables、comments 标签页）以及 AI 操作能力。
- 检测规则（ Detection rules ）：浏览、调优并管理检测规则。提供规则浏览器、KQL 搜索、查询验证以及噪声规则分析。
- 威胁狩猎（ Threat hunt ）：基于 ES|QL 的工作台，用于实体调查。包含查询编辑器、可点击实体以及调查图谱。
- 样本数据（ Sample data ）：为常见攻击场景生成 ECS 安全事件。提供场景选择器以及四种预构建攻击链。
所有操作都会通过同一套 Elasticsearch 和 Kibana API 写回系统，使用的是产品原生接口。基于现有 Elasticsearch API key 实现基于角色的访问控制（ RBAC ）。安装方式为一个 .mcpb bundle 双击即可完成，无需新增基础设施，也无需新的治理模型。
Kubernetes Observability MCP App 将 AKS 调查能力直接带入 VS Code。当 pod 崩溃时，AI coding agent 可以直接查询根因、展示结构化证据，并推荐下一步操作，而无需打开任何 dashboard。
所有 bundle 都可以从最新 GitHub release 中安装。
3. Elasticsearch 现在是生产级列式指标引擎
Azure 已全面采用 OpenTelemetry。Azure Monitor、AKS、Azure Functions 以及 Azure AI Foundry 都原生输出 OpenTelemetry 协议（ OTLP ）数据。如果你已经在收集 Azure 工作负载的 OTel telemetry，那么关键问题是：这些数据落在哪里，以及在凌晨 2 点发生故障时你能多快查询到它。
Elastic 在 2026 年从底层重构了 Elasticsearch 的 metrics 引擎，结果非常显著。新的列式指标引擎以每个数据点 3.75 bytes的方式存储 OTel metrics —— 相比一年前的 25 bytes 提升了6.6 倍存储效率。与早期 Elasticsearch TSDS 相比，查询性能最高提升160 倍。OTel 数据的索引吞吐量提升最高达50%。
支撑这些指标的架构改造分为三层：
- 完全列式存储（ fully columnar storage ）：Elastic 用 doc value skippers 替代了倒排索引和 BKD tree（用于维度字段），这是一种 Lucene 原生结构，可以强化列式布局并消除重复索引开销。每个字段都存储在独立文件中，没有行级跟踪，也没有存储膨胀。
- 向量化 ES|QL 计算引擎（ vectorized ES|QL compute engine ）：新的 TS source 命令（在 Elastic 9.4 中 GA）使用双层模型执行时序聚合：内层针对每个 time series 执行聚合（如 RATE() 或 AVG_OVER_TIME()），外层再对结果进行聚合。计算引擎按 time series 排序顺序处理数据，并直接以零拷贝方式解码为原始数组。counter rate、gauge average 和 window 查询都支持并行向量化执行。
- 原生 OTLP ingestion：一个专用 OTLP protobuf 接入端点（Elastic 9.3 GA）可以直接接收 OpenTelemetry collector 数据，无需 JSON 转换层。基于维度的 hash 计算用于 time series ID 生成，在单个 protobuf message 内进行摊销，从而减少 20% 的索引开销。
对于已经使用 PromQL 仪表盘和告警规则的 Azure AKS 团队，Elastic 9.4 在 Kibana 中提供原生 PromQL 支持（技术预览）。现有查询无需修改即可运行。同一套 TSDS 存储和向量化计算引擎同时驱动 PromQL 与 ES|QL 查询。
结果是一个统一平台，覆盖 logs、metrics、traces 和 security data，无需维护独立后端，没有 cardinality 限制，也没有按 metric 计费。对于已经在生成 OTel 数据的 Azure 开发者，将数据写入 Elasticsearch 的存储成本更低，查询速度也比运行独立 metrics stack + 现有日志系统更快。
下面是一个用于 Azure AKS 工作负载的 ES|QL 时序查询示例：
TS metrics-hostmetricsreceiver.otel-default | WHERE TRANGE(4h) | STATS AVG(RATE(system.cpu.time)) BY host.name, TBUCKET(5m)4. Elastic 现在保护你构建的应用，包括部署它们的流水线
CI/CD 流水线在 2026 年已经成为主要攻击目标，并且直接针对 Azure 和 GitHub 开发者。
Elastic Security Labs 在 2026 年 4 月发布研究，揭示了一个在整个行业中反复出现的模式：攻击者不再专注于生产服务器，而是转而攻击用于部署这些服务器的自动化系统。在 2025 年 9 月，GhostAction 攻击活动通过注入恶意 workflow 文件，从 817 个 GitHub 仓库中窃取了3,325 个 secrets。2026 年 2 月，HackerBot-Claw 通过 GitHub Actions 配置错误入侵了 Aqua Security 的 Trivy 仓库，并通过该漏洞影响 7,000 台机器、暴露33,000 个 secrets，微软安全团队随后也对这一事件进行了记录。
Elastic Security Labs 开源了 cicd-abuse-detector —— 一个可直接插入 CI 的模板，它结合 50+ 信号提取模式以及大语言模型（ LLM ）推理能力，用于检测 GitHub Actions、GitLab CI 和Azure DevOpspipeline 中的可疑变更。它可以运行在标准 ubuntu-latest runner 上，无需 Python 依赖。检测结果会写入 Elasticsearch，用于跨平台关联分析：
FROM logs-cicd.abuse-* WHERE verdict.verdict IN ("malicious", "suspicious") AND @timestamp > NOW() - 7 days | EVAL platform = cicd.platform, repo = cicd.repository, actor = cicd.actor | SORT @timestamp DESC一次查询。所有平台。历史可查询。
对于Entra ID 和 Active Directory 环境，Elastic Security 9.4 提供了四项新的 Entity Analytics 能力，从数据模型层面解决身份噪声问题：
实体解析（ entity resolution ）：将 Okta、Microsoft Entra ID 和 Active Directory 统一为每个员工的单一已验证身份记录。（当攻击者使用同一身份在三个系统中横向移动时，Elastic 将其视为一个实体，而不是三个独立告警。）
动态观察列表（ dynamic watchlists ）：为 Azure 特权管理员、管理层以及核心业务服务账户注入风险倍数。
实体驱动的威胁狩猎线索（ entity-driven hunting leads ）：自动生成面向具体环境的主动威胁狩猎线索，而不是空白查询。
精确实体识别（ precision entity identification ）：在平台层自动治理身份统一。
对于Azure AI Foundry 和 LLM 应用，Elastic 在 9.1 中发布的 Azure AI Foundry 集成 将可观测性集中化：自动从 Azure AI Foundry 上运行的任意模型中收集 logs 和 metrics 并写入 Elasticsearch。
从这里开始，Elastic Observability 提供完整的分布式追踪（ distributed tracing ）能力，覆盖 agent chains，同时包含 token 成本追踪、延迟监控以及安全评估，使你能够清楚看到 agent 做了什么、成本是多少，以及在哪里出错。
对于使用GitHub Actions 和 Azure DevOps 管理 Kibana 的用户，Elastic 9.4 提供 Dashboards as Code —— 可通过 CI/CD 流水线部署的版本化 Kibana 仪表盘。
这些仪表盘与应用代码一起存放在源码仓库中。Pull request、审查门禁以及自动化发布流程同样适用于你的可观测性与安全视图，就像它们适用于被监控的服务一样。
合规性：Elastic 9.4 中 Elasticsearch 和 Kibana 已正式支持 FIPS 140-3 合规性，提前满足 2026 年 9 月的要求。
Elastic Cloud Serverless 已在全球 9 个 Azure 区域上线，并将在未来持续扩展 Azure 区域覆盖范围。
从这里开始：给 Microsoft Build 参会者的 4 个行动
立刻把 Elasticsearch 接入你的 Azure AI Foundry agent。开始免费 Elastic Cloud 试用。进入 Microsoft Azure AI 集成。将你的第一个基于 Azure OpenAI 的 agent 连接到 Elasticsearch 作为检索层。一个可运行的原型不到一小时即可完成。
在 VS Code 中安装 Elastic MCP Apps。从 最新版本发布 下载 .mcpb bundle。在 VS Code Copilot 中使用你的 Elasticsearch URL 和 API key 进行连接。你的第一次安全分诊或 Kubernetes 调查将在聊天中于五分钟内完成。
将 Azure OTel metrics 写入 Elasticsearch。在 Elastic Cloud 上启用 托管 OTLP 端点。将 Azure Monitor 的 OTel collector 指向该端点。你可以在单一 ES|QL pipeline 中查询 AKS metrics、主机 telemetry 和应用 traces——无需独立 metrics 后端。
加固你的 GitHub Actions 和 Azure DevOps 流水线。克隆 cicd-abuse-detector 仓库。将其加入下一次 pull request 检查。在你的 pipeline 配置中对照 完整威胁模型 进行审查。整个方案可在你现有 runner 上运行，无需额外依赖，仅需要 Claude Code CLI。
2026 年的 Elasticsearch 平台是为在 Microsoft 和 Azure 生态中工作的开发者打造的。agents、metrics、pipelines 和 identity 都在这里汇聚。在这里构建。
本文章中描述的任何功能或发布时间均由 Elastic 自行决定。当前不可用的功能可能无法按时交付或完全不交付。
原文：The essential Elastic 2026 wrap-up for Microsoft Build attendees and Azure developers | Elastic Blog
