context-optimization

上下文优化技术

上下文优化通过策略性压缩、屏蔽、缓存和分区，扩展有限上下文窗口的有效容量。有效的优化无需使用更大的模型或更长的窗口，就能提高可用容量——但前提是严格进行测量。以下技术按影响和风险排序。

何时启用

在以下情况下启用此技能：

• 上下文预算或 Token 成本限制了任务复杂度
• 屏蔽观察结果可用可检索的引用替代冗长的工具输出
• 需要提高前缀缓存或 KV 缓存的命中率
• 检索范围限定可减少加载的不相关上下文
• 上下文分区可扩展多个 Agent 的有效容量
• 需要为屏蔽、压缩或分区设置预算触发条件

对于其他技能负责的相关工作，请勿启用此技能：

• 解释注意力机制或上下文窗口为何如此运行：context-fundamentals。
• 诊断正在发生的中间信息丢失、投毒、干扰、混淆或冲突：context-degradation。
• 为长对话设计结构化交接摘要：context-compression。
• 将大型输出、计划或日志保存为文件：filesystem-context。
• 模型主动重写自身上下文及其重新预填充成本：self-managed-context。

核心概念

按以下优先级应用四种主要策略：

1. KV 缓存优化 — 重新排序并稳定提示词结构，让推理引擎重用缓存的键值张量。如果运行时支持前缀缓存，这是成本最低的优化：质量风险低，可立即节省成本和延迟。存在稳定前缀时，应优先应用。

2. 观察结果屏蔽 — 工具输出完成其用途后，将冗长的输出替换为简洁引用。工具输出可能占据 Agent 执行轨迹的大部分内容（claim-context-optimization-tool-output-dominance），因此屏蔽通常能最大幅度地提升容量。若下游需要，仍可检索原始内容。

3. 压缩 — 当利用率超过 70% 时，对累积的上下文进行摘要，然后用摘要重新初始化。这会提炼窗口内容，同时保留任务关键状态。压缩是有损的——应先通过屏蔽移除低价值的大量内容，再进行压缩。

4. 上下文分区 — 当单个窗口无法容纳完整问题时，将工作拆分给上下文相互隔离的子 Agent。每个子 Agent 都在干净的上下文中专注处理自己的子任务。仅当预估上下文超过窗口上限的 60% 时才使用此方法，因为协调开销不可忽视。

基本原则：上下文质量比数量更重要。每种优化都应在降低噪声的同时保留信号。优化前先测量，再测量优化效果。

详细主题

压缩策略

当上下文利用率超过 70% 时触发压缩：总结当前上下文，然后使用摘要重新初始化。这能以高保真方式提炼窗口内容，使后续工作得以继续，同时将性能下降降至最低。优先压缩工具输出（它们消耗 80% 以上的 token），然后是较早的对话轮次，最后是检索到的文档。绝不要压缩系统提示词——它是模型行为的锚点，移除后会导致不可预测的性能下降。

按消息类型保留不同元素：

• 工具输出：提取关键发现、指标、错误代码和结论。删去冗长的原始输出、堆栈跟踪（除非仍在调试）和模板化标题。
• 对话轮次：保留决策、承诺、用户偏好和上下文变化。删去填充内容、客套话，以及已经得出并记录结论的探索性往返对话。
• 检索到的文档：保留与当前任务相关的主张、事实和数据点。删去仅用于一次性推理的支持证据和详述内容。

目标是将 token 减少 50–70%，同时将质量下降控制在 5% 以内。如果压缩幅度超过 70%，请审核摘要是否丢失了关键信息——过度压缩是最常见的失败模式。

观察内容屏蔽

根据新近程度和当前相关性有选择地屏蔽观察内容，而不是一概而论。遵循以下规则：

• 绝不屏蔽：对当前任务至关重要的观察内容、最近一轮中的观察内容、正在进行的推理链中用到的观察内容，以及调试期间的错误输出。
• 3 轮及以上后屏蔽：关键要点已提取到对话流程中的冗长输出。将其替换为简短引用：[Obs:{ref_id} 已省略。要点：{summary}。可检索完整内容。]
• 始终立即屏蔽：重复/重复的输出、模板化标题和页脚，以及此前已总结过的输出。

屏蔽后应将观察内容减少 60–80%，同时将质量影响控制在 2% 以内。关键在于保持可检索性——在外部存储完整内容，并在上下文中保留引用 ID，以便 Agent 在需要时请求原始内容。

KV 缓存优化

通过调整提示词结构，让稳定内容位于前缀，动态内容出现在末尾，从而最大限度地提高前缀缓存命中率。KV 缓存会存储推理过程中计算出的 Key 和 Value 张量；当连续请求共享相同前缀时，会重复使用缓存张量，从而节省成本和延迟。

在每个提示词中按以下顺序排列：

1. 系统提示词（最稳定——在会话中绝不改变）
2. 工具定义（在各请求间保持稳定）
3. 经常重复使用的模板和少样本示例
4. 对话历史（不断增长，但与之前轮次共享前缀）
5. 当前查询和动态内容（最不稳定——始终放在最后）

为缓存稳定性设计提示词：从系统提示词中移除时间戳、会话计数器和请求 ID。将动态元数据移到单独的用户消息或工具结果中，避免破坏前缀。即使前缀中只有一个空格发生变化，也会使该变化之后的整个缓存块失效。相同规则也适用于对较早历史内容进行的任何压缩或屏蔽编辑：其成本取决于编辑内容之后的文本，因此应批量进行此类编辑，并尽量将其安排在上下文末尾附近。

对于稳定的工作负载，目标是达到 70% 以上的缓存命中率。规模化后，这可使成本降低 50% 以上，并使缓存 token 的延迟降低 40% 以上。

上下文分区

当单个上下文无法容纳完整问题，且可能触发激进压缩时，应将工作分配给多个子 Agent。每个子 Agent 在干净、聚焦的上下文中处理子任务，然后向协调 Agent 返回结构化结果。

预计任务上下文超过窗口上限的 60% 时，就应规划分区。将任务拆解为相互独立的子任务，分配给子 Agent，并汇总结果。合并前确认所有分区均已完成，合并兼容的结果；如果汇总后的输出仍超出预算，则进行摘要。

这种方法实现了职责分离——详细的搜索上下文保留在子 Agent 中，协调 Agent 则专注于综合结果。不过，协调会产生实际的 token 成本：协调 Agent 的提示词、结果汇总和错误处理都会消耗 token。只有当节省的 token 多于这些开销时，才进行分区。

预算管理

在会话开始前，为各个上下文类别分配明确的 token 预算：系统提示词、工具定义、检索到的文档、消息历史、工具输出，以及预留缓冲区（总量的 5-10%）。持续监控预算使用情况，当任一类别超出分配额度，或总使用率超过 70% 时，触发优化。

应采用基于触发条件的优化，而非定期优化。监控以下信号：

• token 使用率超过 80%——触发压缩
• 注意力下降迹象（重复、遗漏指令）——触发屏蔽和压缩
• 质量评分低于基线——优化前审查上下文组成

实践指南

优化决策框架

根据上下文中占主导地位的内容选择优化技术：

上下文组成	首选操作	次选操作
工具输出占主导（>50%）	屏蔽观察结果	压缩其余轮次
检索到的文档占主导	摘要	如果文档相互独立，则进行分区
消息历史占主导	选择性保留内容并进行压缩	为新子任务进行分区
多个组成部分影响相当	先优化 KV-cache，再进行层屏蔽和压缩
接近上限且正在主动调试	仅屏蔽已解决的工具输出——保留错误详情

性能目标

跟踪以下指标，以验证优化效果：

• 压缩：减少 50-70% 的 token；质量下降 <5%；压缩步骤本身带来的延迟开销 <10%
• 屏蔽：减少 60-80% 的屏蔽观察结果；质量影响 <2%；延迟开销接近于零
• 缓存优化：稳定工作负载的命中率达到 70% 以上；成本降低 50% 以上；延迟降低 40% 以上
• 分区：扣除协调开销后仍能节省 token；通常需要 3 个以上子任务才能达到收支平衡

根据测量结果迭代调整策略。如果某种优化技术未能显著改善目标指标，就将其移除——优化机制本身也会消耗 token 并增加延迟。

示例

示例 1：压缩触发

if context_tokens / context_limit > 0.8:
    context = compact_context(context)

示例 2：观察结果屏蔽

if len(observation) > max_length:
    ref_id = store_observation(observation)
    return f"[Obs:{ref_id} elided. Key: {extract_key(observation)}]"

示例 3：缓存友好的排序

# Stable content first
context = [system_prompt, tool_definitions]  # Cacheable
context += [reused_templates]  # Reusable
context += [unique_content]  # Unique

示例 4：预算触发的优化策略

budgets:
  tool_outputs: 35%
  message_history: 30%
  retrieved_documents: 20%
  reserved_buffer: 15%
triggers:
  tool_outputs_over_budget: mask resolved observations
  total_context_over_70_percent: compact message history
  repeated_irrelevant_retrievals: tighten retrieval scope

指南

1. 优化前先测量——了解当前状态
2. 先屏蔽，再压缩——先移除价值较低的大块内容，再总结剩余内容
3. 使用一致的提示词，确保缓存稳定
4. 在上下文出现问题之前进行分区
5. 随时间监控优化效果
6. 平衡 token 节省与质量保留
7. 在生产规模下测试优化
8. 针对边缘情况实现平稳降级

注意事项

1. 空白字符会破坏 KV-cache：即使提示词前缀中的空白字符或换行符只有一处变化，也会使该位置之后的整个 KV-cache 块失效。将系统提示词固定为不可变字符串——不要在其中插入时间戳、版本号或会话 ID。部署之间应逐字节比较提示词模板。

2. 系统提示词中的时间戳会降低缓存命中率：在系统提示词中加入 Current date: {today} 或类似的动态内容，会导致每到新的一天（如果使用一天中的具体时间，则会导致每次请求）都完全无法命中缓存。将动态元数据移到用户消息中，或作为单独的工具结果附加在稳定前缀之后。

3. 高负载下压缩会丢失关键状态：执行压缩的模型自身也面临上下文压力（利用率 >85%）时，其摘要质量会下降——它会遗漏任务目标、丢弃用户约束，并抹平细致的状态信息。应在 70-80% 时触发压缩，而不是等到 90% 以上。如果必须延迟压缩，请使用单独的模型调用，并提供只包含待总结材料的干净上下文。

4. 屏蔽错误输出会妨碍调试循环：过度屏蔽会隐藏错误消息、堆栈跟踪和失败详情，而 Agent 需要这些信息在后续轮次中诊断并修复问题。在主动调试期间（最近 3 轮内出现错误），应暂停屏蔽所有与错误相关的观察结果，直到问题解决。

5. 分区开销可能超过节省的成本：每个子 Agent 都需要自己的系统提示词、工具定义和协调消息。对于少于 3 个独立子任务的工作，协调开销往往超过节省的上下文。决定分区前，先估算总 token 数（协调器 + 所有子 Agent）。

6. 部署变更后缓存未命中成本会激增：在不同部署之间重新排列工具、改写系统提示词或更改少样本示例，会使整个前缀缓存失效，导致缓存重新预热期间的成本暂时上升至原来的 2-5 倍。应逐步推出提示词变更，并在部署期间监控缓存命中率。

7. 压缩会让过时摘要显得可信：上下文压缩后，摘要看起来可能很权威，但内容或许反映的是过时状态。如果任务在压缩后发生了变化（新增用户要求、假设得到更正），摘要可能会悄无声息地沿用过时信息。压缩后，继续操作前应根据当前任务目标重新验证摘要。

集成

此技能负责 token 效率策略和预算政策。相邻技能负责诊断、存储和架构：

• context-fundamentals：解释上下文质量和注意力位置为何重要的思维模型。
• context-degradation：输出质量已经下降时的诊断方法。
• context-compression：有损摘要和交接策略。
• filesystem-context：将完整输出和日志卸载到文件中。
• multi-agent-patterns：在相互隔离的 Agent 上下文之间分配工作。
• latent-briefing：在兼容的运行时中，跨编排器与工作器边界选择性保留 KV。
• self-managed-context：由模型而非运行框架决定何时以及编辑哪些实时上下文。
• evaluation：衡量优化是否改善了质量、成本或延迟。
• memory-systems：按需及时提供上下文的持久化检索层。

参考资料

内部参考：

• 优化技术参考 - 阅读时机：实现特定优化技术，并且需要技能正文未提供的详细代码模式、阈值表或集成示例时

此合集中的相关技能：

• context-fundamentals - 阅读时机：不熟悉上下文窗口机制、令牌计数或注意力分布基础知识时
• context-degradation - 阅读时机：诊断 Agent 性能下降的原因，并且需要在选择优化方案前确定出现了哪种退化模式时
• evaluation - 阅读时机：设置指标和基准，以衡量优化技术是否确实改善了结果时

外部资源：

• 关于上下文窗口限制的研究 - 阅读时机：评估特定模型的上下文行为（例如，中间信息丢失效应、注意力衰减曲线）时
• KV 缓存优化技术 - 阅读时机：在推理基础设施层面实现前缀缓存（vLLM、TGI 或云服务提供商 API）时
• 生产工程指南 - 阅读时机：在生产流水线中部署上下文优化，并且需要可运维性模式（监控、告警、回滚）时

---

技能元数据

创建时间：2025-12-20 上次更新：2026-05-15 作者：Agent Skills for Context Engineering Contributors 版本：2.1.0