你是不是也遇到过这种怪事：代理把每一句话都记得清清楚楚，却在关键决策上完全帮不上忙？事实一条不少，检索也很准，可一问“到底该先做什么”，它就开始打太极。问题往往不在记忆容量，而在它根本看不见事实之间的模式和结构。
记得很多，却看不懂：智能代理的盲区
一个项目管理助手的“智商短板”
想象一个项目管理助手，持续读取工程团队的周报。三位工程师在同一周提交了状态更新，每个人都报告了一个阻碍点，描述都很具体，也都是真问题。代理把这三条更新逐条存入记忆，任何时候你想查 Alice、Bob 或 Clara 的进展，它都能立刻调出来。
问题在于，它只会逐条复述，却说不出这三个阻碍其实都源自同一个延迟的任务。对它来说，这是三件互不相关的“小事”；对一个有经验的项目经理来说，这是一条清晰的依赖链，背后只有一个真正的“卡点”。
可以换个角度看：一个刚上手的项目经理读这三条更新，会觉得有三个独立的问题要跟进；而一个老项目经理一眼就能看出，这是同一条依赖链在不同环节上的三种表现。没人给老项目经理上过“图算法”课，他只是参加了足够多的站会，脑子里自然形成了模式识别能力。
今天大多数代理的记忆系统，却还停留在“新手项目经理”阶段：存得很细、查得很快，却完全错过了把这些点连成线的结构。
有用户反馈，他们的客服代理能准确复述每一张工单，却永远说不出“本周最致命的共性问题是什么”，结果团队还是得人工开会对日志。
Zep 推出的一个功能叫 Observations，就是专门补这一块短板的。它会在知识图谱之上自动检测跨对话的模式，把这些模式变成有证据支撑的、可持久引用的“结构化洞察”，供代理直接使用。
知识图谱：从“记住事实”到“看见关系”
知识图谱里到底存了什么
Zep 会从对话和业务数据中构建知识图谱。这个图谱由三个基本构件组成：
- 实体：各种名词，比如人、产品、地点、任务、服务等。
- 事实：连接两个实体的具体陈述，存成带标签的边，比如“支付集成 依赖 认证服务重构”。
- 事件：原始数据源，也就是被 Zep 吸收的对话消息、JSON 负载或文档。每一条事实都能追溯到它是从哪个事件里抽取出来的。
图谱既可以限定在单个用户，也可以在团队内共享。个人图谱记录的是某个用户自己的历史；共享图谱则汇聚一个项目、工作区或整个组织的所有信息，让不同人的数据落在同一张结构化“地图”上。
来看一个共享项目图谱的具体例子。
三位工程师在一周内向项目管理助手提交状态更新：
- Alice（周一）：API 迁移被阻塞，原因是要等后端团队完成认证服务重构。
- Bob（周三）：支付集成停滞，同样在等后端团队的认证服务重构。
- Clara（周五）：结账流程推进不了，因为支付集成还没准备好，这部分由 Bob 负责。
Zep 把每条更新当作一个事件处理，从中自动抽取实体和事实，写入知识图谱：
每一条事实都准确无误，也都可以单独检索出来。但图谱本身并不会自动生成“这是一条阻塞链”的抽象结构，它只是忠实地记录了点和边。
为什么“更聪明的检索”也救不了它
当代理被问到“是什么阻碍了团队”时，它会从图谱里拉出相关事实：
- Alice 被 API 迁移阻塞
- API 迁移等待认证服务重构
- Bob 被支付集成阻塞
- 支付集成等待认证服务重构
- Clara 被结账流程阻塞
- 结账流程等待支付集成
每一条都对，但这些结果里没有任何一条，单独就能告诉代理：只要把一个任务从阻塞状态拉出来，三个人的问题就一起解决了。
你可以去调重排序器、扩大搜索范围、一次返回更多结果，甚至换更大的模型。可这些都只是“把已有的事实拿得更全、更快”，并没有创造出一个新的、代表“依赖链模式”的对象。真正需要的洞察，其实藏在三段对话之间的连接方式里，而不是任何一条单独的记录中。
很多团队会搞一个临时规则：凡是被三人以上提到的任务，就自动标记为阻塞点。听上去挺聪明，但它只告诉你“大家都被卡住了”，却说不出“先解哪一个最划算”，而且只能捕捉到被直接点名的阻碍。
Clara 从头到尾没提过“认证服务”，她的更新离真正的根因隔了两跳。规模小的时候，人还能靠肉眼把这些点连起来；一旦每周有三十条、五十条状态更新，没人会愿意手动做这件事，而偏偏在这种规模下，链条信息最有价值。
Observations：把“模式”变成一等公民
一条人类项目经理会写的 Observation
在这个项目图谱上，Zep 自动生成了一条 Observation：
名称： 认证服务重构阻塞多个工作流
摘要： 认证服务重构由后端团队负责，是影响三个工作流的依赖链的根本阻碍。Alice 的 API 迁移和 Bob 的支付集成都直接等待它完成。Clara 的结账流程被支付集成阻塞。解除认证服务重构的阻塞即可清除这三条阻碍。
图谱里没有任何一条单独的事实，能完整表达这段话。它跨越了三个人、四个工作项和三段互不相识的对话，却被浓缩成一个可引用的“模式对象”。
和单条事实相比，Observations 有几个关键差异：
- 跨实体：事实只连接两个实体的一条边，Observation 会综合整个簇，把多个实体和多段对话编织成一个结构化模式。
- 有证据支持：Observation 里的每一句话，都能追溯到图谱中的具体事实和事件，开发者可以点进去看原始对话。
- 只读：你不能手动创建、编辑或删除 Observations，它们会随着底层证据的变化自动更新或废弃。
从工程视角看，这更像是“图的结构属性的自然语言投影”，而不是一条随手写的注释。
Observations 是怎么长出来的
Observations 的生成分两步：
- 先用确定性的算法做聚类，找出哪些事件在结构上属于同一簇。
- 再用大语言模型（LLM）给每个簇写一个摘要，但模型不参与“怎么聚”的决策。
第一步：把事实压缩成“签名”
Zep 会有后台进程定期扫描新数据。当新的对话被吸收、图谱结构稳定后，就会触发分析流程。第一步是把每一条事实压缩成一个 签名：由两个实体和它们之间的关系类型组成。目标是找出哪些对话在谈论“同一对实体之间的同一种关系”。
压缩之后，每个事件（对话）就变成了一组签名：
- 事件 1（Alice 的更新）：(Alice, API 迁移), (API 迁移, 认证服务), (认证服务, 后端团队)
- 事件 2（Bob 的更新）：(认证服务, 后端团队), (支付集成, 认证服务), (Bob, 支付集成)
- 事件 3（Clara 的更新）：(Bob, 支付集成), (结账流程, 支付集成), (Clara, 结账流程)
重叠关系一下就清晰了：
- (认证服务, 后端团队) 同时出现在事件 1 和事件 2。
- (Bob, 支付集成) 同时出现在事件 2 和事件 3。
- 事件 1 和事件 3 没有任何共享签名。
Alice 从未提到 Bob、Clara、支付集成或结账流程；Clara 也没提过 Alice、认证服务或后端团队。它们之间的“桥梁”，完全是通过 Bob 和认证服务这两个节点间接建立的。
第二步：构建“事件图”而不是“实体图”
到这一步，Zep 会换一个视角看世界。我也不太确定这个比喻是不是最贴切，但可以理解为：从“看任务之间的关系”，切换到“看对话之间的关系”。
它不再盯着实体之间的事实连接，而是构建一张 事件图：
- 节点是对话事件。
- 边是“共享签名”。
在这张图里：
- 事件 1 通过 (认证服务, 后端团队) 连接到事件 2。
- 事件 2 通过 (Bob, 支付集成) 连接到事件 3。
- 事件 1 和事件 3 之间没有直接边。
但三个事件仍然属于同一个 连通分量，因为事件 2 起到了桥接作用。
有意思的是，这条在事件图里追踪到的链条，恰好和项目里的依赖链结构一一对应。Zep 通过跟踪这种传递性链接，自动找到“根本阻碍”所在。这一步完全不依赖嵌入、语义相似度或任何机器学习模型，纯粹是图拓扑问题：
- 哪些对话共享关于同一对实体的事实？
- 这些共享事实如何把对话串成一个连通组？
这点非常关键。基于嵌入的聚类会把“主题相似”的内容堆在一起，比如所有提到工程工作的状态更新都被扔进一个大簇，顺带把那周其他无关的工程更新也拉进来。基于签名的聚类则只关心“是否引用了同一对实体之间的同一种关系”，因此能精准勾勒出具体的依赖链。
第三步：让 LLM 做“翻译官”而不是“裁判”
当算法识别出一个连通分量后，才轮到 LLM 出场。一次受限的 LLM 调用会拿到：
- 这个簇里的关键实体；
- 按时间顺序排列的支持对话；
- 实体之间的关系类型。
模型的任务是：
- 给这个簇起一个名字；
- 写一段摘要，聚焦在决策、约束、依赖、状态变化等“持久信号”上；
- 严格限制在证据明确支持的事实范围内，不瞎猜。
Observation 的结构属性——涉及哪些实体、包含哪些对话、时间窗口多长——全部由算法决定，LLM 只是把这些结构翻译成可读文本。这也是 Observations 被设计成只读的原因：它们本质上是“图结构的自然语言视图”。
当底层证据发生变化时：
- 有新对话加入现有模式，Observation 会用新证据重新生成；
- 出现矛盾证据，旧 Observation 会被废弃或拆分；
- 图谱始终反映当前“被证据支持的世界观”。
比如后端团队下周完成了认证服务重构，Observation 会自动更新：Alice 和 Bob 的阻塞被解除，Clara 的依赖链也发生变化，新的模式会围绕下一个真正的瓶颈重新形成。
让代理从“复读机”变成“决策助手”
同样的数据，完全不同的回答
在应用层，你可以通过 SDK 检索 Observations：
列出某个项目图谱的所有 Observations
observations = client.graph.observation.get_by_graph_id(graph_id="project-atlas")
按相关性搜索 Observations
results = client.graph.search( graph_id="project-atlas", query="blocked workstreams", scope="observations", )
想象项目经理问代理：“本周团队应该优先处理什么？”
- 没有 Observations 时，代理会检索所有阻塞相关的事实，然后列出：三个人被阻塞，两个人提到认证服务，一个人提到支付集成。项目经理拿到的是一份准确的“现状报告”，但优先级判断还是得自己做。
- 有了 Observations 之后，代理的上下文里多了一层“依赖链模式”。它会直接指出：认证服务重构是当前的根本阻碍，完成它可以立刻解除 Alice 和 Bob 的阻塞，并间接解决 Clara 的问题。本周最有杠杆的行动，是给后端团队资源和优先级，把这件事做完。
同样的查询，同样的数据，一种回答只是“描述世界”，另一种已经在“建议行动”。这就是多了一层模式识别之后的差距。有团队在内部试用时反馈：项目经理每周梳理阻塞链的时间，从半天缩到不到一小时，尤其在多人远程协作的场景下差异更明显。
Zep 的四层上下文：从事件到模式
在 Zep 里，上下文大致分成四层：
- 事件（Events）：存原始对话和业务数据。
- 事实（Facts）：把事件结构化成带时间戳的声明。
- 实体摘要（Entity Summaries）：讲述单个节点的历史，比如“认证服务”最近发生了什么。
- Observations：在簇的层面提炼模式和依赖链。
每一层回答的是不同类型的问题：
- 事件：谁在什么时候说了什么？
- 事实：这句话在结构上意味着什么？
- 实体摘要：围绕某个对象，最近的演化轨迹如何？
- Observations：跨多个对象和对话，出现了哪些稳定的模式？
Alice、Bob 和 Clara 都提交了准确的状态更新，每条事实也都被正确写入图谱并可检索。但他们三个人都看不到的是：隐藏在这些更新背后的那条阻塞链。Observations 补上的，就是这块“结构性视野”的空白。
说实话，很多团队以为自己缺的是“更大的模型”或“更多的上下文窗口”，但据一些实际部署数据看，真正拉开体验差距的，往往是有没有把模式识别变成系统的一等能力。
如果你正在为生产环境构建智能代理，这套判断“哪里是根因、哪里是症状”的方法，值得反复拿出来对照和调试，用好了比多加几块 GPU 更值。
常见问题
Q：怎么判断我的代理是否需要引入 Observations 这种模式识别层？
A：一个简单的判断方式是，看代理在“解释现状”和“给出优先级建议”之间的落差有多大。如果它能准确复述事实，却总是在关键决策问题上含糊其辞，说明只做了记忆和检索，没有真正理解事实之间的结构关系。你可以先从一个高价值场景入手，比如项目阻塞分析或客户投诉归因，接入类似 Observations 的机制，观察是否能稳定产出“根因级别”的洞察，再决定是否全面推广。
Q：知识图谱+Observations 会不会带来很大的性能和成本开销？
A：会有额外开销，但通常是可控且可预期的。图谱构建主要是结构化存储和图操作，成本更多在工程复杂度而不是算力；Observations 的生成分为确定性聚类和受限 LLM 调用，前者成本很低，后者可以通过批处理和频率控制来压缩费用。建议做法是：只对关键业务图谱开启 Observations，设置合理的分析周期（例如按天或按周），并监控“每条 Observation 带来的决策价值”，用这个指标来反推是否值得继续投入。
Q：如果底层数据有误，Observations 会不会放大错误甚至误导决策？
A：会有这种风险，所以需要把“可追溯性”设计进系统。Observations 的每一条陈述都能追溯到具体事实和原始事件，项目经理或开发者可以随时点开核对来源，这比黑盒式的“模型直觉”要安全得多。实践中建议：一是对关键实体和关系增加校验流程（例如人工审核或规则校验）；二是在界面上明确标注 Observation 的证据来源和时间范围，让使用者知道“这是基于哪些对话得出的结论”，避免盲目信任。
Q：和直接用嵌入做语义聚类相比，Observations 的优势在哪里？
A：嵌入聚类擅长发现“主题相似”的内容，比如都在聊支付、都在聊性能问题，但很难精确刻画“谁依赖谁”“谁阻塞谁”这种结构性关系。Observations 的聚类基于签名和图拓扑，只在事件之间存在共享实体关系时才连边，因此更适合发现依赖链、传递性阻塞等模式。实测中，有团队发现语义聚类会把一整周所有工程更新堆在一起，而签名聚类只会锁定那几条真正共享关键依赖的对话，两者在可操作性上差异很大。
Q：如果我的业务场景不是项目管理，这套方法还有用吗？
A：有用，而且往往更有意思。只要你的场景里存在“实体—关系—事件”这种结构，比如客服工单里的用户、产品和故障原因，销售线索里的客户、渠道和转化动作，都可以用知识图谱+Observations 来挖模式。判断标准是：你是否经常需要回答“真正的共性问题是什么”“哪条链路最关键”这类问题。如果答案是肯定的，就可以尝试把事件转成图，再用类似的签名聚类方法，让代理从堆事实变成看结构。最后提醒一句，落地前可以先在历史数据上做离线回放，看看生成的 Observations 是否和你团队的直觉一致。
