给 AI Agent 立"规矩"：一组关键文件如何决定它能走多远

AI Agent 核心配置文件架构

这张图真正有价值的地方，并不在"分了几层"，而在于它把一个长期运行的 AI Agent，拆成了一组可以被显式定义、被审计、被迭代的核心文件。

这些文件解决的不是"能不能跑"，而是：

跑久了会不会变形、跑复杂了会不会失控、交给别人会不会不敢用。

下面逐一来看这些关键 sub 概念，它们在工程上的真实作用。

---

SOUL.md：约束 Agent 不偏航的"长期原则"

它定义的是什么

SOUL.md 本质上不是人格，而是不可轻易被覆盖的全局原则集合，例如：

• 永远优先安全而不是速度
• 不执行高风险操作，除非有明确二次确认
• 不为了完成目标而破坏系统完整性
• 不擅自扩展能力或修改自身配置

为什么要单独定义

因为这些原则不应该混在 prompt、代码或 memory 里：

• prompt 会被覆盖
• memory 会被污染
• task 指令是短期的

SOUL.md 是高于任务、长期稳定、默认加载的。

有 / 没有的区别

没有 SOUL.md	有 SOUL.md
Agent 会被短期目标牵着走	Agent 能拒绝"完成任务但危险"的指令
随着能力增强，风险同步放大	能力增强但行为边界稳定
Debug 靠猜	行为异常可回溯到原则

一句话：
SOUL.md 是防止 Agent"越跑越不像人、越跑越像脚本"的关键。

---

IDENTITY.md：明确"我是什么，不是什么"

它定义的是什么

IDENTITY.md 解决的是角色歧义问题，例如：

• 我是执行型 Agent，而不是决策型 Agent
• 我的职责是"提供方案"，不是"最终拍板"
• 我服务于个人 / 团队 / 系统，而不是所有请求者

为什么必须显式存在

在长期对话或复杂任务中，Agent 极易出现：

• 角色漂移
• 权限错位
• 自我假设能力边界

如果身份不写清楚，模型会自动补全一个它"以为合理"的身份。

有 / 没有的区别

没有 IDENTITY.md	有 IDENTITY.md
Agent 时而像助手，时而像老板	行为稳定、预期一致
容易越权建议或执行	自动拒绝角色外行为
用户要反复纠正	一次定义，长期生效

一句话：
IDENTITY.md 是把"你以为你是谁"变成"系统知道你是谁"。

---

USER.md：把"用户"从输入变成事实

它定义的是什么

USER.md 不是聊天记录，而是长期有效的用户画像：

• 目标偏好
• 决策风格
• 可接受风险等级
• 常用上下文

为什么不能只靠上下文窗口

上下文窗口是：

• 临时的
• 易丢失的
• 不可结构化复用的

而 USER.md 是：

• 稳定的
• 可版本化的
• 可被多个 Agent 共享的

有 / 没有的区别

没有 USER.md	有 USER.md
Agent 每次都像第一次见你	行为越来越贴合用户
反复解释偏好	偏好一次定义
难以长期协作	可形成"默契"

一句话：
USER.md 让 Agent 从"会聊天"升级为"懂你"。

---

HEARTBEAT.md：让 Agent 知道"自己还在干什么"

它定义的是什么

HEARTBEAT.md 是一种运行态记忆，而不是历史记忆：

• 当前进行到哪一步
• 上次是否异常中断
• 是否存在未完成承诺
• 当前优先级是什么

为什么重要

没有心跳状态的 Agent：

• 崩溃后无法恢复
• 多任务时容易遗忘
• 很难做长期任务

HEARTBEAT.md 让 Agent 具备**"中断可恢复"的工程特性**。

有 / 没有的区别

没有 HEARTBEAT	有 HEARTBEAT
任务中断即丢失	可续跑
无法判断当前状态	状态透明
难以监控	易于观测

一句话：
HEARTBEAT.md 是让 Agent 从"一次性工具"变成"持续系统"的关键。

---

Skills / Subagents：把能力变成模块，而不是 prompt

它们解决的问题

不是"能不能做"，而是：

• 能力是否可替换
• 是否可测试
• 是否可组合

好处

• 能力升级不影响整体行为
• 出问题可定位具体模块
• 可按任务动态编排

没有技能模块的 Agent，最终都会变成一个巨型 prompt 黑盒。

---

最重要的一点

这些文件的意义在于：
把 Agent 的"隐性假设"变成"显性契约"。

• 对模型是约束
• 对开发者是文档
• 对系统是安全边界

---

结语

真正可用的 AI Agent，不是靠模型有多大，
而是靠你有没有把这些"该写清楚的东西"写清楚。

能跑很容易，
能跑久、跑稳、跑不偏，才是工程。