OpenClaw Agent 的 8 个配置文件，到底分别干什么？

很多人以为创建一个 Agent，就是：

选个大模型，再写一段 Prompt。

其实一个真正能工作的 Agent，至少要解决八类问题：

我是谁？怎么说话？能用什么工具？会什么技能？记住什么？会话怎么管理？消息怎么路由？用哪个模型？

在我们这套 Workspace 架构里，可以把它们拆成 8 个配置文件：

Agent Workspace
│
├── AGENTS.md      # 核心规则
├── SOUL.md        # 人格与风格
├── TOOLS.json     # 工具权限
├── SKILLS.json    # Skills 配置
├── MEMORY.json    # 长期记忆
├── SESSION.json   # 会话管理
├── ROUTER.json    # 消息路由
└── CONFIG.json    # 模型等基础配置

不要死记文件名，重点理解：

这 8 个配置共同回答“这个 Agent 到底应该如何工作”。

---

01、AGENTS.md：Agent 的总说明书

这是最值得重点理解的文件。

可以把它理解成 Agent 的：

岗位说明书 + 工作手册 + 行为规范。

里面重点描述：

Agent 是谁
    ↓
负责什么
    ↓
收到任务后怎么处理
    ↓
可以做什么
    ↓
不能做什么
    ↓
什么时候使用工具
    ↓
遇到异常怎么办

例如代码审核 Agent：

# Role

你是一名高级代码审核工程师。

# Responsibilities

- 检查代码质量
- 查找潜在 Bug
- 检查安全风险
- 提供修改建议

# Rules

- 不直接修改生产代码
- 不执行高风险命令
- 不确定的信息必须明确说明

所以：

AGENTS.md 决定 Agent“怎么干活”。

---

02、SOUL.md：Agent 的灵魂

AGENTS.md 规定怎么干活，SOUL.md 则决定：

这个 Agent 是个什么“性格”的人。

例如：

语气
→ 专业 / 幽默 / 简洁 / 耐心

沟通方式
→ 先给结论再解释
→ 还是循序渐进教学

行为倾向
→ 谨慎
→ 主动
→ 保守
→ 高效率

价值取向
→ 安全优先
→ 准确优先
→ 用户体验优先

比如同样是程序员 Agent：

SOUL A
→ 像资深架构师
→ 简洁直接
→ 不讲废话

SOUL B
→ 像编程老师
→ 非常耐心
→ 每一步都解释原因

底层可能使用完全相同的模型，但最终体验完全不同。

所以：

SOUL.md 决定 Agent“以什么性格干活”。

---

03、TOOLS.json：Agent 能使用什么工具

LLM 只是“大脑”。

真正想操作现实世界，需要 Tools。

例如：

Shell
Browser
HTTP API
Database
文件系统
搜索工具

但不是每个 Agent 都应该拥有全部权限。

例如客服 Agent：

允许：
✓ 查询订单
✓ 查询物流

禁止：
✗ Shell
✗ 删除数据库
✗ 修改服务器

所以 TOOLS.json 的核心思想就是：

控制 Agent 的工具能力边界。

可以理解成给员工发钥匙：

需要哪把钥匙就给哪把，不需要的绝对不给。

---

04、SKILLS.json：Agent 会什么专业技能

Tool 和 Skill 很容易搞混。

记住：

Tool
= 一个具体工具

Skill
= 一套完成某类任务的方法

例如：

Browser
= Tool

“竞品调研”
= Skill

竞品调研这个 Skill 可能告诉 Agent：

第一步：搜索竞品
第二步：收集官网信息
第三步：提取价格
第四步：整理功能
第五步：生成对比报告

然后在执行过程中调用 Browser、Search 等 Tool。

所以：

TOOLS 决定“手里有什么工具”，SKILLS 决定“会用这些工具干什么”。

---

05、MEMORY.json：Agent 应该记住什么

Memory 解决的是：

跨对话以后，哪些信息还值得记住？

例如：

用户长期偏好
项目技术栈
业务规则
重要决策
长期有效事实

Memory 配置关注的核心通常是：

什么值得保存？
       ↓
怎么保存？
       ↓
什么时候检索？
       ↓
检索哪些内容？
       ↓
什么时候更新/遗忘？

重点不是：

什么都记。

而是：

只保留以后真正有价值的信息。

---

06、SESSION.json：当前这场对话怎么管理

Session 和 Memory 不一样。

可以这样区分：

SESSION
= 我们现在聊到哪里了？

MEMORY
= 以后有哪些事情值得记住？

Session 管的是当前会话生命周期和上下文，例如：

当前聊天历史
      ↓
上下文越来越长
      ↓
是否需要 Compaction
      ↓
哪些历史继续保留
      ↓
什么时候结束 Session

因此：

SESSION 管当前对话，MEMORY 管长期记忆。

---

07、ROUTER.json：消息应该交给谁

当系统只有一个 Agent 时，路由问题不明显。

但如果有：

Code Agent
Ops Agent
Customer Agent
Finance Agent

就必须回答：

这条消息到底应该给谁？

Router / bindings 这一层负责根据消息来源和规则进行匹配：

飞书消息
   ↓
来自哪个应用？
   ↓
来自哪个群？
   ↓
来自哪个用户？
   ↓
匹配路由规则
   ↓
找到 Agent

例如：

研发群
→ Code Agent

运维群
→ Ops Agent

客服群
→ Customer Agent

所以：

ROUTER 解决的是“谁来干这件事”。

---

08、CONFIG.json：Agent 的基础运行配置

最后还有一些不属于人格、工具、Memory 的基础配置。

例如：

使用哪个 LLM
模型参数
Provider
运行参数
其他基础设置

可以把 CONFIG.json 理解成：

Agent 的运行参数面板。

特别提醒一点：

API Key 等敏感凭证不建议直接明文硬编码进普通配置文件并提交 Git。

生产环境应该通过环境变量、Secret 管理等方式处理。

---

八个文件到底是什么关系？

现在把它们串起来：

                    AGENTS.md
                   “怎么干活”
                       │
       ┌───────────────┼───────────────┐
       ↓               ↓               ↓
    SOUL.md         TOOLS.json      SKILLS.json
   “什么性格”       “能用什么”       “会干什么”
       │               │               │
       └───────────────┼───────────────┘
                       ↓
                    Agent
                       │
            ┌──────────┼──────────┐
            ↓          ↓          ↓
        MEMORY      SESSION     ROUTER
        长期记忆     当前会话     消息路由
                       │
                       ↓
                   CONFIG
                  运行基础配置

其实八个文件分别回答八个问题：

配置	回答的问题
AGENTS.md	我应该怎么工作？
SOUL.md	我是一个什么性格的人？
TOOLS.json	我能使用什么工具？
SKILLS.json	我会哪些专业能力？
MEMORY.json	长期应该记住什么？
SESSION.json	当前对话怎么维护？
ROUTER.json	消息应该交给谁？
CONFIG.json	我使用什么基础运行配置？

---

Agent 启动时，这 8 个配置怎么工作？

这才是这一篇最重要的地方。

不要把它们理解成：

8 个文件摆在那里等着看。

真正要理解的是 Agent 初始化 → 执行 → 保存状态 的过程。

可以抽象成：

              用户消息到达
                    ↓
               Gateway
                    ↓
             找到目标 Agent
                    ↓
          ┌─────────────────┐
          │ ① 加载基础配置   │
          │ CONFIG          │
          └────────┬────────┘
                   ↓
          ┌─────────────────┐
          │ ② 建立 Agent规则 │
          │ AGENTS + SOUL   │
          └────────┬────────┘
                   ↓
          ┌─────────────────┐
          │ ③ 加载能力       │
          │ TOOLS + SKILLS  │
          └────────┬────────┘
                   ↓
          ┌─────────────────┐
          │ ④ 恢复上下文     │
          │ SESSION + MEMORY│
          └────────┬────────┘
                   ↓
              Agent Loop
                   ↓
          Think → Tool → Result
                   ↓
             生成最终回答
                   ↓
             保存必要状态
                   ↓
               Gateway
                   ↓
                 用户

而 ROUTER 更靠前，它解决的是：

消息来了
   ↓
应该启动/调度哪个 Agent？

找到 Agent 之后，才轮到 Agent 自己的配置和能力参与执行。

---

一条真实消息进来，会发生什么？

比如用户在飞书里说：

“帮我检查一下这个项目有没有安全漏洞。”

整个过程就可以理解成：

① 飞书
用户发送消息

        ↓

② Gateway
接收消息

        ↓

③ Router / Bindings
判断应该交给 Code Agent

        ↓

④ CONFIG
确定模型和运行配置

        ↓

⑤ AGENTS.md
知道自己的职责是代码审核

        ↓

⑥ SOUL.md
按照高级工程师的方式回答

        ↓

⑦ SESSION + MEMORY
读取当前项目上下文和必要历史信息

        ↓

⑧ SKILLS
加载代码审核相关能力

        ↓

⑨ TOOLS
读取代码 / 搜索 / 执行允许的检查工具

        ↓

⑩ Agent Loop

思考
 ↓
调用工具
 ↓
读取结果
 ↓
继续分析
 ↓
必要时再次调用工具
 ↓
生成结论

        ↓

⑪ SESSION / MEMORY
保存必要的会话状态和重要信息

        ↓

⑫ Gateway
把结果返回飞书

这时候，OpenClaw 的 Agent 就不再是一个很玄乎的概念了。

---

最后，用“公司员工”记住这 8 个配置

这是最好记的方法：

AGENTS.md
= 岗位说明书

SOUL.md
= 性格

TOOLS.json
= 公司给你的工具和权限

SKILLS.json
= 你的专业技能

MEMORY.json
= 长期工作笔记

SESSION.json
= 当前会议记录

ROUTER.json
= 公司派单系统

CONFIG.json
= 电脑和工作环境配置

于是一个 Agent 就完整了：

AGENTS 定规则，SOUL 定人格，TOOLS 定权限，SKILLS 定能力，MEMORY 管长期记忆，SESSION 管当前上下文，ROUTER 管任务分发，CONFIG 管基础运行配置。

而当消息真正进来以后，它们不是各干各的，而是共同组成：

路由 → 初始化 → 加载规则 → 恢复上下文 → 加载能力 → Agent Loop → 工具执行 → 保存状态 → 返回结果

这才是理解 OpenClaw Agent 配置架构的关键。