跨 15 个模型和超过 20 万次模拟对话同一份任务内容被拆成多轮后平均准确率掉了 39%。把这些碎片重新拼回单轮几乎不增不减损失大部分收回来。变量只有一个上下文怎么排。生产里的 Agent 每天都在重复这场实验。模型本身没有记忆第 20 轮它“记得”客户是谁只是因为记忆层在调用模型之前已经替它裁好了一段 Prompt。固定 token 预算、无限增长的历史、一条刚进来的用户消息——选择发生在推理之前而不是推理之中。客服系统最常见的翻车不是库里没存到话。三月客户说自己还在 Standard五月又说四月 28 日已经升到 Enterprise。相似度检索会把两句话一起捞回来两句都相关谁也没写“后一句作废前一句”。Agent 于是很有把握地同时引用两套套餐。我起初以为这是召回阈值没调好。后来顺着失败样本往下看发现系统在用同一种通道回答完全不同的问题。四代 Agent 记忆各自修好了上一代也各自留下新的缺口整段对话塞进 Prompt短会话里最正确也最早坏掉。坏掉的顺序常常不是窗口先满而是输入变长后模型就开始漏约束、提前下结论。滚动摘要把 token 增长按住了却把日期、工单号、错误码、精确金额一起按没了。Agent 还记得“出过 schema drift”却说不出字段名和偏移量。切块再 embedding适合回答“他们有没有提过 X”。它不适合回答“现在哪句还成立”。旧事实和新事实对向量模型长得很像一起回来谁也不带失效标记。时序知识图谱换的是存储单位。客户、管道、套餐变成节点“升级”“读取自”“部署在”变成带时间窗的边。同一份数据至少能被读成三种东西顺着一条边得到可核验的断言收拢一个节点上的全部边得到人物或系统画像看边与边的聚类得到没人亲口写过的模式。前三代给你一种读法。图给你多种读法。这才是后面六种上下文能成立的前提。认知心理学那套 semantic / episodic / procedural描述的是记忆“关于什么”不是“怎么取回来”。评测集真正打的是另一组能力抽细节、跨会话推理、处理被替换的事实、判断某段时间里什么为真、以及知道史里根本没有答案。标签贴上去以后检索路径往往还是同一条。六种问题形状对不上同一种检索对象把医院病历柜里的化验单、出院小结、原始手写记录和年度体检趋势叠成一叠再按“看起来像这次主诉”抽三张医生会同时看到过期指标和当前指标。Agent 记忆层现在经常就是这样工作。下面这六问来自同一段虚构客户史Northwind 的数据工程师 Priya三月搭了orders_ingest五月在同一段对话里报了套餐升级和夜间 schema-drift八月新开会话只打了一句hi。问法不同该递进 Prompt 的对象就不同。生产里真正会被问到的事需要的对象只用相似文本会怎样什么变了、何时变带有效期的事实边新旧套餐并列没有替换关系把这个东西讲清楚持续维护的实体摘要每月碎片要靠模型现场拼图客户原话是什么未改写的原始 episode错码和字段名被摘要吞掉那次会话最后怎么收的线程级结果而不是单条断言服务恢复和根因未解被揉成一句为什么老重复发生跨会话、有证据的 observation把共现直接读成因果新会话第一句只有 hi提问前就在场的用户摘要冷启动只能再问一遍身份Zep 把这六种形状做进同一张时序图底层引擎是开源的 Graphiti。写入时抽实体和关系过期事实被关闭有效期而不是删除读取时按问题形状取不同切片而不是只返回 Top-K 段落。事实边带四套时间valid_at/invalid_at记现实世界里何时成立、何时失效created_at/expired_at记系统何时知道这件事。有人三月结婚系统四月才吃到数据问“三月时是否已婚”图仍然答得对——它分得清“世界里为真”和“系统得知”。套餐那例同样如此。Enterprise 从 4 月 28 日打开Standard 在同一天关闭。会话发生在 5 月 8 日变更发生在 4 月 28 日两套时间都被保留。向量库可以同时持有这两句却不会告诉模型一句已经替代另一句。实体摘要是另一副面孔。问“orders_ingest是什么”Agent 需要一段能读的简介读 Postgres、自建连接器、处理量、近期故障。这段话没有人一次性写过是图在新事实进来时重写的。只有摘要会流利但过期只有事实会正确但每次都要现场组装。Episode 是源文本。Priya 报障时写下的字段名、类型冲突、错误码、字节偏移工单系统要的是原句不是转述。线程摘要则包装一次会话的结局服务恢复了根因没找到。下一班支持需要同时看见这两件事而不是从散落事实里再推理一遍。Observation 更危险也更有价值。三次 schema-drift 前面都出现过定时回填图可以给出“值得排查的重复序列”但不能替你宣判回填就是原因。用户摘要则挂在客户中心节点上不跟当前 query 绑定。八月那句hi没有可检索的关键词却已经足够把职位、管道和未结问题垫进第一轮。形状跟问题走 而不是让业务自己拼六次检索六种类型听起来像六套 API、六个 top-k。生产里不该这么用。Zep 的默认路径是一次thread.get_user_context()背后按字符预算混排、统一排序让“计划变更”偏向事实“hi”偏向用户摘要。块变小窗口才留给工具定义和当前指令。不是每个 Agent 都要六种全开。一次性查数的助手事实边可能就够。还没有跨会话历史的产品observation 是空转。用户进线时已经带好账号身份用户摘要的边际收益会明显小于寒暄式入口。fromdatetimeimportdatetime,timezonefromdataclassesimportdataclassfromtypingimportOptionaldataclassclassFact:subject:strpredicate:strobj:strvalid_at:datetime invalid_at:Optional[datetime]created_at:datetime source_episode:strdefclose_interval(old:Fact,new_valid_at:datetime)-Fact:新事实到来时关闭旧区间而不是覆盖写入。# 4月28日升级Standard 在同一时刻失效历史仍可按时间点查询returnFact(subjectold.subject,predicateold.predicate,objold.obj,valid_atold.valid_at,invalid_atnew_valid_at,created_atold.created_at,source_episodeold.source_episode,)deffacts_as_of(facts:list[Fact],when:datetime)-list[Fact]:按世界时间切片回答的是当时为真不是库里最新写入。return[fforfinfactsiff.valid_atwhenand(f.invalid_atisNoneorwhenf.invalid_at)]standardFact(Priya,on_plan,Standard,valid_atdatetime(2026,1,1,tzinfotimezone.utc),invalid_atNone,created_atdatetime(2026,3,2,tzinfotimezone.utc),source_episodemsg_march_onboarding,)enterprise_validdatetime(2026,4,28,tzinfotimezone.utc)standardclose_interval(standard,enterprise_valid)enterpriseFact(Priya,on_plan,Enterprise,valid_atenterprise_valid,invalid_atNone,created_atdatetime(2026,5,8,tzinfotimezone.utc),# 5月8日才说出口source_episodemsg_may_upgrade_and_incident,)print([f.objforfinfacts_as_of([standard,enterprise],datetime(2026,4,1,tzinfotimezone.utc))])# - [Standard]print([f.objforfinfacts_as_of([standard,enterprise],datetime(2026,5,1,tzinfotimezone.utc))])# - [Enterprise]上面这段不是 Graphiti 源码是把“关闭区间、保留双时序”从产品叙事里拆成可运行的最小逻辑。工程上 Graphiti 还会在写入时做实体解析、矛盾边失效和混合检索向量 全文 图遍历Zep 云侧再把六种形状装配成一块 Context Block。自建走 Graphiti Neo4j / FalkorDB / Neptune托管走 Zep边界要划清别把商业装配层误当成开源核心。维度切块向量记忆单摘要记忆时序图 多形状装配实测能力“说过类似的话”召回快叙事连贯、token 稳定能区分当前真值、原话、会话结局和跨会话模式长尾风险过期事实与现行事实并列关键数字被压缩掉且难以追溯抽取误差会变成结构化幻觉observation 容易被读成因果上手成本管线熟、调参直觉强实现短、行为难审计要设计本体、失效规则和预算装配还要接受写入时的 LLM 抽取成本记忆层很像机场的航班屏而不是相册。相册按“看起来像飞机”把旧票和新票贴在一起航班屏必须同时告诉你这班曾经计划几点、现在几点、以及取消记录还在不在。Agent 要的是后者。另一处更硬多轮掉点的论文里CONCAT 几乎回到 FULL说明内容没丢是排布和过程把模型带偏了。记忆层如果仍只交一种段落等于每轮主动把任务再 shard 一次。为什么我觉得“再把检索打磨一轮”救不了过期套餐存储早已不是胜负手。会宣传自己记忆更好的厂商多半在说选择更好。选择如果只有相似度一条路那它再精也只能回答一种问题。图也不是万能补丁。写入抽取会错实体合并会错observation 会把相关说成机制。默认 Context Block 仍然受字符预算约束预算用满时形状优先级比又多召回 20 条更重要。对只做单次查找的 Agent 强行上六种类型是在用平台复杂度换不存在的失败模式。可复用的判断只有一句先看 Agent 答错时缺的是哪一种对象再决定打开哪一种形状。过期事实对事实边需要出示证据对 episode冷启动对用户摘要反复出现但没人写过的结构对 observation。多轮损失的是排布不是字。记忆层每轮都在替模型做一次排布。存得更多、排得更像都改变不了这件事——“什么变了”和“原话是什么”不是同一种对象一段被检索回来的文本不能同时充当两者。你们线上 Agent 最近一次答错更像套餐过期、原话丢失、开场失忆还是把共现当成了根因把那一次失败映射到一种形状上再决定要不要上图。本文改写自 Akshay Pachaar 关于 Zep / Graphiti 六种上下文的公开长帖并对照了 Zep Context Types 文档与 Laban 等人的多轮对话评测。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。
