context-compression
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseContext Compression Strategies
上下文压缩策略
When agent sessions generate millions of tokens of conversation history, compression becomes mandatory. The naive approach is aggressive compression to minimize tokens per request. The correct optimization target is tokens per task: total tokens consumed to complete a task, including re-fetching costs when compression loses critical information.
当Agent会话生成数百万token的对话历史时,压缩就变得必不可少。简单粗暴的方式是激进压缩以最小化每次请求的token消耗,但正确的优化目标应为按任务计算token消耗:完成一项任务的总token消耗量,包括因压缩丢失关键信息而导致的重新获取成本。
When to Activate
激活时机
Activate this skill when:
- Agent sessions exceed context window limits
- Codebases exceed context windows (5M+ token systems)
- Designing conversation summarization strategies
- Debugging cases where agents "forget" what files they modified
- Building evaluation frameworks for compression quality
- Creating durable handoff summaries that preserve decisions, files, risks, and next actions
Do not activate this skill for adjacent work owned by other skills:
- General token-efficiency tactics such as masking, prefix caching, or partitioning: .
context-optimization - Diagnosing why a long context is failing before choosing a mitigation: .
context-degradation - Writing raw outputs, logs, or plans to files without summarizing them: .
filesystem-context - Designing long-term semantic memory across sessions: .
memory-systems
在以下场景激活本技能:
- Agent会话超出上下文窗口限制
- 代码库超出上下文窗口(5M+ token规模的系统)
- 设计对话摘要策略时
- 调试Agent“遗忘”已修改文件的问题时
- 构建压缩质量评估框架时
- 创建能保留决策、文件、风险及后续行动的持久化交接摘要时
以下相邻工作由其他技能负责,请勿激活本技能:
- 通用token效率策略(如掩码、前缀缓存或分区):
context-optimization - 在选择缓解方案前诊断长上下文失效原因:
context-degradation - 直接将原始输出、日志或计划写入文件而不进行摘要:
filesystem-context - 设计跨会话的长期语义记忆:
memory-systems
Core Concepts
核心概念
Context compression trades token savings against information loss. Select from three production-ready approaches based on session characteristics:
-
Anchored Iterative Summarization: Implement this for long-running sessions where file tracking matters. Maintain structured, persistent summaries with explicit sections for session intent, file modifications, decisions, and next steps. When compression triggers, summarize only the newly-truncated span and merge with the existing summary rather than regenerating from scratch. This prevents drift that accumulates when summaries are regenerated wholesale — each regeneration risks losing details the model considers low-priority but the task requires. Structure forces preservation because dedicated sections act as checklists the summarizer must populate, catching silent information loss.
-
Opaque Compression: Reserve this for short sessions where re-fetching costs are low and maximum token savings are required. It produces compressed representations optimized for reconstruction fidelity, achieving 99%+ compression ratios but sacrificing interpretability entirely. The tradeoff matters: there is no way to verify what was preserved without running probe-based evaluation, so never use this when debugging or artifact tracking is critical.
-
Regenerative Full Summary: Use this when summary readability is critical and sessions have clear phase boundaries. It generates detailed structured summaries on each compression trigger. The weakness is cumulative detail loss across repeated cycles — each full regeneration is a fresh pass that may deprioritize details preserved in earlier summaries.
上下文压缩是在token节省与信息损失之间进行权衡。根据会话特性,从三种可投入生产的方案中选择:
-
锚定迭代摘要法:适用于需要跟踪文件的长时间运行会话。维护结构化的持久化摘要,包含会话意图、文件修改、决策和后续步骤等明确板块。触发压缩时,仅对新截断的内容进行摘要,并与现有摘要合并,而非从头重新生成。这能避免全量重新生成摘要时累积的信息偏差——每次重新生成都可能丢失模型认为低优先级但任务必需的细节。结构化强制保留信息,因为专用板块相当于摘要生成器必须填充的检查清单,能发现隐性信息丢失。
-
透明压缩法:适用于重新获取成本低、需要最大化token节省的短会话。它生成针对重构保真度优化的压缩表示,压缩率可达99%以上,但完全牺牲了可解释性。这种权衡至关重要:若不进行基于探针的评估,无法验证保留了哪些信息,因此在调试或工件跟踪至关重要的场景中绝不能使用。
-
再生式全摘要法:适用于摘要可读性要求高、会话有明确阶段边界的场景。每次触发压缩时生成详细的结构化摘要。缺点是多次循环后会累积细节丢失——每次全量重新生成都是全新的过程,可能会优先忽略之前摘要中保留的细节。
Detailed Topics
详细主题
Optimize for Tokens-Per-Task, Not Tokens-Per-Request
优化按任务的token消耗,而非按请求的token消耗
Measure total tokens consumed from task start to completion, not tokens per individual request. When compression drops file paths, error messages, or decision rationale, the agent must re-explore, re-read files, and re-derive conclusions — wasting far more tokens than the compression saved. A strategy saving 0.5% more tokens per request but causing 20% more re-fetching costs more overall. Track re-fetching frequency as the primary quality signal: if the agent repeatedly asks to re-read files it already processed, compression is too aggressive.
衡量从任务开始到完成的总token消耗量,而非单个请求的token消耗。当压缩丢失文件路径、错误消息或决策依据时,Agent必须重新探索、重新读取文件并重新推导结论——这浪费的token远多于压缩节省的量。一种策略每次请求多节省0.5%的token,但导致重新获取成本增加20%,总体成本更高。将重新获取频率作为主要质量信号:如果Agent反复请求重新读取已处理过的文件,说明压缩过于激进。
Solve the Artifact Trail Problem First
首先解决工件追踪问题
Artifact trail integrity is often the weakest dimension in compression evaluations (claim-context-compression-factory-benchmark). Address this proactively because general summarization cannot reliably maintain it.
Preserve these categories explicitly in every compression cycle:
- Which files were created (full paths)
- Which files were modified and what changed (include function names, not just file names)
- Which files were read but not changed
- Specific identifiers: function names, variable names, error messages, error codes
Implement a separate artifact index or explicit file-state tracking in agent scaffolding rather than relying on the summarizer to capture these details. Even structured summarization with dedicated file sections struggles with completeness over long sessions.
在压缩评估中,工件追踪的完整性往往是最薄弱的环节(参考claim-context-compression-factory-benchmark)。要主动解决这个问题,因为通用摘要无法可靠地维持工件追踪。
在每个压缩周期中明确保留以下类别信息:
- 创建了哪些文件(完整路径)
- 修改了哪些文件及修改内容(包含函数名,而非仅文件名)
- 读取但未修改的文件
- 特定标识符:函数名、变量名、错误消息、错误代码
在Agent框架中实现单独的工件索引或明确的文件状态跟踪,而非依赖摘要生成器捕获这些细节。即使是带有专用文件板块的结构化摘要,在长时间会话中也难以保证完整性。
Structure Summaries with Mandatory Sections
为摘要设置强制板块
Build structured summaries with explicit sections that prevent silent information loss. Each section acts as a checklist the summarizer must populate, making omissions visible rather than silent.
markdown
undefined构建带有明确板块的结构化摘要,防止隐性信息丢失。每个板块相当于摘要生成器必须填充的检查清单,使遗漏可见而非隐性存在。
markdown
undefinedSession Intent
会话意图
[What the user is trying to accomplish]
[用户试图完成的目标]
Files Modified
修改的文件
- auth.controller.ts: Fixed JWT token generation
- config/redis.ts: Updated connection pooling
- tests/auth.test.ts: Added mock setup for new config
- auth.controller.ts: 修复JWT token生成逻辑
- config/redis.ts: 更新连接池配置
- tests/auth.test.ts: 为新配置添加模拟设置
Decisions Made
已做出的决策
- Using Redis connection pool instead of per-request connections
- Retry logic with exponential backoff for transient failures
- 使用Redis连接池替代每次请求创建连接
- 为瞬时故障添加指数退避重试逻辑
Current State
当前状态
- 14 tests passing, 2 failing
- Remaining: mock setup for session service tests
- 14个测试通过,2个测试失败
- 剩余任务:为会话服务测试设置模拟环境
Next Steps
后续步骤
- Fix remaining test failures
- Run full test suite
- Update documentation
Adapt sections to the agent's domain. A debugging agent needs "Root Cause" and "Error Messages"; a migration agent needs "Source Schema" and "Target Schema." The structure matters more than the specific sections — any explicit schema outperforms freeform summarization.- 修复剩余测试失败问题
- 运行完整测试套件
- 更新文档
根据Agent的领域调整板块。调试Agent需要“根本原因”和“错误消息”板块;迁移Agent需要“源 schema”和“目标 schema”板块。结构比具体板块更重要——任何明确的 schema 都优于自由形式的摘要。Choose Compression Triggers Strategically
策略性选择压缩触发时机
When to trigger compression matters as much as how to compress. Select a trigger strategy based on session predictability:
| Strategy | Trigger Point | Trade-off |
|---|---|---|
| Fixed threshold | 70-80% context utilization | Simple but may compress too early |
| Sliding window | Keep last N turns + summary | Predictable context size |
| Importance-based | Compress low-relevance sections first | Complex but preserves signal |
| Task-boundary | Compress at logical task completions | Clean summaries but unpredictable timing |
Default to sliding window with structured summaries for coding agents — it provides the best balance of predictability and quality. Use task-boundary triggers when sessions have clear phase transitions (e.g., research then implementation then testing).
何时触发压缩与如何压缩同样重要。根据会话的可预测性选择触发策略:
| 策略 | 触发点 | 权衡 |
|---|---|---|
| 固定阈值 | 上下文利用率达70-80% | 简单但可能过早压缩 |
| 滑动窗口 | 保留最近N轮对话 + 摘要 | 上下文大小可预测 |
| 基于重要性 | 优先压缩低相关性内容 | 复杂但能保留关键信号 |
| 任务边界 | 在逻辑任务完成时压缩 | 摘要清晰但时机不可预测 |
对于编码Agent,默认使用滑动窗口+结构化摘要的组合——它在可预测性和质量之间达到最佳平衡。当会话有明确的阶段过渡(如研究→实现→测试)时,使用任务边界触发。
Evaluate Compression with Probes, Not Metrics
用探针而非指标评估压缩效果
Traditional metrics like ROUGE or embedding similarity fail to capture functional compression quality. A summary can score high on lexical overlap while missing the one file path the agent needs to continue.
Use probe-based evaluation: after compression, pose questions that test whether critical information survived. If the agent answers correctly, compression preserved the right information. If not, it guesses or hallucinates.
| Probe Type | What It Tests | Example Question |
|---|---|---|
| Recall | Factual retention | "What was the original error message?" |
| Artifact | File tracking | "Which files have we modified?" |
| Continuation | Task planning | "What should we do next?" |
| Decision | Reasoning chain | "What did we decide about the Redis issue?" |
传统指标如ROUGE或嵌入相似度无法捕捉功能性压缩质量。摘要可能在词汇重叠上得分很高,但丢失了Agent继续工作所需的唯一文件路径。
使用基于探针的评估:压缩后,提出测试关键信息是否保留的问题。如果Agent回答正确,说明压缩保留了正确的信息;否则,它会猜测或幻觉信息。
| 探针类型 | 测试内容 | 示例问题 |
|---|---|---|
| 召回率 | 事实留存 | “原始错误消息是什么?” |
| 工件追踪 | 文件跟踪 | “我们修改了哪些文件?” |
| 任务延续 | 任务规划 | “我们下一步应该做什么?” |
| 决策验证 | 推理链 | “我们针对Redis问题做出了什么决策?” |
Score Compression Across Six Dimensions
从六个维度评分压缩效果
Evaluate compression quality for coding agents across these dimensions. Accuracy and artifact-trail preservation tend to separate methods more clearly than lexical similarity (claim-context-compression-factory-benchmark), so compression needs specialized handling beyond general summarization.
- Accuracy: Are technical details correct — file paths, function names, error codes?
- Context Awareness: Does the response reflect current conversation state?
- Artifact Trail: Does the agent know which files were read or modified?
- Completeness: Does the response address all parts of the question?
- Continuity: Can work continue without re-fetching information?
- Instruction Following: Does the response respect stated constraints?
针对编码Agent,从以下六个维度评估压缩质量。准确性和工件追踪的保留度比词汇相似度更能区分不同方法(参考claim-context-compression-factory-benchmark),因此压缩需要超出通用摘要的专门处理。
- 准确性:技术细节(文件路径、函数名、错误代码)是否正确?
- 上下文感知:响应是否反映当前对话状态?
- 工件追踪:Agent是否知道哪些文件被读取或修改?
- 完整性:响应是否覆盖问题的所有部分?
- 连续性:无需重新获取信息即可继续工作吗?
- 指令遵循:响应是否遵守既定约束?
Practical Guidance
实践指南
Apply the Three-Phase Compression Workflow for Large Codebases
为大型代码库应用三阶段压缩工作流
For codebases or agent systems exceeding context windows, compress through three sequential phases. Each phase narrows context so the next phase operates within budget.
-
Research Phase: Explore architecture diagrams, documentation, and key interfaces. Compress exploration into a structured analysis of components, dependencies, and boundaries. Output: a single research document that replaces raw exploration.
-
Planning Phase: Convert the research document into an implementation specification with function signatures, type definitions, and data flow. A 5M-token codebase compresses to approximately 2,000 words of specification at this stage.
-
Implementation Phase: Execute against the specification. Context stays focused on the spec plus active working files, not raw codebase exploration. This phase rarely needs further compression because the spec is already compact.
对于超出上下文窗口的代码库或Agent系统,通过三个连续阶段进行压缩。每个阶段缩小上下文范围,使下一阶段在预算内运行。
-
研究阶段:探索架构图、文档和关键接口。将探索内容压缩为组件、依赖关系和边界的结构化分析。输出:一份替代原始探索内容的研究文档。
-
规划阶段:将研究文档转换为包含函数签名、类型定义和数据流的实现规范。一个5M-token的代码库在此阶段可压缩为约2000字的规范。
-
实现阶段:根据规范执行任务。上下文专注于规范和当前工作文件,而非原始代码库探索内容。此阶段很少需要进一步压缩,因为规范已经很紧凑。
Use Example Artifacts as Compression Seeds
使用示例工件作为压缩种子
When provided with a manual migration example or reference PR, use it as a template to understand the target pattern rather than exploring the codebase from scratch. The example reveals constraints static analysis cannot surface: which invariants must hold, which services break on changes, and what a clean implementation looks like.
This matters most when the agent cannot distinguish essential complexity (business requirements) from accidental complexity (legacy workarounds). The example artifact encodes that distinction implicitly, saving tokens that would otherwise go to trial-and-error exploration.
当提供手动迁移示例或参考PR时,将其作为模板理解目标模式,而非从头探索代码库。示例揭示了静态分析无法发现的约束:哪些不变量必须保持,哪些服务会因变更而中断,以及简洁的实现是什么样的。
当Agent无法区分本质复杂度(业务需求)和偶然复杂度(遗留解决方案)时,这一点最为重要。示例工件隐含地编码了这种区分,节省了原本用于反复试验探索的token。
Implement Anchored Iterative Summarization Step by Step
逐步实现锚定迭代摘要法
- Define explicit summary sections matching the agent's domain (debugging, migration, feature development)
- On first compression trigger, summarize the truncated history into those sections
- On subsequent compressions, summarize only newly truncated content — do not re-summarize the existing summary
- Merge new information into existing sections rather than regenerating them, deduplicating by file path and decision identity
- Tag which information came from which compression cycle — this enables debugging when summaries drift
- 定义与Agent领域(调试、迁移、功能开发)匹配的明确摘要板块
- 首次触发压缩时,将截断的历史内容总结到这些板块中
- 后续压缩时,仅总结新截断的内容——不要重新总结现有摘要
- 将新信息合并到现有板块中,而非重新生成,按文件路径和决策标识去重
- 标记信息来自哪个压缩周期——这有助于在摘要出现偏差时进行调试
Select the Right Approach for the Session Profile
根据会话特征选择合适的方法
Use anchored iterative summarization when:
- Sessions are long-running (100+ messages)
- File tracking matters (coding, debugging)
- Verification of preserved information is needed
Use opaque compression when:
- Maximum token savings are required
- Sessions are relatively short
- Re-fetching costs are low (e.g., no file system access needed)
Use regenerative summaries when:
- Summary interpretability is critical for human review
- Sessions have clear phase boundaries
- Full context review is acceptable on each compression trigger
当以下情况时使用锚定迭代摘要法:
- 会话长时间运行(100+条消息)
- 文件跟踪至关重要(编码、调试)
- 需要验证保留的信息
当以下情况时使用透明压缩法:
- 需要最大化token节省
- 会话相对较短
- 重新获取成本低(如无需访问文件系统)
当以下情况时使用再生式摘要法:
- 摘要可解释性对人工审核至关重要
- 会话有明确的阶段边界
- 每次触发压缩时可接受全量上下文审查
Calibrate Compression Ratios by Method
按方法校准压缩率
| Method | Compression Ratio | Quality Score | Trade-off |
|---|---|---|---|
| Anchored Iterative | 98.6% | 3.70 | Best quality, slightly less compression |
| Regenerative | 98.7% | 3.44 | Good quality, moderate compression |
| Opaque | 99.3% | 3.35 | Best compression, quality loss |
Use these as source-specific benchmark figures, not universal constants (claim-context-compression-factory-benchmark). For any task where re-fetching costs exist, this tradeoff generally favors structured approaches.
| 方法 | 压缩率 | 质量得分 | 权衡 |
|---|---|---|---|
| 锚定迭代法 | 98.6% | 3.70 | 质量最佳,压缩率略低 |
| 再生式 | 98.7% | 3.44 | 质量良好,压缩率适中 |
| 透明压缩 | 99.3% | 3.35 | 压缩率最佳,存在质量损失 |
将这些作为特定场景的基准数据,而非通用常量(参考claim-context-compression-factory-benchmark)。对于存在重新获取成本的任务,这种权衡通常更倾向于结构化方法。
Examples
示例
Example 1: Debugging Session Compression
Original context (89,000 tokens, 178 messages):
- 401 error on /api/auth/login endpoint
- Traced through auth controller, middleware, session store
- Found stale Redis connection
- Fixed connection pooling, added retry logic
- 14 tests passing, 2 failing
Structured summary after compression:
markdown
undefined示例1:调试会话压缩
原始上下文(89,000 token,178条消息):
- /api/auth/login端点出现401错误
- 追踪了认证控制器、中间件、会话存储
- 发现Redis连接过期
- 修复了连接池,添加了重试逻辑
- 14个测试通过,2个测试失败
压缩后的结构化摘要:
markdown
undefinedSession Intent
会话意图
Debug 401 Unauthorized error on /api/auth/login despite valid credentials.
调试/api/auth/login端点在凭证有效的情况下仍返回401 Unauthorized错误的问题。
Root Cause
根本原因
Stale Redis connection in session store. JWT generated correctly but session could not be persisted.
会话存储中的Redis连接过期。JWT生成正确,但会话无法持久化。
Files Modified
修改的文件
- auth.controller.ts: No changes (read only)
- middleware/cors.ts: No changes (examined)
- config/redis.ts: Fixed connection pooling configuration
- services/session.service.ts: Added retry logic for transient failures
- tests/auth.test.ts: Updated mock setup
- auth.controller.ts:无修改(仅读取)
- middleware/cors.ts:无修改(已检查)
- config/redis.ts:修复了连接池配置
- services/session.service.ts:为瞬时故障添加了重试逻辑
- tests/auth.test.ts:更新了模拟设置
Test Status
测试状态
14 passing, 2 failing (mock setup issues)
14个通过,2个失败(模拟设置问题)
Next Steps
后续步骤
- Fix remaining test failures (mock session service)
- Run full test suite
- Deploy to staging
**Example 2: Probe Response Quality**
After compression, asking "What was the original error?":
Good response (structured summarization):
> "The original error was a 401 Unauthorized response from the /api/auth/login endpoint. Users received this error with valid credentials. Root cause was stale Redis connection in session store."
Poor response (aggressive compression):
> "We were debugging an authentication issue. The login was failing. We fixed some configuration problems."
The structured response preserves endpoint, error code, and root cause. The aggressive response loses all technical detail.- 修复剩余测试失败问题(模拟会话服务)
- 运行完整测试套件
- 部署到预发布环境
**示例2:探针响应质量**
压缩后,询问“原始错误是什么?”:
良好响应(结构化摘要):
> “原始错误是/api/auth/login端点返回的401 Unauthorized响应。用户使用有效凭证时仍收到此错误。根本原因是会话存储中的Redis连接过期。”
糟糕响应(激进压缩):
> “我们正在调试认证问题。登录失败了。我们修复了一些配置问题。”
结构化响应保留了端点、错误代码和根本原因。激进响应丢失了所有技术细节。Guidelines
准则
- Optimize for tokens-per-task, not tokens-per-request
- Use structured summaries with explicit sections for file tracking
- Trigger compression at 70-80% context utilization
- Implement incremental merging rather than full regeneration
- Test compression quality with probe-based evaluation
- Track artifact trail separately if file tracking is critical
- Accept slightly lower compression ratios for better quality retention
- Monitor re-fetching frequency as a compression quality signal
- 优化按任务的token消耗,而非按请求的token消耗
- 使用带有明确板块的结构化摘要进行文件跟踪
- 在上下文利用率达70-80%时触发压缩
- 实现增量合并而非全量重新生成
- 使用基于探针的评估测试压缩质量
- 如果文件跟踪至关重要,单独跟踪工件轨迹
- 为更好的质量保留接受略低的压缩率
- 将重新获取频率作为压缩质量信号进行监控
Gotchas
注意事项
-
Never compress tool definitions or schemas: Compressing function call schemas, API specs, or tool definitions destroys agent functionality entirely. The agent cannot invoke tools whose parameter names or types have been summarized away. Treat tool definitions as immutable anchors that bypass compression.
-
Compressed summaries hallucinate facts: When an LLM summarizes conversation history, it may introduce plausible-sounding details that never appeared in the original. Always validate compressed output against source material before discarding originals — especially for file paths, error codes, and numeric values that the summarizer may "round" or fabricate.
-
Compression breaks artifact references: File paths, commit SHAs, variable names, and code snippets get paraphrased or dropped during compression. A summary saying "updated the config file" when the agent needscauses re-exploration. Preserve identifiers verbatim in dedicated sections rather than embedding them in prose.
config/redis.ts -
Early turns contain irreplaceable constraints: The first few turns of a session often contain task setup, user constraints, and architectural decisions that cannot be re-derived. Protect early turns from compression or extract their constraints into a persistent preamble that survives all compression cycles.
-
Aggressive ratios compound across cycles: A 95% compression ratio seems safe once, but applying it repeatedly compounds losses. After three cycles at 95%, only 0.0125% of original tokens remain. Calibrate ratios assuming multiple compression cycles, not a single pass.
-
Code and prose need different compression: Prose compresses well because natural language is redundant. Code does not — removing a single token from a function signature or import path can make it useless. Apply domain-specific compression strategies: summarize prose sections aggressively while preserving code blocks and structured data verbatim.
-
Probe-based evaluation gives false confidence: Probes can pass despite critical information being lost, because the probes test only what they ask about. A probe set that checks file names but not function signatures will miss signature loss. Design probes to cover all six evaluation dimensions, and rotate probe sets across evaluation runs to avoid blind spots.
-
绝不要压缩工具定义或schema:压缩函数调用schema、API规范或工具定义会完全破坏Agent的功能。Agent无法调用参数名或类型被摘要掉的工具。将工具定义视为绕过压缩的不可变锚点。
-
压缩后的摘要会产生幻觉信息:当大语言模型总结对话历史时,可能会引入看似合理但从未出现在原始内容中的细节。在丢弃原始内容前,始终根据源材料验证压缩输出——尤其是文件路径、错误代码和数值,摘要生成器可能会“四舍五入”或编造这些信息。
-
压缩会破坏工件引用:文件路径、提交SHA、变量名和代码片段在压缩过程中会被改写或丢弃。摘要中说“更新了配置文件”,但Agent需要的是,这会导致重新探索。在专用板块中逐字保留标识符,而非将其嵌入 prose 中。
config/redis.ts -
早期对话包含不可替代的约束:会话的前几轮通常包含任务设置、用户约束和架构决策,这些无法重新推导。保护早期对话不被压缩,或将其约束提取到能在所有压缩周期中保留的持久化前言中。
-
激进压缩率会在循环中累积损失:95%的压缩率单次使用看似安全,但反复应用会累积损失。经过三次95%的压缩循环后,仅剩下原始token的0.0125%。校准压缩率时要考虑多次压缩循环,而非单次处理。
-
代码和 prose 需要不同的压缩策略:prose 压缩效果好,因为自然语言存在冗余。代码则不然——从函数签名或导入路径中删除单个token就可能使其无用。应用领域特定的压缩策略:激进地总结prose部分,同时逐字保留代码块和结构化数据。
-
基于探针的评估可能给出错误信心:即使关键信息丢失,探针也可能通过,因为探针仅测试其询问的内容。检查文件名但不检查函数签名的探针集会遗漏签名丢失的问题。设计覆盖所有六个评估维度的探针集,并在评估运行中轮换探针集以避免盲点。
Integration
集成
This skill connects to several others in the collection:
- context-degradation - Compression is a mitigation strategy for degradation
- context-optimization - Compression is one optimization technique among many
- evaluation - Probe-based evaluation applies to compression testing
- memory-systems - Compression relates to scratchpad and summary memory patterns
本技能与集合中的其他几个技能相关联:
- context-degradation - 压缩是解决上下文退化的缓解策略
- context-optimization - 压缩是众多优化技术之一
- evaluation - 基于探针的评估适用于压缩测试
- memory-systems - 压缩与临时内存和摘要内存模式相关
References
参考资料
Internal reference:
- Evaluation Framework Reference - Read when: building or calibrating a probe-based evaluation pipeline, or when needing scoring rubrics and LLM judge configuration for compression quality assessment
Related skills in this collection:
- context-degradation - Read when: diagnosing why agent performance drops over long sessions, before applying compression as a mitigation
- context-optimization - Read when: compression alone is insufficient and broader optimization strategies (pruning, caching, routing) are needed
- evaluation - Read when: designing evaluation frameworks beyond compression-specific probes, including general LLM-as-judge methodology
External resources:
- Factory Research: Evaluating Context Compression for AI Agents (December 2025) - Read when: needing benchmark data on compression method comparisons or the 36,000-message evaluation dataset
- Research on LLM-as-judge evaluation methodology (Zheng et al., 2023) - Read when: implementing or validating LLM judge scoring to understand bias patterns and calibration
- Netflix Engineering: "The Infinite Software Crisis" - Three-phase workflow and context compression at scale (AI Summit 2025) - Read when: implementing the three-phase compression workflow for large codebases or understanding production-scale context management
内部参考:
- 评估框架参考 - 适用场景:构建或校准基于探针的评估管道,或需要压缩质量评估的评分准则和LLM评判器配置时
集合中的相关技能:
- context-degradation - 适用场景:诊断Agent在长时间会话中性能下降的原因,在应用压缩作为缓解方案之前
- context-optimization - 适用场景:仅靠压缩不足以解决问题,需要更广泛的优化策略(修剪、缓存、路由)时
- evaluation - 适用场景:设计超出压缩专用探针的评估框架,包括通用LLM-as-judge方法时
外部资源:
- Factory Research: Evaluating Context Compression for AI Agents (2025年12月) - 适用场景:需要压缩方法比较的基准数据或36,000条消息的评估数据集时
- 大语言模型评判器评估方法研究(Zheng等人,2023)- 适用场景:实现或验证LLM评判器评分,以理解偏差模式和校准方法时
- Netflix Engineering: "The Infinite Software Crisis" - 大规模三阶段工作流和上下文压缩(2025年AI峰会)- 适用场景:为大型代码库实现三阶段压缩工作流或理解生产级上下文管理时
Skill Metadata
技能元数据
Created: 2025-12-22
Last Updated: 2026-05-15
Author: Agent Skills for Context Engineering Contributors
Version: 1.3.0
创建时间: 2025-12-22
最后更新时间: 2026-05-15
作者: Agent Skills for Context Engineering Contributors
版本: 1.3.0