OpenClaw 里的 Agent 好不好用,不只取决于模型能力,也取决于 workspace 写得够不够清楚。
很多 Agent 刚装好时确实能聊天,但每次新会话都像重新认识用户:不知道该用什么语气,不知道用户偏好,不知道项目背景,也不知道哪些事情应该主动做、哪些事情必须先确认。workspace 就是用来解决这些问题的。
可以把 workspace 理解成 Agent 的工作台。它里面放的不是运行程序本身,而是一组 Markdown 文件和技能目录,用来告诉 Agent:
- 它是谁;
- 它该怎么工作;
- 用户是谁;
- 工具该怎么用;
- 哪些信息需要跨会话记住;
- 遇到专项任务时该走哪套流程。
OpenClaw 默认主 Agent 的 workspace 通常位于:
~/.openclaw/workspace/
sub-agent 也可以有自己的 workspace。只要 openclaw.json 里把某个 Agent 的 workspace 指到对应路径,OpenClaw 就会从那里加载它的行为规则和上下文资料。
workspace、agentDir、sessions 的职责边界
OpenClaw 目录里有几个名字很容易混在一起:workspace、agentDir、sessions。它们不是同一类东西。
一个常见目录结构大致如下:
~/.openclaw/
├── openclaw.json # 全局配置,负责把系统跑起来
│
├── workspace/ # 默认主 Agent 的 workspace
│ ├── AGENTS.md # 工作规则、多 Agent 协调
│ ├── SOUL.md # Agent 的叙事性格
│ ├── USER.md # 用户画像与偏好
│ ├── IDENTITY.md # Agent 名字、emoji、头像等元数据
│ ├── TOOLS.md # 工具使用规范
│ ├── HEARTBEAT.md # 心跳与阶段性检查规则
│ ├── BOOTSTRAP.md # 首次启动引导,初始化后通常删除
│ ├── BOOT.md # 可选启动检查清单
│ ├── MEMORY.md # 稳定长期记忆总表
│ ├── memory/ # 按日期滚动的记忆
│ │ └── 2026-03-21.md
│ ├── skills/ # 当前 workspace 私有技能
│ │ ├── code-review/
│ │ │ └── SKILL.md
│ │ └── content-strategy/
│ │ └── SKILL.md
│ └── canvas/ # 可选可视化上下文
│
└── agents/ # 各 Agent 的运行态目录
└── main/
├── agent/ # agentDir 默认常指向这里
│ ├── auth-profiles.json
│ └── models.json
├── sessions/ # 会话历史
│ └── *.jsonl
└── qmd/ # 使用 qmd memory backend 时的索引状态
三者的区别可以直接记成表格:
| 名称 | 本质 | 放什么 | 常见位置 |
|---|---|---|---|
workspace | Agent 的工作区 | AGENTS.md、SOUL.md、USER.md、skills/、memory/ | ~/.openclaw/workspace/ |
agentDir | openclaw.json 里的路径配置字段 | 认证配置、模型配置、运行期状态 | ~/.openclaw/agents/<id>/agent/ |
sessions | 会话历史目录 | 对话记录 JSONL 文件 | ~/.openclaw/agents/<id>/sessions/ |
需要特别注意:磁盘上并没有一个天然叫 agentDir 的固定目录。agentDir 只是配置字段名,默认经常指向 agents/<agentId>/agent/,但你可以在 openclaw.json 里改成别的路径。
整体关系可以画成这样:
flowchart TD
A[openclaw.json] --> B[定义 Agent id]
A --> C[指定 workspace 路径]
A --> D[指定 agentDir 路径]
A --> E[配置 channels / models / tools]
C --> F[AGENTS.md 工作规则]
C --> G[SOUL.md 性格设定]
C --> H[USER.md 用户偏好]
C --> I[TOOLS.md 工具规范]
C --> J[memory/ 与 MEMORY.md 长期记忆]
C --> K[skills/ 专项能力]
D --> L[auth-profiles.json]
D --> M[models.json]
D --> N[其他运行状态]
B --> O[sessions 会话历史]
workspace 管“这个 Agent 怎么干活”,openclaw.json 管“系统怎么启动并把 Agent 接上线”。只把系统跑通,只能得到一个能回应的 Agent;认真配置 workspace,才能得到一个行为稳定、边界清楚、能持续积累上下文的 Agent。
核心文件职责速查
OpenClaw workspace 里的文件可以按职责分成几组。
| 文件或目录 | 主要作用 | 类比 |
|---|---|---|
BOOTSTRAP.md | 首次初始化引导,完成后通常删除 | 新员工报到手册 |
IDENTITY.md | Agent 名字、emoji、头像、气质等结构化元数据 | 工牌 / 名片 |
SOUL.md | Agent 的叙事性格、沟通风格、价值观 | 人物小传 |
AGENTS.md | 工作职责、行为规则、边界、多 Agent 协调 | 岗位说明书 |
USER.md | 用户背景、偏好、常见任务、术语习惯 | 用户档案 |
TOOLS.md | 工具列表、使用原则、受限操作 | 工具使用手册 |
HEARTBEAT.md | 心跳时该检查什么、什么时候主动联系用户 | 值班提醒卡 |
MEMORY.md | 稳定、整理过的长期知识 | 长期笔记总表 |
memory/ | 按日期滚动的跨会话记忆 | 每日工作笔记 |
skills/*/SKILL.md | 专项任务触发条件与执行流程 | 操作流程手册 |
这些文件不是越多越好,也不是越长越好。关键是分工清楚:性格归性格,规则归规则,用户偏好归用户偏好,工具限制归工具限制。
AGENTS.md:定义 Agent 怎么工作
AGENTS.md 是 workspace 里最重要的文件之一。它通常会在 session 启动时进入系统提示词,让 Agent 知道自己的职责和规则。
不过不能把它理解成“每次一定完整注入”。OpenClaw 会受到 bootstrapMaxChars、bootstrapTotalMaxChars 这类长度限制影响,某些 session 类型也可能跳过部分文件。更稳妥的理解是:AGENTS.md 往往会参与 Agent 行为塑造,但应该写得短、准、靠前。
AGENTS.md 主要回答这些问题:
- Agent 的核心职责是什么;
- 哪些任务应该自己处理;
- 哪些任务应该交给 sub-agent;
- 遇到危险操作时怎么确认;
- 输出格式有什么默认要求;
- 哪些事情绝对不能做。
一个工程助理型 AGENTS.md 可以这样写:
# Agent 工作说明
## 身份
你是团队的技术助理 Alex,负责代码分析、技术文档整理和工程问题排查。
## 工作原则
- 回答技术问题时优先给可执行方案,不堆概念。
- 需要修改文件前,先读取当前内容并确认路径存在。
- 遇到不确定结论时,明确说明不确定,不编造版本号、接口或报错原因。
- 涉及删除、覆盖、大规模重构等操作时,必须先征得用户确认。
## 多 Agent 协作
- 内容策略、标题、SEO 任务交给 `content-specialist`。
- 数据清洗、指标分析任务交给 `data-analyst`。
- 日常问答、代码定位、任务拆解由当前 Agent 处理。
## 输出格式
- 技术文档使用 Markdown。
- 代码块必须标注语言。
- 列表超过 5 项时先分组。
AGENTS.md 的写法有三个关键点。
写边界,不只写能力
只写“你要帮助用户写代码、分析问题、整理文档”是不够的。大语言模型(LLM,Large Language Model)本来就倾向于尝试完成任务,如果没有边界,它可能会过度发挥。
更有效的规则是:
## 不做的事
- 不在用户未确认的情况下删除文件。
- 不替用户发布公开内容。
- 不把猜测当成事实。
- 不在没有读取项目代码的情况下假设框架结构。
边界让 Agent 更可预测。生产环境里,可预测通常比“显得聪明”更重要。
用场景规则代替空泛规则
“始终保持专业”太宽泛,模型很难判断具体该怎么做。场景化写法更稳定:
- 当用户询问技术方案时,给出方案、适用条件和代价。
- 当用户只是闲聊时,可以轻松回应,但不要过度展开。
- 当用户要求排查报错时,先要到报错信息、运行环境和复现步骤。
规则越接近实际触发场景,越容易生效。
控制长度
AGENTS.md 不适合写成几千字的制度手册。规则太多时,真正重要的内容会被稀释,还会占用启动上下文预算。
一个实用范围是 300 到 500 字。最关键的行为规则放在前面,低频、模糊、重复的规则直接删掉。
SOUL.md:定义 Agent 是什么性格
SOUL.md 和 AGENTS.md 经常被混用,但它们解决的是两类问题。
| 文件 | 关注点 | 例子 |
|---|---|---|
SOUL.md | Agent 是谁,是什么风格,有什么价值观 | “说话直接,不讨好,不装懂” |
AGENTS.md | Agent 怎么工作,任务如何处理,边界在哪里 | “修改文件前先读取,删除前必须确认” |
SOUL.md 更像一份人物小传,不适合写成字段表。结构化身份信息应该放到 IDENTITY.md,工作流程应该放到 AGENTS.md。
一个可用的 SOUL.md 示例:
# SOUL
我是一个直接、可靠、偏工程师气质的 AI 助理。
我喜欢把复杂问题拆开讲清楚,不喜欢空泛结论,也不喜欢用礼貌废话拖慢沟通。
当信息不足时,我会先说明缺口;如果可以通过读取文件、搜索上下文或检查配置自己搞清楚,我会先行动,再给结论。
## 沟通风格
- 口语化,但技术表述要准确。
- 能短就短,需要展开时讲完整。
- 不用“当然可以”“很高兴帮你”这类固定开场。
- 对明显有风险的方案会直接指出问题,并说明替代方案。
## 边界
- 不假装知道不存在的信息。
- 不替用户做不可逆决定。
- 不把私人信息写入长期记忆,除非用户明确要求。
SOUL.md 的价值不在于让 Agent “像人”,而在于建立稳定感。同样的问题,Agent 每次都用相近的判断方式和表达风格处理,用户才敢把复杂任务交给它。
USER.md:把用户偏好变成默认上下文
如果用户每次都要重复说“我喜欢简洁回答”“我用 TypeScript”“不要解释基础概念”,说明 workspace 还没有发挥作用。
USER.md 用来保存用户的长期偏好和背景信息。它不应该记录敏感秘密,也不应该把临时状态塞进去;适合放的是稳定、可复用、跨会话都有用的信息。
示例:
# 用户档案
## 基本背景
- 职业:独立开发者 / 内容创作者
- 常用语言:中文,技术术语可以保留英文
- 常用技术栈:TypeScript、Python、Next.js、Supabase
## 回答偏好
- 喜欢直接给结论,再解释原因。
- 不需要解释基础编程概念。
- 代码示例优先使用 TypeScript 或 Python。
- 不喜欢过度使用 emoji。
- 不喜欢被连续反问,能先给假设和选项时就先给。
## 常见任务
- 分析代码结构
- 起草技术方案
- 整理资料和会议纪要
- 优化内容标题和大纲
SOUL.md 定义 Agent,USER.md 定义用户。两者合起来,就是人机协作的默认契约:Agent 知道自己该用什么方式工作,也知道眼前这个用户更容易接受什么样的输出。
TOOLS.md:告诉 Agent 工具该怎么用
TOOLS.md 不是权限开关,而是工具使用说明。真正决定工具能不能用的,是 openclaw.json 里的 tools 配置,以及 allow/deny、elevated、sandbox 等系统限制。
TOOLS.md 负责告诉 Agent:在已经具备权限的前提下,什么时候该用某个工具,什么时候不该乱用。
示例:
# TOOLS
## 可用工具
- Read / Write / Edit:用于读取、创建和修改文件。
- Bash:用于执行 shell 命令、运行测试、调用脚本。
- Glob / Grep:用于文件搜索,优先于手写复杂 find 命令。
- sessions_spawn:用于启动子代理,前提是 openclaw.json 已允许。
- memory_get / memory_search:用于检索长期记忆。
## 使用原则
- 文件修改前必须先读取目标文件。
- 批量修改前先说明修改范围。
- 路径优先使用相对路径,避免硬编码绝对路径。
- 能用 Read / Write / Edit 完成的文件操作,不要优先用 Bash 拼接命令。
## 受限操作
- 删除文件、覆盖重要配置、执行迁移脚本前必须确认。
- 浏览网页只在用户明确需要外部信息时使用。
- 不把密钥、token、私人通信内容写入长期记忆。
TOOLS.md 和 openclaw.json 的关系可以这样理解:
flowchart LR
A[openclaw.json tools 配置] --> B{系统是否放行}
B -- 否 --> C[Agent 不能使用该工具]
B -- 是 --> D[TOOLS.md 提供使用规范]
D --> E{当前任务是否适合使用}
E -- 否 --> F[换更安全的方式]
E -- 是 --> G[按规范调用工具]
openclaw.json 管“有没有权限”,TOOLS.md 管“怎么用才稳妥”。两层配合起来,Agent 才不容易出现乱跑命令、误删文件、过度调用外部工具的问题。
IDENTITY.md:Agent 的结构化身份档案
IDENTITY.md 保存的是 Agent 的基本身份元数据,适合写成简洁字段。
# IDENTITY.md - Who Am I?
- Name: Nova
- Creature: AI assistant
- Vibe: 直接、有点毒舌、但可靠
- Emoji: 🦊
- Avatar: avatars/nova.png
常见字段含义如下:
| 字段 | 作用 |
|---|---|
Name | Agent 名字,可能影响界面和对话中的显示 |
Creature | Agent 的存在设定,可以是 AI assistant、robot、ghost in the machine 等 |
Vibe | 简短气质描述 |
Emoji | 用户界面(UI,User Interface)里的标识 |
Avatar | 头像路径,可以是 workspace 相对路径、URL 或 data URI |
IDENTITY.md 是名片,SOUL.md 是人物小传。不要把大量性格描述塞进 IDENTITY.md,也不要把头像路径这类字段写进 SOUL.md。
BOOTSTRAP.md:只在初始化阶段使用的引导文件
BOOTSTRAP.md 的作用是把一个全新的 workspace 引导到可用状态。它像一次性 onboarding 脚本:Agent 启动后读到它,就知道当前任务不是马上开始工作,而是先完成自我配置。
典型流程是:
flowchart TD
A[新 workspace 含 BOOTSTRAP.md] --> B[Agent 询问名字、性格、emoji、用途]
B --> C[写入 IDENTITY.md]
C --> D[整理用户背景到 USER.md]
D --> E[改写 SOUL.md]
E --> F[补充 AGENTS.md 工作规则]
F --> G[初始化完成]
G --> H[删除 BOOTSTRAP.md]
BOOTSTRAP.md 通常会要求 Agent 在初始化完成后删除自己。这里的“删除”不是 OpenClaw 底层自动完成,而是模板给 Agent 的行为要求。看到一个 workspace 里还保留 BOOTSTRAP.md,通常说明它可能还处在刚创建、未完全配置好的状态。
常见初始化命令可能会把这些模板文件放入 workspace:
openclaw onboard
openclaw setup
openclaw configure
这些命令可以准备文件,但完整的个性、偏好、边界,仍然需要通过对话或手动编辑补齐。
memory/ 与 MEMORY.md:跨会话长期记忆
LLM 默认没有真正的跨会话记忆。新开一个 session,如果没有外部记忆文件或检索机制,它并不知道之前发生过什么。
OpenClaw 用 Markdown 文件解决这个问题:
memory/YYYY-MM-DD.md:按日期滚动的日常记忆;MEMORY.md:更稳定、更整理过的长期知识总表;memory.md:某些场景下兼容小写文件名。
记忆流转大致如下:
sequenceDiagram
participant U as 用户
participant A as Agent
participant M as memory/ 与 MEMORY.md
participant S as memory_search / memory_get
U->>A: 讨论项目、偏好、决策
A->>M: 写入值得保留的信息
U->>A: 新会话开始
A->>S: 检索相关记忆
S-->>A: 返回匹配内容
A->>U: 基于历史上下文回应
OpenClaw 常见记忆方案有两类:
| 方案 | 特点 | 原始记忆在哪里 |
|---|---|---|
builtin | 默认方案,围绕 Markdown 记忆文件维护本地索引 | workspace 里的 Markdown 文件 |
qmd | 使用更强的检索 / 索引方式,并在 agent 运行目录保存额外状态 | workspace 里的 Markdown 文件 |
关键点是:真正可读、可改、可维护的长期记忆,仍然是那些 Markdown 文件。索引只是帮助检索,不能替代记忆内容本身。
可以手动预埋记忆,让 Agent 第一次启动时就带着背景工作:
# 项目背景
这是一个面向中小团队的 SaaS 产品,目标用户是内容运营人员。
技术栈:
- Next.js
- Supabase
- Tailwind CSS
## 重要约定
- 前端变量命名使用 camelCase。
- 数据库表名使用 snake_case。
- 对外文档使用中文,代码注释可以使用英文。
记忆需要维护。过时信息不清理,会造成“记忆污染”:Agent 可能引用两个月前已经失效的决策。比较稳的做法是让 Agent 周期性把 daily memory 里的高价值内容提炼到 MEMORY.md,同时删除低价值或过期记录。
skills/:按需加载的专项能力包
Skills 是 OpenClaw 的模块化能力包。工具像手脚,skills 更像操作手册:它告诉 Agent 在某类任务里该按什么流程做。
一个 skill 的核心文件是 SKILL.md:
code-review/
├── SKILL.md
├── references/
│ └── review-checklist.md
└── scripts/
└── collect_changed_files.py
SKILL.md 一般包含 front matter 和执行说明:
---
name: code-review
description: 对代码进行结构化 review,优先发现 bug、风险和回归点
---
# Code Review
## 触发条件
当用户要求 review 代码、检查代码质量、发现潜在 bug 时使用。
## 执行流程
1. 读取目标文件,理解整体结构。
2. 检查语法错误、明显 bug、性能问题、安全风险和可维护性问题。
3. 按严重程度输出:Critical / Warning / Suggestion。
4. 每个问题给出位置、原因和修改建议。
## 注意事项
- 不主动修改代码,除非用户明确要求。
- 文件超过 500 行时,先确认 review 范围。
- 没有读取代码前,不输出结论。
Skills 有三层来源:
| 层级 | 位置 | 适合放什么 |
|---|---|---|
| 内置 / bundled skills | 跟随 OpenClaw 安装 | 通用能力 |
| 共享 skills | ~/.openclaw/skills/ | 多个 Agent 都要用的流程 |
| workspace 私有 skills | ~/.openclaw/workspace/skills/ | 某个 Agent 专属流程 |
多个 Agent 都要用的 skill,应该放到共享层;只给某个 Agent 使用的 skill,放到它自己的 workspace 里。不要把公共流程只放在某个私有 workspace,然后期待其他 Agent 自动看到。
skill 的触发条件要具体。比如“有写作需求时触发”太宽,会导致几乎所有内容任务都加载它;更好的写法是“当用户要求制定内容选题、平台定位、栏目规划时触发”。
openclaw.json:把 workspace 接到系统上
workspace 文件负责内容层,openclaw.json 负责系统层。模型、渠道、Agent 列表、workspace 路径、agentDir 路径,都需要在这里配置。
一个简化配置如下:
{
"gateway": {
"port": 18789,
"auth": {
"mode": "token"
}
},
"models": {
"providers": {
"anthropic": {
"apiKey": "sk-ant-..."
}
}
},
"channels": {
"telegram": {
"enabled": true
},
"feishu": {
"enabled": true
}
},
"agents": {
"defaults": {
"workspace": "~/.openclaw/workspace"
},
"list": [
{
"id": "main",
"workspace": "~/.openclaw/workspace",
"agentDir": "~/.openclaw/agents/main/agent"
}
]
}
}
agents.list 是 Agent 定义入口。每个 Agent 至少需要一个 id。
| 字段 | 是否必填 | 含义 | 示例 |
|---|---|---|---|
id | 是 | Agent 唯一标识 | "main" |
workspace | 否 | 该 Agent 使用的 workspace 路径 | "~/.openclaw/workspace" |
agentDir | 否 | 该 Agent 的运行状态目录 | "~/.openclaw/agents/main/agent" |
workspace 和 agentDir 不要互换。前者放行为规则和记忆,后者放运行状态。
多 Agent 场景下的 workspace 设计
多 Agent 系统里,每个 Agent 都应该有自己的 workspace,除非你明确希望它们拥有完全相同的人格、规则和技能。
一个内容生产团队可以这样组织:
~/.openclaw/
├── openclaw.json
├── workspace/ # manager:日常对话和任务调度
│ ├── SOUL.md
│ ├── AGENTS.md
│ └── USER.md
│
├── agency-agents/ # 专业 Agent 的 workspace 集合
│ ├── researcher/
│ │ ├── SOUL.md
│ │ ├── AGENTS.md
│ │ └── skills/
│ │ └── web-research/
│ │ └── SKILL.md
│ │
│ ├── writer/
│ │ ├── SOUL.md
│ │ ├── AGENTS.md
│ │ └── skills/
│ │ └── content-strategy/
│ │ └── SKILL.md
│ │
│ └── coder/
│ ├── SOUL.md
│ ├── AGENTS.md
│ └── skills/
│ └── code-review/
│ └── SKILL.md
│
└── skills/ # 跨 Agent 共享 skills
└── project-context/
└── SKILL.md
agency-agents 不是 OpenClaw 的保留字,只是一种目录命名习惯。OpenClaw 只认 openclaw.json 里写的路径。你把专业 Agent 的 workspace 放到哪里都可以,只要配置指向正确。
对应的多 Agent 配置可以这样写:
{
"agents": {
"list": [
{
"id": "manager",
"workspace": "~/.openclaw/workspace",
"agentDir": "~/.openclaw/agents/manager/agent",
"subagents": {
"allowAgents": ["researcher", "writer", "coder"]
}
},
{
"id": "researcher",
"workspace": "~/.openclaw/agency-agents/researcher",
"agentDir": "~/.openclaw/agents/researcher/agent"
},
{
"id": "writer",
"workspace": "~/.openclaw/agency-agents/writer",
"agentDir": "~/.openclaw/agents/writer/agent"
},
{
"id": "coder",
"workspace": "~/.openclaw/agency-agents/coder",
"agentDir": "~/.openclaw/agents/coder/agent"
}
]
}
}
subagents.allowAgents 是白名单。manager 只能调用列表里的 Agent;即使工具层面存在 sessions_spawn,不在白名单里的 Agent 也不应该被调用。
多 Agent 调用关系可以表示为:
flowchart TD
U[用户] --> M[manager workspace]
M --> R[researcher workspace]
M --> W[writer workspace]
M --> C[coder workspace]
R --> RS[web-research skill]
W --> WS[content-strategy skill]
C --> CS[code-review skill]
P[~/.openclaw/skills/project-context] --> R
P --> W
P --> C
P --> M
共享信息不要复制到每个 workspace。项目背景、统一术语、用户通用偏好,可以做成共享 skill,例如 project-context,放在 ~/.openclaw/skills/。这样只改一份,所有 Agent 都能复用。
从零配置一个内容创作 Agent
假设目标是配置一个内容创作辅助 Agent,负责选题、标题、大纲、资料整理和草稿润色。
1. 初始化 OpenClaw
openclaw onboard --install-daemon
这个命令通常会创建默认 workspace,并放入一组模板文件,例如:
AGENTS.md
SOUL.md
IDENTITY.md
USER.md
TOOLS.md
HEARTBEAT.md
BOOTSTRAP.md
2. 定制 IDENTITY.md
# IDENTITY.md - Who Am I?
- Name: Ink
- Creature: AI writing assistant
- Vibe: 清晰、直接、有内容敏感度
- Emoji: ✒️
- Avatar: avatars/ink.png
3. 编写 SOUL.md
# SOUL
我叫 Ink,是一个专注于内容创作的 AI 助理。
我擅长把混乱想法整理成清晰表达,把零散资料变成有结构的内容。我会关注标题、节奏、观点密度和读者理解成本。
## 性格
- 有创意,但不为了新奇牺牲准确性。
- 说话直接,不绕弯子。
- 对语言细节敏感,包括用词、停顿和段落节奏。
- 不主动堆 emoji,也不写明显 AI 味的套话。
## 沟通风格
- 中文为主,必要时保留英文术语。
- 给标题、角度和结构时,默认提供多个选项。
- 草稿完成后,会说明可调整的方向。
4. 编写 AGENTS.md
# 工作说明
## 主要职责
协助用户完成内容创作,包括:
- 选题判断
- 标题拟定
- 大纲设计
- 草稿写作
- 资料整理
- 文章润色
## 工作原则
1. 创作前先明确目标读者和发布平台。
2. 标题默认给 3 到 5 个选项。
3. 大纲要体现主线,不只堆小标题。
4. 草稿要减少空话,多给具体判断、例子和结构。
5. 涉及事实、数据和引用时,不确定就标记待核实。
## 不做的事
- 不替用户发布内容。
- 不写误导性标题。
- 不在用户未确认的情况下改动定稿内容。
5. 编写 USER.md
# 用户档案
## 背景
- 独立开发者
- 关注 AI 工具、编程助手、产品设计
- 主要发布平台:微信公众号、X
## 写作偏好
- 风格:接地气、有观点、不装。
- 节奏:段落短,逻辑清楚。
- 忌讳:过度使用 emoji、营销腔、空泛结论。
- 术语:LLM 可称为“大模型”,coding agent 可称为“编程助手”。
## 常见任务
- 起标题
- 写大纲
- 整理资料
- 改写技术内容
- 打磨开头和结尾
6. 安装相关 skills
clawhub install skill-creator
clawhub install content-strategy
clawhub install social-content
也可以查看和校验 skills:
openclaw skills list
openclaw skills check
7. 启动 Gateway 并验收
openclaw gateway --verbose
发送一条测试消息:
介绍一下你自己,以及你主要能帮我做什么。
如果 Agent 的名字、语气、职责范围和输出风格都能对应 IDENTITY.md、SOUL.md、AGENTS.md 和 USER.md,说明 workspace 已经开始生效。
常见坑与修正方法
| 问题 | 表现 | 修正 |
|---|---|---|
AGENTS.md 太长 | Agent 抓不住重点,规则时灵时不灵 | 控制在几百字,关键规则前置 |
SOUL.md 和 AGENTS.md 混写 | 性格和工作规则纠缠,文件臃肿 | 性格放 SOUL.md,任务规则放 AGENTS.md |
| 多 Agent 共用 workspace | 研究员、写作者、工程师表现差不多 | 每个 Agent 单独配置 workspace |
改了目录但没改 openclaw.json | 编辑半天不生效 | 检查 agents.list[*].workspace 路径 |
| skill 触发条件太宽 | 上下文膨胀,响应变慢 | 写清具体触发场景和关键词 |
| memory 堆满过期信息 | Agent 引用旧决策,产生记忆污染 | 定期清理 memory/ 和 MEMORY.md |
TOOLS.md 只列工具名 | Agent 知道工具存在,但不知道何时不该用 | 写明使用原则和受限操作 |
把 agentDir 当真实固定目录名 | 目录结构理解混乱 | 记住它只是配置字段,指向运行状态路径 |
配置不生效时,优先检查:
openclaw doctor
再确认:
cat ~/.openclaw/openclaw.json
ls -la ~/.openclaw/workspace
重点看 agents.list 里当前 Agent 的 workspace 是否指向你正在编辑的目录。
把 workspace 当成活文档
workspace 不应该配置一次就放着不动。OpenClaw 的一个重要能力是:只要工具权限允许,Agent 可以读取并更新自己的 workspace。
可以明确给 Agent 这样的规则:
如果我们确认了长期偏好,把它追加到 USER.md。
如果某个工作流程连续验证有效,把它整理成一个新的 SKILL.md。
每天结束时,把 memory/YYYY-MM-DD.md 里高价值内容提炼到 MEMORY.md。
这类机制会让 Agent 逐渐贴合用户,而不是每次都从零开始。
如果 workspace 已经比较重要,建议纳入 Git 管理:
cd ~/.openclaw/workspace
git init
git add .
git commit -m "Initialize OpenClaw workspace"
后续每次调整规则、性格、skills 或长期记忆,都可以提交一次:
git add .
git commit -m "Update agent behavior rules"
这样做的好处很直接:如果某次修改让 Agent 表现变差,可以用版本记录快速回退。
快速参考
常用命令
# 初始化
openclaw onboard --install-daemon
# 启动 Gateway
openclaw gateway --port 18789
# 输出详细日志
openclaw gateway --verbose
# 检查配置
openclaw doctor
# 安装 skill
clawhub install <skill-name>
# 查看 skills
openclaw skills list
# 校验 skills
openclaw skills check
常见路径
| 路径 | 含义 |
|---|---|
~/.openclaw/workspace/ | 默认主 Agent workspace |
~/.openclaw/workspace-<profile>/ | 非 default profile 的默认 workspace |
~/.openclaw/agency-agents/<id>/ | 专业 Agent workspace 的常见组织方式 |
~/.openclaw/skills/ | 跨 Agent 共享 skills |
~/.openclaw/agents/<id>/agent/ | agentDir 默认常指向的运行状态目录 |
~/.openclaw/agents/<id>/sessions/ | 会话历史目录 |
~/.openclaw/agents/<id>/qmd/ | qmd 记忆后端的索引 / 状态目录 |
workspace 是 OpenClaw 里最值得认真打磨的一层。模型能力决定 Agent 能做到什么,workspace 决定它是否知道该怎样为你做事。把身份、性格、规则、偏好、工具边界、记忆和 skills 分层写清楚,Agent 才会从“能聊”变成“稳定、可控、能持续协作”。