把 Agent 的记忆从 25KB 压到 4KB：一套「脑机分离」的记忆架构
把 Agent 的记忆从 25KB 压到 4KB：一套「脑机分离」的记忆架构
多 Agent 系统跑起来之后，最扎心的问题往往不是”不会干活”，而是越用越乱、越用越健忘、越用越容易串台。这篇拆一套很实在的解法：不是加功能，而是给 AI 的记忆立一套”秩序”。读完你会问自己三个问题——你的 Agent，大脑和办公桌分开了吗？它每次启动带进上下文的是精华还是垃圾？你的系统有没有一条不能突破的 Token 红线？
一、病根：不是不会，是”什么都记得一点，什么都记不准”
把配置文件、记忆文档、草稿、产出物全丢在同一个目录层，会发生什么？
Agent 每次启动都像一个刚睡醒的人，先在满屋狼藉里翻半天，然后把不该带进上下文的东西也一起带进来了。临时文件越堆越多、记忆越来越脏、Token 一路飙升。更糟的是它会误读旧草稿、串错项目，然后一本正经地胡说八道——这就是”记忆污染”。
很多人第一反应是套 PARA（Projects / Areas / Resources / Archive）。这套笔记法对人很好用，但对多 Agent 系统不够。原因很关键：
PARA 解决的是”逻辑分类”，不是”物理隔离”。
AI 的大脑和办公桌一旦放在一起，系统迟早会乱。人类可以容忍桌面乱一点，机器不行——桌面一乱，记忆就脏；记忆一脏，执行就偏。
二、核心原则：大脑住楼上，办公桌在楼下，互不串门
整套架构最核心的一句话就是这个。拆成四层：
第一层 · 身份与认知层（根目录）= AI 的大脑。 必须常驻上下文：身份定义、人格语气、记忆索引、领域知识。为什么必须在根目录？因为很多 Agent 框架的底层寻址就是写死按这个结构找的——身份文件每次对话自动注入，这是工程约束，不是设计偏好。我们能做的不是改规则，而是顺着规则把体积和边界控制好。
第二层 · 能力层 = AI 的手脚。 skills/（可复用能力说明）+ tools/（本地脚本）。这也是 Token 节约的第一道防线：能用脚本解决的，就别动用大模型。
第三层 · 劳作层（workspace/）= AI 的办公桌。 所有产出、下载、临时文件都进这里。关键约束只有一条：所有 write 操作必须显式加 workspace/ 前缀——因为 Agent 默认执行目录就是根目录，不加前缀，文件就直接污染大脑层。
第四层 · 公共制度层（shared/）= 共享规则，不共享大脑。 多个 Agent 共用一套价值观/协议/看板，但每个 Agent 的记忆仍然独立、互不串门。共享制度，不共享脑内噪音。
三、三级缓存：把操作系统的内存管理，套到记忆上
这是整套方案里最漂亮的一手——把 AI 记忆设计成一个 OS 式三级缓存：
| 层级 | 位置 | 内容 | 加载策略 |
|---|---|---|---|
| L0（一级缓存） | 根目录 / MEMORY.md | 记忆索引、当前任务、关键决策、紧急待办 | 常驻上下文 |
| L1（二级缓存） | memory/milestones/ | 阶段性总结、经验教训、关键节点 | 按需加载 |
| L2（三级缓存） | memory/journal/ | 完整日志、日常流水 | 冷存储 |
- L0 硬约束 ≤ 4KB（约 800~1000 tokens）：这是 Agent 每次启动都带在身上的”本能记忆”。
- L1 平时不进上下文，需要时才 read 或语义检索拉出来。
- L2 默认永不进上下文，只有明确”复盘某段时间”时才选择性读取。
一句话记住它：把常用、关键、短小的东西放近；把完整、详细、低频的东西放远。
配套的心智模型叫「按需加载」：上下文窗口 = 物理内存（贵且有限），记忆子文件 = 磁盘（便宜且大），按需加载 = 只在需要时把页面换进内存。收益是实打实的——单轮对话 Token 从 5000+ 降到 1500 左右，降幅接近 70%，MEMORY.md 从 25KB 压到 4KB 以内。
四、Token 红线：能用脚本就别用大模型
这条我特别认同，因为它是”成本意识的工程化”，而不是抠门。原则一句话：能用本地工具解决的，就不要用大模型做。 具体四招：
- 脚本优先：数据清洗、格式转换、批量重命名，交给 Python / Shell，一次编写长期复用，几乎不消耗 Token。
- 红线值：
MEMORY.md一旦超限就触发巡检和瘦身。 - 心跳巡检：定期扫描记忆文件体积，异常膨胀就报警。
- Agent 自检：大规模读取前先预估 Token 成本，快超阈值就主动提示”是否继续读取”。
省 Token 不是目的，目的是让算力花在真正需要智能的地方——创意、判断、决策，而不是死记硬背和格式整理。
五、三道防线：防止 Agent 自己把规矩搞坏
架构搭好，还得防它越界：
- 防线一 · 巡检脚本：挂在心跳里，定期扫”根目录有没有冒出非标准文件、
MEMORY.md有没有超限、workspace 结构对不对”，发现就报警自查。 - 防线二 · Git 钩子：
pre-commit做最后物理拦截——根目录出现临时文件、记忆超限、写路径缺workspace/前缀，直接拒绝提交。它拦的是那句最危险的话：“我就先临时放一下”。很多系统就死在这个”临时一下”上。 - 防线三 · 混沌测试：主动给 Agent 下模糊指令（“帮我查一下那个文档”），看它会不会直接去根目录乱翻，还是先追问”哪个文档？在哪个项目？“。这本质是 SRE 那套：不假设系统永远正确，主动设计错误场景看它会不会失控。
还有一条治本的：别指望培训，直接用底层注入机制。 把关键规则写进每轮自动注入的身份文件里，等于每次启动都”重载规则”——培训会忘，硬编码不会。
六、我自己的几点判断（哪些值得抄，哪些别照搬）
我照着自己搭多 Agent 记忆系统的经验，补几条务实的：
- 4KB 别当死数。它是”身份文件全量注入每轮”这个前提下的口径。如果你的系统已经做了「索引常驻 + 语义按需召回」，真正该控的是每轮实际注入的 Token 量，而不是某个文件的总大小——盲目压到 4KB，可能反而砍掉了铁律的可读性，得不偿失。
- “手动 read L1” 是偏原始的版本。有语义召回的系统在”按需加载”这一维其实更先进，别向下对齐。这套架构真正稀缺的价值在于物理隔离 + 体积红线 + 防线脚本这三样，而不是检索本身。
- git hooks 依赖你是个 git 仓。不是的话，把它换成 cron / 看门狗里的一个体积巡检脚本，同样管用。
- 最值得抄的一处，其实是那条”能用脚本就别用大模型”。我自己也把它立成了铁律：任何重复、多步、多参的操作，别每次让大模型现想现拼——脚本不会手滑，现拼的复杂调用才会出错。同一个操作手搓第二次，就该固化成脚本了。这篇文章从记忆架构的角度，独立印证了同一个判断。
结语：AI 不怕没有能力，怕的是没有秩序
三级缓存、按需加载、Token 红线，不是三个分散的小技巧，是一整套记忆管理方案：
- 三级缓存，解决”哪些记忆该常驻、哪些该沉下去”；
- 按需加载，解决”上下文装不下时，怎么还记得更多”；
- Token 红线，解决”如何把算力花在判断和创造上”。
很多人现在在堆 Agent、接工具、拼工作流。但真正决定一个 AI 系统能不能长期跑下去的，往往不是功能数量，而是秩序。AI 不怕没有能力，怕的是它有很多能力却没有边界、有很多记忆却没有结构、有很多上下文却没有重点。
一个真正能长期协作的 AI，首先得记住三件事：自己是谁、该做什么、不该做什么。
本文为学习拆解，架构原型出自公众号《我把 15 个 AI Agent 的记忆架构，从 25KB 压到了 4KB》（叶澄风），观点与判断部分为作者结合自身实践补充。