芥末
发布于 2026-03-21 / 0 阅读
0
0

OpenClaw Workspace 深度配置指南:让 Agent 从能启动到稳定好用

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 目录里有几个名字很容易混在一起:workspaceagentDirsessions。它们不是同一类东西。

一个常见目录结构大致如下:

~/.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 时的索引状态

三者的区别可以直接记成表格:

名称本质放什么常见位置
workspaceAgent 的工作区AGENTS.mdSOUL.mdUSER.mdskills/memory/~/.openclaw/workspace/
agentDiropenclaw.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.mdAgent 名字、emoji、头像、气质等结构化元数据工牌 / 名片
SOUL.mdAgent 的叙事性格、沟通风格、价值观人物小传
AGENTS.md工作职责、行为规则、边界、多 Agent 协调岗位说明书
USER.md用户背景、偏好、常见任务、术语习惯用户档案
TOOLS.md工具列表、使用原则、受限操作工具使用手册
HEARTBEAT.md心跳时该检查什么、什么时候主动联系用户值班提醒卡
MEMORY.md稳定、整理过的长期知识长期笔记总表
memory/按日期滚动的跨会话记忆每日工作笔记
skills/*/SKILL.md专项任务触发条件与执行流程操作流程手册

这些文件不是越多越好,也不是越长越好。关键是分工清楚:性格归性格,规则归规则,用户偏好归用户偏好,工具限制归工具限制。

AGENTS.md:定义 Agent 怎么工作

AGENTS.md 是 workspace 里最重要的文件之一。它通常会在 session 启动时进入系统提示词,让 Agent 知道自己的职责和规则。

不过不能把它理解成“每次一定完整注入”。OpenClaw 会受到 bootstrapMaxCharsbootstrapTotalMaxChars 这类长度限制影响,某些 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.mdAGENTS.md 经常被混用,但它们解决的是两类问题。

文件关注点例子
SOUL.mdAgent 是谁,是什么风格,有什么价值观“说话直接,不讨好,不装懂”
AGENTS.mdAgent 怎么工作,任务如何处理,边界在哪里“修改文件前先读取,删除前必须确认”

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.mdopenclaw.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

常见字段含义如下:

字段作用
NameAgent 名字,可能影响界面和对话中的显示
CreatureAgent 的存在设定,可以是 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

字段是否必填含义示例
idAgent 唯一标识"main"
workspace该 Agent 使用的 workspace 路径"~/.openclaw/workspace"
agentDir该 Agent 的运行状态目录"~/.openclaw/agents/main/agent"

workspaceagentDir 不要互换。前者放行为规则和记忆,后者放运行状态。

多 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.mdSOUL.mdAGENTS.mdUSER.md,说明 workspace 已经开始生效。

常见坑与修正方法

问题表现修正
AGENTS.md 太长Agent 抓不住重点,规则时灵时不灵控制在几百字,关键规则前置
SOUL.mdAGENTS.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 才会从“能聊”变成“稳定、可控、能持续协作”。


评论