Appearance
Team Memory 系统设计：压缩比记录更难
第二部 · Agent 实践 · 第13章
撰写日期：2026-07-03
结论
做组织记忆系统，第一直觉往往是"把所有东西记下来"。我在一个小团队里用 Claude + IM + GitHub 拼装并跑通了一个每日记忆管线之后，判断恰好相反：
组织记忆的核心能力不是记录，是压缩。系统的价值由它拒绝记录的东西决定。
全量记录不需要 AI——GitHub 和文档工具天然就是全量记录。AI 真正的增量，是从每天上百个事件里筛出最多几条真正改变团队未来的，其余全部丢弃。空输出是正常态，不是故障。
1. 三层决策模型：先分类，再决定记不记
不是所有"定了的事"都值得进入记忆。我用三层模型做第一道过滤：
| 层级 | 例子 | 处理 |
|---|---|---|
| Working Decision | 按钮改颜色、接口改字段、文案微调 | 不记。工具自带版本历史，记了只会稀释记忆 |
| Project Decision | 登录方案从短信改为邮箱 | 记。以后会被反复问起，影响后续方向 |
| Principle | 以后原型优先、不画高保真设计稿 | 重点记。影响半年以上的工作方式 |
第二道过滤按影响时长打标：
| 影响时长 | 处理 |
|---|---|
| < 1 天 | 忽略 |
| 1 周 | 弱信号，倾向不记 |
| 1 个月 | Decision，应该记 |
| 半年 | Principle，应该记 |
| 1 年以上 | Playbook，优先级最高 |
两道过滤都写死在筛选 Prompt 里（模板见 记忆筛选器 Prompt），并且明确要求：没有够格的就返回空数组，不为了有产出而降低标准。
2. 人工确认是校准期，不是永久守门
AI 筛出的候选记忆要不要直接入库？我的判断是：这个决策权最终应该交给 AI，但要用数据决定交出的时机，而不是拍脑袋。
实践方式是把人工确认设计成一个带埋点的校准回路：
| 环节 | 设计 |
|---|---|
| 候选呈现 | AI 每天最多提议 5 条，写入一张带勾选框的表格看板 |
| 默认值 | 默认不勾（opt-in）。宁可漏记，不让记忆爆炸 |
| 埋点 | 每条候选记 surfaced，每次人工勾选记 accepted |
| 毕业条件 | 样本 ≥ 10 且接受率 ≥ 90% 持续两周 |
| 毕业后 | AI 自主写入 + 人工事后抽审，确认动作从"守门"降级为"审计" |
接受率低说明 Prompt 或阈值需要收紧；接受率稳定高到一定程度，人工确认本身就成了纯摩擦。这个机制把"AI 什么时候可以自主决策"从立场之争变成了可观测指标。
3. 共享存储，个性化视图
记忆是每个人一份，还是团队一份？我的答案：
存储必须共享（一个团队只有一份事实），呈现可以个性化（每个人关心的切面不同）。
反过来做（每人一份存储）会立刻产生记忆分叉——同一个决策在不同人的记忆里版本不一致，比没有记忆更糟。
4. 删除语义：记忆不自动撤回
镜像层和记忆层的删除语义刻意不同：
| 层 | 语义 | 删除行为 |
|---|---|---|
| 知识库镜像 | 当前状态 | 源头删了镜像就删，git 历史是时间机器 |
| 团队记忆 | 已确认的决策 | 不自动撤回。推翻一个决策 = 一个新的显式决策 |
如果源文档被删就自动抹掉相关记忆，记忆层会退化成镜像层的影子，失去"这件事曾经定过、后来为什么变了"的叙事能力——而这恰恰是组织记忆最值钱的部分。
5. 双重压缩风险
如果数据源里包含 AI 生成的会议纪要，筛选器就是在压缩一份已经被压缩过的内容。上游摘要丢掉的信息，下游永远看不到。
对策不是拒绝用 AI 纪要（全文转写太长太噪），而是把这个风险显式登记，并约定验证动作：一旦出现"会上定了的事没进候选"，先查上游纪要里有没有那句话；查实是上游丢的，再切换到读转写原文。风险可以接受，但必须知情。
6. 推与拉：记忆系统的时间结构
跑通记忆管线后会自然长出第二个问题：除了"晚上该记住什么"，团队每天还需要"早上该注意什么"。两者是同一条管线的两个方向：
| 场景 | 方向 | 触发 | 内容 |
|---|---|---|---|
| 晚报 | 沉淀 | 定时（推） | 记忆筛选：今天什么值得记 |
| 早报 | 注意力路由 | 定时（推） | 近期事件 + 今日日程 + 待确认积压，按紧急度排序 |
| 即时简报 | 重新定向 | 按需（拉） | "我开了三小时会，错过了什么" |
两个容易做错的判断：
- 紧急事件的送达不需要自己做。 IM 的原生通知已经是实时的，重复造推送只会增加噪音。缺的是白天"重新定向"的入口，正解是提供拉取，而不是加更多定时推送。
- 定时窗口必须有状态。 "今天 0 点到运行时刻"这种固定窗口，会把运行时刻到午夜的事件永远漏掉；改成"上次成功运行到现在"的游标窗口（失败不推进游标），改时间、漏跑都不丢事件。时间点本身从此不重要。
7. 静默原则
没有内容的那天，一个字都不要发。
"今天没有需要记录的内容"这种空通知看似无害，实际上在持续训练用户忽略这个通道——等真有内容的那天，通知已经被肌肉记忆划掉了。正确的契约是：没收到推送 = 今天没事。打扰预算是记忆系统最稀缺的资源，Retention 死于低价值通知的速度比死于功能缺失快得多。
8. 最小闭环
整套系统没有写一行产品代码，全部用现成工具拼装：
数据源(代码托管/文档/日历/会议纪要)
→ 定时抓取（纯抓取，不做判断）
→ LLM 筛选（三层模型 + 时长阈值，最多 5 条，可为空）
→ 看板（勾选框，默认不勾）
→ 人工 30 秒确认
→ 归档进 team_memory.md（git 托管）
→ 接受率埋点这个形态足以验证核心假设——"组织记忆 = 记忆压缩器"——而验证成本几乎为零：镜像同步不消耗模型 token，每天至多两次 LLM 调用。先用拼装验证 Workflow，再决定要不要产品化，是我目前对这类系统最推荐的路径。
9. 生命周期补全：记忆系统的新陈代谢
最小闭环只覆盖了生命周期的前半（产生→存储）。记忆的完整生命周期是产生 → 确认 → 检索 → 更新/失效 → 遗忘，后半段每个环节都需要显式机制，否则记忆库会朝"只进不出的沼泽"退化：
| 环节 | 机制 | 关键判断 |
|---|---|---|
| 否决出口 | 看板加「不收录」勾选：不归档、直接清出、记 rejected 埋点 | 只有"收录"没有"拒绝"，积压会淹没确认动作；显式拒绝还让接受率的分母有了意义（分得清"拒绝了"和"还没看"） |
| 确认感知 | 轮询看板，勾选集合 + 全部字段内容指纹稳定一轮才执行归档，然后回执 | 勾选框本身就是人工确认，自动化的只是确认之后的搬运；内容指纹保证用户勾完还在改文字时不会归档半成品 |
| 候选可编辑 | 归档时实时读看板，进入记忆库的是人工润色后的版本 | 候选是草稿不是快照——AI 提初稿，人有编辑权，这比"接受/拒绝"二选一的确认粒度更符合真实审校行为 |
| 冲突检测 | 每晚筛选时把现有记忆库注入 Prompt：重复的不再输出；推翻已有记忆的标"修正："前缀并写明改了哪条 | 记忆库必须自我一致。"修正"类候选价值最高——它维护的正是第 4 节说的"这件事曾经定过、后来为什么变了"的叙事线 |
| 到期复审 | 每条记忆的"影响时长"到期后，晨报提醒一句"这条还成立吗"，每条最多每月一次 | "影响多久"从预估变成契约：半年期的原则半年后必须重新确认，否则时长标注只是装饰 |
| 主动入口 | 群聊里对 Bot 说"记一下"，由它提炼成候选四字段进看板 | 很多真决策发生在群聊而非文档里；只收显式交办的（不扫聊天记录，隐私是团队级授权），且只能投候选——人工闸门不变 |
| 遗忘 | 刻意保留为人工动作 | 删记忆比加记忆更该过人，自动遗忘会静默破坏叙事完整性 |
其中"确认感知"值得单说一句：它把确认成本从"勾完还要记得跑一条命令"降到"勾完就走"。人工闸门最大的敌人不是错误率，是摩擦——摩擦大了，用户会开始批量糊弄确认，闸门形同虚设。