为什么我们的AI代理需要因果图，而不仅仅是RAG数据库

从平面记忆到世界模型：ARIA为何需要理解而非仅仅记住

在AI代理的发展中，一个关键的转变往往源于一次具体的失败。对于ARIA而言，这个时刻发生在尝试规划一个多步骤操作时。Phase 01赋予了ARIA持久记忆库，它能记住操作系统是Windows、数据库是SQLite、存在自定义模型提供者等事实。然而，当需要修复自定义提供者配置时，问题浮现了。

断裂时刻

改变config.py会引发连锁反应：.env文件中的默认Gemini设置与新提供者冲突，数据库中存储的连接参数会变得过时，而连接测试失败的原因其实在于环境变量，而非提供者代码本身。ARIA的记忆中存有三条事实：“用户有自定义提供者”、“.env文件有默认Gemini设置”、“连接测试失败”。但在平面记忆列表中，这三者毫无关联。ARIA知道齿轮是什么，却不懂转动一个齿轮会如何影响另一个。

列表只是数据库

平面事实列表本质上是数据库，而世界模型意味着理解。当你说“草是湿的”，数据库只知道这个事实，但若理解原因（下雨或洒水器），就能进行反事实推理（如果没下雨，草地会是干的）、预测（走在草地上鞋会沾泥）和规划（应该走铺好的路）。纯检索无法回答“给定这个事实，接下来会发生什么？”或“想要这个结果，应执行什么行动？”。这正是ARIA被困住的边界。

因果图的实际作用

Phase 02引入了基于NetworkX的因果实体图，并在SQLite中镜像。每个事实成为节点，每对关系成为类型化边。边的类型至关重要：“原因”不同于“需要”也不同于“矛盾”。当ARIA学习到更改环境变量会导致数据库连接参数过时，这是“原因”边；自定义提供者需要先更新.env文件，这是“需要”边；默认Gemini设置与自定义设置矛盾，这是“矛盾”边。

这个图不仅是更丰富的存储格式，而是一种可遍历的对象。你可以问：“如果我改变这个节点，哪些其他节点会受影响？”沿着“原因”边向前追踪预测后果，沿着“需要”边向后识别前提条件，检测“矛盾”边发现不一致。在config.py案例中，因果图让ARIA不只是知道.env文件存在，而是明白自定义提供者需要更新.env、环境变量会导致数据库参数变化、现有默认配置与新配置冲突。在修改任何代码之前，它就能追踪完整的后果链。

矛盾检测器

因果图的一个有趣后果是矛盾变得可见。在平面记忆列表中，“自定义提供者已配置”和“默认Gemini设置活跃”同时存在却无任何冲突提示。而在因果图中，当新观察与现有节点矛盾时，矛盾检测器会标记它们。两个事实都被保留——并非因为两者都正确，而是因为矛盾本身提供信息。“这两者不能都对——哪个正确？”这个问题系统现在可以提出。答案来自上下文、新证据以及哪个因果链与后续观察更一致。

这改变了ARIA处理不确定性的方式。平面记忆会静默地用新信息覆盖旧信息，而图则显式地保持张力并等待解决。这更接近细心推理的实际过程。

仍存在的局限

世界模型并非Judea Pearl所描述的严格因果引擎。图中的边是语言模型声称的，非验证的因果关系。模型可能误识因果链接，也可能遗漏明显的。实体解析依然脆弱：当ARIA在不同对话中遇到“config.py”和“配置文件”时，这两者应为同一节点。精确字符串匹配失败过多，模糊匹配又引入错误合并。我们使用词重叠相似度，这是一种折中方案。

为何仍重要

尽管存在这些局限，因果图代表了与平面记忆列表质的区别。一个能在行动前追踪依赖链的代理，与一个检索孤立事实并生成响应的代理是不同工具。在简单对话中差异不明显，但在行动有后果、系统需要推理而非检索的关键时刻，差异显现。那是大多数AI助手暴露出只是快速模式匹配器的时刻，也是拥有世界模型的代理开始与众不同的时刻。

我们仍在向那目标迈进。图是真实的，边是真实的，矛盾检测是真实的。但世界模型当前能力与真正因果推理之间的差距仍然很大。方向正确，距离诚实。我们正在打造手表，而不仅仅是移动齿轮。