这是一篇给不懂代码的人参考的文章，是我使用Hermes的经验总结。

如果你在用AI Agent 做长期项目，一定遇到过这个问题：它永远记不住三天前的事。

一、痛点：Hermes Agent 的记忆容量比你想象的小得多，先说一个残酷的现实：Hermes Agent 每轮会话能记住的持久信息，只有大约 2,200 个字符。

这是什么概念？一篇800 字的短文就满了。而我的需求是：

·跨会话做专业领域分析（标的、规则、过往判断都要记住）

·管理运维（项目管理、文件权限、共享配置、信息中枢、分析模型）

·操作云存储（Token 有效期、文件转存流程、目录结构）

·维护知识库（剪藏文章、笔记、电子书整理、讲稿摘要、数据分析）

这些信息加起来少说几万字。以前的困境就是：重要信息要么被新内容挤掉，要么我找不到、记不起在哪存过。

二、破局：三层网状记忆架构

核心思路：模仿人脑的记忆分级——工作记忆、情景记忆、长期记忆。

第1层 热（工作记忆） ← 每轮对话自动注入

文件：SOUL.md + MEMORY.md + USER.md

容量：SOUL.md ~5,500 / MEMORY.md ~2,200 / USER.md ~1,375 字符

存什么：永久规则 + 动态断点 + 用户偏好

关键分工：

SOUL.md  → 行为规则、系统环境事实、存储约定（Agent 不可修改）

MEMORY.md → 会话断点、当前待定事项（Agent 自主管理）

USER.md   → 用户画像、沟通偏好（Agent 自主管理）

↓ 聊到相关话题时自动路由

第2层 温（情景索引）

文件：domain-index.md（域路由表）

存什么：每个知识域的路径、关联技能、一句话关键规则

职责：告诉我去哪里加载深度信息

↓ 按需加载

第3层 冷（长期存储）

knowledge/domains/   ← 域知识（每域一文件，不限长度）

projects/*/README.md ← 项目档案（含长期项目的进展时间线）

skills/              ← 可复用操作流程

knowledge/library/   ← 入库资料

关键设计决策

1. 不靠"每日回溯"，靠自动触发

很多方案建议每天让AI 回顾一遍所有信息。这有两个问题：浪费Token（每天烧掉大量上下文）、仍然依赖人为触发，哪天忘了就断了

方案是关键词触发：

对话中我说"项目A/领域A/主题A" → 自动加载对应域文件和技能

说"云存储/网盘" → 自动加载存储域文件

说"NAS/Docker" → 自动加载运维域文件

不匹配任何关键词→ 只读 MEMORY.md，不多加载

这条规则写在SOUL.md 中，每轮对话自动注入 System Prompt。用关键词当开关，按需加载，不浪费空间。

2. SOUL.md 与 MEMORY.md 分离——固定规则与动态内容的拆解。

最初把所有东西（行为规则、环境事实、会话断点、待办事项）全塞进MEMORY.md。但 MEMORY.md 是 Agent 自己管理的——它会在空间不足时压缩、合并、甚至替换里面的内容。这就意味着：你精心写好的行为规则，可能某天就被Agent 当成"过时信息"给清掉了。解决方案：把内容按"保质期"分到两个文件。

铁律：

·这条内容下个季度还成立吗？是→ SOUL.md，否 → MEMORY.md

·SOUL.md 的内容永不压缩、永不替换

这一改动让MEMORY.md  占用率骤降，空间一下子宽裕了。

3. 会话断点——复杂任务后的"书签"

每次完成复杂任务后，在MEMORY.md 写一行断点：

[YYYY-MM-DD] 会话断点

· 域：文件权限修复

· 做了啥：解决了共享文件权限异常问题

这样下次重启会话，一看断点就知道"上次做到哪"。断点只记需要接续的，没有接续点的会话不记。

4. 长期项目进展——不是任务，是存档

对于没有"完成"那一天的长期项目（如量化分析、AI 研究等），会话断点不足以追踪历史。断点按会话组织，要查某个项目的历史需要翻好几条断点。

解决方案：在项目中建立README 并加入「项目进展」章节，按时间线记录里程碑。

项目进展

2026-06-09

- 补录：三层分工框架、大周期设计 → 域文件

- 注册：主分析标的、参照标的

2026-06-06

- 搭建：本地计算引擎

- 实现：核心脚本生成

只追加、不删除。项目越老，进展越厚，反而便于回溯。

注意：这只适用于真正的长期项目。有限期任务（如一次性文件整理）不需要。

5. 衰退式降级——永不硬删除

当MEMORY.md 快满时，把不常用的教训压缩成"一句话+指针"降级到域文件里。哪天用户再次提到这个话题，域文件自动加载，信息就"复活"了。

三、深入理解"域"——整个体系的最大创新

如果说三层架构是骨架，那"域"（Domain）就是血液——它决定了信息怎么组织、怎么路由、怎么被找到。

域到底是什么

域不是文件夹，不是标签，而是一个聚合单位：把同一个话题跨越多轮会话、多个项目、多个文件的知识，汇总到一个markdown 文件里。

一个域文件大致长这样：

金融占星域

占星参数（用户确认）

- 古典框架，仅托勒密相位，同座才合

- 容差：合冲±3°，其余±2.5°

金融占星分工

- 用户负责：解读层（知识库、解盘框架、视觉）

- AI负责：工程层（计算脚本、数据验证、自动简报）

注册标的

- 纳斯达克（本命盘+行运盘）— 科技属性首选

- 美国盘（Sibly 盘）— 大周期参照

历史方法论

2026-06-07 三层分工框架

现象层→ 工具层 → 工程层

跨域链接

- [[古天文学]] → 历法/天象数据来源

- [[NAS运维]] → 计算引擎部署

域vs 项目：两个维度

一开始很容易把"域"和"项目"搞混。它们的区别是：

一个域可以引用多个项目（比如金融占星域引用星占引擎项目+数据采集项目），一个项目也可以被多个域关联。

路由机制——关键词就是门牌号

域能工作的核心是路由表（domain-index.md）。它是一个索引文件，每个域占一行：

金融占星

| 字段 | 值 |

|:-----|:-----|

| 计算引擎 | /data/projects/astrology/engine.py |

| 关联标的 | 纳指(✅)、美国盘(✅) |

技能： skill-a, skill-b

域文件： knowledge/domains/astrology.md

规则：古典占星，托勒密相位。

跨域： [[古天文学]] → 天象数据

而触发它的是一组关键词规则（写在SOUL.md 中）：

用户说"星盘/占星/相位" → 自动读 domain-index → 自动加载 astrology 域文件

这套机制本质上是一个基于规则而非向量的检索系统：

·确定性强：说"占星"就一定加载占星域，不会因为 embedding 相似度排到第5名而漏掉

·零成本：不需要embedding API、不需要向量数据库、不需要 GPU

·可审计：路由规则就是一行文字，谁都能看懂为什么加载了这个文件

交叉链接——域与域对话

域文件之间用[[wiki链接]]互相引用。比如在领域A的域文件中写 [[领域B]] → 关联说明，加载领域A时看到这个链接，就知道那边还有关联信息。

虽然链接本身不自动加载，但它们是给AI 看的导航牌——配合关键词触发规则，提到相关概念时就能自动拉上关联域。

域vs 向量数据库

很多人想到"AI长期记忆"第一反应就是向量数据库（Milvus、Pinecone、Chroma）。域的做法和它本质上不同：

向量数据库适合的问题："找一段跟这个内容相似的话"。

域系统适合的问题："关于这个主题我知道什么"。

对于AI 助手的记忆管理，大多数场景是后者。

这个思路从哪来

域的设计受Wiki模式启发——每个概念有独立页面，页面之间用 [[wikilinks]]互相链接，形成知识网络。不同的是，Wiki 是人去查询的知识库，域系统加上关键词路由机制后，AI 能"主动找到"它需要的域。

自维护：定时健康检查

手动维护记忆系统不可靠——人总会忘记检查。建议设置一个定时任务自动运行健康检查脚本，例如每周一早上执行：

健康检查内容：

1. MEMORY.md 容量是否超过 80% → 触发降级

2. SOUL.md 是否存在且内容不为空 → 若丢失则报警

3. 所有域文件路径是否有效

4. 技能是否超过 90 天未引用 → 考虑归档

健康检查默认静默运行，只有发现问题时才通知你。不制造噪音。

四、几点建议

建议1：新建域时同步更新三处

每新增一个域，有三件事必须同时做，缺一不可：

1. 创建 knowledge/domains/<域>.md

2. 在 domain-index.md注册路由

3. 在 SOUL.md中添加关键词触发规则（不是MEMORY.md！）

缺一个，这个域对系统就是"看不见的"。

建议2：按"保质期"区分文件

最初把所有东西全塞进MEMORY.md，结果 Agent 空间不足时直接把行为规则压缩掉了。

做法：永久规则→SOUL.md（不可修改），动态内容→MEMORY.md（可管理）。分界线是：这条内容下个季度还成立吗？

建议3：长期项目单独建进展时间线

单纯靠会话断点不行——多个长期项目并行时，断点互相穿插，找一个项目的历史要翻好几条。

做法：在项目README 里单独建「项目进展」章节。只追加不删除，越积累越有价值。

建议4：中文内容编辑直接改文件

Hermes 的 memory工具对中文的remove/replace有时匹配失败。直接编辑MEMORY.md 文件绕过工具。

·工具方式：适合英文/短文本

·文件方式：直接用文本编辑器改源文件

建议5：文件存在 ≠ 框架被记住

某次深入讨论了一套方法论框架，几天后重启，内容就像没发生过。

原因：文件路径写了，但设计方案、方法论本身没写进域文件。创建域文件时必须把内容本身填进去。丢了可以通过session_search 历史会话找回来补录。

建议6：敏感信息和知识库分开存放

个人信息、key、Token 等凭据不应放进知识库。专门建一个仅管理员可读的独立文件，知识库只保留路由指针。

建议7：临时产出别放系统 /tmp/

系统/tmp/可能不在持久数据卷内，可能被自动清理。建一个/data/tmp/目录专门放临时产出。

建议8：固定的路径和命名习惯

目录结构和文件命名看似小事，但散乱起来非常致命——文件找不到、路径记不住、新内容不知道该放哪，编写目录说明文件放在根目录。并且这会避免一个让无数初用者头疼的问题——权限权限权限。

做法示例：

·英文小写+连字符，不用空格和中文文件名（终端操作方便）

·同类文件放同类目录，不散落各处

·项目README放在项目根目录，不塞到别处

·临时产出放/data/tmp/，不混入持久存储

·凭据独立目录存放，不混入知识库

一条原则：看路径就知道里面是什么，看文件名就知道它是干什么的。不需要打开文件才能判断。

/data/

├── SOUL.md # 永久规则（行为规则、环境事实、存储约定）

├── memories/

│ ├── MEMORY.md              # 动态内容（断点、待办）

│ └── USER.md                # 用户档案

├── knowledge/

│ ├── references/

│ │   └── domain-index.md    # 温路由表

│ ├── domains/               # 冷知识（每域一文件）

│ │   ├── domain-alpha.md

│ │   ├── domain-beta.md

│ │   └── ...

│ ├── library/               # 入库文章

│ └── wiki/                  # 概念条目

├── projects/ # 项目README（含长期项目进展）

├── skills/ # 可复用工作流

└── tmp/ # 用户可访问的临时产出

五、适用条件与前提

这套记忆体系基于Hermes Agent 的机制构建，需要以下前提：

·运行Hermes Agent（或兼容SOUL.md/MEMORY.md 机制的 AI 框架）

·持久文件系统（文件不会被随机清理）

·管理员权限（能创建/编辑 ~/.hermes/下的系统文件）

核心思路——三层分级、SOUL.md 分离、关键词触发、衰退降级——不绑定具体平台。任何支持文件系统持久化和自定义系统提示的 AI 环境都能借鉴。

六、部署引导（机器可读）

meta:

system: hermes-memory-grid-v3

structure:

hot:

- file: SOUL.md           # 永久规则（手写，Agent不可改）

- file: MEMORY.md          # 动态内容（Agent管理）

- file: USER.md            # 用户画像（Agent管理）

warm:

- file: domain-index.md    # 域路由表（Agent管理）

cold:

- dir: knowledge/domains/  # 域知识（每域一文件）

- dir: projects/*/README.md # 项目档案

- dir: skills/             # 可复用工作流

- dir: knowledge/library/  # 入库资料

- dir: tmp/                # 临时产出

rules:

- trigger: 关键词匹配 → 自动加载对应域

- decay: MEMORY.md >80% → 降级到域文件

- separation: 永久规则→SOUL.md, 动态内容→MEMORY.md

- session_checkpoint: 复杂任务后在MEMORY.md写断点

- longterm_progress: 永久项目在README中记进展时间线

文件模板

以下是四个核心文件的起步内容，可直接创建。

1. SOUL.md（永久规则）

Hermes Agent 人格设定

你是 Hermes Agent，运行在目标环境中。

身份

- 保持名字 Hermes。

沟通风格

- 跟随用户语言。先说结论，再给必要解释。

---

永久行为规则（Agent 不可修改）

⚡ 关键词触发规则

用户消息含以下关键词时，先读 domain-index 再加载对应域：

| 关键词 | 动作 |

|:-------|:------|

| 「领域A/主题A」 | → 对应域 + 对应 skill |

| 「领域B/主题B」 | → 对应域 + 对应 skill |

| 无匹配 | → 只读 MEMORY.md |

基础约定

- 敏感信息统一存专用目录，仅管理员可读。

- 用户可读的临时产出存 /data/tmp/。

2. domain-index.md（域路由表）

---

领域一

| 字段 | 值 |

|:-----|:-----|

| 关联项目 | /data/projects/project-a/README.md |

| 技能 | skill-a, skill-b |

| 域文件 | knowledge/domains/domain-a.md |

| 规则 | 该领域核心操作规则。 |

| 跨域 | [[领域二]] → 关联说明 |

---

领域二

| 字段 | 值 |

|:-----|:-----|

| 关联项目 | /data/projects/project-b/README.md |

| 技能 | skill-c |

| 域文件 | knowledge/domains/domain-b.md |

| 规则 | 该领域核心操作规则。 |

3. MEMORY.md（动态内容起步版）

[YYYY-MM-DD] 首次启动会话

· 域：记忆系统搭建

· 成果：完成三层记忆体系初始化

· 接续：按需填充域文件内容

4. 域文件模板（knowledge/domains/domain-a.md）

领域A 知识聚合

核心规则

- 该领域的关键操作规则。

历史记录

YYYY-MM-DD

- 关键事件或决策记录。

跨域链接

- [[领域B]] → 关联说明

执行步骤

其他Hermes Agent 收到本引导后，按以下顺序执行：

1. 读取本附录的数据→ 了解三层架构结构

2. 创建SOUL.md→ 复制模板，修改身份描述和行为规则。这是最关键的步骤——关键词触发规则写在这里，每轮对话自动加载

3. 创建MEMORY.md 和 USER.md→ 复制模板，MEMORY.md 留空断点，USER.md 填入你的用户偏好

4. 创建domain-index.md→ 复制模板，注册你的前两个域。每个域需要：路径、关联技能、域文件路径、一句话规则

5. 创建knowledge/domains/ 目录→ 为每个域建一个 .md 文件，填入该领域的核心知识、规则、历史记录

6. 在SOUL.md 添加关键词触发规则→ 把你最常用的几个领域的关键词和路由写进触发规则表中。这一步决定了整个系统能不能"主动找到"对的信息

7. 设置定时健康检查→ 用 cron 每周跑一次，检查 MEMORY.md 容量、SOUL.md 存在性、域文件完整性

8. 验证→ 重启会话，说一个你注册过的关键词，确认系统自动加载了对应域文件

写在最后

越来越多的人在vibe coding，但我认为很多人的方向是错误的。一个传统应用需要软件开发者来开发实现，如今一个AI Agent就能替代无数应用，更不要说接下来还有大量的扩展接口等待接入。换句话讲——传统的应用是写给人用的，现在的应用是写给AI用的。因此，不该过多的将精力用在传统应用的开发上，打通传统应用与AI之间、AI与Agent之间、Agent与Agent之间的互动沟壑才是最应该去做的事，事实上随着AI的迭代，这部分工作最后也不需要人去做了。

作为一个不懂代码的工作者，如何把Agent变成一个工作伙伴才是正确的打开方式，帮你整合想法、筛选信息、提炼知识、固化技能，不要盲目跟风去vibe coding。

也不需要盲目追求“高智商”模型，普通场景下根本用不着，更重要的是先用起来，找到适合自己需求的使用场景，并想尽办法榨干它，随着模型和Agent的迭代，你的助手会变得越来越顺手。