Agent 达到上下文后怎么处理：从滑动窗口到长期记忆的工程实践

摘要Agent 达到上下文窗口上限后不能简单截断历史否则容易丢失目标、约束和工具结果。本文系统讲解上下文窗口限制、滑动窗口、摘要压缩、RAG 检索、任务状态外置、工具结果裁剪、分层记忆和降级策略帮助开发者构建更稳定的长任务 Agent。很多团队在做 Agent 时都会遇到一个看似突然、其实必然出现的问题任务跑着跑着上下文满了。普通聊天机器人可能只是多轮对话变长而 Agent 的情况更复杂。它不仅要记住用户目标还要保存任务计划、工具调用结果、中间判断、失败重试、外部文档、代码片段、历史约束和最终输出要求。只要任务稍微长一点上下文窗口就会快速膨胀。当 Agent 达到上下文上限后如果处理不好轻则回答变差、忘记前文重则丢失关键约束、重复调用工具、执行错误操作甚至把已经完成的步骤重新做一遍。本文从工程实践角度系统讲讲 Agent 达到上下文后应该怎么处理。文章目录一、先理解上下文窗口不是“记忆”二、为什么 Agent 更容易撑爆上下文1. 多轮规划会累积历史2. 工具结果往往很长3. 任务状态容易和聊天记录混在一起4. 失败重试会产生重复信息三、第一原则不要简单截断四、滑动窗口保留最近对话但不能只靠它五、摘要压缩把历史变成状态摘要要持续更新而不是不断追加六、长期记忆只放稳定信息不放所有历史七、RAG让历史和知识按需回来八、任务状态外置不要让模型自己记账九、工具结果裁剪工具不要返回“全量原文”十、上下文预算每次调用前都要算账十一、达到上限时的降级策略1. 请求用户缩小范围2. 分阶段处理3. 输出部分结果4. 切换长上下文模型5. 人工确认关键裁剪十二、常见错误错误一把上下文窗口当数据库错误二摘要过度压缩错误三长期记忆无差别加载错误四工具结果不裁剪错误五只关注输入不预留输出十三、工程实践清单上下文构建历史处理记忆系统工具调用任务状态降级策略总结一、先理解上下文窗口不是“记忆”很多人会把大模型上下文窗口理解成“模型记住的东西”。这个说法不完全准确。上下文窗口更像是模型当前这一次推理时能看到的工作台。放在工作台上的内容模型可以参考没放进去的内容模型就无法直接使用。窗口再大也不是无限记忆。对于 Agent 来说上下文通常包括系统提示词和安全规则用户当前请求历史对话任务计划和步骤状态工具定义工具调用结果检索到的文档片段中间总结和最终输出要求。这些内容都会占用 token。当总量超过模型窗口时系统必须决定保留什么、压缩什么、丢弃什么、外置什么。所以上下文管理的核心不是“怎么把所有东西塞进去”而是“怎么让模型在当前步骤看到最必要的信息”。二、为什么 Agent 更容易撑爆上下文相比普通问答Agent 有几个天然特点会放大上下文压力。1. 多轮规划会累积历史Agent 通常会先规划再执行再根据结果修正计划。如果每轮都把完整计划、完整历史和完整工具结果带上上下文会线性甚至指数膨胀。2. 工具结果往往很长一次搜索可能返回十几条结果一次文档读取可能返回几千字一次代码仓库查询可能返回多个文件。如果工具没有做裁剪模型会被迫阅读大量与当前目标无关的信息。3. 任务状态容易和聊天记录混在一起很多 Agent 简单地把“发生过什么”都放进消息历史。这样实现快但长期任务会很痛苦模型需要从一堆对话里自己恢复任务状态成本高且容易错。4. 失败重试会产生重复信息工具失败、参数错误、网络异常、权限不足都会产生日志。如果这些日志持续进入上下文不仅浪费 token还会干扰模型判断。三、第一原则不要简单截断当上下文超限时最危险的做法是从头或从尾粗暴截断。从头截断可能删掉系统规则、用户目标、关键约束从尾截断可能删掉最新工具结果和当前任务状态。两者都会让 Agent 行为变得不可预测。正确做法应该是基于信息价值裁剪当前用户请求必须保留当前步骤所需约束必须保留未完成任务状态必须保留最近且相关的工具结果保留过期、重复、低相关内容压缩或丢弃。上下文不是按时间排序简单保留而是按“当前决策是否需要”来保留。四、滑动窗口保留最近对话但不能只靠它滑动窗口是最常见的上下文处理方式只保留最近 N 轮消息旧消息丢弃或摘要化。它适合短对话和轻量任务优点是实现简单、成本可控。但只靠滑动窗口做 Agent 长任务风险很大。例如用户在第一轮说“不要修改生产环境”后面聊了很多实现细节。如果滑动窗口把第一轮丢掉Agent 可能忘记这个关键约束。因此滑动窗口应该配合状态摘要使用最近消息负责保留交互细节状态摘要负责保留长期目标、关键约束和任务进度。一个更稳妥的结构是当前请求用户本轮要做什么 任务状态目标、约束、已完成、未完成、阻塞点 最近对话最近 3-5 轮相关消息 必要材料当前步骤需要的工具结果或文档片段这样即使旧对话离开窗口关键状态也不会丢。五、摘要压缩把历史变成状态摘要压缩不是把聊天记录“缩短一下”而是把过程信息提炼成可执行状态。例如一段很长的对话可以压缩成用户目标排查线上接口超时并给出处理建议。 关键约束只读查询不能直接修改生产配置高风险操作需要人工确认。 已完成收集最近 15 分钟告警和接口日志。 当前步骤分析慢请求、依赖服务状态和错误分布。 待确认是否需要扩大排查时间范围。这种状态比原始聊天记录更适合 Agent 使用。摘要要持续更新而不是不断追加很多系统会犯一个错误每轮都生成一段摘要然后把所有摘要都保留。结果摘要本身也越来越长。更好的做法是维护一份“可变状态”每轮根据新信息更新它新目标覆盖旧目标已完成事项进入完成列表过期工具结果移除仍然有效的约束保留阻塞点单独标记。摘要的目标是降低上下文复杂度不是制造另一份长历史。六、长期记忆只放稳定信息不放所有历史Agent 经常需要记住用户偏好、项目背景、业务规则等长期信息。但长期记忆不等于把所有聊天都存起来。长期记忆适合保存用户稳定偏好例如输出语言、格式习惯项目长期背景例如系统架构、业务目标已确认规则例如安全边界、审批流程可复用经验例如某个工具的正确使用方式。不适合保存临时寒暄已过期的中间结果大段原始工具返回未确认的推测敏感信息和密钥。长期记忆进入上下文前也要检索和筛选。不是所有记忆每次都加载而是根据当前任务按相关性召回。七、RAG让历史和知识按需回来当任务涉及大量文档、历史记录或知识库时不应该把所有材料塞进上下文而应该使用 RAG 按需检索。RAG 在上下文管理里的作用是把“可能有用的信息库”放在外部只把“当前问题最相关的片段”放进模型窗口。实践中要注意几个点检索前先理解当前步骤需要什么用元数据过滤缩小范围例如项目、时间、文档类型召回后做重排序避免低相关片段进入上下文对相似片段去重减少重复 token对长片段再摘要只保留证据和结论。RAG 不是越多越安全。召回太多会让模型在噪声里找答案也会推高成本。八、任务状态外置不要让模型自己记账对于复杂 Agent任务状态最好外置到数据库、文件、任务系统或结构化状态对象中而不是完全依赖聊天历史。一个任务状态可以包含{goal:排查线上接口超时问题并给出处理建议,constraints:[只读查询,不能直接修改生产配置,高风险操作需要人工确认],steps:[{name:收集告警和日志,status:done},{name:分析慢请求和依赖状态,status:doing},{name:整理根因判断和修复建议,status:pending}],artifacts:[{type:log_summary,ref:trace-analysis-20260608},{type:metric_snapshot,ref:latency-dashboard-15m}],blocked_reason:null}每次模型调用前只把当前步骤需要的状态摘要放进去。模型执行后再更新外部状态。这种方式有几个好处状态不会因为上下文裁剪而丢失任务可恢复失败后容易定位更适合多人或多 Agent 协作可以审计每一步做了什么。九、工具结果裁剪工具不要返回“全量原文”很多上下文爆炸不是模型造成的而是工具设计造成的。例如读取文档工具如果默认返回全文搜索工具如果默认返回 20 条完整结果数据库工具如果默认返回所有字段都会让上下文迅速变大。工具应该支持limit限制条数fields指定字段max_chars限制字符数summary返回摘要cursor分页读取filter按条件过滤include_raw是否包含原文。Agent 调工具时也应该明确自己需要什么。例如不要说“读取这个文档”而是说“读取标题、摘要和与部署相关的章节”。工具结果进入上下文前可以先做一次结构化压缩来源文档 A 相关结论部署前需要完成审批。 关键证据第 3 节说明生产变更必须走审批流程。 与当前任务关系当前操作涉及生产环境因此需要人工确认。这比塞入整篇文档更可靠。十、上下文预算每次调用前都要算账成熟的 Agent 应该有上下文预算。也就是说模型调用前先规划 token 分配系统规则占多少当前请求占多少任务状态占多少历史摘要占多少工具结果占多少输出预留多少。如果材料超过预算就按优先级裁剪而不是全部塞进去。一个简单策略是固定保留系统规则和当前请求固定保留任务状态工具结果按相关性排序历史记录只保留摘要和最近几轮输出必须预留足够空间。如果不预留输出空间模型可能在生成到一半时被截断最终结果不可用。十一、达到上限时的降级策略即使做了预算复杂任务仍可能达到上限。此时 Agent 应该有明确降级策略。1. 请求用户缩小范围如果用户一次要求分析几十份文档可以回复“内容较多我建议先分析最近 10 份或指定一个主题。”2. 分阶段处理把大任务拆成多个阶段先提取摘要再汇总对比最后生成结论。每个阶段只携带必要中间结果。3. 输出部分结果当预算不足时可以先输出已完成部分并说明剩余部分需要继续处理。4. 切换长上下文模型如果任务确实需要大量材料可以切换到更大窗口模型。但这应该是有意识的选择而不是默认依赖。5. 人工确认关键裁剪对于高风险任务裁剪前可以让用户确认哪些材料必须保留避免误删关键上下文。十二、常见错误错误一把上下文窗口当数据库上下文窗口不是持久化系统。重要状态应该外置保存模型只读取当前需要的部分。错误二摘要过度压缩摘要太短可能丢失关键约束。例如把“不要发布只保存草稿”压缩成“处理文章”就会造成风险。错误三长期记忆无差别加载记忆越多不代表越智能。无关记忆会干扰模型还会增加成本。错误四工具结果不裁剪工具返回越多模型越累成本越高错误率也可能上升。错误五只关注输入不预留输出很多任务失败是因为输入塞太满导致输出空间不足。生成长文、报告、代码时尤其要注意。十三、工程实践清单最后给一份可落地的检查清单。上下文构建是否区分当前请求、任务状态、历史摘要、工具结果是否按相关性而不是时间顺序保留信息是否预留输出 token是否有上下文超限检测历史处理是否使用滑动窗口保留最近对话是否把旧历史压缩成状态摘要摘要是否会更新而不是无限追加是否保留关键约束和未完成事项记忆系统是否区分短期记忆和长期记忆长期记忆是否只保存稳定信息是否按相关性召回记忆是否避免保存敏感信息工具调用工具是否支持分页、字段选择和长度限制是否避免返回无关原文是否把工具结果压缩成结构化事实是否丢弃过期工具结果任务状态是否把任务进度外置保存是否记录已完成、未完成、阻塞点是否支持失败恢复是否能审计每一步操作降级策略是否能拆分大任务是否能请求用户缩小范围是否能输出部分结果是否在高风险场景请求人工确认总结Agent 达到上下文后真正的问题不是“窗口不够大”而是系统是否具备上下文管理能力。一个可靠的 Agent 不应该依赖无限上下文而应该做到当前步骤只加载必要信息历史对话压缩成可执行状态长期记忆按需召回工具结果先裁剪再进入模型任务状态外置保存超限时有明确降级策略。上下文管理做得好Agent 才能处理长任务、复杂任务和可恢复任务。否则窗口再大也只是更晚一点遇到混乱。对于生产级 Agent 来说上下文管理不是优化项而是基础能力。