Agent 的记忆架构常被简化为一个数据库图标，但真正决定其质量的是实体抽取的颗粒度、三层记忆的构建与治理能力。本文从实体抽取的分层流水线出发，详解短期、长期与推理记忆的协同设计，并给出企业 AI 问答的三大关键判断与落地建议，助你从存储思维转向治理思维。

你可能看过很多 Agent 架构图，Memory 那一层通常被画成一个数据库图标，旁边标注「向量存储」或「对话历史」。

这个画法最大的问题是：它让你以为记忆就是存东西。

实际上，真正决定 Agent 质量的不是「存了多少」，而是：

1. 存进去的是什么颗粒度的东西（实体还是原文）
2. 存进去之后能不能归一、去重、关联
3. 出问题时能不能追溯到具体哪一步错了

这篇文章把会分三块来讲：实体抽取怎么做、三层 Memory 怎么建、对企业 AI 问答有什么启发。

一、实体抽取：不要一上来就全靠 LLM

很多人做实体抽取的思路是这样的：把文本扔给大模型，让它输出三元组。准确率可能还行，但成本高、速度慢、稳定性也不够。

更好的做法是一条分层流水线：

spaCy → GLiNER2 → LLM fallback → confidence merge → dedup → relationship extraction → enrichment

翻译成人话：先用便宜的模型扫通用实体，再用领域 schema 补业务实体，最后只把模糊、复杂、跨句的 case 交给 LLM。

三层各司其职：

PM 洞察：第二层是整个流水线的灵魂。schema 设计决定了一切——你让模型抽什么类型，就决定了这张图未来能回答什么类型的问题。比如「校园卡」是产品还是政策？「仅新用户可办」是办理条件还是限制条款？这些分类一旦定错了，后面的知识治理全跑偏。

二、抽完实体之后的三件脏活

实体抽出来只是万里长征第一步。真正吃功夫的是后面的归一、去重和关系抽取。

第一，实体归一。同一个产品可能有多种叫法——「校园卡」「青春卡」「学生套餐」「19块那个卡」。不归一图会碎，乱归一图会脏。这需要基于上下文的消歧能力，不能只靠模糊匹配。

第二，关系抽取。只知道存在「校园卡」和「福建」没用，必须知道它们的关系：校园卡在福建是否可用、有什么办理条件、适用什么用户类型。这些关系类型（AVAILABLE_IN、HAS_FEE、HAS_RESTRICTION、APPLIES_TO）必须在 schema 层面预先定义好。

第三，来源绑定。这是企业场景的生命线——每个实体和关系都要能追溯到：哪个文档、哪个版本、哪个段落、什么时候更新的、谁审过的。没有来源绑定的图谱，很快会变成另一种幻觉。

三、三层 Memory 架构

短期记忆：记住「刚刚发生了什么」

存的是 User → Session → Message → Turn → Task 这条链路。

它的作用不是永久存档，而是保持当前任务不断线。比如用户问「这个套餐适合我吗」，下一轮又问「那便宜一点的呢？」——「便宜一点的」不是知识库能回答的问题，必须从短期记忆里找到上一轮的套餐和约束条件。

短期记忆里需要做轻量抽取：哪条 message 提到了哪个 entity、表达了什么 intent、施加了什么 constraint。

长期记忆：记住「业务世界里稳定存在什么」

这才是传统意义上的知识图谱层。存的是产品、政策、地区、渠道、办理条件、限制条款、用户类型、文档片段。

这里有一个关键的设计原则：用户偏好和业务规则必须分开存。「这个用户喜欢低价」是偏好，「福建地区不可办」是规则。混在一起，模型容易把「用户想要低价」误解成「应该强推最低价」从而忽略限制条件。

推理记忆：记住「Agent 为什么这么做」

这一层最容易被忽略，但对企业场景最重要。

它存的不是完整的 Chain-of-Thought 文本，而是结构化决策轨迹：

触发了什么任务 → 识别了哪些实体 → 调用了哪些工具 → 用了什么参数 → 召回了哪些证据 → 做了什么判断 → 为什么回答而不是拒答 → 为什么转人工或不转人工 → 最后结果怎么样

这一层的价值不是「让模型记住自己想过什么」，而是让团队能复盘 Agent 为什么错、为什么对、怎么改。

没有 Reasoning Memory，badcase 只能写成「AI 回答不准」。有了它，badcase 可以写成「地区实体识别到了，但检索时没有作为 filter 使用，导致召回广东政策回答福建问题」——这两个完全不是一个治理粒度。

四、三层记忆连成一张图

三层 Memory 不能各建各的。它们应该通过关系连在一起：

Message → Mentions → Entity Entity → Supported By → DocumentChunk Message → Triggered → ReasoningTrace ReasoningTrace → Used Tool → ToolCall ToolCall → Returned → Evidence ReasoningTrace → Made → Decision Decision → Produced → Answer Answer → Got → Feedback

一旦跑通这张图，你就能回答以前答不了的问题：哪些 badcase 都涉及同一个产品？哪些错误来自实体归一？哪些工具调用最容易带来错误答案？哪些决策路径更易获得用户好评？哪些高风险场景没触发转人工？

Graph Memory 的意义不是让 Agent 多记一点，而是让组织能治理 Agent 的记忆。

五、对企业 AI 问答的三个关键判断

判断一：不要只建知识库，要建业务对象层。

知识库是文档视角，业务对象层是实体视角。用户问的不是「第 37 页第 4 段」，而是「这个套餐能不能办、我这个地区有没有限制、老用户能不能参加」。系统内部应该围绕产品、政策、地区、渠道、条件、限制来组织，而不是围绕文档来组织。

判断二：不要只评估答案，要评估路径。

一个答案错了，可能的原因是：实体没抽出来、别名没归一、地区没过滤、召回了旧政策、工具参数错了、风险规则没触发、生成时自由发挥……至少有七八个可能的出错环节。没有 Reasoning Memory，你只能看到最后的错；有了它，你能知道错在哪一步。

判断三：不要把 badcase 一股脑塞进 SFT。

有些问题是知识源错了，有些是实体抽取错了，有些是关系没建，有些是检索过滤没做，有些才是模型行为问题。Graph Memory 的价值，就是能把 badcase 拆回系统链路的每个环节单独治理。

六、第一版怎么建：别贪大求全

我建议第一版只建一个最小可用图，三层各自覆盖最核心的实体：

第一版只追求两件事：高频业务实体能稳定抽出来，badcase 能追溯到具体错误环节。做到这两点，Agent 质量治理就已经从玄学变成工程问题了。

结语

记忆架构的本质，不是给模型外挂一个更大的记事本。

它真正做的是三件事：把聊天记录变成上下文，把知识文档变成实体关系，把模型回答变成可追溯的决策链。

对企业 AI 问答来说，最值得借鉴的不是某个工具，而是这个架构思想：

Agent 记忆不是存储问题，而是治理问题。

1. 你能治理实体，才能治理知识。
2. 你能治理路径，才能治理答案。
3. 你能治理记忆，Agent 才会真的越用越好。