十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

OpenClaw 跑跨会话三层记忆(Short-Term / Daily Logs / MEMORY.md):Key 用 TaoToken

OpenClaw 跑跨会话三层记忆(Short-Term / Daily Logs / MEMORY.md):Key 用 TaoToken OpenClaw 的三层记忆Short-Term / Daily Logs / MEMORY.md原本设计得很干净可真正跑起来最先断的往往不是记忆结构而是模型调用通道。TaoToken 的解法是先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿一把 Key把 Base URL 统一成 https://taotoken.net/api三层记忆的每次读写都走同一条通道。记忆要顺利写入 Daily Log、要在新会话启动时把 MEMORY.md 读回上下文每一步背后都是一次模型请求。Key 是临时额度、换个模型就得重配一遍 Base URL、会话结束那一下 daily log 没写成功三层设计再完整也接不上。统一通道之后无论底层换成哪个模型Short-Term 的上下文窗口、Medium-Term 的每日日志、Long-Term 的 MEMORY.md 都能保持原有读写节奏。1. 三层记忆设计完整为什么 OpenClaw 还会“失忆”1.1 三层记忆的正常读写节奏OpenClaw 把记忆分成三层。Short-Term 就是当前会话的上下文窗口模型上下文有多长它就记多长会话结束就自然失效不需要额外持久化。Medium-Term 是 Daily Logs按日期落到memory/daily/下的 Markdown 文件由 session-memory hook 在会话结束时触发一次摘要写入记录当天几个会话分别聊了什么、改了哪些文件、做了哪些决定。Long-Term 是 MEMORY.md由 boot-md hook 在新会话启动时自动读入模型上下文让 agent 一开工就知道长期项目、关键决策和用户偏好。三层各司其职时跨会话记忆的运行节奏是这样的会话 A 结束时session-memory 把本次会话摘要追加到当天的 daily log随后人或每周定时任务从这些 daily log 里抽取真正长期稳定的信息写进 MEMORY.md会话 B 启动时boot-md 把 MEMORY.md 重新读入agent 就能接着上次的上下文干活。每一步看起来都依赖文件系统但每一步背后其实都要发起一次大模型请求只是这些请求被框架封装成 hook 了。问题就在这hook 不关心你用的是哪家模型但它要求你给的 Key 和 Base URL 在触发那一刻是能用的。如果你之前在 LangGraph 里用过 MemorySaver 和 Store可以把这层关系理解为Short-Term 对应 Checkpointer 的会话态MEMORY.md 对应 Store 的长期键值只是 OpenClaw 把文件路径和运维流程也一并定义好了。1.2 模型通道不一致时断的是哪一层最常见的失忆场景是换模型或换 Key而不是记忆结构写错。比如团队里有人习惯用 A 厂商的 Key有人用 B 厂商的还有人只是临时复制了一把别人的 Key 来跑。A 厂商的会话结束后daily log 正常写入换到 B 时如果 Base URL 没有同步改或者 Key 的有效期只在某个控制台里那么会话 B 启动时 boot-md 把 MEMORY.md 读进来了但第一次真正的模型请求就 401后面的任务自然接不上。对照三层来看短期记忆最脆因为当前对话完全依赖连续的成功调用中间断一次用户就会明显感到 agent 忘了刚才在聊什么。中期记忆最隐蔽因为 session-memory 是在会话结束时才触发如果触发时机和认证失败撞在一起当天文件里可能只有日期标题、没有摘要你甚至不会立刻发现。长期记忆通常不会丢文件但表现成「加载了却没生效」——MEMORY.md 太长、优先级被挤占、或者加载后首轮调用就报错都会让 agent 表现得像失忆。换句话说三层记忆结构本身没问题真正要统一的是模型调用这条通道。2. 把 OpenClaw 的模型通道接到 TaoToken先拿 Key 再改配置2.1 从官网创建 Key并记下模型广场的模型 ID打开 TaoToken注册登录后进控制台创建 API Key。创建后把 Key 复制保存好下文统一写成 YOUR_API_KEY。这里要提醒一句模型 ID 不要从别处抄OpenClaw 支持的具体模型以模型广场当时列表为准模型广场就在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 上会展示当前可用的模型 ID、上下文长度和计费说明你只需要把选中的模型 ID 填进配置。创建完 Key 后建议先在 TaoToken 的模型对话页面用同一把 Key 发一条测试消息确认 Key 有效、模型 ID 能正常返回。这一步能提前排除 90% 的配置错误避免改完 OpenClaw 之后还要回头排查基础认证问题。2.2 OpenClaw 默认走 Claude Code 通道settings.json 里指向 TaoTokenOpenClaw 的记忆 hooks 不关心底层是哪个厂商但所有 LLM 请求都走 Claude Code 兼容的环境变量。因此接入 TaoToken 只需要改一处在~/.claude/settings.json的 env 块里写入 Base URL、Key 和模型 ID。完整配置如下{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }注意Base URL 填https://taotoken.net/api末尾不要加/v1YOUR_API_KEY 换成你在模型对话页面已经验证过的那把YOUR_MODEL_ID 以模型广场为准不要用网上教程里随手写的旧 ID。保存后重启 OpenClawboot-md、session-memory、command-logger 这些 hook 触发的每一次模型请求都会通过 TaoToken 统一通道发出。2.3 openclaw.json 里不需要重复配置模型有些读者会习惯在 openclaw.json 里也写一遍 Base URL其实没有必要。openclaw.json 只负责 hooks 的开关、路径和参数模型认证统一由 Claude Code 环境变量接管。这样做的额外好处是当你从 OpenClaw 切到 Claude Code 或其他兼容工具时同一套 settings.json 可以复用Key 也只需要维护一把不用每换一个工具就重新申请一次密钥。3. openclaw.json 里三层记忆 hooks 的落地配置3.1 session-memory会话结束自动追加 Daily LogDaily Log 的写入由 session-memory hook 控制。下面是一份最小可用的 openclaw.json 配置{ hooks: { session-memory: { enabled: true, summaryLength: medium, includeActions: true, dailyLogPath: ./memory/daily/ } } }summaryLength 控制摘要粒度建议先用 medium等跑顺了再按自己的需求调成 short 或 long。includeActions 决定 daily log 里是否记录 agent 实际执行过的命令和文件修改开着会更方便事后复盘但也会让日志更长。dailyLogPath 是日志目录建议用绝对路径或固定在 OpenClaw 启动目录下的相对路径避免不同目录启动时找不到文件。这个 hook 依赖一次模型调用来生成摘要所以它是否成功直接取决于 settings.json 里的认证配置是否稳定。3.2 boot-md新会话启动时自动读入 MEMORY.md长期记忆靠 boot-md hook 加载。它的配置和 session-memory 独立可以同时开着{ hooks: { boot-md: { enabled: true, files: [SOUL.md, IDENTITY.md, USER.md, MEMORY.md] } } }files 数组里的文件会在每次新会话启动时依次读入上下文。MEMORY.md 建议放在这个列表里但要注意文件长度——读入多少就占多少上下文预算太长会挤压当前任务的可用空间。OpenClaw 文档里给出的建议是控制在 200 行以内只保留跨会话都稳定的事实比如正在进行的项目、关键决策、长期偏好。文件越长boot-md 触发的那次模型请求消耗的上下文也越多统一通道只能保证请求发得出去不能替你解决内容膨胀问题。3.3 验证记忆跨会话的三个信号配置完成后不要急着投入正式任务先用三个信号确认三层记忆都走通了。第一个信号新开一个会话直接问 agent“你还记得我上次的项目背景吗”如果 boot-md 正常它能复述出 MEMORY.md 里的内容而不是说“我们第一次聊”。第二个信号结束会话后打开当天的 daily log 文件能看到时间戳、摘要和槽位信息说明 session-memory 在会话结束时成功触发了一轮模型调用并写盘。第三个信号主动换一个模型 ID重启 OpenClaw再重复前两个验证。如果结果一致说明记忆结构没有绑定在特定模型上统一通道把模型的切换影响隔离掉了。这也正是「跨会话、跨模型」两层需求同时满足后的正常状态。4. 一个跨会话任务实例记住同事的 SQL 诊断偏好4.1 会话 A把偏好写进 MEMORY.md举一个实际发生过的协作场景。你帮同事排查一条 Oracle 慢查询同事的偏好非常固定先看执行计划里的全表扫描再按 Rows 和 Bytes 排序最后只挑最可疑的三条 SQL 来分析。这个偏好在会话 A 中会被多次重复属于值得进入长期记忆的信息。在会话 A 结束时把这些内容写进 MEMORY.md 的 Ongoing Preferences 分区格式可以参考## Ongoing Preferences - Oracle SQL 诊断偏好优先看执行计划中的全表扫描 - 分析顺序按 Rows 和 Bytes 排序缩小范围 - 输出约束每次最多给三条最可疑的 SQL附一句诊断理由注意这里的写入动作直接编辑 MEMORY.md 文件即可不需要让 OpenClaw 连上生产库。SQL 诊断只涉及生成和解释真正执行必须在本地完成。之后从这些偏好里生成出的任何 SQL都先由执行者确认可接受再在 SQL*Plus 里跑。4.2 会话 Bboot-md 自动加载偏好并生成诊断 SQL第二天新开会话boot-md 会把上面的 MEMORY.md 自动读入上下文。你只需要说一句“继续帮我看昨天那三条 SQL”agent 就能按同事的偏好生成一整套诊断 SQL例如检查执行计划select * from table(dbms_xplan.display_cursor(null, null, ALLSTATS LAST));以及按 Rows、Bytes 排序找出大对象select operation, object_name, rows, bytes, cost from v$sql_plan where sql_id YOUR_SQL_ID order by bytes desc, rows desc;这些 SQL 生成后由同事在本地 SQL*Plus 里执行再把输出贴回对话。OpenClaw 负责解读执行计划、对比预期、给出下一步建议而不是直接连库执行。整个过程中三层记忆的配合很清楚Short-Term 记住本轮讨论的 SQL_IDDaily Log 记录这次诊断的时间和结论MEMORY.md 让下一次会话一开始就知道同事的分析偏好。模型通道切换不会打断这条链路因为 boot-md 和 session-memory 每次的请求都走同一个 Base URL。5. 记忆断在最常见的三处按序排查5.1 401 / 403Key 没创建或复制错了如果 OpenClaw 启动后第一次模型请求就报 401先别改 hooks。回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 控制台确认这把 Key 是否存在、有没有复制完整。常见原因是复制时多带了空格或者误把文档里的 YOUR_API_KEY 占位符当成了真 Key。确认后重新粘贴一次重启会话再试。注意这里要去的是控制台不是把 Key 填在浏览器地址栏里控制台在官网首页登录后就能看到入口。5.2 Daily Log 是空文件session-memory 没有触发daily log 文件存在但只有日期标题、没有具体摘要通常是会话异常中止导致的。session-memory 是在会话结束时触发摘要调用crash 或 timeout 会让它跳过写入。排查时先看当天文件的时间戳再检查 openclaw.json 里 session-memory 是否 enabled以及 dailyLogPath 是否写到了正确目录。如果路径设置没问题就手动复现一次正常会话结束看文件是否追加了新内容。还有一种容易被忽略的情况会话结束那一次请求因为 Key 过期而失败文件创建了、内容没写进去这时候要从 token 有效期而不是 hooks 配置找原因。5.3 MEMORY.md 太长上下文被吃光boot-md 把 MEMORY.md 全文读入文件越长留给当前任务的上下文越少。如果 agent 表现成“加载了 MEMORY.md 但任务经常记不住”大概率是文件内容太多、重点被稀释。控制到 200 行内把已经结束的项目、失效的偏好移出主文件归档到单独的目录。每周做一次预压缩回看最近 7–14 天的 daily log把真正长期稳定的信息抽到 MEMORY.md把已经沉淀过的日志压缩或删除。经过压缩后再做一次 3.3 节的验证通常能明显感觉到 agent 对长期偏好的命中率回来。6. 跑通后回控制台对一下调用记录以上配置全部落地后建议做一次完整的闭环验证先在 TaoToken 模型对话 页面用同一把 Key 发一条消息确认模型 ID 和 Base URL 正确再回 OpenClaw 走一遍“会话 A 写入偏好 → 会话 B 读取偏好”的流程最后打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 控制台看这次跨会话期间的调用记录和用量确认每次 hook 触发的请求都正常入账。如果 OpenClaw 接下来要承担比较重的代码任务可以在 Coding Plan 里选一个匹配的套餐比零散按量调用更可控Key 的统一管理和续期在 控制台 API Keys 页面。环境变量和 settings.json 的对照关系见 Claude Code 接入文档下次换机器或换工具时照着配一遍就行。
返回列表