架构选型与决策
根据任务时长和跨会话需求，用决策树把任务特征映射到合适的记忆栈架构
核心要点：
- 选型起手用两根轴：任务时长 × 跨会话需求
- 决策树把任务特征映射到四类记忆栈
- 四个 archetype 在四维坐标上的落点各自不同
- 单一方案与 hybrid 的临界条件可量化
- 五类反模式直接对应已知失败
本文是 02-记忆分类体系 四维坐标和 07-生产记忆系统对标 五系统横评的合成应用层，把前 7 篇知识合成一套工程选型流程，不再重复机制细节。
选型从哪两个维度起步？
核心问题：面对一个新 agent 项目，该先问什么问题来缩小记忆栈选项？
两个起步问题决定了大部分选型：任务时长是否会超过单次上下文窗口、状态是否需要跨会话存活。其余维度 （规模 / 审计 / 自主度） 是这两条之后的二级筛选。
| 起步问题 | 含义 | 不满足时可选 | 满足时进入 |
|---|---|---|---|
| 任务时长 > 单窗口？ | 单次任务 token 量是否会撑爆上下文 | 纯工作记忆即可 | compaction 或 context-reset |
| 状态需跨会话？ | 下次会话需不需要继承本次结果 | 关会话即遗忘 | 持久层 （文件 / 向量 / hybrid） |
@tbl-agent-memory-selection-start 记忆栈选型起步两维：任务超窗与跨会话需求的判断标准及对应方向
这两根轴构成 2 × 2 的起手矩阵，落到四类基础场景，再叠规模与审计需求做细分。下文按这条骨架展开决策树。
决策树长什么样？
核心问题：给定一组任务特征，怎么一步步落到一个具体记忆栈？
按"超窗 → 跨会话 → 规模 → 审计需求"四级提问筛选，终点是 4 类基础栈中的一种。
| 任务超窗？ | 跨会话？ | 持久记忆量级 | 审计 / 合规需求 | 推荐栈 |
|---|---|---|---|---|
| 否 | 否 | — | — | 纯工作记忆 （单窗口 + 良好 prompt 组织） |
| 是 | 否 | — | — | compaction-only (五层惰性降级即可，03) |
| 是 | 是 | < 10³ 条 | 强 （人审 / git） | 文件型 + handoff (04) |
| 是 | 是 | 10³ – 10⁶ 条 | 中 （能查、能改） | 文件型索引 + 选择性向量 （CLAUDE.md 路由 + 局部向量库） |
| 是 | 是 | > 10⁶ 条 | 弱-中 | 生产中间件 (Mem0 / Letta, 07) |
| 是 | 是 | 任意 | 极强 （推理过程可追溯） | Hindsight 类 (证据-推断分离，07) |
@tbl-agent-memory-decision-tree 记忆栈选型决策树：超窗、跨会话、持久量级、审计需求四级筛选与推荐方案对照
四级筛选下来基本不会落到"全选"。临界判断：
- 10³ 条：文件型记忆人审与 git diff 仍可控的上限——单文件几百行、目录几十文件；超出靠目录扫描会丢相关条目。
- 10⁶ 条：文件 + 选择性向量不再足以保证检索召回率，必须上多信号检索 (语义 + BM25 + 实体，05) 加专用图/向量库。
- 审计强度：git 可 diff 但不能查"为什么"；需要推理来源时只有 Hindsight 类的证据-推断分离机制能给出，文件 + git 不够。
这四级提问本身不需要量化精确度，起手作用是把候选栈从"什么都能选"压缩到"两三个里选"。
典型 archetype 在四维上落在哪？
核心问题：coding agent / 客服 / 研究助理 / 长任务规划四类典型项目，在 02 的四维坐标上各占什么位置？
四个 archetype 在 （表示，时间，内容，控制） 四维上的落点差异显著，选型差异主要由此驱动。下表用 02 的四维做基准坐标横评。
| Archetype | 表示 | 时间 | 内容 | 控制 | 推荐栈 |
|---|---|---|---|---|---|
| Coding agent | token （文件） | 长期项目级 + 短期会话 | 程序性 （规范） + 情节 （会话） | 启发式 （CLAUDE.md 分层加载） | 文件型 + compaction |
| 客服 / 个人助理 | token + 向量 | 长期用户级 | 语义 （用户事实） + 情节 （历史） | 提示自控 （LLM 判 ADD/UPDATE） | Mem0 类中间件 |
| 研究助理 （长任务规划） | token + 向量 | 长期跨任务 | 语义 （世界知识） + 程序性 （方法论） | 提示自控 + 自演化 | A-Mem 或 Letta |
| 高合规决策 agent | token + 显式分层 | 长期带审计 | 语义 + 情节 + 推断分离 | 学习控制 + 强治理 | Hindsight + 写入门控 |
@tbl-agent-memory-archetype-dimensions 四类典型 agent 在表示、时间、内容、控制四维上的落点及推荐记忆栈
每个 archetype 的关键差异源：
- Coding agent：项目规范是程序性记忆且需要 git 版本同步，文件型记忆天然契合；情节记忆 （这次会话改了什么） 走 compaction 即可。
- 客服 / 助理：用户偏好是稳定语义事实，写入决策频繁触发，用 Mem0 的 ADD/UPDATE/DELETE/NOOP 判定 (见 06) 比文件型人写更合适。
- 研究助理：跨任务的知识增量积累需要"新记忆触发旧记忆演化"，这是 A-Mem 的独特特性，其他系统做不到。
- 高合规：推理可追溯是硬需求，必须分离证据与推断，且写入门控不可缺 (08)。
可借鉴的判断：archetype 决定四维坐标，四维坐标决定生产系统选择。跳过 archetype 直接看 benchmark 选系统，容易落到"benchmark 第一名但不适合本场景"的陷阱。
什么时候单一方案，什么时候 hybrid?
核心问题：上面的推荐栈都是单一方案，实际项目要不要混用文件型 + 向量库 + compaction?
当任意单一方案在某一维度触及上限时引入 hybrid，但默认从单一方案起步。过早 hybrid 是反模式 （见下节）。
引入 hybrid 的三种典型临界：
- 规模临界：文件型记忆条目超过 10³，目录扫描召回率下降，引入局部向量库做语义召回，文件仍做主索引。
- 延迟临界：全上下文方案 p95 延迟超出预算 （通常 10s 是用户感知阈值），引入 Mem0 类中间件压 token，用 3-6 个准确率点换 12× 延迟下降 (07 LoCoMo 数据)。
- 合规临界：业务进入受监管行业 （金融、医疗），需要写入审计链，在原方案基础上叠 Hindsight 的证据-推断分离层或 Mem0 的 changelog 机制。
hybrid 的组合应有主辅关系，不能两套同地位：文件型做主索引时，向量库只覆盖文件外的长尾条目；文件型做长尾时，向量库做核心索引。两套都做主索引会触发"同一事实两处存"的去重难题，直接踩中 06 "update 非 append" 缺口。
反模式：哪些组合是已知失败？
核心问题：选型过程中，哪些常见组合会直接踩坑？
五类反模式分别违反前 8 篇的一条核心结论。识别它们比记住正向推荐更省事。
| 反模式 | 违反的结论 | 失败表现 |
|---|---|---|
| 跨会话需求，只用 compaction 不持久化 | 03 compaction 有损，丢细粒度数字 | 压缩后丢失关键数值，下次会话从零开始 |
| 文件型记忆条目无限增长不分层 | 04 MEMORY.md 索引 + 按需加载 | 单文件膨胀到上千行，每次会话注入超过 25KB |
| 向量库 + 关键词，二选一不融合 | 05 RRF 按排名融合 | 长尾稀有词召回崩，语义近义召回有噪声 |
| 写入用 append-only 不判 UPDATE/DELETE | 06 update 非 append | 矛盾记忆并存，时序推理崩 (OpenAI Memory 21.71 vs Mem0 55.51) |
| 生产系统无写入门控 | 08 写入门控验证 + 跨基底删除验证 | 一次环境注入持续生效，eTAMP 8× 放大效应 |
@tbl-agent-memory-anti-patterns 记忆系统五类反模式：各对应违反的核心结论与典型失败表现
典型踩坑链：项目初期只用 compaction，跨会话后发现状态丢，临时加文件型记忆但不分层，单文件膨胀到几千行，改成全量塞向量库不加多信号融合，长尾词召回崩，加规则却没写入门控，最终被恶意网页内容污染——每一步都是合理决策的局部反应，整体却是反模式叠加。从 archetype 起手能避开这条链，因为每一步选择都有上一级约束。
选型流程总结成几步？
核心问题：把上面所有内容压成一个可执行流程，该按什么顺序问什么？
五步法：archetype 定位 → 决策树筛栈 → 量级核对 → 反模式自检 → 演进路径预留。
- Archetype 定位：在上文四类典型项目里找最接近的，拿到四维坐标的起手点。不在四类里 → 用 02 的四维独立选点。
- 决策树筛栈：按超窗 / 跨会话 / 规模 / 审计四级提问，落到 1-2 个候选栈。
- 量级核对：检查持久记忆条目预期增长 （现在 + 一年后），对照 10³ / 10⁶ 两条临界，决定单一方案还是 hybrid。
- 反模式自检：对当前选型逐条对照五类反模式，任一命中即修正。
- 演进路径预留：文件型 → +向量库 → 生产中间件是常见演进路径，起手方案应允许后续平滑切换 （例如统一抽象 add/search 接口），不要写死特定库。
这套流程的核心是从任务特征出发，不从生产系统的 benchmark 第一名出发。Benchmark 给出的是平均性能，选型要的是"在我的场景下表现"——而这取决于 archetype 与四维坐标，不取决于在 LongMemEval 上得几分。
Takeaway
| 知识点 | 核心结论 |
|---|---|
| 起步两维 | 任务时长 × 跨会话需求决定大部分选型 |
| 决策树 | 超窗 → 跨会话 → 规模 → 审计四级筛，落到 4 类基础栈 |
| 量级临界 | 文件型 < 10³, hybrid 10³–10⁶，生产中间件 > 10⁶ |
| Archetype | Coding / 客服 / 研究助理 / 高合规四类落点差异显著 |
| Hybrid 起点 | 单一方案触上限再引入，主辅关系明确，不两套同地位 |
| 五类反模式 | 各对应 03/04/05/06/08 一条核心结论 |
| 选型流程 | archetype → 决策树 → 量级 → 反模式 → 演进路径 |
| 选型起点 | 从任务特征出发，不从 benchmark 排名出发 |
参考资料
- 02-记忆分类体系 — 四维坐标定义，本文 archetype 落点表的基准
- 03-compaction-与上下文压缩 — compaction 有损特性是反模式 1 的依据
- 04-文件型外置记忆 — 文件型分层是反模式 2 的依据
- 05-向量检索记忆 — RRF 融合是反模式 3 的依据
- 06-记忆操作生命周期 — ADD/UPDATE/DELETE/NOOP 是反模式 4 的依据
- 07-生产记忆系统对标 — 五系统横评，决策树终点候选
- 08-记忆安全 — 写入门控是反模式 5 的依据
延伸阅读
- 01-总览 — 知识域整体索引与名词定义