记忆控制别默认塞给自回归 LLM：读 Jev-Mem 的 System One 记忆架构
长程 Agent 几乎都会撞上同一堵墙：对话、工具输出、环境观察不断堆积，固定上下文装不下；把窗口拉大，也不等于模型真能用到每一段历史。于是团队开始加「agentic memory」——把经验写出去、组织起来、需要时再捞回来。问题很快从「有没有记忆」变成：谁来决定写什么、连什么、怎么搜、何时停？
许多现成方案把这些控制默认交给自回归 LLM：每次记忆操作再生成一段自然语言，再解析、再分支。语义上灵活，但高频率决策被放进了昂贵的生成路径。UT Dallas 的 Jiang、Li、Li 在 arXiv:2609.23986 提出的 Jev-Mem，把这条路径拆开：用 System One 控制面管结构化、高频的记忆决策，用 多关系记忆面存可遍历的图结构，只在需要综合证据与生成答案时调用 System Two。[1]
站内已经写过 TypeSafe 商业产品 Jev 怎么接到 Claude Code、Jev 场景目录，以及 ContractNLI 上均分相近、判决可不同。那些文谈的是「决策层」本身。本篇换到 agentic memory 的控制面：同一套 System-One/Two 分工，落到写路径与读路径上会是什么样子；LoCoMo 上有哪些可核数字；和 扩张 Harness 而不是堆上下文 为什么是同一条长期主义线索。
先钉边界：Jev-Mem 是受 System-One/Two 启发的研究架构命名；论文把 TypeSafe 的 Jev 写成「轻量结构化决策」的一种具体实现（附录用 TypeSafeClient.system_one），不要据此把它读成 TypeSafe 官方同一产品线，除非厂商自己这么写。[1][2]
问题：把记忆控制放在 LLM 关键路径上的代价
论文对 agentic memory 的工作流写得很干净。Agent 维护演化中的记忆 (M_t)；查询 (q_t) 检索证据 (E_t = R(q_t, M_t))；语言模型在证据上推理得到响应；交互再写回 (M_{t+1} = U(M_t, q_t, o_t))。[1]
早期系统多半是「存下来 + 语义相似度检索」。后面的工作更主动：选择性保留、合并重复观察、分层存储、用图表达语义/时间/因果/实体关系。控制也跟着变重——持久 Agent 必须反复决定：存不存、更新不更新、连不连、检索到哪、何时停搜。现有做法常落在两端：固定启发式（快但不灵活），或把这些决策再丢回通用自回归 LLM（灵活但贵）。[1]
关键观察是：记忆控制里大量操作是语义的，但不是生成的——分类一条记忆、判断与既有节点的关系、给候选打分、决定是否继续扩展。输出往往是标签、概率、分数，而不是自由文本。把这类高频决策放进 token-by-token 生成，等于在记忆关键路径上反复付格式化、解析与长上下文开销；控制本身会变成时延与推理成本的主要来源。[1]
这和站内对 Jev 的定位一致：回路里很多调用其实只是为了拿一个结构化判断，却在付「生成整段助手消息」的账。[3] Jev-Mem 把同一直觉接到记忆生命周期两端：写路径与读路径都需要控制面，而不是只在最终回答时才「认真一点」。
把代价拆成三条，评审里更好对账：
- 时延叠乘。 写入要对邻居做关系判断，检索要多轮扩展；若每一跳都再开一轮自回归生成，墙钟会随图密度与会话长度一起爬。
- 错误形态变难查。 自由文本控制策略难做类型检查，也难做回归测试；标签翻了你看得见，一段「我认为应继续搜索」的散文翻了，监控往往只看到「一致性很高」。
- 上下文被控制话术挤占。 模型既要决定搜不搜，又要综合证据写答案时，提示里会同时塞进策略说明与证据正文——这正是 Growing Harness 批评的「控制占用本该留给任务证据的上下文」。[4]
因此问题不是「要不要用 LLM 碰记忆」，而是：哪些记忆决策已经稳定到可以离开生成回路。
三层分工：控制面、记忆面、推理面
Jev-Mem 的架构可以压成三层（论文 Figure 2）：
- System One 控制面：对有界输出空间做轻量结构化决策——记忆 typing、关系判断、查询路由、检索预算分配、图遍历、候选打分、证据充分性评估、自适应停止。
- 多关系记忆面：共享的结构化数据平面；规范观察节点之上，挂语义 / 时间 / 因果 / 实体等多关系视图。
- System Two 推理面：只在复杂综合与最终答案生成时上场；不参与常规的图路由、候选扩展与停止决策。[1]
论文强调：术语借自双过程认知，用作计算如何分配的类比，并不声称底层机制与人类认知一一对应。[1] 站内阅读时也建议保持这一距离——「System One」在这里首先是工程分层，不是心理学结论。
与 TypeSafe Jev 的关系可以写成一句精确话：Jev 提供「无自回归生成的类型化概率决策」这一实现路径；Jev-Mem 的贡献是把记忆控制本身提升为一级系统层，并在构建与检索上统一同一套控制抽象。[1][2] 换句话说：商业 Jev 是控制器的一种后端；Jev-Mem 是「记忆该如何被控制」的架构论文。作者单位是 UT Dallas 计算机系；代码仓库挂在论文给出的 GitHub 组织下。命名共享「Jev」字样，反映的是对 System-One 决策接口的借用与启发，不是厂商发布说明里的产品子系列。
附录把请求形状写得很具体：共享 state，一批 typed 问题（Noul 式真假命题或 Choice），返回落在 ([0,1]) 的模型报告值；作者明确写这些值不假定已校准，多个命题按独立命题评估而非互斥单选——例如一条观察可以同时被标成情景与语义。[1] 这对工程很重要：你拿到的是可分支的结构化信号，仍要用业务阈值与在线校准去接，而不是把 (0.73) 直接当成客观概率。
构建期：先 typing 与候选，再选择性建边
写路径不是「来一条就让 LLM 写一段记忆笔记」。对每条有效观察，Jev-Mem 先建一个规范记忆节点，保留原文、出处、时间戳、嵌入、实体与类型分数；不在摄入时做不可逆的「存或丢」。论文明确写：这样避免「当时看着不重要、以后查询才发现有用」的永久丢失；选择性放在结构构建与后续检索，而不是入口丢弃。[1]
控制器先预测四个可重叠的记忆特征：
[ t(v) = (t_{\mathrm{episodic}}, t_{\mathrm{semantic}}, t_{\mathrm{procedural}}, t_{\mathrm{preference}}) ]
分数是节点注解，不是互斥单类标签——同一观察可以既是情景又带偏好。[1]
接着是「候选发现」与「关系判断」分离。为避免控制器成本随记忆规模线性爆炸，先用向量相似、词法重叠、共享实体、时间邻近等确定性信号，把候选对限制在至多 (K_w) 个；System One 只在这批候选上估计语义相关、方向性因果、同 episode、以及必要时的实体等价。已有可靠结构化信息时尽量不走学习推断：时间戳顺序可直接建时间边，精确共享标识可直接建实体边。[1]
多关系是同一节点对上的独立视图，而不是「每条记忆只能进一张图」。同一对节点可以同时有语义边与时间边。周期性维护再在有界邻域上查冗余、矛盾、过时与可补链接；需要更高层文本抽象时，才把已批准的合并/提升显式升级到 System Two——生成是控制决策的可选后果，不是默认维护手段。[1]
读路径之前，先记住写路径的三条工程含义：
- 规范观察优先：别急着蒸馏成不可回溯摘要；
- 批量、有界的控制器调用：一次写入大致是一批 typing，外加（有候选时）一批关系请求，而不是对每个邻居各开一轮自由生成；
- 确定性信号优先于学习推断：能靠时间戳、精确 ID 建的边，就不要再问模型「它们是不是同一实体」。[1]
和 Mem0 / MemoryOS / A-MEM / MAGMA 等基线比，Jev-Mem 并不否认「主动组织记忆」这条路线——它否认的是：组织与检索过程中的每一个语义决策，都值得再走一遍通用生成。MAGMA 同样强调多关系图；Jev-Mem 的差异更在于控制面是否离开自回归热路径，以及检索是否带预算与停取闭环。[1]
检索期：路由、预算、遍历、打分、停取
检索被写成闭环，而不是固定 top-(k)：
[ \mathrm{route} \rightarrow \mathrm{retrieve} \rightarrow \mathrm{assess} \rightarrow \mathrm{expand} \rightarrow \mathrm{reassess} ]
查询到来时，控制器先预测各关系视图的相关性 (p_g(q))、多跳需求 (h(q))、以及时效重要性 (r(q))。各视图概率独立评估，因此一个问题可以同时激活多张图，而不是硬塞进单一检索意图。超过激活阈值的视图进入预算分配：总扩展预算 (B) 按预测权重分配，多跳预测再约束允许深度。[1]
锚点检索用向量与词法排序的 reciprocal-rank fusion（(\kappa=60)）找入口，再在图上扩展。每一轮会对当前证据集估计：充分性 (s_d)、继续检索的期望效用 (u_d)、缺失证据 (m_d)、未解决矛盾 (c_d)。满足充分且缺失/矛盾低于阈值则停；或继续效用过低也停——既防过早截断，也防无限扩进干扰项。[1]
候选打分把 System One 的四个维度（查询相关、关系有用、信息新颖、对当前证据的支持）与嵌入相似、边权、可选时效项组合；取 top-(W) 进入下一束。终止后，最高分的 (K) 条记忆交给 System Two 做最终综合。[1]
控制开销被显式封顶：写路径的批请求规模有上限；读路径每轮至多一次证据评估与一次批量候选打分；另有图扩展、边、节点、深度、控制器调用次数与墙钟等硬限制，防止控制过程本身无界膨胀。[1]
这一段和 Growing Harness 的对照几乎是同构的：反复出现的控制决策，不该默认占用自回归生成；差别在于 Growing Harness 把控制长成可执行代码，Jev-Mem 把控制交给类型化 System One 决策，并把记忆图本身做成被控制的对象。[4]
若用「谁在决定停搜」做探针，三种常见实现会立刻分叉：
- 固定 top-(k) / 固定深度：便宜，但不问「证据够不够」；
- 让 LLM 在链里自说自话决定是否再检索：灵活，但停取策略难测、难回归；
- System One 输出充分性与继续效用，外加硬预算：可测、可封顶，代价是你要维护阈值与特征。[1]
生产里往往是混合：规则与代码处理「绝不越权」的硬门禁，System One 处理「还要不要再扩一跳」的软判断，System Two 只看最终证据包。Jev-Mem 把后两段写进了同一篇记忆架构里。
LoCoMo 数字：有效性与效率，以及该怎么读
实验部分用 LLM-as-a-Judge（Zheng et al., 2023）量答案相对参考答案是否正确，并用 gpt-4o-mini 作评测侧模型；效率报告总记忆构建时间与平均每查询时延（检索 + 出答案）。[1] 主表是 LoCoMo（Maharana et al., 2024）上的长对话记忆问答。正文写「两个广泛使用的基准」，但主文 Table 1/2 明确汇报的是 LoCoMo；LongMemEval 等出现在相关工作/附录语境。下文只核 Table 中可对上的数字，不外推未列表结果。
有效性（Table 1，LLM-as-a-Judge，越高越好）
| Method | Multi-Hop | Temporal | Open-Domain | Single-Hop | Adversarial | Overall |
|---|---|---|---|---|---|---|
| Full Context | 0.468 | 0.562 | 0.486 | 0.630 | 0.205 | 0.481 |
| A-MEM | 0.495 | 0.474 | 0.385 | 0.653 | 0.616 | 0.580 |
| MemoryOS | 0.552 | 0.422 | 0.504 | 0.674 | 0.428 | 0.553 |
| Nemori | 0.569 | 0.649 | 0.485 | 0.764 | 0.325 | 0.590 |
| MAGMA | 0.528 | 0.650 | 0.517 | 0.776 | 0.742 | 0.700 |
| Jev-Mem | 0.623 | 0.637 | 0.618 | 0.802 | 0.962 | 0.777 |
相对最强基线 MAGMA 的 Overall 0.700，Jev-Mem 0.777 对应约 +11.0% 相对提升（((0.777-0.700)/0.700)）。Multi-Hop 0.625 vs 最强基线 0.569；Open-Domain 0.618 vs 0.517；Adversarial 0.962 vs 0.742——增益集中在「要跨记忆拼证据」或「要在干扰里挑真相关」的题型。[1]
读表时注意一处正文与表格的张力：作者写「六类里五类最好、时间推理追平最好结果」，但 Table 1 上 Temporal 是 MAGMA 0.650、Jev-Mem 0.637。以表为准时，时间类是例外，而不是「追平」。另有一处正文写 Single-Hop「0.797」，表中为 0.802——交稿以表为准。[1]
效率（Table 2）
| Method | Build Time (s) | Latency (s) |
|---|---|---|
| Full Context | N/A | 1.74 |
| A-MEM | 3636 | 2.26 |
| MemoryOS | 3276 | 32.68 |
| Nemori | 1044 | 2.59 |
| MAGMA | 1404 | 1.47 |
| Jev-Mem | 158 | 0.93 |
相对最快竞争记忆系统 Nemori 的 1044 s，158 s 约是 6.6× 加速（约 84.9% 构建时间下降）。查询侧 0.93 s，相对最快记忆基线 MAGMA 的 1.47 s 约 −36.7%；相对 Full Context 1.74 s 约 −46.6%。MemoryOS 单查询 32.68 s，说明「记忆管理本身」完全可以拖垮读路径。[1]
论文把效率归因写得很具体：构建期对有界候选做批量类型化决策，而不是反复调用通用 LLM 做自由文本记忆处理；检索期用 System One 做路由/评估/停取，并用显式预算约束图探索。[1] 有效性与效率同向改善，是这篇最值得引用的系统结论——前提是你接受 LoCoMo + LLM-as-a-Judge 这一评测代理。
基线阵容也值得对照着读：Full Context（无外部记忆、整段历史直接进模型）、A-MEM、MemoryOS、Nemori、MAGMA。作者尽量在可用处共用同一回答骨干模型，以避免「记忆系统赢了其实是更大生成模型赢了」。[1] Full Context 的 Overall 只有 0.481、Adversarial 仅 0.205，提醒一句：把历史全塞进窗口，既不等于用得上，也特别怕干扰项。Jev-Mem 在 Adversarial 上到 0.962，和「自适应选证据、显式停取」是同一故事的两面。
样本与评测局限（诚实边界）
- 评测代理：主指标是 LLM-as-a-Judge，不是人工全标；代理偏差与「裁判模型同族」风险需要单独看待。Judge 用 gpt-4o-mini，回答骨干也在同族生态里时，更要避免把分数读成跨厂商普遍真理。
- 基准范围：主数字来自 LoCoMo；正文虽提「两个基准」，主表并未给出第二套可核表——不要把 Overall 0.777 写成「所有长程记忆任务的新 SOTA」。
- 表文不一致：Temporal / Single-Hop 的正文措辞与 Table 1 不完全对齐；引用请锁定表格单元格，并在笔记里标明例外。
- 图维护成本：多关系图带来表达力，也带来候选发现、关系阈值、周期性维护与漂移治理——论文用有界候选与硬限制压控制开销，但生产里索引、回填与一致性成本仍要预算。
- 与商业 Jev 的耦合：附录展示的是 TypeSafe 风格的 typed Noul / Choice 接口；换掉 System One 后端，架构主张仍可讨论，但论文数字绑定其实验栈。[1]
- 无消融主表：公开主文以端到端对照为主；若你要论证「到底是多关系、还是 System One 停取、还是批处理」各自贡献多少，需要自行补实验或等后续材料，不能从 Overall 反推。
与站内 Jev / Harness / 记忆文对照
把 Jev-Mem 放回站内叙事，对照会更清楚：
| 站内文 | 它钉住的问题 | 和 Jev-Mem 的交点 |
|---|---|---|
| Jev × Claude Code | Jev 不是聊天模型；接口是 state + typed questions | 记忆控制正是「不该生成助手消息」的高频决策 |
| Jev 场景目录 | 路由、门禁、上下文管理等判断场景 | Jev-Mem 把「上下文管理」扩成完整记忆生命周期 |
| ContractNLI 判决对照 | 均分相近可以掩盖翻盘；盯 persistent correctness | 记忆选型同样不该只看一个 Overall；要拆题型与稳定性 |
| Growing Harness | 扩张 harness，而不是堆上下文 | 两边都在把反复控制移出自回归热路径；一个沉代码，一个沉 System One |
| ECC Memory Vault | 可检查的 Markdown vault，而不是不可审计黏糊文本 | 与「规范观察优先、生成是可选升级」同向：可审计存储面 |
| Copilot 记忆与 agentic 编程栈 | 产品侧补齐长期项目上下文与流程参与 | 产品记忆层仍要回答「控制面在谁手里」 |
一句话串起来：决策层（Jev）解决「判断怎么便宜又结构化」；harness 层（Growing Harness / ECC）解决「哪些控制该沉进代码与配置」；Jev-Mem 解决「记忆子系统里的高频控制，为何也不该默认塞回 LLM 生成」。 三条线谈的是同一类失败模式——把本可结构化的控制，反复付成开放生成。
落地清单：何时拆出记忆控制面
下面清单可直接贴进设计评审，不要求你采用论文里的 Jev 后端。
- 先数调用形状。 若每轮写入/检索都在让 LLM「写一段记忆策略 / 解释为何停搜」，把这些输出压成标签、概率、分数——控制面候选已出现。
- 写路径：规范观察 vs 蒸馏摘要。 默认保留可回溯原文与出处；摘要/合并走显式升级，并留下审计痕迹（对照 ECC vault 思路）。
- 关系与检索视图分开。 语义相似不够时，显式建模时间/因果/实体；查询侧允许多视图同时激活，并给总预算，而不是单通道 top-(k)。
- 检索必须有停取条件。 至少同时建模「证据够不够」与「再搜是否还值得」；再加节点/边/深度/时延硬上限。
- 控制器调用要批量、有界。 写入 typing/关系、读取路由/打分，按批提交；禁止对每个邻居各开一轮自由生成。
- 评测拆开有效性与效率。 至少同时报：答案质量（最好含题型拆分）、构建墙钟、查询时延；不要用「记忆更聪明了」掩盖读路径变慢。
- 把 LLM-as-a-Judge 当代理，不当终审。 上线前用业务金标准或人工抽检校准；ContractNLI 文强调的 persistent correctness，同样适用于记忆问答。
- 产品命名与架构命名分清。 用 System-One 启发的记忆控制，不等于采购某一家决策模型；后端可换，分层主张可独立验收。
风险清单（同样要写进评审）：
- 评测代理风险：裁判模型偏好某种回答风格时，Overall 会被抬高或压低。
- 图谱维护成本：关系阈值、冗余清理、矛盾处理、跨会话实体对齐都有运维面。
- 过早蒸馏：摄入时「智能丢弃」看起来省存储，却可能永久删掉未来查询需要的证据——论文选择保留规范观察，是有意的保守。[1]
- 控制面过拟合基准：LoCoMo 的多跳/对抗题型增益，不自动迁移到你的工单或代码库记忆。
- 阈值漂移：激活阈值、充分性阈值、继续效用阈值会随数据分布移动；没有在线监控时，System One「很快」会变成「很快地错停」。
- 权限与隐私：多关系图更容易把「谁对谁说了什么」连成可遍历结构；控制面加速检索的同时，也放大了越权读取的爆破半径——编码 Agent 场景尤其要和 vault / ACL 一起设计（对照 ECC 的可检查存储叙事）。[5]
最小可行切片（不必一次上齐四张图）：先做「写入 typing + 冗余/矛盾标记 + 检索停取三件套」，用同一套 typed 决策接口；跑两周看构建时延、查询时延、人工抽检正确率。若停取与 typing 已经省下明显的生成调用，再考虑因果/实体视图与周期性维护。顺序反了，很容易先背上图运维，却还没证明控制面拆分有收益。
结语
Jev-Mem 最有用的不是又一个「记忆分数更高」的标题，而是把问题写成系统层：记忆控制是高频、有界输出的决策，还是偶发的开放生成？ 若是前者，就不该默认走自回归热路径。LoCoMo 上 Overall 0.777（相对最强基线约 +11.0%）、构建 158 s（约 6.6×）、查询 0.93 s（约 −36.7%）说明：在这篇论文的设定里，分开控制与推理可以同时改善效果与效率——前提是你接受其评测代理，并以 Table 为准读细项。[1]
对站内读者，这篇是 Jev 决策线向记忆子系统的自然延伸，也是 Growing Harness「控制沉出模型」在另一条实现路径上的回声。下一步若要落地，不必先复刻整张多关系图；先把「写入分类 / 检索停取 / 预算分配」从自由生成里拆出来，通常就已经能看见时延与可审计性的变化。
若把站内几条线排成路线图，可以是：用 场景目录 找出「只需要判断」的调用；用 Claude Code 接法 把判断接到 harness 中间件；用 ContractNLI 读法 设计稳定性面板；再用本文把同一控制面推进记忆子系统；最后用 Growing Harness 问一句——哪些记忆控制已经稳到可以继续沉成代码，而不是永远停在「每次再问一次 System One」。长期主义内容要的就是这种可串联的机制链，而不是单篇热榜分数。
代码仓库见论文给出的 github.com/libingzheren/Jev-Mem；预印本 PDF：arXiv:2609.23986。[1]
参考
[1] Dongming Jiang, Yi Li, Bingzhe Li. Jev-Mem: System-One-Controlled Agentic Memory for Efficient AI Agents. arXiv:2609.23986, 2026. https://arxiv.org/abs/2609.23986
[2] TypeSafe AI. TypeSafe AI（论文参考文献条目；Jev / System One 接口以厂商文档为准）. https://typesafe.ai/
[3] 站内：Jev × Claude Code、Jev 使用场景
[4] 站内：扩张 Harness，而不是堆上下文（源论文 arXiv:2609.26760）
[5] 站内：ECC：可核验的 Harness 优化（Memory Vault 一笔）