Agent 引擎版使用 Stateless（无状态）架构，让存储容量、写入吞吐和查询能力可以分别扩展。持久数据由对象存储按量承载和计费，无需预购固定存储容量或手动扩容对象存储；计算资源按实际读写负载配置，本地缓存围绕活跃数据规划。
例如，历史知识库持续增长、日常只访问少量内容时，可以把新增数据交给对象存储承载，将计算和缓存资源集中在活跃访问上，减少为低频数据预留资源的压力。
数据存在哪里，节点分别做什么
|
组成部分 |
主要职责 |
规划时关注什么 |
|
索引节点 |
处理写入、索引构建和后台合并，将需要持久保存的数据写入对象存储。 |
导入吞吐、持续写入量和索引构建开销。 |
|
查询节点 |
执行查询，并在本地缓存查询所需的数据；缓存未命中时从对象存储读取。 |
查询并发、向量检索开销、活跃数据集和缓存容量。 |
|
对象存储 |
保存索引数据、写入日志和运行所需的持久状态。 |
无需选配容量或自行扩容，按实际用量计费。 |
通过创建和连接实例，可以了解控制台中的节点配置和接入地址。
按写入和查询负载分别配置资源
写入高峰与查询高峰不必使用同一套资源配置。可以针对实际瓶颈增加对应角色的资源，减少为单一负载同时扩大两侧资源的浪费：
-
批量导入或持续写入量增加时，扩展索引节点，提升写入和索引构建能力。
-
查询并发增加时，扩展查询节点，增加查询计算和缓存资源。
-
总数据量增长、活跃数据变化不大时，持久存储按用量增长；本地缓存仍围绕活跃数据规划，无需按全量数据同比扩大。
节点规格和数量以购买页提供的配置为准。分片规划、Bulk 并发和查询范围也会影响资源利用率；冷数据访问较慢时，可在用户打开知识库前预热 Slice 缓存，减少首次查询的读取等待。
写入成功后，什么时候能查到
按 ID 确认写入，可使用默认实时读取的 GET/MGet，无需刷新；主分片不可用时的读取边界见按 ID 确认写入。以下说明按条件搜索的可见性。
写入确认与查询可见性是两个阶段。写入日志持久化后可以确认写入；索引节点生成并发布新的可搜索版本，查询节点加载该版本后，数据才进入搜索结果。因此，写入请求成功后立即发起搜索，可能暂时看不到新文档。
常规写入不应传 refresh，应等待后台自动刷新。更频繁地发布和加载数据版本会增加资源开销；默认刷新间隔和同步等待的使用条件见Refresh 与查询可见性。
查询副本与可用性
查询由查询节点上的副本分片提供。查询副本和可承载这些副本的查询节点都需要按可用性目标规划；仅有持久数据并不等于查询服务已经就绪。节点变化或恢复后，还应通过真实查询确认服务可用，并观察缓存恢复期间的延迟。
创建 Collection 时，index.number_of_replicas 默认为 2。设置为 0 时无法提供查询，设置为 1 只能满足基本查询要求，不具备查询高可用能力。生产环境建议至少配置 2 个查询节点，以便单个查询节点故障时仍有可用副本提供查询。查询副本主要承担查询和缓存工作，增加副本数不能替代备份策略。传统 Elasticsearch 的数据层级、ILM、Translog 和副本等待参数也不能直接照搬，见与传统有状态 Elasticsearch 的差异。