LangChain 详解 Deep Agents 的上下文工程：如何记住信息而不塞满上下文窗口

LangChain 发布博客，介绍其开源 Agent 框架 Deep Agents 如何用 middleware 做上下文工程，应对长任务中的 context rot。

LangChain 发布博客，说明其开源 Agent 框架 Deep Agents 如何通过 middleware 做上下文工程，以应对长任务中出现的 context rot 问题，核心在于让 Agent 记住必要信息的同时不把上下文窗口塞满。

• LangChain 博客介绍 Deep Agents 用 middleware 做上下文工程
• 目的是应对长任务中的 context rot，即上下文堆积导致质量衰减
• 上下文治理被提升为框架中间层能力，而非业务代码细节
• 对跑长链路任务的 Agent 团队，稳定性比单轮效果更关键
• 落地前需用真实长任务验证压缩策略的信息损耗

这是什么信号

LangChain 官方博客把话题聚焦到一个具体的工程切口：开源 Agent 框架 Deep Agents 如何用 middleware 做上下文工程。关键词有两个——middleware 和 context rot。前者说明上下文处理被放在了框架的中间层，而不是散落在每个工具的调用逻辑里；后者说明问题被明确定义为：任务一旦拉长，上下文会随对话与工具结果堆积而逐步劣化。

这不是又发一个 Agent 产品，而是把「上下文怎么管」当作框架级问题来回答。它释放的信号是：Agent 的竞争点正在从「能不能调用工具」转向「长任务里还能不能保持判断质量」。

为什么重要

上下文窗口是稀缺资源，但更稀缺的是其中「有效信息」的密度。长任务中，历史工具输出、失败重试、中间结论会持续挤占窗口，导致模型注意力被稀释，表现就是早期还能推理正确，跑到后面开始遗忘约束、重复劳动、答非所问——这正是 context rot 描述的现象。

把这件事交给 middleware 处理，意味着上下文策略可以独立于业务逻辑演进：什么时候压缩、什么时候落盘、什么时候只回传摘要，都收敛到一层可复用的机制里。对框架来说，这是从「提供能力」到「保证长任务稳定性」的分水岭。

对谁有价值

最直接的是正在用 Agent 跑长链路任务的人：多轮检索、跨文件改代码、长流程数据处理。其次是做 Agent 平台与基础设施的团队，需要决定上下文治理能力自研还是依赖框架。再往外，是评估 Agent 方案的技术决策者，因为「长任务不掉线」已经是选型时绕不开的硬指标。

可以怎么行动

第一，用自己的真实长任务做压力测试，重点观察任务后半程的质量衰减曲线，而不是只看首轮效果。第二，把上下文治理从业务代码里抽出来，参照 middleware 的思路，明确压缩、检索回填、状态外置这几类动作的触发条件。第三，关注 Deep Agents 的具体实现方式，判断哪些策略可以迁移到自研栈。

风险与限制

上下文压缩本身有信息损耗，压得太狠会丢掉后续才用得上的细节；middleware 多一层也意味着调试链路变长，出问题时要判断是模型问题还是上下文策略问题。此外，博客与框架的能力描述属于发布方视角，实际收益仍需在自己的任务分布上验证，不要直接把宣传性结论当作已证实的工程指标。

信息差价值在于：多数团队仍把 Agent 效果问题归因于模型能力，而这条信号把矛头指向上下文管理机制。context rot 这个提法本身就有价值，它给「长任务越跑越笨」提供了一个可命名、可讨论、可优化的工程对象，而不是笼统的「模型不行」。

业务启发是，Agent 的工程化重点正在从工具接入转向状态治理。middleware 这一层的位置选择也很关键：放在中间层，上下文策略才能被多个 Agent、多种任务复用，而不是每个流程各写一套压缩逻辑。这直接决定了后续维护成本和能力沉淀速度。

可沉淀的动作有两类：一是建立长任务的质量衰减观察机制，把「后半程表现」纳入常规评测；二是把上下文策略抽象成可配置的组件，明确压缩、外置、检索回填的触发条件与回退方案。做到这两点，框架选型的变化就不会冲击自身的能力积累。

• LangChain：Blog（RSS） 原帖