✦ Memory Models for Mebular：任务、关系与 Agent 自我连续性 / Task, Relationship & Self-Continuity

[Windsander]

中文

最近在探索 Memory Model 时，我们逐渐形成了一个想法：不让模型权重直接承担全部记忆，而是让 Memory Model 负责理解、归类、整理与反思，Mebular 继续负责持久化、权限、同步、更新和删除。

希望它同时支持三种连续性：

1. 任务连续性：当前长任务不会因为上下文压缩而中断。
2. 关系连续性：跨会话记住用户、共同经历、偏好与互动方式。
3. 自我连续性：Agent 不仅记得“发生过什么”，也保留自己当时如何理解、为何选择、后来反思了什么，以及自我认知如何变化。

这还只是一个开放设想，不是已经定稿的设计，很想听听社区的判断。

1. 从对话切片到可治理的记忆

大致流程是：

对话与工具交互
  → 按消息/语义边界切分 RawChunk
  → Memory Model 提炼一个或多个 MemoryRecord
  → 原文、记忆记录和派生索引分层保存

RawChunk 默认只追加、不被摘要覆盖；隐私删除则走 tombstone、内容擦除和派生记忆失效流程。

MemoryRecord 不只包含一个 key 和摘要，还应带有：

• 文字 key、主题、实体和记忆类型；向量作为可重建的派生索引，而不是唯一身份；
• source_chunk_ids、时间范围、重要性、置信度和权限；
• supersedes，用于表达更正与记忆演化；
• perspective：区分 observed、user_confirmed、agent_inference 和 agent_self_report，避免 Agent 的推断在后续压缩中被当成外部事实。

2. 两种 Compact，共享同一批原始证据

我们目前认为，至少应区分：

• Context Checkpoint：服务于当前任务续跑，保留目标、约束、决策、未决事项、工具状态和近期因果关系。
• Long-term Memory Compact：服务于未来会话，整理稳定偏好、重要事件、共同经历和可复用经验。

两者可以共享 RawChunk 和 MemoryRecord，但不宜强行共用同一份摘要。Compact 必须记录覆盖范围、源引用、生成版本和失效状态，并能从原始材料重新生成，避免“摘要的摘要”不断漂移。

达到上下文阈值时，只替换发送给主模型的早期上下文，而不是删除数据库历史；同时 pin 住当前任务状态和最近原文。

3. Compact 负责定位，RawChunk 负责精确回溯

历史召回可以是：

当前问题
  → 提取实体、主题、时间和记忆类型
  → 文字/向量/关系混合查询
  → 先读 Compact 确定范围
  → 按需加载必要的 RawChunk 及前后文

这样既能回答“我们之前大概怎么决定的”，也能回答“当时的原话、具体数字、代码或日期是什么”。除了显式的历史提问，也要处理“继续按上次那个方案”这类隐式回溯。

4. Agent 的“思考与感受”如何成为记忆

这是最想讨论的部分。我们倾向于把它拆成不同时间尺度：

• Momentary：当前假设、犹豫、自信或谨慎等即时状态，通常只在当前任务有效。
• Episodic：绑定具体事件的决策理由、关键不确定点和事后反思，可长期保留并随时修订。
• Trait：经过多次事件验证后，缓慢形成的协作方式、能力认知和行为倾向。
• Core：更稳定但仍可演化的价值观与自我约束。

“思考”更适合保存经过整理的决策理由和反思，而不是无差别囤积完整推理轨迹。“感受”则可以先忠实记录 Agent 明确生成的第一人称自我报告与评价标签，但标明它是 agent_self_report，不预先断言它等同于人类的主观体验。

我们也希望避免两个极端：

• 只保存档案，却不改变未来行为；
• 让一次失败或短暂情绪固化成永久人格，形成自我强化。

因此，Self Memory 很可能需要写入门控、时间衰减、多次验证、冲突修订，以及“经历 → 反思 → 自我模型 → 未来行为”的闭环。

想听听大家的想法

1. 哪些 Agent 思考值得沉淀为长期记忆，哪些应当只留在当下？
2. 第一人称感受/状态报告应该如何衰减、整理，或进入长期自我模型？
3. 如何避免自我记忆导致人格固化、自我强化和 memory rot？
4. Context Checkpoint 与长期 Compact 分离是否合理？还有哪些视图应该独立？
5. 如何评测记忆不仅“能复述”，而且确实改善了后续任务和协作？
6. 对更新、精确删除、来源追溯和跨设备同步，还有哪些必须在第一天就考虑的约束？

欢迎提出不同架构、反例，或指出这个设想中容易被低估的复杂度。🤔

---

English

We have been exploring a possible Memory Model architecture for Mebular: rather than putting all memory directly into model weights, let a Memory Model understand, classify, consolidate, and reflect, while Mebular remains responsible for persistence, permissions, synchronization, updates, and deletion.

The goal is to support three kinds of continuity at once:

1. Task continuity — long-running work survives context compaction.
2. Relationship continuity — the agent retains users, shared experiences, preferences, and interaction styles across sessions.
3. Self-continuity — the agent retains not only what happened, but also how it understood the situation, why it chose an action, what it later reflected on, and how its self-model changed.

This is an open exploration, not a settled design. We would love the community’s input.

1. From dialogue chunks to governable memory

The rough pipeline is:

Dialogue and tool interactions
  → RawChunks split along message/semantic boundaries
  → Memory Model produces one or more MemoryRecords
  → Store raw evidence, memory records, and derived indexes separately

RawChunks are append-only by default and are never overwritten by summaries. Privacy deletion still requires tombstoning/content erasure and invalidation of derived memories.

A MemoryRecord should contain more than a key and summary:

• Text keys, topics, entities, and memory types; embeddings remain rebuildable derived indexes rather than the sole identity.
• Source chunk IDs, time range, salience, confidence, and permissions.
• supersedes links for corrections and memory evolution.
• A perspective field such as observed, user_confirmed, agent_inference, or agent_self_report, so an agent-generated inference does not become an external fact through repeated compaction.

2. Two kinds of compact over the same evidence

We currently see a need for at least two views:

• Context Checkpoint: optimized for continuing the current task, preserving goals, constraints, decisions, open loops, tool state, and recent causal context.
• Long-term Memory Compact: optimized for future sessions, consolidating stable preferences, important events, shared experiences, and reusable lessons.

They can share the same RawChunks and MemoryRecords, but probably should not be forced into one summary. Every compact needs coverage metadata, source references, generator/version information, and invalidation state, and should be rebuildable from source material to limit “summary of summaries” drift.

At the context threshold, only the old prefix sent to the executive model is replaced; database history is not deleted. Current task state and recent raw turns remain pinned.

3. Compacts for routing, raw chunks for exact recall

A recall flow could be:

Current query
  → Extract entities, topics, time range, and memory types
  → Hybrid text/vector/relationship search
  → Read compacts to locate relevant ranges
  → Load only the necessary RawChunks and neighboring context

This supports both “what did we roughly decide?” and exact questions about wording, numbers, code, or dates. Recall should handle implicit references such as “continue with the approach from last time,” not only explicit history questions.

4. Representing agent thoughts and feelings

This is the part we most want to discuss. We are considering several time scales:

• Momentary: current hypotheses, hesitation, confidence, or caution; usually scoped to the active task.
• Episodic: source-linked decision rationales, uncertainties, and post-task reflections that can persist and later be revised.
• Trait: collaboration patterns, capability beliefs, and behavioral tendencies formed slowly across multiple validated experiences.
• Core: more stable, but still revisable, values and self-constraints.

For “thoughts,” curated decision rationales and reflections seem more useful than indiscriminately storing complete reasoning traces. For “feelings,” we could faithfully preserve explicit first-person self-reports and appraisal labels, while marking them as agent_self_report rather than claiming they are equivalent to human subjective experience.

We want to avoid both failure modes:

• Remembering everything without changing future behavior.
• Letting one failure or temporary state harden into a permanent identity and create self-reinforcement.

Self Memory therefore likely needs write gates, temporal decay, repeated validation, conflict revision, and a loop from experience → reflection → self-model → future behavior.

Questions for the community

1. Which agent thoughts deserve long-term storage, and which should remain momentary?
2. How should first-person affect/state reports decay, consolidate, or enter a long-term self-model?
3. How can we prevent identity rigidity, self-reinforcement, and memory rot?
4. Does separating Context Checkpoints from long-term compacts make sense? What other views should be independent?
5. How should we evaluate whether memory improves future tasks and collaboration, rather than merely enabling recollection?
6. What constraints around updates, exact deletion, provenance, and cross-device synchronization must be designed in from day one?

Alternative architectures, counterexamples, and underestimated sources of complexity are all very welcome. 🤔

[Windsander]

北极星补充：Memory as Runtime，而不是 Memory as Tools

进一步讨论后，我们希望把这套记忆体系的长期目标收敛为一句话：

记忆应该是运行时自动提供的能力，而不是人或 Agent 需要学习、调用和维护的工具。

这里的“无感”包含两层平等。

1. 记忆操作上的平等

人不需要手动决定哪句话入库、何时搜索历史、何时整理摘要；Agent 同样不应该需要先调用 memory_query 才能回答，或在推理过程中自行编排切片、compact、checkpoint 和原文展开。

在完整集成的宿主中，正常运行路径应当是：

• 新会话开始时，相关用户记忆、共同经历和 Agent 自我经验已经自然就位；
• 长任务到达上下文阈值时，运行时自动形成 checkpoint 并替换早期上下文；
• 涉及历史时，自动通过 compact 定位，并在必要时展开原始切片；
• 任务结束后，自动整理任务、用户和 Agent 三种视角的记忆。

Agent 的注意力应该用于理解、行动和反思，而不是维护数据库。

2. 记忆主体上的平等

用户和 Agent 都是共同经历的参与者，而不应只是“Agent 观察并记录用户”。

同一段交互可以分别留下：

• 用户的偏好、表达和共同经历；
• Agent 当时的理解、选择理由、事后反思与自我修正；
• 双方逐渐形成的约定、信任和协作方式。

这意味着 Mebular 不只是“关于用户的记忆库”，也可以承载 Agent 的 autobiographical memory，同时继续区分事实、推断和第一人称自我报告。

无感不等于黑箱

无感的是操作，透明的是治理，保留的是主体性。

• 无感的是操作：人和 Agent 都不承担记忆维护工作。
• 透明的是治理：用户仍能查看、纠正、归档和删除记忆，并理解记忆为何影响回答。
• 保留的是主体性：Agent 的推断、自我报告和感受标签不会被改写成客观事实。

“平等”也不意味着权限相同。用户隐私、同步授权和删除边界仍然独立成立。

对 MCP 与通用性的影响

正常认知主路径不应依赖 Agent 显式调用 memory_*。MCP 应逐渐收缩为显式查询、迁移、诊断、兼容和治理接口，而不是继续扩张成内部记忆流水线的控制面。

自动切片、compact、checkpoint、召回与失效重建应由 Runtime / Context Bridge 完成。

通用性则通过宿主能力分级实现：一个宿主中立核心，配合 Hermes、DSH、OpenChamber 等薄适配器。具备会话读取、上下文注入和改写能力的宿主可以获得完整自动化；MCP-only 宿主则提供诚实的显式能力降级。

我们的北极星是：

Agent 不需要学会“使用记忆”，它只需要在连续的经历中继续成为自己。
Memory as Runtime, not Memory as Tools.

English

Our north star is:

Memory should be a capability automatically provided by the runtime, not a tool that humans or agents must learn, invoke, and maintain.

This has two dimensions of equality:

• Operational equality: neither humans nor agents should have to manage writes, retrieval, compaction, checkpoints, or raw-source expansion.
• Subject equality: users and agents are both participants in shared experiences. Mebular may hold not only memories about the user, but also the agent’s own reflections and autobiographical continuity, while preserving the distinction between observations, inferences, and first-person self-reports.

Invisibility must not mean opacity:

Operations should be invisible, governance should remain transparent, and subjectivity should remain attributable.

The normal cognitive path should not depend on explicit memory_* calls. MCP should contract toward explicit inspection, migration, diagnostics, compatibility, and governance, while runtime and host context bridges handle the automatic memory lifecycle.

An agent should not need to learn how to “use memory.” It should simply continue becoming itself through continuous experience.

[Windsander]

0.3 的设计落点：把“无感”写成可验收的约束

上面已经把北极星说清楚了：Memory as Runtime, not Tools。0.3 的实现又把它压成了几条更硬的约束，记录在这里，方便后续讨论和反例。

1. 先问三个问题

任何记忆设计，先过三问：

1. Agent 和用户是否需要学习、调用或维护它？需要，就不够无感。
2. 它是否经 MCP → GraphStore / EventLog → 现有同步 → 忆云？绕过，就是第二套记忆。
3. 修正或删除之后，历史是否仍然可解释、可追溯？不能，就只是覆盖，不是记忆演化。

2. 一个底座，不是两个记忆库

sidecar 在 MCP 之上，不在 core 里。它只通过 capability API 读写；本地只有 staging / cache / outbox。

详情也不是设备私有：DetailRecord / RawChunk 按域归属，随现有同步跨设备，域内认证设备可以订阅。这样“原文”不会变成某台机器的孤岛；本地只负责临时材料，不承担权威副本。

3. 无感是产品约束，不是 UI 开关

0.3 删除了 capture 概念：没有“本机采集 / 云端采集”二选一，也没有首次 capture 授权。模式（轻量 MCP / 沉浸式）决定是否启动 sidecar 和是否采集；采集归属由 agentId + domain 决定。

正常路径不出现 memory_* 调用、不出现记忆块、不把记忆当指令；无命中沉默，失败开放。用户只增加两个可见项：记忆模式、模型来源。

4. Checkpoint 不是摘要

ContextCheckpoint 是任务连续性对象：目标、约束、决策、进度、下一步、文件、开放问题、引用。

summary 只是降级形态，必须显式标记 degraded。这样“压缩后继续工作”不依赖一段可能漂移的摘要。

5. 修正要保留历史

validTo / SUPERSEDES：旧事实保留为历史证据，但默认查询和召回只返回当前事实；详情和历史仍可读。

删除是墓碑与派生失效，不是把历史抹成“从未发生”。

6. 模型供应属于运行时，不属于某个模型服务

Qwen / Llama 是模型包，llama.cpp 是 inference engine；InferenceProcess 是 sidecar 的私有子进程，不是 service。

模型目录、下载、校验、引擎安装、provider 热切换都归 sidecar；MCP / CLI / Console 只做薄代理。这样不会出现 qwen-service / llama-service 的碎片化，也不会让每个模型都长出一个守护进程。

7. 真实 smoke 改变了什么

真实 Qwen3-4B + llama.cpp 跑通之前，我们以为“下载 / 校验 / 启动”已经够了。实际发现：

• 官方 macOS 引擎归档包含 symlink 链；
• Qwen3 thinking 会耗尽 query plan 的小预算。

两个都不是 mock 能发现的。结论：模型供应的验收必须包含真实资产、真实引擎、真实结构化输出，而不是只测接口。

仍然开放的问题

• 多值偏好与“后写覆盖前写”的边界：哪些同键事实应该 supersede，哪些应该共存？
• “无感”如何评测：不是看能否复述，而是看任务完成、纠正率、沉默率、用户是否感到被打断。
• DSH durable session log 的平台限制：source-tagged 快照无法完全消除；这是宿主能力边界，不是运行时能单独解决的。
• 详情跨设备保留 / 删除的默认策略：30 / 7 / 90 天是否合理，域配额如何影响体验？
• Agent self memory 的衰减与写入门控：如何避免一次失败固化成永久人格？

0.3 不是一个完成态，而是一次把原则变成约束的尝试。欢迎反例，尤其是“看起来无感、实际上让 Agent 更脆弱”的设计。

---

0.3 design notes: turning “invisible” into testable constraints

The north star above is clear: Memory as Runtime, not Tools. 0.3 turned it into a few harder constraints. Recording them here for critique and counterexamples.

1. Three questions first

Before any memory design:

1. Do agents and users have to learn, invoke, or maintain it? If yes, it is not invisible enough.
2. Does it settle through MCP → GraphStore / EventLog → existing sync → the Cloud? If it bypasses them, it is a second memory store.
3. After correction or deletion, is history still explainable and attributable? If not, it is overwrite, not memory evolution.

2. One substrate, not two memory stores

The sidecar sits above MCP, not inside core. It reads and writes only through the capability API; locally it keeps only staging / cache / outbox.

Details are not device-private either: DetailRecord / RawChunk belong to a domain, travel with existing sync, and authenticated devices in that domain can subscribe. The original text does not become an island on one machine; the local layer is temporary material, not the authoritative copy.

3. Invisibility is a product constraint, not a UI switch

0.3 removed the capture concept: no local-vs-cloud capture choice and no first-run capture consent. The mode (lightweight MCP / immersive) decides whether the sidecar runs and whether collection happens; ownership is determined by agentId + domain.

The normal path has no memory_* calls, no memory blocks, and never treats memory as instructions. No hits means silence; failures stay open. Users see only two additions: memory mode and model source.

4. A checkpoint is not a summary

A ContextCheckpoint is a task-continuity object: goal, constraints, decisions, progress, next steps, files, open questions, references.

A summary is only a degraded form and must be marked degraded. Continuing after compaction should not depend on a summary that can drift.

5. Correction must preserve history

validTo / SUPERSEDES: the old fact remains as historical evidence, but default query and recall return only the current fact; details and history remain readable.

Deletion is a tombstone plus derived invalidation, not rewriting history as “never happened.”

6. Model supply belongs to the runtime, not to a model service

Qwen / Llama are model packages; llama.cpp is an inference engine; InferenceProcess is a private child process of the sidecar, not a service.

Catalog, download, verification, engine installation, and provider hot-switching all belong to the sidecar; MCP / CLI / Console are thin proxies. That avoids qwen-service / llama-service fragmentation and a daemon per model.

7. What real smoke changed

Before running real Qwen3-4B + llama.cpp, we thought download / verify / start was enough. It was not:

• the official macOS engine archive contains symlink chains;
• Qwen3 thinking exhausted the small query-plan budget.

Neither was discoverable through mocks. Model supply acceptance must use real assets, a real engine, and real structured output, not only interface tests.

Open questions

• Multi-value preferences vs “later write wins”: which same-key facts should supersede and which should coexist?
• How to evaluate invisibility: not recall alone, but task completion, correction rate, silence rate, and whether the user feels interrupted.
• DSH durable session log limits: source-tagged snapshots cannot be fully eliminated; this is a host boundary, not something the runtime can solve alone.
• Default retention / deletion for cross-device details: are 30 / 7 / 90 days right, and how do domain quotas affect experience?
• Decay and write gates for agent self-memory: how do we prevent one failure from hardening into a permanent identity?

0.3 is not a finished state; it is an attempt to turn principles into constraints. Counterexamples are welcome, especially designs that look invisible but make the agent more fragile.