上下文预算分配与记忆 Compaction

大模型 Agent 上下文窗口动态预算分配与长任务记忆压缩机制 (Context Window Token Budgeting & Progressive Memory Compaction) 是将宝贵的有限上下文窗口当作“稀缺系统内存”进行严格预算与分页压缩的核心工程技术；核心分层预算模型：设定固定预算池（如 8k/32k 窗口）：System Prompt 与核心工具定义（预留 20% 静态预算）、动态工作记忆（预留 50% 用于存放最近 3 轮完整 Tool / Output Trace）、输出缓冲区（预留 20% 生成空间）、安全余量（预留 10% 缓冲）；记忆压缩 (Compaction) 策略：当动态工作记忆达到阈值上限时，触发渐进式压缩——1) 滚动滑动窗口截断 (Sliding Window Truncation: 仅保留最近 $K$ 条消息)；2) 语义递归摘要 (Recursive Summarization: 调用快速轻量小模型将早期 10 轮历史对话压缩为高密度 Structured State Summary)；3) 工具结果裁剪 (Tool Output Pruning: 对返回数万行的 API 响应截取关键字段，原文档存入向量库)。

超过 50 轮的长程交互会话、自主编程 Agent 分析大代码库、长文档持续分析系统。

朴素直接拼接所有历史记录会导致上下文在第 15 轮迅速爆满 (Context Overflow OOM)，引发模型注意力涣散 (Lost in the Middle) 与单次推理费用剧增；预算与压缩机制实现了无限长任务的恒定显存与恒定低延迟运行。

详细画出上下文窗口四大分区（System Prompt、Working Memory、Output Buffer、Safety Headroom）的 Token 预算配比与动态流动图？

递归语义摘要 (Recursive Summarization) 算法：如何在压缩历史对话的同时严格保留“已完成子任务状态”、“未解决的缺陷”与“关键实体变量”？

大模型在超长上下文下的“迷失在中间 (Lost in the Middle)”现象：为什么将关键 System 指令与最相关的 RAG 证据放置在上下文首尾能显著提升召回率？

大工具响应裁剪策略：当 Bash 或 Web 搜索工具返回 50,000 字原始 HTML/日志时，如何通过正则表达式与 Head/Tail 采样将其安全截断至 1,000 tokens？

Prompt Caching 友好型上下文排布：如何保持 System Prompt 与历史前缀的绝对静态不变以最大化 KV Cache 命中率？