Elastic 扩展 OpenAI 集成，同时保持企业 AI 的模型中立

Elastic 扩大了对 OpenAI 技术的使用，尽管其企业 AI 战略旨在避免依赖任何单一模型提供商。这一进展通过一份面向投资者的报告进入 Google News，该报告称 Elastic 与 OpenAI 的合作关系正在深化。

这一表述捕捉到了部分事实，但也可能造成错误印象。现有公司资料显示，OpenAI 只是 Elastic 更广泛的模型、云服务、检索工具和开放标准组合中的一个组成部分，并未证明双方建立了新的独家联盟。

这一区别很重要，因为 Elastic 正在争夺企业 AI 应用底层的上下文层控制权。该层负责检索企业信息、执行权限控制、监测模型行为，并将生成的答案连接到业务工作流。

OpenAI 提供模型，并通过 ChatGPT 构成重要的应用入口。Elastic 希望继续充当为这些模型准备和治理所需数据的基础设施。因此，它的主要对手并不只是其他搜索厂商，而是这样一种理念：AI 平台所有者可以将检索、编排、界面和治理整合进一款垂直一体化产品。

Elastic 实际扩展了什么

Elastic 正在扩展既有的 OpenAI 集成战略，而不是以 OpenAI 为核心产品取代其平台。

最清晰的实际案例是 ElasticGPT：这是 Elastic 于 2025 年 7 月在 Slack 中推出的一款内部助手。Elastic 构建它的目的是利用分布在内部系统中的信息回答员工问题。

该助手使用 SmartSource。Elastic 将其描述为检索增强生成与通过 Microsoft Azure OpenAI 提供的 GPT-4o 的结合。检索增强生成，即 RAG，会先查找相关源材料，再让语言模型生成答案。

这种架构为模型提供经过筛选的企业上下文，而不是指望它仅凭训练数据作答。Elasticsearch 充当向量数据库和检索系统，GPT-4o 则将检索到的材料转化为易读的回复。

Elastic 表示，其首个实施版本整合了两类主要信息源。一类是公司的内部 Confluence 站点，其中包含战略、团队、产品和流程信息。另一类是涵盖人力资源与信息技术政策的 ServiceNow 文章集合。

公司还加入了单点登录、访问控制、性能监测和治理流程。这些控制至关重要，因为企业助手必须遵守其检索信息所附带的权限。

Elastic 称，已有超过 3,000 名员工使用该助手。根据其发布的 ElasticGPT results，员工平均每年节省 63 小时，员工满意度达到 98%。

这些数据来自 Elastic，而非独立评估。该公司表示，基于员工时间、托管成本和开发人力计算，该系统在两个月内收回了投资。

所报告的结果提供了一个具体的商业案例，但并不能证明其他公司也会获得相同成果。Elastic 在自己的平台上、为自己的员工开发了该助手，并采用了关于节省时间的内部假设。

更重要的是，ElasticGPT 的设计支持多种语言模型。Elastic 表示，对多种模型的安全访问有助于减少影子 AI，即员工在公司控制之外使用未经批准的服务。

这种设计使 OpenAI 的连接意义重大，却并不意味着其具有排他性。OpenAI 为当前 ElasticGPT 实施方案提供生成组件，而 Elastic 仍负责检索、权限、数据准备和监测。

这一区别改变了对 Google News 标题的理解方式。Elastic 并不只是转售一个聊天机器人，而是将 Elasticsearch 定位为受控数据层，能够向 OpenAI 或其他兼容模型提供上下文。

这也构成了本文的核心张力。Elastic 与 OpenAI 的合作越紧密，其平台对 OpenAI 客户就越有用；但如果它希望继续成为独立的企业基础设施提供商，也必须让 OpenAI 保持可替代性。

为什么 Google News 标题对企业买家很重要

真正的竞争在于，哪家公司会成为专有数据与员工所用 AI 应用之间的控制节点。

企业通常并不难获得一个能力强大的语言模型。它们真正面临的难题，是如何在不制造另一个失控数据孤岛的情况下，将模型连接到最新、受权限控制且可追溯的信息。

通用模型不会自动知道哪一份政策文件是最新版本。它也无法推断某位员工是否应当看到法律备忘录、客户记录、安全警报或尚未发布的财务演示文稿。

检索基础设施通过在查询时选择信息来解决这一问题。身份控制决定用户能够访问什么，而可观测性工具则记录系统性能和故障。

Elastic 已在搜索、安全和可观测性领域销售产品。其企业 AI 的论点是，这些既有的数据和监测功能可以成为助手和智能体的共享基础。

该公司在 2026 年 2 月发布 Elastic 9.3 后进一步强化了这一论点。此次更新使 Agent Builder 正式全面可用，并将其与以技术预览形式发布的 Elastic Workflows 相连接。

Agent Builder 让开发者能够创建可搜索 Elasticsearch 数据并使用已定义工具的智能体。Workflows 将模型决策与基于规则的步骤结合起来，使团队能够为传统自动化保留可预测的操作。

Elastic 的 version 9.3 release 还增加了用于多语言嵌入和重排序的托管 Jina AI 模型。嵌入会将内容转换为用于语义检索的数值表示，而重排序则会按相关性重新排列检索结果。

这些新增能力强化了多模型战略。Elastic 可以与商业模型、云端托管服务，以及通过自身推理服务分发的模型协同工作。

这很重要，因为 OpenAI 也在向企业技术栈下层延伸。ChatGPT 应用可通过模型上下文协议（通常称为 MCP）连接外部数据和工具。

MCP 定义了一种标准方法，使 AI 应用能够发现并调用外部工具。它减少了每个模型界面与每项企业服务之间都需要独特集成的需求。

OpenAI 的企业产品日益支持自定义 MCP 应用，包括搜索、检索、交互式界面和经过选择的写入操作。该公司的 MCP guidance 表示，工作区管理员可以审核应用、控制访问权限，并批准单项操作。

这一扩展让 OpenAI 在界面、应用目录、权限体验和智能体工作流方面拥有更大影响力。但它也为 Elastic 创造了机会，因为每个有能力的智能体都需要可信赖的运营数据。

在两家公司都试图掌握同一个控制节点之前，这种关系是合作性的。OpenAI 希望 ChatGPT 成为员工搜索、分析和采取行动的场所。Elastic 则希望 Elasticsearch 继续充当决定哪些信息和运营上下文进入该界面的系统。

因此，企业买家应将所报道的合作视为一项架构决策，而不只是供应商公告。选择 OpenAI 模型，并不能决定企业上下文存放在哪里、权限如何运作，或模型活动如何被监测。

这些决定会影响未来的切换成本。保持检索和治理层独立的公司可以更轻松地更换模型。采用集成式 AI 技术栈的公司或许能获得简化体验，但也会接受对单一提供商更大的依赖。

押注的是上下文，而非某一个 OpenAI 模型

Elastic 最强的位置在于：相较于更换企业数据基础设施，更换模型造成的干扰更小的那一层。

语言模型获得了大部分关注，因为用户直接与其答案交互。然而，在模型收到提示之前，企业应用依赖许多不那么显眼的组件。

文档必须被摄取、清理、建立索引并与身份相匹配。系统必须检索有用段落、剔除无关材料、记录模型调用，并向运营人员暴露故障。

Elastic 已经处理了其中多项功能。其平台为结构化和非结构化信息建立索引，支持语义搜索和关键词搜索，并收集安全或应用遥测数据。

这种组合使 Elastic 能够将上下文工程定位为一个平台类别。上下文工程是为 AI 系统选择完成任务所需的指令、记录、工具及其他信息的过程。

这一战略并不止于内部员工助手。2026 年 4 月，Elastic 宣布推出面向安全、可观测性、搜索和数据探索的 MCP Apps。

这些应用可在受支持的 AI 客户端中渲染交互式界面。安全分析师可以查看警报或调查图谱，而运维工程师可以检查服务依赖关系和分布式追踪。

Elastic 表示，其安全应用能够对警报分组、展示进程树、运行 ES|QL 查询并创建案件。其可观测性应用则可以显示 Kubernetes 健康状况、异常、服务拓扑和故障影响。

搜索应用可以将自然语言请求转化为仪表板，然后允许用户编辑或导出生成的可视化内容。这已经超越了返回一段生成文本。

根据 Elastic 的 MCP Apps announcement，这些应用已在 Claude、Claude Desktop、VS Code、GitHub Copilot、Goose、Postman 和 MCPJam 中进入公开预览阶段。

这份名单很能说明问题。OpenAI 协助共同编写了 MCP Apps 规范，但 Elastic 的首批可用范围覆盖了由多家公司运营的产品。

Elastic 正在利用一项由 OpenAI 支持的标准，使其工作流能够在竞争性的 AI 环境中移植。因此，这项合作强化而非削弱了 Elastic 的模型中立立场。

这正是标题背后的核心反转。与 OpenAI 建立更深的技术连接，并不必然意味着对 OpenAI 的依赖加深。如果该连接采用开放协议，它可以帮助 Elastic 将相同能力分发到其他环境。

这种做法也对集成式数据平台构成压力。Snowflake、Microsoft、Google、Amazon 和其他提供商，都可以在自身环境中整合数据存储、模型、开发工具和治理能力。

Elastic 必须说服客户，相对独立的搜索和上下文层能够带来更好的相关性、可移植性或运营可见性。否则，企业可能会接受其已在使用的平台所捆绑提供的 AI 功能。

Elastic 的优势在于其已部署在搜索、日志、安全事件和应用遥测等场景中。这些数据集往往包含智能体调查事件或回答企业特定问题所需的证据。

它的劣势在于需要增加额外架构。独立平台必须完成部署、运维和安全防护，并证明其相较于一体化替代方案的合理性。

当 Elastic 与 OpenAI 的连接能够降低这种集成负担时，它就具有价值。如果买家认为其模型供应商或云平台已经提供了足够的检索和治理能力，这种价值就会下降。

对开发者而言，实际问题在于应用逻辑能在多大程度上保持可移植性。将源信息保存在与模型无关的检索系统中，可以简化对不同语言模型的试验。

同样的原则也适用于个人和团队工作流。结构良好的 AI knowledge base 能将有用的源材料与用于查询它的模型分离保存。

Elastic 正在企业级规模上践行这一原则。模型可以变化，而已建立索引的企业信息、访问策略和运营历史则会保留下来。

OpenAI 很重要，但可替换性才是产品本身

Elastic 必须让 OpenAI 良好运作，同时证明客户无需重建数据层即可替换模型。

这一要求带来了艰难的产品平衡。深度集成能够带来更好的体验，但供应商特定功能可能会削弱可移植性。

OpenAI 提供的不只是文本生成。其应用平台还包括工具调用、连接数据、交互式界面、管理控制和智能体工作流。

利用这些能力可以加快开发，但也可能促使开发者围绕 OpenAI 特有的行为、API、权限或界面组件来构建逻辑。

Elastic 的答案是分层架构。Elasticsearch 负责存储和检索信息，而其上层的连接器、模型和用户界面可以更换。

该公司的公开材料将 OpenAI 列为更广泛 AI 生态系统的一员，该生态系统还包括 Anthropic、Cohere、Hugging Face、LangChain、LlamaIndex、Mistral AI、NVIDIA 和主要云服务商。

Elastic Agent Builder 也被描述为模型无关。这使开发者能够选择托管模型服务，而无需改变应用底层的已索引数据。

这一承诺需要的不只是兼容性列表。模型在选择工具、遵循指令、理解检索文档或处理长对话时，表现各不相同。

一个能同时运行于两家供应商的应用，仍可能在准确性、延迟和安全性上产生不同结果。API 层面的模型可移植性，并不保证应用性能具有可比性。

因此，Elastic 必须证明其检索、重排序和工作流控制能够缩小这些差异。买家会希望基于自己的文档和任务进行评估，而非依赖通用基准测试。

该公司通过 ElasticGPT 提供了一个有价值的内部案例研究。员工可以询问公司政策、销售流程、技术支持、会议和产品差异。

不过，这一实施仍依赖 Elastic 自身的衡量标准。其报告的每位员工节省 63 小时，假设与助手的交互意味着时间被腾出用于其他工作。

满意度同样衡量的是用户感受，而不是回答正确性。用户可能喜欢一个快速的回答，即便它遗漏了例外情况或检索到了过时政策。

Elastic 表示，用户可以通过更正源信息来改进知识库。这个反馈循环解决了 RAG 的一个常见弱点，因为许多表面上的模型失败，源于内容不完整或陈旧。

不过，更正也带来了所有权问题。必须有人决定哪个来源具有权威性，解决文件冲突，并在员工角色变动时维护访问权限。

这些是组织层面的任务，而不是搜索功能。软件可以揭示冲突，但信息治理的责任仍在客户一方。

OpenAI 还引入了新的风险面。将检索内容发送至外部模型服务，要求客户理解数据处理、保留、区域可用性和合同保护措施。

使用 Azure OpenAI 可以融入现有的 Microsoft 治理计划，但并不能免除安全审查的必要。企业必须梳理哪些数据离开 Elastic、记录了什么，以及谁能查看这些记录。

MCP 应用带来了更多复杂性，因为它们可以从检索进一步发展到执行操作。遭篡改的指令可能试图滥用已连接工具，而过于宽泛的权限可能暴露敏感结果。

OpenAI 警告称，组织有责任审查自定义 MCP 服务并配置操作权限。某些写入操作需要确认，但管理审查仍然至关重要。

Elastic 在安全和可观测性方面的背景，使其在这一讨论中具有可信的位置。但可信度并不等同于独立证据，证明每个新的智能体工作流都是安全的。

产品检验在于，管理员能否理解智能体的数据路径、复现其操作并限制其权限。如果这一过程仍然困难，模型选择也无法解决采用问题。

这些数字支持什么，又不支持什么

Elastic 的财务表现支持市场对其更广泛平台的需求，但并未单独反映 OpenAI 合作带来的收入。

Elastic 报告称，截至 2026 年 4 月 30 日的第四财季收入为 4.51 亿美元，同比增长 16%。

全年收入达到 17.39 亿美元，同比增长 17%。订阅收入总计 16.34 亿美元，其中销售驱动的订阅收入增长 20%。

公司还报告称，当前剩余履约义务为 12.03 亿美元，同比增长 20%。总剩余履约义务达到 19.82 亿美元，增长 28%。

这些义务代表已签约但尚未确认的收入。它们的增长表明客户承诺的规模更大或期限更长，但并未说明每份合同由哪些产品推动。

Elastic 拥有超过 1,720 家年度合同价值超过 10 万美元的客户，而一年前这一数字超过 1,510 家。

首席执行官 Ash Kulkarni 表示，随着 Elastic 成为客户 AI 基础设施的一部分，客户正在做出更大的承诺。公司的 2026 财年业绩 还强调了搜索、安全和可观测性的整合。

这些业绩强化了这样一种观点：Elastic 拥有可用于推广 AI 功能的企业分销基础。但它们并未显示有多少收入来自与 OpenAI 相关的应用、Agent Builder、向量搜索或传统工作负载。

对于阅读有关扩大合作关系的 Google News 标题的投资者而言，这一归因缺口很重要。合作叙事可能暗示直接的收入催化剂，而底层经济效益实际上仍被打包在平台订阅中。

Elastic 自身的风险表述仍保持了适当谨慎。该公司将客户接受度、AI 竞争、定价、云业务结构以及 AI 项目的成功与否列为可能影响未来业绩的因素。

管理层预计 2027 财年第一季度收入将在 4.69 亿至 4.70 亿美元之间。中值对应的同比增长率为 13.1%，低于上一季度报告的 16%。

对于整个财年，Elastic 预计收入将在 19.85 亿至 20 亿美元之间。中值意味着 14.6% 的增长。

这一展望并未否定 AI 战略，但表明投资者应将产品相关性与即时增长加速区分开来。

企业 AI 项目可以增加数据摄取、向量搜索、安全监控和可观测性的使用，也可能仍处于预览阶段、在治理审查期间停滞，或转向打包式云服务。

Elastic 的公开预览 MCP Apps 就说明了这种不确定性。它们展示了一个可用方向，但公开预览并不等同于大规模生产采用。

该公司尚未披露各个 MCP App 的独立使用数据，也未量化有多少 Elastic 客户将平台连接到 OpenAI 模型而非其他供应商。

更有力的投资论据应包括 AI 工作负载的扩张率、生产部署、相关消费增长和客户留存数据。缺少这些细节，这项合作在战略上仍然引人关注，但在财务上难以单独衡量。

企业买家面临类似的衡量问题。一次成功演示并不能证明其在规模化运行下具有更低运营成本或更好的事件处置结果。

他们应衡量检索准确性、任务完成率、权限失败情况、响应延迟、人工审查时间，以及维护源信息的成本。

ElasticGPT 提供了一个初步的内部参考点。其报告的回本周期和员工满意度展示了 Elastic 认为该平台能够带来的价值。

下一步是获得来自不同组织的外部验证，这些组织具有不同的权限、文档、合规义务和应用环境。

三个信号将表明 Elastic 的战略是否奏效

下一阶段取决于生产环境采用、跨模型一致性，以及证明 AI 工作负载能够改善 Elastic 业务的证据。

第一个信号是 Elastic 的 MCP Apps 从公开预览转向正式发布。正式发布应带来更清晰的支持承诺、管理控制、兼容性细节和生产案例。

安全和可观测性团队应关注客户是否将这些应用用于真实调查，而非仅用于演示。生产事件对数据新鲜度、可追溯性、权限执行和可预测操作提出了更严格要求。

如果能在 Claude、ChatGPT、GitHub Copilot 和其他客户端中得到广泛采用，将增强 Elastic 的模型中立论点。若采用集中在单一界面，战略就会更依赖该供应商。

第二个信号是证明同一工作流能在多个模型之间可靠运行。仅有兼容性是一个较弱标准，因为两个模型可能以不同准确性调用同一工具。

Elastic 应发布涵盖检索质量、工具选择、任务完成、延迟和不安全操作尝试的评估。客户自行运行的测试，将比仅由供应商产生的结果更具说服力。

最具说服力的证据将表明，Elastic 的上下文层能够缩小不同模型之间的性能差异。这将使模型可替换性从设计主张转化为可衡量的产品优势。

如果每当模型变化时，应用都需要大量重写，可移植性的论据就会减弱。届时，买家可能更偏好组件更少的垂直整合平台。

第三个信号是将 AI 活动与订阅扩张联系起来的财务披露。投资者应关注客户增长、剩余履约义务、云消费，以及有关生产 AI 工作负载的评论。

更大的合同将支持 Elastic 的主张，即企业将搜索、安全和可观测性视为一个统一的 AI 基础设施平台。消费放缓或试点周期延长，则会表明这种兴趣尚未转化为持久使用。

竞争对手的回应同样会在这些信号中体现。云服务商和数据供应商将继续把检索、智能体和治理能力嵌入各自的服务中。

Elastic 无需取代每一个一体化平台。它需要证明，客户足够重视独立的上下文层，愿意在多个云环境、模型和 AI 界面之间持续运行它。

与 OpenAI 的合作关系有所助益，因为 ChatGPT 让 Elastic 接触到重要的企业级应用入口。OpenAI 对 MCP 的支持，也让 Elastic 更容易在不依赖私有集成标准的情况下连接工作流。

但同样的开放性也让竞争对手能够进入这一入口。Elastic 必须凭借检索质量、运营数据、权限管理和工作流深度取胜。

这正是为何原始标题并不像表面上那么直观。重要进展并不是 Elastic 选择 OpenAI 作为其唯一的企业 AI 合作伙伴。现有证据恰恰指向相反的方向。

Elastic 正在集成 OpenAI，同时保障客户使用其他模型和界面的能力。其战略成功的前提，是让 OpenAI 成为一个有价值的选项，而非不可避免的依赖。

通过 Google News 跟进这一事件的读者，现在应关注生产环境部署、跨模型评估，以及与 AI 工作负载相关的营收。这些信号将揭示 Elastic 是否拥有持久的上下文层，还是仅仅成为不断扩展的企业 AI 技术栈中的另一条连接。