context-compression

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Context 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数，包括因压缩丢失关键信息而重新获取（re-fetching）的成本。

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节省与信息丢失之间进行权衡。根据会话特征，从三种生产级方法中选择：

锚定迭代摘要（Anchored Iterative Summarization）：对于需要文件跟踪的长时间运行会话，实施此方法。维护结构化的持久摘要，明确包含会话意图、文件修改、决策和下一步骤等部分。当压缩触发时，只总结新截断的跨度，并与现有摘要合并，而不是从头重新生成。这可以防止在整体重新生成摘要时累积的漂移——每次重新生成都有丢失模型认为低优先级但任务所需细节的风险。结构强制保留信息，因为专用部分充当摘要器必须填写的检查清单，从而捕获无声的信息丢失。
不透明压缩（Opaque Compression）：将其保留给会话较短、重新获取成本低且需要最大Token节省的场景。它生成针对重建保真度优化的压缩表示，可实现99%以上的压缩比，但完全牺牲可解释性。这种权衡很重要：没有基于探针的评估就无法验证保留了什么，因此在调试或工件跟踪至关重要时绝不要使用此方法。
再生式完整摘要（Regenerative Full Summary）：当摘要可读性至关重要且会话具有清晰的阶段边界时使用此方法。它在每次压缩触发时生成详细的结构化摘要。弱点是跨重复循环的累积细节丢失——每次完整重新生成都是一次新的遍历，可能会降低早期摘要中保留的细节的优先级。

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

undefined

Session 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需要“源模式”和“目标模式”。结构比具体章节更重要——任何显式模式都优于自由格式摘要。

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错误
通过auth控制器、中间件、会话存储进行追踪
发现过期的Redis连接
修复了连接池，添加了重试逻辑
14个测试通过，2个失败

压缩后的结构化摘要：

markdown

undefined

Session 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.

修复剩余的测试失败（模拟会话服务）
运行完整测试套件
部署到staging


**示例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 needs
```
config/redis.ts
```
causes re-exploration. Preserve identifiers verbatim in dedicated sections rather than embedding them in prose.
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.

绝不要压缩工具定义或模式：压缩函数调用模式、API规范或工具定义会完全破坏Agent功能。Agent无法调用参数名称或类型已被摘要掉的工具。将工具定义视为绕过压缩的不可变锚点。
压缩摘要会幻觉出事实：当LLM总结对话历史时，可能会引入从未在原始内容中出现的看似合理的细节。在丢弃原始内容之前，始终对照源材料验证压缩输出——尤其是摘要器可能“四舍五入”或捏造的文件路径、错误代码和数值。
压缩破坏工件引用：文件路径、提交SHA、变量名和代码片段在压缩期间被转述或丢弃。当Agent需要
```
config/redis.ts
```
时，摘要说“更新了配置文件”会导致重新探索。在专用章节中逐字保留标识符，而不是嵌入到散文中。
早期轮次包含不可替代的约束：会话的前几轮通常包含无法重新推导的任务设置、用户约束和架构决策。保护早期轮次免受压缩，或将其约束提取到能承受所有压缩周期的持久前言中。
激进压缩比跨周期复合：95%的压缩比一次看起来安全，但重复应用会复合损失。在95%的情况下经过三个周期，原始Token仅剩0.0125%。校准压缩比时假设多个压缩周期，而不是单次通过。
代码和散文需要不同的压缩：散文压缩效果好，因为自然语言是冗余的。代码则不然——从函数签名或导入路径中移除一个Token就可能使其无用。应用特定领域的压缩策略：激进地总结散文部分，同时逐字保留代码块和结构化数据。
基于探针的评估会产生虚假信心：探针即使丢失关键信息也可能通过，因为探针只测试它们询问的内容。检查文件名但不检查函数签名的探针集将错过签名丢失。设计覆盖所有六个评估维度的探针，并在评估运行之间轮换探针集以避免盲点。

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条消息的评估数据集时
Research on LLM-as-judge evaluation methodology (Zheng et al., 2023) - 何时阅读：实施或验证LLM评判评分以理解偏差模式和校准时
Netflix Engineering: "The Infinite Software Crisis" - 三阶段工作流和大规模上下文压缩（AI Summit 2025） - 何时阅读：为大型代码库实施三阶段压缩工作流或理解生产级上下文管理时

Skill Metadata

Skill元数据

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