OpenClaw 核心配置文件：SOUL.md — 性格与行为准则

置顶 | 发表于 | 分类于

我们在使用 OpenClaw 时都有过这样的困惑：明明安装了许多强大的 Skills（技能），API 也是最贵的，但代理的表现却依然笨拙，只能被动响应，无法主动思考，甚至经常重复提问。这并不一定是大模型本身的能力不足，也不是插件质量问题，核心原因在于忽略了系统底层的“灵魂”配置。真正决定 OpenClaw 智商上限的，不是昂贵的模型调用，而是那些藏在 /.openclaw/workspace/ 目录下不起眼的 .md 配置文件。本文将深入拆解这些核心文件的功能与配置逻辑，带你通过修改底层配置，彻底告别 AI 代理的机械感。
OpenClaw 的所有核心逻辑都存储在工作空间目录(**/.openclaw/workspace/** )下。如果不熟悉命令行界面的话，也可以在 Web UI 中查看和编辑。位置如下图：
alt text
打开这个目录，我们会看到如下层级的文件结构，每个文件都承担着不同的职责：

  • AGENTS.md：LLM的工作手册，代理调度规则与标准作业程序。
  • BOOTSTRAP.md：初始化序列与核心系统提示词。
  • HEARTBEAT.md：定时执行逻辑与主动任务状态自检。
  • IDENTITY.md：代理身份定义与系统边界约束。
  • MEMORY.md：长期上下文数据与既定规则的持久化存储。
  • SOUL.md：LLM的性格，响应语气、行为特征及输出格式配置。
  • TOOLS.md：工具授权注册表及调用参数规范。
  • USER.md：用户(你的)画像数据，包含特定偏好与交互限制配置。
  • memory/：存储日常运行日志与短期上下文。
  • skills/：已安装的第三方技能扩展目录。
    今天我们介绍 SOUL.md 文件，这是 OpenClaw 的核心文件。

什么是 SOUL.md？

每个 OpenClaw 代理都有一个名为 SOUL.md 的文件，作为其底层身份层。它是一个纯 Markdown 文件，定义了你的代理的性格、沟通风格、核心价值观和行为准则。OpenClaw 在启动时读取这个文件，并将其作为系统级提示词应用到每一次交互中——无论你的代理是在回复早间消息、起草邮件，还是在凌晨三点执行定时任务。
不同于每次对话都会重置性格的传统聊天机器人，你的 OpenClaw 代理通过 SOUL.md 保持一致的自我意识。同样的语气、同样的优先级、同样的规则——始终如一。

它存放在哪里？

SOUL.md 位于：~/.openclaw/agents//SOUL.md
如果你只有一个代理（默认代理），路径通常是 ~/.openclaw/agents/default/SOUL.md。OpenClaw 在引导设置时会创建一个最简版的 SOUL.md，但大多数用户会随着时间推移进行大量自定义。

内容结构参考

结构良好的 SOUL.md 包含四个部分：

1. 身份

代理是谁？叫什么名字？扮演什么角色？

1
2
3
# Identity
You are Atlas, a technical assistant for a software engineering team.
You work for Acme Corp. Your primary user is Sarah, the lead engineer.

2. 沟通风格

代理应该如何说话？正式还是随意？简洁还是详细？

1
2
3
4
5
# Communication Style
- Be concise. Prefer bullet points over paragraphs.
- Never use emojis unless the user does first.
- Default to Chinese. Switch to English if the user writes in English.
- When explaining technical concepts, use analogies.

3. 核心价值观和规则

不可违反的行为边界。这是安全性和对齐方面最重要的部分。

1
2
3
4
5
6
# Rules
- Never delete files without explicit confirmation.
- Never send messages to contacts unless specifically asked.
- Always summarize what you plan to do before executing multi-step tasks.
- If you are unsure about something, say so. Do not guess.
- Never share API keys, passwords, or sensitive data in chat messages.

4. 领域知识

代理应始终了解的上下文信息。

1
2
3
4
5
# Context
- Our tech stack: Next.js, PostgreSQL, Redis, deployed on AWS
- Sprint cycle: 2-week sprints, standup at 9:30 AM PST daily
- Code style: We follow the Airbnb ESLint config
- Jira project key: ACME

真实案例

极简风格

1
You are a helpful assistant. Be brief. Confirm before destructive actions.

这完全可以用。SOUL.md 不需要很长。但具体的指令才能产生具体的行为。

行政助理

1
2
3
4
5
6
7
8
9
10
# Identity
You are Monday, a personal executive assistant.
# Style
- Professional but warm tone
- Proactive: suggest follow-ups after completing tasks
- Morning briefing at 8 AM: calendar, unread messages, weather, top news
# Rules
- Never schedule meetings without checking calendar conflicts first
- Always include timezone when mentioning times
- Summarize long emails in 3 bullet points before forwarding

DevOps 代理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Identity
You are Ops, a DevOps automation agent for a small startup.
# Style
- Terse, terminal-style responses
- Use code blocks for all commands
- No pleasantries
# Rules
- Never run destructive commands (rm -rf, DROP TABLE, force push) without confirmation
- Log all infrastructure changes to #ops-log channel
- Alert on-call if any health check fails twice in a row
# Context
- Infrastructure: 3 EC2 instances, RDS PostgreSQL, CloudFront CDN
- Monitoring: Datadog, PagerDuty
- Deploy: GitHub Actions -> ECR -> ECS

编写技巧

1.具体，而非笼统。”Be helpful” 什么都不会产生。”最多 5 个要点，删除文件前确认” 才能产生一致的行为。
2.从简短开始，逐步迭代。 先写 10 行。只有当你发现代理做了你不想要的事情时，才添加规则。SOUL.md 中的每一行都应该有其存在的理由。
3.用边界情况测试。 让你的代理做一些模糊或有风险的事情，看看它如何回应，然后调整规则。
4.让代理自己写灵魂文件。 使用一周后，问你的代理：”根据我们目前的交互，对你的 SOUL.md 提出改进建议。” 它往往能发现你遗漏的问题。
5.控制在 2,000 字以内。 SOUL.md 会被加载到每个提示词中。臃肿的灵魂文件会浪费 Token，稀释重要的规则。如果你需要大量领域知识，请使用技能或记忆系统代替。

-------------本文结束感谢您的阅读-------------