设计原则与哲学
羽忆的很多实现选择，如果只看局部会显得“有点克制”。例如为什么不默认自动写入、为什么要把记忆和历史拆层、为什么召回不是简单搜索。这些决策都来自一组明确的设计原则。
原则 1：用户数据主权优先
记忆属于用户，不属于平台。系统必须允许用户：
- 自行部署与迁移
- 自行决定什么进入记忆
- 自行删除、归档、失效已有内容
- 在任何时候关闭自动写入
这条原则的直接后果是：所有看起来“更智能”的自动能力，都不能以牺牲用户感知和控制权为代价。
原则 2：模型无关、宿主无关
羽忆不应绑定在某一家模型供应商，也不应绑定在某一个 Agent 宿主。
这意味着：
- 服务端对象模型和 API 契约要独立存在
- Adapter 只做意图映射与格式转换，不承载核心业务判断
- 向量检索、LLM Judge 都必须是可替换、可关闭、可降级的增强能力
如果某个宿主下线，或者某个模型供应商不可用，核心记忆系统仍然应该可以独立运行。
原则 3：记忆与历史必须分层
这是整套设计里最关键的一条原则。系统里的信息至少分成两类：
| 层 | 特征 | 典型内容 |
|---|---|---|
| Stable Memory | 高稳定性、跨会话可复用 | 用户偏好、项目约定、技术决策、长期事实 |
| History Recall | 过程性、阶段性、可降级 | 任务摘要、决策轨迹、近期进展、问题上下文 |
如果不做这层拆分，系统最终只会走向两个极端：
- 只存“精华”，导致任务过程上下文大量丢失
- 什么都存，导致召回被噪声淹没
分层的本质不是增加概念，而是把两类生命周期完全不同的信息分开管理。
原则 4：显式控制优先于自动智能
自动写入、自动召回、自动合并冲突，这些能力在产品体验上都很诱人，但如果用户不知道系统做了什么，信任会先被破坏。
因此第一阶段坚持以下约束：
- 以显式操作为主
- 自动能力默认为关闭或受限
- 自动写入产生的结果必须可见、可审查、可撤销
- 高风险操作不能绕过人工确认
这不是保守，而是为了先建立“这套系统是可控的”这一前提。
原则 5：召回要面向消费设计
搜索的目标是“找到尽可能多的相关结果”，召回的目标是“给当前任务生成可以直接注入模型上下文的最佳材料”。两者不能混为一谈。
因此 Recall Orchestrator 的设计重点不是查全，而是：
- 排序
- 去重
- 冲突标注
- Token 预算控制
- 新鲜度提示
只有把返回结果限制在模型真正能消费的范围里，召回才有价值。
原则 6：先闭环，再复杂
第一阶段不是做“功能最丰富的记忆系统”，而是做“最小但完整的记忆闭环”。
第一阶段必须跑通的，是：
- 可部署
- 可写入
- 可召回
- 可删除
- 可跨 Agent 共享
而不是一上来就追求完整自动化、复杂权限体系或高级知识治理。
原则之间如何仲裁
当多个目标发生冲突时，仲裁顺序可以简单理解为：
- 用户数据主权
- 显式控制
- 分层设计
- 模型与宿主无关
- 面向消费的召回
- 闭环优先
例如，某个自动能力即使能明显提升体验，只要会让用户无法感知“系统替我写了什么”，就应该被推迟、降级或改造成显式确认流程。