编辑｜Sia

前阵子，Claude Code 意外泄露了 512,000 行 TypeScript 源码。

好家伙，Anthropic 这波莫不是把 Claude Code 的「底裤」都露出来了？

AI 圈扒完之后发现，最有意思的地方不是模型，而是 Claude Code 这个 Coding Agent 外面那层运行系统。

泄露的大部分代码，都在处理这些事：什么时候读文件，什么时候调用工具，什么时候压缩上下文，什么时候继续下一步。

也就是今天越来越火的 Agent Harness。



一次意外，也算给行业提了个醒。

Agent 时代，真正重要的不只是模型智商，还有模型外面那套上下文组织、工具调用和任务循环系统。



这套系统里，连接「模型」和「外部知识世界」的基础设施——RAG，也必须跟着进化。

为啥嘞？



如果有人想知道「某条产品路线到底受谁影响？」，答案可能藏在这样一条链里：

A 公司收购了 B 公司、B 公司的 CTO 后来加入了 C 项目、 C 项目又影响了某条产品路线。

三件事分开看，未必都和用户的问题特别相似；只有把它们串起来，才是真正的答案。

传统 RAG 可以迅速在资料库里找到几段「看起来最像」的文本，但未必拧得清它们之间是啥关系。

对 Agent 来说，这就很要命。

因为， Agent 不只是问答，它还要基于检索结果继续推理、调用工具、做下一步决策。第一步检索错了，后面就会一路跑偏。

结果会有多离谱呢？

有研究发现，在医学临床文本生成中，传统 RAG 技术反而让大模型幻觉率，从基线状态的 5.0% 飙升至 43.6%。

原因就是，它只是找到了「看起来相关」的资料，而不是循证的证据。



这也是为什么，it’s time to 重新思考 RAG。

不预则废？Graph 也不是银弹啊

以微软 GraphRAG 为代表的方案，算是对传统 RAG 局限的一次重要修正。

还是上面那个问题：某条产品路线到底受谁影响？

GraphRAG 会先把 A 公司、B 公司、CTO、C 项目、产品路线这些实体，以及它们之间的关系抽出来，做成一张知识图谱。

再沿着「谁和谁有关」、「哪些事件属于同一个主题」、「哪些信息共同指向一个结论」去组织答案。

这一步很重要。它让 RAG 从简单的向量相似度匹配，向结构化关系推理迈出了一大步。

尤其是在全局理解和主题总结上，GraphRAG 确实很管用。



引入知识图谱像是给 RAG 修了一座知识宫殿，漂亮也更有结构，但构建和维护起来却不堪重负。

抽三元组、合并实体、归一关系、建全局图、做社区摘要……每一步都很贵，每一步都可能出错。

更尴尬的是，好不容易盖好了，一旦真正查询时，很多系统并没有充分「沿着图里的关系去找答案」，最后还是退回到「找几个相似节点 / 相似摘要」老一套。

最要命的是，世界总在变。今天项目负责人换了、明天客户需求变了、后天某条产品路线又被推翻了……

预制的图谱，总不能每天推倒重建吧？



不久之后，另一条强路线 HippoRAG 2 登场了。

受海马体记忆启发，它希望系统像人脑回忆一样：从一个线索出发，沿着图里的关系扩散，激活更多相关记忆。

如果用户想知道，某条产品路线到底受谁影响？

HippoRAG 2 会先识别关键实体和线索，比如 A 公司、B 公司、CTO。然后在图谱里激活相关节点。

接着用 Personalized PageRank 这类图排序算法，沿着关系继续扩散：从 B 公司找到 CTO、张三、 C 项目，直到产品路线。最后，再把这些线索交给LLM 生成答案。

通过把 RAG 继续推向「结构化记忆」和「多跳检索」，HippoRAG 2 确实有效解决了传统 RAG 在多跳推理和长期记忆上的一部分问题。

但也同样留下了巨大的工程挑战。



和 GraphRAG 一样，HippoRAG 2 也离不开一张离线构建的全局图。

而且，查询时还要在 graph 上跑 PageRank / Personalized PageRank 这类排序算法。

这套方法在 benchmark 规模下很强，一旦到了真实 Agent 场景，全局图的维护和排序就会变得很重。

脑补一下：每天都要持续写入新文档、新实体、新别名、新关系......

那有没有一种办法：

既要结构，又不要一上来就修一座知识宫殿；

既要多跳，又不要每次都在全局图上跑一遍复杂排序；

既要支持 Agent 长期使用，又不能每来一批新数据，就把整张图推倒重建；

现在，轮到广州智跃深空人工智能科技有限公司 Zleap AI 提出的 SAG（SQL-Retrieval Augmented Generation） 出场了。

SAG：用超边结构重构 Agent 数据底座

其实，名字已经点题了——不是 Graph、Hippo，而是 SQL-Retrieval。

它的核心想法是在离线阶段，SAG 先把原始文本先整理成「事项 + 实体」的数据库结构。等查询来了，再围绕当前问题，用 SQL 动态串出一张局部线索网。

例如，一些讨论《给阿嬷的情书》的原始 chunk 如下。







传统三元组会把这段完整事件链，拆成很多条 「主体 - 关系 – 客体」：

但一段话常常不是一个简单关系，而是一件完整的事。强行拆成很多三元组，就像把一篇新闻剪成碎纸条，关系词抽错一点，整条线索就断了。

SAG 改成：



也就是说，一个 chunk 对应一个完整的 event。一个 event 可以连接多个 entity。

反过来，一个 entity 也可能出现在多个 event 里。



一个 event，把多个 entities 绑在了一起，在图结构上，这更像「超边（many-to-many hyperedge）」。

这些都会被写进 SQL 和向量索引里。查询时，系统通过共享实体把相关事项临时连起来。



SAG结构示意图，离线写入。

当用户想知道，为什么会有人投资《给阿嬷的情书》？

SAG 会先让 LLM 从查询中识别实体，比如投资方、深圳企业、资金来源、投资决策。然后，兵分两路。

第一条路，是结构路径。

系统会去 SQL 中查询：哪些事项卡和这些实体有关？它可能首先找到「深圳企业投资《给阿嬷的情书》」这张事项卡（ event )。

这张卡能解释投资方看中了影片的社会传播和市场扩散潜力，但还不能完整回答「为什么值得投」。

于是，SAG 会继续读取 event 里的 entities。例如：深圳企业、潮汕、侨乡经济、华人情感、家庭观影、社会传播，再通过 SQL 反查其他包含这些 entities 的 event 。

这样，系统会进一步找到「侨批题材带来文化价值」这张卡（ event ）；再沿着侨批、地域文化、海外华人、公共文化价值等 entities，找到「主创经验和中小成本制作降低投资风险」这张卡（ event ) 。

整个过程本质上是 SQL join，不是全局图推理。最终，原本分散在不同 chunk 里的信息被串成一条链。



SAG结构示意图，在线检索。

第二条路，是语义路径。

SAG 也不会完全放弃传统向量检索，它会同时用 query 的 embedding，直接去 chunk 索引里找语义上最相似的文本。

所以，SAG 最后拿到其实是两批候选。

系统此时会做一轮相似度过滤，再让 LLM 在更小的候选集里挑出最关键的 event。

最后，再把这些 event 映射回原始 chunk，和直接向量召回的 chunk 合并，形成最终给 LLM 看的证据。

最后你得到的答案，可能是这样：

投资人之所以愿意投资《给阿嬷的情书》，并不是因为它一开始就具备传统商业大片的外观。相反，这个项目表面上有不少风险，比如方言表达、非流量演员、弱商业类型。但也有几个优势，投资人投《给阿嬷的情书》，本质上是在投一个文化辨识度强、成本风险可控、情感共鸣有扩散潜力的电影项目。

RAG 新 SOTA 到了

说了这么多，SAG 到底有没有用？ Zleap AI 拿了三个经典多跳问答数据集来测：

HotpotQA、2WikiMultiHopQA、MuSiQue。

它们都在考系统会不会「顺藤摸瓜」。尤其是 MuSiQue，最多要做 4 跳推理，基本就是 RAG 里的硬骨头。

对手 HippoRAG 2 ，也绝对不是软柿子。

结果，在统一配置下：

SAG 在前 2 条结果里命中关键证据的能力，直接领先了 11.1 个百分点。越早命中，后面的 token 越省，延迟越低，推理链也越不容易跑偏。



最难的 MuSiQue，也很能说明问题。

SAG 的 Recall@5 是 80.0%，HippoRAG 2 是 65.1%，差了将近 15 个百分点。

可见，在越需要多跳推理的场景里，SAG 的「事项 + 实体 + SQL 扩展」越能发挥作用。

消融实验进一步支持了提升来自结构本身的判断。

论文还验证了 SAG 对 embedding 模型不敏感。



换成更强的 NV-Embed-v2 后：

真正起作用的，是底层结构变了，而不是堆更强 embedding 。

新 SOTA，还能工业落地，也就它了

据 Zleap AI 透露，SAG 已经在约5 亿条数据规模的生产环境中部署，且数据规模还在持续增长，在线检索延迟保持在秒级以内

刷新 SOTA，还能如此规模化落地的 RAG，估计也就 SAG 了。



SAG 能在大规模数据下维持低延迟，关键在于分工。

慢活儿，离线做。用 LLM 做结构化抽取，把 chunk 变成 event 和entity；

快活儿，在线做。用 SQL、向量索引和全文索引快速召回。只让 LLM 判断很小的候选集。

SAG 也比 GraphRAG 更扛增长。

因为，chunk 是天然的并发单元，每个 chunk 都可以独立处理。

每当新网页、新文档、新项目进来，不用重新计算全局关系，直接把新增内容变成新的 event 和 entity 并入索引体系即可。

它不是一张每天都要重修的知识图谱，更像一套能持续生长的线索档案库，这使得增量处理和持续扩展，都成了自己的优势。

当然，很多人会问实体越来越多，合并会不会很复杂？

会复杂，但SAG 没有把「完美实体合并」放在主链路里这点也和 GraphRAG 很不一样。

GraphRAG 把实体当成图里的核心节点，实体合并错了，整张图都会被污染。不合并，路径又会断掉。所以，必须认真做实体消歧，工程量也会越来越大。

但 SAG 可以接受一定程度的「不完美合并」。

因为 entity 不是答案本身，更像是「路标」；event 才是那张写清楚事情经过的卡片。

比如，同一家公司被写成几个不同名字，系统不一定要在入库时立刻判断它们是不是同一个实体。

SAG 可以先保守处理：入库前做简单字符串归一和 SQL 查询，在同一个 source 下，如果同类型、同名字的实体已经存在，就直接复用。没有，就插入为新实体。

后续查询时，再通过向量检索、全文检索和 LLM 重排把相关线索补回来。

为了让用户更直观地体验这套机制，Zleap AI 还做了一个 Wikipedia 搜索 demo。我们也简单问了个问题：

与《给阿嫲的情书》主题相似的电影，还有哪些呢？

很快，它就放出一段基于十几条结果的总结。下面是被召回的证据卡片，比如《亲爱的奶奶》、《阿嬷的梦中情人》、《情书》。



体验地址：https://wiki.zleap.com/search

点开《亲爱的奶奶》，右侧还能看到这条结果为什么被召回，以及它对应的原始证据。



左边返回了《亲爱的奶奶》《阿嬷的梦中情人》《情书》这些结果，而是右边展示了每条结果为什么被召回。

这就是 SAG 的可追溯性。Agent 不只是要拿到答案，还要知道答案从哪来；不只是要回答当前问题，还要知道下一步该沿着哪条线索继续查。

最有意思的是 View Graph。



它不是一张提前建好的知识图谱，而是 SAG 针对这一次问题，临时展开的一张局部线索网。

图里的节点，就是系统围绕当前问题召回出来的一批事项卡（ event ）。用户问亲情电影，系统就围绕亲情、书信、家庭、回忆这些线索扩展

如果问「收购 Instagram 的公司，其创始人上过哪所大学」，系统又会围绕 Instagram、Facebook、创始人、大学这些实体和关系重新扩展。



也就是说，SAG 不是提前把全世界的关系都算好，再等用户来查。它是在问题发生时，只激活当前问题需要的局部关系。

这正是它能适应大规模 RAG、并与传统 RAG、GraphRAG 拉开差距的关键。

不止是知识，还有记忆

对 Agent 来说，真正的数据底座，其实还要能承载记忆。

除了知道外部世界发生了什么，Agent 还需要知道：用户偏好什么表达方式，某个项目推进到了哪一步，上一次任务查到了什么结论，哪个旧判断后来又被新信息推翻。

这些内容如果只按普通 RAG 的方式存成文本块，系统就只能找回一段相似聊天记录，却未必知道哪条是历史背景，哪条是当前状态，哪条已经失效。

SAG 刚好提供了一个更自然的组织方式。

每条记忆都可以被写成一个 event：谁，在什么时候，对什么对象，做了什么事，产生了什么状态变化；相关的人、项目、任务、偏好，可作为 entity 连接起来。

这样一来，Agent 的记忆就不再是一堆松散的历史对话，而是一套可以持续写入、按线索找回、随问题动态展开的事项档案。

当然，论文也提到，真正面向长期 Agent Memory，还需要进一步加入版本化和时间感知能力。但这也是它作为 Agent 数据底座最值得期待的地方。

从这个角度看，SAG 真正指向的是一种新的数据组织范式：知识可以被持续写入，记忆可以被沿线索找回，状态变化也有机会被长期追踪。

这或许也是下一代 Agent 数据基座真正需要补上的一课。

1、开源项目地址：

https://github.com/Zleap-AI/SAG

2、论文地址：

https://arxiv.org/abs/2606.15971

3、有关医疗AI幻觉的论文：

Representation Before Retrieval: Structured Patient Artifacts Reduce Hallucination in Clinical AI Systems

https://www.medrxiv.org/content/10.64898/2026.02.13.26346256v1.full.pdf