1. 项目背景:当AI Agent开始"暴饮暴食"
去年在部署OpenClaw处理一个大型代码仓库时,我遇到了一个令人抓狂的现象:每次Agent执行read_file操作后,系统响应速度就会明显下降。通过监控面板发现,一个简单的代码查询任务竟然消耗了超过50万tokens——这相当于让AI把整本《战争与和平》从头到尾读了五遍,而它实际需要的可能只是某个函数定义。
这种"暴饮暴食"现象在AI Agent领域非常普遍。传统架构下,Agent处理信息就像个不懂节制的饕餮:
- 读取500KB的日志文件?全部吞下!
- 历史对话超过20轮?全部记住!
- 需要修改某行代码?先把整个项目塞进上下文!
这种全量堆叠(Message Bloat)的设计至少带来三重伤害:
- 经济成本:云服务API按token计费,无效传输直接烧钱
- 性能损耗:模型需要处理的无关信息越多,响应速度越慢
- 推理干扰:就像在嘈杂的菜市场做数学题,无关信息会降低AI的判断准确率
实测数据:原版OpenClaw处理100MB代码库时,单次任务平均消耗82万tokens,其中有效信息占比不足15%
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 问题诊断:解剖Agent的"消化系统"
2.1 全量堆叠的三宗罪
第一罪:文件读取黑洞
当Agent调用read_file读取配置文件时,传统做法是把整个文件内容永久存入messages数组。后续每次交互,模型都要重新"阅读"这个文件——哪怕只是询问文件创建时间。
第二罪:历史对话滚雪球
在多轮对话中,系统会将所有历史消息(包括工具调用、中间结果、调试信息)不断累积。就像开会时每个人都要重复之前的所有讨论,效率可想而知。
第三罪:暴力检索综合症
Agent需要某个函数定义时,常见做法是:
- 读取整个项目结构
- 加载所有源代码文件
- 在内存中全文搜索
这种"把图书馆所有书倒在地上找一句话"的方式,消耗惊人。
2.2 人类智慧 vs 机器蛮力
观察程序员的工作方式,会发现完全不同的模式:
- 分层处理:先看目录结构 → 定位子模块 → 找到具体文件 → 跳转到目标行
- 按需加载:只打开当前需要的文件,用grep等工具精准定位
- 记忆摘要:记住"刚才修改了c
