Remove repeats
Deduplication
识别语义重复或结构化重复，避免同一信息被多次写入。
Strengths
降低长期层噪声，提高检索效率。
Risks
过度去重会误删有差异但相似的有效信息。
Best Fit
任何持续运行的长期记忆系统。
Plain Explanation
污染治理可以理解成代理记忆系统的“清洁和秩序”。如果长期没人整理，记忆里会越来越多重复内容、旧信息、相互矛盾的事实，最后代理虽然记得很多，却越来越不靠谱。
When To Use
- 当系统会长期在线运行，或者记忆会持续累积时，这一层迟早会成为核心问题。
- 当同一用户会跨任务、多轮、多天使用代理时，污染和过期问题会更快暴露。
- 当系统开始支持多用户、多项目或多 agent 协作时，作用域治理几乎是必需项。
Design Questions
- 系统如何处理重复、冲突、过期与错误记忆？
- 不同用户、任务、项目、agent 之间是否有清晰 scope 边界？
- 系统是否知道每条记忆来自哪里、何时产生、何时应该失效？
Evaluation Metrics
长期记忆里有多少内容其实是重复的
新旧冲突出现时，系统能不能稳定处理
明明已经过期的记忆，还会不会经常被命中
跨用户、跨任务串味的情况多不多
Mainstream Mechanisms
先抓住这一页真正主流的机制主线
这一组不是“所有相关概念”，而是这个维度最核心、最值得先理解的主线。带下划线的机制可以直接点开，会弹出一个更细的解释窗。
Pipeline
把这些机制放回一条工作流里看
如果只看孤立卡片，机制之间的关系会很模糊。把它们放回 pipeline 中，就能看清每一步在系统里承担什么角色，以及问题通常出在什么位置。
1
Detect
识别重复、冲突、过期与跨作用域污染信号。
2
Isolate
在 user / session / task / project 等边界内隔离记忆。
3
Resolve
对重复和冲突内容执行去重、覆盖或版本化。
4
Age
通过 TTL 和 decay 降低陈旧记忆的影响力。
5
Audit
保留来源、时间戳和版本信息，支持回溯与纠错。
Mechanisms
扩展机制与细部取舍
Resolve contradictions
Conflict Resolution
当新旧记忆冲突时，决定覆盖、版本化、并存还是人工确认。
Soft forgetting
Decay / TTL
通过时间衰减、访问频次、TTL 等方式降低陈旧记忆影响力。
Boundary control
Scope Isolation
按 user / session / task / project / org 分层隔离记忆边界。
Examples
把这一章放进真实场景里看
旧偏好长期霸榜
用户半年前喜欢某种写作风格，但现在已经明确改口。如果系统没有 decay 或版本更新，旧偏好仍然可能在检索里排第一。
Takeaway: 污染治理不是只处理错误，也要处理“曾经正确、现在过期”的记忆。
跨项目串味
用户上午在 A 项目里讨论数据库迁移，下午在 B 项目里问接口问题。如果作用域没隔离，系统可能把 A 项目的迁移状态错带进 B 项目。
Takeaway: 很多看似“模型答非所问”的问题，实际上是治理层的边界没守住。
Architecture Notes
从系统设计角度看这个维度
这一部分补充的是更偏 memory system design 的视角：不只看概念本身，而是看这些机制在真实系统里应该放在哪一层、如何被组织、如何被观测。
污染治理要贯穿 write-time、store-time、retrieve-time 三个阶段，不能等到查询时报错了再补洞。
至少要保留 provenance、timestamp、scope、version 这些元数据，不然很多冲突根本没法判断。
如果系统会长期在线，decay 和 TTL 应该进日常调度逻辑，而不是靠人手动清理。
Misconceptions
这一章最容易被误解的地方
误解一：污染治理只是做一下去重。
误解二：只要检索相关性高，旧信息就不会造成伤害。
误解三：治理属于后期运维问题，不需要在架构阶段考虑。
Deep Dive
展开理解这个维度
什么叫 memory pollution
污染不是某一个单独的 bug，而是一堆小问题慢慢积累出来的偏差。刚开始看不明显，时间一长就会越来越难收拾。
- 重复写入会让某些信息在检索中被不合理放大。
- 旧事实未失效，会让系统误以为世界状态仍未变化。
- 跨项目串味，则会把别的任务的状态带进当前决策。
治理为什么不能被当成附加项
没有治理的 memory，前期看起来往往很聪明，因为它确实“记住了很多”。但时间一长，系统会因为记得太杂、太旧、太乱而越来越不可信。
- 系统越运行越久，污染累积效应越明显。
- 治理机制通常不会直接提升单轮效果，但能决定半年后系统是否还能用。
- 因此 memory hygiene 应该与 write policy 同级设计，而不是事后补救。
一个实用治理组合
真实系统很少只靠一种治理机制。更常见的做法，是在写入、存储、检索三个环节都加一点保护。
- 写入前做基础去重和作用域判断。
- 写入后保留来源、时间戳和版本信息。
- 检索时再叠加 decay、scope filtering 和 source preference。
为什么治理现在越来越强调“时间维度”
很多 memory 问题不是一轮就爆炸，而是积累几十轮、几百轮之后才慢慢显形。也正因为这样，治理不能只看单次检索，还要看系统会不会随着时间越跑越偏。
- 有些风险不是 prompt injection 当场触发，而是被长期写入后慢慢影响后续任务。
- 因此 evaluation 不应只看单回合安全，还要看记忆积累后的行为变化。
- 通俗地说，不只是看今天档案室乱不乱，还要看它会不会一个月后彻底失控。
用更通俗的话说，污染治理像什么
如果写入策略是决定“什么进档案室”，那污染治理就是决定“档案室如何一直保持有序”。否则文件会越来越多，但真正想找的东西反而越来越难找。
- Dedup 像清理重复复印件。
- Conflict resolution 像给新旧版本做取舍或留档。
- TTL 和 decay 像告诉系统：有些东西不是永远都该排在前面。
Failure Modes
常见失败模式
没有来源字段，导致冲突处理完全失去依据
没有作用域隔离，多个任务或用户的状态互相串味
没有衰减机制，陈旧但曾频繁出现的信息长期霸占召回
Previous Chapter
4. Write Policy
何时写入长期记忆
看什么信息被允许沉淀为长期记忆
Next Chapter
6. Memory Objectives
记忆服务于什么
看整套记忆最终为哪类能力服务