编程任务的上下文治理，要同时减少重复输入和保留判断所需证据。本文以虚构的社区图书交换站字段迁移为例：Agent 需要把旧字段兼容到新接口，不能遗漏失败测试、迁移前提与回滚。我们按终端输出、会话压缩、技能加载三个入口设计对照，不沿用原文的账单故事、套餐限制或固定节省比例。
先分清输入长度、额度与账单
命令输出只是输入的一部分，系统规则、用户请求、历史、技能和模型输出都会影响资源使用。订阅额度与 API 费用也不等价。保留模型、主机、任务、缓存与重试口径，使用实际用量记录；没有准确 tokenizer 时只能写估算，不能把字节或字符直接当作计费 token。
开始前检索 GitHub 开源方案，参考 RTK 的命令输出过滤路径及其节省说明：其文档区分 shell 输出缩减和最终账单变化，展示的 token 数有估算前提。它是值得评估的现成实现，不是原文所有同名技能的核验结果。采用前检查许可、维护、依赖、主机集成和恢复方式，本文没有安装或运行过滤器。
先保存未经优化的同任务基线，记录完成率、调用、重试、耗时与输入输出。每次改一层，比较通过验收的整个任务成本。某轮输入更短但需要反复回查或误改代码，不能称净收益。原文宣称“装上净省”不是普遍成立的前提，压缩、搜索与摘要本身可能增加模型调用。
场景一：命令先缩范围，再过滤输出
查字段迁移先定位相关模型、接口与测试，不把全仓库日志、锁文件和长 diff 都交给模型。使用路径、文件类型和查询条件控制搜索，保留条件与未覆盖范围。简洁状态适合看改动概览，关键代码审查仍需读完整相关上下文；只看签名不能验证迁移实现。
过滤器需要保留命令、工作目录、退出码、失败用例、预期与实际、关键堆栈和原日志位置。通过项可汇总，重复警告可计数，但不同位置的同文案错误不能合并。YAML、JSON 或锁文件在当前问题中可能就是证据，不能因为长就都当噪声。截断写截断，不称完整检查。
原始输出保存到获准本地位置，保留检索与回取方法，设置访问与保留期限。日志可能包含密钥、私有路径和用户数据，发送到外部压缩服务前确认具体范围与目的地。过滤器自身的安装脚本、hook 和代理行为也要检查，不为节省上下文改变系统代理或安全控制。
用正常测试、未知失败、空输出、多行堆栈、超长行和中文路径试验。确认过滤后仍能判断目标故障，管道不会把生产者失败改成成功。若命令输出需要供后续脚本解析，就保留机器可读原件，不用自然语言摘要替代有效 JSON。先低风险验证，再扩大使用范围。
可给 Agent 请求：“只检查旧新字段兼容相关用例，保存完整日志；返回实际退出码、失败断言和有关堆栈。未知错误保留原文，不能为了简洁隐藏失败。”用原输出和过滤结果对照，记录哪些细节被省略以及是否额外回取。
场景二：长会话压缩保留行动状态
交接摘要包含目标、最新用户要求、当前版本、允许动作、已执行与证据、未完成、已否定方案和下一步。字段迁移尤其保留旧字段兼容期限、数据库状态、备份与回滚前提。计划执行不是执行完成，测试环境通过不是生产迁移完成，不能为了短把这些状态合并。
先保存可恢复原记录，再压缩客套、重复日志和已无关讨论。关键约束、失败原因、版本和证据链接优先保留。旧要求被新要求替代时记录替代关系，不将矛盾指令并列成同时有效。恢复路径必须能被下一会话访问，不能只写临时变量或已关闭窗口。
摘要不可能保证答案完全不变。用新阅读者核对：能否说明当前要修什么、不能改什么、哪个检查真跑了、下一步为何安全？若答不出，回取原文补证据。截断和摘要都可能损失信息，所谓可恢复依赖原件存在且可访问，不是摘要算法的自动保证。
设置压缩与回取预算。摘要过度可能让 Agent 反复读回全量记录，导致总调用增加。对代码与用户原始输入尤其谨慎，保留语义和准确引用；不能把压缩后的伪代码当原始实现。比较压缩前后任务正确性与返工，而不只看长度下降。
场景三：按实际加载行为管理 Skill
先观察当前主机加载的是名称描述、完整正文还是按需引用资源，记录版本与作用域。安装数量不等于每轮输入全部正文，懒加载也不代表元数据与搜索零成本。不要从一个用户删除很多技能的故事推导所有主机都能省同样费用。
盘点技能名称、描述、来源、路径、用途和最近验证。重叠项先测试是否可替代；低频关键恢复方法不能仅因少用就删除。按主机支持方式缩小作用域或停用，备份配置并记录恢复位置，不未经授权批量清理。必要项目规则不应为了省 token 被藏到无法触发的技能里。
给每个技能设预算时，先按真实模型 tokenizer 或主机用量确定可观测口径；没有准确数据写估算。超预算应先精简重复、拆分参考并保留触发与边界，不机械截断一半。缺掉失败处理的短技能可能比长技能造成更大损失。
描述以具体用户意图为准，测试应触发与不应触发的任务。关键词搜索可辅助发现，但命中不等于最佳匹配。当前 SkillPI token 查询结果主要是认证令牌与 SDK，不能关联为上下文压缩能力；本篇暂不编造原文六个名称的平台链接。以后有可核验匹配条目再按输出、摘要或加载步骤更新关联。
同任务对照与故障恢复
固定代码、任务、模型与 fixture，分别比较只过滤、只摘要、只调整技能范围。检查兼容断言、未修改范围、退出码、回滚资料和最终产物。记录额外回取、重试与人工修复。缓存或定价变化与输入减少分开，不把输出字节降低百分比写成总账单下降百分比。
过滤丢堆栈就恢复相关段并改规则；摘要漏兼容要求就回取原记录；技能不触发就查主机发现和描述，不继续堆相似包。优化导致正确性下降时回退，不用更短结果掩盖任务未完成。额度异常也要查实际服务使用与重试，不假定都是日志造成。
FAQ 与验收包
省 token 的方法自己会耗吗？可能，特别是模型摘要、检索和评估，需看净效果。过滤能保证不丢错吗？不能，先用已知与未知错误样本验证并保留原件。压缩是截断吗？可以是摘要或结构过滤，但两者都要检查信息损失与恢复路径。
适用于所有编程 Agent 吗？原则可参考，具体命令、hook、加载与计费取决于主机和版本。应该先装哪个？先找基线中最大且可解释的重复输入，复用现有功能试验，不把发现器作为必要前提。
交付基线、输出对照、原日志索引、交接摘要、加载观察、配置差异与恢复说明。只声称实际测过的范围和口径。本文没有修改读者主机、读取额度或执行 token 实验。
来源
本文按中英文原文的输出过滤、会话压缩和按需加载三场景，以原创字段迁移案例重写。开源方法与统计边界参考 RTK 官方仓库及节省口径说明。采用具体功能前核对当前版本与官方说明，不直接复述宣传比例。