长上下文智能体为什么越跑越笨：从上下文工程视角重构工作内存管理

一、问题的表象：智能体在长会话中的“退化”

很多开发者在接入长程智能体后都会遇到类似现象：任务刚开始的前几轮对话，模型表现得很聪明，改代码、理逻辑、调接口都顺畅。但只要会话推进到三四十轮之后，整个智能体就像换了一个人——终端响应明显变卡，模型开始前言不搭后语，甚至频频漏掉几轮前刚刚声明过的入参，开始在自己编造的局部假设里产生幻觉。

更让人头疼的是月底看账单，API 费用比预期高出一大截：明明只是排查了一个几行代码的小 bug，累计消耗的输入 Token 却动辄好几十万。

很多人第一反应是模型能力不行，或者觉得厂商宣传的长上下文不够实在。但深入排查大量长程 Agent 的调用日志后会发现，问题往往不在模型的推理底子，而在上下文管理上太粗放了。

二、从“提示词调优”到“上下文工程”

前 OpenAI 联合创始人 Andrej Karpathy 提过一个很有启发性的类比：如果把大模型看作计算机的 CPU，那么上下文窗口其实就是有限、易失且昂贵的工作内存。

这个类比非常关键。CPU 很强，但如果内存里堆满垃圾，再强的算力也会被拖垮。同样的道理，当我们在多轮对话里让 Agent 跑 grep 把整个文件都读进来、让外部工具倾倒深层嵌套的原始 JSON，或者无节制地把几百行构建测试日志塞进去时，本质上是在往模型的内存里倒垃圾。哪怕模型支持 100 万甚至 200 万 Token，也经不住这种无差别的堆叠。

也正因为这样，最近技术社区里的风向在悄悄变化：单纯调提示词措辞的“提示词工程”开始降温，而聚焦大模型工作内存调度与生命周期管理的“上下文工程”，正在成为更有价值的工程底座。

传统的上下文管理方式可以被描述为一种“失控黑盒”：原始代码、冗长 JSON 和报错信息直接堆进上下文黑盒，容易引起费用膨胀与注意力发散。而现代上下文工程更像一套清晰的内存管理系统，通过结构化精简、流式压缩与看板观测，让 Agent 的输入始终保持精炼。

三、理解长上下文的现实阻碍

要理解为什么上下文工程越来越受重视，得先看看长上下文在实际工程中遇到的现实阻碍。

过去大家花很多时间琢磨“提示词怎么写、语气怎么调”，这在单次问答里确实有用。但在复杂的 Agent 场景下，智能体要频繁调命令、读文件、发请求，上下文变成了一个持续变化、不断膨胀的动态系统。这个系统有三个典型特征：

第一，不可控的膨胀速度。 每次工具调用、每次文件读取、每次错误堆栈打印，都在往上下文里追加内容。开发者如果不做主动干预，Token 消耗会以近乎线性甚至超线性的速度增长。

第二，注意力的稀释效应。 虽然长上下文窗口让模型“能看见”更多内容，但看见不等于关注。当关键信息被大量冗余内容包围时，模型提取有效信息的准确率会明显下降。这跟人在一屋子噪音里听不清对话是一个道理。

第三，状态管理的缺失。 多轮会话中，哪些信息应该保留、哪些应该丢弃、哪些应该压缩、哪些应该归档，目前大多数工程实现并没有明确的策略。一切都靠“先把所有东西塞进去再说”，这显然不是长久之计。

四、上下文工程的三个核心原则

针对上述问题，一套成熟的上下文工程实践通常遵循三个核心原则：

4.1 精简输入：只给模型真正需要的信息

这不是简单的“少给一点”，而是要区分“任务相关信息”和“辅助性信息”。比如一个代码调试任务，模型需要看到的是目标函数的逻辑、相关类型定义和关键调用链，而不是整个仓库的文件列表或者前后端完整交互日志。

精简输入需要做语义层面的筛选，而不是机械地截断。一个好的做法是在工具调用层就做拦截：工具返回的原始数据先经过一层过滤，只保留与当前任务有关的部分，再写入上下文。

4.2 结构化表达：让信息更容易被模型消费

同样一份信息，用不同形式表达，模型的理解效率和准确率差异很大。对于代码类任务，基于语法树的结构化表示往往比平铺的文本更高效——它直接告诉模型函数之间的依赖关系、变量的作用域变化和控制流走向，省去了模型自己从代码文本里重新推导结构的精力。

对于 API 返回的 JSON，直接倾倒深层嵌套的原始字符串是最坏的选择。更合理的做法是提取关键字段、压缩无关层级、保留必要的数据约束关系。

4.3 生命周期管理：为上下文建立“垃圾回收”机制

上下文不应该是一个只进不出的容器。一套合格的上下文工程方案，需要明确回答几个问题：哪些信息在完成某一阶段任务后就可以丢弃？哪些信息需要压缩成摘要保留？哪些信息需要在会话层面持久化？哪些信息只是临时性的中间结果？

这本质上是给上下文引入类似操作系统内存管理的机制：有使用中的工作集、有可回收的缓存页、有需要持久化的存储区。现代操作系统之所以能高效运行复杂应用，靠的就是这套分级管理机制，而不是把所有数据都摊开放在 CPU 寄存器里。

五、三条技术路线：来自开源社区的实践启发

基于上述原则，开源社区涌现出了不少值得关注的实践经验。这些实践从不同角度切入，分别对应上下文生命周期中的不同阶段。以下从技术思路层面进行拆解，不涉及具体品牌或工具推荐。

5.1 结构化精简：基于语法树的代码上下文化

在代码类 Agent 任务中，Token 消耗的一个重要来源是“整文件读取”。开发者调用工具打开文件时，工具往往会把文件的完整文本返回，而模型真正需要的可能只是其中某一个函数、某一个类或某一段逻辑。

结构化精简的思路是：在代码进入上下文之前，先对代码进行静态解析，生成语法树或类似的中间表示。通过语法树，可以精确定位某个函数的所有引用、某个变量的声明位置、某个方法的调用关系。这样，工具返回的不再是整段文件文本，而是一个经过裁剪的结构化视图。

举个示意性的例子。假设一个 Python 文件包含十几个类和上百个方法，而当前任务只涉及其中一个类的两个方法。传统做法会把整个文件读进上下文，结构化精简做法则只返回这两个方法的签名、实现体和它们依赖的少量辅助类型定义。

这种做法的价值不仅仅在于节省 Token。更重要的是，它减少了模型需要“理解”的代码量。模型不需要从几百行代码里自己找重点，重点在进入上下文之前就已经被整理好了。这直接提升了模型对于代码逻辑的把握准确率。

5.2 流式压缩：面向 JSON 和工具输出的增量处理

另一种思路针对的是外部工具输出，尤其是 API 调用返回的 JSON 数据。在实践中，很多开发者会直接把 API 的原始响应塞给模型。但 API 返回的 JSON 往往包含大量无关字段、嵌套结构、重复的元数据和调试信息，模型真正需要的关键业务字段可能只占其中很小一部分。

流式压缩的做法是在工具返回数据写入上下文之前，对数据做实时处理和压缩——去除冗余字段、简化嵌套层级、保留必要的结构信息。比如对于一个包含列表嵌套对象的复杂响应，只提取后续决策需要的字段子集，并将数据压缩成更紧凑的结构化表达。

这种思路可以理解为给上下文加了一个“数据适配层”。适配层负责把不同工具、不同 API 返回的异构数据，统一转换成对模型友好的精简表达。这样做的好处是多方面的：降低 Token 成本、减少噪音干扰、提高模型提取关键信息的效率。

5.3 可观测回收：长上下文的垃圾回收与状态看板

第三种思路关注的是上下文本身的“健康状态”。由于上下文在长会话中持续膨胀，开发者需要一种机制来观测上下文里到底装了什么、哪些内容占用了大量空间、哪些内容已经不再需要。

可观测回收的核心是：为上下文维护一个结构化的索引，记录每一块内容的来源、大小、加入时间和当前是否仍被后续逻辑引用。基于这个索引，系统可以自动识别出“死引用”——比如某个工具调用的详细输出在后续十轮对话中都没有再被提及，这段内容就可能是可回收的候选。

进一步地，通过实时看板展示上下文的构成和变化趋势，开发者可以直观地看到 Token 消耗的分布情况、不同类型内容的占比变化，以及垃圾回收策略触发的效果。这种可观测性让上下文管理从“靠感觉”变成了“靠数据”。

六、真正的工程价值

当上下文管理从粗放转向精细化之后，会带来几个层面的收益：

模型稳定性提升。 上下文里噪音少了，模型对于关键信息的关注度自然会提升，长会话中的逻辑一致性和指令遵循能力也会改善。幻觉出现的概率虽然不能降为零，但会因为这些系统性噪音的减少而显著下降。

成本结构改善。 输入 Token 的消耗是很多智能体应用中成本占比最高的一项。通过精简和压缩，可以将输入量在保证任务完成质量的前提下大幅削减，这直接影响每一轮调用的费用。

可维护性增强。 上下文不再是不可见的黑盒，而是有结构、可观测、可回收的内存系统。这意味着开发者可以针对不同类型的任务设计不同的上下文策略，而不再是一套“全部堆进去”的粗暴方案。

七、写在最后

从单次问答到多轮 Agent 工作流的演进，本质上是在重新理解大模型的能力边界。长上下文窗口的不断扩大，并不意味着我们可以放弃对输入质量的管理。恰恰相反，窗口越大，越考验工程的精细程度。

把上下文当作“有限的、易失的、昂贵的工作内存”来对待，是构建可靠长程智能体的一个核心认知起点。围绕这个认知，精简输入、结构化表达和生命周期管理构成了上下文工程的三块基石。具体采用哪种技术路线，取决于任务类型和数据形态，但背后的逻辑是共通的：别让模型在一片噪音里找答案。

在未来，上下文工程不会只是一个过渡性实践。随着智能体从“能对话”走向“能干活”，对工作内存的精细化管理会像操作系统中的内存管理一样，成为底层基础设施中不可或缺的一环。现在开始认真对待上下文中每一个 Token 的去留，比事后再做成本优化要有效得多。