最近 GitHub Trending 里有个叫 Semantica 的项目，仓库主页把自己称为“面向上下文和可问责 AI 系统的图原生基础设施”。这个说法挺大，里面既有知识图谱、来源追踪，也有本体、规则推理、冲突检测和审计导出。光看 README，容易把它归到又一个 GraphRAG 项目里。
我觉得它瞄准的，是 Agent 进入工作流后会越来越常见的一类问题。
假设一个 Agent 改错了配置，或者把一段内部信息写进了不该出现的地方。你回头查，会看到一串工具调用，一堆对话摘要，可能还有最后一条“任务已完成”。可真正想问的几件事，常常没有地方可问。
它当时参考了哪份文档？那份文档是不是已经过期？它引用的规则后来被谁改过？它为什么把这一步判断成允许？这个动作又影响了后面哪些结果？
很多 Agent 的“记忆”能帮它在下一轮找到相关资料，却帮不了团队在出事后把这条判断路径讲清楚。
Semantica 想补的，正是这一块。
能找回内容，不等于能解释决定
先把一个容易混淆的概念分开。
向量检索和 RAG（检索增强生成）解决的是“现在有什么材料和眼前问题相近”。用户问某个项目的部署方式，系统从文档、工单或历史对话里找出相似片段，模型据此回答。这套做法很有用，很多 Agent 的长期记忆也靠它起步。
可相似内容只是一次判断的输入之一。
拿一个编程 Agent 举例。它准备执行 git push，表面上只是一条命令。团队真正关心的却是一段任务历史。它是否一直在用户指定的仓库里工作，是否读取过 .env 或客户资料，提交的文件从哪里来，是否经过测试，推送目标是不是受控仓库。
向量库可以找回“仓库发布规范”或“不要泄露凭据”这两段文本，却不天然保存这次 push 和前面那些事实之间的关系。它也不会自动留下一张能供人复盘的图，说明“读取受限文件”如何让“外部推送”从普通动作变成需要确认的动作。
这就是记忆和决策证据分家的地方。
前者服务于 Agent 当下工作。它把相关信息找回来，让模型少忘东西。后者服务于人和系统之后的追问。它要保留这次判断碰过什么事实，受过什么规则约束，最后造成了什么后果。
两类能力可以放在同一个系统里，职责却不同。把它们都叫做 memory，反而会掩盖工程上的缺口。
一条日志通常不够用
日志当然重要。没有日志，连 Agent 调了什么工具、改了哪些文件都很难说清。
问题是大部分日志更像流水账。它能告诉你 10 点 31 分调用了某个工具，10 点 32 分写入了一个文件，10 点 33 分发起了网络请求。它不擅长回答这些动作背后的关系。
例如，一条“写入配置文件”的日志很难表达以下区别。
第一种情况里，Agent 正在当前项目中更新用户指定的测试配置，提交前跑过了已有测试。
另一种情况里，它先抓取了外部网页，又读了本地凭据文件，随后新建一个配置文件并准备推到陌生仓库。
最后一个动作都可能是写文件或推送。风险判断却已经不同。差异不藏在某一行日志里，藏在几条事实、一次规则检查和后续动作组成的路径里。
这也是为什么不少团队在 Agent 出问题后会陷入一个很熟悉的循环。有人翻聊天记录，有人看终端输出，有人检查 git diff。最后大家大概知道“它做错了”，但说不清它在第几个判断点偏离了，也无法把这个判断点变成下一次任务的固定检查。
事件多了以后，日志会越来越长，解释反而越来越短。
Semantica 想保存的，是一次判断的来路
按照 Semantica README 的描述，它把实体、事实、关系和决策都放进 Context Graph（上下文图）里。项目提供的 record_decision() 接口会把一次决策作为结构化节点保存，再通过因果关系把它同上游依据和下游影响连接起来。项目方还提供 trace_decision_chain() 这类查询，用于回溯一项决策的因果链。
它在 README 里举的是高风险业务案例，比如贷款审批和药物相互作用检查。这里不妨把它缩小到更日常的 Agent 场景。
一个文档整理 Agent 收到任务，先记录用户要求和允许访问的目录。它读到一份标记为内部的文件，又从一份公开网页抽取了补充信息。之后它生成摘要，尝试发邮件给外部联系人。系统如果只记录“发送邮件”，留给人的只有一个动作。
如果把判断过程记录下来，邮件节点可以关联到任务目标、读取过的材料、内部数据标签、收件人所属域名、触发的策略，以及用户有没有最终确认。后来发现摘要泄露信息时，团队不用从全量日志里猜。它可以沿着邮件这个节点向前找，看到哪份输入把风险带进来，也能向后看同一份摘要是否又被上传、归档或复用。
这就是项目所说的 provenance（来源追踪）和 decision record（决策记录）在 Agent 里的实际含义。它们把原本散落在消息、工具和数据库里的事实，组织成可以提问的对象。
Semantica 还强调其图构建、规则推理和来源层可以在不调用 LLM 的情况下运行，并支持 W3C PROV-O 导出。这个定位对金融、医疗、法律等需要审计的业务尤其有吸引力。项目是否能在复杂生产环境里兑现这些承诺，需要使用者自己验证；README 能证明的是它已经把“决策记录和来源关系”当成产品中心，而不只是附在向量检索后面的功能。
官方 README 的 Knowledge Explorer 演示 展示了图谱浏览、决策节点和实体关系如何放在同一个界面里。它是产品演示，不是性能测试，适合把它当作理解这套数据组织方式的参考。
先问为什么，再谈要不要上图
看到知识图谱，很多人的第一反应是架构要变重了。这个担心没有错。
图数据库、本体、实体消歧、事实冲突和时间版本，每一项都需要维护。原始数据质量不稳时，图只会把混乱关系画得更清楚，不会替团队修掉错误。规则写得太宽，Agent 会被误拦；规则写得太窄，审计记录再完整也挡不住问题发生。
更现实的一点是，很多任务根本不需要它。
一个只读的问答机器人，能访问的资料很少，也不会调用外部工具，向量检索加普通日志往往就足够。一个一次性的数据清洗脚本，输入和输出都在受控目录里，留好版本记录和执行日志也比引入整套图层更划算。
图结构真正有价值的地方，出现在任务会跨多个来源、多个工具和多个时间点，且一次判断会影响后续权限、数据流向或业务结果的时候。
例如，Agent 会根据合同、CRM、网页和邮件共同决定是否外发报价；或者多名 Agent 共享客户上下文，又需要知道哪条规则在什么时候覆盖过旧规则。到了这种程度，团队需要的就不只是“搜到一段相关文本”，还需要知道这段文本被谁用过，如何影响了某个动作，以及新事实出现后哪些旧决定需要重审。
这时，决策图才有机会比一堆拼接式日志更省事。
上图来自 Semantica 的官方架构素材，展示的是项目设计里的 Agent 上下文流，不表示任何通用实现都必须采用同一套组件。
小团队可以从四个字段开始
不必一上来安装图数据库，也不必先设计完整的本体。
如果团队正在做会写文件、发消息、改代码或调用业务 API 的 Agent，可以先为高影响操作补齐一小份记录。记录用户最初授权它做什么，允许在哪个目录、项目或系统里活动。记录这个动作参考了哪些文件、网页、工单、规则或人工指令。再把它为什么准备执行、命中了哪条策略、是否经过用户确认，以及调用是否成功、改了什么、哪些后续任务又引用了结果，一并留下来。
这四类信息的价值很朴素。任务出问题时，团队能把一次动作还原为一串事实，而不是只看到模型最后的自然语言解释。后来发现某类错误反复出现，也能把它们聚到同一种判断上，改规则、补测试或收紧权限。
存储形式可以先很简单。数据库里的关联表、带 ID 的 JSON 事件、任务目录里的结构化 Markdown 都可以。关键在于每个高风险动作都能回到依据和后果，而不是每个模块都必须换成图数据库。
有些团队做到这一步就够了。只有当跨任务、跨系统的关系开始多到手工关联很困难时，再考虑引入 Semantica 这类完整的图基础设施，会更稳一些。
记忆负责找资料，证据负责回答问题
Agent 的记忆当然还要继续做。没有检索和摘要，它每次任务都得重新翻项目资料，合作体验很快就会变差。
不过，随着 Agent 获得更多工具和权限，记忆系统会同时承担两种工作。一种是把相关信息带回当前上下文，帮助它推进任务。另一种是保留足以让人复盘的判断依据，帮助团队知道它为什么这样做。
前一种关心相关性和速度，后一种关心来源、版本、规则和后果。两者偶尔会共用同一份数据，但不能互相代替。
Semantica 的价值还谈不上已经被生产环境验证。它至少提醒了一件容易被忽略的事。团队给 Agent 加“长期记忆”时，别只问它能记住多少文档，也该问一遍，当它做出一项会影响外部世界的决定，我们能不能把这项决定的来路讲明白。
参考来源
以上来源主要用于说明 Semantica 的公开设计和来源追踪标准。项目仓库中的功能说明属于项目方口径，本文不将其等同于独立性能或生产效果验证。