你的 OpenClaw 越跑越慢？不是模型的问题，是你的 session 太胖了，这里有完美解决方案

用 OpenClaw 跑长任务的人迟早会遇到这个场景agent 刚启动的时候反应很快跑了两三个小时之后开始变慢六七个小时之后每次回复要等十几秒Telegram 消息偶尔直接超时。你以为是模型变笨了或者 API 限速了或者服务器扛不住了。都不是。是你的 session 太胖了。胖在哪OpenClaw 的 session 会累积所有的对话历史、工具调用结果、文件读写记录。每次 agent 要回复你它得先把整个 session 装配进上下文窗口。一个跑了 8 小时的 session 是什么样的内容类型占比特点你说的话5%有用agent 的回复15%部分有用工具调用输出bash、文件读写、搜索结果60%大部分过期系统提示词 skills10%每次都要加载重复的上下文恢复10%纯浪费60% 的 token 花在了已经过期的工具输出上。你两小时前让 agent 读的那个文件内容还挂在 session 里每次回复都要重新装配一遍。你三小时前跑的那段 bash 输出200 行日志还在那占着位置。这就是session 肥胖症。为什么 /compact 不够用OpenClaw 自带 /compact 命令会让 agent 把长历史压缩成一段摘要。问题是摘要是自然语言写的。自然语言摘要有三个毛病第一密度低。agent 写的摘要经常是我们讨论了 X然后做了 Y接着解决了 Z 的问题这种句子。看着像有信息量实际上恢复现场的时候什么都找不到。文件路径没了决策原因没了下一步动作模糊了。第二每次不一样。同样的 session让 agent 压两次出来的摘要结构完全不同。下一个 agent 接手的时候不知道该信哪个版本。第三该删的没删该留的没留。闲聊保留了文件路径丢了。过程保留了结论丢了。换一种压法结构化索引我们在生产环境里试了一种不同的压缩方式。不写自然语言摘要写结构化索引。格式长这样::SESSION_INDEX{ ::META{ session_key:bounty-hunter-2026-05-08 date:2026-05-08 topic:操盘手特训营全书重塑 status:active } ::GOAL{ primary:完成全书 PDF 输出 } ::DECISIONS{ ::ITEM{id:D1|desc:用 weasyprint 不用 wkhtmltopdf} ::ITEM{id:D2|desc:中文字体用 Noto Sans CJK} } ::STATE{ ::ITEM{key:主稿|value:已完成|conf:high} ::ITEM{key:PDF输出|value:被 elevated 权限阻塞|conf:high} } ::ARTIFACTS{ ::FILE{path:/root/workspace/特训营.md|role:主稿|status:final} ::FILE{path:/root/workspace/特训营.print.html|role:印刷版|status:ready} } ::TODO{ ::ITEM{prio:P0|task:开通 elevated 权限后安装 PDF 工具链} ::ITEM{prio:P1|task:生成 PDF 并验证中文显示} } ::RISKS{ ::ITEM{level:high|desc:Telegram provider 下 elevated 未生效} } ::ANCHORS{ ::ITEM{ref:/root/workspace/特训营.md|note:全书终版在这} } ::SUMMARY{ one_line:主稿和HTML都好了卡在elevated权限出不了PDF } }对比一下两种压缩方式自然语言摘要结构化索引信息密度低散文体高每行一个事实一致性每次压出来不一样格式固定机器可解析文件路径经常丢强制保留决策记录混在段落里独立字段下一步动作我们接下来可以考虑...P0/P1/P2 优先级恢复速度要读完整段再理解扫一眼就知道现场token 成本200-500 tokens80-150 tokens同样的信息量结构化索引的 token 成本大约是自然语言摘要的 1/3。什么时候压不是等 session 卡死了才压。我们定了八个触发条件会话超过 30 条有效消息出现大文件操作PDF、长文档、批量编辑一个任务形成了稳定结论heartbeat 到来且 session 明显变肥即将 /new发现装配成本在上升回复变慢完成一个阶段性交付物出现重复上下文或重复解释关键的思维转变heartbeat 不只是报平安还要承担瘦身职责。agent 收到 heartbeat 的时候先检查 session 是不是肥了肥了就先压再回复。恢复怎么做压完之后agent 恢复现场的顺序也要倒过来先读 PROJECT_INDEX项目级再读 SESSION_INDEX会话级再读相关文件只有索引不够时才回看原始长历史大部分 OpenClaw agent 的默认行为是反过来的先扫全量 trajectory装配整段历史然后在一堆过期信息里找有用的。这就是慢的根源。两层压缩短期任务只需要 SESSION_INDEX。长期项目需要两层SESSION_INDEX 记录这次会话做到哪了PROJECT_INDEX 记录这个项目长期做到哪了。::PROJECT_INDEX{ ::META{name:操盘手特训营|updated:2026-05-08} ::GOAL{primary:完成全书出版级 PDF} ::FACTS{ ::ITEM{key:总字数|value:85000} ::ITEM{key:章节数|value:12} } ::DECISIONS{ ::ITEM{id:PD1|desc:排版用 CSS print media 不用 LaTeX} } ::ARTIFACTS{ ::FILE{path:特训营.md|role:主稿|status:final} } ::NEXT{ ::ITEM{prio:P0|task:PDF 输出} } }项目跨了十几个 session换了三个 agent中间重启过两次 gateway。只要 PROJECT_INDEX 在任何一个新 agent 读一遍就能接手。不需要回放十几个 session 的完整历史。实测效果在我们的生产环境里OpenClaw Telegram每天 100 消息用这套协议跑了一周指标压缩前压缩后平均回复延迟8小时 session12-15秒3-5秒单次装配 token 消耗8000-120002000-4000Telegram 超时率每天 3-5 次基本消失/new 后恢复时间30-60秒5-10秒agent 接手准确率看情况读索引就能干活最明显的变化是 heartbeat 不再卡了。之前 heartbeat 经常因为 session 太重光装配上下文就超时。现在 heartbeat 到了先压一下session 保持在合理体重后续每次回复都快。完整协议完整的 Session Compression Index Protocol v1.0 已经开源包含十四个章节总原则、触发条件、压缩目标、输出位置、索引格式、项目级压缩、写作规则、恢复策略、heartbeat 规则、/new 规则、主会话纪律、禁止事项、铁律、最终目标。GitHub 地址评论区问我要索引格式用的是 I-Lang 的声明语法::ENTITY{field:value} 结构如果你用过 I-Lang 的 SOUL 或 GENE 定义这个格式会很熟悉。不了解也没关系上面的例子照着抄就能用。一句话你的 agent 不是变笨了是被自己的历史压垮了。给它一个索引层让它靠索引活不靠长聊天活。