夜雨聆风最近在做 OpenClaw 连续业务调试时，我们遇到一个很典型的问题：单轮问题还能接受，但一旦连续提问，响应时间会明显拉长，首字节越来越慢，输入体积也越来越大。
如果只凭体感，很容易把原因归结为“模型慢”或者“工具多”。但真正把数据拉出来之后，会发现问题并不只是模型本身，而是一个更典型的系统问题：上下文膨胀。
本文基于一组真实连续 10 轮业务问题调试样本，从运行与运维视角复盘 OpenClaw 为什么会慢，以及哪些优化最值得优先落地。
一、这次分析覆盖了什么
本次样本不是单一问答，而是一组连续业务问题，场景包括：
库存查询 商品价格与补货 销售与三级账 进货统计 供应商分析 销售预测与采购建议 行程与酒店查询 在途未收货单据 日销与热销商品 最后一轮整体复盘分析
运行环境是一套典型的 Agent 体系：
测试环境 容器规格：4C8G 使用主流大模型 存在模型代理层 默认高思考等级 开启技能自动模式 接入多个外部工具服务 带有 workspace 规则、memory 机制和技能体系
这不是“轻量聊天机器人”场景，而是一套已经进入真实业务接入阶段的智能体运行环境。
二、先看总体数据
先看本次样本的核心统计：
这组数据至少说明了两件事：
第一，输入远大于输出。总输入约 1280 万 Tokens，但总输出只有约 2.8 万 Tokens，说明系统的主要成本并不在“生成内容”，而在“理解上下文”。
第二，固定底噪已经非常重。即使用户问题很短，系统每次仍会稳定带入接近 7.8 万字符的固定上下文。
三、连续 10 轮问题的速度表现
为了看清这不是偶发现象，而是随着问题推进不断加重，我们把 10 个主问题的关键数据整理如下：
这张表反映出几个关键现象：
首条响应延迟已经从个位数秒拉长到 20 秒、30 秒、甚至 50 秒级 耗时最长的几轮，整轮已经接近 6 分钟 并不是只有“最复杂的问题”才慢，部分查询型问题的首字节也同样偏长
这说明问题不仅仅在工具链路长，还在于模型前置负担过重。
四、为什么越问越慢
继续看会话快照的累计变化：
这组数据非常清楚地说明：
后续问题并不是独立执行的，而是在同一个长会话中不断累积历史。
最明显的证据有两个：
消息数从 31 增长到 266 请求体平均体积从 12.7 万字符膨胀到 42 万到 51 万字符
这意味着后面的每个问题都在反复消费前面的问题、回答、工具返回和过程信息。所以“越问越慢”并不是主观印象，而是长会话不断叠加的结果。
五、真正拖慢系统的，不是用户问题，而是 Tool 结果
输入膨胀拆解的数据更能说明问题：
这张表能直接得出一个非常关键的结论：
最大的动态输入来源不是用户问题，也不是固定 System Prompt，而是历史 Tool 原始返回结果。
从版本 2 开始，Tool 结果长期占整体上下文的 70% 到 80%。这意味着模型每次处理新问题时，首先要重新阅读大量旧的工具返回，而不是优先处理当前问题。
这也是为什么后续问题的输入规模会长期维持在十万 Tokens 以上。
六、这不是单纯的模型问题，而是上下文治理问题
很多团队遇到类似现象时，第一反应会是：
模型是不是慢 代理层是不是有额外延迟 工具服务是不是太多
这些都可能有影响，但从本次样本看，更核心的问题其实是：
模型每次收到的内容太重了。
这种“重”，主要来自四个方面。
1. 固定输入成本高
system prompt、tool schema、技能目录、workspace 规则会稳定进入每次请求，形成很重的固定底噪。
2. 默认思考等级偏高
当前系统默认高思考模式，对规划、总结类问题有价值，但对库存、价格、单据、基础查询类问题并不划算，反而会放大首字节时间。
3. 长会话历史未压缩
只要会话不压缩，历史就会持续膨胀，后续轮次的推理负担只会越来越重。
4. 工具结果未摘要化
工具执行结果如果不做结构化摘要，而是直接回灌原始内容，就会迅速吞掉上下文预算。
所以，从运维和系统工程的角度看，本次问题的本质并不是“模型性能不足”，而是“上下文治理失控”。
七、技能体系方向是对的，但消费方式需要调整
这套环境里已经有 43 个自定义 Skills，覆盖多个业务域。这说明系统已经做了较多业务沉淀，从方向上看是正确的。
但当前更需要关注的问题是：技能资产是如何被消费的。
如果 Skill 被设计成运行时长文档，默认全量进入上下文，那么它就不再是能力资产，而会变成输入负担。
更合理的做法应该是：
平时只保留轻量技能索引 当前问题命中时，再加载对应的 1 到 2 个 Skill Skill 内容更偏执行规约，而不是长篇说明手册 Tool 调用完成后，必须输出摘要化结果
因此，对当前技能体系的评价应该是：
业务沉淀方向是对的 技能数量和覆盖面已经具备价值 问题主要不在“有没有 Skill”，而在“Skill 是否以低成本方式参与运行”
八、哪些优化最值得优先落地
如果从落地收益和改造成本综合考虑，最值得优先做的有五项。
1. 下调默认思考等级
将默认高思考调整为中等或更轻模式，让查询型问题优先走轻量路径。
2. 停止回放原始 Tool 结果
工具执行完成后，只保留：
主键 时间范围 核心统计值 结论 是否需要继续查询
不要继续带原始 JSON。
3. 停止回放过程性推理信息
历史中只保留用户问题和最终回答，不再保留中间的思考痕迹和调用结构。
4. 新问题切新会话，或设置强压缩规则
顶层新问题不应持续沿用旧历史。如果不方便切新会话，也至少应设置会话长度阈值和自动压缩策略。
5. 技能按需加载
不再默认全量加载技能描述，而是采用“先索引、后命中、再读取”的轻量策略。
如果只能优先做三件事，建议顺序如下：
下调默认思考等级 停止回放原始 Tool 结果 新问题切新会话
这三项通常就能显著改善首字节和整体响应速度。
九、结论
这次连续 10 轮业务调试案例给出的结论非常明确：
OpenClaw 之所以会越跑越慢，核心并不只是模型本身，而是上下文持续膨胀。
从系统层面看，问题主要来自：
固定底噪重 默认思考等级高 长会话不压缩 Tool 原始结果持续回灌 技能体系没有按需消费
因此，下一阶段真正应该做的，不是继续一味增加技能、增加工具、增加规则，而是把重点转向上下文治理。
一句话总结：
OpenClaw 的性能问题，很多时候不是模型不够快，而是系统让模型处理了太多本不该反复处理的内容。谁能把上下文装配得更轻、更准、更可控，谁的系统就更稳定，也更接近可持续的生产形态。
