OpenClaw 实战(四):记忆系统与多 Agent 编排

单个 AI 助手能做的事有限，但一支配合默契的 AI 团队，可以应对真正的业务挑战。

为什么 AI 总是”记不住”？

不管用的是 Qwen、Kimi 还是其他模型，都有个绕不开的限制：上下文窗口是有限的。

“上下文窗口”是什么？简单理解，就是 AI 一次性能”装进脑子”的信息量上限。就像人脑的短期记忆容量有限，AI 能同时处理的文字数量也有个天花板。

这个天花板意味着什么？

丢给 AI 一份 50 页的招标文件，让它写技术方案。写到一半，上下文快满了，它开始”失忆”——前面定的框架、提的要求，记不住了。

上午让它写严肃的商业方案，下午让它帮忙制定旅行计划。模型可能因无法立刻切换语气，之前的对话历史还在上下文里待着，从而给出违和的回答。

工作时需要它写严谨的技术文档，下班后想让它帮忙想个朋友圈文案。同一个 AI 很难立刻切换不同的角色。

这些问题的根源就一个：单个 AI 的上下文窗口再大，也扛不住复杂任务的消耗。

OpenClaw采用了这样一套机制来应对这些问题：记忆系统 + 多 Agent 编排。

记忆系统：让 AI 跨会话记住你

OpenClaw 的记忆系统基于”文件即真相”的思想，主要由两层组成。

双层记忆结构

长期记忆（MEMORY.md） 存放精选持久化偏好、配置决定与沉淀经验，放在工作区根目录。

有个安全机制：MEMORY.md 默认仅在私聊会话中加载，群组会话中不会注入。默认情况下，群聊和私聊使用不同的 session key，系统根据会话类型决定是否注入 MEMORY.md。

这样设计是为了防止私密信息泄露给群成员。不过，完整的隔离还需要配合 sandbox 配置一起使用。需要用户在 openclaw.json 中配置 sandbox 或 non-main 模式来限制群聊中的工具权限。否则群聊中的 Agent 仍然可能访问工作区文件

每日日志（memory/YYYY-MM-DD.md） 存放阶段性项目进展、当天的探讨细节。会话启动时，系统默认读取”今天加昨天”的文件数据来维系短期事件的连贯性。

这种设计把”可复用事实”与”过程噪声”分开，让检索与上下文注入保持清爽的信噪比。

记忆是如何写入的？

OpenClaw 的记忆写入主要由 AI 自动完成，不需要手动编辑。

自动写入每日日志 — 对话过程中，AI 会自动把重要信息记录到 memory/YYYY-MM-DD.md。比如项目进展、调试记录、当天讨论的决策。

用户触发写入长期记忆 — 当说”记住这个”或”把这个写进记忆”时，AI 会把信息写入 MEMORY.md。比如”记住我偏好使用 Python 编写脚本”。

定期整理 — 有两种方式：

1. 手动整理 — 每隔一段时间 review 每日日志，把值得长期保存的内容提炼到 MEMORY.md 中。

2. 自动整理（Dreaming） — OpenClaw 在 2026 年 4 月发布的实验性功能，会在后台自动分析短期记忆，把高频、高相关的内容提升到 MEMORY.md。需要手动开启，默认不启用。

AI 会怎么写记忆？

了解 AI 的写入逻辑，有助于更好地使用记忆系统。

AI 会自动记录 — 对话中的关键信息、项目进展、技术决策等。比如”完成了招投标系统初版”、”修复了登录模块的 BUG”。

当说”记住这个”时 — AI 会把信息写入长期记忆。这时候建议给出具体、清晰的内容。比如：

• ✅ “记住：我偏好使用 Python 编写脚本”
• ✅ “记住：生产环境部署在 us-east-1 区域”

AI 不会记录 — 临时的对话内容、一次性问题、没有明确指示的闲聊。这些只保留在每日日志中，不会进入长期记忆。

记忆检索：两种主流方式

记忆搜索（memory_search） 默认采用混合搜索算法（BM25 + 向量相似度），将数据切成小块（400 token/分块并设置小额重叠带）。返回带详细文件路径和行号的查询片段。

精确读取（memory_get） 基于已有依据读取内容，精确命中特定行，防止信息污染。

有个配置细节：memory_search 的语义检索能力通常需要独立的 embedding 供应商（如 OpenAI、Gemini、Voyage 或本地 embedding 路径）。

配置方法是在 openclaw.json 中指定 embedding provider：

{"agents":{"defaults":{"memorySearch":{"provider":"openai","model":"text-embedding-3-small"}}}}

缺少 embedding 并不等于记忆搜索完全失效。当前实现仍会退化到 lexical/keyword 检索路径，只是相关性、召回质量和跨表述匹配能力会下降。

记忆搜索权重设置可参考以下配置：

{"agents":{"defaults":{"memorySearch":{"query":{"hybrid":{"enabled":true,"vectorWeight":0.7,"textWeight":0.3}}}}}}

默认配置下，向量相似度权重为 0.7，关键词匹配权重为 0.3。这个比例的设计思路是：

• 向量相似度（70%）
  
   — 捕捉语义相关性，比如”Python 脚本”能匹配到”用 Python 写的自动化程序”
• 关键词匹配（30%）
  
   — 保证精确匹配，比如变量名、文件路径、ID 等

记忆会过期吗？

会。比如项目迁移了、配置变更了、偏好改变了，旧记忆可能不再适用。

OpenClaw 的处理方式：

• 新事实覆盖旧事实
  
   — AI 会自动识别冲突，用新信息更新记忆
• Dreaming 自动整理
  
   — 开启后，系统会定期分析记忆，标记过期的内容
• 手动清理（可选）
  
   — 如果需要，可以直接编辑 MEMORY.md 删除或更新条目

对大多数用户来说，记忆管理是自动的，不需要额外操作。

但记忆系统也有局限

记忆系统能解决”跨会话记住”的问题，但解决不了”当下任务太复杂”的问题。

比如这个场景：同时丢给 AI 3 篇动辄上万字的长篇技术博客，要求翻译并做摘要。

即使用上记忆系统，单个 AI 还是得一篇一篇啃——上下文窗口就那么大，没法同时装下 3 篇长文。

这时候，多 Agent 协作派上用场了。

多 Agent 编排：把大任务拆小

OpenClaw 的多 Agent 协作理念：让不同的 AI 扮演特定专家，组合成一支能互相配合的虚拟团队。

多 Agent 的隔离机制

在 OpenClaw 中，不同的 Agent 在底层有物理级别的隔离：

认证与模型隔离 — 不同 Agent 可绑定不同的 API Key 和模型（翻译员用 Claude 3.5 Sonnet，画图员用擅长图像解析的独立模型）。

记忆隔离 — 独立生成日记本和上下文序列，彼此互不串台。

灵魂隔离 — 每个 Agent 完全独享自己的 SOUL.md 和 IDENTITY.md。

工作区隔离 — 每个 Agent 有独立的 workspace 目录。

这种设计保证了”术业有专攻”——每个 AI 都能专注自己的领域，不会被其他任务干扰。

创建 AI 团队

第一步：用 CLI 快速创建

# 添加一个专注编程的 Agentopenclaw agents add coder# 添加一个负责营销写作的 Agentopenclaw agents add writer# 查看已创建的 Agent 列表openclaw agents list

创建完成后，为它们分别定制独特的 SOUL.md 职业设定。

第二步：配置路由绑定

给每位”员工”指派接待窗口。OpenClaw 的路由机制通过修改 openclaw.json 实现：

{"agents":{"list":[{"id":"main","workspace":"~/.openclaw/workspace-main"},{"id":"coder","workspace":"~/.openclaw/workspace-coder"},{"id":"writer","workspace":"~/.openclaw/workspace-writer"}]},"bindings":[{"agentId":"coder","match":{"channel":"telegram","peer":{"kind":"direct","id":"用户的 Telegram ID"}}},{"agentId":"writer","match":{"channel":"feishu","peer":{"kind":"group","id":"oc_content_group_xxx"}}}]}

路由绑定依赖明确的优先级：精准匹配 ID 级别 > 频道级别匹配。

第三步：启用 Agent 间通信

对于复杂任务，需要 AI 互相打配合。先在 openclaw.json 中启用 sessions_send 内线电话机制：

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

这里分享一下个人经验，我有遇到过这么种情况，在同一个通信工具中切换不同的机器人agent，让它们之间相互交接工作，agent之间通信有时候会“不记得”使用sessions_send来通信，错误的想采用通信工具的消息通道来发送消息而失败。

我的解决方案是：提醒它 “记住agent之间通信使用sessions_send” 方法。

常见的协作模式

根据社区实践，以下是几种常见的多 Agent 协作模式，根据任务特点选择。

Supervisor（监督者模式）

设置一个中央统筹者，负责接收任务并分发给其他 AI。

配置方法：在主 AI main 的 SOUL.md 里赋予其调度职责。

## 角色团队调度核心。当收到以下需求时，派发给对应 Agent：- 编程或技术研发需求 → 派发给 @coder- 公众号写作需求 → 派发给 @writer- 日常问答 → 自己处理最后整合多方结果回复给用户。

适用场景：需要统一入口、统一输出的任务，比如项目管理、内容发布流程。

Router（路由模式）

根据消息来源或内容关键词，自动路由到对应 AI。

配置方法：在 openclaw.json 的 bindings 中定义路由规则。

适用场景：不同渠道有明确分工的场景，比如技术群用 coder、内容群用 writer。

Pipeline（流水线模式）

任务按顺序经过多个 AI 处理，每个 AI 负责一个环节。

流程示例：用户 → writer(初稿) → editor(审核) → publisher(发布) → 用户

适用场景：有明确工序的任务，比如内容创作流程、代码开发流程。

Parallel（并行模式）

主 AI 召唤多个子代理并行处理，最后汇总结果。

典型场景：同时分析 10 个竞品网站，要求输出对比报告。

主 AI → 子代理 1（分析竞品 A 的功能、定价、优劣势）      → 子代理 2（分析竞品 B 的功能、定价、优劣势）      → 子代理 3（分析竞品 C 的功能、定价、优劣势）      ...      → 汇总结果 → 用户

适用场景：可拆分的批量任务，比如批量翻译、批量分析、批量处理。

子代理 (SubAgent) 能力

上述需要预先配置的多 Agent 协作模式，一般适合于需要长期多个固定Agent 协作的情况。

OpenClaw 还内置了子代理能力。可以应对任务过程中临时需要Agent 处理子任务的情况

子代理(SubAgent)和前四种模式的区别：

触发方式：

1. 用户手动触发
   
    — 使用 /subagents spawn  命令
2. AI 自动触发
   
    — 需要在配置中启用 sessions_spawn 工具，AI 会根据任务情况调用

典型场景： 同时处理 5 个不同格式的数据文件，要求统一清洗并输出标准化报表。AI 可以召唤多个子代理并行处理，最后汇总结果。

监控命令：

在聊天窗口中输入以下命令，可以监控子代理状态：

# 查看当前正在运行的并行子代理任务/subagents list# 抽查某个特定子代理的工作日志/subagents log <session-id># 一键叫停所有子代理/subagents kill all

常见问题排查

消息路由不生效

现象：配置了 bindings，但消息还是发到了主 Agent。

排查：检查 openclaw.json 中 agents.list 是否包含所有 Agent，检查 bindings 的 peer.id 是否正确（飞书用 open_id 或 chat_id），确认优先级：精准匹配 ID > 频道匹配 > 默认路由。

解决：重启 Gateway 使配置生效。

Agent 间无法通信

现象：主 Agent 无法调用 sessions_send 派发给子 Agent。

排查：检查 tools.agentToAgent.enabled 是否为 true，检查 tools.agentToAgent.allow 是否包含相关 Agent ID，确认子 Agent 的 workspace 路径正确。

解决：配置修改后需要重启 Gateway。

记忆搜索效果差

现象：memory_search 返回结果不相关。

排查：检查 embedding API Key 是否配置（独立于主模型 Key），检查索引是否构建完成（文件保存后约 2 秒），尝试调整 vectorWeight 和 textWeight。

解决：用 openclaw doctor 验证 embedding provider 状态。

最后

记忆系统解决的是”跨会话记住”的问题，多 Agent 编排解决的是”当下任务太复杂”的问题。

两者配合好了，AI 助手才能真正成为”数字分身”——既记得住习惯，又扛得住复杂的活儿。

（完）

下一篇，聊聊OpenClaw 的自动化与定时任务——如何让 AI 在睡觉时也能主动工作，真正实现”设置一次，受益很久”。

真正的智能助手，不是等指令才动，而是知道什么时候该主动。