部分内容可能来自网络或者由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规则驱动每轮替换旧工具输出成本极低不调用 LLMSession 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-contextHermes 在此之上做了内外双驱内部保留 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第二代 ACIAgent-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 还有两个基本约束深度限制防止无限递归生成孙 AgentHermes 设 MAX_DEPTH2和并发上限Hermes MAX_CONCURRENT_CHILDREN3以及部分工具对子 Agent 禁用DELEGATE_BLOCKED_TOOLS。但多 Agent 不是银弹反而有个上下文相关的陷阱幻觉会互相放大。Agent A 带偏、B 跟着强化、C 继续叠加最后所有 Agent 收敛到同一个高置信度的错误结论。破解办法是引入交叉验证——让某个 Agent 独立判断或用单元测试 / 编译器 / 人工审查做外部反馈打断这条链。小结多 Agent 的上下文价值在于隔离——脏活留在子上下文主上下文只收结论。但要警惕跨 Agent 幻觉放大且强依赖任务不要硬拆。八、工程落地一条真实的上下文演进路线结论先行上下文管理不是一次性设计而是随业务复杂度迭代出来的。最初是严格限制窗口硬控上下文长度接着利用尾部注意力特性把关键约束放在上下文末尾对抗 Lost in the Middle然后针对异常场景补充指引、做工程化裁剪再引入 Summary 压缩 Prompt Cache 改造降低成本与延迟最后走向 Sub Agent 检索与执行分离 异步压缩——用子 Agent 隔离检索过程、把压缩放到异步链路以免阻塞主流程。这条路线几乎完整覆盖了本文的四类策略限制窗口和裁剪是 CompressPrompt 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 AgentsWrite / Select / Compress / Isolate 四类策略Drew Breunig — How Long Contexts FailContext Poisoning / Distraction / Confusion / ClashAnthropic — How we built our multi-agent research systemCognition (Devin) — Dont Build Multi-Agents共享上下文原则Anthropic — Effective Harnesses for Long-Running AgentsAndrej Karpathy — 关于上下文窗口即 RAM、LLM 即操作系统的类比