最近在与众多 Agent 创业团队交流时，我们发现了一个非常有意思的共性：至少有三分之一的团队在检索这件事情上翻过车。

究其原因，是因为大家习惯性地把AI Agent 的检索等同于传统网页搜索的 API 化。

但两者的底层逻辑有着本质的区别：

传统搜索： 核心目标是把相关网页呈现给人，由人来完成后续的阅读、判断和决策。

Agent 搜索： 核心目标是动态、实时、高频的为大模型提供可直接参与推理、决策和任务执行的“可信证据”。

这意味着 Agent 检索系统必须具备极强的任务理解能力。它需要根据上下文自动拆解问题、生成多轮查询、融合关键词与语义检索，并通过重排序（Reranking）、元数据过滤、内容抽取和来源校验，将碎片化的信息转化为结构化、可引用、可追溯的知识输入。

不仅如此，传统搜索往往是用户的一次性动作；而 Agent 的检索则是高频、链式、任务驱动的。一个复杂的任务可能会触发几十次甚至上百次检索、改写与验证，这对系统的低延迟和稳定吞吐提出了极高的要求。

那么，面向 AI Agent 的检索系统到底该怎么做？

不久前，我们与全球知名的 AI 搜索技术提供商 Exa 的核心研发团队行了深度访谈。作为服务了 Cursor、Lovable、AWS、HubSpot、OpenRouter、Coderabbit等一众顶尖 AI 产品的背后功臣，Exa团队分享了他们在深度服务客户过程中的核心心得，以及如何借助 Zilliz Cloud 攻克entity search（实体搜索）场景下的高并发、毫秒级延迟与 Schema 零停机变更等痛点。

希望以下分享对你有帮助。

1. Exa 是谁，如何给 AI Agent 提供 grounded search

Q：Exa 现在提供的是什么产品？主要客户是谁？

Exa：简单来说，Exa 的定位是 AI 时代的搜索引擎。我们的客户既有 Cursor、Lovable 这样的 AI 原生新星，也有AWS、HubSpot这样的大型企业。

只要一家公司在用 Agent 来推动知识工作，它就必须解决大模型的幻觉问题，需要Grounded Context，让 Agent 能够基于真实世界的数据做出响应。因此，不管公司大小，我们服务的本质上是那些正在积极推进 Agent 驱动工作流（Agent-driven workflow）的团队。

为了满足这些团队的需求，我们提供了一个高可靠、低延迟、定制化的网页搜索 API。这个 API 能够覆盖不同的计算延迟场景，其中两种典型是：

Instant Search（即时搜索）： 延迟小于 200 毫秒，专门为语音 Agent 或高频交互场景设计。

Deep Research（深度研究）： 提供带有结构化输出和丰富元数据增强（Enrichments）的深层检索。

在技术底层，传统的搜索引擎很难支撑 Agent 多轮查询、图文融合、高频调用和高质量重排（Rerank）的特性。因此，我们放弃了传统搜索引擎的架构，设计了一套全新的神经架构（Neural Architecture）。

这让我们对整个技术栈拥有端到端的控制权，可以针对质量和速度去优化每一层。比如最近发布的 Exa Instant，我们把搜索延迟做到了 <200ms，从而让 neural search 可以真正高效服务于AI Agent 的实时搜索，同时保证我们在AI 搜索领域的高质量、速度和可定制性优势。尤其在代码搜索、极致低延迟搜索以及人员/公司等实体搜索场景下，我们能显著提升搜索效率和 token 使用效率。

当然，自己做搜索引擎意味着很多东西都要自己来：训练 Embedding 模型和 Reranker、抓取海量网页、建立数十亿网页的索引等。

2. 转折点：从网页搜索到实体搜索

随着业务的拓展，Exa 迎来了一个关键的技术转折点：从广义的网页搜索扩展到垂直的实体搜索（Entity Search，如针对公司、人物、代码等特定对象的搜索）。

Q：你们是在产品发展的哪个阶段意识到需要向量数据库的？

Exa： 我们的搜索引擎本身就是构建在 Embedding 和向量相似度检索之上的，所以向量检索一直是我们技术栈的核心。但当我们开始做实体搜索（Entity Search）时，原有的基础设施遇到了瓶颈。

实体搜索对系统的要求和网页搜索完全不同，它需要：

1. 更丰富的元数据模式（Metadata Schema）。
2. 更频繁的实时数据更新。
3. 强大的托管式可扩展能力。

虽然我们内部的数据库针对核心网页搜索做了极致优化，但为了加快实体搜索层的迭代速度，我们还是决定引入专业的向量数据库Zilliz Cloud 。目前，我们的核心网页索引仍然跑在内部基础设施上，而 Zilliz Cloud 则专门用来支撑我们的entity search layer。

Q：在引入新方案之前，原有的技术方案主要卡在哪里？

Exa： 主要是新场景带来了三个传统技术栈很难优雅解决的需求：

• 混合检索（Hybrid Search）： 必须深度结合稠密向量（Dense Vector）的语义理解和稀疏向量（Sparse Vector）的精准关键词匹配。
• 动态 Schema： 实体属性丰富且经常变化，需要数据库支持灵活的元数据过滤。
• 运维成本： 随着垂直场景（如人脉、企业、代码）变多，管理多个专用数据集（Specialized Collection）的运维负担呈指数级上升。我们迫切需要一个托管方案来解放工程师。

Q：现在你们具体用向量搜索/向量数据库解决什么问题？

Exa： 现在 Zilliz Cloud 支撑的是我们的 entity search layer。在这一层中，它在各大垂直实体集合（Entity Collection）里同时承担了“核心索引（Primary Index）”和“近实时缓存（Recency Cache）”的双重角色。

这里的核心挑战在于：每一个垂直实体场景（比如找公司、找人、找特定代码），都要求在高频、实时更新的数据上，进行低延迟且带复杂过滤条件的搜索。

如果用传统方案，数据频繁更新会要不断重新构建索引，从而带来极高的延迟和性能损耗。而 Zilliz Cloud 的全托管混合检索（Managed Hybrid Retrieval）和热更新（Hot-upsert）能力完美解决了这个痛点，不仅能让检索结果保持实时可检索，同时完全不需要重建索引。

由于这些垂直场景的数据会直接通过我们的 Search API 交付给 各种大客户， Zilliz 提供的速度和召回率，会直接决定我们核心业务的质量。

3. Exa 对托管向量检索层的要求

对于一个把搜索当成核心命脉的公司来说，评估外部托管系统的标准是非常苛刻的。

Q：选择 Zilliz Cloud 之前，你们评估过哪些向量数据库？评估标准是什么？

Exa： 我们团队天天都在和向量检索打交道，市面上的主流方案我们都非常熟悉。当时我们的核心评估标准主要有四个：hybrid search、 metadata schema、低延迟（从秒级到毫秒级）、高扩展性。Zilliz Cloud 这几项都满足，而且在 hybrid search benchmark 上的表现明显领先。具体要求如下：

Q：你们最早是怎么知道 Zilliz Cloud / Milvus 的？

Exa： 我们很早就知道 Milvus。毕竟是最成熟的开源向量数据库之一。我们团队天天做 vector search，不太可能没听过它。

再后来，我们开始规划 entity search infrastructure 的时候，作为全托管 Milvus，还有企业级性能增强的Zilliz Cloud 很自然就进入了候选列表。

Q：评估过程中，Zilliz Cloud 哪些点比较打动你们？最后选择它的关键原因是什么？

Exa： 有几个点很快就看出来了。

1. 原生混合检索与内置 Rerank： 它支持在单次 API 调用里直接融合 Dense 语义搜索和 Sparse BM25 关键词匹配，并通过倒数排名融合（RRF）或权重完成重排。很多竞品在这点上都需要我们在应用层自己写复杂的逻辑。
2. 过滤无性能断崖： Zilliz Cloud的 Cardinal 索引引擎非常强大。在实际业务中，我们经常需要把复杂的元数据过滤（比如行业、地区、代码语言）叠在向量搜索上。在 Zilliz 上，这种复杂查询的延迟依然稳稳满足我们生产环境的严苛要求。
3. 运维极简与热更新： 作为一个全托管服务，它的 Hot-upsert（热更新）能力允许我们在不重建索引的情况下让数据保持最新。这让我们的工程师能把百分之百的精力放在优化搜索体验和快速上线新的垂直场景上。
4. 速度： Zilliz Cloud 的查询延迟满足我们对生产搜索的毫秒级召回的严格要求。我们的用户期待的是毫秒级结果，Zilliz 能撑住这个要求。

4. Zilliz 和 Exa 的架构是怎么配合的

Q：Zilliz Cloud 在你们的架构里处在什么位置？

Exa： 我们的 entity search 架构分三层：ingestion、search 和 API。

• 在 ingestion 层，我们用自己的 ML pipeline 对 entity data 做 enrichment 和 embedding，然后把 dense vector 和 sparse vector upsert 到 Zilliz Cloud。
• 在 search 层，我们的后端会根据用户 query 生成 embedding，然后向 Zilliz Cloud 发 hybrid search 请求，把 semantic matching、keyword matching 和 RRF reranking 结合起来。
• 到了 API 输出层，搜索结果会再用 structured metadata 做 enrichment，然后通过我们的 Search API 和 Websets 产品服务出去。

Zilliz Cloud 位于这个 workflow 的检索核心：它存储所有 entity vectors 和 metadata，并负责低延迟搜索。但我们的主网页索引则是在另一套内部基础设施上构建和管理的。

Q：你们团队使用 Zilliz Cloud 或 Milvus 的体验怎么样？

Exa： API 很直观，文档也比较扎实，系统在生产环境里一直很可靠。学习成本不高，因为 Milvus 里的概念，比如 collections、indexes、search params，和我们理解 vector search 的方式很一致。

另外，Zilliz Cloud 是托管服务，所以我们基本不需要处理太多运维事故。

Q：和 AWS 或其他云服务集成起来怎么样？

Exa： 非常顺畅。我们的基础设施主要托管在 AWS 上，而 Zilliz Cloud 本身也原生跑在 AWS 上。这种天然的邻近性使得我们的 EKS（Kubernetes）服务与 Zilliz Cloud 之间的网络延迟极低，这对于构建毫秒级别Instant Search 至关重要。

5. 采用之后发生了什么变化

Q：你们看到的前三个主要收益是什么？有没有可以量化的指标或改进？

Exa： 第一个明显收益是 developer velocity。托管服务加上清晰的 API，让我们的团队可以快速上线新的 entity-search vertical，而不需要再去构建和维护额外基础设施。

除此之外，schema flexibility 和 adaptability 也很重要，因为这些 vertical dataset 会不断演进。还有一点是，通过 autoindex 带来的搜索质量提升，在实际使用中也很有价值。

Q：Zilliz Cloud 里你们最看重哪些功能？

Exa： 日常用下来，最突出的有两点。

Filtering without performance cliff： 可以把复杂 metadata filters 叠在 vector search 上，而且对延迟的影响非常小。

Fast vertical launches： 托管式扩展能力让我们可以很快发布新的搜索垂直场景，不需要每次都重新搭一套基础设施。

如果对以上方案中提到的能力感兴趣，欢迎点击文末阅读原文，新人用户可获得 300 元人民币的免费 Zilliz Cloud 额度。