一、问题描述
在使用 OpenClaw 这类工具进行桌面 UI 自动化时，观察到 Token 消耗显著高于预期。一个典型的"定位按钮并点击"操作，实际消耗往往达到数千甚至上万 Token。这种现象在多步骤任务中更为突出。
本文尝试从几个角度探索可能的优化方案，部分经过实测验证，部分仍处于推演阶段。
二、消耗分析
首先要弄清楚 Token 消耗在哪些环节。
截图传输
每张 1920×1080 的截图压缩后约 200--300 KB，经视觉模型编码后对应 1500--2500 Token。一个包含 5 次截屏的简单任务，仅此一项就消耗近万 Token。
上下文膨胀
系统启动时自动扫描 workspace 目录，加载所有可读文件。实测发现，一个仅有 22 Token 输入的任务，系统加载了超过 4 万 Token 的上下文，其中包含大量无关的备份文件、重复配置和历史日志。
重复描述
在多步任务中，模型需要反复描述当前 UI 状态。随着步骤增加，这些描述累积成为显著的 Token 开销。
三、模型路由
一个直观的思路是：不同复杂度的任务使用不同规模的模型。
操作方法
在工具配置中加入任务分类逻辑。简单任务（元素定位、单次点击）调用小参数模型（如 Gemini 2.0 Flash-Lite），复杂任务（多步推理、跨窗口比对）调用大模型（如 Claude Opus）。分类可以通过关键词匹配或调用一个极低成本的分类模型实现。
实测结果
在 50 个混合任务的测试中，采用关键词路由后总 Token 消耗降至原来的约 40%，成本降至约 15%，成功率从 96% 降至 92%。主要的成功率损失来自 3 次分类错误------复杂任务被错误分配给能力不足的小模型，导致重试。
适用条件
任务链条较长（5 步以上）且任务类型分布稳定的场景。短任务场景下，路由本身的额外开销可能抵消节省。
四、上下文压缩
这个方向的目标是减少每次请求携带的冗余信息。
文件层清理
检查 workspace 目录，移出以下类型文件：备份文件（.bak）、重复的配置文件（多份 AGENTS.md）、与当前任务无关的大体积日志。在一个典型项目中，清理后初始上下文从 4.4 万 Token 降至 1.9 万 Token，降幅约 57%。这项操作没有观察到负面效果。
历史消息压缩
使用 /compact 命令定期压缩对话历史，移除已过时的 UI 状态描述。测试了不同压缩频率：
- 每 5 步压缩：平均上下文 1.2 万 Token，成功率 91%
- 每 10 步压缩：平均上下文 2.4 万 Token，成功率 94%
- 不压缩：上下文持续增长至超过 5 万 Token，成功率 95%
过早压缩会导致早期任务目标和约束丢失，引发重复操作。每 10 步压缩在成本和成功率之间取得较好平衡。压缩的最佳间隔可能与具体任务类型相关，尚无通用公式。
五、按需检索
全量加载所有记忆文件的低效问题，可以通过检索替代来解决。
核心思想
收到任务时，不加载全部历史记忆，而是以任务描述作为查询，从记忆库中检索最相关的少量记录，仅将检索结果注入上下文。
实现方式
在 OpenClaw 中接入本地检索模块，使用 BM25 加向量匹配的混合检索策略。向量化采用 all-MiniLM-L6-v2 模型（384 维）。每次检索返回 top-5 记录，约 1000--2000 Token。
对比测试
测试任务为每日报表导出（7 步，需调用历史操作记录），记忆库大小约 15KB：
- 全量加载：平均 15,200 Token，成本 $0.061，成功率 94%
- top-5 检索：平均 5,800 Token，成本 $0.023，成功率 92%
- top-3 检索：平均 4,100 Token，成本 $0.016，成功率 90%
待解决问题
检索召回率受查询措辞影响。"导出昨天的报表"与"把昨天那个报表再导一次"的检索结果存在差异。将向量模型升级到 768 维后召回率从 82% 升至 87%，但检索延迟从 0.2 秒增加到 0.6 秒。对于实时交互任务，这个延迟可能需要考虑。
六、视觉替代
截图的高 Token 消耗推动了对替代数据源的探索。
Accessibility Tree
操作系统提供的 UI 结构描述，以文本格式呈现，包含元素类型、名称、状态和层级关系。同一界面，截图约 2000 Token，Accessibility Tree 仅 400--800 Token。
测试了不同应用类型上的元素定位成功率（以截图方案为基准）：
- 原生 Win32 应用：89%，与截图接近
- Qt 应用：84%，略低
- Electron 应用：62%，明显下降
- 无辅助标签的网页：45%，不可用
混合方案（优先尝试 Accessibility Tree，失败时回退到截图）可将 Token 消耗降低约 35%，同时保持与纯截图方案相近的成功率。
DOM 剪枝
针对网页 UI，完整 DOM 树常达数万 Token。通过只保留可见元素、移除脚本和样式节点、限制遍历深度，可以将一个原始 25,000 Token 的 DOM 压缩至 3,000--5,000 Token。元素定位成功率从 91% 降至 83%，损失在可接受范围内。
七、未解决问题
以下现象已有观察，但尚未形成稳定的解决方案。
轮询等待的浪费
在等待异步操作完成时，Agent 以固定频率（约 1 秒）截屏检测变化。观测到一个等待 8 秒的任务实际截屏 9 次，其中 8 次的画面没有变化。这部分浪费约占总 Token 消耗的 20--30%。尝试设计自适应频率调节机制（检测到连续 N 次相同截屏后降低轮询频率）尚未完成。
模型切换延迟
模型路由节省了成本，但增加了延迟。每次切换涉及新的 API 连接建立，实测增加 0.8--1.2 秒。对于交互式任务可能不可接受，更适合后台批处理场景。
长链条状态漂移
超过 15 步的任务中，即便采用定期压缩，模型对早期 UI 状态的描述仍会逐渐偏离实际。压缩策略保留下来的信息不足以纠正这种漂移。可能需要引入显式的状态校验点------在关键步骤后重新读取并确认 UI 状态，但这会增加截屏次数，与降本目标存在冲突。
八、小结
基于当前测试，以下几种优化相对成熟，可以直接采用：
| 优化项 | Token 节省 | 成功率影响 | 实施难度 |
|---|---|---|---|
| 文件清理与去重 | 25--50% | 无 | 低 |
| 模型路由 | 40--70% | -2~4% | 中 |
| 按需检索 | 60--75% | -2~5% | 中 |
| Accessibility Tree 优先 | 30--50% | -3~8% | 中 |
| DOM 剪枝 | 30--60% | -5~10% | 中 |
各项优化的适用条件不同，相互之间可以叠加使用。例如，在长链条的网页自动化任务中，可以同时采用模型路由、DOM 剪枝和按需检索，预期综合节省可达 80% 以上，但需要验证叠加后的成功率变化。
上述结论基于特定软件版本（OpenClaw v0.5.2）和有限的测试任务集，泛化性有待进一步验证。后续计划在更多类型的应用和更长的任务链条上重复测试，以确认这些优化方案的稳定性和适用范围。