上下文太长，先找重复输入在哪里，而不是先安装一个宣称能省九成 token 的工具。以虚构的城市步道网站维护任务为例：Agent 需要修正路线筛选、保留旧接口兼容，并交付回归结果。真正要减少的是与这个决定无关的材料；失败证据、约束和用户授权范围不能随摘要一起丢掉。
先建立同任务的基线
选一组固定任务和相同版本的代码、模型与测试夹具，记录每个任务的输入、输出、工具调用次数、失败重试、耗时和最终正确性。把工具日志、会话历史、技能描述与正文分开统计。字符数只能作粗略代理，不能把中文字符、英文单词、字节直接当作模型 token。若主机只显示估算量，标记“估算”，不要伪装成计费明细。
基线还要记录缓存命中、输入与输出的计量口径，以及是否包含重试。某次输入变短，但为了找回丢掉的错误堆栈多跑五次命令，总成本可能更高。用完成并通过验收的任务比较，而不是挑最短的一轮对话。本例的指标表是工作方案，本文没有执行成本实验或承诺节省比例。
开始前检索了 GitHub 的开源相关资料，参考 BerriAI 的 LiteLLM 文档仓库理解使用量中缓存部分的区分。它适合了解已有网关的计量边界，不是为减少日志就必须新增的服务。引入网关还会增加依赖、凭据和运维成本；本例先采用原生命令过滤、可回查记录与小范围技能配置，不下载执行压缩器。
场景一：压住工具输出，留下可追查证据
先缩小命令的查询范围。要判断改动文件，使用简洁状态和目标路径；要定位路线筛选，搜索相关组件、接口与测试，不把整个仓库打包给模型。搜索命中太多时按文件类型或目录收窄，保留搜索条件和未覆盖范围。空结果只表示这次查询没找到，不能推断功能不存在。
测试输出先给结论与定位线索：运行命令、工作目录、版本或提交、退出码、失败测试名、预期与实际、关键堆栈、原始日志位置。通过测试可汇总数量，失败样本不能只剩一句“有错误”。对于相同警告，可写出现次数和首个完整例子，但保留与此次失败相关的差异。去重时不能把不同文件同名错误合成一条。
完整日志留在获准的本地位置，摘要只引用路径和必要片段。向任何外部服务传日志前，先按任务权限处理凭据、个人信息和私有路径，不能为了压缩把原日志发送到陌生网站。原始日志也应有访问与保留期限；“留本地”不是无限期堆积的理由。
管道接入前验证退出码传递。过滤器成功不等于被测程序成功，截断输出也可能让生产者异常退出。分别检查失败命令、无输出命令、超长行、Unicode 路径和多行堆栈。自动摘要应标注省略了什么；如果只有前几行，要写“截断”，不能写“完整检查”。
可给 Agent 的请求是：“只跑路线筛选相关测试，保存原始日志；返回退出码、失败用例和第一处有关堆栈。重复信息按数量汇总，遇到未知错误保留原文，不把失败改写成通过。”交付物包括摘要、原日志索引、过滤规则和一组对照样本。
场景二：把长对话变成有证据的交接
会话摘要应保留任务目标、已接受约束、当前代码版本、已完成动作及证据、尚未确定的问题、下一步和恢复路径。把事实、推测与提议分开。例如“已修改筛选器”不是“接口兼容已通过”；“准备发布”不是“已经上线”。标记测试是在 mock、局部测试环境还是实际目标上完成，避免续跑时扩大结论。
以步道网站为例，热信息是当前失败用例和待改函数；温信息是已确认的接口约定、设计决策与相关文件；冷信息是完整日志、旧方案和可回查讨论。热温冷只是一种组织方式，不代表主机必然按这三层自动加载。摘要内写清如何检索冷资料，不要假定新会话能访问上一轮临时变量或未保存窗口。
每次压缩前保留可恢复的原记录，并验证摘要是否能支持下一步。让另一轮阅读者回答：当前要修什么、不能改变什么、哪个测试真跑过、还有哪个疑点？答不出时回查来源补齐。旧决定如果后来被用户改掉，要保留最新决定和替代关系，不能把互相冲突的要求拼成同时生效。
压缩强度应随风险变化。删除客套与重复日志通常代价低；删除授权边界、失败分支、版本号或证据引用可能引发重复发布、错误回滚。若摘要器只保留“总体成功”，直接拒收该摘要。所谓十万压到八千，是需要按任务检验的信息损失取舍，不是任何会话都适用的质量保证。
实操交接卡可写：“目标：修复筛选后的空列表提示；约束：保持旧查询参数；完成：提交 X 的单元测试通过，见日志 A；未完成：移动端返回键未测；下一步：在测试环境复现返回操作；发布状态：未发布。”其中 X 和 A 必须替换成真实可访问记录，不能把模板占位当成完成证据。
场景三：让技能库围绕任务加载
先盘点当前主机实际发现了哪些技能，哪些名称与描述进入上下文，哪些正文按需读取。不同产品、版本与配置可能不同；不能断言安装一百个技能就必然每轮加载一百份完整正文。记录主机版本、作用域、发现路径与可观察证据，再决定调整方式。
把稳定规则与专门方法分开。项目必须遵守的目录规则、安全边界和交付要求应保留在相应规则层，不能为了省 token 藏进不会触发的技能。将专门技能放在需要它的项目或作用域，按主机支持方式禁用不常用项；改动前备份配置并记录原位置，不未经授权批量删除目录。
名称和描述应准确表达触发条件，而不是塞入所有关键词抢匹配。先用几条真实任务测试路由：修复筛选应找到开发与回归方法，整理会议资料不应加载数据库迁移方法。记录漏触发、误触发以及所读文件；必要时明确指定一个已核验技能。加载器增加一次搜索与读取也有成本，按需加载不是零开销。
本轮刷新 SkillPI 的 token 搜索，结果主要涉及认证令牌、通信凭据与 SDK，不能因为英文同词就关联到语言模型上下文压缩。本专题暂不附这些不匹配的 Skill，也不把原文六个名称冒充已在 SkillPI 核验的记录。未来新增候选时，逐一确认公开详情、固定来源、许可、运行前提及它具体覆盖日志、会话还是加载步骤。
对照实验与故障处理
先改一层：例如只缩短工具输出，保持任务、模型、历史策略与技能配置一致，再观察正确性、token、调用次数和耗时。用同一组正常、失败与边界案例做前后对照，检查是否需要额外回查。缓存命中带来的计费变化应与实际输入长度变化分开；缓存并不自动缩小模型所面对的上下文。
若模型漏掉失败，恢复原始错误段并调整保留规则；若交接后反复做旧工作，补动作状态、证据与最后检查点；若技能不触发，查描述、作用域和主机发现记录，而不是安装更多相似包。若统计节省很多但完成率下降，回退压缩强度，按成功任务的总成本重算。
FAQ 与验收清单
先压命令还是会话？从基线中最大且最重复的部分开始，通常先缩小命令范围比较容易验证。要不要用统一压缩器？先拿堆栈、代码缩进、JSON 和多语言样本验证；删除注释可能改变解释信息，激进压缩可能破坏机器可读格式，不能把一种规则无差别套到所有内容。
技能多是否一定浪费？只有观察实际加载范围后才能判断，安装数量不等于输入 token。摘要能否替代原记录？不能，关键结论仍需来源与回查路径。工具免费是否等于没有成本？还需计算模型调用、依赖安装、维护和失败恢复，许可与服务收费也要分别核实。
验收时保留基线表、过滤规则、原日志索引、交接卡、技能配置差异和恢复步骤。用至少一个失败案例确认退出码与错误证据没有丢失，用一个续跑案例确认没有把未发布误记为已发布。结果只声明测过的任务与环境，不宣传统一百分比。
来源
本篇依照中英文原文的工具输出、长会话与技能库三类场景，用原创步道网站案例重写；未核实的用户引语、安装量与节省比例不作为事实沿用。缓存计量边界参考 LiteLLM 官方文档仓库，具体供应商与模型的当前要求应另查官方说明。本篇没有安装加载器、修改读者配置或执行节省实验。