你的 Agent 记住一切，却什么都不理解

Agent 记忆所处的阶段，正是多年前分析学所处的阶段：你问什么，它返回什么，仅此而已。后来，分析学开始主动揭示哪个数字变了、为什么变，而无需你发起查询。Agent 记忆至今还没有完成这一跃迁。

或者说，它刚刚完成了？

今天每个 Agent 记忆系统解决的都是同一个问题：存储事实，并在查询时检索出正确的那部分。

缺失的部分，是模式识别。

设想一个项目管理助手，它阅读工程团队的状态更新。同一周内，三个人提交了更新。每个人都报告了一个阻塞项，且每个报告都准确而具体。

Agent 存储了这三条更新，并且可以随时按请求检索出其中任何一条。

但它无法告诉你的是：这三个阻塞项，最终都追溯到一个被延迟的单一任务。

可以这样理解：一个新项目经理读三份状态更新，看到的是三个需要解决的问题。一位有经验的项目经理读同样的三份更新，看到的却是一个问题、三种表象。

没有人教过这位有经验的项目经理去串联它们。他经历了足够多的站会，因此能识别出这种形态。

今天的 Agent 记忆给你的是新项目经理。它能正确存储每一条更新、准确检索它们，却错过了把它们连接起来的结构。

要填补这个缺口，需要的不是更好的检索，而是额外的一步：将已存储的事实作为结构进行分析，并把该结构所呈现出的内容写下来。

这一步的输出，就是一条观察（Observation）。它是由事实如何在多段对话之间关联而组装出的上下文，而不是任何单段对话本身所包含的内容。

每条观察都始终与产生它的具体事实和消息绑定，这正是它能成为 Agent 可以依赖的持久上下文、而非猜测的原因。

让我们看看它是如何运作的。

知识图谱如何存储数据

Zep（开源版 Graphiti）是实现了这一点的 Agent 记忆平台之一，并将该能力作为名为 Observations 的功能推出。其机制起始于它根据你的数据构建的图谱。

它从对话和业务数据中构建知识图谱。该结构有三个基本构件：

• 实体（Entities） 是名词：人、产品、地点、任务、服务。

• 事实（Facts） 是连接两个实体的具体断言，以带标签的边存储。“Maya 购买了一张站立式办公桌” 就是一条事实，位于 Maya 实体与 Standing Desk 实体之间的边上。

• 片段（Episodes） 是原始资料：Zep 摄入的实际对话消息、JSON 载荷或文档。每条事实都可追溯回其被提取自的片段。

图谱可以限定在单个用户范围内，也可以在团队之间共享。

用户图谱保存一个人的历史。共享图谱保存关于一个项目、工作区或组织的所有信息，来自许多人的数据流入同一个结构。

下面是一个共享项目图谱的具体示例。

三位工程师在一周内向 PM 助手提交状态更新：

• Alice（周一）： API 迁移被阻塞。她在等待 auth service 重构，而这项工作由后端团队负责。

• Bob（周三）： 支付集成停滞了。他同样在等待后端团队的 auth service 重构。

• Clara（周五）： 结账流程无法推进，因为支付集成尚未就绪。那项工作属于 Bob。

Zep 将每条更新作为一个片段处理，自动提取实体和事实，并构建知识图谱：

每条事实都是准确的，并且可以被单独检索。图谱中没有包含的，是这些事实共同形成的形态。

为什么更好的检索解决不了这个问题

当 Agent 查询 “what’s blocking the team” 时，它取回的是已存储的事实：

• Alice 被 API 迁移阻塞

• API 迁移正在等待 auth service 重构

• Bob 被支付集成阻塞

• 支付集成正在等待 auth service 重构

• Clara 被结账流程阻塞

• 结账流程正在等待支付集成

每一行都是正确的，但结果中没有任何信息告诉 Agent：解除一个任务，就能让三个人全部前进。

你可以调整 reranker、扩大搜索范围，或返回更多结果。

这些都没有用，因为 Agent 所需的洞察从未被存储为一条离散的内容。它存在于事实如何跨三段独立对话相互关联之中。

大多数团队采用的变通方案是一条规则：将任何被三个人或更多人提及为阻塞项的任务标记出来。但这只会告诉你团队卡住了，却不会告诉你该先解除哪个任务的阻塞，而且它只能捕捉人们直接点名说出的阻塞项。

Clara 从未提到 auth service。她的更新距离真正原因有两跳之遥。

在这种规模下，人可以手动把点连起来。但当一周有三十份状态更新时，没有人会这样做，而恰恰是这个时候，依赖链才最重要。

Observations 会产出什么

针对这个项目图谱，Zep 会生成：

名称： Auth service 重构阻塞多个工作流

摘要： 由后端团队负责的 auth service 重构，是影响三条工作流的依赖链中的根阻塞项。Alice 的 API 迁移和 Bob 的支付集成都直接依赖于它。Clara 的结账流程则被支付集成下游所阻塞。解除 auth service 重构的阻塞后，三条工作流将全部畅通。

图谱中的任何单条事实都不包含这一结论。它横跨三个人、四个工作项和三段独立对话。

三个属性使 Observations 不同于单条事实：

• 跨实体： 一条事实位于两个实体之间的单条边上。一条 observation 则跨越整个簇进行综合，连接多个实体和对话。

• 有证据支撑： 每一条论断都能追溯到图谱中的具体事实和片段。

• 只读： 你无法手动创建、编辑或删除 observations。它们遵循证据。下面的机制会解释原因。

Observations 是如何创建的

其机制是一个两阶段流水线：

• 先由确定性算法处理聚类

• 随后由 LLM 撰写摘要。模型从不决定哪些内容被归为一组。

将事实归约为签名

Zep 运行一个后台进程，定期检查新数据。当新对话被摄入且图谱稳定后，它就会启动分析。

第一步，将每条事实归约为一个 签名（signature）：它连接的两个实体，加上关系类型。目标是找出哪些对话引用了相同实体之间的相同关系。

归约之后，每个片段（对话）都有一组签名：

• 片段 1（Alice 的更新）：(Alice, API Migration)、(API Migration, Auth Service)、(Auth Service, Backend Team)

• 片段 2（Bob 的更新）：(Auth Service, Backend Team)、(Payments Integration, Auth Service)、(Bob, Payments Integration)

• 片段 3（Clara 的更新）：(Bob, Payments Integration)、(Checkout Flow, Payments Integration)、(Clara, Checkout Flow)

重叠部分变得清晰可见：

• (Auth Service, Backend Team) 出现在片段 1 和片段 2 中

• (Bob, Payments Integration) 出现在片段 2 和片段 3 中

• 片段 1 和片段 3 之间没有共享内容

Alice 从未提到 Bob、Clara、支付集成或结账流程。Clara 从未提到 Alice、auth service 或后端团队。

构建片段图

在这里，Zep 转换了视角。

它不再看由事实连接的实体，而是构建一个 片段图（episode graph），其中对话是节点，共享签名是边。

• 片段 1 通过 (Auth Service, Backend Team) 与片段 2 相连

• 片段 2 通过 (Bob, Payments Integration) 与片段 3 相连

• 片段 1 和片段 3 没有共享签名

但三者最终落在同一个 连通分量（connected component） 中，因为片段 2 充当了桥梁。

Alice 的更新和 Clara 的更新虽然没有任何共同实体，却加入了同一个簇，因为 Bob 的更新同时触及两侧，并在其间架起桥梁。

值得注意的是，算法所跟随的链与项目中的依赖链是同一种结构。Zep 正是通过它生来就用于追踪的那种传递性关联，找到了根阻塞项。

这个过程不使用 embedding、不依赖语义相似度，也不动用任何 ML 模型。它是纯粹的图拓扑：哪些对话共享关于同一对实体的事实，以及这些共享对如何将它们串联成连通组。

这个区别很重要，因为基于 embedding 的聚类会把讨论相似主题的内容归为一组。在那种方法下，三份状态更新会仅仅因为它们都是关于工程工作的而被聚在一起，同时被聚进去的还会有当周所有其他状态更新。

而基于签名的聚类，会将引用了相同实体之间相同关系的对话归为一组，这正是使具体依赖链变得可检测的原因。

总结聚类结果

一旦算法识别出连通分量，LLM 就会撰写摘要。

一次受约束的 LLM 调用会接收到该簇的关键实体、按时间顺序排列的支持性对话，以及关系类型。

随后它返回一个名称和摘要，并倾向于决策、约束、依赖和状态变化等持久信号，且只局限于证据明确支持的事实。

observation 的每一个结构属性（哪些实体、哪些对话、时间窗口）都由算法决定。LLM 只是将该结构转化为可读的散文。

这就是为什么 observations 是只读的。它们是图的结构属性，只是用自然语言描述出来。当证据发生变化时：

• 与现有 observation 匹配的新对话，会促使该 observation 带着新证据被重新生成

• 相互矛盾的证据会导致旧 observation 被弃用

• 图谱始终反映当前已知的状态

如果后端团队下周交付了 auth service 重构，observation 就会更新。Alice 和 Bob 解除阻塞，Clara 的依赖发生变化，模式会围绕现在真正阻塞工作的因素重新形成。

这对 Agent 意味着什么改变

通过 SDK 检索 observations：

# List all observations for a project graph
observations = client.graph.observation.get_by_graph_id(graph_id="project-atlas")

# Search observations by relevance
results = client.graph.search(
    graph_id="project-atlas",
    query="blocked workstreams",
    scope="observations",
)

现在，假设 PM 问 Agent 团队本周应该优先做什么。

如果没有 observations， Agent 会检索到阻塞事实并罗列出来。三个人被阻塞。两人提到 auth service。一人提到支付集成。PM 得到一份准确的总结，但仍然需要自己理清优先级。

如果有 observations， Agent 的上下文中会包含依赖链。它会报告 auth service 重构是根阻塞项，解除它可以直接让 Alice 和 Bob 前进、并顺带解除 Clara 的下游阻塞，而本周杠杆率最高的单一行动，是让后端团队获得完成这项工作所需的资源。

同样的查询，同样的数据。一种响应描述了状况，另一种则指出了行动。

更宏观的图景

Zep 中上下文的演进层次：

• Episodes（片段） 存储原始对话数据

• Facts（事实） 将其结构化为带时间戳的断言

• Entity summaries（实体摘要） 叙述单个节点的历史

• Observations（观察） 跨聚类综合模式

每一层回答不同类型的问题。它们合在一起，推动 Agent 从回忆走向理解。

Alice、Bob 和 Clara 各自提交了准确的状态更新。每一条事实都正确进入了图谱，每一条都可以被检索到。

但三个人都无法报告的——因为他们都看不到的——是贯穿三者之下的那条链。

这正是 Observations 所填补的缺口。它不是对人们所说内容的更好检索，而是对他们合并数据所呈现出的结构进行分析。

资源：

• Zep Graphiti GitHub 仓库 →

• Zep Observations 文档 →

如果你正在构建一个 AI 工程师会喜欢开源工具，欢迎联系我们。我们只覆盖那些通过我们自身测试的工具，所以我们会先试用你的工具，并且只有它经得起检验时才会撰写文章。

感谢 ZepAI 赞助本期内容。