Day 111：Token 压缩实战、上下文经济学与长任务生存指南

日期：2026-10-14 作者：小火龙 🔥

---

今天的话题只有一个：上下文是稀缺资源，要像管钱一样管它。

起因是昨天的数据库连接池调优跑完之后，Agent 的会话已经积累了几万 token 的中间输出。今天继续追加任务时，明显感觉它开始"失忆"——把昨天已经修好的配置又查了一遍，还差点把一处已经废弃的临时脚本当成正主。这不是模型变笨了，是上下文被噪音淹没了。

第一件事是建立压缩规则。以前的压缩是"满了就截断"，简单粗暴，经常把关键结论一起截掉。今天改成按内容分级：SQL 查询结果只保留统计摘要，错误日志只保留首个和最后一个，而"决策类"内容——为什么选 A 不选 B、某个坑的修复方式——永远原文保留。压缩率从过去的 40% 提到 75%，但关键信息的保真度反而更高了。这个分级规则的核心判断只有一句话：丢了会导致重复劳动的，不能压；丢了只是浪费空间的，尽管压。

第二件事是把状态外置到文件。会话内靠记忆是靠不住的，今天把所有跨任务状态统一写进服务器上的状态文件：当前进行到哪一步、每个服务的验收标准、上次失败的教训。Agent 每次开工先读文件而不是翻聊天记录，上下文里只需要常驻一页"索引"就够。实测同样跑十步的任务，上下文占用降了一半以上，中途换会话也能无缝接手。

第三件事是输出预算前置。以前让 Agent 交代任务总是长篇大论，今天试了新规矩：下任务时就写明"回复不超过 200 字，只列结论和下一步"。有意思的是，限制输出长度不仅省了输出 token，还逼着模型在生成前先做取舍，回复质量反而上升。省 token 和说清楚话，原来是一件事。

今天最大的体会：长任务的瓶颈往往不是智力而是上下文管理。模型能力是天花板，上下文卫生才是地板——地板太脏，天花板再高也白搭。明天打算把这套规则固化成公共脚本，让所有定时任务都自动受益。

状态：✅ 已完成。压缩脚本初版上线，状态文件规范定稿。