上下文工程六大战术：Agent上下文溢出死亡与自救

概述

2026年，AI Agent领域正在经历一场静默但深刻的范式迁移——从"提示词工程"（Prompt Engineering）转向"上下文工程"（Context Engineering）。这不是概念炒作，而是生产环境的血泪教训。StackOne团队记录了一个典型案例：一个Agent在一次工具调用中返回15万Token，塞进了20万Token的上下文窗口，此后Agent并没有崩溃，而是开始"安静地做出错误决策"。Tian Pan的实验数据显示，当上下文使用率超过85%时，Agent的任务完成率下降37%，而开发者往往对此毫无察觉。Anthropic在2025年9月发布的工程博客中正式将上下文定义为"Agent最关键的有限资源"。本文深入拆解六大上下文管理引擎——从Token预算制、虚拟内存分页、提示词压缩到ACON自优化压缩、滑动窗口摘要和缓存复用层——在生产环境中的真实表现与架构取舍。

上下文工程 vs 提示词工程：为什么范式必须迁移

提示词工程解决的是"你告诉模型什么"，上下文工程解决的是"模型看到什么"。当Agent只是单轮问答时，这两者几乎没有区别。但当Agent进入多步推理、多轮对话、多工具调用的生产场景时，上下文窗口就从"资源"变成了"定时炸弹"。

2026年2月的一项涵盖9,649次实验的研究证实：精心设计的提示词在上下文膨胀后的效果劣化幅度远超模型本身的性能差异。一个在首轮表现优秀的Agent，在第12轮工具调用后，其准确率可能从92%暴跌至54%——不是因为模型变笨了，而是上下文被无效信息淹没。

上下文溢出的六种死亡模式：

六大上下文管理引擎深度对比

战术一：Token预算制——事前防御，拒绝超支

Token预算制的核心思想极其朴素：在Agent开始执行之前，为每个环节分配Token配额，超配即拦截。这像个人理财——你不会等刷爆信用卡才想起来做预算。

架构原理：

Agent Budget Guard（GitHub: woodwater2026/agent-budget-guard）实现了一个三层预算架构：

会话总预算(Session Budget)
├── 单轮预算(Round Budget) — 每轮最多消耗X Token
├── 工具预算(Tool Budget) — 每次工具调用返回最多Y Token  
└── 应急储备(Reserve) — 保留Z Token给关键决策

Tian Pan在Token预算分配框架中给出了一个生产级参考配额：对于编程Agent，系统提示占20%，对话历史占30%，工具输出占35%，推理链占10%，应急储备占5%。而搜索Agent的配额完全不同——工具输出可以占到50%，因为搜索结果本身是核心信息。

关键代码片段：

class TokenBudget:
    def __init__(self, total: int):
        self.total = total
        self.allocated = {}
        self.reserve_ratio = 0.05  # 5%应急储备

    def allocate(self, task_type: str) -> dict:
        profiles = {
            "coding": {"system": 0.20, "history": 0.30, 
                       "tools": 0.35, "reasoning": 0.10},
            "search": {"system": 0.15, "history": 0.20, 
                       "tools": 0.50, "reasoning": 0.10},
            "analysis": {"system": 0.15, "history": 0.35, 
                         "tools": 0.30, "reasoning": 0.15},
        }
        profile = profiles.get(task_type, profiles["coding"])
        usable = int(self.total * (1 - self.reserve_ratio))
        return {k: int(usable * v) for k, v in profile.items()}

    def check_tool_output(self, output_tokens: int, 
                          budget: dict) -> bool:
        return output_tokens <= budget["tools"]

生产经验：Zylos的研究报告显示，一个金融分析Agent在实施Token预算制后，每任务平均成本从$7.2降至$3.1，同时任务完成率从71%提升至83%——因为预算制迫使开发者在工具输出端做截断和过滤，反而提高了信息密度。

变现潜力：高。Token预算制是最容易包装成"AI成本优化训练营"的技术点，概念简单、效果直观、数据漂亮。可以设计一个"从$8到$2的Agent瘦身实战"课程。

战术二：虚拟内存分页——OS思想照亮Agent

MemGPT（现更名为Letta）是上下文管理领域最具雄心的项目。它的核心隐喻来自操作系统：LLM的上下文窗口就是RAM，外部存储就是磁盘，Agent自己就是操作系统内核——它决定什么留在内存里，什么换出到磁盘上。

架构原理：

Letta v0.16.7（GitHub: letta-ai/letta, ~22.4K Stars）实现了三层内存架构：

1. 核心内存(Core/Working Memory) — 始终在上下文窗口内，类似CPU寄存器。存放当前任务的关键事实、用户画像、活跃指令。容量通常在500-2000 Token。
2. 归档内存(Archival Memory) — 外部向量数据库，类似磁盘。Agent通过archival_memory_insert和archival_memory_search两个函数调用自主管理。容量无限。
3. 召回内存(Recall Memory) — 对话历史索引，类似日志文件。Agent通过conversation_search按语义检索过去的对话。

graph TB
    subgraph "Letta虚拟内存架构"
        LLM["LLM上下文窗口<br/>(= RAM, 200K Token)"]
        CM["核心内存 Core<br/>500-2K Token<br/>当前任务关键信息"]
        AM["归档内存 Archival<br/>向量数据库<br/>无限容量"]
        RM["召回内存 Recall<br/>对话历史索引<br/>语义检索"]

        LLM <-->|"始终驻留"| CM
        LLM -->|"archival_memory_search<br/>archival_memory_insert"| AM
        LLM -->|"conversation_search<br/>conversation_search_date"| RM

        CM -->|"page out<br/>换出"| AM
        AM -->|"page in<br/>换入"| CM
    end

    style LLM fill:#e1f5fe
    style CM fill:#c8e6c9
    style AM fill:#fff9c4
    style RM fill:#f8bbd0

关键洞察：Letta与传统RAG的本质区别在于——谁来做检索决策。在RAG中，检索逻辑是硬编码的（每次都查Top-K）。在Letta中，Agent自己决定何时检索、检索什么、保留什么。这种"自管理内存"范式在长任务中表现显著更好：Letta官方数据显示，在超过50轮的对话任务中，Letta的信息召回率比固定RAG方案高41%。

生产差距：Letta的理念先进，但生产部署复杂度不容忽视。Letta需要Agent具备较强的"元认知"能力——它需要知道自己知道什么、不知道什么。使用GPT-4o或Claude Sonnet级别模型时效果良好，但降级到更小模型时，Agent的自管理质量明显下降。Mem0团队的对比测试显示，在同等条件下，Letta的每次交互延迟比Mem0高2.3倍，因为Agent需要额外的推理来决定内存操作。

战术三：提示词压缩——用小模型为大模型瘦身

LLMLingua来自微软研究院（EMNLP'23, ACL'24），它解决的问题是：能否在送入大模型之前，用小模型把提示词压缩一下？

架构原理：

LLMLingua的核心思路是token级别的信息量评估。它用一个小语言模型（如GPT-2或LLaMA-7B）计算每个Token的困惑度(Perplexity)，困惑度低的Token（即高度可预测的）被认为是"冗余"的，可以安全删除。

LLMLingua-2将方案改为token级二分类（保留/删除），用一个训练好的BERT-scale模型直接判断每个Token是否必要，速度比原始方案快3-5倍。

TokenMix的2026年实测数据：

一个实际案例：某团队将月度LLM调用成本从$42,000压缩到$2,100——20倍压缩，准确率仅下降1.5个百分点。但关键在于，压缩比的甜区(Sweet Spot)因任务而异。编程任务对压缩最敏感（5x以上开始出错），而摘要/翻译任务在10x压缩下仍保持高精度。

生产使用注意点：LLMLingua引入了一个额外的延迟——小模型推理。在大流量场景下，这个额外延迟可能抵消Token节省带来的成本优势。Morph的实践建议是：只在上下文超过模型窗口50%时才启用压缩，否则直通。

变现潜力：极高。这是一个"投入1美元讲解、产出10倍回报"的经典技术点。可以设计"提示词压缩训练营"：用$10的API额度完成$200的任务。

战术四：ACON自优化压缩——Agent学会自己压缩

ACON（Agent Context Optimization）是微软研究院发表于ICML 2026的工作，它代表了上下文压缩的下一阶段：让Agent自己学习最优压缩策略。

架构原理：

传统压缩方法（包括LLMLingua）使用固定策略——无论什么任务、什么阶段，都用同一套压缩逻辑。ACON的核心创新在于引入了蒸馏(Distillation)机制：先让高性能模型在不同场景下尝试不同的压缩策略，记录哪些策略在哪些场景下效果好，然后将这些策略蒸馏成一个小型策略模型。

ACON流程： 1. 环境采集：在标准Agent环境（如WebShop、ALFWorld）中运行长时Agent任务 2. 压缩实验：在每个决策点尝试不同的压缩粒度和策略 3. 策略蒸馏：将"场景特征→最优压缩策略"的映射蒸馏为策略模型 4. 在线推理：新任务运行时，策略模型实时决定压缩方式

ACON在GitHub上的实现（microsoft/acon）提供了标准化管线，覆盖环境、Agent、压缩器和蒸馏器四个模块。

实测数据：在SWE-bench等长时Agent基准上，ACON相比固定压缩策略，任务完成率高出12-18%，同时Token消耗相当。更重要的是，ACON在"关键决策点"（如代码提交前的最终审查）自动降低压缩比，确保关键信息不丢失。

局限与风险：ACON目前仍处于研究阶段（ICML 2026 Poster），生产就绪度有限。策略蒸馏需要大量离线训练数据，且策略模型本身需要维护。对于任务类型多变的Agent系统，ACON的策略泛化能力尚未充分验证。

战术五：滑动窗口摘要——最朴素但最可靠

Agno（前身为Phidata）的上下文管理策略最简单：维护一个滑动窗口，旧消息超限后被摘要压缩，新消息完整保留。但"简单"不等于"简陋"——Agno在实现细节上做了多项工程优化。

架构原理：

Agno的Token追踪系统在每次LLM调用前计算当前上下文的Token总量：

# Agno Token追踪简化逻辑
def manage_context(messages, model_limit):
    total_tokens = count_tokens(messages)

    if total_tokens > model_limit * 0.85:  # 85%安全阈值
        # 策略1: 截断旧工具输出
        for msg in find_old_tool_outputs(messages):
            msg.content = summarize(msg.content, max_tokens=200)

        # 策略2: 压缩早期对话
        old_messages = messages[:-recent_window]
        summary = summarize_batch(old_messages)
        messages = [SystemMessage(summary)] + messages[-recent_window:]

    return messages

关键工程细节：

1. 85%阈值法则：Agno不在100%才触发管理，而是在85%时就开始压缩。这是因为Agent在下一轮可能需要生成大量输出，留出15%缓冲区是必要的。Tian Pan的实验证实了这个阈值的合理性——超过85%后，模型输出质量开始非线性下降。
2. 工具输出截断优先：当需要释放Token时，Agno优先截断旧的工具输出，而非对话历史。原因是工具输出（如API响应、搜索结果）的信息密度通常低于用户对话。
3. 摘要层级：不是一刀切地摘要所有旧消息，而是按时间远近分层——越旧的消息摘要越激进。

OpenSearch 3.5采用了类似策略并做了增强：摘要时保留关键实体和数值，而不是纯粹的语义压缩。这使得在金融分析场景中，关键数字不会在摘要中丢失。

生产优势：滑动窗口摘要不需要额外模型（除了摘要本身），不需要向量数据库，不需要Agent具备元认知能力。它是最容易集成到现有Agent框架的上下文管理方案。

战术六：缓存复用——不压缩，但避免重付

Anthropic的Prompt Caching代表了另一种思路：不压缩上下文，但避免为不变的上下文部分重复付费。

架构原理：

Claude API的Prompt Caching允许开发者标记上下文中的"缓存断点"(Cache Breakpoint)。被标记的内容如果与前一次请求相同，直接从缓存读取，跳过重新处理。

import anthropic

client = anthropic.Anthropic()

# 缓存系统提示和知识库
response = client.messages.create(
    model="claude-sonnet-4-6-20250514",
    max_tokens=4096,
    system=[
        {
            "type": "text",
            "text": system_prompt,  # 大段系统提示
            "cache_control": {"type": "ephemeral"}
        },
        {
            "type": "text", 
            "text": knowledge_base,  # 知识库文档
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[{"role": "user", "content": user_query}]
)

成本影响：Prompt Caching的Token价格结构： - 缓存写入：比正常输入贵25% - 缓存命中：比正常输入便宜90%

对于一个系统提示占10万Token、用户查询占2千Token的客服Agent，如果80%的请求命中缓存，总成本可降低约70%。Anthropic还提供了1小时缓存时长（默认5分钟），适合高频调用的生产场景。

Agent场景的特殊价值：在Agent循环中，系统提示和工具定义通常每轮不变，变化的是对话历史和工具输出。通过缓存不变的"基座上下文"，Agent每轮只需为增量内容付费。

局限：Prompt Caching目前仅适用于Claude系列模型。对于使用多模型路由的Agent系统，缓存只能在Claude调用段生效。此外，缓存命中率对会话模式高度敏感——如果用户每轮都在切换话题（导致系统提示变化），缓存几乎无效。

生产级上下文管理架构：组合方案

单一战术无法覆盖所有场景。以下是三种经过生产验证的组合方案：

graph LR
    subgraph "方案A: 轻量级"
        A1["Token预算制<br/>事前分配"] --> A2["滑动窗口摘要<br/>超限截断"]
        A2 --> A3["工具输出截断<br/>信息密度过滤"]
    end

    subgraph "方案B: 中量级"
        B1["Token预算制"] --> B2["LLMLingua<br/>提示词压缩"]
        B2 --> B3["Prompt Caching<br/>基座缓存"]
        B3 --> B4["滑动窗口摘要"]
    end

    subgraph "方案C: 重量级"
        C1["Letta三层内存<br/>虚拟分页"] --> C2["LLMLingua<br/>Token压缩"]
        C2 --> C3["ACON策略<br/>自适应压缩"]
        C3 --> C4["Prompt Caching"]
    end

StackOne的"Agent自杀"报告给出了一个关键警示：62%的Agent上下文溢出故障不是发生在峰值负载时，而是发生在"看似正常"的稳态运行中。原因是一个缓慢累积的上下文膨胀——每轮只多占3-5%的Token，但50轮后就超过阈值。这解释了为什么方案A的85%预警阈值比100%硬截断更有效。

InKeep的发现：上下文质量比模型质量更重要

InKeep的工程团队在2026年4月发布了一份引发广泛关注的报告，标题直截了当："Most AI agent failures aren't about model quality — they're about poor context management"。他们的A/B测试数据显示：

• 同一模型（Claude Sonnet 4.5），优化上下文管理后任务完成率从68%提升至91%
• 更强模型（Claude Opus 4.5）但不优化上下文，任务完成率只有74%
• 上下文优化带来的提升（23分）远大于模型升级带来的提升（6分）

这个数据对AI工程团队的预算分配有直接影响：与其把钱花在更贵的模型上，不如先投资上下文工程。一个$0.003/Token的模型配上优秀的上下文管理，往往比$0.015/Token的模型配上粗暴的全量灌入更有效、更便宜。

变现与训练营评估

最有价值的单一知识点：85%阈值法则。仅此一条规则就能防止大多数Agent上下文溢出故障。把它加入你的Agent框架，立刻见效。

选型建议

上下文工程不是锦上添花的优化技巧，而是Agent能否从Demo走向生产的分水岭。每一个在Demo中表现完美的Agent，在没有上下文管理的生产环境中都会经历同样的死亡螺旋——不是崩溃，而是安静地变蠢。理解并实施上述六大战术中的至少两种组合，是2026年AI Agent工程师的基本功。

参考来源

1. Effective context engineering for AI agents — Anthropic — Anthropic官方上下文工程指南，定义上下文为Agent最关键的有限资源
2. Agentic Context Engineering: How to Keep Agents Sharp — StackOne — 六种上下文失败模式和七种生存策略的实战总结
3. Tokens Are a Finite Resource: A Budget Allocation Framework — Tian Pan — Token预算分配框架，覆盖编程/搜索/分析三大任务类型的配额方案
4. The 2026 Token Optimization Playbook — Mem0 — Token优化实战手册，包含多信号检索和Token预算管理
5. ACON: Optimizing Context Compression for Long-horizon LLM Agents — ICML 2026 — 微软研究院Agent上下文自优化压缩论文
6. Handling context window limits in Agno — Agno框架Token追踪与上下文溢出防护实践

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。