作者：来自 Elastic Dayananda Srinivas
探索为什么即使在 MCP、federated search 和 large context windows 的时代，搜索引擎和 indexed search 仍然是可扩展、精准、企业级 AI 的基础。
测试 Elastic 的领先、开箱即用的功能。浏览 Elasticsearch Labs repo 中的示例 notebooks，启动免费的 cloud trial，或现在就在本地机器上试用 Elastic。
随着大型语言模型 (LLMs)、agent 框架以及像 Model Context Protocol (MCP) 这样的新协议的兴起，一个引人深思的问题开始浮现：
我们真的还需要搜索引擎吗？
如果 agent 可以按需调用工具，模型可以在大规模 context 窗口中推理，为什么不直接从每个系统实时获取数据，让 LLM 来解决呢？
这是一个合理的问题，但也是错误的结论。
现实是 MCP 和 agent 工具并不能消除对搜索的需求。它们只让搜索的质量比以往任何时候都更为关键。在这篇博客中，我们将探讨为什么 MCP、联合搜索(federated search) 和大 context 窗口不能替代搜索引擎，以及为什么索引仍然是可扩展、精准、企业级 AI 的基础层。
MCP 实际上是什么（以及它不是什么）
MCP 是一种协调协议。它规范了 agent 如何从外部系统请求信息或操作。
MCP 不做的事情：
- 对跨系统的结果进行排名。
- 理解异构数据的相关性。
- 规范 schema 或 metadata。
- 大规模的数据转换或增强。
- 应用一致的安全和权限。
- 针对延迟、成本或规模进行优化。
换句话说，MCP 告诉 agent 如何请求数据，而不是哪些数据最重要。
现代检索需要查询智能（query intelligence），而不仅仅是数据访问
在现代企业搜索架构中，检索质量在查询到达索引之前就已决定。原始查询 —— 尤其是由 agent 生成的 —— 可能不完整、过于字面化、基于 schema 而非意图驱动，有时甚至语法无效。
这就是为什么成熟的搜索平台引入 query intelligence 层，在检索开始之前进行 query 重写、实体规范化、同义词扩展和意图消歧。
例如，一个 agent 生成的请求：“显示上个 sprint 的严重性 2 的身份验证失败/Show severity 2 authentication failures from last sprint” 可能会被重写，以包括身份验证同义词（login, SSO, OAuth）、规范化的严重性映射，以及 sprint 到日期范围的转换。结果不仅是更多匹配，而是更相关的匹配。
在企业 AI 中，检索不是单一步骤，而是一个可控的 pipeline。
这一区别至关重要，因为一旦基于 MCP 的 agent 开始从多个工具实时拉取信息，它们就在新名称下重现了一个熟悉的模式：联合搜索 (federated search)。
基于 MCP 的检索是伪装的联合搜索
联合搜索并不新鲜。企业几十年来一直在尝试。
模型很简单：
- 将用户的 query 并行发送到多个系统 (SharePoint, GitHub, Jira, customer relationship management [CRM])。
- 收集响应。
- 合并并呈现结果。
MCP 驱动的工具调用遵循相同模式，只是调用者现在是 agent，而不是用户界面。
同样的问题也会再次出现。
为什么联合搜索在企业规模下会失效
延迟变得不可预测：联合查询的速度取决于最慢的系统。企业系统的响应时间和速率限制可能差异巨大，因此联合查询往往缓慢且不稳定。agent 必须等待多次往返才能开始推理。结果是体验滞后，等待时间不可预测。
相关性分散：因为每个系统独立对结果进行排名，没有统一的相关性模型。联合搜索无法在所有内容上应用单一的排名或语义理解，因此结果常常显得零散或不完整。agent 可能检索到正确的信息，但不是最有用的信息。
上下文浅显且不完整：联合系统通常只暴露通过 API 调用可直接访问的内容。它们很少展示：
- 使用信号，如点击、停留时间、访问新近性、受欢迎程度或权威性。
- 跨不同系统的文档关系以关联洞察。
- 单一孤岛之外的组织知识。
这剥夺了 agent 所需的广泛上下文，从而影响高质量推理。
过滤和功能受限：在联合设置中，你只能对每个系统都支持的字段进行过滤（“最低公分母”）。如果某个系统不支持特定的过滤器或维度，该功能将完全丧失。这严重限制了丰富的搜索功能，如日期范围、类别或标签。
索引搜索的强大能力
搜索引擎通过使用专门的数据结构实现大规模的毫秒级检索，包括用于词汇搜索的倒排索引和用于基于向量检索的 k 维树 (k-d trees)。这种方法是将每个来源抓取或摄取到搜索引擎中，创建一个企业知识的集中存储。这带来了巨大的优势：
- 按设计实现速度：搜索索引速度极快。查询命中倒排索引和专用数据结构，避免了轮询每个后端系统的需求。
- 随着时间累积的相关性：支持语义搜索的搜索引擎能够理解意图，机器学习模型可以在企业场景中重新排序结果。在一个 Elastic 实验中，当将向量搜索与问答 (QA) 模型结合以提取答案时，Elastic 用户看到更准确的结果。它比关键词匹配提供更高的精度。
- 高级功能：Elastic 的 Graph 检索增强生成 (RAG) 解决方案展示了如何将索引结构化为知识图谱，从而实现更具上下文的检索。换句话说，索引不仅是对文本的历史汇总；它们还可以编码关系和本体，使 AI 能够跨文档连接信息点。
- 权限感知搜索：企业 AI 不能在安全性上妥协。索引搜索允许：
agent 只能看到用户被允许查看的内容，而不会将数据泄露到模型提示或训练中。Elasticsearch 适合作为下图中的索引搜索层，因为它提供了上下文工程所需的核心组件。
通过搜索模板和受控执行实现检索一致性
在大规模环境下，检索必须可预测、安全且可重复。这就是搜索模板变得至关重要的原因。
搜索模板充当应用程序、agent 和搜索平台之间的检索契约。agent 不再在运行时动态构建查询，而是调用预定义的检索模式，以强制执行：
- 一致的相关性逻辑
- 强制的安全过滤器
- 成本和延迟保护
- 业务特定的排名规则
- 明确的索引和字段范围边界
在基于 MCP 的架构中，这一点尤为重要。agent 不应动态发明检索策略，而是 MCP 工具调用可以直接映射到经过批准的搜索模板，确保每个检索请求都遵循企业相关性和治理标准。
这种方法将检索从临时查询执行转变为受控的检索编排。
检索现在是一项多层次的工程学科
现代企业检索不再是简单的查询到索引操作。它通常包括多个协调层：
- 查询理解 — 重写、扩展、实体解析
- 检索策略选择 — 混合搜索、向量搜索、图检索，或合成查询技术，如假设文档嵌入 (Hypothetical Document Embeddings, HyDE)，系统先生成代表性答案或扩展上下文，再利用更丰富的语义信号检索文档。
- 执行治理 — 模板、安全执行和性能保护措施
- 排序与重新排序 — 融合词汇精度、语义相似性，以及来源于交互的相关性信号，如点击模式、停留时间和文档使用频率。
当这些层在上游实现时，agent 接收到的是干净、高置信度的上下文，而非原始、零散的数据。
这就是大规模 agent 系统在生产环境中可靠的原因。
高级检索技术在推理开始前提升上下文质量
现代检索系统越来越多地使用 AI 辅助技术，在排序应用之前提高召回率和语义覆盖。
一个例子是假设文档嵌入 (Hypothetical Document Embeddings, HyDE)。系统不仅嵌入原始查询，而是先生成假设答案或扩展上下文，对该表示进行嵌入，然后基于更丰富的语义信号检索文档。
这在企业环境中特别有用，因为：
- 用户或 agent 可能不知道确切术语
- 知识分布在不同孤岛中
- 重要上下文是隐含的而非明确陈述
像 HyDE 这样的技术提高了在原始查询不充分时仍能检索到相关文档的概率。
这强化了企业 AI 的一个关键原则：更好的上下文检索产生更好的推理结果。
Agent 不是数据工程师；它们是推理系统
它们不应该负责将原始数据拼接在一起、调和 schema，或补偿不良检索。
这就是像 Elasticsearch 这样的搜索平台成为基础的原因。
通过一次性摄取数据并在上游进行规范化（通过 pipeline、mapping、enrichment processors 和预构建索引），Elasticsearch 解决了 schema 不匹配问题，整合跨来源信号，并生成可直接检索的数据视图。在查询时，agent 接收到的是干净、已排序、语义增强的结果，而不是零散的原始记录。
例如，agent 不必独立从 CRM、工单和文档系统中拉取数据，并实时调和客户 ID、时间戳和格式；Elasticsearch 可以将这些来源预先索引为统一的客户交互索引，支持混合（关键词 + 向量）搜索和相关性排序。然后 agent 查询单一、一致的接口，并立即在最相关的上下文上进行推理。
这种职责分离 —— Elasticsearch 处理数据集成和检索，agent 专注于推理、规划和决策 —— 正是使 agent 系统可扩展、可靠并适合生产的原因。
Elastic 在 AI 堆栈中的角色
Elastic 天生位于搜索和 AI 的交汇点。
- 连接器和爬虫持续从企业系统摄取数据。
- 语义搜索和向量搜索支持基于意图的检索。
- 混合搜索将词汇精度与语义理解融合。
- RAG 工作流将 LLM 锚定在权威且权限感知的数据上。
Elastic 不与 agent 或 MCP 竞争，而是使它们更高效。
更大的模型并不能消除检索
有人怀疑，巨大的新 LLM 是否可以绕过传统搜索，或许通过让模型一次性读取所有内容。大 context 窗口看起来很强大，但它们会带来：
- 更高的延迟
- 更高的成本
- 噪声导致的精度下降
- 更容易产生混淆、上下文冲突和上下文污染
RAG 的优势在于先过滤再推理。在另一个 Elastic Search Labs 实验中，RAG 大约在 1 秒内得出答案，而原始 LM 方法需要 45 秒，成本仅为其 1/1250，并且精度更高。换句话说，给 LLM 一百万个文档 token，比先通过索引过滤更慢、更昂贵，且实际上精度更低。
结论：MCP 改变的是接口，而非基本原理
MCP 在 agent 与工具交互方式上是一个重要的进步，但它并不能取代快速、相关且受控的检索需求。
在企业 AI 中：
- 上下文质量决定答案质量。
- 索引创造这种上下文。
- 搜索是基础，而不是遗留系统。
在 MCP 时代，索引并未过时。它们是基于 MCP 的 agent 能够正常工作的原因。
