用决策关系图补上 Agent 的长期记忆

团队换掉一个队列方案后，旧实现却作为 fallback 留了下来，还依赖已经被替换的设计，最终在生产环境暴露问题。作者由此做了 memgraph：用本地关系图记录决策、证据、反驳和替代关系，让 AI 和开发者都能追溯「为什么这么选」。

它值得看的地方，是把决策之间的依赖变成可检查的数据。不过，检查关系是否自洽，与判断技术方案是否正确，是两回事。

为什么能搜到旧文档，还是会忘记决策

作者遇到的问题，不是找不到一句历史记录，而是没人能讲清：最初为什么选这个方案、依据是什么、谁同意了替换，以及哪些实现还依赖旧选择。

作者认为，Vector RAG 擅长找回文本，却没有自动维护这些决策关系。搜出两份互相冲突的 ADR（架构决策记录），并不等于知道哪份已经失效。

memgraph 的做法，是把决策和事实分别存成节点，再显式记录它们之间的关系。例如，一个事实可以反驳某项决策，新决策可以替代旧决策，某个实现也可以继续依赖旧决策。

决策变更后，需要保留的不只是新结论，还有旧结论为何失效。

工具是零依赖的 Node.js CLI，要求 Node.js 18+，采用 MIT 许可证。不需要网络、服务端或 embeddings（向量嵌入），数据保存在单个 JSON 文件里，可以跟代码一起提交。

把「旧方案已失效」变成 CI 能检查的规则

原文用队列选型演示了完整过程：先选 Postgres LISTEN/NOTIFY，再记录 NOTIFY payload 上限为 8000 bytes 的事实，最后改用 Redis Streams。

下面这组命令解决的是决策及其变更原因的留档问题：

memgraph init
memgraph add --type decision --title "Use Postgres LISTEN/NOTIFY for the queue" --source "ADR-014"
memgraph add --type fact --title "NOTIFY payloads cap at 8000 bytes" --source "Postgres docs"
memgraph link m-002 m-001 --relation contradicts
memgraph add --type decision --title "Switch the queue to Redis Streams" --source "ADR-019"
memgraph supersede m-001 m-003 --reason "payload cap makes NOTIFY the wrong tool"

要看最后一行：supersede 记录了替代关系和原因，旧节点仍然存在。--source 则负责留下依据来自哪里。

录入之后，有三个查询入口：

• memgraph why m-003 用来查看来源、支持证据、矛盾和替代关系。
• memgraph check 检查未解决的矛盾、仍依赖失效节点的有效节点，以及没有来源的主张。
• memgraph list 列出全部节点，并标记已经被替代的节点。

memgraph check 发现错误时以退出码 1 结束，因此可以作为 CI 门禁：PR 引入了图中可识别的矛盾，或者保留了对旧决策的依赖，就会在合并前失败。

仓库还提供了一个小型团队决策图，可以用下面的命令运行演示：

sh examples/run-demo.sh

这里要关注演示中的 fallback reader：它仍然依赖旧设计，所以检查会报错。

作者报告，这张示例图恰好检出两个问题：fallback reader 依赖已被替代的决策，以及一个开放问题没有来源。8000 bytes 上限与旧方案之间的矛盾不会继续报错，因为旧方案已经被替代，这段冲突属于已解决的历史。

这比简单地「发现两句话冲突就报警」更有用。历史可以保留，当前规则也能保持清晰。

我的判断

我认同它把「找资料」和「维护决策状态」区分开来。相比只写 ADR，显式关系更方便检查跨决策依赖；相比只做向量检索，它提供了更明确的当前状态和替代路径。

但作者对 Vector RAG 的概括有边界。检索系统也可以结合状态字段、关系数据和过滤规则。原文没有提供对照实验，不能据此认定关系图在所有决策检索场景里都更好。

示例检出两个问题，也只是演示结果，没有说明真实团队能减少多少事故。尤其是，原文没有说明工具会自动分析代码、发现遗漏的 fallback。CI 能检查的范围，取决于团队录进图里的内容。

来源同样不等于真相。作者明确说，memgraph 无法判断来源是否可信，只能追踪出处、检查关系是否仍然自洽。队列为何必须放弃 LISTEN/NOTIFY，原文也没有展开具体负载和实现约束，不能把这次选型当成通用结论。

能拿来做什么

• 在 Node.js 服务发生队列等基础方案变更时，把依据、替代原因和遗留依赖一起记录下来，重点检查 fallback 是否仍然有效。
• 如果团队愿意持续维护决策图，可以把 JSON 随代码提交，并将 memgraph check 加入 CI，让已记录的关系问题在 PR 阶段暴露。
• 在日常 AI 编程中，涉及方案沿革时先查询 memgraph why 和 memgraph list，再把结果交给 agent，帮助它区分当前决策与历史方案。
• 决策被推翻时使用 supersede 保留历史，同时继续审查证据本身；有来源、关系自洽，都不能替代技术验证。