AI Agent上下文管理实战：从死亡循环到智能截断的完整方案

在AI Agent开发中，大家往往把注意力放在提示词（Prompt）的优化上，却忽略了一个更关键的问题——上下文管理。Arise公司产品负责人Sally-Ann Delucia在最近的技术分享中，详细讲述了她的团队在构建AI Agent "Alex"过程中，如何从上下文管理的"死亡循环"中突围的完整历程。这些经验对于每一位正在构建AI Agent的开发者来说，都极具参考价值。

上下文工程为何比提示词工程更重要

去年中期，"上下文工程"（Context Engineering）这个概念开始在AI圈走红。Andrej Karpathy曾在X上公开表示，他更看重上下文工程而非提示词工程。Karpathy是AI领域最具影响力的技术领袖之一，曾任特斯拉AI总监和OpenAI联合创始团队成员。他的这一观点引发了广泛讨论，因为它将关注点从"如何措辞指令"转移到了"如何组织信息"这一更底层的系统设计问题上。Sally-Ann对此深表认同，她给出了一个精辟的定义：

最好的上下文策略，是让你的Agent记住它需要记住的，忘掉它不需要记住的。

很多人以为上下文管理就是"把内容塞进上下文窗口"，但真正的上下文工程是战略性地选择模型能看到什么。这里需要理解一个关键的技术背景：大语言模型（LLM）的上下文窗口是指模型在一次推理中能够处理的最大文本长度，通常以token为单位衡量。Token是模型处理文本的最小单元，一个英文单词大约对应1-2个token，一个中文字符通常对应1-2个token。早期的GPT-3.5上下文窗口仅有4K token，而如今Claude、GPT-4o等模型已扩展到128K甚至更大。然而，上下文窗口越大并不意味着效果越好——研究表明，当上下文过长时，模型对中间部分信息的注意力会显著下降（即"Lost in the Middle"现象）。

因此，上下文管理不是简单地控制在token限制以内，而是要精心挑选最重要的信息。如果Agent没有正确的上下文，就会给出糟糕的回答；回答质量差，用户就不会再使用你的产品。因此，上下文管理本质上是一个产品和用户体验问题，而不仅仅是工程问题。

恶性循环：越失败上下文越大

Alex是构建在Arise可观测性平台之上的AI Agent，需要处理大量的trace和span数据。这里有必要解释一下这些概念：Trace和Span是分布式系统可观测性（Observability）领域的核心概念，源自Google的Dapper论文和OpenTelemetry标准。一个Trace代表一个完整的请求链路，从用户发起请求到最终返回结果的全过程；Span则是Trace中的一个操作单元，比如一次数据库查询、一次API调用或一次模型推理。在AI Agent场景中，每一次工具调用、每一轮LLM推理都会生成对应的Span，这些Span嵌套组合形成完整的Trace。Arise作为AI可观测性平台，其核心功能就是收集和分析这些Trace/Span数据，帮助开发者理解Agent的行为和性能瓶颈。

团队采用了"用Alex来构建Alex"的策略——如果Alex能帮助团队自身更高效地开发，那它就一定能帮到用户。

然而，他们很快陷入了一个恶性循环：Alex在trace和span数据上运行 → span数据不断增长 → 数据量超出上下文限制 → Alex执行失败 → 失败本身又产生新的span数据 → 上下文进一步膨胀 → 再次失败……

上下文管理的三步解决方案

这个系统既在分析数据，又被数据所束缚。团队意识到，如果不解决上下文管理问题，Alex永远不可能正常工作。

三步突围：从朴素截断到智能记忆

第一步：朴素截断——简单但脆弱

最直觉的方案是截断（Truncation）：只取上下文的前100个字符，丢弃其余部分。这种方法在简单场景下确实有效，但Agent很快就"失忆"了。用户问了第一个问题后，追问相关细节时，Alex完全不知道在说什么——每次追问都像是一次全新的对话。

教训：过度截断会破坏推理链，导致Agent丧失多轮对话能力。

第二步：摘要压缩——听起来完美，实际不可靠

既然LLM擅长总结，为什么不让它把所有上下文压缩成摘要呢？这听起来是显而易见的解决方案，但实际效果极不稳定。问题在于：你无法控制LLM认为什么是"重要的"。

这背后有深层的技术原因。LLM生成摘要时存在固有的不确定性，这与模型的采样机制密切相关。模型在生成每个token时是基于概率分布进行采样的，即使temperature设为0（贪婪解码），不同的输入上下文也会导致模型对"重要性"的判断产生偏差。此外，LLM在摘要时容易出现"幻觉"（Hallucination）——可能遗漏关键细节或引入原文中不存在的信息。在AI Agent场景中，这种不可控性尤为危险：如果摘要丢失了某个关键的工具调用参数或中间推理步骤，后续的推理链就会完全断裂。

教训：摘要缺乏对"重要性"的控制，不适合作为上下文管理的核心策略。

第三步：智能截断+记忆存储——真正可行的方案

最终奏效的方案是智能截断与记忆存储的结合：

保留头部：取前100个字符（对话开头的关键上下文）
保留尾部：取最后100个字符（最新的交互信息）
截断中间：移除中间部分，但将其存入记忆存储
按需检索：Agent在需要时可以主动回溯，从记忆中获取之前的工具调用结果或对话内容

值得注意的是，这种"保留头尾、截断中间"的策略与前文提到的"Lost in the Middle"研究发现高度吻合——模型本身对中间部分信息的关注度就较低，因此截断中间部分对模型推理能力的影响相对最小。

核心理念是：上下文决定模型当前看到什么，记忆决定什么信息能存活下来。 这两者需要协同工作但又相对独立。这个方案已经稳定运行了数月，效果显著。

智能截断策略的实际效果

长会话是AI Agent的隐形杀手

即便有了智能截断策略，团队又遇到了新问题：用户不会主动重启对话。在Alex的使用场景中，用户会在不同页面间切换，持续在同一个对话中提问。对话轮次从最初的不到10轮，增长到了20轮以上。

长会话带来的失败往往出现得很晚，等到用户报告或团队主动检查数据时才被发现。为此，团队引入了长会话评估（Long Session Evals）：加载前10轮对话，然后测试第11轮的表现。

Evals（评估）是AI Agent开发中的质量保障体系，类似于传统软件开发中的自动化测试，但又有本质区别。与传统单元测试不同，Agent的评估需要处理输出的非确定性——同样的输入可能产生不同但都合理的输出。常见的评估方法包括：基于规则的精确匹配、LLM-as-Judge（用另一个LLM来评判输出质量）、人工标注对比等。Arise团队提出的长会话评估是一种针对上下文退化的专项评估策略，通过模拟真实的多轮对话场景来检测Agent在长对话中的表现衰减。

这样，上下文退化的问题就变成了可测试、可量化的指标，不再需要被动等待用户反馈。这种评估方法让团队能够在开发阶段就发现上下文管理的薄弱环节，而不是等到生产环境中才暴露问题。

子Agent架构：分而治之的上下文策略

即便有了截断和评估，某些任务的数据量对单个Agent来说仍然太大。比如搜索任务——Alex需要在Arise平台中搜索数据，一个trace栈中可能包含数百个span，涉及多次查询和大量中间推理。

团队的关键洞察是：并非所有上下文都需要存在于同一个Agent中。

子Agent架构设计

子Agent架构是多Agent系统（Multi-Agent System）设计中的一种经典模式，在软件工程中类似于微服务架构的思想——将一个庞大的单体应用拆分为多个职责单一、独立运行的服务。目前，LangGraph、CrewAI、AutoGen等主流Agent框架都提供了对多Agent编排的原生支持，这种架构模式正在成为行业标准实践。

改造前：主对话、聊天历史、重数据、搜索全部塞在一个Agent的上下文中，导致频繁溢出。

改造后：

主Agent：只保留对话上下文，保持轻量，扮演"编排者"（Orchestrator）角色
子Agent：承载数据密集型操作，拥有独立的上下文空间，扮演"专家"（Specialist）角色
协作机制：主Agent将重任务委派给子Agent，子Agent处理完后将结果传回主Agent
记忆共享：两者都可以从记忆存储中检索所需上下文

这个架构成为了真正的"游戏规则改变者"。团队随后推出了多个子Agent，将所有数据密集型操作都按这种模式处理，有效避免了单一Agent上下文过载的问题。这种架构的优势不仅在于解决上下文膨胀问题，还带来了更好的可维护性和可扩展性——每个子Agent可以独立优化、独立测试、独立迭代。

仍在探索的前沿问题

尽管取得了显著进展，Sally-Ann坦言团队仍面临多个挑战：

持续优化中的上下文策略

1. 超大上下文仍会导致崩溃。 由于Alex是在Agent数据上运行的Agent，客户的系统提示、用户消息、对话历史本身就是分析对象。随着客户数据增长，上下文问题会被放大。目前的应对模式仍然是继续拆分子Agent。

2. 长期记忆尚未实现。 当前的记忆机制本质上还是"带存储的上下文"，并非真正的长期记忆。用户希望能引用之前讨论过的问题，甚至在新对话中延续之前的分析。真正的长期记忆需要解决多个技术难题：如何在跨会话间持久化关键信息、如何建立高效的记忆索引和检索机制、如何处理记忆的时效性和冲突。团队正在开发真正的长期记忆功能。

3. 上下文选择仍依赖启发式规则。 "前100、后100"的策略虽然有效，但团队尚未建立原则性的上下文预算或上下文质量指标。目前主要依赖评估（Evals）来判断上下文选择是否正确。理想状态下，系统应该能够根据任务类型和复杂度动态调整上下文分配策略，而非使用固定的截断参数。

有趣的是，当Claude Code的代码被公开后，团队发现Anthropic也在使用类似的截断和压缩策略。Claude Code是Anthropic推出的AI编程助手，能够在终端环境中自主完成代码编写、调试和重构等任务。其实现代码的公开揭示了一个重要事实：即便是最前沿的AI实验室，在面对上下文管理这一工程挑战时，也没有找到根本性的突破方案。当前的上下文管理更多依赖工程经验和启发式规则，而非理论上的最优解，这也意味着这一领域仍有巨大的创新空间。Arise团队本来希望能从中找到什么"秘密武器"，结果发现大家面临的挑战和解法竟然如此相似。

核心启示

从Arise团队近一年的AI Agent上下文管理实战经验中，我们可以提炼出几个关键认知：

上下文管理是迭代的过程，没有一劳永逸的方案
上下文工程、记忆管理、评估体系三者缺一不可
Agent失败的根源往往不是提示词，而是上下文
子Agent架构是处理数据密集型任务的有效范式
长会话评估是发现上下文退化问题的关键手段

在AI Agent开发日趋成熟的今天，上下文管理正在从"附带问题"升级为"核心工程挑战"。谁能更好地解决"让Agent记住该记的、忘掉该忘的"，谁就能构建出真正可靠的AI Agent产品。