一个做竞品周报的 Agent，前面刚读完五家公司各几万行的市场数据，又看了几十篇新闻，最后只需要把报告排版好。它却带着全部原始导出、搜索结果和两版废稿，继续跟模型聊。

这不是模型上下文不够长的问题，是系统把仓库当成了聊天记录。

10 月 14 日，LangChain 在 Deep Agents 的一篇工程文章里把这个问题讲得很直。他们把长任务里的性能衰减叫作 context rot。模型并不是突然变笨，而是指令、工具输出、文件片段和中间草稿越积越多，真正该看的信号被噪声淹掉了。

我觉得这件事比又一个模型排行榜更值得开发者盯住。现在很多团队已经会用 LangGraph 编排节点，会接搜索、数据库和 Browser 工具，也会给模型配一个越来越长的 window。但 Agent 能不能跑完一个跨天任务，决定因素常常不在推理模型，而在每一段信息究竟该不该进入它的工作记忆。

上下文不是内存条，它更像手术台。

台上堆满东西，手术刀再锋利也没用。

长上下文最容易诱发一个误解

模型厂商持续扩大 context window，工程团队自然会有一种冲动，把更多材料直接塞进去。需求文档、数据库导出、网页全文、完整日志、过去所有对话，能给的都给。

看起来很保险，仿佛信息越完整，答案越可靠。

但长任务并不按这个逻辑工作。模型每次调用都要在当前上下文里重新判断什么重要。一个搜索工具返回五百条候选，一个 SQL 查询带回数万行记录，一次失败重试又产生一段长日志。它们即使不超出窗口，也会持续抢占注意力。最后 Agent 在写最终结论时，眼前可能同时摆着三天前已经作废的假设和刚刚确认的数据。

这类错误特别别扭。它不总是表现为胡说八道，更多时候是任务做到九成后开始变形。报告引用了旧数字，代码修了已不存在的分支，审批流忘了最初的限制，或者反复调用同一个工具。

很多人会归因于模型不稳定。我自己的判断是，至少有一半排查方向错了。你得先问，模型此刻看见了什么。

LangChain 给出的分类很实用。一类工作是阻止无关内容进入 window，另一类工作是管理已经留在 window 里的内容。前者处理输入闸门，后者处理存量垃圾。RAG 只解决了前半段的一部分，能找回资料不等于能控制 Agent 在执行过程中产生的废料。

Deep Agents 提供的不是一个神奇记忆，而是五条信息通道

这篇文章列出五种机制，Offloading、Summarization、Skills、Subagents 和 Long-term memory。把它们并列看，很容易误会成五个可选插件。其实它们分别处理完全不同的时间尺度和信息形态。

Offloading 处理大块原始物料。Deep Agents 的 FilesystemMiddleware 会在工具结果超过约 20,000 tokens 时，把完整结果写到文件系统，模型只看到开头、结尾和一个路径。超长的人类输入也会被转存，阈值约为 50,000 tokens。

这里的关键不是省 token，而是把读取权还给 Agent。它先看到预览，需要具体数值时再通过 read_file 翻到那一段。模型不必在每一步都背着一整张市场数据表，但数据也没有丢。

Summarization 处理的是任务推进后的历史。默认当 window 使用量到 85% 左右，系统把较早消息压成摘要，保留最近对话原文。更重要的一点是，原消息会写入 conversation history，摘要不是把过去一把火烧掉，而是给它建立一个可回读的索引。

Skills 是按需加载的程序性知识。比如发布博客时才加载发布规范，排查 Java 服务时才加载诊断 SOP。把所有操作手册塞进 system prompt 很常见，也很浪费。知识应该像工具箱，任务需要时打开某个抽屉，不该每天背着整间仓库上班。

Subagents 则隔离噪声最重的探索。让一个主 Agent 直接做网页搜索、读十篇材料、比较版本、写结论，主线程会被所有失败请求和候选片段污染。更合适的方式是把研究交给子 Agent，主 Agent 只接收结论、证据链接和不确定项。

最后是 Long-term memory。它跨会话保存稳定事实和偏好，比如客户的部署约束、一个项目的代码约定、用户明确表达过的取舍。Deep Agents 用受控存储中的普通文件保存这些内容，模型或 provider 可以更换，记忆不必跟着某个 API 一起消失。

这五种机制放在一起，才是一套完整的上下文工程。

不是记得越多越好，而是每一类信息都要有自己的进场方式、保留期限和回读入口。

摘要不是压缩率游戏，最危险的是把状态压没了

Summarization 很容易被实现成一次 LLM 调用，提示模型把前文总结为几百字。这样做能迅速降 token，但会埋下一颗很隐蔽的雷。

Agent 任务里最不该丢的不是背景介绍，而是状态。

举个 Spring 服务迁移的例子。一个 Agent 已经确认数据库 schema 需要兼容两版客户端，发现某个 Redis key 不能提前删除，CI 上还有一项 integration test 尚未通过。如果摘要只留下「正在完成迁移，已修改接口和缓存」，下一轮模型就会自然地把未完成的事当作已完成，把约束当成可选细节。

所以可用的任务摘要至少要分层记录。

  • 已确认事实，且最好带来源或文件路径
  • 当前假设，以及它仍然需要验证
  • 已完成动作和可验证产物
  • 未完成动作、阻塞原因和下一步
  • 不可违反的约束，例如权限、幂等、数据迁移窗口

我更愿意把它叫作 state checkpoint，而不是 summary。前者提醒我们，它必须支持恢复执行。你可以压缩解释，但不能压缩责任边界。

这也是 LangGraph 这类状态图框架真正该发挥作用的地方。图里的 state 不该只是 messages 数组。对生产任务而言，它还应该有结构化的任务状态，原始证据的引用，副作用的执行记录，以及待人工确认的关卡。对话可以被压缩，状态机不能靠模型猜。

文件系统很朴素，反而更适合做 Agent 的外部记忆

不少团队一提到长期记忆，就立刻想到向量数据库。它当然有用，尤其在语义检索场景。但如果 Agent 需要的是某次工具调用的完整 JSON、一次部署的日志片段、一个确定版本的 SQL 文件，向量检索并不是天然最优解。

文件和对象存储有几个很现实的优点。

第一，它保真。原始输出可以原样保存，日后排错不会面对一段被二次改写的摘要。

第二，它可定位。一个明确路径加行号，通常比「语义上相近的三段记忆」更适合工程操作。

第三，它容易审计。你能知道某次 Agent 读了哪个文件、哪一版内容，又据此产生了什么副作用。

第四，它更容易迁移。Deep Agents 明确把记忆放在自己控制的普通文件中。模型从 A 换成 B，甚至编排框架改变，业务记忆仍在。这对不想把工作流锁死在单一厂商上的团队很重要。

当然，文件系统不等于不要索引。目录层级、元数据、全文检索和生命周期清理都少不了。麻烦在于许多 Agent 项目一开始就把「memory」设计成一张无限增长的对话表，等到任务失败才想起做归档。

那时已经很难分清哪些内容是事实，哪些只是某轮模型说过的话。

给 Java 和 LangGraph 团队的一套落地切法

如果你正在做一个能跑半小时以上的业务 Agent，不用等待一次大重构。可以先在现有 Spring Boot 服务或 LangGraph workflow 外面补四层边界。

工具层先返回引用，再按需展开

对于搜索、数据库导出、日志查询、文件遍历这类工具，不要把完整 payload 原封不动塞回 messages。工具执行器负责把原文写进对象存储或工作目录，返回一小段 preview、统计信息、artifactId 和读取接口。

例如一次查询返回 30,000 行订单，不应该让模型通读 30,000 行。返回总行数、聚合指标、前后各几行和可分页查询的参数。Agent 想核实某个客户时，再精确拉取。

这块需要注意一下，preview 不是装饰。它要能帮助模型决定要不要继续读取，所以应该包含 schema、时间范围、异常值提示和引用地址，而不是随便截取前一千个字符。

把任务状态从 messages 里拆出来

给每个 run 一份结构化 state，存在数据库或可版本化文件中。至少包含 goal、constraints、completedSteps、pendingSteps、artifacts、riskFlags 和 humanApprovals。

每完成一个有副作用的步骤，就先写 checkpoint，再把结果告诉模型。这样即使一次模型调用超时、服务重启或用户中途修改需求，系统也能从状态恢复，而不是靠把所有历史聊天重新投喂一遍。

这听着比 prompt engineering 笨一点，但生产系统需要的就是这种笨办法。消息是叙事，状态才是事实。

子 Agent 的交付物必须有固定合同

不要只让研究子 Agent 回一句「我已经分析完了」。主 Agent 收到的应该是一份短而稳定的 result contract。

比如包含结论、证据 artifactIds、置信程度、尚未解决的问题、建议动作和是否产生副作用。这样子 Agent 的上下文可以很脏，主链路仍然干净。

反过来说，子 Agent 并不是免费并行。它会带来成本、结果不一致和协调开销。任务只需一次精确检索时，再开一个 Agent 反而别扭。把它用于资料探索、代码库侦查、方案对比这类高噪声工作，才划算。

为压缩设置业务触发器，不只看 token

85% window 是一个通用阈值，不是业务规则。一个订单退款 Agent 在切换客户案例时，一个代码 Agent 在从定位 bug 转入改动和测试时，都应该主动生成 checkpoint。主题切换往往比 token 快满更能说明旧上下文即将失效。

你可以按阶段定义摘要模板。研究阶段保留来源、假设和反证。执行阶段保留输入、输出和幂等键。验收阶段保留预期终态、实际终态和差异。这样压缩后留下的是下一步做决定所需的东西，不是上一篇聊天的缩写。

先别急着谈记忆，先画一张信息流图

很多 Agent 项目在 Demo 阶段都很顺。输入一句话，模型会调工具，最后给出一段像样的回复。真正上线后，用户会追加问题，工具会失败，文件会变大，任务会跨天，权限和审计也会找上门。

此时最重要的问题不是「怎么让它记住所有东西」。而是下面四个。

  • 这条信息是给当前决策用，还是未来可能回查
  • 它应该以原文、结构化状态、摘要还是 Skill 的形式存在
  • 谁能读取它，读取会不会带来新的权限风险
  • 什么时候过期，过期后保留证据还是删除内容

把这四个问题画成信息流图，你会发现不少看似高级的 memory 功能，其实只是缺了一个明确的归档策略。还有不少所谓模型退化，只是把无关数据一次次带回了工作台。

LangChain 这篇文章给出的五种手段并不新奇，文件、摘要、按需加载、隔离执行和持久化都是老工程思路。它的价值恰恰在这里。Agent 不是一个会无限记忆的聊天机器人，它是一个需要被安排工作台、档案柜和交接班制度的软件系统。

模型窗口会越来越大。

但一个成熟的 Agent，不该因此学会囤积，而应该学会在需要时拿到正确的那一页。

参考资料