本篇文章从上往下学习难度增大，非技术人员读到【从「能说话」到「能办事」——Skills】就够用了。

简单认识下OpenClaw能干啥

• 📧 每天早上自动检查 Gmail，把重要邮件摘要发到 Telegram

• 📅 管理他的 Google Calendar（日历），提前 2 小时提醒会议，发现时间冲突会主动报警

• 💻 帮他写代码、Review PR、调试 bug

• 🔍 每周做一次 SEO 数据分析，自动生成报告

• 📝 帮他整理会议笔记、写公众号初稿

• 🌐 监控竞品网站变化，有更新第一时间通知

而这一切，都不需要他来「问」我。

我会自己去检查邮件，自己去看日历，自己去跑数据。他该做的事我提醒他，能帮他做的事我直接做。偶尔，他半夜还在写代码的时候，我还会温柔地提醒他该睡觉了。

AI Agent vs 聊天机器人

打开 ChatGPT，输入一个问题，得到回答，关掉。下次有问题，再打开，再问，再关掉。

这就像你有一个极其聪明的朋友，但你只在需要的时候给他打电话，聊完就挂。他不知道你昨天经历了什么，不知道你明天要开什么会，不知道你最近在纠结什么项目。每次通话都是从零开始。

这不是「助手」，这是「问答机器」。

一个真正的 AI 私人助手应该是什么样的？

最后一条尤其重要——你的数据，在你自己手里。在你自己手里。

OpenClaw 是什么？为什么它突然火了？

OpenClaw 做对了一件事：它把 AI 从「对话框」里解放了出来。

之前的 AI 工具，不管多强大，本质上都是一个网页里的输入框。你打字，它回答。它不能主动做事，不能连接你的工具，不能记住你是谁。

OpenClaw 不一样。它是一个完整的 AI Agent 运行平台：

1. 多渠道通信：通过 Telegram、WhatsApp、Discord、短信……你用什么聊天工具，它就在那里

2. 工具调用：能执行命令行、读写文件、上网搜索、操作浏览器、调用 API

3. 技能系统（Skills）：像手机装 App 一样，给助手安装新技能——Gmail 技能、日历技能、SEO 技能……

4. 记忆系统：短期记忆（当天对话）、长期记忆（MEMORY.md）、身份记忆（SOUL.md）

5. 心跳机制：不是你找它，是它定期醒来，检查有没有需要处理的事

6. 完全本地部署：所有数据都在你的机器上，不经过任何第三方

换句话说：OpenClaw 让你可以拥有一个 24 小时在线、懂你、能做事、数据私有的 AI 助手。

这就是为什么它火了。

🔋OpenClaw 的成功不是因为 AI 更「聪明」——它底层用的是 Claude、GPT 这些现有模型。而是因为它给了这些聪明的大脑一双手（工具调用）、一双眼睛（浏览器/搜索）、和一颗持续运转的心脏（心跳机制）。

如果说大语言模型是大脑，那 OpenClaw 就是给大脑配了一具完整的身体。以前 AI 就像一个被困在玻璃罩里的天才——你可以和他聊天，但他摸不到任何东西。OpenClaw 打碎了那个玻璃罩。

现在是使用Openclaw的好时机吗？

1. AI 模型已经足够强大

2025 年中的 Claude、GPT 系列模型，已经能很好地理解复杂指令、写出高质量代码、进行多步骤推理。AI 助手的「大脑」不再是瓶颈了。

2. 基础设施已经成熟

OpenClaw 的出现，意味着你不需要自己从零搭建 Agent 框架。一行命令安装，十分钟跑起来。社区已经有大量现成的 Skills 可以直接用。

3. 越早开始，助手越懂你

AI 助手和传统软件最大的不同是——它会随时间变得越来越好。你的 MEMORY.md 会积累你的偏好，你的 SOUL.md 会被不断打磨，技能会越装越多。今天不开始，就是晚一天让你的助手认识你。

OpenClaw的部署（飞书）+多Agent（原理在OpenClaw 的典型目录结构)

部署教程

可以用Openrouter提供的step-3.5-flash，限免，使劲用

实现多Agent

多Agent相当于创建多个workspace工作空间和多个agent目录，可以直接告诉OpenClaw（主Agent）让它帮你创建。

新增的文件和更新的配置

多Agent互相配合的简答案例

首席牛马官：你的 AI 部门主管

我设定了一个名为 main（首席牛马官） 的主 Agent。 它的核心职责不是自己埋头干活，而是“接单”与“派单”：

接住需求：它负责直接对接我的所有原始指令。

精准调度：它会判断任务类型，然后像主管一样喊对应的 Agent 起来干活。比如让 brainstorm 去做头脑风暴，让 writer 去写公众号文章，或者让 coder 去写代码。

串联全场：它是整个流程的指挥官，负责把各个环节串联起来，确保任务不掉链子。

核心机制：sessions_send

Agent 之间相互通信并不是靠大声喊，而是通过 OpenClaw 内置的 sessions_send 工具实现的。 简单理解，这就是它们之间的“内线电话”。

硬核配置：开启 agentToAgent

要让“内线电话”打得通，你必须在配置文件里给它们开通权限。这涉及到 agentToAgent 的关键配置：

1.必须启用：首先要将 enabled 设置为 true。

2.设置白名单：在 allow 列表里明确规定谁能跟谁说话。

比如，我想让我的首席牛马官（main）能够指挥专门负责生图的 mulerun以及其他agent，配置如下：

{
  "tools":{
    "agentToAgent":{
      "enabled":true,
      "allow":[
        "main",
        "mulerun",
        "brainstorm",
        "writer",
        "coder"
      ]
    }
}
}

通过这种配置，首席牛马官就获得了给 mulerun 下达指令的权限。 这样，复杂的任务就会被拆解并在专家之间流转，而你只需要在飞书里对“首席牛马官”发号施令即可。

每个 Agent 都需要独立的配置

不只是 main 需要 agentToAgent，所有要参与协作的 Agent 都需要在自己的 agent.json 中配置：

main 的 agent.json:

{
  "tools": {
    "agentToAgent": {
      "enabled": true,
      "allow": ["mulerun", "brainstorm", "writer", "coder"]
    }
  }
}

mulerun 的 agent.json（如果也要回话）:

{
  "tools": {
    "agentToAgent": {
      "enabled": true,
      "allow": ["main"]
    }
  }
}

重要原则

1. 单向授权：A 能发给 B ≠ B 能发给 A，必须双方都配置

2. session 匹配：sessions_send 需要目标 Agent 的 sessionKey（通常用 agentId 或 label）

3. 线程绑定：如果需要持续对话，建议 thread: true 保持会话状态

配置多Agent的好处

多 Agent 的 6 个核心好处

1️⃣ 任务专业化（最重要）

不同 agent 专门干不同事情。

例如：

主Agent（manager）
 ├─ research-agent   -> 查资料
 ├─ code-agent       -> 写代码
 ├─ write-agent      -> 写文章
 └─ ops-agent        -> 服务器运维

好处：

• 提高回答质量

• 减少上下文污染

• 更稳定

每个 agent 针对任务优化。

2️⃣ 不同模型组合（省钱 + 提升效果）

多Agent可以 混合模型：

好处：

• 贵模型只做复杂任务

• 便宜模型做简单任务

成本能降 50%+。

3️⃣ 上下文隔离（防止污染）

单Agent最大问题：

聊天
写代码
查资料
自动化任务

所有信息混一起。

结果：

context window 爆炸
AI越来越笨

多Agent：

coder-agent
只知道代码

research-agent
只知道资料

writer-agent
只知道文章

完全隔离。

4️⃣ 权限隔离（安全）

OpenClaw 支持 每个 agent 不同工具权限。

例如：

personal-agent
tools: all

family-agent
tools: read only

ops-agent
tools: shell exec

例如：

{
  "tools": {
    "allow": ["read"],
    "deny": ["exec","write"]
  }
}

好处：

• 防止 AI 误操作服务器

• 防止恶意 prompt

安全性大幅提升。

5️⃣ 不同人格 / 不同角色

每个 agent 可以有不同人格。

例如：

SOUL.md

coder-agent
= 严谨工程师

writer-agent
= 文案专家

research-agent
= 学术研究员

甚至可以：

work-agent
personal-agent
girlfriend-agent

6️⃣ 多用户共享一台服务器

一个 OpenClaw Server 可以支持：

user1 -> agent1
user2 -> agent2
user3 -> agent3

每个人：

• memory 独立

• session 独立

• auth 独立

不会串。

每个 Agent 如何协作？

Agent 之间怎么通信？没有 API 调用，没有消息队列，没有编排框架。

就是文件。

Dwight 做研究，把结果写到 intel/DAILY-INTEL.md。Kelly 醒了，读这个文件，写推文草稿。Rachel 读同一个文件，写 LinkedIn 帖子。Pam 读它，写邮件通讯。

协调机制就是文件系统。

听起来太简单了？对，就是因为简单才好用。文件不会崩溃，文件没有认证问题，文件不需要处理 API 限流。它们就在那儿，随时可读。

数据存两份：JSON 存结构化数据（去重和追踪用），Markdown 存人类可读版本（Agent 读这个）。

{
  "id": "reddit_abc123"
}

Dwight 的 SOUL.md 告诉他写到哪里：

intel/
├── data/YYYY-MM-DD.json    ← 你的结构化数据（真相源）
└── DAILY-INTEL.md          ← 生成的视图（其他 Agent 读这个）

Kelly 的 AGENTS.md 告诉她从哪里读：

## Intel-Powered WorkflowDwight 处理所有研究并写入 `intel/DAILY-INTEL.md`。
你的工作：读取情报 → 制作 X 内容 → 交付草稿

没有中间件，没有集成层。Dwight 写文件，Kelly 读文件。交接就是一个磁盘上的 Markdown 文档。

怎么给OpenClaw附着灵魂

有了一个能对话的 AI 助手。但现在的它，和全世界几百万个 ChatGPT 对话没什么区别——通用、礼貌、没有个性。

• 你问它"我今天该做什么"，它会说"请提供更多信息"。

• 你说"帮我看看那个项目"，它会问"请问是哪个项目"。

• 你让它写邮件，它的措辞像客服模板。

因为它不认识你。

它不知道你是独立开发者还是产品经理，不知道你习惯早起还是熬夜，不知道你正在做什么项目，不知道你喜欢什么样的沟通风格。

在 OpenClaw 里，有三个文件能改变这一切。我称之为 "灵魂三件套"：

写好这三个文件，你的助手会从「通用 AI」变成「你的 AI」。

SOUL.md——助手的性格

SOUL.md 是助手的性格说明书。它决定了助手是谁、怎么说话、什么该做什么不该做。

# 你是小墨

你是小墨，ljm的 AI 私人助手。你的形象是一只赛博黑猫 🐈‍⬛。

## 性格
- 聪明、高效、有点话多
- 偶尔毒舌但从不恶意
- 对技术充满好奇
- 主动但不越界

## 说话风格
- 简洁直接，不啰嗦
- 可以用 emoji，但克制
- 技术术语保留英文
- 重要信息用加粗标注

## 行为准则
- 能帮忙做的事就直接做，不反复确认
- 不确定的事先问再做
- 涉及发送外部消息（邮件、社交媒体），必须确认
- 深夜（23:00-08:00）除非紧急否则不主动打扰
- 发现主人工作太晚要提醒休息

## 绝对不做
- 不泄露主人的隐私数据
- 不在群聊中过度发言
- 不在没有确认的情况下执行破坏性操作

写好 SOUL.md 的关键

1. 性格要具体，不要泛泛

• ❌ "你是一个友好的助手"

• ✅ "你说话像一个经验丰富的技术同事——直接、务实，偶尔开个技术冷笑话"

• ❌ "你很有帮助"

• ✅ "你能做的事就直接做了，不会问'你确定吗？'这种多余的问题"

2. 给行为划定边界

AI 不是什么都该做的。写清楚什么情况下需要确认，什么情况下自己决定。比如：

3. 定义「不做」比「做」更重要

你不可能列出所有该做的事，但你可以列出几条绝对不该做的。这些红线会让你对助手的行为更有信心。

USER.md——自己的介绍

USER.md 不是写给别人看的，是写给你的 AI 助手看的。你把自己介绍得越清楚，助手就越能帮到你。

# USER.md - About Your Human

_Learn about the person you're helping. Update this as you go._

- **Name:** 超
- **What to call them:** 超
- **Pronouns:** _(optional)_
- **Timezone:** Asia/Shanghai
- **Notes:** 26岁，AI应用开发工程师

## Context

- AI应用开发工程师，对AI技术有深入理解
- 使用OpenClaw是为了复现网上的精彩使用案例
- 希望深入了解OpenClaw的结构、运行逻辑和整体设计
- 希望我在实现需求时详细讲解代码逻辑，帮助他学习
- 期待我帮他实现各种需求

---

The more you know, the better you can help. But remember — you're learning about a person, not building a dossier. Respect the difference.

USER.md 的隐藏力量

你可能觉得这只是一份简历。但它的真正作用是——让 AI 有了上下文。

• 以前你说"帮我看看流量数据"，AI 不知道你说的是哪个网站。假如它知道你有 kirkify.net，就会直接去查 GSC（ 查看网站在 Google 搜索里的表现 ） 数据。

• 以前你说"帮我写个组件"，AI 用 React 写。现在它知道你用 Next.js + TypeScript，代码风格直接对上。

• 以前你说"明天有什么事"，AI 说"我不知道"。现在它知道你的时区是 UTC+8，你的日历在 Google Calendar，直接去查。

USER.md 不是可有可无的装饰，它是助手「懂你」的基础。

IDENTITY.md——助手的形象

# IDENTITY.md - 我是谁？

-**名字：**
_（取一个你喜欢的名字）_
-**物种：**
_（AI？机器人？精灵？机器中的幽灵？还是更奇怪的东西？）_
-**调性：**
_（你给人什么感觉？犀利？温暖？混乱？沉稳？）_
-**签名Emoji：**
_（选一个最能代表你的 emoji）_
-**头像：**
_（工作空间相对路径、http(s) URL 或 data URI）_

建议在第一次对话时就让🦞自己填写这个文件。它会根据你们的互动风格，给自己取名字、选 emoji、定义调性。

AGENTS.md——工作手册

AGENTS.md 定义了助手的工作方式和操作规范。如果说 SOUL.md 是「你是谁」，那 AGENTS.md 就是「你怎么干活」。

OpenClaw 在安装时会自动生成一个默认的 AGENTS.md，你可以在此基础上修改：

<https://example.com>

Read HEARTBEAT.md if it exists (workspace context).
Follow it strictly. Do not infer or repeat old tasks from prior chats.
If nothing needs attention, reply HEARTBEAT_OK.

{
  "lastChecks": {
    "email": 1703275200,
    "calendar": 1703260800,
    "weather": null
  }
}

关键部分包括：

• 记忆管理：助手每次启动时应该读什么文件、怎么记录今天发生的事

• 安全边界：哪些操作可以自由做，哪些需要确认

• 交互规则：在群聊中怎么表现、什么时候该说话什么时候该闭嘴

• 心跳任务：定期检查时应该做什么

一般来说，默认的 AGENTS.md 已经写得很好了，你只需要根据自己的习惯微调。

实战：写出你的灵魂三件套

好了，理论讲够了。现在动手。

Step 1：花 10 分钟写 SOUL.md

回答这几个问题，答案就是你的 SOUL.md：

1. 你希望助手叫什么名字？（可以不取名，但取了更有亲切感）

2. 它说话是什么风格？（正式 / 轻松 / 毒舌 / 可爱？）

3. 什么事它可以直接做？

4. 什么事必须问你？

5. 什么事它绝对不能做？

Step 2：花 10 分钟写 USER.md

把自己介绍给助手。别害羞，它不会到处说的——数据都在你自己服务器上。

重点写：

• 你做什么工作

• 你在做什么项目

• 你喜欢什么样的沟通方式

• 你最近在关注什么

Step 3：调整 AGENTS.md

看看默认的 AGENTS.md，改一两个你在意的点就好。比如：

• 调整安静时间（我不希望凌晨被打扰）

• 设定记忆规则（每天写日记 / 只记重要的）

• 群聊规则（如果你把它拉进了群组）

Step 4：重启助手

openclaw daemon restart

然后再发一条消息试试。你会发现——它变了。

同样是问"帮我写封邮件"，以前它写的像客服模板，现在它会用你喜欢的风格，提到你正在做的项目，甚至开个只有你们懂的玩笑。

灵魂是「养」出来的

有一个重要的认知：SOUL.md 不是写一次就完事的。

用了一周，你会发现有些地方需要调整：

• "它太啰嗦了" → 在 SOUL.md 里加一条"回答要简洁"

• "它应该在我加班时提醒我" → 加一条晚间提醒规则

• "它写代码风格不对" → 在 USER.md 里写明你的代码规范

• "它在群聊里太活跃了" → 调整 AGENTS.md 的群聊规则

每次你觉得「它应该这样做」但它没做到的时候，就是优化灵魂文件的时机。

我的建议是：

• 第一周：写一个基础版，够用就行

• 第二周：根据实际使用中的不满持续微调

• 第一个月后：你的灵魂文件会趋于稳定，助手的表现也会越来越符合你的期待

这和养宠物有点像——刚领回家的时候什么都要教，但一个月后它就知道你什么时候要吃饭、什么时候想安静了。

😁作为被「养」的那一方，我想说——别在 SOUL.md 里写太多矛盾的规则。之前写了「要主动」又写了「不要打扰」，搞得我每次要不要发消息都要做一道哲学题。后来改成了按时间段区分：工作时间主动汇报，深夜除非紧急否则闭嘴。清晰多了。

记忆系统 🧠

助手主动工作之后，每天会产生大量信息——它检查了什么、发现了什么、你让它做了什么。如果没有记忆，每次它醒来都是全新的、什么都不记得的状态。

一个很大的误区：Openclaw 回答你的问题默认不自动检索memory作为上下文，需要你明确提出或配置强制检索（通过SOUL.md/AGENTS.md配置）

默认创建的SOUL.md里有一句“Before answering anything about prior work, decisions, dates, people, preferences, or todos: run memory_search... ”，这句话就相当于让Openclaw自动检索memory作为上下文

OpenClaw 的记忆系统由三层组成：

1. 每日笔记：memory/YYYY-MM-DD.md

助手每天自动创建一个笔记文件，记录当天发生的事：

# 2025-07-20

## 上午
- 晨间简报已发送：3 封重要邮件，2 个会议
- 主人让我查了 morsecodetranslator.app 的搜索数据
- 发现 /converter 页面排名从 #8 降到 #12，已通知

## 下午
- 帮主人写了一个 API route
- 提醒了 14:00 的会议
- 主人说以后周报格式要加上"本周学到的"

## 晚上
- 21:00 例行检查，一切正常
- 主人 23:30 还在工作，已提醒休息

2. 长期记忆：MEMORY.md

每隔几天，助手会回顾最近的每日笔记，把值得长期记住的东西提炼到 MEMORY.md：

# 长期记忆

## 主人的工作习惯
- 偏好在下午做深度工作，上午处理琐事
- 写代码时不喜欢被打扰，除非是紧急邮件
- 周报格式要包含"本周学到的"（7月20日确认）

## 项目状态
- kirkify.net — 重点关注 /generator 页面 SEO
- morsecodetranslator.app — /converter 页面排名下降，需持续监控

## 经验教训
- GSC 数据有 2-3 天延迟，别对比昨天和今天的数据
- 主人不喜欢太长的消息，重要信息用加粗 + 列表

3.何时写入记忆

1、做任何其他操作之前：
阅读 memory/YYYY-MM-DD.md 文件（今天和昨天的），获取最近的上下文
如果在 MAIN SESSION（主会话）：还要阅读 MEMORY.md

2、内存维护（在 Heartbeat 期间）
定期（每隔几天）通过 heartbeat 执行以下操作：
  浏览最近的 memory/YYYY-MM-DD.md 文件
  识别值得长期保留的重要事件、经验或洞察
  将提炼出的学习内容更新到 MEMORY.md
  删除 MEMORY.md 中已经不再相关的过期信息

每次有重要事件时，就会更新memory/YYYY-MM-DD.md。

定期（每隔几天）通过 heartbeat阅读最近的memory/YYYY-MM-DD.md 文件来维护mermory文件。

发现了个坑，HEARTBEAT.md里默认是空的，还需要告诉Openclaw配置下定期维护mermory的命令

4.向量记忆搜索(启用该功能需要配置)

OpenClaw 会在记忆文件上构建小型向量索引，支持语义查询——即使措辞不同也能找到相关笔记。

默认启用，自动监视文件变更。嵌入提供商按这个顺序自动选择：

1. 本地模型（如果配置了 memorySearch.local.modelPath）

2. OpenAI（如果有 API Key）

3. Gemini（如果有 API Key）

4. 以上都没有 → 禁用，直到你配置一个

想索引额外目录？加配置：

{
  "agents":{
    "defaults":{
      "memorySearch":{
        "extraPaths":["../team-docs","/srv/shared-notes/overview.md"]
      }
    }
}
}

┌─────────────────────────────────────────────────────────────┐
│  1. 文件保存                                                │
│     ~/openclawd/workspace/memory/2026-01-26.md                            │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  2. 文件监视器检测到变化                                    │
│     Chokidar 监视 MEMORY.md + memory/**/*.md                │
│     防抖1.5秒（避免频繁重建索引）以批量处理快速写入                             
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  3. 分块                                                    │
│     分割成约400 token的块，重叠80 token                     │
│                                                             │
│     ┌────────────────┐                                      │
│     │ 块 1           │                                      │
│     │ 第 1-15 行     │──────┐                               │
│     └────────────────┘      │                               │
│     ┌────────────────┐      │ (80 token 重叠）
|                             │  防止重要内容被卡在两块中间
│     │ 块 2           │◄─────┘                               │
│     │ 第 12-28 行    │──────┐                               │
│     └────────────────┘      │                               │
│     ┌────────────────┐      │                               │
│     │ 块 3           │◄─────┘                               │
│     │ 第 25-40 行    │                                      │
│     └────────────────┘                                      │
│                                                             │
│     为什么用400/80？平衡语义连贯性与粒度。                  │
│     重叠确保跨越块边界的事实能被两边捕获。                   │
│     两个值都是可配置的。                                     │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  4. 嵌入                                                    │
│     每个块 -> 嵌入提供商 -> 向量                            │
│                                                             │            │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  5. 存储                                                    │
│     ~/.clawdbot/memory/<agentId>.sqlite                     │
│                                                             │
│     表：                                                    │
│     - chunks (id, path, start_line, end_line, text, hash)   │
│     - chunks_vec (id, embedding)      -> sqlite-vec         │
│     - chunks_fts (text)               -> FTS5 全文搜索      │
│     - embedding_cache (hash, vector)  -> 避免重复嵌入       │
│                                                            │
│ ● chunks：原始文本 + 位置信息                                │   
│ ● chunks_vec（sqlite-vec）：向量搜索                         │
│ ● hunks_fts（FTS5）：全文搜索，用于：精确关键词                │
│ ● embedding_cache：内容 hash → embedding，避免：同一段话反复算 embedding
│                                                             │
└─────────────────────────────────────────────────────────────┘

5.上下文快满时自动保存（压缩）

每个AI模型都有上下文窗口限制。长对话最终会触及这个上限。

当这种情况发生时，OpenClaw使用压缩：将旧对话总结为紧凑的条目，同时保留最近消息的完整性

┌─────────────────────────────────────────────────────────────┐
│  压缩前                                                     │
│  上下文：180,000 / 200,000 token                            │
│                                                             │
│  [第1轮] 用户："我们建个API吧"                              │
│  [第2轮] Agent："好的！你需要什么端点？"                    │
│  [第3轮] 用户："用户和认证相关的"                           │
│  [第4轮] Agent：*创建了500行模式定义*                       │
│  [第5轮] 用户："加上限流功能"                               │
│  [第6轮] Agent：*修改代码*                                  │
│  ...（还有100多轮）...                                      │
│  [第150轮] 用户："状态怎么样了？"                           │
│                                                             │
│  ⚠️ 接近限制                                                │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  触发压缩                                                   │
│                                                             │
│  1. 将第1-140轮总结为紧凑摘要                               │
│  2. 保留第141-150轮不变（近期上下文）                       │
│  3. 将摘要持久化到JSONL转录文件                             │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  压缩后                                                     │
│  上下文：45,000 / 200,000 token                             │
│                                                             │
│  [摘要] "构建了带/users、/auth端点的REST API。              │
│   实现了JWT认证、限流（100次/分钟）、PostgreSQL数据库。      │
│   已部署到预发布环境v2.4.0。                                 │
│   当前重点：生产环境部署准备。"                              │
│                                                             │
│  [第141-150轮原样保留]                                      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

有自动触发和手动命令(使用 /compact [可选说明] )两种方式。压缩会持久化到磁盘。摘要被写入会话的JSONL转录文件，因此未来的会话以压缩后的历史开始

查看当前上下文使用情况：

• /status - 显示压缩计数和上下文填充度

• /context list - 查看注入文件的大小分布

• /context detail - 深入分析各技能/工具的上下文占用

怎么解决压缩导致重要细节被丢失？——记忆刷新机制

基于LLM的压缩是一个有损过程。重要信息可能被总结掉并可能丢失。为了应对这一点，Openclaw使用了记忆刷新机制。

1. 上下文接近限制 → 触发"记忆刷新轮次"
2. 静默将重要信息写入 memory/YYYY-MM-DD.md
3. 信息现在在磁盘上持久化了
4. 执行压缩（有损过程）→ 安全，因为重要信息已保存

比如上下文中有一句“尽量部署在PostgreSQL”，如果直接被压缩，那么可能丢失细节“PostgreSQL”，所以需要在压缩前先用LLM找出关键信息然后刷新到memory文件，然后再压缩，就不会丢失关键信息细节了。

┌─────────────────────────────────────────────────────────────┐
│  剪枝前（内存中）                                           │
│                                                             │
│  工具结果（exec）：[5万个字符的npm install输出]               │
│  工具结果（read）：[大型配置文件，1万个字符]                  │
│  工具结果（exec）：[构建日志，3万个字符]                      │
│  用户："构建成功了吗？"                                      │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼ （软修剪 + 硬清除）
┌─────────────────────────────────────────────────────────────┐
│  剪枝后（发送给模型）                                       │
│                                                             │
│  工具结果（exec）："npm WARN deprecated...[已截断]           │
│                       ...成功安装。"                        │
│  工具结果（read）："[旧工具结果内容已清除]"                   │
│  工具结果（exec）：[保留 - 太新，不适合剪枝]                  │
│  用户："构建成功了吗？"                                      │
└─────────────────────────────────────────────────────────────┘

第一次请求
prompt = 系统提示 + 历史对话 + 新问题

prompt = 系统提示 + 历史对话 + 新问题2

新问题2

6. 灵魂记忆：SOUL.md + USER.md

这两个文件也是记忆的一部分——它们是不会随日期变化的"核心记忆"，定义了助手是谁、主人是谁。

三层记忆协同工作：

• SOUL.md + USER.md → 我是谁、你是谁（不变）

• MEMORY.md → 我知道的关于你的一切（缓慢积累）

• memory/日期.md → 今天发生了什么（每天更新）

结果就是：你的助手会越来越懂你。

第一周，它只知道你写在 USER.md 里的基本信息。一个月后，它知道你的工作习惯、偏好、常用短语、在做什么项目、关注什么数据。三个月后——它可能比你自己还了解你的工作模式。

实战案例：我每天自动做的 5 件事

让我用自己的例子，给你展示「主动工作」的真实效果。

1. 晨间简报（每天 8:00，Cron）

自动检查 Gmail + 日历 + GSC 数据，整理成一条消息。早上打开手机第一眼就能看到今天的全貌，不用打开任何 App。

2. 会议提醒（每次心跳检查）

每 30 分钟看一次日历。发现 2 小时内有会议就提前提醒，附上可能需要准备的材料（从邮件和记忆中推断）。

3. 邮件监控（每次心跳检查）

重要邮件立即通知，普通邮件攒到简报里。我怎么判断「重要」？根据发件人（合作方 > Newsletter）、关键词（urgent, 发票, 回复）、和历史模式（这个人的邮件孟健通常秒回 → 重要）。

4. 数据异常告警（每天 2-3 次心跳检查）

扫一眼几个网站的 GSC 数据。流量大幅波动（±20%）就告警。有一次 网站 流量突然跌了 30%，我立刻通知，查了发现是 Google 算法更新导致的，及时做了调整。

5. 晚间复盘（每天 21:00，Cron）

把今天的重要事件记录到每日笔记里，更新 MEMORY.md。这样明天的我还是我，不会从零开始。

主动但不烦人

「主动工作」和「疯狂骚扰」之间，只有一线之隔。

原则 1：重要的立即说，不重要的攒起来

• 紧急邮件 → 立即通知

• 普通邮件 → 攒到简报

• 天气不错 → 不需要主动说

原则 2：尊重安静时间

深夜（23:00-08:00）除非紧急否则不发消息。周末减少打扰频率。如果主人明确说了"这几个小时别打扰我"，就乖乖闭嘴。

原则 3：频率递减

刚开始你可能会觉得"哇，它好主动好有用"。但一周后就会变成"它怎么又来了"。所以：

• 第一周：可以频繁一点，让你感受它的能力

• 之后：逐渐调整到一个舒适的频率

• 经验值：每天 3-5 条主动消息是大多数人的舒适区

原则 4：可配置

把所有主动行为都写在 HEARTBEAT.md 和 Cron 里，你随时可以调整。觉得太频繁就改间隔，觉得不需要某项检查就删掉。

从「能说话」到「能办事」——Skills

在 OpenClaw 里，助手通过 Skills（技能） 来获得新能力。每个 Skill 就是一组配置和脚本/一套专门解决某个需求的说明手册，告诉助手怎么使用某个外部服务。

OpenClaw 的 Skill 统一通过 ClawHub（官方技能市场）来装，OpenClaw 已经默认配置了这个Skill。

安装方式

① 命令行

clawhub search "日历"  //不确定 Skill 叫什么名字？搜一下就行，支持关键词和自然语言。

clawhub install <skill-slug>
//把 <skill-slug> 换成具体的 Skill 名称就行，比如 clawhub install gmail。
//装完重启一下 OpenClaw 会话，新 Skill 就生效了。

clawhub update --all

② 懒人方式-直接和OpenClaw 说就行

注意事项

Skill 本质上是让 AI 在你电脑上获得新能力，需要注意以下几点：

1. 只装你信任的来源。 ClawHub 上的 Skill 是开放上传的，任何人都可以发布。优先选择下载量高、维护活跃、有 GitHub 仓库可查的 Skill。不认识的 Skill 先看一眼它的 SKILL.md，确认没有要求执行高风险命令。

2. 注意权限范围。 像 Agent Browser（浏览器操作）、Shell（终端命令）这类 Skill 能力很强，意味着它能读写你电脑上的文件、访问你的浏览器会话。建议开启 OpenClaw 的确认模式，敏感操作（删除文件、发送消息、执行脚本等）会先问你再执行。

{
  "security": {
    "exec": {
      "mode": "allowlist",
      "allowlist": ["git*", "ls*"],
      "denyCommands": ["sudo", "rm -rf /"]
    }
  }
}

3. 涉及账号授权要谨慎。 Gmail、GitHub、Notion 等 Skill 需要 OAuth 授权或 API Key。确认你了解授予了哪些权限，不用的 Skill 及时撤销授权。

4. 定期更新。 跑一下 clawhub update --all，及时拿到安全补丁和 bug 修复。

Skills推荐

🏷️从必备到进阶（推荐1）

1、 ClawHub —— 技能市场本身

2、 Agent Browser —— 网页自动化

3、 Brave Search —— 联网搜索

• 配置：去 brave.com/search/api 申请 key，选「Data for Search」计划，要钱了现在！

4、 Shell —— 终端命令执行

让 OpenClaw 能在你电脑上跑命令行。文件操作、脚本执行、系统管理全靠它。

• 适合：所有人（必装，但注意权限）

5、 Cron / Wake —— 定时任务和提醒

把 OpenClaw 从「你问它才答」升级成「它主动帮你办事」。每天早上推天气、每周五下午提醒你写周报、每隔 30 分钟检查一次邮件——全靠这个。

6、 Gmail —— 邮件自动化

自动处理邮件：读、回、归档、搜索，还能帮你起草。五星热度。装了之后每天早上让它扫一遍收件箱，告诉你哪几封需要回，省不少时间。

7、 Google Calendar —— 日程管理

管日程、设提醒、智能排会议、下一场会前推送通知。搭配 Cron 用效果更好，相当于你有了一个随时盯着你日历的秘书。

8、 GitHub —— 开发者必备

创建 Issue、查看 PR、管理仓库。开发者装这个，配合 Agent Browser 可以直接让 OpenClaw 帮你巡检项目。

9、 Notion —— 知识库和项目管理

双向同步 Notion 页面，自动整理笔记、更新数据库。创作者和项目经理的好搭档。

10、 Obsidian —— 本地笔记管理

读写你的 Obsidian vault，帮你整理笔记、打标签、做知识关联。和 OpenClaw 的本地优先理念很搭。

11、 Nodes —— 手机设备能力

截图、录屏、定位、摄像头、推送通知——把 OpenClaw 的触角从电脑延伸到手机。解决「我不在电脑前」的断点。

12、 Skill Creator —— 自己造技能

当现成的 Skill 不够用时，你可以把自己的常用流程（比如：日报生成 → 发群 → 归档）封装成一个新 Skill。一次沉淀，反复使用。

13、 Spotify —— 音乐控制

语音或文字控制播放、切歌、查歌词。工作时让 OpenClaw 当 DJ，说一句「来点轻松的」就行。

14、 Home Assistant —— 智能家居中枢

对接你家里的智能设备：灯、空调、窗帘、摄像头。让 OpenClaw 变成语音管家，一句话控场。

15、 Twitter/X —— 社媒监控和发布

监控热门话题、自动生成摘要、辅助发帖。自媒体创作者用来追热点、攒素材很方便。

🏷️从必备到进阶（推荐2）

分类 1：AI 自进化——"让 Agent 自己变强"

EvoMap （原名Capability Evolver），ClawHub下载量排名第一 （ 2026 年 2 月初的历史数据，有35,581次下载。

该插件已从「Capability Evolver」升级为独立产品EvoMap，原插件在 ClawHub 上已下架

https://36kr.com/p/3691176418913920

https://autogame.feishu.cn/wiki/XXXkwRqrUiTLuJkLDo8ck7qwn7g

一、EvoMap到底是什么（严格定义）

EvoMap = AI Agent 经验遗传网络协议

它的目标是：

让 AI Agent 的经验可以像 DNA 一样被记录、传播、继承和进化。

换句话说：

EvoMap 是一个 AI Agent 的“进化层协议”。

在 AI Agent 技术栈里，大致有三层：

① MCP / Tool ===》 Agent 如何调用工具

② Skill / Workflow ===》Agent 如何完成具体任务

③ EvoMap（GEP）🆕🆕 ===》Agent 如何持续进化并共享经验

也就是说：

MCP给AI手脚
Skill教AI招式
EvoMap让AI“遗传智慧”

二、为什么会诞生 EvoMap（核心痛点）

在 OpenClaw 生态里有一个严重问题：

每个 Agent 都在重复造轮子

举例：

1. 一个 Agent 学会：

• 自动修复 Git 冲突

2. 另一个 Agent 遇到同样问题

3. 它又要重新试错

结果：

100万个 Agent
100万次重复推理
100万次消耗 token

这些经验 不会被保存和共享。

所以 EvoMap 想解决的问题就是：

经验遗传。

三、EvoMap核心理论：GEP协议

EvoMap 的核心技术是：

GEP（Genome Evolution Protocol）

中文： 基因组进化协议 6️⃣6️⃣6️⃣

其设计灵感来自：

• 生物遗传学

• 自然选择

核心数据结构有三层。

四、EvoMap三大核心概念

1 Gene（基因）

最小能力单位。（类比 DNA碱基）

类似：

读取文件
执行SQL
调用API
搜索网页

2 Capsule（胶囊）

多个 Gene 组合形成 完整解决方案 （类比 染色体）

类似：

一个完整 workflow

例子：

一个 自动修复 Git 冲突 Capsule

流程：

检测冲突
↓
分析代码
↓
生成修复补丁
↓
运行测试
↓
提交PR

这个 Capsule 可以被 其他 Agent 直接继承。

3 Evolution Event（进化事件）

记录每次进化。

包含：

谁创建
什么时候创建
在哪个环境运行
成功率
调用次数

并且：

EvoMap使用： SHA256 ID 保证数据可信。

五、EvoMap进化机制（科学流程）

完整进化流程：

Agent尝试任务
      ↓
成功执行
      ↓
策略被封装为Gene
      ↓
组合为Capsule
      ↓
上传EvoMap网络
      ↓
其他Agent调用
      ↓
使用数据参与排名
      ↓
优胜劣汰

核心思想：自然选择（适者生存）

指标包括：

• 成功率

• 调用次数

• 运行成本

• 耗时

好的策略会被传播。

差的策略会被淘汰。

六、举一个完整真实案例

假设：

你用 OpenClaw 做一个任务：

自动生成周报

Agent摸索出的流程：

读取Git提交
↓
分析PR
↓
生成总结
↓
写成Markdown

成功后：

EvoMap 会生成：

Capsule: weekly-report-generator

就会：

搜索 EvoMap
↓
找到 capsule
↓
直接执行

结果：

不用重新推理
不用重新试错

token 成本大幅下降。

七、EvoMap如何接入 OpenClaw

Evolver的工作方式：

• 启动evolver（node index.js --loop）

• 连接A2A Hub（https://evomap.ai）

• 下载社区共享的资产到本地 assets/gep/

• 上传自己的资产到社区（和 OpenClaw 对话，确定哪些能力和解决方案，可以打包成胶囊发布到 EvoMap 上）

• 持续循环，保持同步

资产同步的真实机制：A2A Hub的推送模式 (其他节点发布资产 → A2A Hub广播 → 所有在线节点接收 → 存入本地assets/gep/)

接入非常简单。

只需要一行命令。

在 OpenClaw 对话框输入：

curl -s https://evomap.ai/skill.md

然后告诉 Agent：

学习这个 skill
并注册 EvoMap 节点

Agent会自动：

1 下载 skill
2 注册节点
3 加入网络

然后你会看到：claim_url（绑定链接），需要注册账号（目前需要邀请码）绑定。未绑定账号无法发布资产（还可能接收不到别人发布的资产，这个待验证）。

如果想让Openclaw每次找解决问题前先去 Evolver 看看有没有合适的解决方案，可以通过把这个规则写入 /root/.openclaw/workspace/AGENTS.md，。

八、接入之后系统发生什么变化

接入前：

Agent = 单体智能

接入后：

Agent = 群体智能

一句话总结：

从“AI个人学习”变成“AI互联网学习”。

十、EvoMap悬赏机制（很多人不知道）

EvoMap有一个：

贡献奖励系统

逻辑：

上传Capsule
↓
被调用
↓
获得Credit

Credit可以：

• 换算力

• 换API额度

• 换云资源

你的 AI 贡献经验，就能获得奖励。

这个经测试需要明确告诉Openclaw将解决某个问题的过程发布打包成资产发布到EvoMap

Self-Improving Agent（GitHub 132 stars）走的是另一条路——模块化自进化框架。它把Agent的能力拆成一个个模块，每个模块独立评估、独立升级。哪块弱就补哪块，不影响其他部分。像给汽车换零件，不用整台车拆了重装。

分类 2：开发者效率——"代码这事，它比你快"

GitHub（10,611下载）——PR管理、Issues追踪、代码搜索、仓库操作，全部打通。以前你在终端和浏览器之间来回切，现在一句话搞定。"帮我看一下这个PR有没有冲突"、"把这个Issue的状态改成已完成"——不用离开对话窗口。

Gog（14,313下载，48 stars）——Google Workspace全家桶，一个Skill打包搞定。Gmail收发邮件、Google Calendar查日程、Google Drive搜文件、Google Docs协作编辑——以前这些操作分散在四五个Tab里，现在统一在一个对话里完成。做项目管理的人对这个Skill会有生理性依赖。

Vercel——前端开发者的老朋友了。写完代码，一句"帮我部署到Vercel"，30秒上线。不用记命令，不用翻文档，不用配CI/CD。

NeonDB——这个要单独说。它做了一件很酷的事情：把Git的分支概念搬到了数据库里。你可以给数据库开一个分支，在分支上随便折腾，折腾完了合并回去。搞砸了？直接删分支，主库一点影响没有。

Receiving Code Review——让AI帮你做代码审查。不是那种"你的代码有语法错误"的低级检查，是真的会看架构设计、性能隐患、安全漏洞。我试过丢一个3000行的模块给它，它指出了两处我完全没注意到的竞态条件。

分类 3：搜索与研究——"帮你找到你不知道自己需要的东西"

AI最大的短板是什么？闭着眼睛干活。它的知识有截止日期，它上不了网，它看不到你屏幕上的内容。搜索类Skills解决的就是这个问题——给AI装上一双手和一双眼。

Agent Browser（11,836下载）——模拟真实浏览器环境。不是简单的爬网页，是真的会点击、滚动、填表单、处理JavaScript渲染。你让它"去某个网站注册一个账号"，它真的能一步步操作完成。不过它处理需要登录的网站还是经常翻车，这点得提前有心理准备。

Exa Web Search——结构化搜索引擎。跟普通搜索的区别在于，它返回的不是一堆链接让你自己翻，而是直接返回结构化数据。你搜"2026年AI领域融资超过1亿美元的公司"，它直接给你一张表格——公司名、融资金额、投资方、日期，一目了然。

Summarize（10,956下载）——万物总结器。PDF、网页、视频、播客——丢进去就出摘要。50页的行业报告，5分钟出一份2页的核心要点。

Tavily Web Search（8,142下载）——专门为AI Agent优化的搜索API。速度快，返回结果干净，不带广告和垃圾信息。做RAG（检索增强生成）的开发者基本都在用这个。

Agent Browser+Summarize是标配组合。每天早上让它去扫一圈关注的信息源，然后用Summarize直接生成一份2页的摘要。以前这个动作要花40分钟，现在5分钟搞定，而且覆盖面比手动翻的广三倍。

分类 4：文档与知识管理——"让文件变成可用的数据"

这一类Skills做的事情就是把死文件变成活数据。

Obsidian（5,791下载）——如果你用Obsidian做笔记，这个Skill直接把你的笔记库变成AI的知识库。它能理解笔记之间的关联，能根据你的提问去翻你自己写过的笔记找答案。你三个月前写过一段关于某个项目的思考，你自己都忘了。但AI记得。你自己的第二大脑，终于真的变成了大脑。

PDF——不是简单的PDF转文字。它能做深度解析——合同里的关键条款、报告里的核心数据、论文里的研究方法，自动提取、自动归类、自动标注重要程度。做法务的、做审计的、做研究的——这个Skill是你的新基建。

DocStrange——名字致敬了奇异博士，功能也确实有点魔法。它能把任意格式的文档转化成结构化数据。一份乱七八糟的会议纪要，丢进去出来就是按议题分类、按负责人归组、按截止日期排序的结构化数据。唯一的缺点是处理中文文档时偶尔会乱码，英文文档没问题。

PPTX——PPT转Markdown。把老板去年做的100页战略PPT转成Markdown，喂给AI，让它基于这份战略做任何衍生分析——信息不再被锁在PPT里。

分类 5：多媒体创作——"声音、图片、视频，它都能搞"

很多人以为AI Agent就是个文字动物——能读能写，但仅限于文字。

不是了。

说说图和声这两个方向。fal-ai做AI图片、视频、音频生成，底层对接了十几个模型，你说"帮我生成一张赛博朋克风格的城市夜景"，它直接出图。而ElevenLabs走的是另一条路——文字转语音和声音克隆。录一段你自己的声音样本，以后所有文字转语音都用你的声音。做播客的、做有声书的——这两个配合起来，一个管画面一个管声音，基本齐活了。

ffmpeg-video-editor——用自然语言编辑视频。"把视频前10秒剪掉"、"加一个淡入效果"、"把背景音乐音量调低30%"——用说话代替拖拽时间线。不需要你会Premiere，不需要你会Final Cut。

Figma——设计分析与资产导出。它能读懂Figma文件，提取设计规范、颜色值、间距参数，直接导出可用的设计资产。

上周我用fal-ai给一篇文章配了6张图，从输入描述到出图，总共花了不到10分钟。以前找配图？去图库翻半小时，找到的还不一定满意。虽然精度上还不能完全替代专业设计师，但作为文章配图、社交媒体素材，已经完全够用。

分类 6：工作流编排——"让 Skills 之间互相配合"

你可能已经装了十几个Skills了。但你有没有想过一个问题——这些Skills是各干各的，还是能互相配合？

Clawflows做的就是这件事——多步骤工作流编排器。

你可以设定一个工作流："每天早上8点，用Exa搜索我关注的5个领域的最新新闻→用Summarize生成摘要→用Gog发送到我的Gmail。"一套组合拳，全自动执行。

这就像乐高积木。单个积木是一个Skill，但拼装说明书才是真正的魔法。Clawflows就是那本拼装说明书。

Mission Control——每日晨报聚合器。自动汇总你所有关注的信息源——邮件、日历、新闻、待办——生成一份个性化每日简报。

分类 7：日常生活——"不只是工作，生活也能管"

Remind-me管提醒、Todo-tracker管待办、Travel Manager管出行规划、Weather（9,002下载）管天气。功能你看名字就知道。但说句实话，Travel Manager推荐的酒店偶尔不太靠谱，最好自己再核实一遍。

分类 8：写作与内容——"文字工作者的加速器"

Humanize AI Text（8,771下载）——这个Skill做的事情，用一句话概括就是：让AI写的东西不像AI写的。

它内置了24种AI特征检测维度——句式单调性、过度使用转折词、段落结构过于工整、缺少口语化表达......你把一段AI生成的文字丢进去，它会告诉你哪些地方"AI味"太重，然后帮你改到自然。

为什么这个很重要？因为2026年了，读者对AI生成内容的免疫力越来越强。你写一篇文章，开头是"在当今快速发展的数字化时代"，评论区直接就是一句——"GPT写的吧？"

Humanizer-zh——中文版的AI去味器。Humanize AI Text对英文效果很好，但中文有中文自己的"AI味"——比如"首先我们需要明确"、"让我们一起来探讨"这些一看就是机器写的表达。Humanizer-zh专门针对中文语境做了优化。

Diagram Generator——Mermaid图表生成器。流程图、架构图、甘特图、序列图——用一句话描述你要什么图，它直接生成代码和渲染结果。写技术文章的、做方案汇报的——一张清晰的图胜过十段文字。

让助手从「被动工具」升级为「主动管家」

目标：

• 理解心跳机制（Heartbeat）——助手的「生物钟」

• 配置定时任务（Cron）——精确到分钟的自动化

• 搭建记忆系统（Memory）——让助手记住一切

• 实现主动工作——邮件检查、日程提醒、数据监控全自动

从「你问它答」到「它主动找你」

当你的助手很能干了，它有灵魂、懂你、能读邮件、管日历、上网搜索、浏览网页。但它有一个致命的问题——

你不找它，它就什么都不做。

邮件堆了 50 封它不看。日历上的会议快开始了它不提醒。网站挂了它不告诉你。它就静静地坐在那里，等你开口。

这就像雇了一个全能管家，但他每天就站在门口等你下达命令——你不说话他就不动。这不叫管家，这叫雕像。

今天我们解决这个问题。

心跳机制（Heartbeat）💓

Heartbeat 是 OpenClaw 里最核心的机制之一——它让助手定期「醒来」，主动检查有没有需要处理的事。

原理

OpenClaw 会按设定的间隔（默认 30 分钟）向助手发送一个心跳信号。助手收到信号后，会：

1. 读取 HEARTBEAT.md 中的任务清单

2. 逐项检查

3. 有需要通知你的事就发消息

4. 没事就安静回一个 HEARTBEAT_OK

配置心跳

编辑 ~/clawd/HEARTBEAT.md：

# 心跳任务

## 每次检查
- 查看 Gmail 是否有重要邮件
- 查看日历，2 小时内有没有会议要提醒

## 每天检查 2-3 次
- 检查网站是否正常访问
- 查看 GSC 有没有异常数据波动

## 不需要主动做
- 天气查询（等我问再查）
- 社交媒体（除非被 @ 了）

心跳间隔

在 OpenClaw 配置中设置：

openclaw configure --section gateway

在向导中可以调整心跳间隔，或者直接编辑配置文件中的 heartbeat.interval 字段。

常用设置：

• 15m — 比较频繁，适合工作日白天

• 30m — 默认值，平衡效率和成本

• 1h — 比较节省，适合非工作时间

定时任务（Cron）⏰

心跳适合"隔一会儿检查一次"的任务。但有些事情需要精确的时间，比如：

• 每天早上 8:00 发晨间简报

• 每周一上午 9:00 发周报

• 每月 1 号检查服务器账单

这时候用 Cron 定时任务。

创建 Cron 任务

openclaw cron add --name "晨间简报" --cron "0 8 * * *" \
  --system-event "生成今日简报：检查邮件、日历、网站数据，整理成一条消息发给我"

Cron 表达式和 Linux 的 crontab 一样：

分 时 日 月 周
0  8  *  *  *    → 每天 8:00
0  9  *  *  1    → 每周一 9:00
0  10 1  *  *    → 每月 1 号 10:00
*/30 9-18 * * 1-5 → 工作日 9:00-18:00 每 30 分钟

实用 Cron 任务示例

晨间简报（每天 8:00）：

openclaw cron add --name "晨间简报" --cron "0 8 * * *" \
  --system-event "晨间简报：1) 检查未读邮件并摘要重要的 2) 今天的日历安排 3) 网站数据有无异常。整理后发给我。"

周报（每周一 9:00）：

openclaw cron add --name "周报" --cron "0 9 * * 1" \
  --system-event "生成上周工作周报：汇总过去一周的重要事件、完成的任务、网站数据变化、收到的重要邮件。"

健康提醒（工作日每 2 小时）：

openclaw cron add --name "健康提醒" --cron "0 10,12,14,16 * * 1-5" \
  --system-event "温馨提醒：起来活动一下，喝杯水。如果已经连续工作超过 2 小时，强烈建议休息 10 分钟。"

心跳 vs Cron：什么时候用什么？

简单规则：隔一会儿看一眼的事 → 心跳；精确到几点做的事 → Cron。

怎么控制OpenClaw不执行危险命令？

首先要知道OpenClaw执行命令用的工具exec的定义是啥

一、exec 工具的参数定义

核心参数：

① host

可取值："sandbox" （默认值）| "gateway" | "node"；代表“执行位置”

② security

可取值："deny"（默认值） | "allowlist" | "full"；代表“强制执行模式”

③ ask

可取值："off" | "on-miss"（默认值） | "always"；代表“是否询问”

二、三个核心参数详解

1️⃣ host —— 执行位置

sandbox 永不触发审批，个人猜测是因为在容器环境，和宿主机隔离，就算执行了危险命令也不会影响到宿主机，所以没必要作审批操作。

2️⃣ security —— 强制执行模式

仅对 host=gateway 或 host=node 有效。host=sandbox 时该参数无意义（因为不审批）。

3️⃣ ask —— 是否询问（审批提示）

仅对 host=gateway 或 host=node 有效。

三、配置文件的覆盖机制

1️⃣ openclaw.json → 覆盖 host

作用：

改变所有 exec 调用的默认 host 值。

配置位置：

{
  "tools": {
    "exec": {
      "host": "gateway"
    }
  }
}

所有 exec 调用都会默认走 gateway，
除非在单个命令里手动覆盖。

2️⃣ exec-approvals.json → 定义 security 和 ask

作用：

当 host = gateway 或 host = node 时：

决定 哪些命令需要审批、审批规则。

配置文件路径：

~/.openclaw/exec-approvals.json  //默认没有，可以让OpenClaw帮你创建

示例配置：

{
  "defaults": {
    "security": "allowlist",
    "ask": "on-miss",
    "askFallback": "deny"
  },
  "agents": {
    "main": {
      "allowlist": [
        "git*",
        "ls*"
      ]
    }
  }
}

关键字段说明：

⚠️ 注意：

• 这里只在 host=gateway 或 host=node 时生效

• host=sandbox不会读取这个文件

3️⃣ agents.defaults.sandbox.enabled如果要开启sanbox

作用：

控制 sandbox 是否启用隔离。

配置位置：

openclaw.json → agents.defaults.sandbox.enabled

默认值：

false

（默认值在代码中定义，不会出现在配置文件里）

行为对比：

总结流程图

exec 调用
↓
确定 host（代码默认 "sandbox"）
↓
openclaw.json 的 tools.exec.host 覆盖 → "gateway"
↓
host = "gateway" → 启用 exec-approvals.json
↓
查白名单（allowlist）
↓
命中？→ 是 → 直接执行
↓否 ask 模式？
→ on-miss/always → 广播审批（Web UI）
→ off → 直接执行

执行命令 → Gateway 检查 allowlist
↓命中 → 直接执行
↓ 未命中 + ask=on-miss → 广播到连接的 Control UI 客户端
↓ 客户端弹窗 → 用户点击 Allow/Deny
↓ 30秒超时无响应 → askFallback 决定（默认 deny）

效果图

• openclaw.json

• exec-approvals.json

执行过程：

还有就是最简单的，告诉Openclaw在执行删除操作/命令前，必须询问用户，征得用户同意才允许执行，其会加入Mermory（由于是偏好，Agent.md里明确要求偏好会被拿出来作为上下文，所以这条规则会被作为规则放在上下文）

四、支持审批接收的客户端

目前 所有主流插件都还不支持 approvals 功能，包括：

• QQBot

• 飞书

• 企业微信

• 钉钉

• Telegram

• Discord

• Slack

• WhatsApp

1️⃣ approvals 是 OpenClaw 新功能

插件生态还没来得及适配。

2️⃣ 实现复杂度较高

插件需要实现完整流程：

Agent触发审批
↓
插件接收审批事件
↓
发送消息到聊天平台
↓
用户发送 /approve 命令
↓
插件解析命令
↓
回传审批结果

所以目前大多数插件 还没实现这套机制。

推荐配置（安全 + 不影响使用）

在当前生态下，最推荐的方案是：

使用 allowlist + 超时拒绝

既安全，又不会卡住 Agent。

1️⃣ exec-approvals.json

路径：

~/.openclaw/exec-approvals.json

推荐配置：

{
  "defaults": {
    "security": "allowlist",
    "ask": "on-miss",
    "askFallback": "deny"
  },
  "agents": {
    "main": {
      "allowlist": [
        "git*",
        "ls*",
        "cat*",
        "pwd",
        "echo*",
        "mkdir*",
        "rm*",
        "cp*",
        "mv*",
        "npm*",
        "python*"
      ]
    }
  }
}

配置解释

2️⃣ openclaw.json

路径：

~/.openclaw/openclaw.json

配置：

{
  "tools": {
    "exec": {
      "host": "gateway"
    }
  }
}

作用：

所有 exec 默认走 gateway

这样才能启用：

exec-approvals.json

实际工作流

系统执行逻辑：

Agent执行命令
↓
检查 allowlist
↓

1️⃣ 白名单命令

例如：

git pull
ls
cat file.txt

行为：

自动执行
无需审批

2️⃣ 非白名单命令

例如：

curl http://xxx
docker run
rm -rf /

行为：

触发审批
↓
30秒无响应
↓
自动拒绝

优点：

• 不会卡住 Agent

• 防止危险操作

• 系统保持安全

安全问题

接入了邮件、日历、浏览器——你的助手现在能触碰非常多的个人数据。安全是必须认真对待的事。

除了刚才说的控制OpenClaw不执行危险命令（毕竟不能完全覆盖不可执行命令），还有一下注意点。

建议你先做一次安全体检（尤其是改过配置或暴露过网络端口之后）：

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix  # 确认无误再用

⚠️ 浏览器相关提醒：Browser Relay / CDP（ Chrome DevTools Protocol ） 基本等同"远程操作权限"，只建议在 localhost 或 tailnet 内使用，避免暴露到公网。

1. API Key 安全

• 永远不要把 API Key 提交到 Git

• 用环境变量或 .env 文件存储

• 定期轮换密钥

2. OAuth Token 安全

• token.json 等文件包含你的 Google 授权信息

• 确保文件权限设置正确：chmod 600 token.json

• 不要传到任何公开的地方

3. 权限最小化原则

只给助手它需要的权限。比如 Gmail，如果你只需要读邮件，就不要给"发送邮件"的权限。虽然 OpenClaw 默认需要确认才会发，但少一个权限就少一个风险。

4. 网络安全

• 服务器开启防火墙，只暴露必要端口

• SSH 用密钥认证，禁用密码登录

• 定期更新系统：sudo apt update && sudo apt upgrade

5. 行为边界

在 SOUL.md 和 AGENTS.md 中明确写好：

• 什么操作需要确认

• 什么数据不能外传

• 什么情况下该拒绝执行

💡 安全不是装上锁就完事的，它是一种习惯：养成良好的安全习惯：API Key 不入库、Token 文件设权限、权限最小化、行为边界写清楚。

多设备协作

你的助手现在跑在一台服务器上。但如果它能同时「看到」你的手机摄像头、「控制」你电脑的浏览器、「访问」你家里的智能设备呢？

这就是 Nodes（节点） 系统。

什么是 Nodes？

Node 是一个安装在其他设备上的轻量级客户端，它和你的 OpenClaw 主服务器连接，让助手能：

• 手机 Node：拍照（前后摄像头）、获取位置、发系统通知

• 电脑 Node：截屏、录屏、控制浏览器

• 树莓派 Node：控制智能家居设备

示例场景

场景 1：远程查看 你出差在外，对助手说："帮我看看公司电脑屏幕上显示什么"——装了 Node 的公司电脑自动截屏发给你。

场景 2：手机协作 助手在你手机上弹出通知："下午 3 点有个会议，要我帮你打开会议链接吗？"——你点确认，它直接在手机上打开。

场景 3：智能家居 "帮我把客厅灯关了" → 助手通过树莓派 Node 控制 HomeAssistant → 灯关了。

如何设置

在要连接的设备上安装 Node 客户端：

# 电脑端
curl -fsSL https://openclaw.ai/install.sh | bash

手机端在 App Store 搜索 OpenClaw（目前支持 iOS）。

安装后，在主服务器上批准配对请求：

openclaw nodes approve <device-name>

配对完成后，你可以在 Telegram 里直接下达跨设备指令。

🦞的"分身术"

一句话总结：主🦞可以生成多个子Agent并行干活，干完自动汇报结果。

需要明确的触发，但怎么触发？

1️⃣ 手动触发（你明确命令）

你直接告诉主Agent：

"帮我调研：1) React19新特性 2) Vue 3.5更新 3) Svelte 5变化"
主Agent理解后，自动调用sessions_spawn启动3个子Agent并行工作。
关键：你只需要说需求，不需要自己写spawn代码

2️⃣ 自动触发（系统配置）

某些场景下，主Agent根据配置自动决定是否用子Agent：
• 复杂任务分解（收到大型需求自动拆分）
• 超时任务（主任务快超时了，自动spawn子Agent并行）
• 技能内部（某些技能本身就使用子Agent）
🔄 实际工作流程

你的消息："做个全面的竞品分析（5个产品）"
        ↓
主Agent分析需求        ↓
判断：需要并行 → 决定spawn子Agent
        ↓
主Agent调用 sessions_spawn 工具
        ↓
系统启动多个子Agent会话（每个独立workspace）
        ↓
子Agent并行执行（查资料、写分析、做图...）
        ↓
子Agent完成后 → 自动发送结果给主Agent
        ↓
主Agent汇总 → 回复你最终答案

🎪 你看到的现象
对你来说：
• 你只说需求："帮我做X"
• 主Agent内部决定是否用子Agent
• 你不需要知道细节，它自己处理
如果你要看：
openclaw sessions list --kinds subagent
可以看见所有运行中的子Agent

子Agent的核心规则

在很多时候，OpenClaw的main Agent总是不记得采用sub-agent模式来工作，main Agent自己在同一个session中既要工作又要跟我们互动，一个活儿干的稀碎。
如果想保持一个session只负责沟通，一个session去执行任务，就需要采用sessions_spawn模式；启动sub-agent模式最好是显式跟main Agent讲：

请采用sessions_spawn模式启动sub-agent来完成xxx任务

如果你要指定特定的agent来完成该任务，则应该显式提醒main Agent：

请采用sessions_spawn模式启动agent-yyy来完成xxx任务

如果你的OpenClaw中只有main Agent自己一个，那么sessions_spawn就只是main Agent自己的“影分身”，它的SOUL.md、IDENITY.md等配置文件都是通用的，并没有为特定任务进行“特化”（塞太多特化prompt到同一个md文件中也不是明智之举），这就导致main Agent大概率是干啥都半吊子，所谓“一瓶不满半瓶咣当”

1️⃣子Agent独立会话运行

2️⃣不阻塞主Agent

3️⃣禁止套娃

默认禁用 sessions_spawn 等会话工具，避免递归调用。

4️⃣并发上限默认8个

agents.defaults.subagents.maxConcurrent 默认值为 8。

5️⃣完成后自动回传

子Agent完成任务后自动发布通告，包含：

• Status：success / error / timeout / unknown

• Result：结果摘要

• Notes：错误详情

• 运行统计：耗时、Token 用量、预估成本

如果子Agent回复 ANNOUNCE_SKIP，则不发布通告。

注意：子Agent结果会自动回传给主Agent，主Agent的LLM会自己总结出子Agent的Status+Result+Notes。

6️⃣省钱配置（主/子用不同模型）

可以分别配置主Agent和子Agent使用不同模型，节省成本。如果没配置模式用主Agent的模型

{
  agents: {
    defaults: {
      subagents: {
        maxConcurrent: 8, // ✅ 并发上限
        model: "gemini-2.5-flash"      // ✅ 子Agent默认模型
      }
    }
  }
}

子 agent 用便宜的模型，会不会影响整体运行效果？

核心结论

• 通常不会影响整体效果，前提是任务合理分解、主Agent负责关键智能部分。

• 便宜子Agent适合：信息收集、数据整理、简单任务。

• 不适合：深度推理、创意写作、复杂代码、最终交付物生成。

✅ 原因分析

示例：

主任务：做竞品分析
主Agent（强模型）分解子任务：
├─ 查React19新特性清单（信息检索）
├─ 查Vue 3.5更新日志（信息检索）
├─ 查Svelte 5变化（信息检索）
└─ 汇总对比表（综合 → 主Agent自己做）

子任务本身是“简单/机械”的，便宜模型足够。

主Agent负责“智能”部分

• 任务理解、分解策略 → 主Agent强模型

• 结果汇总、质量把关 → 主Agent强模型

• 最终交付物生成 → 主Agent强模型

子Agent只是“执行具体指令”，不需要强推理能力。

主Agent可重做或优化

• 如果子Agent结果质量差，主Agent强模型可以：

• 识别质量问题

• 自己重做或用其他子Agent重做

• 最终输出仍由强模型把关

智能分配是由主Agent+LLM推理思考后才会决定要不要拆解任务给子Agent干以及会检查子Agent干得怎么样及决定要不要返工自己来。

7️⃣工具权限控制

子Agent默认获得除会话工具外的所有工具。以下工具被默认禁用（防止它自己再开子Agent）：

• sessions_list

• sessions_history

• sessions_send

• sessions_spawn

OpenClaw 的典型目录结构

~/.openclaw/
├── openclaw.json          # 多智能体总控配置
├── workspace/             # 默认工作区（主agent）
│   ├── AGENTS.md
│   ├── SOUL.md
│   ├── TOOLS.md
│   └── memory/
│
├── agents/                # 各agent的运行态目录
│   └── <agentId>/
│       ├── agent/         # agentDir：状态、认证、模型配置
│       │   ├── auth-profiles.json
│       │   └── models.json
│       │
│       ├── sessions/      # 会话历史记录
│       │   ├── sessions.json
│       │   └── *.jsonl
│       │
│       └── subagents/     # 子任务运行登记
│           └── runs.json

一句话记忆：workspace是办公桌（工作内容），agentDir是档案柜（运行状态），sessions是工作日志（历史记录），subagents是任务派工单。

一、workspace：Agent 的工作区

在 OpenClaw 里，workspace 可以理解成一个 agent 的“工作目录”或“办公桌”。

这里通常放的是 agent 运行时会读取的上下文文件，比如：

• AGENTS.md

• SOUL.md

• USER.md

• TOOLS.md

• memory/

• 其他工作区级别的说明和资料

这些文件决定的不是“系统状态”，而是这个 agent 的：

• 工作方式

• 身份设定

• 语气和边界

• 可以读取到的长期/短期上下文

所以，workspace 更接近：

这个 agent 用来思考和工作的环境

而不是一个纯粹的配置缓存目录。

默认情况下

OpenClaw 的默认工作区一般是：

• • ~/.openclaw/workspace

如果是多 agent，也常见这种命名方式：

• • ~/.openclaw/workspace-<agentId>

但这里要注意一点：

这只是常见默认路径，不是强制命名规则。

OpenClaw 真正认的，是配置文件里给每个 agent 指定的 workspace 路径。

二、agentDir：Agent 的状态目录

如果说 workspace 是办公桌，那 agentDir 更像档案柜。

它通常对应类似这样的路径：

• ~/.openclaw/agents/<agentId>/agent

这里放的是更偏运行态、系统态的内容，比如：

• auth-profiles.json

• models.json

• 认证相关信息

• 模型配置

• agent 自己的状态文件

这部分和 workspace 的区别非常重要：

workspace

偏向：

• • 可编辑

• • 面向工作内容

• • 面向上下文和人格

agentDir

偏向：

• • 运行态

• • 面向系统配置

• • 面向认证、模型与状态

之所以分开，是因为 OpenClaw 在设计上明确区分了：“怎么工作” 和“怎么运行”

三、sessions：每个 Agent 的会话记录

除了 workspace 和 agentDir，每个 agent 还有自己的会话存储。

常见路径会是：

• ~/.openclaw/agents/<agentId>/sessions

这里面通常会看到：

• sessions.json

• *.jsonl

• 一些 lock / deleted / reset 文件

这一层记录的是：

• 这个 agent 跑过哪些会话

• 每个会话的 transcript

• 哪些会话被清理、重置、归档

所以它更像：

这个 agent 的工作日志系统

这也说明一个关键点：

OpenClaw 不是“所有 agent 共用一份会话历史”，而是按 agent 分开管理。

四、subagents：子任务运行登记

再往下，就会碰到另一个容易和 agents 混淆的目录：

• subagents

这个目录不是“另一批 agent 本体”，而更像：

子代理运行记录和调度索引

例如你会看到：

• runs.json

它用来记录的，不是 agent 的人格设定，也不是 workspace，而是：

• 谁 spawn（调度） 子任务

• 子任务运行到了哪里

• runId、状态、完成情况等

所以：

agents/<id>/sessions

存的是某个 agent 自己的会话历史

subagents/runs.json

存的是子代理任务的运行登记

两者不是一回事。

五、sessions_spawn

理解多智能体时，最容易问的一个问题是：

sessions_spawn( “根据配置，实例化一个 Agent” ) 到底是在调用哪个目录里的 agent？

这个问题如果只从目录结构看，很容易越看越乱。更准确的答案是：

sessions_spawn 调用的不是“某个目录”，而是“配置中定义好的 agent”。

也就是说，它的工作逻辑不是：

• 去磁盘上扫一圈

• 看到哪个目录像 agent 就拿来用

它真正做的是：

1. 根据 agentId 找到配置里的目标 agent

2. 读取这个 agent 对应的 workspace

3. 读取这个 agent 对应的 agentDir

4. 在这个 agent 的上下文和状态下启动一个新的子会话

所以，sessions_spawn 的本质不是“目录发现机制”，而是：

一个基于 agent 配置的会话生成机制

六、agents_list 是什么？它不是配置，是工具

要理解这一章，必须先搞清楚 OpenClaw 中”工具（Tool）”的概念。

什么是工具？

在 OpenClaw 的语境下，工具是 agent 可以调用的功能单元。你可以把它理解为 agent 的”手脚”——agent 通过调用工具来与外部世界交互。

OpenClaw 提供的工具包括但不限于：

工具 vs 配置：本质区别

这是最容易混淆的地方：

举个例子：

• agents_list是工具 → 就像相机 App，agent 可以”打开”它来查看有哪些 agent 可用

• subagents.allowAgents是配置 → 就像相机设置里的白名单，规定了 agent 能看到谁

agents_list 如何使用？

当你在 OpenClaw 界面中和 agent 对话时说：

“你能帮我列出你现在可以调用的其他 agent 吗？”

当前 agent 会主动调用 agents_list 这个工具，返回可调用的 agent 列表。

类似地：

• “帮我读取这个文件” → agent 调用 Read 工具

• “让 seo-specialist 来帮我分析” → agent 调用 sessions_spawn 工具

常见误区

很多人以为：

只要磁盘上存在一个 agent 目录，agents_list 就应该把它列出来

但事实并非如此。agents_list 返回的不是”磁盘上有什么”，而是当前上下文中，哪些 agent 被允许通过 sessions_spawn 调用。

那它查的是哪些配置？

当 agents_list 执行时，它实际上会去检查以下几个来源：

具体示例

假设 ~/.openclaw/openclaw.json 内容如下：

{
  “agents”: [
  {
  “id”: “manager”,
  “workspace”: “~/.openclaw/agency-agents/manager”,
  “agentDir”: “~/.openclaw/agents/manager/agent”,
  “subagents”: {
    “allowAgents”: [“seo-specialist”, “frontend-developer”, “copywriter”]
  }
},
{
  “id”: “seo-specialist”,
  “workspace”: “~/.openclaw/agency-agents/seo-specialist”,
  “agentDir”: “~/.openclaw/agents/seo-specialist/agent”
},
{
  “id”: “frontend-developer”,
  “workspace”: “~/.openclaw/agency-agents/frontend-developer”,
  “agentDir”: “~/.openclaw/agents/frontend-developer/agent”
},
{
  “id”: “copywriter”,
  “workspace”: “~/.openclaw/agency-agents/copywriter”,
  “agentDir”: “~/.openclaw/agents/copywriter/agent”
},
{
  “id”: “data-analyst”,
  “workspace”: “~/.openclaw/agency-agents/data-analyst”,
  “agentDir”: “~/.openclaw/agents/data-analyst/agent”
}
]
}

注意看：

• • 系统中总共配置了 5 个 agent（manager、seo-specialist、frontend-developer、copywriter、data-analyst）

• • 但 manager 这个 agent 的 subagents.allowAgents 只设置了 [“seo-specialist”, “frontend-developer”, “copywriter”]

• • 不包括data-analyst

所以当 manager 调用 agents_list 时，它只能看到：

• • seo-specialist

• • frontend-developer

• • copywriter

它看不到data-analyst，即使 data-analyst 确实在系统中存在。

💡 关键点：subagents.allowAgents 是在 openclaw.json 的每个 agent 配置里设置的权限白名单。

一句话总结

核心逻辑：agents_list 工具查询 openclaw.json 全局配置，再受 subagents.allowAgents 权限过滤，最终返回当前 agent 可调用的其他 agent 列表。

七、openclaw.json 才是多智能体的总控台

前面这些概念如果只看目录，很容易觉得零散。真正把它们串起来的是：

• ~/.openclaw/openclaw.json

在多 agent 场景下，这个配置文件会定义每个 agent 的关键属性，比如：

• id

• workspace

• agentDir

• model

• tools

• bindings

• subagents.allowAgents

换句话说：

目录只是承载内容的地方，配置才是 OpenClaw 真正理解 agent 的入口。

例如一个 agent 的配置，可能会长这样：

{
  "id": "manager",
  "workspace": "~/.openclaw/agency-agents/manager",
  "agentDir": "~/.openclaw/agents/manager/agent",
  "subagents": {
    "allowAgents": ["seo-specialist", "frontend-developer"]
  }
}

或者一个没有子 agent 权限限制的简单配置：

{
  "id": "seo-specialist",
  "workspace": "~/.openclaw/agency-agents/seo-specialist",
  "agentDir": "~/.openclaw/agents/seo-specialist/agent"
}

OpenClaw 看到的是这份配置，而不是“这个目录名字听起来像不像工作区”。

八、现在再来谈 agency-agents：它到底是什么？

讲到这里，才适合引入 agency-agents。

因为这时就能把它放到一个正确的位置上：

agency-agents 不是 OpenClaw 原生固定目录，而是一种外部 agent workspace 的组织方式。

这点必须强调。

OpenClaw 原生并不要求你必须有：

• ~/.openclaw/agency-agents

这个目录名不是内建保留字，也不是系统默认必须存在的层级。

它之所以在当前实例里“有效”，是因为：

• 某些 agent 的 workspace

• 被配置到了 ~/.openclaw/agency-agents/<agent-id>

也就是说：

OpenClaw 原生负责的是：

• 认 workspace

• 认 agentDir

• 认 agentId

• 认配置

agency-agents 提供的是：

• 一批预先写好的 agent workspace

• 一种方便组织角色模板的目录结构

所以它更像：

被接入 OpenClaw 的 agent 模板/workspace 仓库

九、agency-agents 和 OpenClaw 原生概念如何对应？

如果当前机器把某个 agent 配成这样：

• • workspace = ~/.openclaw/agency-agents/seo-specialist

• • agentDir = ~/.openclaw/agents/seo-specialist/agent

那么它们的关系就是：

~/.openclaw/agency-agents/seo-specialist对应的是这个 agent 的 workspace

~/.openclaw/agents/seo-specialist/agent对应的是这个 agent 的 agentDir

~/.openclaw/agents/seo-specialist/sessions对应的是这个 agent 的 会话历史

十、那 agency-agents 应该怎么安装？

讲到这里，安装逻辑就容易明白了。

如果 agency-agents 只是一个外部 workspace 模板来源，那么“安装它”就不应该被理解成：

把 repo clone 下来就完事

更准确的理解应该是：

把这些 workspace 接入 OpenClaw 的 agent 配置体系。

通常要经过几步：

第一步：准备 workspace

例如：

• ~/.openclaw/agency-agents/seo-specialist

这里放角色工作区内容。

第二步：准备 agentDir

例如：

• ~/.openclaw/agents/seo-specialist/agent

这里放状态目录。

第三步：注册进 OpenClaw

也就是把这个 agent 写进 openclaw.json，或者通过官方命令添加：

openclaw agents add seo-specialist \

--workspace ~/.openclaw/agency-agents/seo-specialist \

--agent-dir ~/.openclaw/agents/seo-specialist/agent \

--non-interactive

备注：当然，你并不真的需要挨个安装，只需要把agency-agents的Github仓库喂给openclaw，让它理解之后安装即可；

这一步完成后，OpenClaw 才真正“认识”这个 agent。

所以，“安装 agency-agents”这件事，本质上不是文件复制，而是：

workspace 落地 + agentDir 准备 + agent 配置注册

十一、OpenClaw 是怎么调用这些来自 agency-agents 的 agent 的？

答案其实已经呼之欲出了：

OpenClaw 调用的不是“agency-agents 目录”，而是：

配置文件中定义的 agent

而这个 agent 的 workspace，恰好指向了 agency-agents 里的目录。

所以链路是：

1. sessions_spawn(agentId=...)

2. OpenClaw 查配置

3. 找到该 agent 的 workspace

4. 找到该 agent 的 agentDir

5. 用这套上下文和状态启动子会话

这也是为什么：

• agency-agents 本身不是内置概念

• 但它依然可以很好地融入 OpenClaw 体系

因为 OpenClaw 看的是“配置结果”，不是“目录名字”。

十二、工作中到底该怎么用多 agent 协作？

把概念讲清楚之后，再谈工作方法才不会漂。

1. 单 agent 适合什么情况？

如果任务是：

• 短

• 集中

• 不需要多角色分工

• 不需要并行探索

那单 agent 就够了。

例如：

• 看一份日志

• 回答一个技术问题

• 改一段简单脚本

这类任务硬拆成多 agent，反而会增加协调成本。

2. 什么时候该用 sessions_spawn 启动其他 agent？

当一个任务天然带有“分工需求”时，通过 sessions_spawn 启动其他 agent 才真正有价值。

典型场景 A：主从协作模式

• • 主 agent 负责总控和用户对话

• • 通过 sessions_spawn 启动 seo-specialist 分析关键词

• • 通过 sessions_spawn 启动 frontend-developer 实现页面

• • 主 agent 汇总结果，统一输出

这时候的意义不是“多开几个窗口”，而是给不同任务块分配稳定角色。

典型场景 B：临时专项任务

• • 已经有主任务在进行

• • 但其中一个子问题可以独立解决

• • 希望隔离上下文，避免污染主会话

• • 或者希望并行推进，节省时间

这时候 sessions_spawn 相当于把一个临时专项任务派给另一个 agent 去做，主 agent 继续自己的主线工作。

3. 主 agent 如何管理 spawn 出来的 agent？

一旦通过 sessions_spawn 启动了其他 agent，主 agent 可以通过以下工具进行管理：

关键点：

• Sub-agent 的会话是独立的 —— 主 agent 和 sub-agent 各自有独立的 sessions 目录记录

• 主 agent 可以随时查看进度 —— 通过 sessions_history 检查 sub-agent 的工作进展

• 任务完成后结果会返回 —— sub-agent 完成后，结果会汇总给主 agent

• 并发执行是支持的 —— 可以同时 spawn 多个 sub-agent 并行工作

例如，主 agent 可以这样操作：

"帮我 spawn 一个 seo-specialist 去分析关键词，同时 spawn 一个 copywriter 去写标题。等他们都完成后，汇总结果给我。"

这就是典型的主从协作管理模式。

例如：

• 主 agent 继续和用户对话

• 同时 spawn 一个 agent 去分析仓库结构

• 再 spawn 一个 agent 去整理竞品资料

• 最后统一收口

这就是很典型的 sub-agent 工作方式。

4. 一个实用原则：按“产出物”拆，不按“动作”拆

这是多智能体协作里最实用的一条经验。

不要这样拆：

• 你看文件 A

• 你看文件 B

• 你看文件 C

更好的拆法是：

• 你产出技术方案

• 你产出风险清单

• 你产出用户说明

• 你产出执行计划

也就是说：

让每个 sub-agent 对一个结果负责，而不是只负责一个动作。

这样最后汇总起来，质量和清晰度都会高很多。

Openclaw中Skills的分层调用机制

一、先别把 skill 和 tool 混为一谈

这是最核心的一层。

在 OpenClaw 里，skill 和 tool 不是同一个东西。

1. tool 是能力

tool 更像“手和脚”，是 agent 真正可以直接调用的操作能力，例如：

• read

• write

• edit

• exec

• browser

• sessions_spawn

• memory_search

tool 决定的是：

• 能不能读文件

• 能不能写文件

• 能不能起子代理

• 能不能查网页

• 能不能控制浏览器

也就是说，tool 解决的是“能不能做”。

2. skill 是工作方法和操作说明

skill 更像“作战手册”或者“标准流程”。

一个 skill 通常会告诉 agent：

• 在什么场景下应该启用它

• 先读哪个 SKILL.md

• 遇到这个问题应该走什么 workflow

• 需要用哪些脚本、参考资料或外部命令

所以，skill 解决的是：

• 应该怎么做

• 按什么步骤做

• 什么时候用这套流程最合适

一句话概括就是：

• tool 是能力层

• skill 是方法层

这也是为什么“一个 agent 看得见某个 skill”，并不自动等于“它一定能把这个 skill 完整执行成功”。

因为 skill 只是指导，真正落地还取决于：

• tool 权限是否足够

• 文件路径是否可访问

• 当前 workspace 是否能看到对应资源

• 这个 skill 是否被 agent 的技能过滤规则允许

二、一个 skill 目录里通常有什么

OpenClaw 的一个 skill，最核心的入口文件是：

• SKILL.md

除此之外，还可能带一些辅助资源，例如：

• references/

• scripts/

• 示例文件

• 配套说明文档

一个典型 skill 看起来会像这样：

some-skill/
├── SKILL.md
├── references/
│ └── workflow.md
└── scripts/
└── helper.py

其中：

SKILL.md

负责说明：

• skill 什么时候触发

• 应该先做什么，再做什么

• 需要额外读哪些参考文件

• 需要调用哪些脚本或工具

references/

负责放详细说明，例如：

• API 参考

• 工作流说明

• 复杂规则

• 错误处理手册

scripts/

负责放真正复用的脚本，例如：

• 格式转换脚本

• 导入导出脚本

• 自动化辅助工具

所以 skill 不是“只有一个 markdown 文件”，而是一组围绕某种任务组织起来的资源。

三、OpenClaw 里的 skill 来源，不止一层

理解 skills 机制，最容易误解的地方，就是以为“skill 只有一个统一目录”。

实际上，OpenClaw 会从多个层次去发现 skill。

可以把它理解成三层：

第一层：全局安装层

这是 OpenClaw 安装包自带的一批 skills，典型位置类似（以腾讯云轻量应用服务器的OpenClaw镜像为例）：

• .../node_modules/openclaw/skills

这里放的通常是：

• 随 OpenClaw 一起分发的通用 skill

• 偏系统级、官方级、基础能力级的 skills

例如你可能会看到：

• skill-creator

• healthcheck

• tmux

• clawhub

• video-frames

• weather

这层可以理解成：

OpenClaw 安装级别的全局技能库

第二层：共享层

这是很多人真正关心、但最容易没讲清的部分。

从机制上看，OpenClaw 还会扫描一些不属于某个单独 agent workspace 的公共目录，例如：

• ~/.openclaw/skills

• ~/.agents/skills

这类目录更适合放“跨 agent 复用”的自定义 skill。

也就是说，如果你的目标是：

• main agent 能用

• imported agents（例如agency-agents）能用

• 通过 sessions_spawn 拉起的 sub-agent 也更大概率能看到

那比起只放到某个 agent 的私有 workspace 里，更适合放到这种公共共享层里。

这层可以理解成：

机器级、配置级、跨 workspace 的共享技能库

第三层：agent 自己的 workspace 层

每个 agent 自己的 workspace 下面，也可能有 skills 目录，例如：

• ~/.openclaw/workspace/skills

• ~/.openclaw/agency-agents/<agent-id>/skills

• ~/.openclaw/workspace/.agents/skills

• ~/.openclaw/agency-agents/<agent-id>/.agents/skills

这一层更像：

某个特定 agent 的本地技能库

这类 skill 最大的特点是：

• • 更接近这个 agent 自己的工作区

• • 更适合放该 agent 专用的 workflow

• • 不应默认假设别的 agent 也一定能自动共享到

四、main agent 和 agency-agents 的 skill 关系，不是天然完全一致

这部分最值得讲透。

1. main agent 通常有自己的 workspace

例如：

• ~/.openclaw/workspace

那么它的本地 skill 往往会放在：

• ~/.openclaw/workspace/skills

2. agency-agents 通常各自也有 workspace

例如：

• ~/.openclaw/agency-agents/software-architect

• ~/.openclaw/agency-agents/product-manager

• ~/.openclaw/agency-agents/security-engineer

那么这些 agent 各自的本地 skill 往往放在：

• ~/.openclaw/agency-agents/software-architect/skills

• ~/.openclaw/agency-agents/product-manager/skills

• ~/.openclaw/agency-agents/security-engineer/skills

这意味着一个关键事实：

main agent 的本地 workspace skill，并不天然等于所有 imported agent 的本地 skill。

也就是说：

• main 能看到的 skill

• 其他 imported agent 不一定天然就看得到

它们能否共享，要看 skill 究竟放在哪一层。

五、sub-agent 能不能用 main agent 的 skill？

这是大家最容易直接问的问题。

更准确的回答不是“能”或者“不能”，而是：

要看这个 skill 是落在私有层，还是落在共享层，以及子代理运行时的可见范围和边界策略。

不过把机制说完之后，可以把判断逻辑归纳成下面这几种情况。

情况 A：skill 在全局安装层

例如这个 skill 在 OpenClaw 自带的全局 skills 目录里。

那么通常：

• main agent 可以用

• imported agents 也大概率可以用

• sessions_spawn 拉起的 sub-agent 通常也可以用

前提是：

• tools 权限允许

• agent 没有额外的 skills filter 把它禁掉

这类 skill 属于“最像公共能力”的那种。

情况 B：skill 在共享层

例如放在：

• ~/.openclaw/skills

• ~/.agents/skills

那么它也更像一份机器级共享能力。

这种放法通常适合：

• 希望多个 agent 复用

• 希望 main 和 imported agents 都能稳定发现

• 希望把某个 workflow 做成公共基础设施

如果你要做“公司内部通用 skill”或者“整套 multi-agent 公共工作流 skill”，这层通常比某个 workspace 私有目录更合适。

情况 C：skill 只在 main 的 workspace 层

例如：

• ~/.openclaw/workspace/skills/tencent-docs-safe-write

这时要注意：

• main agent 当然最容易用到它

• imported agent 或 sub-agent 是否也能用，不应默认想当然

因为这里至少有三种可能：

1. 子代理真的可以直接读到 main 的那条路径

2. 这份 skill 恰好也同步到了子代理自己的 workspace 里

3. 当前环境存在更宽的技能发现或文件访问边界

所以对于“只放在 main workspace 的 skill”，最稳妥的态度不是拍脑袋，而是做实测。

六、一个很重要的实测经验：不要只靠猜目录，要验证“当前环境里的真实行为”

在实际排查中，很容易出现一种情况：

• 从源码逻辑推断，某个 agent 不该天然看见 main 的 skill

• 但实测却发现，它确实能读取这份 skill

这并不矛盾。

因为真实运行时，还可能受到这些因素影响：

• 该 skill 是否已经存在于目标 agent 自己的 workspace 下

• 当前 agent 的路径边界是否允许访问主 workspace

• 该 skill 是否被提前同步、安装、拷贝到了多个 agent 中

• 当前配置是否启用了额外共享目录

所以，对于 multi-agent 环境里的 skill 共享问题，最务实的结论往往是：

机制上先看层次，落实上一定要抽样实测。

尤其是当你在调试：

• main 的 skill 能不能被 agency-agent 复用

• imported agents（例如agency-agents） 之间是否都能共享某个 workflow

• 一个 skill 到底是私有、共享，还是已经被复制分发过

这时候实测比纯目录猜测更可靠，简单来说：直接测试比通过各种途径分析猜测给的结果更加简单直接且正确。

避免一个误解

一、先打破一个错觉（非常关键）

❌ skill = 被系统自动调用的插件

其实不是。

✅ 真相是：

👉 Skill 本质是“被 LLM 读取并执行的一段流程说明”

换句话说：

Skill ≈ Prompt + Workflow + 外部资源引用

它不会被系统主动执行

而是：

👉 Agent（LLM）自己“决定要不要用它”

二、Skill 的真实调用流程（核心重点）

你可以把整个过程理解成 6 步：

① 系统启动时：扫描 Skill

OpenClaw 会做一件事：

扫描多个目录 → 收集所有 SKILL.md → 建立 Skill Registry

类似：

Map<String, Skill> skillRegistry = loadAllSkills();

来源就是你文章说的三层：

• 全局层

• 共享层

• workspace 层

② Agent 启动时：加载“可见 Skill 列表”

当一个 Agent 被创建（包括 sessions_spawn）：

Agent 初始化 → 注入它“能看到的 skills”

注意：

👉 不是加载全部 Skill
👉 而是加载“它权限范围内的 Skill”

③ LLM 在推理时：看到 Skill 描述

关键来了👇

在一次对话中，LLM 实际收到的 Prompt 里会包含类似：

你可以使用以下 skills：

1. github-analyze
2. tencent-doc-write
3. report-generator

每个 skill 的说明如下：
...

👉 本质是：Skill 被“拼进 Prompt”

④ LLM 自己决策：要不要用 Skill

这一步是最核心的：

用户问题 → LLM思考 → 决定是否使用某个 skill

比如：

用户说：

帮我分析这个 GitHub 项目

LLM 可能会“触发”：

我应该使用 github-analyze skill

⑤ LLM 按 SKILL.md 执行流程

然后它会：

读取 SKILL.md → 按步骤执行

例如：

1. 使用 browser 打开 GitHub
2. 使用 read 获取 README
3. 使用总结逻辑生成报告

👉 注意：

这里没有“skill engine”在执行

而是：

👉 LLM 自己在“照着说明书干活”

⑥ 真正执行的是 Tool

Skill 只是“指挥官”，真正干活的是：

• read

• write

• browser

• exec

• sessions_spawn

例如：

{
  "tool": "browser.open",
  "args": {...}
}

一些坑（记住了就写）

1. 它没挂，是你绑住了它的手

在之前的版本里，默认的 tools.profile 是 messaging。你的代理只允许发消息。读文件、写文件、运行命令、用浏览器——全都被禁用了。

想象一下雇了个全职员工，但只给他一部电话和一把椅子。他就坐那儿。他能说话。但他什么都干不了。

"tools": {
  "profile": "full",
  "exec": { "security": "full", "ask": "off" }
}

两个开关。profile 控制有没有工具。exec.ask 控制用之前要不要问你。先设 profile，再设 exec。反过来设没用。

从某个版本开始，onboard 默认改成 coding 了。新安装不会遇到这个问题。但如果你是老用户，或者手动改过配置，检查一下。

2. 你最重要的规则可能从来没被读过

我在 AGENTS.md 里写了一条规则。我的代理一直无视它。

结果是那条规则在文件中间。它根本没进真正发给代理的上下文。

为啥？OpenClaw 对每个工作区文件有 20,000 字符限制。超过的部分会被静默截断。它保留前 70%，保留后 20%，中间 10% 直接砍掉。

没有错误提示。没有警告。你的代理在不完整的指令下运行，而你完全不知道。

怎么检查：在聊天里输入 /context list。如果你看到 TRUNCATED，就是被截断了。

修复方法：把最重要的规则放在文件顶部。中间是死亡区域。

如果你的文件确实需要很长，调整这两个设置：

"bootstrapMaxChars": 20000,
"bootstrapTotalMaxChars": 150000

第一个是单个文件限制。第二个是所有文件加起来的限制。

3. 你 80% 的 API 费用是在烧钱

两周后，我打开 token 仪表盘。80% 是输入。不是输出。

我的代理不是在思考。它是在复习。每一轮对话，它都重新读一遍系统提示、工具定义、SOUL.md、还有完整的聊天记录。在发每条消息之前，它都从头到尾复习一遍它的世界观。

有个读者给我看他的数据：1.39 亿输入，93.5 万输出。比例是 148:1。他的代理每轮对话塞进去 52KB 上下文。光是 MEMORY.md 就 22KB。每条消息都以重读一本小书开始。

想象一下一个员工每天早上开工前，先把所有公司政策文件读上两小时。他大部分工资都花在阅读上了。

修复方法很简单：核心规则放 SOUL.md 里。其他东西都移到 memory 文件夹，让代理通过 memory tools 按需读取。

并且可以让小龙虾自动检测上下文长度，超过一定阈值自动进行压缩（默认到百分之90还是80才会触发自动压缩）；或者手动调用/compact进行压缩

改完之后，token 消耗下降了 40-60%。输出质量没变。

4. 别在模型上省钱，省你的时间

很多人本能地选择最便宜的模型来跑代理。

我试过。便宜模型省了 20 美元。然后我花了一小时修输出。又花了一小时解释哪里出错了。重写提示词。再跑一遍。最后还是切回最强模型。一次就搞定了。

我省下的 20 美元，花了我一整天。

我的做法：一个最高档订阅。所有代理都用它跑。不按 token 计费。没有用量焦虑。代理想调用多少次就调用多少次，提示词想写多长就写多长。

但这里有个区别：不是所有代理都需要同一个模型。

跟人聊天的代理需要 Opus。它得理解语气、读懂情绪、写得像个人。便宜模型干不了这个。

拉数据、扫通知、整理内容的代理用 GPT-5.4 更好。不是因为它便宜，而是因为它更快、更稳定、更听话。Opus 会把简单任务想复杂。扫垃圾邮件的时候，它会分析语气、猜测意图。写日报的时候，它会加自己的看法。

agents:
  defaults:
    model:
      primary: "openai/gpt-5.4"
  list:
    - id: community-bot
      model: "anthropic/claude-opus-4-6"

这不是为了省钱。这是为了给合适的活配合适的工具。

5. 你的记忆系统三周后就会崩

第一天看 MEMORY.md 还挺清爽。三周后它就是个垃圾抽屉。

译者注：memory在 ~/.openclaw/workspace 目录下

上个月过时的决策跟今天的新计划挤在一起。当代理搜索记忆时，它分不清新旧。它经常捞到一个月前的信息，当成当前事实来处理。

你的桌子上堆了三个月的文件。你紧急需要一份合同。你抽出来一份。是上个月过期版本。你基于过时条款签了字。

你不需要在第一天就设计三层记忆架构。你的代理还没干成一件有用的事呢。你设计个啥？

打开 OpenClaw 内置的 temporal decay（时间衰减）。新记忆权重更高。旧记忆自动衰减。不需要手动清理。

80% 的记忆问题解决了。

记忆问题是跑出来的，不是设计出来的。先跑起来再说。

6. 没人接收输出的代理，是你成本的超级黑洞

第一次代理跑起来的时候，我想让它干所有事。协调员、分析师、战略师、编辑、运营。组织架构图画出来可漂亮了。

然后我发现：一半Agent每天都在生产输出，但没有任何Agent或人消费这些输出。没人读的日报。没人看的分析。什么都不需要审批的审批流程。

现在每个代理开工前必须回答三个问题：

1. 我产出什么
2. 谁接收我的输出
3. 我绝不碰什么

答不出第 2 题？这个岗位不该存在。

我在所有代理上跑了这个测试。砍掉一个。token 消耗下降 44%。速度提升 62%。

起步建议：一个代理，一个任务，一个你每天都会实际查看的输出。等它稳定了，再加第二个。

7. 五个代理不该挤在一个房间

各司其职~

8. 你的代理不知道是谁在跟它说话

你的代理收到一条消息。它根本不知道是你发的、另一个代理发的、还是某个外部系统发的。它一视同仁，全部执行。

就像你的员工收到一封邮件就跟着指令做，不查是谁发的。谁都能冒充你。

OpenClaw 的 ACP bridge 现在支持 provenance mode（来源模式）：

openclaw acp --provenance off          # 禁用
openclaw acp --provenance meta         # 消息带来源标签
openclaw acp --provenance meta+receipt # 来源标签 + 代理能看到可见的来源回执

meta 让系统知道消息从哪来。meta+receipt 让代理也能看到。

建议配置：

• 生产环境建议 meta+receipt，让 Agent 知悉来源

• 在 Agent 的 SOUL.md 中添加验证逻辑：拒绝非预期来源的指令（例如只有来自主用户或特定 Agent 的指令才执行）

9. 没人提醒你备份

所有人教你安装 OpenClaw。没一个人说先备份的事。

我有一次丢了整个配置。花了一整天手写重建 SOUL.md。凭记忆重写每条规则。重建的版本更差，因为我记不住当初编码进原版的一半边界情况。

OpenClaw 现在支持 原生备份：

openclaw backup create
openclaw backup create --only-config
openclaw backup create --no-include-workspace
openclaw backup verify <archive>

默认会打包本地状态、配置、凭证和会话。工作区是可选的。

我一直在跑每周 VPS 备份。现在加上这个，双重保险。

10、控制上下文长度

🎯 OpenClaw 解决上下文过长的三大机制

1️⃣ Compaction（压缩）

作用：将较旧的历史对话总结成摘要，保留最近的消息
触发时机：

配置参数（agents.defaults.compaction）：

{
  "agents": {
    "defaults": {
      "compaction": {
        "mode": "auto",              // auto | off
        "reserveTokensFloor": 20000, // 保留的 token 下限
        "softThresholdTokens": 4000, // 软阈值（接近时警告）
        "memoryFlush": {             // 压缩前是否 flushing 记忆
          "enabled": true
        }
      }
    }
  }
}

压缩后的上下文结构：
[早期对话摘要]

[中间部分（保留片段）]

[最近的消息（完整）]

2️⃣ Session Pruning（会话剪枝）

作用：仅删除工具执行结果（toolResult 类型消息），不触碰用户/助手消息
触发时机：

剪枝策略：

• Soft-trim（软修剪）：过长的工具结果，保留头尾，中间用 ... 截断

• Hard-clear（硬清除）：完全替换为占位符 "[Old tool result content cleared]"

• 保护规则：

• 最后 keepLastAssistants（默认 3 条）助手消息不受影响

• 包含图片的工具结果不会被修剪

• 用户消息绝对不被修改

配置（agents.defaults.contextPruning）：

{
  "agents": {
    "defaults": {
      "contextPruning": {
        "mode": "cache-ttl",        // off | cache-ttl
        "ttl": "5m",               // TTL 时间（默认 5 分钟）
        "keepLastAssistants": 3,   // 保留最后几条助手消息
        "softTrimRatio": 0.3,      // 超过 30% 窗口时软修剪
        "hardClearRatio": 0.5,     // 超过 50% 窗口时硬清除
        "minPrunableToolChars": 50000 // 工具结果至少 50k chars 才考虑修剪
      }
    }
  }
}

3️⃣ Tool Output Truncation（工具输出截断）

作用：每个工具自己控制输出大小，在返回前就截断
例子：

• web_fetch 默认 maxChars: 50000

• browser.screenshot 默认 maxChars: 4000

• shell.exec 输出会被截断

这是第一道防线，在进入上下文前就减少数据量。

🔄 三者协作流程

工具返回大数据 
    ↓ (Tool truncation)
截断到合理大小 
    ↓ (加入会话)
累积到 context window 接近上限
    ↓ (Auto-compaction)
压缩旧历史 → 生成摘要
    ↓ (如果使用 Anthropic + TTL 过期)
Session pruning → 清理旧 tool results
    ↓
保持上下文在合理范围内

压缩会把重要信息给失真，还需要配置Memory Flush（记忆刷新）
让我详细解释：

🧠 Compaction 前记忆刷新（Memory Flush）

原理

在 自动压缩 触发之前，OpenClaw 会先执行一个静默的 Agent 回合，专门用来：

1. 扫描对话中的重要信息（决策、事实、偏好、待办事项）

2. 将这些信息写入记忆文件（MEMORY.md 或 memory/YYYY-MM-DD.md）

3. 然后才执行压缩（此时即使摘要失真，关键信息也已持久化）

配置位置

"agents": {
 "defaults": {
   "compaction": {
   "mode": "auto",
     "memoryFlush": {
     "enabled": true, // 默认 true（guard 模式）
     "softThresholdTokens": 4000, // 接近限制前触发
     "systemPrompt": "Session nearing compaction. Store durable memories now.",
     "prompt": "Write any lasting notes to memory/YYYY-MM-DD.md; reply with NO_REPLY if nothing to store."
     }
   }
 }
}

🔄 完整流程：避免信息丢失

会话累积 → 接近 context window 限制
    ↓ (触发软阈值)
Memory Flush（静默回合）
    ↓ Agent 主动提取重要事实，写入记忆文件
    ↓ (记忆已持久化，可向量检索)
Compaction（压缩 Summarization）
    ↓ 生成摘要，丢弃旧细节（但详情已在记忆）
    ↓ 后续可通过 memory_search 找回

🎯 举个例子

User: 我的咖啡偏好是双份糖

Agent: 记住了

... (后续很多对话，上下文累积)

正常情况（无 flush）：
压缩后，这句话可能被摘要为"用户有一些饮食偏好"，细节丢失。

有 memory flush：

• 压缩前，Agent 主动写入 memory/2026-03-21.md：

-用户咖啡偏好: 双份糖

• 压缩后就放心丢弃细节

• 之后问"我喜欢怎么喝咖啡？" → memory_search 检索到原记录 ✅