GraphRAG 可能会过时，Agent 的“外部世界”才刚刚开始

本文来自微信公众号： AIGC从0到1 ，作者：王零壹

过去两年，企业Agent有一个很奇怪的处境。

模型越来越强，能塞进上下文的文档越来越多，RAG方案也越来越复杂。但真到了“替我查一笔订单为什么延迟、判断能否调货、找出受影响客户、再提交一个排程申请”这种任务，很多Agent还是像一个知识面很广的实习生。

它会搜，也会总结，偶尔说得头头是道。

但它并不真正知道：这家公司里“客户”“订单”“库存”到底分别是什么；这些对象此刻处于什么状态；谁可以看、谁可以改；哪一条规则是正式规则；更重要的是，它能不能把答案变成一个受约束的行动。参见AI知识基础正在重写：原始来源、维基、检索、记忆要分开

微软的GraphRAG项目已经明确进入维护模式，不再接收新功能或新PR。

正在成形的，是另一层东西：Agent的Context正从一摞临时塞进Prompt的文本，变成一套有对象、关系、状态、权限、来源和动作的外部世界。

我暂且把它叫作：Structured Context Infrastructure，结构化上下文基础设施。

GraphRAG只是它早期的一种形态。

一、GraphRAG没输，问题是它从来不是“RAG的高级版”

GraphRAG当年火起来，有很现实的原因。

普通向量检索擅长回答：“哪一段文本和我的问题最像？”但企业里很多问题不是找一句话，而是找关系。

比如，“过去一个季度，导致交付延期的共性因素是什么？”这不是从文档里捞一段相似句子就能回答的。它需要把供应商、仓储、订单、审批、天气、设备故障等信息连接起来，看局部关系如何汇成整体模式。

微软最初做GraphRAG，瞄准的就是这种“全局理解”问题。

问题在于，图不是万能检索器。

后续系统评测发现，普通RAG在单跳、细节型问题上经常更强；局部GraphRAG在多跳关系问题上有优势；而依赖社区摘要的全局GraphRAG，容易丢掉细节，在“资料其实不足”的问题上也更容易编出一个听起来完整的答案。

这不难理解。

图能帮你看到关系，却也会带来新的中间层：实体抽取、关系抽取、实体消歧、社区划分、摘要生成。每多一层，就多一层失真机会。

所以，Vector RAG、Hybrid RAG、GraphRAG、Knowledge Graph、Ontology，并不是一条从低级到高级的技术升级链。

它们更像不同的工具：

• 向量检索负责找相似文本；

  
  

• 图负责表达关系；

  
  

• 本体负责规定企业里“什么东西算什么东西”；

  
  

• 状态层负责描述现实现在如何；

  
  

• 权限层决定谁能知道、谁能做；

  
  

• 动作层决定Agent可以改变什么。

  
  

把这些东西拼起来，才接近一个Agent真正需要的Context。

二、一摞文档，不是一个世界

假设你问一个企业Agent：

“客户A的订单为什么延期？现在有哪些可调配库存？如果改走供应商B，会影响哪些客户？我有权限提交调整吗？”

一个典型RAG系统会去召回若干文档：订单条款、库存报表、供应商邮件、操作手册、政策说明。

这已经比传统搜索好很多。

但它仍然缺少一些更基础的东西。

客户A在系统里是哪一个真实实体？“可调配库存”按哪套规则定义？供应商B的履约状态是不是实时的？这次调整会触发什么审批流程？提交申请的人是否有权限？执行后，哪些下游状态必须写回？

这些都不是“再加十个chunk”能稳妥解决的。

企业Agent需要看到的，应该是一个被组织过的局部世界：

对象是什么；对象如何关联；现在处于什么状态；哪些规则有效；哪些数据可信；谁能访问；此刻允许做什么。

这和“给模型更多上下文”是两回事。长上下文能解决“模型一次能读多少字”。结构化Context要解决的是“模型读到的东西，究竟意味着什么”。

Context Window不是Context Model。

这也是为什么，Glean近年强调Enterprise Graph，不只连接文档，还连接人、团队、项目、产品、流程和个人权限；IBM则干脆把这条路线称为“Context as Infrastructure”。

它们要补的，并不是模型的知识量，而是模型在一个组织里行动时缺失的“常识”。

三、Palantir真正结构化的，是企业里的名词和动词

如果要找一个把这件事讲得最直白的产品案例，Palantir的Ontology很有代表性。

传统知识图谱偏向于描述名词：

客户、订单、商品、设备、航班，以及它们之间的关系。

但企业不会停在描述现实。企业每天都要审批、调度、取消、升级、采购、派工。

Palantir Ontology的特别之处，在于它试图把名词和动词一起结构化。对象、关系、当前状态、业务逻辑、权限和可执行动作，进入同一层。

于是，一个Agent不再只是问：

“库存是多少？”

它还可能问：

“在当前权限和业务规则下，我能否把这批库存重新分配给客户A？”

2026年6月，Palantir的Ontology MCP正式GA。它把对象类型、动作类型和函数暴露为MCP工具，让外部Agent可以查询对象、调用预定义动作；每一次调用都运行在认证用户既有的权限边界内。

这件事的价值，它让企业的“世界模型”开始具备一个可控的操作界面。

过去，企业软件把数据放在数据库里，把流程放在另一个系统里，把权限放在第三个系统里。人是那个负责理解它们关系的中间件。

Agent要真正进入企业，必须接过一部分这种工作。但前提是，企业得先把现实中的对象、约束和动作讲清楚。

四、引用是收据，不是监控录像

事情到这里，真正麻烦的问题才出现。

如果一个Agent最后引用了A、C两份资料，是否意味着它就是因为A、C得出了这个结论？

未必。

它可能先看了B、D、E；可能沿图遍历时读到某个邻居节点；可能被一段社区摘要改变了判断；也可能先从模型自身知识或其他Context形成答案，再找一段看起来支持它的材料补上引用。

所以，引用正确和引用忠实，是两回事。

一篇2024年的研究就专门区分了citation correctness与citation faithfulness：引用材料确实能支持一句话，不代表模型真的依赖它得出了这句话。后者可能存在“先有结论、后找依据”的事后合理化。

到了Agentic GraphRAG，这个问题更复杂。

今年5月的一项研究通过移除、隔离和遮蔽实验发现：被引用的图节点通常是必要的，但只保留这些节点并不一定足以复现答案；Agent在遍历过程中访问但未引用的实体，以及周边图结构，也可能影响最终判断。

这意味着，至少要把四件事分开：

• 哪份材料可以支持结论；

  
  

• 这个结论能沿什么路径追溯回原始材料；

  
  

• 模型在形成答案前接触过什么；

  
  

• 去掉某段Context后，结论会不会改变。

  
  

前两项是证据与溯源问题。后两项，开始逼近因果问题。

AI看过什么，不等于它为什么这样判断。

五、图让Agent更会关联，也让错误更会长大

普通RAG的错误，常常局限在某个chunk。

GraphRAG的错误可能更有扩散性。

假设原始资料里有一个含糊甚至错误的关系：A导致B。实体抽取时，它被写进图；社区摘要把它概括为“A是B的主要原因”；更高一层的总结再把它写成背景规律。之后，用户问一个看似无关的问题，这个高层结论又会进入Context。

一个局部错误，最后成了系统默认相信的结构性先验。

这不是图技术独有的缺陷，但图和多阶段摘要会把它放大。

微软的VeriTrail已经在处理相近的问题：它不只检查最终答案能否在原始材料里找到支持，还沿着多阶段生成过程形成的DAG逆向追踪，试图定位不受支持的内容是在哪一个中间环节被引入的。VeriTrail

这类工作提醒我们，未来Agent的可靠性不能只靠最后加一串脚注。

如果中间的抽取、总结、关系归纳已经出了问题，最后一个看似“引用齐全”的答案，可能只是把错误包装得更像事实。

六、有些信息不该影响Agent，引用机制已经太晚了

还有一层更现实的风险。

如果一份用户无权访问的文件已经进入模型Context，再要求模型“不要引用它”，没有多少意义。

模型可能不复述机密内容，但它已经读过了。它可能改变回答的措辞、排序、判断，甚至通过一个看似无害的建议泄露出结构性信息。

所以，权限控制必须发生在Context之前。

正确的顺序应该是：

先判断用户权限，再确定允许的Context集合，然后检索、推理和生成。

而不是先把所有资料都交给模型，最后再检查引用有没有越界。

这也是为什么，企业里的Context Infrastructure不只是检索层，它还必须是治理层。

更严格的架构，往往会包含几道门：

权限过滤→候选检索→证据选择→证据验证→封存证据集→生成→溯源记录→结论校验。

Evidence-first的思路很有意思。它要求系统先明确“哪些材料已经被承诺为证据”，再允许模型生成；模型不应该先写一段漂亮答案，再在结尾补上引用。

还有一种更强的方式是Context Isolation。

不要把A、B、C三十份材料扔进一个巨型Prompt，让模型自由混合。先在每一个来源内部抽取带来源的claim，再让系统基于这些claims做结构化组合。

这样，文档污染会被收缩成claim组合问题。

图在这里也不再只是帮助模型“自由联想”的工具。它可以反过来约束模型：哪些关系已验证，哪些关系只是候选，哪些结论可以进入行动环节。

代价当然存在。

约束越强，模型的自由综合能力越弱，覆盖面也可能下降。高风险场景里，这个代价值得付；低风险创作和探索任务里，未必需要把每句话都封进证据池。

未来的难题不是“要不要可靠”，而是不同任务要为可靠性付出多少灵活性。

七、不会有一张永恒的大图

Ontology一直有个老问题：谁来维护？

企业在变，业务线在变，指标定义在变，流程也在变。让一群人花几年设计一张完美企业本体，最后往往会得到一个结构很完整、和现实渐行渐远的系统。

所以，未来更可行的形态，不太像“构建一张永恒的企业知识图谱”。

它更像双层Context。

稳定层保存那些不应该轻易变化的东西：身份、核心对象、权限、官方定义、长期关系、业务规则和可执行动作。

动态层保存当前任务里临时出现的东西：实时状态、候选证据、短期关系、假设、置信度、检索轨迹和溯源信息。

稳定层告诉Agent：这个组织里的世界规则是什么。

动态层告诉Agent：此刻它看到的世界是什么样。

最近关于Dynamic Ontology和自动Schema诱导的研究，值得从这个角度理解。它们意味着在尝试把本体从一次性的大工程，变成可以根据任务、反馈和新数据逐步调整的运行时能力。

但自动生成得更快，不代表自动生成得更对。

企业真正缺的，从来不是第二份漂亮的现实描述，而是一份足够可靠、能进入流程、又能被不断纠正的现实接口。

八、下一代Agent会争夺什么

但企业更在意的，可能是另一组问题：

这个Agent到底知道什么？

它不知道什么？

它依据哪条规则行动？

它有没有权限？

它的结论能追溯到哪里？

如果结果错了，我们能不能找回是哪一步错了？

这些问题听上去不如“模型智商”性感，却决定了Agent能否从Demo走进真实流程。

今天，我们已经开始能记录Agent调用了什么工具、检索了哪些资料、最后引用了什么内容。

真正还很黑的部分是：哪一段Context改变了它的判断。

它是一个可以被实证的问题：给定Agent接触过的资料、工具结果、记忆和结构关系，哪些信息真正参与了这一次决策？去掉其中一个，结果会不会变？这种影响能否被记录、复现和审计？

Graph不是终点。

最终形成竞争力的，可能是一套位于数据与Agent之间的结构化Context Infrastructure：它让Agent知道世界里有什么，知道这些东西如何关联，知道自己可以做什么，也让人类在出事时能够回头问一句：

“你为什么这么做？”