Elasticsearch 9.2 新增 .integration_knowledge 系統索引，供 Fleet 的 AI 助手使用

9.2 新增 .integration_knowledge 系统索引。这条改动大多数用不上——它是给 Fleet 和 AI 助手准备的。但它透露了一个方向上的信号：ES 开始为"AI 助手来理解集成"提供内置的存储位置。

说明

来源和边界先交代：本文的依据出自 v9.4.2 标签下的官方文件（9.2.0.yml、KibanaOwnedReservedRoleDescriptors.java），文中引用的原文均来自这些文件。我没有启动集群、也没有跑测试，示例取自官方示例；哪些是文档写明、哪些是我的推断，正文里逐处标注。

图 1：官方文件 9.2.0.yml（v9.4.2 标签）。来源：GitHub elastic/elasticsearch v9.4.2 9.2.0.yml

官方条目

9.2 的 changelog 标为 feature（9.2.0.yml 第 604–607 行 @ v9.4.2），area: Infra/Core，PR 132511。

只有一行 summary。好在源码里有注释说明用途。

图 2：官方文件 KibanaOwnedReservedRoleDescriptors.java（v9.4.2 标签）。来源：GitHub elastic/elasticsearch v9.4.2 KibanaOwnedReservedRoleDescriptors.java

它是干什么的

最直接的证据在安全侧的权限定义里（KibanaOwnedReservedRoleDescriptors.java 第 180–186 行 @ v9.4.2）：

// Integrations knowledge base: Fleet creates, manages, and uses this index to store knowledge base documents to be consumed
// by AI assistants to support integrations
// assistants.
RoleDescriptor.IndicesPrivileges.builder()
    .indices(".integration_knowledge*")
    .privileges("read", "write", "create_index")
    .allowRestrictedIndices(true)
    .build(),

注释把三件事说清楚了：

• 谁创建和管理：Fleet；
• 装什么：知识库文档（knowledge base documents）；
• 给谁用：AI 助手，用来支持集成（to support integrations）。

连起来讲就是：Fleet 把"关于各种集成的知识"写进这个索引，AI 助手读它，从而能回答集成相关的问题。

"集成"和"知识库"分别指什么

这两个词需要解释一下，否则这段注释不太好懂。

集成（integration）：Elastic Agent 用来采集某种数据源的软件包。比如采集 Nginx 日志的集成、采集 MySQL 指标的集成。每个集成有自己的配置方式、字段定义、常见问题。

知识库（knowledge base）：这里指的是供检索的文档集合——是针对具体集成的说明性内容，不是 ES 产品文档。

AI 助手：能理解和生成自然语言的工具。它回答"我该怎么配这个集成"这类问题时，需要参考资料。

所以这个索引的用途是：给 AI 助手提供一个可检索的、关于集成的知识来源。

图 3：官方页面 PR #132511。来源：GitHub elastic/elasticsearch pull/132511

为什么需要一个专门的索引

顺着想一层：为什么不直接让 AI 助手去读产品文档？

能想到几个理由（这是理解，官方没解释设计动机）：

一，检索需要索引。 AI 助手要"找到相关段落"，靠的是检索。文档放在索引里，才能用 ES 自己的检索能力（包括向量检索）去找。这就是 ES 作为数据库该干的事。

二，内容需要随版本走。 不同版本的集成配置可能不同。放在集群里的索引，天然跟集群版本绑定，不会出现"助手引用了别的版本的文档"这种问题。

三，权限需要可控。 从前面那段代码能看出，这个索引的读写权限是分配给特定保留角色的，且 allowRestrictedIndices(true)——它是受限索引，普通用户碰不到。知识库内容不该被随意改写。

第三点最关键：把知识放进集群，才能用集群的权限模型管它。这跟"把文档放外部 HTTP 服务"相比，安全性和可控性都不在一个层级。

权限是怎么配的

回到那段代码，几个细节值得说：

.privileges("read", "write", "create_index")
.allowRestrictedIndices(true)

权限是 read + write + create_index，没有 delete。 判断这是有意的——Fleet 可以建、可以写，但不能删。删的权限通常不轻易给。

allowRestrictedIndices(true) 说明它是受限索引。这类索引默认不允许普通访问，必须显式声明才能授权。系统索引通常都这样处理，目的是防止误操作。

它挂在 Kibana 拥有的保留角色下（从类名 KibanaOwnedReservedRoleDescriptors 能看出）。也就是说：管理这个索引的是 Kibana 侧的组件（Fleet），不是终端用户。

对使用者意味着什么

如果没有用 Fleet 和 AI 助手功能，这条改动对你没有任何影响。 索引不会平白无故产生数据——它是 Fleet 在用相关功能时才创建和写入的。

如果你在用 Fleet，有几点可以留意：

• 集群里可能多一个 .integration_knowledge* 开头的索引；
• 它的权限由保留角色管理，不需要你手动配；
• 作为受限索引，普通查询默认看不到它。要查的话得显式处理。

如果你在做 AI 助手相关的集成，这个索引值得关注——它是 Elastic 官方为这类场景准备的位置，自己再建一套知识库索引之前，可以先看看这个能不能用。尤其是当你需要的知识正好是"怎么配某个集成"时，它大概率比你自己攒的更准、更新。

系统索引意味着什么

.integration_knowledge 前面那个点号不是随便加的——以 . 开头且被注册为系统索引，会带来一整套不同于普通索引的规则。这点值得说，因为它决定了你能对它做什么。

一，默认不可见、不可访问。 系统索引是受限的，普通查询不会碰到它，普通用户也没有权限。这就是为什么前面那段权限定义里要显式写 allowRestrictedIndices(true)——不开这个开关，授权语句对系统索引无效。

二，管理方式不同。 系统索引的创建、映射、生命周期通常由管理它的组件（这里是 Fleet）负责，不是用户。你不需要建它，也不该改它的 mapping。

三，升级时会被特殊处理。 系统索引有专门的迁移机制，版本升级时可能需要格式转换。这也是为什么不该往里塞自己的数据——迁移逻辑只认它自己期望的内容。

在别的篇里讲过"数据比代码活得久"（Watcher 的 types 字段 Watcher 的 types 字段拖了好几个大版本才删掉）。系统索引更是如此：一旦有内容存在里面，后续的兼容负担就开始了。

所以看到"新增一个系统索引"，可以默认一个判断：这是给某个组件用的内部存储，不是给你用的。要用它提供的数据，走那个组件提供的接口，而不是直接读写索引。这条默认判断对 ES 系统索引成立，能快速分辨"要关心的"和"不用管的"。

ES 在为 AI 场景补基础设施

把这条改动放到 9.x 的大背景里看，会更有意思。

9.x 里跟 AI 相关的改动不少，前面写过几篇：

前几篇都是在做"让 ES 能存向量、能检索向量"，属于能力建设。

本篇不一样——它是第一个明确"给 AI 助手用"的内置存储。 从能力到应用，这一步跨得挺明确。

判断是：这个方向会继续。AI 助手要接进数据系统，需要解决"知识从哪来"的问题，而 ES 恰好是天然的答案。把知识库做成系统索引，等于给了个官方答案。

（说明：上面关于"方向会继续"是推断，不是官方表态。判断依据是这类索引一旦建立就有了兼容负担，通常不会只用一次。）

自己建还是用它

如果你在做类似的事（给 AI 助手准备知识来源），会面临一个选择：用这个索引，还是自己建一个？

建议是先看看 Fleet 的这个功能能不能满足，理由：

• 它是官方维护的，内容跟着版本更新，不用自己维护；
• 权限、生命周期都由系统管，省掉一堆运维工作；
• 跟 Elastic 生态的其他部分是打通的。

适合自己建的情况：

• 你的知识不是关于 Elastic 集成的（比如是自己业务的文档）——那这个索引不适用，它装的是集成知识；
• 你需要完全控制内容的更新时机和方式；
• 你用的版本还没有这个索引（9.2 之前）。

判断依据其实很简单：看你的知识内容是什么。是关于 Elastic 集成的 → 用官方的；是自己的业务知识 → 自己建。

不要做的事：往 .integration_knowledge 里写自己的业务文档。它是系统索引，内容和生命周期由 Fleet 管理，写进去可能被覆盖，也可能影响 Fleet 的功能。

怎么确认你的集群里有没有它

如果你想知道这个功能有没有被启用，不用猜，直接看。

系统索引默认不在普通查询里出现，但可以直接指定名字查：

# 看有没有这个索引
curl -s 'localhost:9200/_cat/indices/.integration_knowledge*?v'

# 有的话看它装了多少内容
curl -s 'localhost:9200/.integration_knowledge/_count'

没有输出（404）是正常的——说明 Fleet 还没用上这个功能，或者你没装 Fleet。

如果查到了，可以再看一眼文档长什么样：

curl -s 'localhost:9200/.integration_knowledge/_search?size=1&pretty'

看一条就够知道它装的是什么形态的内容了。

（说明：这个索引的实际 mapping 和文档结构未核实——源码里只看到权限定义，没看到索引定义。上面这几条命令是通用的查看方式，具体返回什么以你的集群为准。）

为什么值得花这一分钟：如果你的集群里突然多了一个不认识的索引，知道它是什么、归谁管，比忽略它强。系统索引出问题时的排查路径跟普通索引不一样，先认清身份能省不少事。

如果不想要它

有人会问：能不能删掉或者禁用？

不必处理，也不该手动删：

• 它只在 Fleet 用到相关功能时才产生数据，不用就不存在；
• 手动删系统索引，可能让管理它的组件进入异常状态；
• 即使删了，Fleet 下次需要时还会重建。

所以正确的做法是不用管它。如果确实在意集群里有这么个索引，该做的是关掉 Fleet 侧对应的功能，而不是在 ES 侧删索引。

写在最后

这条改动对多数人没有直接影响——它服务的是 Fleet + AI 助手这条链路。

我的判断是：这条值得写是因为它的方向性比本身的内容更有意思——ES 开始为"AI 助手理解这个系统"提供内置位置。这类改动在 changelog 里往往只有一行，容易被跳过，但它标示了产品在往哪走。

一，.integration_knowledge 是 Fleet 创建和管理的、给 AI 助手用的知识库索引。我的建议是不要自己往里写数据，它归 Fleet 管。 用途是"支持集成"——让助手能回答"这个集成怎么配"这类问题。

二，它是受限索引，权限挂在 Kibana 的保留角色上，有 read/write/create_index 但没有 delete。 普通访问默认看不到——要授权必须显式开 allowRestrictedIndices。

三，别往里写自己的东西。 它是系统索引，内容由 Fleet 管。要用它提供的数据，走 Fleet 的接口，不要直接读写索引。

四，不用管它。 没有 Fleet 相关功能就不会产生数据；真要去掉，也该在 Fleet 侧关功能，而不是在 ES 侧删索引。

另外诚实标注了两点："为什么需要专门索引"的三条理由是理解，官方没有解释过设计动机；"方向会继续"也是推断，不是官方表态。源码注释是看到的唯一官方说明，已逐字引用。

参考

• changelog 9.2.0：Add .integration_knowledge system index for usage by AI assistants（第 604–607 行）@ v9.4.2
• KibanaOwnedReservedRoleDescriptors.java：用途注释（第 180–182 行）与权限定义（第 183–186 行）@ v9.4.2
• PR 132511

本文对照 Elasticsearch v9.4.2 标签的 changelog 与源码核对，引文与代码逐字取自原文。"为什么需要专门索引"的三条理由、"这个方向会继续"均为判断，官方未解释设计动机、未做相关表态，已在正文标注。该索引的完整读写路径与 Fleet 侧行为未逐个核实。撰写时未启动集群、未运行测试。