学习

这是一份面向学习和借鉴的设计笔记。它说明 OpenClaw 如何让 AI Agent 记住长期信息、查找历史细节、在上下文压缩前保存重要内容，并把零散记录逐步整理成可靠的长期记忆。 OpenClaw 的核心思路可以概括为一句话：把记忆当作可治理的数据生命周期，而不是把它藏在模型或向量数据库里。 人能看到和编辑关键记忆；模型只能通过明确的文件、工具和运行时能力读取或写入记忆；索引负责帮模型找到内容，但原始文件仍然是事实来源。 一页读懂 如果不用工程术语，可以把 OpenClaw 的记忆系统理解成三件东西： 一本精简的人设和长期档案：MEMORY.md，只放长期稳定、反复有用的信息。 一套按天保存的工作日志：memory/YYYY-MM-DD.md，记录当天发生的细节、任务、决策和观察。 一个图书馆目录：SQLite、全文检索和向量索引，帮助 agent 在需要时找到旧内容。 这三件事分工不同： MEMORY.md 像简历或个人资料，短、准、长期有效。 memory/ 像工作笔记，详细、可追加、可回看。 搜索索引像目录卡片，可以重建，不应该成为唯一真相。 OpenClaw 不会把所有历史都塞进 prompt。它只把启动时真正需要的高信号内容放进上下文，详细历史通过 memory_search 和 memory_get 按需读取。这样既保留了长期连续性，又控制了 token 成本和隐私风险。 这套设计解决什么问题 长期运行的 Agent 会遇到四类记忆问题： 记不住：跨天、跨会话后，用户偏好和项目约定丢失。 记太多：把完整聊天历史塞进 prompt，成本高、速度慢、还容易污染回答。 记不准：模型凭印象回答，把临时结论当成事实。 记不安全：私聊内容、群组内容、后台任务内容混在一起，边界不清。 OpenClaw 的答案不是单靠 RAG，也不是单靠 prompt summary，而是组合出一条完整路径： 会话内容 -> 需要保存的短期事实写入 memory/ -> 搜索索引让旧内容可被找回 -> 多次被使用的内容进入 dreaming 整理 -> 高价值候选再进入 MEMORY.md -> 启动和回答时按需加载 这条路径的重点是分层：详细内容留在文件里，常用结论进入长期记忆，检索工具负责连接两者。 关键设计原则 1....

Version: 2026.5.7 | 基于源码 + 官方文档梳理 一句话理解 OpenClaw = 多通道 AI 网关 + 嵌入式 Agent 运行时。它不是"套壳聊天机器人"，而是一个能对接多种 IM 平台、运行多个 AI 模型、支持插件扩展的 agent 基础设施。 1. 顶层架构 ┌──────────────────────────────────────────────────────────────────┐ │ OpenClaw Gateway │ │ │ │ ┌─────────────┐ ┌──────────────┐ ┌────────────────────────┐ │ │ │ Channel │ │ Agent │ │ Plugin │ │ │ │ Layer │ │ Runtime │ │ System │ │ │ │ │ │ (Pi/Codex) │ │ │ │ │ │ WhatsApp ───┤ │ │ │ Provider Plugins ──────┤ │ │ │ Telegram ───┤ │ ┌────────┐ │ │ Channel Plugins ──────┤ │ │ │ Discord ────┤ │ │ Agent │ │ │ Context Engine ───────┤ │ │ │ Signal ─────┤ │ │ Loop │ │ │ Memory Plugins ───────┤ │ │ │ Slack ──────┤ │ └────────┘ │ │ Hook Plugins ─────────┤ │ │ │ ....