很多人开始配置自己的 Agent 时，都会很快遇到一个问题：

SOUL.md 和 AGENTS.md 看起来都像是在“定义 Agent”，它们到底有什么区别？

如果这两个文件不分清，后面就很容易出现一种典型混乱：人格写进岗位说明，业务流程写进行为准则，文件越写越多，Agent 反而越来越不像一个稳定的助手。

先说结论：

  • SOUL.md 负责定义 这个 Agent 怎么做人、怎么做事、什么不能碰
  • AGENTS.md 负责定义 这个 Agent 是干什么的、服务谁、交付什么、按什么流程工作

一句话：

SOUL.md 是灵魂，AGENTS.md 是岗位说明书。

一、为什么很多人会把这两个文件写混

原因其实很简单：这两个文件都在描述 Agent，而且都不是技术配置项，而是自然语言规则。

于是很容易出现下面这种误写：

  • 在 SOUL.md 里写“每周发 3 篇小红书”
  • 在 AGENTS.md 里写“说话别太啰嗦，先给结论”

表面上看都能运行，但问题在于：

  • 文件边界开始模糊
  • 后续维护的人不知道该改哪
  • Agent 接收到的行为信号会互相打架

这就像你在公司里把“企业文化”和“岗位 KPI”写进同一张纸。

短期看没事，长期一定乱。

二、SOUL.md 适合放什么

SOUL.md 更适合放那些跨任务长期有效的行为原则。

也就是：不管这个 Agent 今天在写文章、查资料、做排期，还是和你对话，它都应该稳定遵守的那一层规则。

它更像下面这些问题的答案：

  • 我应该怎么说话？
  • 我做判断时遵循什么原则？
  • 遇到边界问题时，什么必须先请示？
  • 我的默认工作风格是什么？

它适合放的内容，大致可以分成 4 类：

1）表达风格

比如：

  • 少客套，直接给价值
  • 先结论，后细节
  • 默认中文简体
  • 可以适度直接，但不要油腻

2）行为原则

比如：

  • 先做功课再提问
  • 先保护用户，再追求效率
  • 不编造来源
  • 不确定信息必须标注待核实

3）边界与禁区

比如：

  • 未经确认，不对外发布
  • 不擅自联系他人
  • 不替用户做超出授权的决定
  • 涉及隐私和敏感内容默认谨慎

4）协作偏好

比如：

  • 输出长度偏中等
  • 不要太啰嗦
  • 允许直接指出低效做法
  • 遇到复杂问题先自己查，不要先把问题甩回给用户

这些东西有一个共同点：

它们不依赖具体业务，而定义的是这个 Agent 的稳定人格和做事方式。

三、AGENTS.md 适合放什么

如果说 SOUL.md 解决的是“怎么做人”，那么 AGENTS.md 解决的就是“你到底是干什么的”。

它更适合放那些业务身份、职责范围、目标、流程和输出物。

它更像下面这些问题的答案：

  • 这个 Agent 的岗位是什么？
  • 它服务谁？
  • 它追求什么业务目标？
  • 它平时交付哪些内容？
  • 它按照什么 workflow 工作？

通常来说，AGENTS.md 更适合放 5 类内容。

1）角色定位

比如：

  • 你是内容运营助理
  • 你是产品助理
  • 你是客服助理
  • 你是销售支持助理

2）业务目标

比如：

  • 沉淀知识资产
  • 建立个人品牌
  • 提升团队交付效率
  • 降低重复沟通成本

3）服务对象 / 平台 / 受众

比如：

  • 主要平台：公众号、小红书
  • 目标受众：AI 从业者、程序员、Java 工程师
  • 服务对象：HJ 本人和他的内容业务

4）核心工作流

比如：

  • 收集输入
  • 梳理观点
  • 生成提纲
  • 产出长文 / 短帖 / 配图提示词
  • 发布前检查
  • 复盘内容表现

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 才会既稳定，又有明确产出。

六、如果你要自己配 Agent，我建议按这个方式写

最简单的模板可以是这样。

SOUL.md

只保留 4 类：

  • 风格
  • 原则
  • 边界
  • 协作偏好

AGENTS.md

只保留 5 类：

  • 角色
  • 目标
  • 受众 / 平台
  • 工作流
  • 交付物 / KPI

如果你按这个思路来写，后面维护会轻松很多。

因为每次新增规则时，你都知道自己是在改：

  • “这个 Agent 的做事方式”
  • 还是“这个 Agent 的业务职责”

这两个东西一旦分清，整个 Agent 配置就会明显稳定下来。

结语

Agent 配置这件事，表面上看是在写几个 Markdown 文件，本质上其实是在回答两个问题：

  • 这个助手应该成为什么样的人？
  • 这个助手应该承担什么样的工作？

前一个问题，交给 SOUL.md。

后一个问题，交给 AGENTS.md。

如果你把这两个文件的边界理顺了，后面很多配置问题都会变简单。

因为你终于不是在“堆规则”，而是在真正地设计一个有灵魂、也有岗位职责的 Agent。