传统 RAG 有一个沉默的缺陷。每次检索都是一次性赌博。Embedding 搜索像一个凭感觉从书架抽书的助手，抽到什么算什么。你没法翻目录，没法逐页浏览，没法对同一份文件反复追问“这段的上文是什么”。
7 月 5 日，LlamaIndex 开源了一个名为 legal-kb 的参考应用，把这件事彻底翻了个底朝天。它给 AI Agent 配了四样东西：检索、查找、读取、grep。不是 API 文档里那些抽象名词，就是你在终端里每天用的那些操作。不是一次性的，是持久的，是工具化的。Agent 可以像一个人那样“工作”在知识库里。
LlamaIndex 拿出了什么
legal-kb 不是一个库，而是一个完整的 TanStack Start Web 应用。你登录后创建项目、上传文件、和 Agent 对话。每个项目背后对应一个独立的 LlamaCloud Index v2 索引，这是 LlamaIndex 的托管解析和检索平台。文件上传后在后台自动解析、索引，Agent 在每一次对话中实时查询这个索引。
从外表看，它像一个“法律文档版的 ChatGPT”。但真正有意思的东西藏在 src/lib/agent.ts 里面。
Agent 被赋予了四个工具：
- retrieve：混合语义搜索，支持 top_k、score_threshold、rerank，以及按文件名称和版本号过滤。底层调用 beta.retrieval.retrieve API。
- findFiles：按文件名精确匹配或子串搜索，自动分页。底层对应 beta.retrieval.find。
- readFile：读取文件原始内容，支持 offset 和 length 窗口，你可以说“只读第 500 到第 1000 个字符”。底层对应 beta.retrieval.read。
- grepFile：在单个文件中按正则表达式匹配模式，返回字符位置和上下文片段。底层对应 beta.retrieval.grep。
这四个工具不是平权的。Agent 的执行链被强制约束了顺序：先 findFiles 建立文档清单，再 retrieve 缩小搜索范围，最后用 readFile 或 grepFile 确认原文措辞。这是一个“先翻目录、再查索引、最后读原文”的人类阅读流程，被完整复制给了 Agent。
为什么是法律文档，为什么又不仅是法律
legal-kb 的项目名里有 legal，但选择法律文档的原因很简单：法律场景天然具备“大量文件加精确引用加版本控制”的全部特征，这是检验一个检索系统最苛刻的试金石。
LlamaIndex CEO Jerry Liu 在发布时的说明非常清晰：
We've created a comprehensive Retrieval Harness for modern agentic retrieval in 2026. The harness provides a persistent data pipeline that can connect to a data source, index and update a large knowledge base, and expose a broad set of tools akin to filesystem operations (semantic/keyword search, regex grep, file search, read).
LlamaIndex 内部称之为 Retrieval Harness。这个术语值得记住。它有三个关键属性：持久化，数据管道保持存活；工具化，暴露原子操作而非封装策略；可插拔，你可以接入任何 Agent。它不是一个产品特性，是一个架构范式。
为什么单次 Embedding 搜索不够了
传统 RAG 的流程是一锤子买卖。用户提问，Embedding 搜索，Top-K 返回，LLM 生成答案。如果返回的那些文本里没有正确答案，你只能换个问法重来。
这在简单问答场景下够用。“苹果公司 2024 年营收是多少？”这种问题，如果知识库里有一份财报，第一次检索大概率就能命中。但复杂任务完全不同。“从 5000 份供应商合同中找出所有涉及 GDPR 合规条款变更的文件”，这要求系统在大量文件中做多次交叉验证、逐段比对、精细过滤。单次检索的 Top-K 窗口根本装不下这种复杂度。
2026 年 6 月，微软研究人员在 arXiv 上发表的 AgenticRAG 论文（2605.05538）给出了量化证据。在 BRIGHT 基准上，Agentic Retrieval 的 recall@1 达到 49.6%，比最佳 Embedding 基线高出 21.8 个百分点。WixQA 上事实性得分 0.96，相对提升 13%。FinanceBench 上答案正确率 92%，仅比完美证据（oracle access）低 2 个百分点。
最关键的发现来自消融实验：从单次检索切换到 Agent 工具使用，带来了 5.9 倍的性能提升。 多查询搜索和文档内导航各自贡献了质量和效率的增益，但最大的变量是“赋予 Agent 工具”这件事本身，而不是任何算法上的高级改进。
这个 5.9 倍的数字背后有一条简单却反直觉的结论：与其花几个月调优 embedding 模型、设计检索策略、调试 reranking pipeline，不如直接给 Agent 一套文件系统工具，让它自己决定怎么找。
文件系统就是最好的 API
legal-kb 最反直觉的设计选择是：它没有为 Agent 设计任何高级检索策略。没有 Self-RAG，没有 CRAG，没有 HyDE，没有 RAPTOR。Agent 能用的只有四个原始操作：find、retrieve、read、grep。
这恰恰是最聪明的决定。
因为任何高级检索策略的本质，都可以被拆解为这四个原子操作的组合。Self-RAG 不就是“检索-判断-再检索”的循环吗？CRAG 不就是“检索-纠正-检索”吗？把它们直接编码成 Agent 的原生工具，而不是硬编码成管道里的黑盒，就等于给了 Agent 自己决定“什么时候查、怎么查、查完要不要再查”的自由度。
多位行业观察者在社交平台上给出了几乎一致的评价。一位开发者说：hybrid search across the whole index with read, grep, and find is basically giving an agent the same tools a developer would use on a local filesystem。另一位评论得更直白：filesystem operations but for vibes is actually the unlock，agents been fumbling retrieval tasks for too long。
给 Agent 一套文件系统操作，而不是一个封装好的检索函数，这意味着 Agent 可以自主决定检索策略。它可以先找文件名缩小范围，再语义搜索，最后 grep 精确匹配。每一个步骤的输出都影响下一步的决策。这和人类处理信息的方式如出一辙。
某种意义上，legal-kb 在做的不是“让 Agent 更会检索”，而是“让检索环境变得更像 Agent 能理解的世界”。
持久化管道的隐藏价值
legal-kb 的另一个设计细节容易被忽略：版本控制。
每个 project 和 filename 组合支持多版本共存。你重新上传一份 nda.pdf，系统不会覆盖之前的版本，而是产生 v1、v2、v3 三个版本并行存在。检索层通过 version 元数据字段过滤。这意味着知识库本身有了版本管理。你可以回溯到上一个版本的文档状态，查看 Agent 基于哪个版本做了判断。
这在法律和金融合规场景中意义重大。合同条款在不同版本之间的变化往往是争议焦点。如果 Agent 引用的是一份已经被修订过的旧版本，后果可能是灾难性的。版本控制把这个风险从“需要人工核对”降到了“系统自动筛选”。
持久化管道还解决了一个更根本的问题。一位行业观察者一针见血地点到了要害：
Most 'agentic retrieval' pain isn't recall — it's the agent re-indexing the world every run because nothing survives between calls.
这正是许多 RAG 系统的致命伤。每次对话都要重新索引，Agent 的记忆在调用之间完全消失。legal-kb 的持久化管道让索引持续存活，知识库在对话之间不丢失上下文。Agent 不需要每次从头开始探索它已经去过的地方。
上传管道在 src/lib/files.ts 中的实现很清晰：文件字节被推送至 LlamaCloud 源目录，同时 File 和 ProjectFile 两条记录被写入 PostgreSQL（通过 Prisma），索引同步被触发但不等候完成，UI 轮询状态直到就绪。非阻塞式索引编排，在工程层面也足够务实。
2026 年的三条 Agentic Retrieval 路线
当前的 Agentic Retrieval 市场大致分三条路线。
检索增强派以 LlamaIndex 为代表。核心思路是在传统检索基础设施上叠加 Agent 层。给 Agent 工具，让它在知识库里自主导航。优势是与现有 Index 和 Parse 基础设施深度集成，有完整的技术栈闭环。劣势是需要依赖 LlamaCloud 生态，对第三方搜索后端支持有限。
知识图谱派以 Graph-R1（Agentic Graph RAG with RL）为代表。用知识图谱加强化学习实现多跳推理，适合有复杂层级关系的企业知识管理。优势是推理路径可解释、归因清晰，劣势是建图成本高、更新周期长、不适合频繁变动的语料库。
全栈搜索派以 Algolia、Elastic 等传统搜索公司为代表，将 Agent 能力整合进已有搜索基础设施。优势是客户基础庞大、搜索工程积累深厚，劣势是对 AI Agent 的原生理解不如前两者深。
三条路线目前还处于各自跑通核心场景的阶段，尚未形成明确的赢家格局。但 LlamaIndex 这次 legal-kb 的开源发布，等于把第一路线的完整技术栈——从文档解析、索引、检索到 Agent 编排——全部以可运行代码的形式公之于众。对于任何正在构建 Agentic Retrieval 能力的工程团队来说，这是市面上为数不多真正“开箱即用”的参考实现。
Agentic Retrieval 的隐性门槛
legal-kb 证明了一个关键命题：基于工具而非管道的检索架构，在复杂知识探索任务上显著超越传统 RAG。但要把这个架构部署到生产环境，还有几个隐性门槛需要跨越。
第一个是工具调用的成本。Agent 在自主探索过程中可能会调用几十次甚至上百次检索工具，每次调用都消耗 API 额度。在 legal-kb 的 demo 场景中这不成问题，但在企业级每天处理数万次查询的负载下，成本会急剧放大。
第二个是 Agent 何时停止的问题。一位评论者非常精准地指出了这一点：The persistent pipeline is the right call... The harder half: teaching it when it has enough to stop retrieving。给 Agent 自由探索的能力之后，如何让它学会“我找到了，停止搜索”，这比检索本身更难。legal-kb 目前依赖模型的自然 reasoning 来做出这个判断，但在关键任务场景中，需要有更明确的停止条件。
第三个是知识库漂移。如果知识库在 Agent 执行任务过程中发生了更新，旧文档被替换、新条款被加入，Agent 已经缓存的上下文如何处理？legal-kb 的版本控制机制提供了一个技术基础，但 Agent 层面的上下文一致性保证尚未被充分解决。
这些门槛不削弱 legal-kb 的价值，但它们定义了 Agentic Retrieval 从参考实现走向生产级系统之间的距离。
站在范式转移的前夜
抛开具体的产品细节，LlamaIndex 这一轮的战略意图已经非常清晰：从 RAG 框架向 Agent 检索基座升级。Index v2 的 beta API 围栏被 legal-kb 完整跑通，下一步很可能是一站式托管服务。让企业只需要上传文档，就能获得一个自带 Agentic Retrieval 能力的知识库，而不需要自己搭建 Agent 编排层。
这个方向如果走通，LlamaIndex 在 AI 基础设施版图中的角色将从“帮你做 RAG 的库”变成“Agent 默认要知道的那个知识层”。这不是同一个量级的竞争。
对于正在构建企业 AI 产品的团队，legal-kb 释放的信号值得认真对待：检索基础设施正在从“一次问、一次答”的搜索范式转向“让 Agent 在知识库里工作”的行为范式。如果你还在用单次 Embedding 搜索对付复杂的多文档场景，你可能已经在用上一个时代的工具解决下个时代的问题。
检索不再是 Agent 的一次性动作。它是一套工具，一个工作空间，一种持续存在的能力。Agent 来来去去，但文件系统从来不会过时。
快报