> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/zh/ai/ai-whitepaper/agentic-search.md).
# 智能体搜索
## **什么是 Agentic Search？**
#### Agentic Search 是一个统一、权限感知的上下文层，涵盖 Zoom 内容和连接的企业数据源
Agentic Search 是一种企业级知识检索能力，它会在 Zoom 原生内容与已连接的第三方数据源中收集、索引并关联相关信息，形成一个可针对查询进行匹配的单一组织知识体。与传统搜索不同之处在于：一次查询能够借助的范围有多广——会议转写文字、Team Chat 消息，以及位于企业云盘中的文档，都可能共同产生同一个结果。该结果的呈现形态取决于切入点——用自然语言生成的综合答案，或供另一个模型推理的、带排序的一组有依据的源材料——但所涵盖的来源以及针对它们所执行的权限并不会改变。
在 Zoom 中，检索范围涵盖已在平台上逐步累积的工作记录——会议录制和转录、会议摘要、团队聊天对话，以及随其创建的文档、笔记和其他相关产物。超越 Zoom 之后，检索还扩展到连接的记录系统和内容存储库，其中可能包括 Salesforce、Google Drive、OneDrive、SharePoint、Confluence、Box、ServiceNow、Workday、Zendesk 和 Seismic 等服务。只要支持并启用索引，这些系统中的内容就会与 Zoom 原生信息一同被导入到 Zoom 的检索层中，因此一个问题将基于一套组织知识整体来得到回应，而不是一组彼此隔离、各自都需要按照自身规则进行搜索的存储库。
检索全过程都具备权限感知。来自各个源系统的访问控制都会被继承并强制执行，因此呈现的信息——无论是 Zoom 原生还是第三方——都仅限于请求的用户或代理所适用的权限。扩大可搜索来源的范围，并不会扩大任何个人对这些来源的访问权限。
#### “Agentic Search”描述的是一种能力，而不是一种界面
Agentic Search 最好被理解为一种底层能力，而不是某个特定的屏幕或按钮。相同的能力可以通过多种方式实现：普通用户可通过 ZoomMate 界面使用，应用和 AI 代理则可通过 Search 和 Ask API 以及模型上下文协议（MCP）使用。无论使用哪种入口，这个术语都指向同一个核心功能：跨来源检索并综合相关信息。
#### ZoomMate 使用 Agentic Search 从已连接的组织知识中检索已索引数据，然后将结果综合成自然语言响应
对于日常用户来说，ZoomMate 是代理式搜索变得日常化的地方。无论是为即将召开的会议做准备，回忆在几次过去的会议中做出的决定，还是查找与一个待办行动项相关的文档，这些都可以通过一次请求解决，而不必在会议、聊天、文档、云存储以及 CRM 或工单系统之间分别搜索。
#### MCP 和 Search and Ask API 将相同的检索能力扩展到应用程序和外部 AI 智能体
应用程序和外部 AI 代理，包括基于第三方 LLM 构建的代理，通过 MCP 将 Agentic Search 作为工具进行呼叫。访问控制随呼叫一起传递，因此代理检索到的信息与其已认证用户的权限保持一致。
该 **搜索 API** 返回一组按相关性排序的结果，并将生成留给调用方自己的模型，这适用于原始、有依据的源材料才是期望输出的场景。
该 **提问 API** 在 Zoom 内同时执行检索和生成，返回一条经过综合、带引用的自然语言答案。
#### 一个常驻索引和按请求时检索可使频繁变化的数据保持最新
Agentic Search 并不局限于静态索引。内容会被向量化、索引化并添加关键词，获批准的第三方内容则通过以管理员为范围的增量同步纳入，以便后续高效检索。变化频繁的数据，或需要请求时新鲜度的数据，可以改为通过 MCP 或等效的实时连接直接查询，而不是由索引提供。
结合起来，常驻索引和按请求时检索意味着上下文层反映的是所连接系统的当前状态，而不是上次同步时的状态。
## **数据源和索引**
#### Zoom 的索引架构是专门打造用于对话式 AI 检索的
Zoom 的索引架构是专门打造用于对话式 AI 的，采用向量搜索、内容分块，以及围绕对话式系统检索上下文方式设计的模式。许多企业搜索和图技术最初都是围绕不同目标设计的：正在连接文档、人员、元数据以及生产力环境中的其他实体。这种架构差异之所以重要，是因为对话式 AI 需要识别并检索与用户的问题在语义上相关的具体信息片段，而不是主要在文档或实体之间导航关系。Zoom 的方法围绕这种检索模型来构建和索引内容，使对话式用例成为核心架构考量，而不是叠加在为其他目的设计的系统之上的能力。
换句话说：这就是按单本书对图书馆进行索引，与按某人实际可能需要用来回答问题的段落对图书馆进行索引之间的区别。
#### 第三方连接器可将 Zoom 的上下文层扩展到已获授权的第三方系统，具体取决于管理员是否启用
Agentic Search 支持从已授权的第三方连接器进行索引，包括 Google Drive、OneDrive、Box、Salesforce、ServiceNow、Zendesk、Seismic、Confluence 和 SharePoint，并且还有其他连接器是否在线取决于当前发布状态。某个连接器处于在线状态并不意味着其内容会自动可搜索——在 Agentic Search 开始摄取之前，必须由管理员启用每个源。这个由管理员控制的模型是有意为之：它旨在让索引范围与组织实际授权的内容保持一致，而不是默认公开每个可连接系统。
#### 索引如何工作：从摄取到可查询索引
当连接器启用后，Agentic Search 会构建已批准内容的可搜索索引，而不是针对每个请求重新查询源系统。该过程分为几个阶段：
1. **摄取** — 已批准内容会从已连接的源中提取，受管理员授权的范围以及正在连接的用户的权限约束。对于诸如云驱动器之类的基于文件的源，文档内容会被检索用于处理，而不只是简单地建立链接。
2. **分段** — 检索到的内容会被拆分为更小的段落，因此检索可以返回与查询相关的文档特定部分，而不是整份文件。
3. **向量化** — 每个段落都会使用嵌入模型转换为数值嵌入，从而使检索不仅能基于精确措辞，还能基于语义进行匹配。
4. **关键词索引** — 内容也会被建立索引用于关键词匹配。Search 和 Ask 功能都依赖关键词匹配以及向量相似度，因此这两种方法是协同运作的，而不是彼此替代。
5. **权限元数据索引** — 用户访问信息会与内容一起建立索引，这些信息来源于源系统自身的原生权限，因此可以在查询时应用基于权限的过滤。
结果是一个客户专属的检索索引——来自某个源的内容会以限定于该客户并受该客户权限管控的形式存储，而不是存储在共享或跨租户的存储中。
#### 图表和数据流可供参考
展示 Zoom 的 Agentic Search 如何连接到第三方应用、服务和数据源的图表——包括连接和索引数据流——可在以下位置找到： [Zoom AI 白皮书](https://library.zoom.com/ai/ai-whitepaper/diagrams#zoommate-third-party-connections-and-indexing).
#### 哪些内容被索引取决于管理员为连接器授权的范围
会被索引的内容取决于管理员为连接器授权的范围。一旦来源连接，索引就会通过持续更新来维护，而不是一次性摄取：
1. **初始同步**：在首次配置时，连接器会对范围内内容进行完整同步，包括现有历史内容。
2. **每日索引更新**：对于某些来源，连接器每天刷新一次范围内内容。
3. **增量同步**：对于其他来源，连接器会在每天持续运行定期同步，仅处理自上次同步以来新增、修改或变更的内容，而不是每次都重新处理整个存储库。
#### 索引检索和实时检索协同工作
Agentic Search 使用两种检索路径，具体采用哪一种取决于来源如何连接以及它包含何种数据——而不是由用户或管理员按每次查询或每个文件夹切换的设置决定。
作为……连接的内容 **账户级数据源** 在管理员面板中会被摄取到按客户区分的索引中，并从那里进行搜索。这是非结构化内容——文档、知识文章和文件——的默认路径，因为预先构建的索引使检索在查询时快速而高效，并生成可供整个组织共享的可搜索索引。
内容可被访问 **通过 MCP 或 API 直接、实时地访问** 在其他情况下：由个人用户授权的个人连接器（例如他们自己的电子邮件、日历或个人云存储）、像 CRM 对象数据这样的结构化记录，以及其他会频繁变化、因而适合在请求时获取最新内容的内容。个人连接器只检索连接用户可以访问的文档，而结构化数据连接则使用其自己的用户身份验证和授权，而不是由索引提供。
由于路径取决于连接方式，同一个底层应用程序可以根据其设置方式以任一种方式访问。作为管理员管理的数据源连接的云存储服务会被建立索引以供组织范围内搜索，而作为个人连接器连接的同一服务则会被直接查询，并限定在该用户自身的访问范围内。
#### 外部 Agentic Search 连接构建于模型上下文协议（MCP）之上
Zoom 与外部模型、工具和数据源之间的连接都基于模型上下文协议（MCP），这是一种用于将模型与工具和数据连接起来的开放客户端—服务器标准。MCP 服务器运行在 Zoom 的边缘，提供一个一致的接口，通过它发起检索请求——既用于从已连接系统进行实时检索，也用于外部智能体将 Agentic Search 作为工具访问。这个标准化传输层用通用连接模型取代了按来源逐一的定制集成。
#### 索引时长因客户、数据量和数据类型而异
某个连接器完成全部索引所需的时间没有固定时间表。所需时间因每个客户而异，取决于要索引的数据量以及所涉及的数据类型。被索引的第三方平台施加的速率限制也是一个影响因素——每个来源系统都会限制在给定时间窗口内可拉取的数据量，而这种限流会因平台、套餐层级和 API 设计而不同。计划对大型或高使用率存储库首次执行索引的客户，应预计需要数周时间，而不是当天或当周即可完成。
#### 索引容量会随 ZoomMate 许可证层级扩展，并在组织级别汇总
索引容量取决于许可证层级，而不是固定的统一配额。每位已授权用户会根据其层级贡献一份按席位计算的容量，这些容量会汇总成一个全组织共享的单一池，而不是分配给每个单独用户。
所有已连接来源和所有用户的已索引内容总量必须保持在组织的合并池内——这意味着某个用户为大型存储库建立索引，会占用与其他所有人相同的共享容量。由于该池会随着每个已授权席位的增加而增长，组织的总容量就是其所有已授权用户贡献之和。
例如，如果一个许可证提供 1GB 存储空间，那么 25 个许可证时，账户总共拥有 25GB 存储空间。100 个用户时，则为 100GB。
计划为大型存储库（完整的 Confluence 空间、较大的 SharePoint 站点、成熟的 CRM 实例）建立索引的组织，应根据预期的总内容量来确定其许可证层级和席位数，而不是根据每个用户的使用模式。可获得额外的索引容量——如需更多信息，请联系你的 Zoom 账户团队。
#### 文件大小和文件类型都会影响哪些内容会被索引
适用两个独立的大小限制，而且它们的行为不同：
* **64 MB 原始文件上限（下载）：** 如果来源文件的原始大小超过 64 MB，它将被跳过，不会下载用于处理。
* **16 MB 处理后内容上限（索引）：** 下载的文件会转换为统一的处理格式。如果生成的处理后文件超过 16 MB，则只索引其前 16 MB 的内容；其余部分不会被索引。
这两个限制的失败方式不同：原始文件过大时会被完全跳过，而处理后文件过大时会被截断而不是排除，因此其开头内容仍会出现在检索结果中，而后面的内容不会。
此外，索引还取决于文件类型，与大小无关。多媒体内容——音频、视频和图像——无论大小都不会被索引。它会在转换为统一处理格式时被移除，早于任何大小限制的评估。所有文档都会索引元数据，但只有受支持的非媒体文件类型才会索引完整内容。对于不受支持的类型，文档仍可通过其元数据被发现，但其内容不可搜索。
#### 管理员目前无法控制内容的索引顺序
目前没有机制允许管理员在已连接来源内优先让某些特定文件夹、空间或内容类型先于其他内容被索引。索引会在已启用连接器中的符合条件内容上进行，但无法设定顺序，这意味着组织无法优先索引其最有价值的内容，应预期索引覆盖会在整个存储库中逐步展开，而不是先从最关键的业务材料开始。
索引也无法安排在选定的时间或频率运行。一旦启用某个来源，索引就会按其自身节奏运行，而不是按照管理员设置的计划运行，因此最好将其视为一个在完成时才完成的后台进程，而不是一个可以围绕特定时间窗口安排的任务。
## **管理、权限与治理**
#### 管理员可以控制连接哪些来源，而用户则对自己的访问进行身份验证
连接器由管理员启用，管理员决定哪些第三方系统可在组织内用于索引和搜索。启用连接器会使某个来源对组织可用，但并不会本质上授予其内容访问权限。每位用户都必须单独对该来源进行身份验证——一旦完成身份验证，他们的检索权限就会与其在来源系统中的现有权限一致，因此他们只能显示自己在该系统中原本就可访问的内容。
#### 检索会感知权限且为只读
Agentic Search 旨在应用每个来源系统的访问控制，因此答案只会反映该用户已经被允许查看的内容；两个提出同一问题的用户，可能会根据其在第三方数据源中的各自权限获得不同结果。检索是只读的，并遵循各来源的保留策略——例如，Zoom 会议内容遵循其适用的保留期限，而不是由搜索层单独保留。由于检索在查询时受治理且感知权限，它也提供了批量导出原始转录或记录的替代方案，使访问权限与原始第三方来源保持一致。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://library.zoom.com/technical-library/zh/ai/ai-whitepaper/agentic-search.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.