AI技术

企业Agent长期记忆：如何做成可审计的关系图谱

,
企业Agent长期记忆：如何做成可审计的关系图谱封面

9月24日AI技术日报中，Oracle AI Agent Memory 26.8新增Graph Memory、图谱感知检索、图像记忆、Schema升级和企业控制，并用supersedes、refines、supports、contradicts、duplicates等关系描述记忆之间的联系。这条消息真正值得企业关注的，不是“向量库又多了一种功能”，而是Agent长期记忆开始从相似片段集合，走向能够表达事实演化、证据关系和治理边界的组织记忆层。

传统做法通常把对话、邮件、会议纪要切成片段，计算向量后存入数据库。用户提问时，系统找出最相似的若干片段交给模型。这对短期问答有效，但一旦进入长期业务，就会暴露根本问题：新旧地址同时命中时哪个有效？某份会议结论后来被谁修正？两份报告互相矛盾时Agent依据什么行动？一段记忆来自用户陈述、系统推断还是已审批文件？如果只保存文本和向量，相似度无法回答这些问题。

可审计的长期记忆，不是“Agent记住得更多”，而是每条记忆都能说明从哪里来、何时生效、谁有权看、与其他事实是什么关系，以及它曾经影响过哪些决策。

企业Agent长期记忆：如何做成可审计的关系图谱信息图

从文本块升级为“记忆声明”

企业记忆图谱的基本单元不应是一段原始文本，而应是一条结构化声明。每条声明至少包含：主体、谓词、客体、事件时间、生效区间、记录时间、来源、证据位置、创建者、租户、密级、置信度、状态和Schema版本。

例如，“客户A的收货地址为北京地址B”不能只保存为一句话。系统应记录该声明来自客户在9月20日提交的变更单，9月22日审核通过，自9月25日起生效；旧地址并未删除，而是被新声明以supersedes关系取代。这样，Agent处理9月24日订单和9月26日订单时，会得到不同但正确的答案，审计人员也能复原当时系统可见的事实。

这里必须区分两种时间：业务事实发生或生效的有效时间，以及系统实际写入记录的事务时间。双时间模型能处理“后来才补录的历史事实”，也能回答“系统在某一天为什么会做出那个判断”。若只保留最后状态，审计就会失去历史现场。

工程上可把声明拆成不可变的statement表、可版本化的entity表和单独的relation表。statement_id永久稳定，subject_id与object_id引用企业主键，predicate引用受控词表；valid_from、valid_to描述业务有效区间，recorded_at、retired_at描述系统持有该版本的区间。原文页码、段落、图片坐标等定位信息放入evidence_locator，避免只留一个随时可能失效的链接。置信度也不宜只有一个总分，可分别记录抽取置信度、来源可信等级和人工核验状态，使检索器不会把模型“很确定”误当作来源“很权威”。

版本时间还需要明确查询语义。线上问答通常查询“现在记录的、当前有效的事实”；事故复盘则要以任务发生时刻同时截取有效时间和事务时间。对迟到数据，应追加一个带原始业务时间的新版本，而不是回写旧行；对时区、日期精度和开放区间也要统一约定。只有日期而没有时刻的材料，可以保存精度字段并采用保守边界，不能擅自补成零点。

一套四层记忆架构

第一层是原始证据层。邮件、文档、图片、会议纪要、数据库变更和工具执行结果先以不可变对象保存，计算内容哈希，记录来源系统、采集时间和访问权限。日报提到图像记忆，意味着图片不能只做OCR后丢弃原件；文字、版面、图片区域和原文件之间应保持定位关系，便于以后核验模型是否读错表格或印章。

第二层是抽取与规范化层。解析器从原始证据中提取实体、事件、关系和时间，并做实体消歧。例如“华东一厂”“一号工厂”和内部编码F-001是否同一对象，不能由每次问答临时猜测。抽取结果先进入候选区，经过Schema校验、规则核验或人工确认后，才升级为可用于自动决策的正式记忆。

第三层是关系图谱层。节点可包括人员、组织、设备、合同、项目、地点、事件和声明；边除了业务关系，还要包含日报所强调的记忆关系：supersedes表示替代，refines表示细化，supports表示支持，contradicts表示冲突，duplicates表示重复。关系边本身也应带来源、时间、置信度和创建机制，避免“边是模型猜出来的”却被当作确定事实。

第四层是检索与决策接口。查询不再只是向量Top-K，而是混合检索：先用权限和时间过滤缩小范围，再做关键词与向量召回，然后沿图关系扩展一到两跳，最后由重排器根据来源可信度、时效性、关系类型和任务风险排序。返回给Agent的不是一堆片段，而是“当前有效事实＋相关证据＋冲突提示＋历史版本”。

图谱感知检索如何避免把错误放大

多跳扩展很有价值，也很危险。若不限制路径，图谱会快速带回大量远关系信息，既增加Token成本，也可能把低置信度推断包装成事实。企业应为不同任务定义可走的边和最大深度。例如，查询客户最新地址时允许沿supersedes链寻找当前版本，但没有必要沿“同一销售负责”继续扩展；分析项目结论时可以查看supports和contradicts，却不应自动把duplicates当作独立证据计数。

检索排序可以采用一个可解释评分：语义相关度、时间有效性、来源等级、关系距离、置信度和权限匹配分别计分。高风险任务还应设置“证据门槛”：至少有一条已审批的一手来源，或者两条相互独立的支持证据；若存在未解决的contradicts边，则Agent只能提示冲突或转人工，不能自行选择更顺眼的结论。

记忆写入也不能由生成模型直接完成。更稳妥的流程是“提取—候选—校验—提交”：模型负责提出候选事实和关系，确定性程序做Schema、时间、实体与权限检查，必要时由业务人员确认，最后通过事务写入图谱。更新采用追加而不是覆盖，旧声明标记失效并建立替代关系，从而保留完整谱系。

冲突处理应区分“可自动归并”和“必须裁决”。同一来源的后续审批单、明确带生效日期的主数据变更，可按预设优先级建立supersedes；不同来源对同一对象、同一谓词、重叠有效期给出不兼容取值时，则创建冲突簇，记录发现时间、影响范围、责任人和处理期限。duplicates只合并检索权重，不删除证据；refines只有在语义更具体且不改变原声明时才能建立。裁决结果也应是一条新声明，并指向所采纳与驳回的候选，禁止悄悄删除“输掉”的版本。

审计链要覆盖读取、写入和行动

很多系统只记录“Agent最终回答了什么”，这远远不够。可审计记忆至少需要三类日志。

一是写入日志：谁或哪个模型从哪份证据抽取了什么，使用哪个提示和模型版本，经过哪些校验，谁批准成为正式记忆。二是读取日志：某次任务检索了哪些声明，哪些被权限过滤，沿哪些图关系扩展，最终把哪些内容送入模型。三是行动日志：模型基于哪些记忆做出建议，随后调用了什么工具，执行结果如何，是否被安全策略阻断。

日志应使用稳定的任务ID、记忆ID、证据ID和策略版本串联。对于关键决策，可以生成“决策包”：保存当时有效的事实子图、证据引用、模型与提示版本、权限上下文和输出哈希。这样即使模型后来升级、图谱继续变化，也能复盘当时决策。

“能够复盘”还要通过可执行回放验证。决策包应冻结检索请求、过滤条件、排序参数、返回顺序、工具输入输出摘要及依赖数据的版本号；随机性参数和模型服务标识也要记录。若旧模型或外部接口已不可用，系统至少应支持证据级复现：证明当时送入模型的上下文未经篡改，并把重新运行结果与原结果做差异报告。审计存储可采用追加写、哈希链和独立保留策略，但哈希只能证明内容一致，不能证明事实本身正确。

W3C PROV提供了描述实体、活动和责任主体的通用模型，可作为数据谱系设计参考；OpenTelemetry可用于跨模型调用和工具执行串联追踪。两者不直接替企业定义业务语义，但能减少审计字段各自为政。

权限不是图谱外面的一个过滤器

企业记忆天然跨部门、跨项目和跨时间。若先全量召回、再在结果端删敏感字段，敏感关系可能已经进入模型上下文。权限控制必须在检索最前端执行，并覆盖节点、边、属性和原始证据。一个用户能看到“项目存在”，不代表能看到合同金额；能看到合同节点，也不代表能沿边找到涉密供应商。

建议采用ABAC，即根据用户角色、部门、项目关系、数据密级、使用目的和当前环境共同授权。权限随组织变化时，也要有生效时间和审计记录。多租户环境必须在存储、索引、缓存和日志四层保持隔离，不能只依赖应用查询条件。

具体实现中，授权决定应绑定主体、资源、动作、用途和环境五类属性，并返回允许、拒绝或需脱敏，而不是简单布尔值。图遍历每扩展一条边都要重新计算权限，派生声明的密级原则上不得低于其敏感来源。向量索引可按租户与密级分区，缓存键必须包含权限上下文和策略版本，防止高权限用户的结果被低权限用户复用。紧急越权应采用有时限的break-glass流程，要求填写理由、二次确认并触发事后复核。

“被遗忘权”与不可变审计之间也需要分层处理。原始个人数据可按法规删除或匿名化，同时保留不含个人内容的操作证明、哈希和删除事件。备份、向量索引、图数据库副本与缓存必须进入统一删除清单，否则主库删除并不等于真正遗忘。

Schema演化是长期系统的生命线

日报中特别提到Schema升级，这一点常被低估。企业业务模型会不断变化：设备类型增加、合同状态拆分、组织架构调整、旧关系需要弃用。如果没有版本机制，几年后图中相同字段可能代表不同含义。

Schema应像代码一样进入版本库，包含变更说明、兼容策略、迁移脚本和回滚方案。新增字段通常可以向后兼容；修改关系语义则需要建立新类型并迁移，不能直接覆盖。每条记忆保留写入时的Schema版本，读取接口负责转换为当前视图。迁移前后应运行数据质量测试：孤立节点比例、无来源声明比例、时间区间冲突、重复实体率、无权限标签率以及矛盾关系未闭环数量。

数据工程约束比图数据库选型更重要

图数据库、关系数据库加图扩展、向量数据库与对象存储可以组合使用，选型并非第一难题。真正困难的是身份主键、来源质量和更新语义。没有主数据管理，同一客户会分裂成多个节点；没有来源等级，群聊转述和盖章合同会被等价对待；没有事件驱动的增量更新，图谱很快过期。

建议把权威业务系统作为事实源，记忆层保存跨系统关联、版本与证据，而不是反向成为所有主数据的手工副本。写入流程要支持幂等，使用来源记录ID和内容哈希去重。数据延迟应显式记录，Agent必须知道“最新同步到几点”，不能把尚未同步误解为不存在。

质量监控也应面向决策：除了图有多少节点和边，更应统计有效事实覆盖率、冲突解决时长、过期记忆命中率、无证据回答率、权限误召回率以及由错误记忆引发的人工纠正次数。

产业判断：组织记忆会成为比Prompt更难迁移的资产

模型和Agent框架会快速迭代，Prompt也很容易复制。经过多年积累、具备权限、证据、版本和关系的组织记忆层却难以在短期重建。它会逐渐成为企业AI基础设施中的独立层：上接不同模型和Agent，下接文档、业务数据库和工具系统。

这也意味着供应商锁定风险会从模型API转向记忆格式。企业应要求数据可导出、关系类型可映射、证据ID稳定、向量可重建，并把核心Schema掌握在自己手中。图谱不是为了追求“知识更丰富”，而是为了让自动化行动有可核验的事实基础。

企业落地建议

第一阶段不要追求全公司知识图谱，而应选择事实变化频繁、审计价值高的单一场景，如客户主数据变更、设备维修决策或合同条款解释。第二，先定义10—20种核心实体和5种记忆关系，尤其明确supersedes与contradicts的处理规则。第三，为每条正式记忆强制保存来源、时间、权限和Schema版本。第四，建设混合检索和一跳扩展，证明价值后再增加多跳。第五，用真实历史争议案例做回放测试，检查系统能否恢复“当时知道什么”。第六，把记忆读取与工具执行日志串联，形成完整决策链。

长期记忆的目标不是让Agent像人一样“什么都记得”，而是让它只在有权、有效、有证据的条件下记住正确的事，并在出错时能够回答：这条记忆从哪里来，为什么当时相信它，又该如何纠正。

参考资料

分享到