部分内容可能来自网络或者由AI生成。
如有雷同，纯属巧合，仅供学习参考之用。
Agent 上下文管理：从窗口约束到工程化治理
决定每一轮交互时，模型的上下文窗口里应该出现哪些信息、以什么结构出现、何时移除。它是介于"提示词工程（怎么说）"和"驾驭工程 / Harness（在什么约束下运行）"之间的中间层，也是当前决定 Agent 长程任务成功率的关键变量。
一、为什么上下文管理是 Agent 的第一性工程问题
一句话结论：上下文窗口是稀缺、共享且会相互干扰的资源，管理不当会直接拖垮模型的决策质量。
Karpathy 有一个被反复引用的类比：把 LLM 看作 CPU / 操作系统，上下文窗口就是它的 RAM——是工作内存，容量有限，且需要主动调度。Agent 的每一轮推理，本质都是在这块有限的 RAM 里塞进"系统提示 + 历史对话 + 工具返回 + 检索结果 + 记忆"，然后让模型基于这块内存做下一步决策。
真正的麻烦有两层。
第一层是成本与延迟：Transformer 注意力的计算复杂度是 O(n²)，上下文越长，推理越慢、越贵。
第二层更隐蔽，是质量衰减——上下文越长，关键信号越容易被噪声稀释，这类现象被统称为 Context Rot（上下文腐烂），其中最典型的是 "Lost in the Middle"：模型对开头和结尾的信息敏感，对中间大段内容的注意力显著下降。很多看起来像"模型能力不足"的问题，追根溯源其实是上下文组织不当。
Drew Breunig 把上下文失效细分成四种模式，工程上非常实用：
失效模式 | 含义 | 典型场景 |
Context Poisoning（上下文中毒） | 一个幻觉或错误进入上下文后被反复引用、层层放大 | 早期一次错误推断污染整条决策链 |
Context Distraction（上下文分心） | 无关内容占比过高，模型注意力被带偏 | 塞入大量用不上的历史或工具原始输出 |
Context Confusion（上下文混淆） | 多个相似工具 / 信息让模型分不清该用哪个 | 一次性挂载几十个功能重叠的工具 |
Context Clash（上下文冲突） | 上下文里存在互相矛盾的指令或事实 | 新旧约束并存、多来源结论打架 |
这四种模式给出了上下文管理的目标函数：不是"尽可能多地喂信息"，而是在每一轮都维持尽可能高的信噪比。后面所有策略，本质都是围绕这个目标在做取舍。
小结：上下文管理要同时对抗三件事——窗口容量、推理成本、注意力衰减。判断一个上下文设计好不好，标准不是"塞了多少"，而是"当前这轮里，无关内容占比有多低"。
二、上下文窗口里到底装了什么
结论先行：把上下文拆解成稳定性不同的分层，是一切治理的前提。
一个运行中的 Agent，其上下文窗口通常由这几部分构成：
系统提示（身份 / 行为规则 / 安全红线）、工具定义、Skills 描述、对话历史（含工具调用与返回）、检索到的知识、跨会话记忆、以及当前用户输入。
这些内容的"稳定性"差异极大——有的每轮都不变，有的每轮都在变。按"使用频率 × 稳定性"分层管理，是业界共识：
常驻层 ── 身份定义、项目约定、绝对禁止项。每轮都成立，保持短、硬、可执行 按需加载 ── Skills / 领域知识。描述符常驻，完整内容触发时才注入 运行时注入 ── 当前时间、渠道 ID、用户偏好等动态信息，每轮按需拼入 记忆层 ── 跨会话经验写入 MEMORY.md，不进系统提示，需要时才读 系统层 ── 能用 Hooks / 代码规则 / 工具约束表达的确定性逻辑，完全不进上下文分层带来两个直接收益。
其一是信噪比：确定性逻辑（比如"实例 ID 必须以 i- 开头"）交给代码校验，就不必反复占用 token 让模型去记。
其二是Prompt Cache 命中率：LLM 推理时，如果当前请求的前缀与上次完全一致，这部分 KV 可以直接复用，无需重算。命中的前提是精确前缀匹配——任何一个 token 变化都会击穿缓存。所以把稳定内容（系统提示、工具定义）放前面、动态内容（时间、用户输入、工具结果）放后面，既是分层设计，也是在保护缓存。
这里有个反直觉但重要的判断：稳定的大系统提示，成本往往低于频繁变动的小提示。因为缓存写入只付一次费，后续每次读取可享受高折扣。Skills 延迟加载之所以有效，也在于按需注入的内容追加在稳定前缀之后，不破坏前缀缓存。
Claude Code 把这个思想做到了系统提示内部：它在组装 System Prompt 时显式插入一条边界标记__SYSTEM_PROMPT_DYNAMIC_BOUNDARY__，边界之前是可全局缓存的静态部分（身份、系统规则、工具指南、语气风格），边界之后才是每会话不同的动态部分（会话指导、记忆、环境信息、MCP 指令等），从而让缓存边界清晰可控。
小结：先分层，再谈治理。分层不仅省 token，还直接决定缓存效率；确定性逻辑应尽量下沉到代码 / Hooks，而不是留在上下文里让模型反复消费。
三、四类治理策略：写入、检索、压缩、隔离
结论先行：业界看似五花八门的上下文技巧，基本都能归入 LangChain 总结的四类——Write（写入 / 卸载）、Select（检索 / 选择）、Compress（压缩 / 精简）、Isolate（隔离）。理解这四类，再看具体系统就有了坐标系。
Write（写入 / 卸载）：把不必时刻在场的信息写到上下文之外——文件系统、数据库、记忆文件。工具返回的大段 JSON 与其塞进上下文，不如落盘成文件，让 Agent 用 grep / 脚本按需读取。这也是 Manus 反复强调的"文件系统即上下文"。
Select（检索 / 选择）：需要时才把相关内容取回来。包括 RAG、记忆检索、Skills 渐进式披露。核心是"默认少给，按需取回"。
Compress（压缩 / 精简）：在信息必须留在上下文时，通过摘要或修剪降低其体积。对应 Compaction（生成摘要替换历史）和 Pruning（直接删减冗余）。
Isolate（隔离）：把探索、试错、调试的细节关进子 Agent 的独立上下文，主 Agent 只接收结论。
这四类不是互斥的，一个成熟系统往往同时用上全部四类。下面几节按"压缩、记忆（写入 + 检索）、Skills 与工具（检索）、隔离"逐一展开真实系统的落地细节。
四、压缩与修剪：把历史"折叠"进窗口
结论先行：对话历史是上下文里唯一持续膨胀且可被安全折叠的部分，压缩（Compaction）和修剪（Pruning）是两种互补手段——前者用 LLM 生成摘要保留语义，后者用规则直接删减冗余。
一个直观的比喻（来自 OpenClaw 的解读）：长对话像一场开卷考试，课本学到第 50 页，最近的 45~50 页是必考重点，前面是随机抽查，而你只能带 10 页纸进考场。合理策略是——完整保留最近必考的重点，把前面的知识压成精炼摘要。这正是"头尾保留、中间摘要"的由来。
4.1 压缩（Compaction）：分块 + 多阶段摘要
OpenClaw 提供手动（/compact，可指定保留内容）和自动两种触发。自动触发用的是绝对水位线：当前 token 用量 > 上下文窗口 − 预留空间时触发，例如窗口 20 万、预留 2 万，用到 18 万就压缩。压缩前会把旧消息自适应分块，每块独立生成摘要，再合并：
关键常量（OpenClaw src/agents/compaction.ts） BASE_CHUNK_RATIO = 0.4 每块占上下文的 40% MIN_CHUNK_RATIO = 0.15 每块至少占 15% SAFETY_MARGIN = 1.2 20% 安全缓冲 SUMMARIZATION_OVERHEAD_TOKENS = 4096 为摘要指令与推理预留 摘要分层降级： summarizeInStages() 顶层：消息少→直接兜底；否则分块摘要再合并 └─ summarizeChunks() 处理单块，最多重试 3 次 └─ summarizeWithFallback() 完整摘要失败→剔除超大消息重试→再失败返回 "No prior history."生成摘要时的保留优先级是关键工程细节，各家高度一致：必须保留当前活跃任务、重要决策与结论、待办（TODO）、已做的承诺，以及所有不透明标识符（UUID、hash、IP、端口、URL、文件名等必须原文保留，改错一位后续工具调用就失效）。OpenClaw 用identifierPolicy: "strict"强制这一点，还配了 5 分钟超时保护和会话写锁防并发损坏，并允许用便宜模型专门做压缩。
Claude Code 把压缩分成三个层级，按代价从低到高排列：
压缩层级 | 触发 / 机制 | 特点 |
MicroCompact | 规则驱动，每轮替换旧工具输出 | 成本极低，不调用 LLM |
Session Memory Compact | 会话级摘要 | 中等，保留决策脉络 |
Full LLM Compact | 上下文超阈值时整体 LLM 摘要 | 代价最高，信息折叠最彻底 |
值得一提的是，Claude Code 的完整压缩用的是一套"九段式"结构化模板（明确要求分段保留背景意图、关键决策、已改文件、待办、当前状态等），本会话开头的 compact 摘要正是这套模板的产物——工程上可以直接借鉴。
Hermes 在触发逻辑上做了个更泛化的改进：用相对阈值而非绝对阈值。它不看绝对 token 数，而是监控占总窗口的比例，比如达到 50% 就触发：
context_length = 200,000 模型最大窗口 threshold_percent = 0.50 50% 触发 threshold_tokens = 100,000 当前对话 ≥ 此值即压缩好处是泛化能力强：无论底层换成 200K 还是 32K 窗口的模型，都能按"剩余空间健康度"自动决定何时清理，不必逐模型调配置。裁剪时同样采用"头部保护（系统指令 + 初始任务）+ 尾部保护（最近数轮）+ 中间摘要"。
4.2 修剪（Pruning）：规则删减工具返回
工具调用的返回往往是上下文的"吞噬大户"——一个大文件读取或复杂 JSON / XML 响应可能瞬间吃掉数万 token（阿里云不少 API 的返回就足以撑爆窗口）。OpenClaw 的策略是"头尾保留、中间省略"：Error / Traceback / 结构定义等关键信息通常在首尾，检测到超长输出就保留首尾、中间替换为...，并控制裁剪比例（一般不超过 50%）以尽量保留核心语义。此外它还结合 KV Cache 的时间窗口（通常 5~15 分钟）主动剔除过期的旧会话片段，既省 token 又降低推理延迟。
4.3 压缩 vs 修剪：怎么选
维度 | 压缩 Compaction | 修剪 Pruning |
核心操作 | 生成摘要替换旧消息 | 直接删减工具 / 会话结果 |
信息保留 | 摘要保留关键信息 | 信息直接丢失 |
成本 | 需调用 LLM | 规则删减，极低 |
适用场景 | 对话历史太长 | 工具结果太大 / 会话太多 |
一个容易踩的坑：压缩最大的风险不是"摘要不够短"，而是"保留顺序设错"。LLM 倾向于优先删掉"看起来还能重新获取"的信息，早期的工具输出常最先被删，但与之绑定的架构决策、约束理由、失败路径也容易被一并丢掉。
务实做法是在 CLAUDE.md 或等价文档里显式写出压缩保留优先级；
更稳的做法是把完整历史落盘为文件，摘要里只引用文件路径，让压缩变成"有损但可追溯"，而不是不可恢复的硬截断。
小结：压缩保语义、修剪省成本，二者配合使用。无论哪种，标识符必须原样保留、关键决策必须优先保留、最好可追溯。
五、记忆系统：让上下文跨会话延续
结论先行：Agent 没有原生的时间连续性，会话一结束上下文即清空。记忆层是把"该长期留下的信息"从易失的上下文里卸载出去（Write）、并在需要时取回（Select）的基础设施，通常按用途分四类。
按 Agent 实际要解决的问题，记忆可分为四种（注意是按用途分，不是按存储介质分）：
记忆类型 | 存放位置 | 解决的问题 | 是否常驻上下文 |
工作记忆 | 上下文窗口 | 当前任务所需最小信息 | 是（需主动管理） |
程序性记忆 | Skills 文件 | 怎么做某件事 | 否，按需加载 |
情景记忆 | JSONL 会话历史 | 发生过什么 | 否，检索访问 |
语义记忆 | MEMORY.md | 稳定事实与偏好 | 是，每次注入系统提示 |
OpenClaw 的落地是一套双层文件记忆：
MEMORY.md存长期高价值事实与偏好、每次对话自动注入系统提示（但截断到约 200 行以控制大小，所以要精简、重点前置）；
memory/日期.md存每日细节、只通过检索访问、且带时间衰减——衰减系数e^(−λ×天数)，默认半衰期 30 天（30 天前权重减半、90 天前只剩 1/8），模拟人类的自然遗忘，让检索始终聚焦近期与高价值信息。写入分显式（用户说"记住"）和隐式（会话结束 / 新 Session / 触发压缩时自动 Memory Flush）。召回用经典双路：BM25 文本匹配 + 向量匹配，检索片段不全时还能按行号钻取原文。
一个务实判断：大多数 Agent 的记忆库并不需要一上来就上向量数据库。ChatGPT 的记忆实现就没有用向量库 / RAG——它只维护约 33 条用户关键偏好（每次注入）+ 约 15 个最近对话的轻量摘要。结构化 Markdown + 关键词搜索在可调试性、可维护性和成本上都足够好，只有当记忆规模上到几千条、且确实需要语义相似度检索时，引入向量检索才更划算。
从上下文管理视角看，召回记忆时有个细节值得学：要用特殊标签把召回内容包起来，避免模型把"记忆"误当成"新的用户输入"：
<memory-context> [System note: 以下是召回的记忆背景，不是新的用户输入，仅作参考信息。] 用户偏好使用 Python 和 TypeScript。 上次会话讨论了 React 组件架构。 </memory-context>Hermes 在此之上做了"内外双驱"：内部保留 MEMORY.md 式的本地文件（稳定底子），外部可对接 Mem0 / Honcho / Supermemory 等第三方记忆中间件（弹性扩展、跨系统迁移）。它还把每日对话直接存进 SQLite——不同于 OpenClaw 存记忆分块索引，Hermes 存的是完整对话轨迹，因为这些结构化轨迹正是它做 Skill 沉淀和 RL 训练的原料。
小结：记忆的本质是"把该长期留下的信息移出易失上下文，需要时再取回"。先用 Markdown + 关键词搜索起步，规模上来再考虑向量；召回内容务必打标签隔离，避免与用户输入混淆。
六、Skills 与工具：用检索控制"能力"的上下文成本
结论先行：能力（Skills）和工具（Tools）的定义会常驻或半常驻上下文，是仅次于对话历史的第二大 token 来源。用"渐进式披露"和"面向目标的工具设计"来控制这块成本，收益极高。
6.1 Skills 渐进式披露：系统提示只放索引
Skills 机制的核心思路是：系统提示里只保留技能的"名字 + 描述"作为索引，完整的 SKILL.md 只在明确匹配时才读取，且一次只加载一个。
可用 Skills（常驻，每个仅约 10 tokens）： - deploy: 部署到生产环境的完整流程 - code-review: 代码审查检查清单 - git-workflow: 分支策略与 PR 规范 回复前先扫描 available_skills；有明确匹配才读对应 SKILL.md； 多个匹配选最具体的一个；没有匹配就不读。这样 Agent 拥有近乎无限的能力边界，日常上下文却保持轻量。但描述符的写法有两个坑：
其一是字数。描述符是常驻的，Skill 一多，长描述累积成本很可观：
# 低效（约 45 tokens） description: This skill handles the complete deployment process to production. It covers environment checks, rollback procedures, and post-deploy verification... # 高效（约 9 tokens） description: Use when deploying to production or rolling back.其二是精度。描述太泛（"help with backend"）会让任何后端任务都误触发，路由就乱了。有效的描述符是"路由条件"而非"功能介绍"——"何时该用我 / 何时不该用我"比"我能做什么"重要得多。实测数据很直接：没有反例时路由准确率从基准 73% 掉到 53%，补上反例后升到 85%，响应时间还降了 18%。反例不是可选项。
6.2 工具设计：从 API 封装到面向 Agent 目标
工具定义的质量比数量更关键——仅 5 个 MCP 服务器就可能带来约 55,000 tokens 的工具定义开销，相当于在 200K 窗口里还没开口就用掉近三成，工具一多，模型对单个工具的注意力也被稀释（正是前面说的 Context Confusion）。
工具设计经历了三代演进：
代际 | 思路 | 示例 |
第一代 API 封装 | 每个 API endpoint 一个工具，粒度过细 | get_post + update_content + update_title |
第二代 ACI（Agent-Computer Interface） | 工具对应 Agent 的目标而非底层操作 | update_yuque_post(id, title, content) 一次说完整 |
第三代 Advanced Tool Use | 优化工具的发现 / 调用 / 描述 | Tool Search / Programmatic Tool Calling / Tool Use Examples |
第三代里有两项对上下文管理特别关键。
其一是 Tool Search（动态工具发现）：不把全部工具定义一次性塞给模型，而是让 Agent 按需搜索工具，上下文保留率可达 95%，某些评测里模型准确率从 49% 提升到 74%。Cursor 的做法类似——把工具描述同步到文件夹，Agent 默认只看到工具名，需要时再查定义，A/B 测试显示调用 MCP 工具的任务总 token 消耗降低 46.9%。
其二是 Programmatic Tool Calling（代码编排）：不让中间数据一轮轮穿过模型，而是让模型用代码编排多个工具调用，中间结果在执行环境里流转、不进上下文，token 消耗可从约 150,000 降到约 2,000。
好工具还应返回结构化错误 + 修正建议，而不是笼统的 "Error"，这样 Agent 出错后能自我修复而非盲目重试
小结：Skills 用渐进式披露把能力成本压到极低，工具用"面向目标 + 动态发现 + 代码编排"把定义与中间数据挡在上下文之外。调试 Agent 选错工具时，先查工具描述，多数问题出在描述不准，而非模型能力。
七、隔离：用多 Agent 保护主上下文
结论先行：子 Agent 最大的价值之一，是把探索、搜索、调试的过程细节隔离在自己的独立上下文里，主 Agent 只接收结论——这是 Isolate 策略的核心，也是多 Agent 在上下文管理上的真正意义。
子任务里的搜索、试错、调试不应污染主 Agent 的上下文。主 Agent 真正需要的只是结论
Claude Code 和 OpenClaw 都用"精简系统提示"给子 Agent 做隔离：
OpenClaw 定义了三种提示词模式——full（主 Agent，全模块加载）、minimal（子 Agent，只保留工具 / 工作区 / 运行时）、none（几乎只有一行身份）。子 Agent 用 minimal，既省 token 又避免主 Agent 的 Skills / Memory 指令泄漏，保护隔离边界。子 Agent 还有两个基本约束：深度限制（防止无限递归生成孙 Agent，Hermes 设 MAX_DEPTH=2）和并发上限（Hermes MAX_CONCURRENT_CHILDREN=3），以及部分工具对子 Agent 禁用（DELEGATE_BLOCKED_TOOLS）。
但多 Agent 不是银弹，反而有个上下文相关的陷阱：幻觉会互相放大。Agent A 带偏、B 跟着强化、C 继续叠加，最后所有 Agent 收敛到同一个高置信度的错误结论。破解办法是引入交叉验证——让某个 Agent 独立判断，或用单元测试 / 编译器 / 人工审查做外部反馈，打断这条链。
小结：多 Agent 的上下文价值在于隔离——脏活留在子上下文，主上下文只收结论。但要警惕跨 Agent 幻觉放大，且强依赖任务不要硬拆。
八、工程落地：一条真实的上下文演进路线
结论先行：上下文管理不是一次性设计，而是随业务复杂度迭代出来的。
最初是严格限制窗口（硬控上下文长度）；
接着利用"尾部注意力"特性，把关键约束放在上下文末尾（对抗 Lost in the Middle）；
然后针对异常场景补充指引、做工程化裁剪；
再引入 Summary 压缩 + Prompt Cache 改造降低成本与延迟；
最后走向 Sub Agent 检索与执行分离 + 异步压缩——用子 Agent 隔离检索过程、把压缩放到异步链路以免阻塞主流程。
这条路线几乎完整覆盖了本文的四类策略：
限制窗口和裁剪是 Compress，Prompt Cache 改造依赖分层与前缀稳定，Sub Agent 分离是 Isolate，异步压缩是把 Compress 从主链路卸载出去。它给出的工程启示是：先解决"塞不下"（限制 + 裁剪），再解决"贵和慢"（Cache + 摘要），最后解决"复杂任务扛不住"（隔离 + 异步），分阶段演进，而不是一步到位。
Hermes 还展示了上下文管理的"离线"一面——它有两种压缩，
运行时的上下文压缩（对话进行中，降到窗口 50% 以下，粗略估算 token）和离线的轨迹压缩（对话结束后，用 HuggingFace tokenizer 精确计数、压到固定 15,250 token、用 Gemini Flash 做摘要），后者是为生成训练数据服务的。这提示我们：上下文治理的产物（对话轨迹）本身也是资产，可以反哺 Skill 沉淀和模型训练，形成"自进化"闭环。
小结：上下文管理是演进出来的。按"塞不下 → 贵和慢 → 扛不住"三阶段推进，且要意识到治理产生的轨迹数据本身有二次价值。
九、落地清单与取舍建议
把全文收敛成一份可执行的判断清单：
关于"放什么"：系统提示只放每轮都成立的常驻内容，短、硬、可执行；确定性逻辑（格式校验、权限边界）下沉到 Hooks / 代码，不要占 token 让模型记；动态信息放上下文末尾，既对抗 Lost in the Middle，又保护前缀缓存。
关于"怎么清"：对话历史用压缩（保语义）+ 修剪（省成本）配合；压缩时死守两条铁律——标识符原样保留、关键决策 / 待办优先保留；能落盘的大工具输出就落盘，让 Agent 按需 grep，别一次性喂给模型。
关于"记什么"：记忆先用 Markdown + 关键词搜索起步，规模到几千条再上向量；长期记忆文件保持精简、重点前置；召回内容用标签隔离，别和用户输入混。
关于"要不要拆 Agent"：只有子任务相互独立、且探索过程会污染主上下文时才拆；强依赖、需共享上下文的任务用单 Agent；拆了要用精简系统提示做隔离，并加交叉验证防幻觉放大。
一个贯穿始终的取舍：上下文管理的每一步都是"信息完整性 vs 窗口 / 成本 / 注意力"的权衡，没有免费的午餐。压缩会丢细节、修剪会丢信息、隔离会增加协调成本。工程上要做的不是消灭这些损耗，而是让损耗可控且可追溯——这也是本文反复强调"落盘可追溯""标识符原样保留""召回打标签"的原因。
参考来源
Anthropic — Effective Context Engineering for AI Agents（上下文工程官方博客）
LangChain — Context Engineering for Agents（Write / Select / Compress / Isolate 四类策略）
Drew Breunig — How Long Contexts Fail（Context Poisoning / Distraction / Confusion / Clash）
Anthropic — How we built our multi-agent research system
Cognition (Devin) — Don't Build Multi-Agents（共享上下文原则）
Anthropic — Effective Harnesses for Long-Running Agents
Andrej Karpathy — 关于"上下文窗口即 RAM、LLM 即操作系统"的类比
