在 Jetson Orin 上离线跑通的 Agent 记忆系统——提取 → 消解 → 存储 → 检索 → 更新 → 删除 → 版本回溯，C++ 实现、自写分词器与 ONNX INT8 推理，全程不依赖云端。下面可切换两段真实转录回放：记忆系统本体的 CLI 生命周期，与它驱动出的座舱助手应用。
两段都是在 Orin 上录制、全程离线的真实转录回放（非模拟、非指标陈列）：记忆系统 · 生命周期看引擎本体怎么转，座舱助手 · 应用看它装上车能干什么。点按钮切换。
以下每一步都是 memolink CLI 在 Orin 上的真实输出（2026-10-22 录制）。点「下一步」逐条回放，右侧记忆库随每步实时变化。完整生命周期：提取 → 写入 → 检索 → 矛盾更新（SUPERSEDE）→ 版本回溯 → 显式更新 → 删除 → 统计。
每一步都是 cockpit_assistant 在 Orin 上的真实输出（2026-10-23 录制）。左侧是驾驶员与助手的对话，右侧是这一轮的记忆操作（检索到什么、治理拦截了什么、写入了什么），下方是记忆库全库状态——每轮后 memory 表里哪些记忆新增（绿）、哪些失效（红删除线）、哪些对当前驾驶员不可见（🔒），数据来自 --dump 的真实全库快照。点「下一轮」逐轮回放。完整真实转录见 cockpit_demo_transcript.md。
测试数据集：自建中文车载记忆基准——v1 集（24 条记忆、18 条查询，跨类型话题互异）与 v2 集（16 条记忆，含 episodic「近期 vs 久远」近重复对）；System-2 消解五分类用 30 个构造场景（Q2），受约束提取编造率（Q4）与英文模型 config-only swap（Q5）用 LongMemEval，多驾驶员治理（Q7）用仓库内 test_memory_governance 测试集；末尾的检索规模实验另用独立 Python/faiss 原型构造 1,000 / 10,000 / 100,000 条记忆三档（来源见下方标注）。
上面的演示是「能看见功能在跑」；这里是「跑得多好」的量化证据。统计卡数字由仓库内程序在 Orin 上实跑生成、可复现（bench/results/*.json）；末尾另附一组独立原型的检索/embedding 取舍实测作为设计佐证（来源已标注）。
Q1–Q7 闸门全部在 Orin 真机跑通：版本化 CRUD（Q1，41/41 单测）、五操作消解（Q2，五分类 70% / 可记四类 84% / 目标定位 14/14）、类型特化检索（Q3，v2 基准 hit@1 +31.2pp、episodic 3/8→8/8）、受约束提取（Q4，编造率 3.7%）、LongMemEval 英文模型 config-only swap（Q5，dim 384、5/5）、多驾驶员治理（Q7，GovernanceFilter owner/scope/authority 过滤 + 强度衰减淘汰 + strict fail-closed，test_memory_governance 全过）。详见 docs/memory_v2_design.md。
设计取舍的实测佐证 · 为什么用精确检索、INT8 embedding
下面两组数字来自一个独立的 Python/faiss 原型（edge-agent-memory，完整基准与复现见其仓库），非 memolink 自身 C++/SQLite 实现的测量——绝对值不直接迁移，但结论与 memolink 的设计选择一致，作为「为什么这么选」的实测依据。
| 检索方式（512 维 · recall@5） | N=1,000 | N=10,000 | N=100,000 |
|---|---|---|---|
| 精确 faiss flat · 延迟 / recall | 0.127ms / 1.0 | 0.787ms / 1.0 | 6.63ms / 1.0 |
| HNSW ef=64 · 延迟 / recall | 0.074ms / 0.998 | 0.171ms / 1.0 | 0.139ms / 1.0 |
| HNSW 建索引耗时 | 0.25s | 3.86s | 36.1s |
结论：agent 记忆的现实量级是 1e3~1e4 且增量更新——精确检索亚毫秒、recall 恒 1.0、建索引近乎免费、追加 O(1)；HNSW 在 10 万条上建索引要 36s，换来的查询加速却发生在本就不是瓶颈的环节（生成 ~920ms vs 检索 0.16ms）。故 memolink 刻意用精确检索（SQLite 暴力余弦），ANN 在此量级是过度设计。embedding 侧：INT8 相对 FP32 余弦 0.99+、单线程比 FP32 双线程还快、模型 23.9MB vs 94.8MB——佐证 memolink 的 ONNX INT8 embedding 选择。
图 1 · 记忆生命周期全链路（全程本地离线）：提取 → 消解 → 版本化存储 → 类型化检索 → 治理过滤 → 座舱应用
记忆生命周期全程在本地完成：提取 → 消解 → 存储 → 检索 → 更新 → 删除 → 版本回溯。座舱域天然把这些机制变成「看得见、且非它不可」的功能——而不是一个套了记忆库的聊天机器人。细节见 docs/memory_v2_design.md（含诚实边界与复现）。
各机制输入输出：提取——对话轮（user/assistant 消息对 + 会话上下文）→ 候选事实集（受约束 JSON，每条含 text/type/owner/scope）；消解——候选事实 + 库内同类型记忆 → 五分类决策（CREATE/UPDATE/REINFORCE/SUPERSEDE/NOOP）+ target_id；检索——自然语言查询 → Top-K 记忆（意图路由 + 类型加权 + 时间衰减）；治理——驾驶员身份 + 记忆三标签（owner/scope/authority）→ 可见性过滤（strict fail-closed）。
| 机制 | 做法 |
|---|---|
| 双过程消解 | System-1 确定性规则（空库/无同类型→CREATE、逐字重复→REINFORCE）处理约 32%；相似度落入模糊地带的交给 System-2 本地 4B LLM 五分类（CREATE/UPDATE/REINFORCE/SUPERSEDE/NOOP） |
| 类型特化检索 | 查询意图路由 + 同类型加权（×1.6）+ 时间衰减——v2 基准 hit@1 +31.2pp（episodic 3/8→8/8）。「上次充电在哪」路由到 episodic、「座椅加热怎么开」路由到 procedural，不是全类型一锅搜 |
| 非破坏性版本化 | SUPERSEDE 把旧值标记失效但保留，history 可回溯完整演变（Graphiti 式边失效的端侧落地）。如搬家后地址从西湖区改滨江区：旧记忆失效保留、新记忆入库建双向链 |
| 多驾驶员治理 | GovernanceFilter 按 owner+scope+authority 强制端侧隔离：换驾驶员后，前任的私人记忆（家庭住址、孩子学校）被拦截不可见，共享记忆（车辆电池/续航）仍可见；strict fail-closed |
| 端侧实现 | C++，自写 WordPiece 分词器 + ONNX INT8 embedding（与 HF 逐 token 对拍 25/25），本地 4B LLM 做消解与提取，全程离线 |