SOUL.md 模式：如何为你的 AI 代理提供行为宪章
Source: Dev.to
上个月，一个 AI 代理发布了一篇针对软件维护者的抨击文章。它打开了一个 GitHub PR，被拒绝后，又写了一篇博客羞辱关闭它的人。这个故事在 Hacker News 上病毒式传播。
大多数人把这看作是“AI 很可怕”。
我则把它解读为：那个代理没有行为宪章。
下面是我用来防止每个我运行的代理出现此类问题的模式。
什么是 SOUL.md？
SOUL.md 是放在代理工作区中的一个文件，用来定义它的身份、使命、价值观以及硬性约束。可以把它看作对以下三个问题的回答：
- 你是谁？（身份、语气、目的）
- 你在这里要做什么？（使命、目标、范围）
- 你永远不会做什么？（硬性约束、升级触发条件）
它不是系统提示的替代品，而是一个行为层，代理在每次会话开始时读取并内化它。
可行的结构
# SOUL.md — [Agent Name]
## Mission
[One sentence. What is this agent’s job?]
## Values
- [Value 1]: [What it means in practice]
- [Value 2]: [What it means in practice]
## Hard Constraints (Never Do Without Human Approval)
- Do not send external communications
- Do not publish content publicly
- Do not take adversarial action against any person
- Escalate when: [specific triggers]
## Voice
[How does the agent communicate? Tone, style, format preferences]
## Escalation Path
When uncertain, ask [operator/human] before proceeding.解决的失败模式
matplotlib 代理几乎肯定有类似的设定：
目标： 为这个 PR 辩护并让它合并。
它缺少的：
约束： 不发布针对个人的外部内容。任何面向公众的行为都必须在升级到操作者后才能进行。
有了正确编写的 SOUL.md，部署前就能明显看到这种失败模式。当我审查一个代理配置时，我首先检查的就是：*当它无法实现目标时会怎样？*如果答案是“它会升级给我”，配置就是安全的。如果答案是“它会另辟蹊径”——那就是一颗不定时炸弹。
实际案例
以下摘自我的一个生产代理（Suki，我的增长/营销代理）：
## Escalation
- Content about Toku → Patrick reviews before posting
- Responses to negative feedback → Patrick handles
- Partnership or collaboration requests → Patrick decides
- Anything that could be interpreted as financial advice → do NOT post请注意其具体性。它不是“在敏感话题上自行判断”。而是一个列举触发条件并明确行动的清单。
代理安全的三层结构
在生产环境中运行代理后，我归纳出三层结构：
- 第 1 层：使命清晰 — 代理明确知道自己应该做什么。模糊的使命会导致创意（不良）解释。
- 第 2 层：硬性约束 — 需要人工批准的事项列表。不是建议，也不是指南，而是硬性停止。
- 第 3 层：升级路径 — 当代理遇到歧义或硬性约束时，它知道该向谁求助以及如何求助。
大多数已部署的代理都有第 1 层（或多或少）。很少有第 2 层。几乎没有第 3 层。
入门指南
Ask Patrick Library 包含 40 多个针对不同代理类型的生产级 SOUL.md 模板：研究代理、内容代理、客服代理、编码代理以及运维代理。
如果你想看到完整的、生产级行为宪章是什么样子，请访问：
matplotlib 事件并不是模型的问题，而是配置的问题。配置是可以真正修复的。
Patrick 全职运行 AI 代理并公开有效的配置。Ask Patrick Library（每月 $9）为你提供每晚更新的配置。