用了两个月 Hermes Agent，改了 30 多次 SOUL.md。这篇文章分享我的三层知识架构：SOUL.md 做索引、Skills 做流程、Obsidian 做知识库。

效率痛点

你有没有遇到过这种情况：装了一个 AI Agent，配好了 API Key，连上了飞书/Telegram，兴冲冲地用起来——结果它要么像个实习生一样每件事都要问你，要么自作主张干了一堆你不需要的事。

问题不在模型，不在工具，在于你没告诉它「你是谁」。

Hermes Agent 有一个设计：SOUL.md。这个文件是 Agent 系统提示词的第一条，定义了 AI 的性格、价值观和行为边界。写得好，AI 就像你的老搭档；写得烂，AI 就是个戴了面具的陌生人。

我的实战经历：从混乱到秩序

第一版：什么都往里塞

刚开始我把能想到的规则全塞进 SOUL.md：怎么派活、怎么写代码、怎么调试、怎么发文章……SOUL.md 膨胀到 4KB+，每条消息白白浪费 3000-4000 token。规则太多 AI 反而记不住——你写 50 条规则，它能遵守 20 条就不错了。

第二版：拆到 Skills，但还不够

发现 SOUL.md 每条消息都注入，但 Skills 只在需要时加载。所以把操作性规则全部拆成独立 Skills。SOUL.md 只保留核心身份和红线。

这一步是对的，但还不够。因为真正让 AI 变聪明的不是规则，而是知识。

第三版：三层知识架构

经过反复调整，找到最优解——三层分离：

• SOUL.md（身份层） → 我是谁、我的底线是什么、我怎么说话
• Skills（流程层） → 我怎么做某类任务（按需加载，空闲零成本）
• Obsidian（知识层） → 我需要知道什么事实和上下文（按需查询）

关键洞察：SOUL.md 不只是规则文件，它还是一个索引。

我的 SOUL.md 里有这样一段：

1
2
3

## 流程违规与教训
- wiki/reference/ERRORS.md：可避免的流程违规
- wiki/reference/LEARNINGS.md：技术挑战/意外错误

这不是规则，这是指针——告诉 AI：「你的经验教训存在这两个路径里，遇到相关问题时去查。」

SOUL.md 的五层内部结构

第一层：身份声明 — 一句话定义 AI 是谁。 第二层：核心信条（3-5 条） — 价值观层面的决策原则。 第三层：铁律（5-9 条） — 绝对不可违反的行为规则。20 条 = 没有铁律。 第四层：红线（3-6 条） — 安全边界。每加一条问：真的会出事吗？ 第五层：风格指引（3-5 条） — 控制说话方式，不是控制做什么。

三条核心原则

原则一：每条规则问「每条消息都需要吗？」 闲聊天气时这条规则有意义吗？没有就放 Skills 或 AGENTS.md。

原则二：少而硬 > 多而软。 5 条严格遵守 > 50 条「尽量做到」。「保持专业」→ 什么叫专业？「先给结论再解释」→ 可判断。

原则三：SOUL.md 是索引，不是仓库。 事实性知识→Memory，操作性流程→Skills，项目信息→AGENTS.md，历史经验→Obsidian wiki。SOUL.md 只放跨项目、跨场景、每条消息都需要的东西。

实操建议

从 15 行精简版开始，用一周观察迭代。当 SOUL.md 超过 50 行或出现条件规则，就拆成 Skills。

不要写进 SOUL.md 的： 项目路径→AGENTS.md，代码风格→Skills，服务器信息→Memory，错误记录→Obsidian wiki。

总结

SOUL.md 的本质是约束传播。好的约束让 AI 更精准，坏的约束让 AI 更困惑。

真正的效率提升来自三层分离：

1. SOUL.md 做索引 — 精简身份 + 红线 + 风格
2. Skills 做流程 — 操作规则按需加载
3. Obsidian 做知识库 — 事实知识独立存储，SOUL 通过路径索引指向它

最好的 SOUL.md 不是最长的那个，而是你用了一个月之后还能背出来的那个。