Agent记忆记得一切却理解不了 因为缺少大脑蓝图

Agent记忆记得一切却理解不了 因为缺少大脑蓝图

你的Agent把所有对话、文档、事实都存进了记忆，查询时却经常返回噪声。向量库按相似度召回，跨块连接直接失效；换上知识图谱，节点和边有了，可实体全是“Topic”，关系全是“RELATES_TO”，按严重程度或客户层级过滤根本做不到。数据在，结构却不在。Agent没忘任何东西，只是没人告诉它该关注什么。

我起初以为，把事实塞进图谱就能自动获得多跳推理。后来把客服场景的50段真实对话跑通，才发现：LLM自己决定实体类型、关系标签和属性时，结果永远是通用的。图谱退化成了昂贵的向量库。真正的修复很直接——提前定义模式，把领域蓝图写进提取模型。这份蓝图就是本体。

平面检索为何在多跳推理上崩溃

向量记忆把事实切成文本块，靠语义相似度召回。这在单块事实时够用，一旦查询需要连接不同块的事实，立刻失效。

三句事实：

• Alice管理Project Atlas
• Project Atlas跑在PostgreSQL上
• PostgreSQL集群周二宕机

问“Alice的项目是否受周二宕机影响”，需要三条全部串起来。向量搜索通常只召回第1和第3条——它们都提到相关词。第2条是桥梁，既不提Alice也不提周二，相似度匹配直接漏掉。

知识图谱把实体变成节点、关系变成边，靠遍历而不是匹配。那条链（Alice → manages → Project Atlas → runs on → PostgreSQL）对平面检索不可见，对图谱却是原生支持。

记忆流水线里真正决定一切的一步

图基Agent记忆几乎都走同一条流水线：

提取是黑盒。你把文本丢进去，LLM自己挑类型、标签、属性。你对分类和结构零控制。客服场景里，工单变成“Topic”，客户变成“Object”，关系变成“RELATES_TO”。数据全在，却无法按类型、严重程度或套餐层级过滤。查询返回噪声。

用Pydantic把模式提前钉死

修复方式和AI栈其他地方一模一样。FastAPI用Pydantic响应模型，函数调用用Pydantic schema，Agent记忆也一样。

在Zep里，用EntityModel（Pydantic BaseModel子类）定义自定义实体类型，配上EntityText字段和描述。描述和文档字符串至关重要——具体例子给提取模型足够信号，教它原本不知道的词汇。

# 定义用户实体 —— 描述直接指导提取模型分类
from zep_cloud.types import EntityModel, EntityText

class User(EntityModel):
"""公司内部或外部的实际人员，包括员工、客户、合作伙伴"""
name: EntityText = Field(description="全名，例如 'Alex Chen' 或 '企业客户 Acme'")
role: EntityText = Field(description="职位或角色，例如 'lead developer' 或 'enterprise account manager'")
plan_tier: EntityText = Field(description="客户套餐层级，仅客户实体有效，例如 'enterprise' 或 'pro'")

# 技术实体同样模式
class Technology(EntityModel):
"""编程语言、框架、数据库或基础设施组件"""
name: EntityText = Field(description="技术名称，例如 'PostgreSQL' 或 'Docker'")
category: EntityText = Field(description="类别，例如 'database'、'container' 或 'language'")

边类型用EdgeModel，并携带属性：

class WorksOn(EdgeModel):
"""用户在某个项目上的工作关系"""
role: EntityText = Field(description="在该项目中的具体角色，例如 'lead developer'")

class UsesTechnology(EdgeModel):
"""用户使用某项技术的熟练程度关系"""
proficiency: EntityText = Field(description="熟练度，例如 'advanced' 或 'intermediate'")

最后用EntityEdgeSourceTarget把源/目标约束写进图谱：

# 约束强制类型安全
# WORKS_ON 只能连接 User → Project
# USES_TECHNOLOGY 只能连接 User → Technology
# 不符合约束的关系不会产生类型化边

模式一旦激活，提取流水线跑五步：实体识别 → 实体解析（合并“Nexus”和“the Nexus project”）→ 事实提取（输出类型化边）→ 事实解析（检测矛盾并失效旧事实，保留历史）→ 时间提取（把时间引用映射到边的有效窗口）。你的Pydantic模式直接指导第1和第3步。

实际走通一次摄入与查询

摄入一段开发者Alex讨论工作的对话（活跃Web应用Nexus、技术栈、熟练度）。查询Project节点，返回的是带project_status和project_type属性的Nexus，而不是通用“Topic”。边也是类型化的：WORKS_ON带着role: lead developer，USES_TECHNOLOGY带着对应熟练度。现在可以精确过滤“哪些活跃项目使用PostgreSQL”。

上下文模板再把类型化事实组装成提示就绪块。你定义要包含哪些边类型和实体类型，Zep加上时间注解，格式化成单一字符串注入Agent。

10/10/10硬约束与模式作为推理边界

Zep强制最多10个自定义实体类型、10个边类型、每类型最多10个字段。这是刻意的——逼开发者先想清楚领域里真正重要的东西，而不是建模一切。

源/目标约束同时是护栏：模式里没有Project到Competitor的边类型，即使对话提到两者，提取模型也不会创建该关系。模式定义了合法记忆的空间。这和类型化函数调用同一原理——约束LLM输出空间，防止无效参数。记忆模式把同样约束应用到Agent存储的内容上。

从3-4个实体类型和3-4个边类型开始，先覆盖领域逻辑的80%，再增量加复杂。

无模式约束的Agent记忆，就是一个行为像向量库的图谱。你付了图谱构建的成本，却没拿到结构化检索的收益。模式是把收益拿回来的方式，而且它是Pydantic，没有新东西要学。

这在领域专用场景尤其明显。LLM对通用知识提取还过得去，一旦出现内部术语、与常见词碰撞的产品名、训练数据里没有的黑话，无指导提取就产出胡言。模式把领域词汇直接带进提取步骤，LLM不需要见过你的术语，只需要你写的定义。

向量记忆便宜却扁平，无模式图谱昂贵却通用，有模式的图谱才真正让多跳推理可过滤、可查询、可信任。你现在的Agent记忆，是在用哪种方式记住世界的？欢迎直接说。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。