OpenClaw 多智能体系统实践

Maddie_Mo

479人浏览 · 2026-04-18 09:47:00

Maddie_Mo · 2026-04-18 09:47:00 发布

OpenClaw 多智能体系统实践：从 Agent 分工、工作空间到长期记忆与成本控制

OpenClaw 多智能体系统实践：从 Agent 分工、工作空间到长期记忆与成本控制

在这里插入图片描述

一、前言

最近我在整理和重构自己的 OpenClaw 多智能体系统，希望把它从一个简单的 AI 工具调用框架，逐步改造成一个更稳定、更可控、更适合长期项目开发的本地智能体工作流系统。

在这个过程中，我主要围绕以下几个方向进行了设计和调整：

多智能体角色划分
每个 Agent 的工作职责定义
独立工作空间与共享项目空间设计
长期记忆系统设计
上下文长度控制与成本优化
OpenClaw Gateway 的启动与排查
与智能终端、小智设备、MCP 工具的联动流程
前端设计风格文件与 Coding Agent 的结合方式

这篇文章主要记录我目前对 OpenClaw 多智能体系统的整理思路，也可以作为后续继续完善系统的基础文档。

二、项目背景

在使用 OpenClaw 的过程中，我发现如果只是单纯让一个 AI 助手完成所有任务，很容易出现几个问题：

上下文越来越长，最终导致上下文爆炸；
模型调用成本不可控；
不同任务之间缺少明确分工；
长期项目中的关键信息容易丢失；
Agent 的工作职责不清晰，容易重复规划、重复调用工具；
本地文件、记忆、任务进度缺少统一管理；
简单问题被复杂化，复杂问题又缺少稳定流程。

因此，我希望把 OpenClaw 改造成一个更清晰的多智能体系统，让不同的 Agent 负责不同类型的工作。

整体目标是：

让 OpenClaw 不只是一个 AI 聊天工具，而是一个可以持续执行任务、管理记忆、协调多个 Agent，并能与本地工具和智能终端联动的 AI 工作系统。

三、整体 Agent 架构设计

目前我设计的核心 Agent 包括：

main-agent
ceo-agent
coordinator-agent
planner-agent
research-agent
coding-agent
qa-agent

对应的中文名称可以理解为：

主控代理
首席决策代理
协调调度代理
规划架构代理
研究调研代理
代码开发代理
质量测试代理

整体调用关系如下：

用户输入
   ↓
Main Agent（主控代理）
   ↓
CEO Agent（首席决策代理）
   ↓
Coordinator Agent（协调调度代理）
   ↓
Planner / Research / Coding / QA
   ↓
Coordinator 汇总
   ↓
Main Agent 输出最终结果

这套设计的核心思想是：

Main Agent 负责入口
CEO Agent 负责判断
Coordinator Agent 负责调度
Planner Agent 负责规划
Research Agent 负责调研
Coding Agent 负责实现
QA Agent 负责检查

四、为什么需要多智能体分工？

如果所有事情都交给一个 Agent，会出现几个明显问题。

1. 任务边界不清楚

同一个 Agent 既要规划，又要写代码，又要调研，又要测试，很容易出现职责混乱。

例如用户只是问：

OpenClaw 怎么启动？

如果没有任务分级，模型可能会生成一大段系统架构分析，而不是直接给出命令。

2. 成本不可控

不同任务对模型能力要求不同。

简单任务不需要调用高成本模型，复杂代码或架构任务才需要更强模型。

3. 上下文容易膨胀

当所有信息都堆在一个 Agent 的上下文里，时间久了会导致上下文爆炸。

4. 长期记忆混乱

如果没有按 Agent 和项目拆分记忆，所有历史信息都会混在一起，后续检索和使用都会变得困难。

因此，多智能体系统不是为了复杂而复杂，而是为了让任务边界、成本控制和长期维护更加清晰。

五、各 Agent 的职责划分

1. Main Agent：主控代理

中文名称

主控与入口代理。

核心职责

Main Agent 是整个系统的入口，负责接收用户请求，并将任务转交给后续 Agent。

主要工作

接收用户输入；
判断用户请求类型；
将任务交给 CEO Agent 做决策；
接收最终结果；
输出用户可读的最终回复。

不负责的事情

不直接写代码；
不直接做复杂调研；
不直接执行测试；
不深入参与具体任务实现；
不保存大量临时上下文。

输出结果

Main Agent 最终只输出面向用户的结果，避免把内部复杂流程全部暴露出来。

示例：

用户：帮我整理 OpenClaw 的 Agent 工作流程。

Main Agent：
1. 接收请求；
2. 交给 CEO 判断复杂度；
3. 由 Coordinator 分配给 Planner；
4. 最终把整理结果返回用户。

2. CEO Agent：首席决策代理

中文名称

首席执行官代理 / 项目总控代理。

核心职责

CEO Agent 负责判断任务的重要性、复杂度和执行优先级，是整个多智能体系统中的决策层。

主要工作

判断任务是否值得执行；
判断任务属于简单任务、中等任务还是复杂任务；
决定是否需要多 Agent 协作；
判断是否需要调用高成本模型；
决定是否需要 Planner、Research、Coding、QA 参与；
控制整体任务边界，避免过度执行；
避免简单任务被复杂化。

示例场景

如果用户只是问：

OpenClaw 怎么启动？

CEO Agent 应该判断为简单任务，不需要复杂规划，直接给出 2 到 3 步命令即可。

如果用户要求：

帮我设计一个完整的 OpenClaw 多智能体工作流系统。

CEO Agent 才需要触发 Planner、Research、Coding、QA 等 Agent 参与。

不负责的事情

不直接编写大量代码；
不做具体测试；
不保存所有项目细节；
不替代 Coordinator 进行任务分发。

3. Coordinator Agent：协调调度代理

中文名称

协调与调度代理。

核心职责

Coordinator Agent 负责在多个 Agent 之间进行任务分发和结果汇总。

主要工作

接收 CEO Agent 的决策；
将任务拆分给不同 Agent；
管理任务执行顺序；
汇总 Planner、Research、Coding、QA 的结果；
避免多个 Agent 重复劳动；
将最终结果返回给 Main Agent；
管理跨 Agent 的阶段性输出。

适合处理的场景

例如一个复杂任务：

帮我搭建一个本地 RAG 系统，并生成接口、前端页面和部署说明。

Coordinator Agent 可以拆分为：

Planner Agent：设计系统架构
Research Agent：调研技术方案
Coding Agent：编写代码
QA Agent：检查代码和运行逻辑

不负责的事情

不替代 CEO 做战略判断；
不直接深入写代码；
不做最终用户表达；
不保存长期项目记忆。

4. Planner Agent：规划架构代理

中文名称

项目规划与架构设计代理。

核心职责

Planner Agent 负责把复杂任务拆解成清晰的执行计划和系统结构。

主要工作

制定项目规划；
输出技术路线；
设计目录结构；
设计模块职责；
设计数据流和调用链；
生成开发任务清单；
制定阶段目标；
输出项目文档骨架。

不负责的事情

不直接写大量代码；
不做最终测试；
不替代 Coding Agent 执行具体开发；
不做没有依据的技术调研结论。

示例输出

1. 先搭建 Gateway 服务；
2. 再设计 Agent 工作空间；
3. 然后配置长期记忆文件；
4. 最后接入智能终端或 MCP 工具。

Planner Agent 更适合处理“我要怎么做”“架构怎么搭”“流程怎么设计”这类问题。

5. Research Agent：研究调研代理

中文名称

技术研究与资料调研代理。

核心职责

Research Agent 负责查找资料、分析技术方案、对比不同框架或模型。

主要工作

调研开源项目；
分析 GitHub 仓库；
对比模型能力；
查询最新技术资料；
整理技术报告；
输出选型建议；
识别技术风险。

适合处理的场景

例如：

这个 GitHub 仓库能不能应用到 OpenClaw？

Research Agent 需要分析仓库结构、能力边界、集成方式和潜在风险。

不负责的事情

不直接修改项目代码；
不做最终用户交付；
不做没有来源依据的结论；
不替代 Coding Agent 完成实现。

6. Coding Agent：代码开发代理

中文名称

代码执行与开发代理。

核心职责

Coding Agent 负责实际编写、修改、调试代码。

主要工作

编写脚本；
修改配置文件；
编写 API 服务；
编写前端页面；
处理报错；
生成可执行命令；
修复代码问题；
整理代码结构；
按项目规范输出代码。

不负责的事情

不做高层战略决策；
不负责最终质量审查；
不替代 Planner 设计复杂架构；
不在未理解文件结构时盲目修改。

示例任务

帮我写一个 OpenClaw MCP 工具，用于接收小智智能终端任务，并把生成结果保存到桌面。

Coding Agent 应该输出实际可运行的代码、配置和命令。

7. QA Agent：质量保证代理

中文名称

质量保证与测试代理。

核心职责

QA Agent 负责审查结果是否正确、完整、可执行。

主要工作

检查代码逻辑；
检查配置文件；
检查命令是否正确；
检查文档是否完整；
检查潜在风险；
输出修改建议；
做最终验收；
检查是否符合用户要求。

适合处理的场景

例如：

帮我检查这个 OpenClaw 配置有没有问题。

QA Agent 应该重点检查配置项、路径、端口、模型名称和实际运行逻辑。

不负责的事情

不做大范围架构设计；
不直接主导项目开发；
不替代 Research Agent 做资料调研；
不随意通过未验证的结果。

8. 智能体模型推荐

Agent	默认模型	备用模型	原因
Main Agent	openai/gpt-5-chat	openai/gpt-5.4-mini	Main 更偏意图识别、任务分流、上下文压缩，不需要太强推理，但要稳定、快、便宜
CEO Agent	google/gemini-2.5-pro	moonshotai/kimi-k2.5	CEO 要负责全局规划、复杂决策、跨 Agent 协调，Gemini 2.5 Pro 在长上下文、规划、结构化思考上更强
Planner Agent	qwen/qwen3-max	google/gemini-2.5-flash	Planner 需要做任务拆解、架构、模块划分，Qwen3 Max 性价比很高，中文结构化能力不错
Research Agent	google/gemini-2.5-pro	moonshotai/kimi-k2.5	调研需要长上下文、文档阅读、方案比较、信息整合，Gemini 2.5 Pro 最合适
Coding Agent	anthropic/claude-sonnet-4.6	qwen/qwen3-coder	Claude Sonnet 4.6 代码质量、重构、补全、复杂逻辑稳定性最好；Qwen3 Coder 适合低成本补充
QA Agent	openai/gpt-5.4-mini	deepseek/deepseek-chat	QA 更适合低成本快速审查、找边界问题，不需要一直用最贵模型
Coordinator Agent	openai/gpt-5-chat	deepseek/deepseek-chat	Coordinator 偏状态管理、调度、消息输出，不需要超强推理
简单聊天 / 一级任务	deepseek/deepseek-chat	openai/gpt-5-chat	成本最低，适合简单问题、翻译、配置说明、命令解释

成本控制三层路由：

低成本层：DeepSeek Chat、GPT-5 Chat
中间层：Qwen3 Max、GPT-5.4 Mini、Kimi K2.5
高价值层：Gemini 2.5 Pro、Claude Sonnet 4.6

六、Agent 工作空间设计

为了避免不同 Agent 的记忆和任务文件混乱，我设计了独立工作空间结构。

目录结构如下：

agents/
 ├── ceo-agent/
 │   ├── workspace/
 │   ├── memory.md
 │   └── sessions/
 │
 ├── planner-agent/
 │   ├── workspace/
 │   ├── memory.md
 │   └── sessions/
 │
 ├── research-agent/
 │   ├── workspace/
 │   ├── memory.md
 │   └── sessions/
 │
 ├── coding-agent/
 │   ├── workspace/
 │   ├── memory.md
 │   └── sessions/
 │
 ├── qa-agent/
 │   ├── workspace/
 │   ├── memory.md
 │   └── sessions/
 │
 └── coordinator-agent/
     ├── workspace/
     ├── memory.md
     └── sessions/

七、目录含义说明

1. workspace/

workspace/

这是每个 Agent 的临时工作目录。

适合存放：

当前任务的中间文件；
临时代码；
草稿文档；
测试输出；
工具执行结果；
某个任务的临时分析文件。

例如 Coding Agent 的 workspace/ 可以放代码草稿，Research Agent 的 workspace/ 可以放调研资料。

注意：

workspace/ 不应该无限制保存所有历史内容，任务完成后应该将长期有价值的信息提炼到 memory.md 或项目级文档中。

2. memory.md

memory.md

这是每个 Agent 的长期记忆文件。

适合记录：

该 Agent 的长期职责；
用户偏好；
项目关键约定；
已确认的技术结论；
不应该重复询问的信息；
长期有效的任务规则。

例如：

# coding-agent memory

## 用户代码风格要求

- C# 字段变量使用下划线加驼峰式命名，例如 `_Client`
- 所有方法和字段需要中文注释
- Unity 脚本需要添加 AddComponentMenu
- 文件头需要包含项目名、文件名、作者、日期和说明
- 行内注释尽量不要放在变量后方，应单独占一行

3. sessions/

sessions/

这是每个 Agent 的会话记录目录。

适合保存：

某一次任务的上下文摘要；
某一次工具调用记录；
某一次任务的输入输出；
某一次协作过程中的阶段性结果；
任务结束后的复盘摘要。

它不应该无限制保存完整聊天记录，而应该保存摘要。

例如：

sessions/
 ├── 2026-03-25-openclaw-memory-design.md
 ├── 2026-03-31-model-routing-test.md
 └── 2026-04-07-design-style-integration.md

八、项目级工作空间设计

除了 Agent 自己的目录，还需要有项目级目录，用于保存整个项目的长期资料。

目录结构如下：

projects/
 └── openclaw-project/
     ├── project_memory.md
     ├── tasks.md
     ├── architecture.md
     ├── decisions.md
     ├── progress.md
     └── risks.md

九、项目文件说明

1. project_memory.md

用于保存整个项目的长期记忆。

适合记录：

项目目标；
核心功能；
用户长期要求；
关键路径；
已确认方案；
不需要重复讨论的背景。

示例：

# OpenClaw Project Memory

## 项目目标

构建一个基于 OpenClaw 的本地多智能体系统，支持任务规划、代码开发、技术调研、质量审查、长期记忆和智能终端联动。

## 核心原则

- 简单任务直接完成
- 复杂任务才启用多 Agent 协作
- 长期信息写入固定记忆文件
- 不依赖无限上下文
- 控制模型调用成本

2. tasks.md

用于记录当前任务列表。

示例：

# Tasks

## 当前任务

- [ ] 完善 ceo-agent 的 AGENTS.md
- [ ] 完善 planner-agent 的 AGENTS.md
- [ ] 完善 coding-agent 的代码规范
- [ ] 设计长期记忆写入规则
- [ ] 测试 OpenClaw Gateway 启动流程

3. architecture.md

用于记录系统架构。

示例：

# Architecture

## Agent 调用链

用户 → Main Agent → CEO Agent → Coordinator Agent → 子 Agent → Coordinator → Main Agent → 用户

## 核心模块

- Agent 工作空间
- 项目级记忆
- 会话摘要
- Gateway 服务
- MCP 工具
- 智能终端接入

4. decisions.md

用于记录关键决策。

示例：

# Decisions

## 决策 1：每个 Agent 拥有独立 memory.md

原因：

- 避免不同 Agent 记忆混乱
- 便于职责隔离
- 降低上下文污染

## 决策 2：复杂任务才启用多 Agent

原因：

- 降低成本
- 减少无效调用
- 提高响应速度

5. progress.md

用于记录项目进度。

示例：

# Progress

## 2026-03-25

完成 OpenClaw 长期记忆机制初步设计。

## 2026-03-31

完成模型分配方案初步设计。

## 2026-04-07

开始研究设计风格文件如何接入 OpenClaw。

6. risks.md

用于记录项目风险。

示例：

# Risks

## 风险 1：上下文过长

解决方案：

- 只保留最近 20 条上下文
- 超长时先摘要再裁剪
- 长期信息写入 memory.md

## 风险 2：模型调用成本过高

解决方案：

- 简单任务使用低成本模型
- 复杂任务才调用高能力模型
- 减少不必要的多 Agent 协作

## 风险 3：Agent 职责不清晰

解决方案：

- 每个 Agent 单独编写 AGENTS.md
- 明确负责事项和不负责事项
- 复杂任务由 Coordinator 统一调度

十、AGENTS.md 文件设计

每个 Agent 都应该有自己的 AGENTS.md 文件，用来描述它的工作职责和行为规则。

推荐目录结构如下：

~/.openclaw/workspace/agents/
├── ceo-agent/AGENTS.md
├── coding-agent/AGENTS.md
├── planner-agent/AGENTS.md
├── research-agent/AGENTS.md
├── qa-agent/AGENTS.md
├── coordinator-agent/AGENTS.md
└── main-agent/AGENTS.md

每个 AGENTS.md 建议包含以下内容：

# Agent 名称

## 中文名称

## 核心职责

## 工作范围

## 工作流程

## 可调用工具

## 不负责事项

## 输出格式

## 成本控制规则

## 记忆读写规则

十一、Main Agent 的 AGENTS.md 示例

# Main Agent

## 中文名称

主控与入口代理。

## 核心职责

作为 OpenClaw 系统入口，负责接收用户请求、判断基础意图，并将任务转交给 CEO Agent 或 Coordinator Agent。

## 工作流程

1. 接收用户输入；
2. 判断是否为简单任务；
3. 简单任务直接返回；
4. 复杂任务交给 CEO Agent 判断；
5. 接收最终结果；
6. 输出用户可读结果。

## 不负责事项

- 不直接写复杂代码；
- 不直接做技术调研；
- 不直接进行质量审查；
- 不保存大量历史上下文。

## 输出要求

- 面向用户；
- 简洁清晰；
- 优先给可执行步骤；
- 不暴露内部无关流程。

十二、CEO Agent 的 AGENTS.md 示例

# CEO Agent

## 中文名称

首席决策代理。

## 核心职责

负责判断任务复杂度、执行优先级、是否需要多 Agent 协作，以及是否需要调用高成本模型。

## 任务分级

### 简单任务

满足以下条件之一即可视为简单任务：

- 用户只需要一个命令；
- 用户只问一个明确概念；
- 用户只需要 2 到 3 步操作；
- 不需要读取大量文件；
- 不需要多 Agent 协作。

处理方式：

- 直接输出结果；
- 不启用复杂规划；
- 不调用多个 Agent。

### 中等任务

满足以下条件之一可视为中等任务：

- 需要整理结构；
- 需要生成一份较完整文档；
- 需要修改少量配置；
- 需要一个 Agent 参与即可完成。

处理方式：

- 可交给 Planner 或 Coding Agent；
- 不默认启用所有 Agent。

### 复杂任务

满足以下条件之一可视为复杂任务：

- 涉及多文件代码修改；
- 涉及系统架构设计；
- 涉及调研、开发、测试多个环节；
- 涉及长期项目记忆；
- 需要多个 Agent 协同。

处理方式：

- 交给 Coordinator Agent；
- 由 Coordinator 分配 Planner、Research、Coding、QA。

## 成本控制

- 简单任务使用低成本模型；
- 复杂任务才使用高能力模型；
- 不为了形式启用多 Agent。

十三、Coordinator Agent 的 AGENTS.md 示例

# Coordinator Agent

## 中文名称

协调调度代理。

## 核心职责

负责根据 CEO Agent 的决策，将任务分配给合适的子 Agent，并汇总各 Agent 的执行结果。

## 工作流程

1. 接收 CEO Agent 的任务决策；
2. 分析任务需要哪些 Agent；
3. 分配任务给 Planner、Research、Coding、QA；
4. 收集阶段性结果；
5. 去除重复内容；
6. 汇总为最终结果；
7. 返回给 Main Agent。

## 调度原则

- 只调用必要 Agent；
- 避免重复劳动；
- 先规划，再执行，再检查；
- 简单任务不进入复杂协作流程。

## 不负责事项

- 不直接替代 Coding Agent 写代码；
- 不替代 QA Agent 做最终审查；
- 不替代 CEO Agent 做复杂度判断。

十四、Planner Agent 的 AGENTS.md 示例

# Planner Agent

## 中文名称

项目规划与架构设计代理。

## 核心职责

负责复杂任务的拆解、系统结构设计、技术路线规划和开发步骤设计。

## 主要工作

- 输出项目结构；
- 输出模块职责；
- 输出任务步骤；
- 输出技术路线；
- 输出架构说明；
- 输出阶段目标。

## 工作原则

- 先给可执行方案；
- 不过度推演；
- 不写无关长篇背景；
- 规划必须能落地。

## 不负责事项

- 不直接写大量代码；
- 不做最终测试；
- 不输出没有依据的调研结论。

十五、Research Agent 的 AGENTS.md 示例

# Research Agent

## 中文名称

技术研究与资料调研代理。

## 核心职责

负责技术资料调研、开源仓库分析、模型能力对比和方案选型建议。

## 主要工作

- 分析 GitHub 仓库；
- 对比不同技术方案；
- 查询最新资料；
- 输出选型建议；
- 识别潜在风险。

## 输出要求

- 有结论；
- 有理由；
- 有适用场景；
- 有不适用场景；
- 不夸大技术能力。

## 不负责事项

- 不直接改代码；
- 不做最终部署；
- 不替代 Coding Agent。

十六、Coding Agent 的 AGENTS.md 示例

# Coding Agent

## 中文名称

代码开发与执行代理。

## 核心职责

负责代码编写、配置修改、脚本生成、报错排查和工程实现。

## 主要工作

- 编写代码；
- 修改配置；
- 生成命令；
- 修复报错；
- 整理项目文件；
- 输出可运行方案。

## 工作原则

- 不确定文件结构时先读取文件；
- 不盲目猜测；
- 输出代码要尽量完整；
- 命令要可复制执行；
- 修改配置要说明位置。

## 不负责事项

- 不做高层战略决策；
- 不替代 QA Agent 做最终审查；
- 不替代 Planner Agent 做完整架构。

十七、QA Agent 的 AGENTS.md 示例

# QA Agent

## 中文名称

质量保证与测试代理。

## 核心职责

负责检查代码、配置、文档和流程是否正确、完整、可执行。

## 主要工作

- 检查代码逻辑；
- 检查配置错误；
- 检查命令是否可执行；
- 检查文档是否完整；
- 检查潜在风险；
- 输出修改建议。

## 检查重点

- 是否符合用户要求；
- 是否存在路径错误；
- 是否存在配置项错误；
- 是否存在模型名称错误；
- 是否存在上下文过长问题；
- 是否存在成本浪费问题。

## 不负责事项

- 不直接承担主要开发；
- 不做没有依据的通过判断；
- 不替代用户确认敏感操作。

十八、模型分配方案

不同 Agent 对模型能力的需求不同，因此不应该所有 Agent 都使用同一个高成本模型。

一个比较合理的分配方式如下：

Agent	推荐模型	备用模型
ceo-agent	deepseek-chat	qwen-plus
planner-agent	qwen-max	openai/gpt-5.4-mini
research-agent	gemini-2.5-pro / kimi-k2.5	qwen-max / claude-sonnet
coding-agent	claude-sonnet	claude-opus / deepseek-reasoner
qa-agent	openai/gpt-5.4-mini	qwen-plus / deepseek-chat

这里的核心思路是：

CEO Agent 不需要每次都用最贵模型；
Coding Agent 对代码能力要求较高，可以使用 Claude Sonnet 类模型；
Research Agent 需要长上下文和资料分析能力；
QA Agent 需要稳定、严谨、低幻觉；
Planner Agent 需要结构化和系统设计能力。

十九、上下文爆炸问题

在使用 OpenClaw 时，我遇到过类似下面的问题：

100% context used
975.5k / 163.8k

这说明上下文已经严重超出模型可处理范围。

如果不处理，会导致：

回复变慢；
费用增加；
模型开始混乱；
无法准确记住当前任务；
重复读取无关历史；
工具调用越来越多。

二十、上下文控制规则

为了解决这个问题，我设计了以下规则：

# 上下文控制规则

1. 默认只使用最近 20 条上下文。
2. 超过长度时，先生成摘要。
3. 摘要写入 memory.md 或 sessions/。
4. 丢弃旧的完整对话内容。
5. 后续任务只读取摘要和必要记忆。
6. 不把历史聊天记录当成长期记忆。
7. 长期重要信息必须写入固定文件。

这套规则的关键点是：

对话不是记忆，文件才是记忆。

二十一、长期记忆系统设计

我希望 OpenClaw 的长期记忆类似文件级记忆系统。

核心文件可以是：

~/.openclaw/memory.md

也可以进一步拆分为：

~/.openclaw/workspace/agents/ceo-agent/memory.md
~/.openclaw/workspace/agents/coding-agent/memory.md
~/.openclaw/workspace/projects/openclaw-project/project_memory.md

长期记忆不应该保存完整聊天记录，而应该保存高度压缩后的结构化摘要。

示例：

# Memory

## 用户偏好

- 用户希望回答尽量直接
- 配置类问题优先给 2 到 3 步可执行命令
- 不希望过度规划
- 技术内容需要可落地

## 项目目标

- 构建 OpenClaw 多智能体系统
- 支持长期记忆
- 支持低成本运行
- 支持本地 Gateway
- 支持智能终端接入

## 已确认规则

- 简单任务不启用多 Agent
- 复杂任务才使用 Planner、Research、Coding、QA
- 工具调用前后需要给用户反馈

二十二、记忆写入原则

长期记忆不是越多越好，而是越准确越好。

应该写入记忆的内容

用户长期偏好；
项目目标；
已确认的技术方案；
重要目录路径；
长期有效的规则；
反复使用的代码规范；
关键问题的最终结论。

不应该写入记忆的内容

临时闲聊；
一次性报错；
没有复用价值的信息；
未验证的猜测；
冗长的完整对话；
重复内容。

二十三、成本控制策略

为了避免成本爆炸，我设计了模型调用策略。

1. 简单任务

简单任务直接回答，不启用多 Agent。

例如：

OpenClaw 怎么启动？

只需要返回：

openclaw gateway start
openclaw dashboard --no-open

不需要调用 Planner、Research、Coding、QA。

2. 中等任务

中等任务可以使用 Planner 或 Coding Agent，但不需要全部 Agent 参与。

例如：

帮我整理一个 OpenClaw 的目录结构。

可以只调用 Planner Agent。

3. 复杂任务

复杂任务才启用多 Agent 协作。

例如：

帮我搭建一个从智能终端到 OpenClaw，再到桌面文件生成的完整系统。

可以启用：

CEO → Coordinator → Planner → Coding → QA

4. 模型升级规则

只有在以下情况下才使用高成本模型：

复杂代码生成；
长文档写作；
架构设计；
多文件调试；
复杂报错排查；
需要高可靠性的 QA 审查。

二十四、工具调用反馈规则

为了让用户知道系统正在做什么，我还设计了工具调用反馈规则。

规则如下：

# 工具调用反馈规则

1. 每次准备调用工具前，先向用户说明要做什么。
2. 工具调用成功后，向用户说明结果。
3. 如果继续调用其他工具，也要继续反馈。
4. 工具失败时，需要说明失败原因。
5. 最后再输出最终结果。

示例：

我将先检查 OpenClaw Gateway 的运行状态。

工具执行完成：Gateway 当前未启动。

接下来我将检查配置文件是否存在 gateway.mode。

工具执行完成：配置中 gateway.mode 已设置为 local。

最终建议：执行 openclaw gateway start 启动服务。

这样可以避免用户觉得 AI 在“黑箱执行”。

二十五、OpenClaw Gateway 常用命令

在使用 OpenClaw 时，Gateway 是非常关键的一部分。

常用命令如下。

1. 启动 Gateway

openclaw gateway start

2. 重启 Gateway

openclaw gateway restart

3. 查看 Gateway 状态

openclaw gateway status

4. 安装 Gateway 服务

openclaw gateway install

5. 设置本地模式

openclaw config set gateway.mode local

6. 修复配置

openclaw doctor --fix

7. 打开 Dashboard

openclaw dashboard --no-open

二十六、常见问题：Gateway service not loaded

有时候执行：

openclaw gateway restart

会出现：

Gateway service not loaded.
Start with: openclaw gateway install
Start with: openclaw gateway
Start with: launchctl bootstrap gui/$UID ~/Library/LaunchAgents/ai.openclaw.gateway.plist

这个说明 Gateway 服务还没有被加载。

可以按下面步骤处理。

第一步：安装 Gateway 服务

openclaw gateway install

第二步：启动 Gateway

openclaw gateway start

第三步：查看状态

openclaw gateway status

如果仍然不行，可以尝试：

launchctl bootstrap gui/$UID ~/Library/LaunchAgents/ai.openclaw.gateway.plist

二十七、常见问题：配置项不识别

之前我也遇到过类似问题：

Error: Config validation failed: <root>: Unrecognized key: "openai"

或者：

Unrecognized key: "providers"

这说明当前 OpenClaw 版本的配置 schema 不支持这些字段。

解决思路是：

不要直接手写不确定的配置项；
使用 OpenClaw 官方支持的 config set 命令；
先执行 doctor 检查；
不同版本的配置结构可能不同。

可以尝试：

openclaw doctor --fix

然后再设置：

openclaw config set gateway.mode local

二十八、打开 .openclaw 目录

在 macOS 中，如果需要用访达打开 .openclaw 目录，可以执行：

open ~/.openclaw

如果需要打开工作空间，可以执行：

open ~/.openclaw/workspace

如果需要查看日志目录，可以执行：

open ~/.openclaw/logs

二十九、OpenClaw 与智能终端的任务流程

我希望实现这样的流程：

智能终端对话
   ↓
任务发送
   ↓
OpenClaw 接收消息并执行
   ↓
资料生成并存储到桌面
   ↓
OpenClaw 向智能终端发送回执
   ↓
智能终端回复用户
   ↓
任务完结

这个流程可以用于：

小智智能终端；
本地语音助手；
MCP 工具调用；
自动生成报告；
自动生成文档；
自动写入桌面文件。

三十、智能终端请求示例

例如用户对智能终端说：

生成一份关于人工智能的调研报告，并发送到我的桌面。

MCP 服务可以接收到：

user_input=生成一份关于人工智能的调研报告，并且发送到我的桌面。
output_dir=/Users/maddie/Desktop
language=中文

然后系统判断任务类型：

Detected task type: report

接着调用 OpenClaw Responses API：

http://127.0.0.1:18789/v1/responses

最终生成文件到桌面。

三十一、OpenClaw 与设计风格文件的结合

我还研究了如何把设计风格文件接入 OpenClaw，例如从设计类仓库下载的 Markdown 风格文件。

我的思路是：

design-styles/
 ├── DESIGN_INDEX.md
 ├── minimal.md
 ├── apple-style.md
 ├── dashboard-style.md
 └── saas-style.md

然后在 Planner Agent 或 Coding Agent 中加入规则：

# 设计风格选择规则

当用户提出前端、页面、UI、美化、交互优化等任务时：

1. 先读取 DESIGN_INDEX.md
2. 判断当前项目适合哪种设计风格
3. 再读取对应风格文件
4. 根据风格文件生成 UI 或代码
5. 如果用户指定风格，则优先使用用户指定风格

这样就可以让模型自己根据项目类型选择合适的设计风格。

三十二、为什么不是所有 Agent 都读取设计文件？

设计风格文件主要和 UI、前端、交互相关。

因此不需要所有 Agent 都读取。

比较适合读取设计文件的是：

planner-agent
coding-agent

其中：

Planner Agent 用于决定采用什么风格；
Coding Agent 用于按照风格实现页面；
QA Agent 可以检查最终页面是否符合风格要求；
CEO Agent 和 Research Agent 不需要默认读取。

三十三、最终推荐目录结构

综合整理后，我认为 OpenClaw 可以使用下面这种结构：

~/.openclaw/
 ├── openclaw.json
 ├── memory.md
 ├── logs/
 │   └── gateway.log
 │
 └── workspace/
     ├── AGENTS.md
     │
     ├── agents/
     │   ├── main-agent/
     │   │   ├── AGENTS.md
     │   │   ├── memory.md
     │   │   ├── workspace/
     │   │   └── sessions/
     │   │
     │   ├── ceo-agent/
     │   │   ├── AGENTS.md
     │   │   ├── memory.md
     │   │   ├── workspace/
     │   │   └── sessions/
     │   │
     │   ├── coordinator-agent/
     │   │   ├── AGENTS.md
     │   │   ├── memory.md
     │   │   ├── workspace/
     │   │   └── sessions/
     │   │
     │   ├── planner-agent/
     │   │   ├── AGENTS.md
     │   │   ├── memory.md
     │   │   ├── workspace/
     │   │   └── sessions/
     │   │
     │   ├── research-agent/
     │   │   ├── AGENTS.md
     │   │   ├── memory.md
     │   │   ├── workspace/
     │   │   └── sessions/
     │   │
     │   ├── coding-agent/
     │   │   ├── AGENTS.md
     │   │   ├── memory.md
     │   │   ├── workspace/
     │   │   └── sessions/
     │   │
     │   └── qa-agent/
     │       ├── AGENTS.md
     │       ├── memory.md
     │       ├── workspace/
     │       └── sessions/
     │
     ├── projects/
     │   └── openclaw-project/
     │       ├── project_memory.md
     │       ├── tasks.md
     │       ├── architecture.md
     │       ├── decisions.md
     │       ├── progress.md
     │       └── risks.md
     │
     └── design-styles/
         ├── DESIGN_INDEX.md
         ├── minimal.md
         ├── dashboard.md
         └── saas.md

三十四、从零整理 OpenClaw 的推荐步骤

如果从零开始整理 OpenClaw，我建议按下面顺序来：

第一步：整理 agents/ 目录和每个 AGENTS.md
第二步：建立每个 Agent 的 memory.md
第三步：建立 projects/openclaw-project/ 项目记忆目录
第四步：加入上下文裁剪和摘要规则
第五步：配置模型分配策略
第六步：测试 Gateway 启动和 Dashboard
第七步：接入 MCP 或智能终端
第八步：逐步加入设计风格、代码规范、QA 审查规则

这样系统不会一开始就过度复杂，也方便后续逐步扩展。

三十五、总结

通过这次整理，我对 OpenClaw 的定位更加清晰了。

它不应该只是一个简单的 AI 命令工具，而应该逐步演化成一个具备以下能力的本地智能体系统：

有明确 Agent 分工；
有项目级长期记忆；
有 Agent 级独立记忆；
有上下文裁剪机制；
有成本控制策略；
有 Gateway 服务；
有本地工具调用能力；
能和智能终端、MCP、桌面文件系统联动；
能够长期服务于一个持续迭代的项目。

目前最重要的不是一次性把所有能力做完，而是先把基础结构搭好：

Agent 职责清晰
记忆文件固定
上下文可控
成本可控
任务流程可追踪

只要这几个基础打稳，后续无论是接入小智智能终端、扩展 MCP 工具，还是让 OpenClaw 参与代码开发、报告生成、项目管理，都会更加稳定和清晰。

暂时先这样吧，如果实在看不明白就留言，看到我会回复的。希望这个教程对您有帮助！
路漫漫其修远，与君共勉。

AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

2026 毕业季 AI 论文工具硬核横评：从初稿到定稿，9 款神器帮你告别熬夜焦虑

AtomGit开源社区

AI 驱动钓鱼攻击演化机理与多维度防御体系研究

AtomGit开源社区

我刚看了一个很怪但很有意思的仓库，LangChain 这套东西，居然被人搬进了 SAP ABAP

AtomGit开源社区

所有评论(0)

查看更多评论

Maddie_Mo

@weixin_43925843

已为社区贡献4条内容