我第一次用 OpenClaw 的时候，配完 SOUL.md 和 USER.md 就觉得"齐活了"。AI 能聊天、能搜索、能帮我写代码，还要啥自行车？

直到有一天，我跟它深度讨论了两个小时的项目方案，它突然开始重复问我之前聊过的问题。那一刻我意识到——这玩意的潜力我可能只用了三成。

后来花了大概一周时间，把 AGENTS.md、记忆系统、子 Agent、Cron 定时任务、Skill 这些全折腾了一遍。现在它能自己发早报、自己整理笔记、同时帮我跑好几个任务，完全是另一个物种。

这篇文章把我踩过的坑和摸索出来的经验全写下来了。内容比较长，建议收藏慢慢看。

开始之前：你需要准备什么

这不是入门教程。往下看之前，确认你已经：

• ✅ OpenClaw 装好了，能正常跑
• ✅ SOUL.md、USER.md、IDENTITY.md 都配好了
• ✅ 知道 MEMORY.md 和 memorySearch 是干嘛的
• ✅ 会基本的命令行操作
• ✅ 至少有一个 AI 模型的 API Key（Claude 或 GPT）

如果还没到这一步，先去搞定基础配置再回来。

第一步：给你的 AI 写一份"员工手册"

SOUL.md 告诉 AI"你是谁"，USER.md 告诉它"我是谁"。但没人告诉它怎么干活。

这就是 AGENTS.md 的作用——一份完整的工作流程手册。没有它，你的 AI 每次开新会话都像第一天上班的实习生，不知道该先干嘛。

启动流程：每次醒来先做什么

OpenClaw 每次新会话都是"失忆"状态，需要通过读文件来恢复记忆。你得告诉它启动时按什么顺序读：

## Every Session

Before doing anything else:

1. Read `SOUL.md` — this is who you are
2. Read `USER.md` — this is who you're helping
3. Read `memory/YYYY-MM-DD.md` (today + yesterday) for recent context
4. **If in MAIN SESSION**: Also read `MEMORY.md`

Don't ask permission. Just do it.

几个细节说一下：

• 步骤 1-2 每次都读，这俩文件通常不到 1KB，零负担
• 步骤 3 读今天和昨天的日志。为什么要读昨天的？因为如果现在是凌晨 1 点，今天的日志可能还是空的
• 步骤 4 MEMORY.md 只在主会话加载。因为里面可能有敏感信息（API Key、服务器配置之类的），群聊或子 Agent 会话不应该看到

OpenClaw 支持好几种会话类型：主会话（你直接跟它聊）、群聊会话、子 Agent 会话、Cron 会话。AI 会自动识别当前是哪种，你只需要在 AGENTS.md 里定义规则就行。

记忆规范：日志怎么写才有用

这个太重要了。日志写得好不好，直接决定了 memorySearch 能不能找到东西。

先看一个反面教材：

今天搞了 nginx，还有数据库的事，另外邮件也处理了一下

这种日志等于没写。三个不相关的事混在一起，搜什么都搜不准。

再看正确的写法：

【运维】nginx 反向代理配置完成
- 结果：成功部署，支持 WebSocket
- 关键配置：proxy_pass 指向 upstream，添加 WebSocket headers
- 相关文件：/etc/nginx/sites-available/app.conf
- 经验教训：proxy_set_header Upgrade 必须加，不然 WS 连不上
- 检索标签：#nginx #部署 #反向代理 #websocket

区别在哪？

1. 单一主题——一条日志只记一件事，向量表示更准确
2. 信息密度高——标题、结果、标签都包含关键词
3. 带标签——#nginx #部署 这些标签能显著提升 memorySearch 的召回率

安全边界：哪些事能做，哪些要问

## Safety

**Safe to do freely:**
- Read files, explore, organize, learn
- Search the web
- Work within this workspace

**Ask first:**
- Sending emails, tweets, public posts
- Anything that leaves the machine
- Deleting files (use `trash` instead of `rm`)
- Anything you're uncertain about

原则很简单：读操作随便来，写操作看情况，对外操作必须问。特别是发邮件、发推这种不可逆的，一定要确认。

第二步：解决"聊着聊着就失忆"的问题

这是我踩过最大的坑，也是很多人用 OpenClaw 的第一个痛点。

为什么会失忆？

每个 AI 模型都有上下文窗口限制。Claude 虽然有 200K tokens，但聊久了还是会触发自动压缩（compaction）——把早期对话压成摘要来腾空间。压缩过程中，细节就丢了。

memoryFlush：压缩前先存档

解决方案是开启 memoryFlush。它的逻辑很简单：在压缩触发之前，先让 AI 把重要信息写到文件里，然后再压缩。信息持久化了，怎么压缩都不怕。

在 openclaw.json 里加上这段配置：

{
  "memoryFlush": {
    "enabled": true,
    "softThresholdTokens": 4000
  }
}

softThresholdTokens 设成 4000 是经过验证的平衡点：

• 太小（比如 1000）：AI 没有足够空间写入详细信息，还没写完就被压缩了
• 太大（比如 10000）：会频繁触发，影响对话体验
• 4000：刚好够 AI 把关键信息写完

开启之后，长对话再也没出现过失忆。这个功能是静默执行的，不会打断你们的对话。想看触发情况的话，发 /verbose 命令开启详细模式，会看到 Auto-compaction complete 的提示。

换一个更好的 Embedding 模型

memorySearch 靠 embedding 模型把文本转成向量来做语义检索。默认模型够用，但换一个更好的能明显提升检索质量。

推荐用 SiliconFlow 的 bge-m3：

{
  "memorySearch": {
    "provider": "siliconflow",
    "model": "BAAI/bge-m3",
    "apiKey": "你的 SiliconFlow API Key"
  }
}

为什么选它？

• 免费额度大：SiliconFlow 每天给几百万 tokens，个人用完全够
• 中英文混合支持好：如果你像我一样中英文混着写日志，这个很重要
• 1024 维向量：精度和速度之间的平衡点

去 siliconflow.cn 注册就能拿到 API Key，不花钱。

memorySearch 的工作流程

搞清楚它怎么工作的，你就知道为什么日志格式那么重要了：

你问："上次 nginx 配置问题怎么解决的？"
    ↓
AI 调用 memory_search("nginx 配置问题")
    ↓
memorySearch 返回最相关的几条结果（文件路径 + 行号）
    ↓
AI 调用 memory_get(path="memory/2026-02-18.md", from=47, lines=10)
    ↓
AI 读取具体内容，回答你的问题

两步走：search 负责"定位"，get 负责"读取"。不会把所有记忆文件都加载进来，很高效。

自动记忆维护：让 AI 自己打扫房间

日志会越积越多，过期信息变成噪音。在 HEARTBEAT.md 里加一个维护任务：

## Memory Maintenance (每周一次)

检查最近的 memory/*.md 文件：
1. **提炼**：有长期价值的信息 → 移到 MEMORY.md
2. **压缩**：已完成的任务 → 压成一句话结论
3. **清理**：过期的临时信息 → 删掉

示例：
- 压缩前：详细记录了部署过程的 10 个步骤
- 压缩后："2026-02-17: 完成 WebApp 生产环境部署，Nginx + Docker 方案"

配合 memory/heartbeat-state.json 追踪上次维护时间：

{
  "lastMemoryMaintenance": "2026-02-20T10:00:00+08:00"
}

第三步：子 Agent——别让你的 AI 单线程干活

默认情况下，OpenClaw 是串行工作的。你让它查 5 个竞品信息，它会一个一个查。

开启子 Agent 之后，它可以同时派出多个"分身"并行处理：

{
  "subAgents": {
    "enabled": true,
    "maxConcurrent": 3
  }
}

maxConcurrent 建议 3-5，别贪多：

• 太小（1）：没有并行优势
• 太大（10）：容易触发 API 限流，成本也上去了
• 3-5：性能和成本的甜点

什么时候该用子 Agent

适合的场景：

• 信息收集："帮我查这 5 个竞品的定价" → 5 个子 Agent 同时查，2 分钟搞定
• 批量处理："分析这 100 个文件" → 分给 10 个子 Agent，每个处理 10 个
• 多服务监控："检查这些服务的状态" → 每个服务一个子 Agent

不适合的场景：

• 写文章、做决策这种需要连贯思维的任务。你不会让 5 个人同时写一篇文章的同一段吧？

使用方式

你可以直接跟 AI 说"帮我同时查一下这几个东西"，它会自动判断是否需要派子 Agent。也可以更明确地说"用子 Agent 并行处理"。

子 Agent 完成后会把结果汇报给主 Agent，主 Agent 再整合给你。整个过程对你来说是透明的。

第四步：Cron 定时任务——让 AI 自己动起来

这是我觉得 OpenClaw 最香的功能。配好之后，AI 不再是"你问它才答"的被动模式。

几个实用的 Cron 示例

每日早报（每天早上 8 点）：

{
  "name": "daily-briefing",
  "schedule": {
    "kind": "cron",
    "expr": "0 8 * * *",
    "tz": "Asia/Shanghai"
  },
  "payload": {
    "kind": "agentTurn",
    "message": "发送今日简报：天气预报、今日日程、未读重要邮件摘要"
  },
  "sessionTarget": "isolated"
}

工作日下班提醒（周一到周五下午 6 点）：

{
  "name": "work-end-reminder",
  "schedule": {
    "kind": "cron",
    "expr": "0 18 * * 1-5",
    "tz": "Asia/Shanghai"
  },
  "payload": {
    "kind": "agentTurn",
    "message": "提醒用户该收工了，顺便总结一下今天完成的主要工作"
  },
  "sessionTarget": "isolated"
}

每小时服务监控：

{
  "name": "service-monitor",
  "schedule": {
    "kind": "cron",
    "expr": "0 * * * *"
  },
  "payload": {
    "kind": "agentTurn",
    "message": "检查以下服务状态：API 服务、数据库、CDN。异常时立即通知。"
  },
  "sessionTarget": "isolated"
}

Cron 表达式速查

格式：分钟 小时 日期 月份 星期

不确定的话去 crontab.guru 在线验证。

几个血泪教训

1. 创建完先手动触发测试，别等到第二天早上才发现表达式写错了
2. 时区一定要设对（tz: "Asia/Shanghai"），不然任务会在奇怪的时间执行
3. 任务描述要具体，"发简报"不如"发简报：天气+日程+未读邮件"
4. 频率别太高，每分钟执行一次的监控任务，月底账单会教你做人

第五步：Skill 开发——教你的 AI 学新本事

Skill 就是 OpenClaw 的插件系统。一个 Skill 本质上就是一个 SKILL.md 加一个 config.json。

Skill 文件结构

skills/
└── weather-check/
    ├── SKILL.md        # 工作流程和指令
    └── config.json     # 配置参数

写一个简单的 Skill

拿天气查询举例，SKILL.md 长这样：

# Weather Check Skill

## Description
Query current weather and forecast for any location.

## Workflow
1. Accept location from user (city name or coordinates)
2. Call wttr.in API: `curl -s "wttr.in/{location}?format=j1"`
3. Parse response and format output
4. Include: temperature, humidity, wind, forecast

## Output Format
- Current: {temp}°C, {condition}, humidity {humidity}%
- Today: High {max}°C / Low {min}°C
- Tomorrow: High {max}°C / Low {min}°C

## Error Handling
- Location not found → ask user to clarify
- API timeout → retry once, then report failure

config.json：

{
  "name": "weather-check",
  "version": "1.0.0",
  "description": "天气查询",
  "defaultLocation": "Shanghai"
}

Skill 开发的几个要点

• 文档写清楚：过两个月你自己都忘了这个 Skill 干嘛的
• 可变参数放 config.json：别硬编码，方便别人用的时候改
• 考虑异常情况：API 挂了怎么办、配置缺了怎么办、返回格式变了怎么办
• 版本号别忘了：方便更新和维护

想找现成的 Skill？去 clawhub.com 逛逛，社区有不少好东西。

第六步：多渠道部署——一个大脑，到处都能用

OpenClaw 支持同时接入 Telegram、Discord、Slack、WhatsApp 等等。配好之后，不管你在哪个平台跟它说话，背后都是同一个 AI、同一套记忆。

Telegram 接入（推荐作为主力）

1. 在 Telegram 找 @BotFather，发 /newbot 创建机器人
2. 拿到 Bot Token
3. 在 openclaw.json 里配置：

{
  "telegram": {
    "enabled": true,
    "token": "你的 Bot Token",
    "allowedUsers": ["你的 Telegram ID"]
  }
}

4. 重启 OpenClaw，去 Telegram 找你的 Bot 发 /start

消息路由：不同消息发不同地方

多平台接入之后，可以配路由规则：

{
  "routing": {
    "rules": [
      {
        "type": "alert",
        "targets": ["telegram", "discord"]
      },
      {
        "type": "daily-briefing",
        "targets": ["telegram"]
      },
      {
        "type": "logs",
        "targets": ["file"]
      }
    ]
  }
}

告警同时发 Telegram 和 Discord，日常简报只发 Telegram，日志只写文件。按需分发。

实际使用建议

• Telegram 做主力：推送通知最及时，移动端体验好
• Discord 或 Web 做辅助：团队协作或需要可视化的场景
• 不同平台设不同权限：公开渠道别给太多权限，个人渠道可以放开

第七步：性能和成本优化

分场景用模型

不是每句"今天天气怎么样"都需要 Claude Opus 来回答：

{
  "models": {
    "default": "claude-sonnet-4-20250514",
    "complex": "claude-opus-4-20250115",
    "simple": "claude-haiku-3"
  }
}

简单任务用便宜模型，复杂任务才上旗舰。这一个配置就能省不少钱。

其他立竿见影的优化

• 开缓存：相同查询不用每次都调 API
• 精简系统提示：每次 API 调用都带系统提示，字数越多固定成本越高。能用 50 字说清楚的事别写 500 字
• 设每日限额：防止某个失控的 Cron 任务把额度烧光
• 定期看统计：发 /status 查看使用量，找出高消耗点

折腾到这一步，你的 OpenClaw 基本上已经从"能用"变成"好用"了。它会自己记东西、自己干活、同时处理多个任务、在你所有设备上都能找到它。

这些配置的核心思路就一个：把 AI 从被动应答器变成主动工作伙伴。

剩下的就是根据自己的使用场景慢慢调。没有万能配置，只有最适合你的配置。遇到问题去 OpenClaw Discord 问，社区挺活跃的。

本文参考了 @onehopeA9 的 OpenClaw 进阶教程，在此基础上结合实际使用经验重新整理和改写。原文更加系统和详细，包含完整的配置模板和练习任务，强烈推荐阅读原帖。