从 Agentic Search 看大模型时代的存储优化

本文为原创文章，版权归作者所有。未经许可，禁止转载。

审阅草稿

这篇文章目前是供合作者审阅的 draft 版本，结构、图示和技术表述仍可能继续调整。

大模型推理看起来是 next-token prediction：模型根据已有上下文预测下一个 token，再不断重复这个过程。但在真实系统里，推理很少只是“生成”。尤其在 Agentic Search 场景中，提示模板、会话历史、长期记忆、检索结果、工具返回、缓存产物与数据库记录，都会以不同形态进入推理链路。模型并不是在真空中猜下一个词，而是在“继续生成”和“引用既有信息”之间不断做选择。

因此，大模型时代的存储不再只是“把东西放起来”。更准确地说，存储是一套围绕**可引用性**建立的机制：让信息在合适的时刻、以合适的形态、用可控的成本被再次使用，从而改变推理的自由度与不确定性。

问题也随之从“数据放在哪里”变成了“引用路径如何被组织”。一条信息要先被判断为值得引用，再被建模成可调用的形态，随后被检索、回查、压缩并注入上下文。越往下走，抽象的“知识”越会变成具体的 IO、延迟和成本。

沿着这条引用路径继续往下看，传统搜索里的许多默认假设会慢慢松动。过去我们习惯把索引想象成一个在线服务：query 来了，系统在全局索引上找最近邻，再把结果返回。这个模型默认每次查询相对独立，也默认索引需要被一组常驻机器持续服务。

Agentic Search 的形态不太一样。一个 Agent 在执行任务时，很少只问一次；它会沿着同一个目标反复追问、调用工具、验证证据、修正计划。于是，真正反复被触碰的不是整个知识库，而是围绕当前任务形成的一小片局部工作集。全量数据仍然可以很大，甚至更适合沉在对象存储里；靠近 Agent 的，则是少量语义相关的 partition、payload page、工具结果和验证证据。到这一步，索引也不再只是一个固定精度、固定服务形态的结构：IVF 负责把语义邻域收束成少量行，OPQ/PQ 可以把精度和成本拆成可渐进读取的列，Policy 再决定这次引用要展开到哪里。

从生成到引用：Agentic Search 的存储问题¶

推理不只是 next-token prediction¶

传统语言模型的基本动作是预测。但工程系统的基本动作往往是选择：这个事实要不要查数据库？这段背景要不要走检索？这次工具结果要不要缓存？上一次会话的结论是否仍然可信？用户偏好应该直接注入，还是按需召回？

一旦把推理抽象成“生成 / 引用”的序列决策，许多看似分散的模块就会落到同一张图上：上下文工程、长期记忆、RAG、搜索、工具调用、缓存、日志回放，都是外部可引用数据源；压缩、重排、裁剪、权限、TTL、命中率、延迟与 token 成本，都是围绕引用路径展开的系统优化。

这也是为什么存储会在大模型系统中重新变得重要。不是因为模型突然需要更多磁盘，而是因为系统越来越依赖“把不确定生成替换成可验证引用”。

Agentic Search 的引用路径¶

Agentic Search 可以理解为 Agent 在执行任务时主动寻找、筛选、回查、压缩并注入外部信息的过程。它不是传统搜索框里的单次查询，而是一条贯穿任务执行的引用链路：

Memory / Harness / Domain Data
  -> Retrieval Intent
  -> Embedding + Metadata Filter
  -> ANN Candidate
  -> Payload Fetch
  -> Rerank / Compress / Inject
  -> Model Generate

这条链路里的每一步都对应一种存储问题。Memory 和 Harness 决定“什么值得被引用”；数据格式决定“引用对象能否被稳定建模和调用”；检索系统决定“如何找到候选”；物理布局决定“候选 payload 如何被低成本读出”；Policy 则决定“什么时候引用、引用多少、用哪条路径”。落到运行时，它经常会变成一个朴素的选择：这一步是继续生成，还是引用已有数据；如果引用，要引用到多深、多少、以什么成本引用。

更重要的是，Agentic Search 会系统性改变搜索的访问分布，也改变搜索系统的部署形态。传统搜索更像一组彼此独立的 query，不断打到同一个全局索引；为了服务这份索引，系统往往需要一组常驻机器来承载 shard、replica、内存缓存和在线 fanout。而 Agent 在真实任务中会连续追问、调用工具、验证证据、修正计划，这些动作通常围绕同一个任务、租户、领域或会话上下文展开。于是，全局知识库没有变小，但每个正在运行的 Agent 进程都会形成自己的局部工作集：少量热 partition、热文档、热 payload page、近期工具结果和验证证据会被反复访问。

这也是为什么缓存、预取、局部索引和物理布局会变得重要。系统仍然需要拥有全量知识，但全量数据和索引可以更自然地放在 S3 这类对象存储上，由 Agent 进程按任务拉取自己需要的一小片热数据。不过，对象存储只是事实底座，不是模型友好的引用接口；缺少封装时，LIST、元数据读取、长 payload 和分页碎片都会转化为更多工具调用与上下文成本。访问不再只是“所有请求共享一个大缓存”的问题，而是每个 Agent 进程都可以把自己的任务上下文沉淀成一个很小、可复用、可淘汰的 working set。存储优化的目标，就是让这些小工作集更容易被再次访问。

存储优化的目标：让引用进入可控成本曲线¶

所以，Agentic Search 的存储优化目标不应该写成“检索越快越好”，而应该写成：让不同查询形态进入不同成本曲线。

简单问题、低 payload、小 top-k 查询，重点可能是少做事、少 refine、少引入额外状态；复杂问题、大候选集、重 payload、需要 rerank 或证据拼接的查询，才值得付出更多检索和回查成本。存储系统要做的不是给所有 query 一套默认配置，而是让 Agent 能在运行时选择合适的引用路径。

引用什么：Memory、Harness 与数据格式¶

Memory：历史、偏好与任务状态¶

模型侧的存储，不等同于把聊天记录永久保存下来。它的目标是把历史交互、环境反馈、外部知识与中间结论组织成当前步骤可有效消费的状态，让模型更少“猜”、更多“引用”。

在 Agent 场景中，记忆通常可以分成三类：

事实记忆：用户偏好、环境状态、明确事实与长期稳定约束，回答“智能体知道什么”。
经验记忆：过去行动中的成功、失败与策略总结，回答“智能体如何改进自身”。
工作记忆：当前任务或会话中的临时状态、目标、计划与中间结论，回答“智能体现在正在处理什么”。

这里真正困难的不是“记住更多”，而是“在有限窗口和推理预算里放什么最值”。记忆系统需要在成本、质量与稳定性之间做权衡：压缩和摘要能提高信息密度，但可能丢失关键细节；长期记忆能提升连续性，但错误、过期或互相矛盾的信息会污染推理；外部状态能降低遗忘风险，但写入、晋升、去重与冲突消解本身又会引入新的不确定性。

Harness：标准、证据与可执行环境¶

如果把视角从单次模型调用切到 Agent，存储问题会进一步扩展。Agent 需要引用的不只是知识库中的事实，还包括任务的当前状态、完成定义、工具使用方式、验证证据、历史决策与人类反馈。也就是说，Agent 的长期能力很大一部分来自 harness，而不只来自模型参数。

长程 Agent 的典型失败模式并不神秘：上下文窗口填满后开始失去连贯性；跨 session 后不知道上一轮做到了哪里；做了一半就提前宣布完成；或者在自评时过于宽松，忽略真实用户路径里的问题。Anthropic 的 long-running agent harness 和 OpenAI 的 Codex harness engineering 都指向同一个结论：要让 Agent 稳定工作，必须把执行环境本身设计成模型可读、可执行、可验证的外部状态系统。

这个外部状态系统通常由几类工件组成：

任务状态：progress log、execution plan、git history、已完成/未完成列表，让新 session 能快速接班。
完成标准：feature list、acceptance criteria、sprint contract、评测 rubric，防止 Agent 做太多、做太少或自行修改验收口径。
可执行入口：init script、开发环境脚本、工具说明、MCP/SDK 接口，让 Agent 不必每次重新猜测如何启动、查询和验证系统。
验证证据：测试结果、浏览器自动化截图、日志、trace、metrics、CI 状态，把“看起来完成了”转化成可回放证据。
治理与约束：lint、结构测试、权限、hooks、架构规则和文档 freshness 检查，把人类偏好与系统不变量沉淀为机械约束。

Multi-agent system 也可以放在这个框架下理解。它的价值不是简单“多几个模型一起干活”，而是把不同类型的引用和判断拆开。Planner 把模糊意图扩展成可执行规格；Generator 按规格产生变更；Evaluator 用测试、浏览器、日志或 rubric 去验证结果。职责隔离的关键收益在于：生成者不再负责给自己打分，评价者可以被调成更怀疑、更具体、更贴近验收标准。

但 harness 复杂度不能无条件增加。每一个 planner、evaluator、context reset、subagent 或 review loop，都是在假设“当前模型单独做不好某件事”。当模型能力变化、任务类型变化、工具接口变化时，这些组件是否仍然必要，都需要重新验证。好的 harness 不是越复杂越好，而是把模型当前不稳定的能力外置为可引用、可检查、可替换的系统能力。

数据格式：从结构化工件到 AI-native dataset¶

数据侧的存储关注的是：信息以什么形态存在，才真正能被模型和系统调用。原始内容本身通常不够。大模型场景中的一条数据，除了 text、image、audio、tool trace 等内容，还需要明确的类型与维度，例如任务类型、语言、领域、难度、时间、来源、权限、置信度、输出格式约束、上下文依赖等。这些维度决定了数据能否被路由、过滤、对齐、评测和追溯。

在轻量级和快速迭代阶段，Markdown、YAML、JSON 与 Jinja 往往承担这种建模功能。Markdown 适合承载规则、语境、边界、流程与说明，例如 AGENTS.md、SKILL.md、Dataset Card；YAML 适合表达配置、split、子集入口和模板元数据；JSON 适合承载可严格解析的样本结构、评测协议、通过标准与工具调用记录；Jinja 则把 prompt 建模成“样本到输入/输出”的映射函数。

当数据规模和扫描需求上来后，Parquet 这类列式格式会成为更自然的底座。LLM 数据工作负载经常需要对海量样本反复做过滤、分桶、采样、统计、质量分层、去重与归因，这些操作天然依赖列投影和条件过滤。Parquet 的优势不是“更像 AI 格式”，而是把 schema、列式压缩、嵌套结构和高吞吐扫描固化为默认能力。

但 Parquet 也有边界。Agentic Search 不只是扫描结构化表，而是要在 embedding、metadata、长文本 payload、工具轨迹和多模态 blob 之间做随机访问、过滤和回查。Lance 这类面向 AI 工作负载的格式，正是在这个方向上把“检索、随机访问、多模态存储”下沉为底座能力。

换句话说，格式的演进方向并不是从“文件”走向“更复杂的文件”，而是从“数据被保存”走向“数据可被调用”。

如何读出：Lance 存储结构与 Agent Search 局部性¶

Lance 如何组织 embedding、metadata 与 payload¶

在 Agentic Search 里，一条样本通常不是单纯的文本。它至少包含三类信息：用于语义召回的 embedding，用于过滤、权限和路由的 metadata，以及最终要交给 reranker 或模型阅读的 payload。一个面向 AI workload 的存储格式，需要让这三类信息在同一数据资产中协同工作。

可以把 Lance 粗略理解为一个面向随机访问和向量工作负载优化的列式数据集。它通过 manifest 记录数据集版本和 fragment 组成；每个 fragment 内部按列组织数据，列数据再被拆成适合读取和跳过的物理单元。这样做的好处是：metadata filter 可以只读相关列，embedding 可以参与向量索引，payload 又可以在候选确定后被按 row id 回查。

这和传统“对象存储放原文、数据库放路径、向量库放 embedding”的三套系统相比，有一个重要区别：embedding、metadata 与 payload 不再只是松散拼接，而是能在同一个数据集抽象下被索引、过滤、回查和版本化。对于 Agent Search 来说，这意味着“找到候选”和“读回证据”可以被放到一条更统一的引用路径里优化。

存储格式不只是 schema，也是访问布局¶

讨论存储格式时，很容易只看到逻辑层：有哪些列、字段类型是什么、metadata 如何表达、embedding 维度是多少。但对 Agentic Search 来说，格式还包含另一层同样重要的东西：访问布局。也就是说，当一批候选 row id 被召回之后，它们在物理文件中的相对位置如何，payload 是否能被连续读出，metadata filter 是否能跳过无关区域，向量列和文本列是否能按不同访问模式分别优化。

可以把 Lance 在这里承担的角色拆成两层：

逻辑层：embedding / metadata / payload 共同描述一条可引用样本
物理层：fragment / column / page / row id 决定这条样本如何被读出

逻辑层解决“这是什么数据、能不能被检索、能不能被过滤、能不能被模型引用”；物理层解决“这批数据被引用时，要发起多少次读取、读多少无关字节、能不能把相邻读取合并”。前者决定可调用性，后者决定调用成本。

这也是布局设计的意义。传统列式格式通常围绕分析型扫描优化：尽量只读相关列，利用压缩和统计信息减少全表扫描成本。Agentic Search 的访问模式则更接近“先用向量索引找到一批 row id，再按 row id 回查 payload”。如果这些 row id 在物理上高度离散，系统就会面对大量小 range read；如果它们在语义上相近、物理上也相近，reader 就更容易把多次回查合并。

因此，本次优化的着力点不是改变“这条数据长什么样”，而是改变“相似数据在物理上是否挨在一起”。reorder 的价值正是在这里：它试图把索引层已经存在的语义分区，投影到存储层的物理布局上，让 Agent Search 的局部性不只停留在向量空间里，也能体现在 IO 路径上。

IVF_PQ 查询中的候选召回与 payload 回查¶

以 IVF_PQ 为例，查询并不是直接把所有向量扫一遍。系统会先根据 query embedding 找到若干 IVF partition，再在这些 partition 内用 PQ 近似距离得到候选；如果需要更高质量的结果，还会进一步 refine，读取原始向量或 payload 做重排、裁剪和注入。

这里有一个经常被忽略的事实：向量索引只解决了“候选在哪里”，但 Agent 真正需要引用的是候选背后的文本、工具结果、日志片段或文档上下文。也就是说，ANN candidate 之后还有一次 payload fetch。对于少量候选查询，这个回查成本可能不显眼；但当系统需要读回较大候选集做 rerank、聚合或证据拼接时，payload fetch 就会成为引用路径里的主要成本之一。

候选 row id 如果在物理上高度离散，就会产生大量随机读；如果它们在文件里相邻，reader 就有机会把多个小读合并成更少的连续 range read。到这里，语义检索问题已经变成了存储布局问题。

Agent Search 的局部性：领域、会话、租户与候选集¶

通用 ANN benchmark 往往假设 query 分布近似均匀，但 Agentic Search 的真实 workload 通常不是这样。一个法律、科研或企业知识库 Agent 的用户 query，会围绕少量语义区域反复访问相邻证据；同一个会话里的连续问题，往往指向同一批文档、概念、任务状态和工具结果；企业知识库还天然存在租户、权限、项目和团队边界。

这种局部性至少体现在几个层面：

领域局部性：垂直领域 query 会围绕少量主题区域反复访问。
会话局部性：同一任务中的连续检索常常命中相近文档和证据。
租户局部性：企业数据按团队、权限和项目天然分区。
候选局部性：rerank、evaluator、multi-agent review 往往需要读回一批相关候选，而不是只取一个点。
时间局部性：最近引用过的 trace、feature spec、工具结果和历史决策容易再次被引用。

如果 ANN partition 与 payload 的物理布局能对齐这种局部性，系统就有机会把语义上的相近访问转化为存储层的顺序访问。

这里的关键变量可以称为**连续性**。在 base/shuffled 数据中，IVF/PQ 虽然在语义空间里找到了相邻候选，但这些候选对应的 row id 可能散落在不同 fragment、page 或对象存储 range 上；一次 top-k 回查会退化成多次小 range read。compact 之后，相同 partition 或相邻 partition 中的样本在物理上更接近，候选 row id 的跨度变小，payload range 更容易被合并读取。连续性变好，并不一定意味着读字节必然更少，因为合并 range 可能会读入一些桥接字节；但它通常会减少请求次数和随机 IO，这才是对象存储路径上最有价值的收益来源。

对象存储路径上的 range read、IOPS 与 bridge bytes¶

在本地 NVMe 上，随机读和顺序读的差异已经足以影响 p50；到了对象存储路径，差异会进一步放大，因为每次 range read 都可能带来请求开销、网络 RTT 和调度开销。此时，真正影响延迟的不只是读了多少字节，还包括读了多少次、每次读之间是否可以合并、以及为了合并相邻 range 额外读取了多少“桥字节”。

Lance reader 会尝试把相邻 range read 合并。当 row id 在物理上接近时，IOPS 可以显著下降；但合并也可能带来额外 bytes。旧直觉“少字节必更快”在这里并不总成立。对 Agent Search 来说，更接近 wall-time 的变量常常是 range read 次数、IOPS、payload 大小和对象存储路径上的 RTT 共同作用。

如何优化：Reorder、Adaptive nprobe 与策略封装¶

Reorder：把语义局部性转成物理局部性¶

reorder --compact 的目标，是把 IVF partition 从纯粹的索引结构提升为物理布局的一等维度。IVF partition 可以看作语义空间里的粗粒度桶；如果 Agent query 会反复命中相近 partition，那么这些 partition 对应的 row 最好在物理上也尽量接近。

这就是 partition-primary compact 的核心思想：让同一 IVF partition 中的 row 在磁盘上更连续，从而让 ANN 候选后的 payload 回查更容易被合并成连续 range read。它优化的不是向量距离计算本身，而是“候选已经找到之后，证据如何被读回来”。

这个优化成立需要一个前提：查询确实会读回一批相关候选。若 Agent 只需要很少的 top-k，payload 又很轻，那么物理紧凑布局带来的 range 合并收益可能还没来得及显现，就已经被额外读取的桥字节、refine 开销、网络 RTT 或调度开销抵消。相反，当系统需要读回较多候选做 rerank、证据拼接或多轮验证时，payload 回查会放大物理局部性的价值。

因此，compact 不能写成“默认加速器”。它更准确的定位是：当引用路径进入重候选、重 payload、对象存储 range-read 压力区间时，把语义局部性转化为 IO 局部性的布局策略。

Adaptive nprobe：动态控制检索预算¶

如果说 reorder 是从数据布局侧优化引用路径，那么 adaptive nprobe 是从查询策略侧控制引用预算。

固定 nprobe 的做法，是每次查询都探测同样多的 IVF partition。这种方式简单、稳定，但对 Agent Search 来说并不总是合适：有些 query 很明确，少量 partition 已经能给出足够好的候选；有些 query 更开放，必须扩大探测范围才能获得足够召回。用同一 nprobe 处理所有 query，本质上是在给所有引用请求分配相同预算。

adaptive_nprobes 的思路是从较小的探测范围开始，根据候选分数、margin 或置信度判断是否继续扩大搜索。它对应 Agentic Search 内部更细粒度的“继续找 / 停止找”决策：简单 query 尽早停止，困难 query 才继续扩大搜索半径。

这和 reorder 是两类不同优化：reorder 改变“数据怎么放”，adaptive nprobe 改变“查询读多少”。前者影响候选回查的物理访问模式，后者影响候选召回的搜索预算。两者可以组合，但不能混在一起归因。否则我们会误以为某个布局更快，实际上收益来自查询侧早停；或者反过来，把查询策略的风险错误归因给存储格式。

实验室验证：收益来自重引用路径，而不是所有查询¶

为了验证上述判断，我们做过一组可复现实验：在 Lance 数据集上构造 Wikipedia chunk + embedding 的 Agent Search 近似 workload，并分别在本地 NVMe 与 S3 模拟路径上比较 shuffled baseline 与 partition-primary compact 布局。实验并不是为了证明某个配置永远最佳，而是为了验证一个机制判断：物理布局优化是否只在重引用路径中稳定转化为收益。

结果符合这个机制判断：当 top-k 很小、payload 很轻时，compact 并不会稳定带来延迟收益，有时还会因为额外读和调度开销而变慢；当候选集增大、payload 回查变重时，物理局部性开始稳定转化为更少的 range read、更低的 IOPS 和更好的 p50。对象存储路径会进一步放大这个边界：轻量查询更容易被 RTT 和调度成本吞掉收益，而重 payload 查询更容易从 range 合并中获益。

为了给量级一个直觉：在我们的一组实验室数据中，重候选 / 重 payload 查询上，紧凑布局能带来约三到四成的 p50 下降，并显著减少读 IO；而轻量 top-k 查询基本只能算持平，甚至可能退化。这里重要的不是某个具体 K 或某个实验配置，而是边界本身：布局优化服务的是重引用路径，不是所有 ANN 查询。

这说明 Agent Search 的优化不能只问“compact 是否更快”，而要先问：top-k 多大、payload 多重、是否需要 rerank、是否在对象存储路径、并发多高、refine 多强，以及当前 query 是否具有领域或会话局部性。

Policy 封装：让不同 query 进入不同成本曲线¶

工程侧真正要做的，不是简单选择“数据库、搜索还是 RAG”，而是把引用路径封装成可组合、可观测、可迭代的组件：

Retriever 负责召回候选，并区分语义检索、关键词检索与 metadata filter。
Ranker 负责重排、裁剪和选择最终注入片段。
Cache 负责复用热点 query、近期工具结果和局部证据。
Policy 负责根据 query 形态选择轻量检索路径、局部性优化路径或重 payload 回查路径。
Logger 和 Hook 负责记录候选、注入片段、token 成本、延迟、IO 与失败原因。

这里的观测不只是为了调试，而是为了判断“引用是否真的值得”。每次引用都应该留下证据链：为什么检索、命中了什么、注入了什么、节省或增加了多少 token 与延迟，以及最终是否改善任务结果。

其他优化方向也应该放在这个策略框架里讨论。例如，小 k 和大 k 可以使用多版本索引；payload-aware layout 可以同时考虑 partition、文档归属、租户、权限和 chunk 邻接关系；session-local cache 可以复用近期候选和 rerank 结果；hybrid retrieval 可以先用关键词或 metadata filter 缩小范围，再在局部集合里做向量检索；hot/cold tier 可以把高频 partition 放到更近的存储层。

这些优化都围绕同一件事：Agentic Search 不是一次固定查询，而是一组带局部性的引用决策。存储系统要暴露足够多的策略维度，让 Agent 在运行时选择合适的引用成本，而不是被某个默认索引配置锁死。

未来工作：渐进式索引与按需精度¶

沿着这个方向继续走，索引本身也可以变成渐进式读取的对象。今天的向量索引通常在构建时就固定了精度与体积：要么使用较小但误差更大的压缩索引，要么使用更大、更接近原始向量的索引。对 Agentic Search 来说，更理想的形态是：完整 OPQ/PQ 码本作为一个整体存在，但每次查询只选择其中一部分精度切片：先读取很小的核心切片，获得大部分排序能力；如果 query 难、margin 小或任务风险高，再增量读取更多 refinement 切片，把精度逐步补上来。

一个可探索的方向，是基于 OPQ（Optimized Product Quantization）构造渐进式 PQ 码本。这里可以把 PQ 的存储理解成一个二维矩阵：IVF 负责语义局部性，用行表示；OPQ/PQ 负责精度与成本局部性，用列表示。一次 query 先通过 IVF 选择少量语义相关的行，再通过 policy 选择需要读取多少精度列。简单 query 可能只读核心列，困难 query 才继续读取 refinement 列，用来修正距离、提高排序稳定性，或者服务高价值 query 的 rerank 前置阶段。

这和 adaptive nprobe 的思想是相通的，但控制对象不同：adaptive nprobe 决定“探测多少 partition”，渐进式 PQ 决定“为同一批候选读取多少精度”。前者扩展搜索半径，后者加深候选估计质量。两者结合之后，Agent 可以先用小半径、少量精度列得到低成本答案；只有在证据不足时，才同时扩大搜索范围和提高距离估计精度。

这样的索引设计也更适合对象存储路径。语义上相近的 partition 行可以形成局部工作集；精度上常用的核心列可以更小、更热、更容易缓存；更高精度的 refinement 列可以冷一些，只有困难 query 才触发增量读取。于是，索引不再是一份必须一次性加载的在线服务状态，而更像一个可以按行、按列逐步展开的引用矩阵。

总结：存储优化就是引用路径优化¶

大模型时代的存储优化，表面上是数据量、格式、索引、缓存和检索系统的变化；本质上是推理范式从“纯生成”转向“生成 + 引用”之后，系统对可引用数据的组织、调度与治理要求。

Memory 和 Harness 决定什么值得引用；数据格式决定引用对象能否被稳定调用；Lance 这类 AI-native dataset 让 embedding、metadata 与 payload 能在同一数据资产中协同；reorder 把 Agent Search 的语义局部性转化为物理局部性；adaptive nprobe 动态控制查询预算；渐进式索引则进一步把“精度”也变成可按需读取的成本维度；Policy 则根据 query 形态选择不同成本曲线。

更进一步看，Agentic Search 可能会把检索系统带到一个新方向：它不再把索引看成一份必须常驻内存、服务所有请求的固定结构，而是把索引、payload、缓存和工作集组织成可按需展开的引用系统。IVF 决定读哪些语义行，OPQ/PQ 决定读多少精度列，物理布局决定证据如何被低成本回查，Policy 则把这些选择组合成不同的成本曲线。

未来的大模型系统，竞争力很可能不只来自模型参数本身，也来自它周围的存储与引用系统：哪些信息值得保存，如何保存成可调用形态，何时引用，引用多少，以及如何证明这次引用确实带来了质量或成本收益。