findscripter 何时使用
在以下情况启用本技能：
- 智能体会话历史超出上下文窗口限制（动辄百万 token）。
- 代码库本身超出窗口（5M+ token 级系统）。
- 设计对话摘要 / 会话压缩策略。
- 排查智能体「忘记自己改过哪些文件」一类问题。
- 构建压缩质量的评估框架。
核心目标不是「每次请求最少 token」，而是「每个任务最少 token」：从任务开始到完成消耗的总 token，包括压缩丢信息后被迫重新抓取的成本。一个只多省 0.5% token、却引发 20% 重抓取的策略，总账更亏。
不该用的边界：
- 会话很短、或重抓取成本极低时，直接用最激进的不透明压缩即可，无需本技能的结构化开销。
- 本技能产出的摘要不能替代环境内的实测、验证与专家复核。
- 缺少必要输入、权限、安全边界或成功标准时，先停下来澄清，不要硬压。
步骤
锚定式增量摘要（Anchored Iterative Summarization，首选）的落地流程：
- 按智能体需求定义固定的摘要分区（见下方模板）。
- 首次触发压缩时，把被截断的历史归纳进各分区。
- 后续每次压缩，只归纳新截断的内容。
- 把新摘要增量合并进已有分区，而不是整体重新生成（重生成会在多轮压缩中丢细节）。
- 记录每条信息来自哪一轮压缩，便于排查。
触发时机同样关键：
| 策略 | 触发点 | 权衡 |
|---|---|---|
| 固定阈值 | 上下文利用率 70-80% | 简单，但可能压得过早 |
| 滑动窗口 | 保留最近 N 轮 + 摘要 | 上下文大小可预测 |
| 重要性优先 | 先压低相关度片段 | 复杂但保信号 |
| 任务边界 | 在逻辑任务完成处压缩 | 摘要干净但时机不定 |
对多数编码智能体，滑动窗口 + 结构化摘要在可预测性与质量上最平衡。
指令
- 永远优化 tokens-per-task，而非 tokens-per-request。
- 用带显式分区的结构化摘要做文件追踪；分区即清单，强制摘要器逐项填写，防止信息「静默漂移」。
- 在上下文利用率 70-80% 时触发压缩。
- 用增量合并替代整体重生成。
- 用探针式评估检验压缩质量。
- 若文件追踪至关重要，单独维护工件索引（artifact index）/ 文件状态表。
- 接受略低的压缩率以换取更高的信息保留度。
- 把重抓取频率当作压缩质量的监控信号。
三种方案对比（可据此选型）：
| 方法 | 压缩率 | 质量分 | 权衡 |
|---|---|---|---|
| 锚定增量 | 98.6% | 3.70 | 质量最佳，压缩略低 |
| 重生成 | 98.7% | 3.44 | 质量尚可，可读性好 |
| 不透明 | 99.3% | 3.35 | 压缩最高，质量受损 |
多保留 0.7% 的 token 换来 0.35 质量分；凡重抓取有成本的任务，都该倾向结构化方案。选型口径：长会话 / 需文件追踪 / 要可验证 → 锚定增量；要极限省 token 且会话短 → 不透明；要摘要可读、阶段边界清晰 → 重生成。
巨型代码库（超窗口）走三阶段压缩：研究阶段产出一份结构化研究文档 → 规划阶段转成含函数签名、类型定义、数据流的实现规格（5M token 代码库≈2000 词规格）→ 实现阶段对着规格执行。若有手工迁移示例 / 参考 PR，用作模板，它能揭示静态分析看不到的约束与「本质复杂度 vs 偶然复杂度」的区分。
示例
结构化摘要模板：
## 会话意图
[用户想完成什么]
## 文件改动
- auth.controller.ts: 修复 JWT token 生成
- config/redis.ts: 更新连接池
- tests/auth.test.ts: 为新配置补 mock
## 关键决策
- 用 Redis 连接池替代每请求一连接
- 瞬时失败采用指数退避重试
## 当前状态
- 14 个测试通过，2 个失败
## 下一步
1. 修复剩余失败用例
2. 跑全量测试
3. 更新文档
探针式评估：压缩后直接提问来量化功能质量（ROUGE / 向量相似度抓不到这点——摘要词面重合度高，却可能丢了智能体唯一需要的那个文件路径）。
| 探针类型 | 测什么 | 示例问题 |
|---|---|---|
| 召回 | 事实保留 | "原始报错信息是什么？" |
| 工件 | 文件追踪 | "我们改过哪些文件？" |
| 续接 | 任务规划 | "下一步该做什么？" |
| 决策 | 推理链 | "关于 Redis 问题我们定了什么？" |
好坏对比——问「最初的报错是什么」：
- 好（结构化）："/api/auth/login 返回 401 Unauthorized，凭据有效仍失败，根因是会话存储中 Redis 连接陈旧。"——端点、错误码、根因俱全。
- 差（激进压缩）："我们在调一个认证问题，登录失败了，修了些配置。"——技术细节全丢。
注意事项
- 工件追踪是普遍最弱项（评估中仅 2.2-2.5/5.0）：即便带显式文件分区，长会话里也难保完整。编码智能体需要知道哪些文件被创建 / 被改且改了什么 / 只读未改，以及函数名、变量名、报错信息——必要时用独立的工件索引或脚手架里的显式文件状态追踪来补强。
- 评估覆盖六维：准确性、上下文感知、工件追踪、完整性、连续性、指令遵循。准确性在各方法间差异最大（0.6 分差距），工件追踪普遍偏弱。
- 不透明压缩压缩率最高（99%+）但不可解释，无法验证保留了什么——慎用于需要审计的场景。
互见
- context-degradation：压缩是对抗上下文退化的缓解手段。
- context-optimization：压缩只是众多优化技术之一。
- evaluation：探针式评估同样适用于压缩测试。
- memory-systems：压缩与暂存区 / 摘要记忆模式相关。
采编自 sickn33/antigravity-awesome-skills（MIT 许可）。原文外部参考：Factory Research《Evaluating Context Compression for AI Agents》(2025-12)、LLM-as-judge 评估方法（Zheng et al., 2023）、Netflix Engineering《The Infinite Software Crisis》(AI Summit 2025)。