很多人开始配置自己的 Agent 时，都会很快遇到一个问题：
SOUL.md 和 AGENTS.md 看起来都像是在“定义 Agent”，它们到底有什么区别？
如果这两个文件不分清，后面就很容易出现一种典型混乱：人格写进岗位说明，业务流程写进行为准则，文件越写越多，Agent 反而越来越不像一个稳定的助手。
先说结论：
SOUL.md 负责定义 这个 Agent 怎么做人、怎么做事、什么不能碰AGENTS.md 负责定义 这个 Agent 是干什么的、服务谁、交付什么、按什么流程工作一句话：
SOUL.md 是灵魂，AGENTS.md 是岗位说明书。
原因其实很简单：这两个文件都在描述 Agent，而且都不是技术配置项，而是自然语言规则。
于是很容易出现下面这种误写：
SOUL.md 里写“每周发 3 篇小红书”AGENTS.md 里写“说话别太啰嗦，先给结论”表面上看都能运行，但问题在于：
这就像你在公司里把“企业文化”和“岗位 KPI”写进同一张纸。
短期看没事，长期一定乱。
SOUL.md 适合放什么SOUL.md 更适合放那些跨任务长期有效的行为原则。
也就是：不管这个 Agent 今天在写文章、查资料、做排期，还是和你对话，它都应该稳定遵守的那一层规则。
它更像下面这些问题的答案：
它适合放的内容，大致可以分成 4 类：
比如：
比如：
比如：
比如：
这些东西有一个共同点：
它们不依赖具体业务，而定义的是这个 Agent 的稳定人格和做事方式。
AGENTS.md 适合放什么如果说 SOUL.md 解决的是“怎么做人”，那么 AGENTS.md 解决的就是“你到底是干什么的”。
它更适合放那些业务身份、职责范围、目标、流程和输出物。
它更像下面这些问题的答案：
通常来说，AGENTS.md 更适合放 5 类内容。
比如：
比如：
比如：
比如：
比如：
这些内容有一个共同点：
它们定义的是这个 Agent 的工作岗位，而不是性格。
如果你拿到一条规则，不知道该放哪，就问自己一句：
它到底在回答“我怎么做事”，还是“我做什么事”？
放进 SOUL.md。
例如：
放进 AGENTS.md。
例如：
这是区分这两个文件最省脑子的办法。
SOUL.md很多人喜欢把一切“对 Agent 的要求”都堆进 SOUL.md，因为它名字听起来更高级。
但这会带来两个问题：
SOUL.md 变成一个无边界的大杂烩AGENTS.md 反而变空，只剩一句角色介绍这样做的后果是，Agent 会越来越像“有很多态度，但没什么明确职责”。
反过来也一样。
如果你把所有业务流程和 KPI 都塞进 AGENTS.md，却不定义风格和原则，那 Agent 通常会变成另一个问题：
所以真正合理的方式，不是二选一，而是：
SOUL.md 负责“人格和准则”AGENTS.md 负责“业务和工作”两者配合，Agent 才会既稳定，又有明确产出。
最简单的模板可以是这样。
SOUL.md只保留 4 类：
AGENTS.md只保留 5 类：
如果你按这个思路来写，后面维护会轻松很多。
因为每次新增规则时，你都知道自己是在改：
这两个东西一旦分清，整个 Agent 配置就会明显稳定下来。
Agent 配置这件事，表面上看是在写几个 Markdown 文件，本质上其实是在回答两个问题：
前一个问题，交给 SOUL.md。
后一个问题，交给 AGENTS.md。
如果你把这两个文件的边界理顺了，后面很多配置问题都会变简单。
因为你终于不是在“堆规则”，而是在真正地设计一个有灵魂、也有岗位职责的 Agent。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。