1. 为什么每次发问都带着上一轮的“记忆”如果你在用 OpenClaw 做本地 AI 工具调用大概率遇到过这种场景第一次问“帮我写个 Python 快速排序”它答得挺准第二次你换了个完全无关的问题比如“帮我看看这段 Nginx 配置哪里写错了”结果它还在那儿扯排序算法甚至把上一轮的代码片段混进回答里。这不是模型变笨了而是会话上下文没清干净。OpenClaw 默认按 agent session 运行每次对话会保留 conversation history。只要 session_id 不变模型就会一直带着之前的上下文。对于 IDE 插件、自动化脚本、批量 API 调用这类场景历史记录反而是污染源——你希望每次提问都是干净上下文0 历史、0 缓存、纯推理。这篇就聚焦一个具体需求在 TaoToken 统一 Key 接入的前提下怎么通过 settings.json 骨架把 OpenClaw 配成“每次发问前清空对话记录”的无状态模式。我会给出可复制的配置、验证清空是否生效的检查动作以及几个我实际踩过的坑。适合正在用 OpenClaw 做本地工具调用、又不想被上下文干扰的开发者。2. TaoToken 统一 Key 的前置准备在改 OpenClaw 配置之前先把模型接入这一层理顺。TaoToken 的作用是提供一个统一的 API Key让你在 OpenClaw 里不用为每个模型单独配一套凭证。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end API 地址是 https://taotoken.net/api 。你需要先拿到 Key。登录后进控制台在 API Keys 页面创建一个新 Key复制出来备用。这个 Key 后面会写进 OpenClaw 的 settings.json 里作为模型调用的凭证。注意Key 只显示一次创建后立刻保存到本地安全位置。不要直接提交到 Git 仓库。TaoToken 的接入文档里有完整的参数说明包括 base_url、model 名称、超时设置等。如果你用的是 Claude Code 或 Anthropic 风格的调用文档里也有对应的配置示例。建议先把文档过一遍确认你的 OpenClaw 版本支持的字段名因为不同版本的 settings.json 结构会有差异。拿到 Key 之后先别急着改 OpenClaw。可以用一个最简单的 curl 请求验证 Key 是否可用curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer YOUR_TAOTOKEN_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: ping}], max_tokens: 16 }如果返回正常的 JSON 响应说明 Key 和网络都没问题。这一步能排除掉后面配置出错时“到底是 Key 问题还是 OpenClaw 问题”的干扰。3. settings.json 骨架让每次提问都是干净上下文OpenClaw 的清空历史有三条路每次新建 session_id、关闭 memory、调用 reset。生产环境最稳的是第一条——每次请求生成新的 UUID 作为 session_id这样 OpenClaw 不会带历史也不会写入历史。下面是一份可以直接复制的 settings.json 骨架。它做了三件事接入 TaoToken 统一 Key、关闭 agent 默认 memory、强制每次请求使用独立 session。{ providers: { taotoken: { base_url: https://taotoken.net/api, api_key: YOUR_TAOTOKEN_KEY, default_model: claude-sonnet-4-20250514, timeout: 60 } }, agents: { defaults: { provider: taotoken, model: { primary: claude-sonnet-4-20250514 }, memory: { enabled: false, write_on_request: false, read_on_request: false }, session: { mode: stateless, generate_per_request: true, reuse_across_requests: false } } }, conversation: { clear_before_prompt: true, max_history_messages: 0, persist_history: false } }几个关键字段解释一下。memory.enabled: false是关掉 agent 的记忆读写这样每次请求不会写入历史也不会读取历史等于 stateless。session.generate_per_request: true配合reuse_across_requests: false保证每次发问都生成新的 session_idOpenClaw 找不到旧 session自然就不会带上下文。conversation.clear_before_prompt: true是在发问前主动清空当前会话的历史队列max_history_messages: 0则把历史消息上限压到零。如果你用的是 openclaw.json 而不是 settings.json字段名可能略有不同但核心逻辑一样{ agents: { defaults: { memory: { enabled: false } } } }这份配置适合 IDE 插件、自动化脚本、批量 API 调用。如果你是在 CLI 里手动用也可以在新问题前调用/reset或者用 API 的DELETE /sessions/{session_id}清空。但频繁 reset 不如每次新 session 干净后者不会残留任何缓存。4. 验证对话记录是否被正确清空配置写完不代表生效。你需要一个可重复的检查动作确认每次发问真的是干净上下文。第一步准备两个明显无关的问题。比如第一问“11 等于几”第二问“把‘hello’反转成大写。”如果历史没清空第二问的回答里可能会莫名其妙提到数字或加法。第二步在 OpenClaw 里连续发这两问观察第二问的响应。更可靠的方式是看日志里的 session_id。在 settings.json 里把日志级别调到 debug{ logging: { level: debug, log_session_id: true, log_history_length: true } }然后发两次请求在日志里搜session_id和history_length。如果配置正确你会看到两个不同的 session_id且每次请求的 history_length 都是 0。第三步用 API 直接验证。发一个请求带上一个固定的 session_id然后再发一个不带 session_id 的请求对比返回curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer YOUR_TAOTOKEN_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 记住数字 42}], session_id: test-session-001, max_tokens: 32 }然后再发一次同样 session_id 的请求问“我刚才让你记住什么”。如果 memory 关闭且 session 不重用第二次请求不应该知道 42。如果它答出了 42说明历史还在配置没生效。我试过在 IDE 插件里用这套检查发现插件本身会缓存 session_id导致 settings.json 里的generate_per_request被覆盖。解决办法是在插件配置里也关掉 session 复用或者每次调用前手动生成 UUID。5. 本篇常见错排查错误一改了 settings.json 但没重启 OpenClaw。配置是启动时加载的热改不生效。改完必须重启进程否则你看到的还是旧行为。错误二session_id 被上层工具覆盖。很多 IDE 插件和自动化框架会自己管理 session_id优先级高于 settings.json。如果你发现每次请求的 session_id 还是同一个去插件或框架的配置里找 session 相关字段把它关掉或改成每次生成。错误三memory.enabled 设为 false 但 write_on_request 还是 true。这两个字段要一起关。只关 enabled 不关 write某些版本仍会写入历史文件下次启动时又读回来。错误四TaoToken Key 权限不足。如果 Key 只有部分模型权限OpenClaw 调用时会报 403看起来像配置错误。先在控制台确认 Key 的模型范围或者用 curl 单独测一下目标模型。错误五把 clear_before_prompt 当成万能。这个字段只清当前会话的历史队列如果 session 本身被复用清空后下一轮又写进去了。真正干净的做法还是每次新 session_idclear_before_prompt 只是辅助。错误六日志里 history_length 显示 0 但模型仍带上下文。这种情况通常是模型服务端缓存了 prompt。检查你的请求里有没有带cache_control或类似字段有的话去掉。TaoToken 的接入文档里有关于缓存控制的说明可以对照排查。6. 接入与排障的下一步如果你在配置过程中遇到 Key 报错、session 不生效、或者想确认某个模型是否支持无状态调用可以直接去 TaoToken 控制台看 API Keys 的状态和调用记录。接入文档里有完整的字段说明和示例排障时对照着看比猜快得多。想先验证模型对话是否正常可以用模型对话页面发一条测试消息确认 Key 和模型都通。如果你打算长期用 OpenClaw 做编码或 Agent 任务Coding Plan 里有针对这类场景的配置建议包括 session 管理和上下文控制的最佳实践。配置这件事最怕的是改了一堆字段但不知道哪个生效。建议你按这篇的骨架先跑通最小可用版本再用日志验证 session_id 和 history_length确认干净上下文之后再逐步加其他功能。
