1. 长会话为什么越聊越慢Context 膨胀的真实代价如果你用 OpenClaw 跑过超过两小时的连续对话大概率见过这个场景前半小时回复又快又准一小时后开始答非所问两小时后直接甩出一句context too large或者响应时间从 2 秒涨到 20 秒。这不是模型变笨了是 Session 里的 Context 体积在悄悄膨胀。OpenClaw 的 Session 机制本质上是一个对话容器。每一次用户消息、AI 回复、工具调用输入输出、系统提示、工作区文件快照都会按顺序追加进这个容器。容器本身没有上限但底层大模型的 context window 有硬上限——Claude Sonnet 是 200k tokens很多国产模型只有 32k 或 128k。一旦容器里的内容逼近这个上限要么报错要么模型开始丢中间它只能看到开头和结尾中间的历史被静默截断于是你问它刚才那个函数名是什么它一脸茫然。更隐蔽的成本是钱。Context 是按 token 计费的一个膨胀到 150k tokens 的 Session每轮对话都要把这 150k 重新送进模型。你只是问了一句继续账单上却多了 150k 的输入 token。长会话跑一天成本能翻好几倍。我实测过一个典型场景一个用于代码审查的 OpenClaw Agent连续处理 40 个 PR 后Session 累积到 180k tokens单轮响应从 3 秒涨到 18 秒单轮成本从 0.02 元涨到 0.35 元。触发一次/compact后Context 降到 22k响应回到 4 秒成本回到 0.03 元。这就是 Session 管理的价值。OpenClaw 给出的解法是三条主线压缩Compaction把旧历史总结成摘要重置Reset开一个全新 Session持久化Persistence把状态落到磁盘保证重启不丢。这三条线不是互斥的而是配合使用日常靠压缩维持连续性切换话题靠重置保持干净持久化保证进程崩溃后还能恢复。这篇文章会把这套机制拆开给出可以直接复制的配置片段、压缩阈值参数以及一套重置前后对比的验证动作让你在本地就能复现 Context 体积和召回效果的变化。适合已经在用 OpenClaw 跑 Agent、但被长会话拖慢或拖贵的人。2. TaoToken 前置准备给 OpenClaw 配一个稳定的模型入口OpenClaw 本身是 Agent 框架它不提供模型需要你接一个兼容 OpenAI 或 Anthropic 协议的 API 入口。TaoToken 提供的就是这个入口官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 。在开始 Session 管理之前先把模型入口配好否则后面所有压缩、重置的验证都跑不起来。整个流程分三步拿 Key、写配置、验证连通。2.1 获取 API Key登录后进入控制台在 API Keys 页面创建一个新 Key。建议按用途分开建一个给 OpenClaw 主 Agent 用一个给测试脚本用方便后面排查问题时区分调用来源。Key 只在创建时完整显示一次复制后存到本地密码管理器。控制台地址https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite API Keys 页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite2.2 确认模型 ID不同模型在 Session 压缩时的行为差异很大。上下文窗口小的模型比如 32k压缩触发更频繁窗口大的模型200k可以撑更久但单轮成本更高。在模型对话页面可以先试跑几个模型确认哪个适合你的场景模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite常见的模型 ID 形如claude-sonnet-4-20250514、gpt-4o、kimi-k2等具体以控制台模型列表为准。记下你要用的 Model ID下一步写进配置。2.3 写入 OpenClaw 配置OpenClaw 的模型配置在~/.openclaw/openclaw.json。如果你用的是 Claude Code 风格的接入配置结构会略有不同但核心三件套不变Base URL、API Key、Model ID。{ models: { providers: { taotoken: { baseUrl: https://taotoken.net/api, apiKey: sk-你的Key, models: [ { id: claude-sonnet-4-20250514, name: Claude Sonnet 4, contextWindow: 200000 } ] } }, default: taotoken/claude-sonnet-4-20250514 } }这里contextWindow字段很关键OpenClaw 的自动压缩就是靠它来判断何时触发的。如果你填错了比如实际 32k 的模型填成 200k压缩永远不会触发Session 会一直涨到报错。填小了则会频繁压缩浪费 token 在总结上。2.4 验证连通配好后跑一条最小请求确认 Key 和端点都通curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 回复 OK 两个字母}], max_tokens: 10 }返回里能看到choices[0].message.content是OK说明入口通了。如果返回 401检查 Key 是否复制完整如果返回 model not found检查 Model ID 拼写。这一步做完OpenClaw 就有了稳定的模型入口接下来才能谈 Session 的压缩和重置。如果你打算长期跑编码类 Agent可以考虑用 Coding Plan 降低单位成本Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite3. 可复制的 Session 配置压缩阈值、裁剪策略与持久化参数这一节是全文的核心给出可以直接粘贴进~/.openclaw/openclaw.json的配置片段。我会把每个参数的作用、推荐值、以及调错后的后果都讲清楚。3.1 完整的 Session 配置片段{ session: { dmScope: per-channel-peer, compaction: { enabled: true, auto: true, threshold: 0.75, keepRecentMessages: 12, summaryModel: taotoken/claude-sonnet-4-20250514, summaryMaxTokens: 2000 }, contextPruning: true, pruningKeepToolResults: 3, maintenance: { mode: enforce, pruneAfter: 14d, maxEntries: 200, rotateBytes: 10mb } }, agents: { defaults: { contextPruning: true } } }3.2 压缩阈值 threshold 怎么定threshold: 0.75的意思是当 Session 的 token 数达到模型 context window 的 75% 时自动触发压缩。200k 窗口的模型就是 150k tokens 触发。这个值不能设太高。设成 0.95 的话压缩还没跑完下一轮请求可能就已经超限报错了。也不能设太低0.5 的话每聊几句就压缩一次总结本身也要花 token反而更贵。0.7 到 0.8 是实测比较舒服的区间我一般用 0.75。keepRecentMessages: 12表示压缩时保留最近 12 条消息不动只把更早的历史总结成摘要。这个数字太小比如 3模型会丢失近期上下文回答开始飘太大比如 50压缩效果不明显Context 还是很大。12 到 20 是合理范围。summaryMaxTokens: 2000限制摘要本身的长度。摘要太长就失去了压缩的意义太短又会丢关键信息。2000 tokens 大约能覆盖 1500 字的中文摘要对大多数技术对话够用。3.3 裁剪 Pruning 和压缩的区别很多人把这两个搞混。压缩是把旧历史总结成摘要摘要会写进 JSONL 持久化裁剪是把工具调用的输出直接截断只在内存里临时处理不落盘。pruningKeepToolResults: 3表示只保留最近 3 次工具调用的完整输出更早的工具输出在送进模型前被截断。这对代码类 Agent 特别有用——一次read_file可能返回几千行跑十次就是几万 tokens但模型其实只需要最近几次的结果。裁剪是无损于对话逻辑的省 token 手段因为它砍的是工具输出这种低信息密度内容。压缩是有损的因为总结必然丢细节。所以优先开裁剪再靠压缩兜底。3.4 持久化与维护参数dmScope: per-channel-peer是多用户场景的必选项。默认的main会让所有私聊共享一个 SessionA 用户问的问题会出现在 B 用户的上下文里这是严重的信息泄漏。per-channel-peer按渠道加发送者隔离每个用户一个独立 Session。maintenance.mode: enforce让清理策略真正执行而不是只报告。pruneAfter: 14d表示 14 天未活跃的 Session 归档maxEntries: 200限制索引文件最多 200 条rotateBytes: 10mb在 sessions.json 超过 10MB 时轮转。生产环境建议开 enforce否则 sessions.json 会无限增长最终拖慢启动。3.5 配置生效验证改完配置后重启 gateway然后查看当前 Session 状态openclaw sessions --json | head -50输出里能看到每个 Session 的inputTokens、outputTokens、totalTokens。如果totalTokens已经接近你设的阈值但压缩没触发检查contextWindow是否填对。4. 验证请求重置前后 Context 体积与召回效果对比配置写完不算完得有一套可复现的验证动作确认压缩和重置真的起作用了。这一节给出一套完整的对比实验你可以在本地照着跑。4.1 构造一个会膨胀的 Session先制造一个长对话。用一个脚本连续发 30 轮请求每轮带一段长文本模拟真实的长会话#!/bin/bash for i in $(seq 1 30); do curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { \model\: \claude-sonnet-4-20250514\, \messages\: [ {\role\: \user\, \content\: \这是第 $i 轮。请记住关键信息项目代号 ALPHA-$i负责人是成员 $i。$(printf 填充文本%.0s {1..200})\} ], \max_tokens\: 50 } /dev/null echo 第 $i 轮完成 done跑完后查看 Session 状态openclaw sessions --json | jq .[] | {sessionId, totalTokens, compactionCount}你会看到totalTokens涨到了几万compactionCount可能是 0还没触发阈值。4.2 触发压缩并观察变化手动触发一次压缩/compact 保留所有项目代号和负责人信息忽略填充文本压缩完成后再查状态openclaw sessions --json | jq .[] | {sessionId, totalTokens, compactionCount}totalTokens应该明显下降compactionCount加 1。同时 verbose 模式下会看到 Auto-compaction complete的日志。4.3 召回效果对比这是最关键的一步压缩后模型还能不能记住关键信息压缩前问一句项目代号 ALPHA-15 的负责人是谁压缩后再问同样的问题。如果压缩指令写得好明确要求保留项目代号和负责人模型应该还能答对。如果答错了说明摘要丢了关键信息需要调整/compact的指令或者在配置里调大summaryMaxTokens。4.4 重置对比现在执行重置/new这会生成新的 Session ID旧的 JSONL 保留存档。再问同样的问题模型应该完全不知道 ALPHA-15 是什么——因为上下文已经清空了。这就是重置和压缩的本质区别压缩保留信息但压缩体积重置彻底丢弃。验证旧 Session 文件还在ls -la ~/.openclaw/agents/main/sessions/你应该能看到新旧两个.jsonl文件旧的没被删除只是不再被当前 Session 引用。4.5 记录对比数据把三次的totalTokens和响应时间记下来形成一张对比表阶段totalTokens单轮响应时间能否召回 ALPHA-15压缩前约 600008s能压缩后约 150003s能取决于摘要质量重置后约 5002s不能这张表就是你判断 Session 管理是否生效的依据。如果压缩后 totalTokens 没降说明阈值或配置有问题如果压缩后召回失败说明摘要指令需要优化。5. 常见报错排查401、local proxy failed、reading choices、OAuthSession 管理跑起来后最容易撞上的几类报错集中在这里。逐个拆解。5.1 401 Unauthorized{error: {message: Invalid API key, type: authentication_error}}原因通常是 Key 复制不完整、Key 被删除、或者配置里apiKey字段写成了环境变量名但环境变量没导出。排查顺序先在 curl 里直接测 Key 是否有效再检查openclaw.json里的apiKey是不是硬编码了正确的值。如果用的是环境变量引用比如${TAOTOKEN_KEY}确认 shell 里echo $TAOTOKEN_KEY有输出。5.2 local proxy failedError: local proxy failed: dial tcp 127.0.0.1:7890: connect: connection refused这个报错说明 OpenClaw 在尝试走一个本地代理端口但那个端口没有服务在监听。常见于之前配过代理、后来关掉了但配置没清。检查openclaw.json里有没有proxy字段或者环境变量HTTP_PROXY、HTTPS_PROXY是否指向了一个已失效的地址。清掉这些配置让请求直连https://taotoken.net/api即可。5.3 reading choices 相关报错Error: reading choices: unexpected end of JSON input这通常不是 Session 问题而是 API 返回了非 JSON 内容比如 HTML 错误页OpenClaw 解析时崩了。原因可能是 Base URL 写错比如漏了/v1或者多写了路径。确认baseUrl是https://taotoken.net/api请求路径由 OpenClaw 自动拼接。如果还是报错用 curl 直接打一次看返回的原始内容是什么。5.4 OAuth 相关报错Error: OAuth token expired, please re-authenticate如果你用的是 Claude Code 风格的 OAuth 接入token 过期后会报这个。重新走一遍授权流程即可。但如果你用的是 API Key 接入本文推荐的方式不应该出现 OAuth 报错——如果出现了说明配置里混入了 OAuth 相关的 provider检查models.providers下有没有多余的条目。5.5 压缩不触发Session 涨到很大但compactionCount一直是 0。检查三处compaction.enabled是否为 truecompaction.auto是否为 truecontextWindow是否填得比实际大。最常见的是contextWindow填成了 200000 但实际模型只有 32000导致阈值永远达不到。5.6 压缩后模型失忆压缩触发了但模型开始忘记之前的关键信息。这是摘要质量问题。两个调整方向调大summaryMaxTokens比如从 2000 到 4000或者在手动/compact时给更明确的指令比如保留所有函数签名、变量名、文件路径忽略解释性文字。排查时建议开 verbose 模式能看到每次压缩前后的 token 数和摘要内容定位问题最快。6. 把 Session 管理接进你的日常工作流Session 管理不是配一次就完事的它需要跟着你的使用习惯调整。分享几个我踩过坑之后固定下来的做法。第一按任务类型分 Session。代码审查、文档写作、数据分析用不同的 Session不要混在一个里。混用会导致上下文互相干扰压缩时摘要也会变得混乱。OpenClaw 的sessionKey支持按渠道和 peer 隔离你可以用不同的飞书群或 Slack channel 来天然隔离。第二切换话题前手动/compact。自动压缩是被动的等它触发时 Context 已经很大了。主动在话题切换点压缩能保持 Session 一直处于轻量状态。指令写具体一点比如保留所有 API 设计决策和错误码定义忽略调试过程。第三重要节点用/new而不是/compact。如果旧话题彻底结束了新话题和它没关系直接/new更干净。/new kimi还能顺便换模型一条命令搞定重置加切换。第四定期跑openclaw sessions cleanup --dry-run看清理预览。生产环境开enforce模式后这个命令能让你在真正删除前确认哪些 Session 会被归档。别等到磁盘满了才发现 sessions.json 涨到了几百 MB。第五把contextWindow填准。这是最容易被忽略但影响最大的一项。填错了要么压缩不触发要么频繁触发。不确定的话去模型对话页面实际测一下或者查控制台的模型列表。如果你打算把 OpenClaw 跑成长期在线的 Agent建议把 Coding Plan 用上单位成本比按量付费低不少适合高频调用的场景Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite接入文档里有更详细的参数说明和示例配置遇到本文没覆盖的字段可以去查接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite最后提醒一句Session 管理的核心不是把配置抄对而是理解压缩保连续性、重置保干净、持久化保不丢这三者的取舍。你的场景偏连续对话就多靠压缩偏任务隔离就多靠重置两者都要就靠持久化兜底。配置只是手段判断什么时候用哪个才是关键。