用分层上下文减少 Agent 无关记忆干扰

AI Agent 的记忆越来越多，回答却越来越容易串台：写客户邮件时带出服务器配置，排查服务时提到上个月的报价。原文认为，问题不只是模型不会判断相关性，而是所有知识都被放进了同一个入口，随时可能进入对话。

作者给出的办法是：把知识分成五层，分别通过常驻、任务触发、明确引用和语义召回进入上下文，再用独立 profile 隔开工作、个人和 homelab 等领域。这套设计值得借鉴，但它能保证多大范围的隔离，需要拆开看。

记忆该放哪里，要先问它什么时候需要出现

原文把知识层级定义为三个维度的组合：知识如何进入模型上下文、允许占多大空间、预计能保持正确多久。实际组织时，作者选择「进入上下文的触发条件」作为主轴。

原因很直接：内容是否相关，需要模型判断；某个文件是否自动加载、某个记忆库是否参与检索，则可以通过配置控制。

五层分别承担不同职责：

层级	放什么	如何进入上下文
L0 Identity	身份、语气、边界、记忆政策	每轮始终注入
L1 Resident memory	通用用户信息、知识入口	每轮始终注入
L2 Procedural	操作流程与注意事项	当前任务匹配 skill 时加载
L3 Reference	配置表、清单、合同、运行手册	任务明确读取文件
L4 Retrieved memory	历史决策、沟通与尝试记录	根据语义相似度召回

L0 通常是 SOUL.md 或系统提示词。它定义 Agent 如何行事，尤其要提前规定记忆使用政策。一旦开始往里面塞服务器名、客户名和报价，这些内容就获得了进入每轮对话的资格。

L1 常见载体是 MEMORY.md、USER.md。作者提出两个要求：只留通用信息和指针，并设置硬性容量限制。原文引用的 Hermes 实现中，MEMORY.md 上限为 2,200 字符，USER.md 为 1,375 字符，两者在会话开始时以冻结块注入。这是具体实现的例子，不是所有 Agent 都应照抄的标准。

下面这段配置式文本说明，常驻记忆如何指向领域资料：

Infra facts: wiki/infra/ + memory bank 'homelab'.
Clients and contracts: wiki/business/clients/ + bank 'business'.

要看的是每行冒号后面的目录和 bank 名称：它们提供查找入口，没有把基础设施配置或客户条款直接带进来。不过，目录名本身如果包含敏感信息，也不能自动视为安全。

常驻上下文越小，越容易检查每条内容是否真有必要常驻。

流程、准确数据和历史经历，不能用同一种读取方式

L2 是 skills，保存「怎么做」：步骤、常见问题，以及去哪里查资料。处理客户邮件的 skill 可以指向合同目录和 business bank；homelab 管理 skill 则指向设备清单和 homelab bank。

这层连接了任务识别与数据访问。任务先触发流程，流程再引导 Agent 读取需要的数据。作者反对把客户名单、IP 表直接贴进 skill，因为这样一来，每次触发流程都会加载整份数据。

L3 保存需要准确查找的参考资料，例如端口表、服务清单和合同。问「host Y 上某服务使用哪个端口」，需要命中唯一正确的记录，语义相近的三个段落并不能代替答案。

因此，作者主张把这类资料放进可明确读取的文件、wiki 或记录系统。若由 LLM 维护 wiki，可以在资料进入时先整理成结构化、带关联的页面，也就是原文提到的 LLM Wiki 做法。

L4 则适合历史经历：客户曾确认什么、某个方案何时试过、为什么没有采用。此时用户通常记不住文件名，语义召回更有用。

风险也出在「相似」上。客户账单问题与账单服务器部署位置可能在 embedding 空间里很接近。如果客户记录和基础设施资料混在同一个 bank 中，检索就可能跨领域带回内容。标签和过滤条件可以收窄范围，但作者更倾向于每个领域独立建库。

读写也要分开控制。一个 bank 可以参与 recall，却不接受 retention，也就是允许检索、禁止写入。每个 bank 还应声明自己的 retention mission，告诉负责提取记忆的 LLM 应保存什么、排除什么。但这仍是一条模型执行的提取规则，不能当作存储权限。

历史记录最终也可能变成准确事实。例如「客户已经按这些条款签约」，应进入可编辑、可核查的 L3，L4 保留沟通过程即可。否则，旧经历可能长期以当前事实的面貌出现。

profile 能阻止跨库召回，却隔不开共享磁盘

作者把系统分为五个领域：通用、homelab、个人、工作和教育。每个领域使用独立 profile，各自拥有身份文件、常驻记忆、skills、定时任务及记忆库配置。

例如运行 agent -p homelab，启动的是配置限定在 homelab 领域的 Agent。工作 bank 根本不在它的召回池里，因此正常召回路径不会拿到客户合同。

通用 profile 比较特殊：它可以只读召回多个领域，但不向这些领域写入。这样既能回答跨领域问题，也能避免闲聊被自动沉淀进长期记忆。前提是后端支持分别配置读库与写库；不支持时，作者建议使用独立 general bank，接受较弱的跨领域视野。

定时任务和委派子任务也继承所属 profile 的范围。例如 homelab profile 的夜间巡检，只使用它所配置的记忆来源。

但原文明确承认：这些 profile 共享文件系统，终端仍可能读取其他 profile 的文件。

profile 隔离的是上下文来源，不是操作系统访问权限。

所以，凭据仍应进入环境文件或 secret store，wiki 应放在公开仓库之外，并在合适时使用目录权限。只要其他读取路径仍然开放，就不能把「不参与召回」扩大成「绝不可能泄露」。

迁移顺序也有讲究：先拆分召回池，再给 L1 设置预算，把领域事实迁入各自 wiki 目录，最后让 skills 指向已经存在的资料。原文认为建库可以先于内容迁移，但如果旧混合库仍参与召回，风险并不会因新库建好就消失。关键是实际切换读取范围。

我的判断

我赞同这套方案对「准确记录」和「历史经历」的区分。配置表需要确定性查找，过去的讨论可以接受语义检索。两者混用，容易把检索误差带进原本要求精确的任务。

相较于反复提醒模型「不要提无关内容」，缩小默认加载范围和召回池，也更容易检查和维护。不过，原文没有提供串台率、任务成功率、延迟或 token 消耗的对照数据。它主要是一套架构主张和操作经验，不能据此断言五层方案一定优于所有单库设计。

作者对配置隔离的部分表述也偏强。bank 不在召回配置中，可以保证该召回入口不会查询它；共享文件、已有会话内容和其他工具路径，仍可能把信息带进来。结尾关于泄漏「不再可能」的判断，需要限定在受控召回路径内理解。

profile 也有维护成本。原文提醒，5 个尚可管理，15 个就像维护一支系统队伍。对领域边界清楚的个人助手，这个成本可能值得；对共享代码和知识的研发团队，每个项目都建 profile，可能只是增加重复配置。项目差异优先用 L3 目录组织，确实需要不同记忆范围时再拆 profile，更符合作者的原则。

另外，L3 的准确性不会由架构自动保证。单文件单写入方、变更日志和定期审查仍然必要。Agent 完全按流程读取了一张过期表，也会得到错误答案。

能拿来做什么

• 检查日常 AI 编程使用的常驻说明，把只服务于单个项目的接口表、部署地址和配置迁入项目文档，只保留入口；设置容量上限，接近 90% 时审查是否混入了领域事实。
• 整理前端发布或 Node 服务排障 skill，让它描述步骤并指向配置清单。会变动的端口、环境对应关系和服务清单留在参考文件中，避免维护两份事实来源。
• 把「试过什么、为什么放弃」留在历史记忆中，把已经确认的配置与决策结果写入可核查的记录系统；召回历史时明确提醒 Agent，这些内容未必代表当前状态。
• 若同一 Agent 同时处理客户工作和个人 homelab，按领域拆分 bank 与 profile，并检查读取、写入和定时任务配置。确有跨领域问答需求时，再配置通用 profile 的只读召回范围。