context-optimization

context-optimization 技能概览

context-optimization 是一项实用技能，用来减少 token 浪费、保留工作记忆，并让随着上下文增长而变长的 AI 工作流依然可用。在你需要管理上下文限制、压缩工具输出冗余、为缓存稳定提示词，或设计能在长任务中保持准确性的系统时，使用 context-optimization 技能。它尤其适合 Context Engineering 场景，因为目标不只是“塞进更多文本”，而是让真正重要的文本持续处于激活状态。

这项技能适用于什么场景

这项技能面向正在判断如何处理长对话、大文档或多步骤 agent 运行的读者。它聚焦真实部署中最关键的四个动作：利于缓存的提示词结构、观察输出遮罩、压缩，以及分区拆分。相比通用的“prompt 优化”指南，它更偏向决策导向。

context-optimization 的突出之处

这份 context-optimization 指南最强的信号在于：它会按影响和风险来排序技术方案。这能帮你避免过度工程化——先稳定提示词，再压缩噪声观察输出，再做压缩，最后在需要时再拆分。附带的参考材料和工具脚本也说明，它面向的是实际落地，而不只是理论讨论。

最适合的用户与使用场景

context-optimization 技能适合：

• 构建长时间运行 agent 的开发者
• 需要为大量工具轨迹或冗长检索结果付费的团队
• 在模型上下文上限附近工作的工程师
• 想在不更换模型的前提下降低延迟或 token 成本的人

如果你的任务只是一次性的短 prompt，通常不需要这项技能。

如何使用 context-optimization 技能

正确安装 context-optimization

使用仓库设置中的 context-optimization 安装命令：
npx skills add muratcankoylan/Agent-Skills-for-Context-Engineering --skill context-optimization

安装后，确认技能路径是 skills/context-optimization，并在把它应用到项目之前先阅读 frontmatter 说明。只有当你准备把这项技术真正放进工作流里时，安装才最有价值，而不是只浏览概念。

先从正确的源文件开始

使用 context-optimization 时，请按以下顺序阅读文件：

1. SKILL.md：激活规则和策略顺序
2. references/optimization_techniques.md：压缩与预算细节
3. scripts/compaction.py：实现模式和辅助函数

如果你需要把这项技能迁移到另一个仓库，在把思路复制到自己的代码库之前，先扫描完整的 skills/context-optimization 目录，看看是否还有其他支持文件。

把模糊目标改写成可用的 prompt

像“优化上下文”这样的弱请求留白太多。更强的输入会明确瓶颈和目标结果：

• “在不丢失决策状态的前提下，降低一个重工具 agent 的 token 使用量”
• “设计一种 prompt 结构，提升重复调用中的 KV-cache 复用”
• “展示如何在保留可检索引用的同时遮罩冗长的 observation 输出”
• “为一个上下文上限为 32k 的长时间支持 agent 制定压缩策略”

这很重要，因为 context-optimization 不是单一技巧；正确动作取决于问题到底是成本、延迟、历史增长，还是检索噪声。

在正确的工作流里使用这项技能

一个好的 context-optimization 使用方式是：

• 找出最吃 token 的部分
• 标明哪些内容必须逐字保留，哪些可以摘要
• 在多次调用中保持稳定的 prompt 区块不变
• 用紧凑引用替代已完成的工具输出
• 在窗口已经接近饱和之前就先做压缩

对于 Context Engineering，把它当作一种运行纪律，而不是一次性的清理动作。

context-optimization 技能常见问题

context-optimization 只适用于大模型吗？

不是。只要上下文稀缺或昂贵，context-optimization 就有价值，包括较小的窗口和包含大量工具调用的系统。大模型同样受益，因为减少 token 也能降低成本和延迟。

这和普通 prompt 有什么不同？

普通 prompt 是让模型去完成一项任务。context-optimization 则是要求你把任务结构化，让模型能更久地保留正确状态、少浪费 token。这个差异在 agent 工作流中尤其重要，不只是单次回复。

初学者在使用前需要知道什么？

初学者要知道，并不是每一行文本都应该保留。核心判断是：什么必须精确保留，什么可以摘要，什么应该用引用替代。如果你说不清这三类内容，输出通常会过于笼统。

什么时候不该用这项技能？

如果任务很短、历史不重要，或者输出不需要反复跟进，就不要用 context-optimization。在这些情况下，优化上下文的额外成本可能没有必要。

如何改进 context-optimization 技能

给这项技能提供正确的约束

最好的 context-optimization 结果来自包含以下信息的输入：

• 模型或上下文窗口大小
• 工具类型以及大致输出量
• 延迟或成本目标
• 哪些状态必须跨轮次保留
• 系统是交互式、批处理还是 agentic

没有这些细节，技能就只能猜最重要的权衡是什么。

警惕常见失败模式

主要失败模式包括：过度摘要、丢失决策历史，以及优化错层。如果问题出在工具输出，先做 observation 遮罩，再改写 prompt。如果问题出在重复前缀，重点放在通过缓存复用来稳定 prompt。如果对话本身已经太长，就应该更早触发压缩阈值。

在第一次结果之后继续迭代

想把 context-optimization 指南做得更好，可以先要一个初稿，然后拿真实的对话记录或工作负载去测试。比较优化前后的 token 数、重复内容和决策保留情况。如果第一次尝试省了 token 却破坏了连续性，就应该收紧保留规则，而不是继续加大压缩力度。

用具体示例改进输出

一个更强的后续请求可以这样写：
“这里有一段 12 轮的 agent 日志和一个 4k token 的工具输出。请把它优化到适合跨轮次复用，保留用户偏好和未完成任务，并说明哪些内容应该摘要，哪些应该遮罩。”

这类输入能帮助 context-optimization 技能产出真正值得安装、可用于 Context Engineering 的结果，而不只是理论上正确。