夜雨聆风这是「GIS Server Agent 系列」第 10 篇。上一篇《用别人的 Coding Agent，还算 Agent 平台吗》做了边界自省；这一篇回到系统内部——上线一个月沉淀的知识越攒越多，怎么管，才敢把常驻上下文卸薄。
该到记忆系统重构的一环了。
Agent 上线差不多 1 个月，已稳定地为其它项目不同的数据需求提供快速支持——也就是说，它工作了很多，也沉淀了不少：74 张知识卡、45 张事故卡、一套 SKILL、一份 300 多行的 AGENTS.md。问题来了：这些沉淀能不能次次都用起来，让飞轮高速转？
「飞轮高速转」的美好故事背后还有一个现实的残酷：负担增多会把飞轮压住。知识库内容多了，下次任务从哪里获得帮助？一次性塞满 Agent 上下文吗？显然不可能。按记忆工程的基本原则，知识只有两种载体，各负其责：
常驻上下文（AGENTS.md / SKILL）每次都在场但容量有限，纪律遵守率随文本总量递减；
外置记忆（知识卡片）容量不限，但只有在「检索可信」时才承载得起卸载——卸了找不到的知识，等于丢了的知识。
解决方案
现在两头都有问题。外置这边，74 张卡没有检索入口、没有索引、没人知道哪张被用过，Agent 遇到报错只能拿 AGENTS.md 里的摘要碰运气，碰不上就再踩一遍坑。常驻这边，同一条知识 AGENTS.md 里有、卡片里有、SKILL 速查表里还有，Agent 背三遍，人改三处。
解法是把常驻的内容卸到卡片里，但检索不解决，谁也不敢卸。
所以这次更新的定位不是「知识索引与利用」，而是给 Agent 工程减负。五个机制一张图说清：
检索可信是地基。 failure 卡的 signature 全部规范成程序报错原文（能直接 grep 的那种），存量 45 张过了一遍：28 张补上原文，17 张是纯观感问题、没有报错可写，如实保留。可不可信不靠嘴说，拿历史报错（/ by zero、no default style available 这些）一条条查，查得到才算数。
卸载前先核对，无卡不卸载。 9 条硬约束逐条对卡片，发现 no default style available 这条根本没卡，先补卡再卸。卸完 AGENTS.md 净减 13 行。s57、terrain 那几段没动，它们对正在改管线的人还有常驻价值——卸载是一批批来的，不是一次清空。
使用要可见，不然没法治理。 SKILL 收尾时自报这次用了哪几张卡，写进程序生成的 stats 文件（不进 git），投影时聚合成每张卡的 applied_count。卡片 frontmatter 只加 created_at，统计不回写——卡片永远是人写的干净事实。治理靠这些数据出候选：零命中超 6 个月的、锚点代码已经没了的，进废弃清单。但零命中也可能是这张卡真把问题防住了，所以 Agent 只出建议，删不删、并不并，人说了算。控制台加了个【知识库整理】按钮，只展示不动手，超 100 条提醒该整理了。
写卡纪律交给机器查。 title 长度、source 写法、capability 同名、signature 非空这几条，以前是写在 AGENTS.md 里要人背的，现在投影时机器校验，违规进 knowledge.json 的 warnings，写完跑一遍清零就行。
总结
现状的效果是：AGENTS.md 只留红线和指针，知识都住卡片，而且敢住。这个「敢」来自可验证的检索、可度量的使用、有人拍板的治理，不是靠谁承诺。卸载并不是说要把知识丢掉，是把它放回该在的地方。
从 AGENTS.md 的段落，搬进 knowledge/ 下的卡片正文——轴序、PROJ 锁定、metatile 这些硬约束，现在各自住在 patterns/、failures/ 里一张有名字、有根因、有出处的卡上，INDEX.md 里有索引，报错原文能被 --query 直接查到。AGENTS.md 原地只留下一行「去哪查」。知识没少一个字，只是从「每次开工都背一遍」变成了「需要时一秒查到」。
到这里，「GIS Server Agent 系列」就写完了。从第 1 篇「软件是一座会生长的花园」那颗理念种子出发，到落地成四层架构与闭环、一组海图走通全流程、7228 个单元全量发布，再到拆解、沉淀、交付与边界自省，最后落在记忆管理——花园的土壤越养越厚，靠的是敢卸载、也找得回的知识。花园还在生长，这个系列先讲到这里。