“上下文工程是 AI Agent 工程化落地中最容易被忽视、却最致命的核心环节。”资料给出的这个判断，直接改变了 Agent 开发的优先级：决定 Agent 能力的不是 Prompt 写得多好，而是上下文管理得多好。典型 Agent 运行时持续累积系统提示词、用户指令、历史对话、工具调用结果和中间推理过程。Token 逼近窗口上限会同时带来三件事：成本线性增长、模型出现“中段遗忘”、窗口溢出直接报错。资料因此把 Prompt 工程与上下文工程区分开：前者解决“让模型理解意图”，后者解决“在有限窗口内持续保持智能与一致性”。
Token 预算管理是资料展开最充分的部分。单轮预算构成为：总 Token = System Prompt + User Message + History Messages + Tool Results + Tool Definitions + Output Tokens；且必须满足 Input + Output ≤ Max Context Window。容易忽略的是输出 Token 占用：GPT-4o 窗口 128K，如果 max_tokens=4096，输入最多只能约 124K。
估算方面，英文 1 Token 约 0.75 单词，中文 1 汉字通常 1~2 Token。不同模型 Tokenizer 不同：OpenAI 用 tiktoken BPE，Anthropic 用自己的 Tokenizer，开源模型多用 SentencePiece。资料特别提醒，混用 Tokenizer 误差可能超过 20%。因此生产系统应使用目标模型的编码器计数。
预算分配采用优先级递减。资料中的 TokenBudgetConfig 默认比例：系统层 5%、任务层 10%、对话历史 30%、工具结果 35%、检索内容 15%、安全缓冲 5%。可用输入 Token = 最大上下文 - 预留输出 Token。按 128K 和 4096 输出预留计算，系统层约 6,200 Token，历史约 37,200，工具结果约 43,400。TokenCounter 缓存 tiktoken encoder，并对消息列表计数：每条消息约 4 个固定 Token，name 字段额外 1，每轮结束标记 2。
固定比例不够，资料给出 DynamicBudgetManager，按阶段调整。AgentPhase 分四类：INITIALIZATION、EXPLORATION、EXECUTION、SUMMARIZATION。探索阶段工具结果升到 50%，历史降到 20%，RAG 10%；执行阶段工具结果 25%，历史 40%，RAG 10%；总结阶段工具结果 10%，历史 55%，RAG 10%。对话超过 15 轮后，历史再加 5%，工具结果减 5%，最后归一化。这个设计反映了一个直观事实：工具密集型阶段要留空间给返回结果，总结阶段则要保住历史脉络。
压缩策略方面，资料目录列出三类：摘要压缩（Summarization）、LRU 裁剪、选择性保留（Selective Retention），并设有“三种策略的对比与组合”。但提供的正文没有展开具体算法、阈值或代码。因此能确认的是策略名称与分类，不能把外部常见做法当作该文事实。工程分析：落地顺序建议先实现 TokenCounter 和静态预算，再根据阶段切换动态预算，最后引入压缩；压缩时系统层和安全规则应保持不可裁剪，工具结果因信息密度低应优先被压缩或摘要。
分层上下文设计方面，资料将其分为四层：系统层、任务层、对话层、工具层，并包含“四层上下文架构”和“各层详解”章节。但提供的正文只到系统层标题，未给出各层职责细节。因此这里只能确认分层框架，不能补充每层的具体字段。工程分析：如果按该框架落地，应把稳定约束放系统层，把当前目标放任务层，把可压缩的交互放对话层，把外部返回放工具层，并让 Token 预算与层级优先级绑定。
资料还列出上下文窗口溢出的分级响应：软溢出到硬溢出，包含三个级别、分级响应实现和时序图；以及一个完整的上下文管理器实现，包括整体架构、完整实现和生产部署建议。提供的正文未展开这些部分。适用边界方面，资料明确聚焦“对话型 Agent”，即多轮交互、工具调用、状态维持；单次推理和超长文档 RAG 不完全适用。版本声明提醒，内容基于 2024-2025 技术栈，涉及 GPT-4o/GPT-4.1、Claude 3.5/4 Sonnet、LangChain v0.3+，API 细节可能变化。
对中高级工程师而言，这篇资料最有价值的部分不是某个压缩技巧，而是把上下文工程拆成可计量的预算问题：先知道窗口如何被消耗，再让预算随阶段变化，最后才谈压缩和分层。资料未展开的压缩算法、分层字段和溢出响应，应在原文或生产验证中补齐，而不是按标题猜测。