我给 AI Agent 装了一套「记忆系统」：从 ACE 论文到生产级闭环
如果你的 AI 编码助手每次新 session 都像得了失忆症——不知道上次做到哪、不记得踩过的坑、不更新自己的技能库。我用一个周末，基于两篇顶会论文，给 Hermes Agent 搭了一套完整的上下文工程系统。成果：skills 描述缩减 84%，16 个 cron job 全自动运行，5 个 draft skill 自动生成。
AI Agent 的最大瓶颈不是推理能力。是记忆。 每次新 session 等于新生儿。78 个技能 76% 从未被使用。 修复这个问题，不需要等下一个大模型。只需要一个好架构。
问题的量化
先看数据。在搭建这个系统之前，我扫描了自己的 Hermes Agent：
| 指标 | 数字 | 意味 |
|---|---|---|
| 总 skills | 78 | — |
| 从未被使用 | 59 (76%) | Agent 根本不知道它们存在 |
| 描述超 100 字符 | 39 (57%) | 撑爆 prompt token |
| MEMORY.md 字符数 | 6,765 | 含 600+ 行重复日期（bug） |
| Curator 运行次数 | 5 | 0 stale, 0 archived（从未清理过） |
| 解决方案文件 | 43 | 全堆在一个目录，无法检索 |
一句话总结：Agent 在积累知识，但知识从来没有被有效组织、检索、回写。
这个问题的本质不是模型能力。是架构设计。
理论基础：两篇论文
我花了半天读了两篇 2026 年的关键论文：
ACE (Agentic Context Engineering) — ICLR 2026, arXiv 2510.04618
核心发现：上下文的本质不是静态摘要，而是持续演化的 playbook。三个角色形成闭环：
| 角色 | 职责 | 论文结果 |
|---|---|---|
| Generator | 执行任务 | — |
| Reflector | 反思产出 | — |
| Curator | 整理、去重、衰减、回写 | +10.6% benchmark, -86.9% 延迟, -75.1% 成本 |
关键洞察：Bulletized context + 增量更新。 永远不重写整个上下文，只追加新的结构化条目。论文记录过一个 case：散文式上下文从 18,282 tokens 压缩到 122 tokens 后几乎完全丢失信息——这就是为什么「写得更短」不是解决方案，「写得更结构化」才是。
Memory for Autonomous LLM Agents — arXiv 2603.07670
58 页综述，覆盖了 2022 到 2026 年的 agent memory 研究。结论：行业正在收敛到三层架构——episodic（事件记忆）、semantic（语义记忆）、procedural（过程记忆）。这与 ACE 的三角色模型高度对齐。
系统设计
基于这两篇论文，我搭建了一个完整的上下文工程系统。核心架构：
Session End（Hook 触发，不等定时任务）
↓
reflect.sh --classify → 自动分桶到 patterns/bugs/knowledge
index.py → .index.yaml 结构化索引
memory-hook.sh → 阈值检测 → 自动更新 MEMORY.md
pattern-detector.sh → 3+ 同模式 → draft skill
skill-usage-hook.sh → 快照差分追踪技能使用
↓
Cron 兜底（hook 挂了也不怕）
5 个 cron job：衰减 / 去重 / LLM 合并 / 投毒扫描 / 灾难恢复
设计决策一：Hook 优先于 Cron + Agent
业界常见的做法是「定时任务 + Agent 自己决定」。问题：Agent 可能「忘了」执行，延迟 24 小时才生效。
我的方案：Hook 即时触发为主，Cron 兜底为辅。
| 场景 | Hook（即时） | Cron（兜底） |
|---|---|---|
| 新解决方案分类 | ✅ session-end | ❌ |
| MEMORY.md 更新 | ✅ session-end | ✅ 每日 4:00 |
| 模式检测 | ✅ session-end | ✅ 每周日 3:30 |
| 衰减/去重 | ❌（太重） | ✅ 每周日凌晨 |
设计决策二：不破坏 Hermes 原生接口
所有改动通过 ~/.hermes/skills/ 和 ~/.hermes/scripts/ 实现。不改一行 Hermes 核心代码。删脚本 + 删 cron 即可恢复原状。
设计决策三：反思→分类→回写全自动
之前： Agent 踩坑→写 solution 文件→下一个 session 不知道这个文件存在。
现在：
任务完成 → reflect.sh 反思
→ 自动分桶 patterns/bugs/knowledge
→ index.py 注册到 .index.yaml（结构化索引）
→ pattern-detector 检测 3+ 同模式 → 自动生成 draft skill
→ 5+ high-importance → 自动回写 MEMORY.md
成果
Skill 系统
| 指标 | 改造前 | 改造后 |
|---|---|---|
| Description 总字符 | ~15,000 | 2,322 (-84%) |
| 超长描述 | 39 (57%) | 0 |
| 幽灵条目（无实际 skill） | 70 | 0 |
| 平均描述长度 | 190 chars | 34 chars |
Memory 系统
| 指标 | 状态 |
|---|---|
| MEMORY.md 字符 | 2,166 / 2,200 ✅ |
| Solutions 索引 | .index.yaml 362 行 |
| Cron jobs（新增） | 5 个（衰减/去重/合并/扫描/恢复） |
| Pattern 候选 | 5 个 draft skill |
自进化
.reflect.sh --classify → 33 条索引
↓
pattern-detector.sh → 3 个高重要性模式 (17/16/6 occurrences)
↓
.candidates/ → 5 个 draft SKILL.md
↓
等待 curator 审核 → 自动发布
踩坑实录
这套系统不是一遍搭好的。以下是真实踩过的坑：
坑 1：str.replace 全文替换
memory-sync.py 用 content.replace("最后更新：", f"最后更新：{today}") 更新时间戳。但这个操作是全文替换——每次运行在原日期前面再粘一个新日期。几周下来，MEMORY.md 的 6,765 字节几乎全是重复日期。
修复： 改用 re.sub(r"^> 最后更新：[\d-]+\n", ...) 精确匹配。
坑 2：access_count 不递增
整个 decay 系统依赖 access_count 判断文件是否被使用。但没有任何代码递增这个计数器。结果：所有文件都会被标为「从未使用」，30 天全部归档，90 天全部删除。
修复： 改用文件 mtime（修改时间），不依赖计数器。
坑 3：yq 未安装
计划用 yq 做 YAML 操作，但服务器没装。PyYAML 是现成的。
教训： 设计前先检查已安装的工具。
坑 4：source 路径没有项目信息
跨项目模式检测需要知道「这个 pattern 在哪些项目出现过」。但 source 字段写的是 session://date，没有项目路径。
修复： 每次分类时注入 project=$PWD。
坑 5：Agent 决策不可靠
原始设计是「cron 触发的 Agent 读 JSON → 决定是否更新 MEMORY.md」。但 Agent 可能不读、可能读了不执行。
修复： 改 Hook 自动执行，零 Agent 决策。
与行业实践的对比
| 能力 | Claude Code Auto-Memory | Codex Chronicle | 我们 |
|---|---|---|---|
| Agent 自写上下文 | ✅ CLAUDE.md | ✅ chronicle | ✅ AGENTS.md + MEMORY.md 回写 |
| 渐进式加载 | ✅ description only | ✅ 上限 2% context | ⚠️ Hermes 架构限制 |
| 文件衰减 | ❌ | ❌ | ✅ mtime + trust decay |
| 模式检测→Skill 生成 | ❌ | ❌ | ✅ 3+ same-tag → draft |
| 记忆投毒防御 | ❌ | ❌ | ✅ MINJA pattern 扫描 |
| 零破坏设计 | ❌ (couples to core) | ❌ | ✅ 不改核心代码 |
我们独有的： ACE 三角色全闭环（行业中唯一完整实现）、Hook 优先架构、自进化 Skill 生成。
这个系统适合谁
如果你：
- 维护 3+ 个 AI Agent 项目
- 有 50+ 个 skills 但不知道哪些真的被用过
- Agent 的记忆文件在默默膨胀
- 想让 Agent 自己从踩坑记录里学会新技能
那么这套系统可以直接适配。所有的脚本在 ~/.hermes/skills/ 和 ~/.hermes/scripts/ 下，不改 Agent 核心代码。
下一步
当前系统已经跑了完整的 Reflector→Curator→Evolver 闭环。接下来：
- Embedding 语义去重 — 当前用的是 content hash，对近义内容无法去重
- 跨项目 AGENTS.md 自动更新 — pattern 跨 2+ 项目出现时自动写回
- LoCoMo benchmark 评估 — 用标准 benchmark 量化记忆能力提升
本系统基于 ACE (arXiv 2510.04618) 和 Memory for Autonomous LLM Agents (arXiv 2603.07670) 两篇论文。全部代码在 ~/context-engineering-system/，不改 Hermes 核心。