LlamaIndex legal-kb:把 RAG 从「一次搜索」变成「多步循环」的检索引擎范式

事件

2026 年 7 月 5 日,LlamaIndex 开源 legal-kb——一个完整的参考应用,展示了一种叫 Retrieval Harness 的智能体检索模式。

核心思路:给 AI Agent 配四个文件系统风格的工具,让它像人一样去「找文档 → 查内容 → 验细节」,而不是传统的「一次向量搜索返回 Top-K 块」。

四个工具:

工具	能力	底层 API
`retrieve`	混合语义检索 + 可选 rerank + 引用	`beta.retrieval.retrieve`
`findFiles`	按文件名/子串搜索	`beta.retrieval.find`
`readFile`	带 offset 的原始内容读取	`beta.retrieval.read`
`grepFile`	正则匹配 + 字符位置	`beta.retrieval.grep`

系统提示强制了调用顺序:Agent 必须先调 findFiles 列出文件清单,再用 retrieve 定位,最后用 readFile/grepFile 确认精确措辞。

底层栈:TanStack Start Web App + Vercel AI SDK 6 ToolLoopAgent + Prisma(数据持久化)+ WorkOS(认证)。

关键特性:每个项目有版本控制——重复上传 nda.pdf 会产生 v1、v2、v3 并存,检索时按 version 元数据字段过滤。这意味着知识库本身有 git 语义,可追溯每个版本引用的内容。

回答带可视化引用:每个检索到的块有短 id(例如 cite:c7f2qa),Agent 内联引用,UI 渲染为可点击的引用标签,点击后打开源页截图 + 引用文本的 bounding box。

深度剖析

这件事的本质,是把「RAG」这个词从一个「检索技术」重新定义成「数据基础设施」。

传统 RAG 范式的天花板

过去 3 年的 RAG 范式基本是同一个套路:

1. 把文档切成 chunk 2. 向量化 3. 用户提问 → 向量搜索 → Top-K 块 → 塞进 prompt → 生成回答

这套范式的问题:

Top-K 是个黑盒:用户不知道检索到什么,只知道模型回答了什么
Chunk 边界破坏语义:合同条款、代码函数、政策章节经常被切碎
无法跨文档推理:「对比 NDA 和 MSA 的违约条款」这种问题,单次检索根本做不到
没有版本控制:同一份政策更新了,旧版引用还在索引里,模型可能用错版本

Retrieval Harness 是另一种范式

legal-kb 把 RAG 重新设计成「Agent + 数据管道的持续循环」:

[数据源] → [持续索引管道] → [知识库(带版本)]
                                    ↓
                            [Agent ToolLoopAgent]
                                    ↓
                       findFiles → retrieve → readFile/grepFile
                                    ↓
                          [可追溯的回答 + 视觉引用]

核心转变有三个:

1. Agent 是「操作员」,不是「接收方」 传统 RAG 把检索结果塞进 prompt,让模型消化。Retrieval Harness 让 Agent 主动决定:先看哪些文件、用什么查询、什么时候读全文、什么时候验细节。这是从「自动挡」到「手动挡」的范式转移。

2. 检索是「循环」,不是「单次」 ToolLoopAgent 可以多轮调用工具——「我想找的是 X,但我看到的可能是 Y,所以我再 grep 一次确认」。这是 LLM 时代的「grep | head | tail | awk」多管道能力。

3. 知识库是「活的」,不是「静态的」 持续索引管道 + 版本控制 = 文档更新会自动反映到检索结果,但旧版本仍然可查。法律、金融、医疗这种「知识有时间属性」的场景,这才是合规要求。

法律、金融场景的天然适配

法律文档的几个特征:跨文件、长文档、版本敏感、引用精确。传统 RAG 在这些场景基本是「能用,但经常答错」。Retrieval Harness 直接对应这些痛点:

「这份 MSA 的违约条款和 2025 年那版的差异是什么?」——retrieve + version filter
「对比这三份 NDA 的保密期限」——findFiles + retrieve + grep
「找出所有提到「不可抗力」的条款」——grepFile 全文件扫描
「这条引用的具体段落在哪?」——visual citation 直接跳到 bounding box

值得关注的原因

「RAG 已死,智能体检索永生」可能是 2026 H2 最重要的范式信号。LlamaIndex 是 RAG 框架的事实标准制定者,这次亲手把 RAG 从「单次检索」升级为「多步循环」,这不是补丁,是从架构层面换引擎
AI Agent 工具设计的「文件系统化」趋势:legal-kb 的四个工具(retrieve/findFiles/readFile/grepFile)本质上就是 find、cat、grep、search 的 AI 化重写。Cursor、Claude Code、Vercel AI SDK 都在往这个方向走——给 Agent 一个熟悉的操作语义,比给 Agent 一个全新的抽象更高效
「视觉引用 + bounding box」是 AI 答案可解释性的关键一步。07-05 Senior SWE-Bench 上「用 AI 测 AI」的循环验证偏差,需要「Agent 的每个回答都能追溯到具体段落」来缓解。legal-kb 的 visual citation 是这个方向上的范本
「知识库版本控制」对所有「数据有生命周期」的行业都有意义:法律(合同版本)、金融(财报版本)、医疗(临床指南版本)、政策(法规版本)。这套机制直接复制到任何需要「历史快照」的场景

风险与待观察

Reference App,不是生产就绪框架。法律行业用这套需要补:合规审计、权限隔离、跨项目检索、Agent 行为日志
依赖 LlamaCloud(LlamaIndex 母公司 LlamaIndex AI 的商业服务),不是纯开源。@llamaindex/llama-cloud 这个 SDK 是闭源的,虽然可以自托管底层
多步循环 = 成本上升。一次合同查询可能触发 4-6 次 LLM 调用,SWE-bench 时代的「成本感」在 RAG 时代同样重要
「Agent 自由发挥」vs「系统提示强约束」的平衡。legal-kb 强制了 findFiles 先调,但实际生产里 Agent 经常跳过这一步。这道墙,本质上是 LLM 时代「确定性 vs 灵活性」老问题的 AI 版

总结

LlamaIndex legal-kb 不是一个「新产品」,是一次「范式重定义」。把 RAG 从「一次搜索 + Top-K」重新设计成「Agent + 数据管道 + 工具循环」的三层架构。

对 AI coding 行业的启示:「上下文工程」的核心不是「塞更多 chunk 进 prompt」,而是「给 Agent 工具让它自己去找」。07-05 Senior SWE-Bench 上 Opus 4.8 只有 24%,不是因为它「读得不够多」,而是因为它「找不到该读什么」。

这套 Retrieval Harness 模式,如果被 Cursor、Claude Code、Cline 这些 AI coding 工具的下一代版本吸收,会直接改变 AI 编程的体验——从「我和 AI 聊天,它给我代码」变成「我和 AI 协作,它在文档/代码/测试/部署的整个生命周期里自由搜索、精确引用、版本可追溯」。

这是 RAG 的 2.0 版本。

---

来源:

https://www.marktechpost.com/2026/07/05/llamaindex-legal-kb-agentic-retrieval-over-index-v2-with-retrieve-find-read-and-grep-tools
https://www.tmtpost.com/agent/ai-article/18893
https://github.com/run-llama/legal-kb
https://aihot.virxact.com/items/cmr7ita5g00reslxdrprk52b0