Agent 记忆最危险的一步：把“这次”写成“永远”

Agent 记忆管线里常见一段流程：对话、工具结果、任务结果送进 extractor，extractor 提出候选记忆，候选直接写进长期存储。看起来很顺。旅行助手很快会同时记住三句话：

• 我通常偏好靠过道。
• 这趟航班订靠窗。
• 航班延误了 25 分钟。

这三句话不能同权。第一句可能影响以后订票，第二句只属于这趟行程，第三句航班结束就失效。问题不在存储容量。瓶颈在写入前那道判断：候选记忆到底该进账户、进当前行程、留在会话，还是直接拒绝。

Akshay Pachaar 在 X 上把这条管线拆得很清楚：强记忆系统能记录事实来源、做冲突解析、跟踪有效期，这些不该让一个额外模型重复做。决策模型只在应用有产品级规则时才有位置。比如旅行应用要求：用户明确说过的偏好才能进账户级记忆；从单次预订推断出的偏好只挂在这次行程；护照号和支付信息不进通用记忆；模糊候选留在会话里等确认。

这一步需要语义判断。候选被分类后，普通代码就能执行策略。难点是分清“长期偏好”“一次性指令”和“弱证据推断”。

Jev 是 TypeSafe AI 推出的 System One 决策模型。它不写段落，也不聊天。输入是一段 state 和若干 typed questions，输出是选项、分数、概率。问题类型有三种：Choice 从给定选项里选一个，Score 落在有序刻度上，Noul 回答是或否并给 0 到 1 的概率。多个问题可以针对同一份 state 并行评估。代码保留分支，模型只提供模糊判断。

Akshay 的原帖用了旅行助手的例子。对每个候选，应用把提议事实、源证据、当前用户/行程/会话状态发给决策模型，问几个有类型的问题：用户是否明确表达了这个偏好？它是否应超出当前行程？保留范围是什么？以后复用会不会造成真实风险？返回概率后，阈值留给代码：

if aisle_pref.probability > 0.8 and aisle_pref.confirmed:
    store_account_memory(user_id, aisle_pref)
elif window_request.apply_to == 'current_trip':
    attach_to_trip(trip_id, window_request)
elif delay.is_temporal:
    keep_in_session(session_id, delay)
else:
    reject_or_ask_user(candidate)

这段代码的价值在于可审查。低置信度去人工确认，敏感字段在进入通用记忆前拒绝。模型版本、问题、标准、阈值都要记录，才能回放。

主推视频来自 Akshay 的帖子，展示 Jev 的定位和记忆判断。

需要说清楚边界：Jev 不能生成文本、代码、摘要，也不适合算术、计数、日期比较、精确字符串操作。它不擅长需要多步隐藏推理的判断。上下文里塞太多无关材料会降低准确率。用户可控的 state 也要当作不可信输入，prompt injection 可以移动答案。所谓“不会幻觉”要精确表述：它不能返回 schema 外的值，但可以自信地选错 schema 内的值。

Graphiti 在这个组合里负责记忆层。它是开源的时序上下文图框架，处理 extraction、实体解析、来源追踪、时序更新和检索。Akshay 的建议是，应用把批准的候选作为 episodes 发给 Graphiti 这类系统。如果 Graphiti 当前的 ingestion 已经满足需求，不必加决策模型。只有当产品规则要求在写入前检查“偏好是否被确认”“事实是否安全存储”时，才需要在前面加一道决策模型。

Graphiti 仓库也给了一个直接信号：它提供 JevClient，把节点去重和边解析路由到 Jev，重复阈值默认 0.7，矛盾阈值默认 0.8。文档明确说，Jev 只该接 dedupe_nodes.nodes 和 dedupe_edges.resolve_edge，不要用于 extraction、摘要或其他生成任务。内容会发给 TypeSafe 托管的 API，这个数据边界要在接入前讲清楚。

Graphiti 的时序图能保存事实的有效窗口：什么时候成立，什么时候被替代。旧事实被标记失效，不直接删除。这个设计对“用户时区变了”很关键。有网友在回复里说，自己的 bot 把旧时区和新时区都当成长期事实；最后用的办法很土但有效：关于用户的事实以最新为准，一次性信息进带日期的日志，按时间过期。

另一个容易漏的点是决策和理由。John Rood 在回复里提醒，记忆闸门如果只分类事实和偏好，可能把“当时为什么这么决定”丢掉，过一阵 agent 又重开一个已经讨论过的问题。他的建议是保留对话上下文。Scott Benson 补了一条更可执行的规则：extractor 永远不直接写长期记忆；它只提议，闸门决定，日志把源证据放在每条事实旁边，方便以后解释“它为什么被留下”。

这些规则比“多存一点”更接近工程现实。记忆不是仓库越大越聪明。写入前的语义闸门、可追溯的证据、按风险分层的阈值、能过期的会话状态，缺一个都会出事故。

Jev 也不只用于记忆闸门。公开的 reranker 实测是个有用的旁证。Adam Hevenor 在 Hev Mind 的 benchmark 里把 Jev 当 reranker，检索 BM25 top 30 后用每个文档一个 Noul 打分。三个 BEIR 数据集平均 nDCG@10：Jev batch 0.501，BM25 原序 0.404，Voyage rerank-3 0.504，Cohere rerank-v3.5 0.486，Mixedbread v3.1-listwise 0.511。价格 $0.54 每千次查询，p50 223ms，p95 约 1.4s。单文档调用把尾延迟压到 p95 256ms，代价是 30 倍请求。

这份数据的有趣处不在“打败谁”。Jev 每篇文档返回校准概率。在 SciFact 上，分数高于 0.9 的文档有 76% 被判相关，低于 0.1 的只有 0.5%。一个概率阈值就能同时做 rerank 和 prune。对 RAG 管线来说，这比一个需要按语料重新校准的 logit 更顺手。尾延迟是明确短板，追求 p95 的团队得选单文档 shape，或者别把它放在最外层的同步路径上。

社区项目也在试更轻的用法。Prateek 用 Jev 做了一个 Claude Code 插件，给 coding agent 的 prompt 打分，官方贴文说几乎不增加延迟。这个方向符合 Jev 的定位：不替 agent 思考大问题，只在已知答案空间里做快速判断。

也有网友拿 Jev 去跑寻路实验，比如 Shivam Chauhan 用 Manhattan 场景比较 Dijkstra 和 A*。这类演示更像 launch week 的边界测试，不是生产结论。它能说明 Jev 的接口灵活，也提醒别把决策模型当通用推理器。

Paulo Coutinho 写了葡语长文，把 Jev 的 API、三种问题类型、LangChain 集成和限制整理得更完整。对非英语读者有帮助。链接：https://paulox.dev/blog/2026/9/19/jev-a-ia-que-nao-conversa-system-one-model-da-typesafe-ai-guia-completo-com-exemplos-e-uso-pratico/

如果要落地，先别重写整个 agent。选一个低风险、答案空间明确、目前却要慢 LLM 或脆正则的判断。把 state 压到只含必要信息，写下每个选项的标准，收集歧义和对抗样本，用 shadow mode 跑在现有流程旁边。先自动化最安全的分支，保留人工或强模型处理不确定案例。固定模型版本，记录问题、阈值和证据。

有一个原则值得写进代码评审：能由确定性代码算对的事，不要问模型。日期排序、计数、金额计算、权限判断，交给代码。决策模型只处理普通 if 语句理解不了的含义。

回到旅行助手。用户说“这次要靠窗”，系统不该把它升级成永久偏好；用户说“我通常靠过道”，系统也不该把它只留在这次会话。真正需要判断的是这句话的来源、范围、时效和风险。Jev 这类模型提供概率，Graphiti 这类记忆层保存时序和证据，应用代码拥有最终分支。三者各做各的，记忆才可能从“越存越乱”变成“知道什么不该记”。

参考链接：

• Akshay 原帖：https://x.com/akshay_pachaar/status/2120205022046965836
• Jev 长文：https://x.com/i/article/2100940576741093376
• Graphiti：https://github.com/getzep/graphiti
• Hev reranker benchmark：https://hevmind.com/writing/jev-as-a-reranker/