前段时间我把一个智能体任务从十几个子步骤扩展到上百个子步骤结果跑不了几轮就开始答非所问旧信息和新信息互相打架翻日志一看token消耗早就超出了合理范围。最讽刺的是底层模型当时标称支持非常夸张的上下文窗口——但任务照样崩了。折腾了几天之后我才真正想明白一件事智能体长任务跑不稳大多数时候不是缺上下文而是缺“删掉多余上下文”的能力。别再迷信无限上下文了学会自己删记录的智能体才真正跑得起长任务。这个结论听起来有点反直觉但它几乎适用于我现在接触到的所有智能体场景销售智能体、客服智能体、多智能体协同系统、甚至教学类智能体只要任务是分批、分阶段完成的早晚会遇到同一个问题——上下文记忆失去控制。这篇文章我就想把整个思路掰开揉碎讲清楚为什么无限上下文救不了你长期任务真正需要的记忆架构是什么以及如何让智能体学会自己删除、压缩、整理记录最后再把我踩过的坑一并交底。1. “无限上下文”这个神话是怎么破灭的1.1 窗口再大注意力也是有限的先说一个很容易被忽略的事实上下文窗口代表的是模型“最多能读多少字”而不是“读了之后都能想起来”。基于Transformer架构的大模型其注意力机制本身就存在衰减规律。当输入非常长的时候模型对中间位置的记忆会明显弱于开头和结尾这个现象业内有个通俗说法叫“lost in the middle”。也就是说你以为智能体记住了全程实际上它经常只记得最初几句和最近几句。我做过一个粗测同一份资料分别放在5000字的对话中和放在超长上下文的对话中让模型回答同一个问题。放在5000字时基本能答对放在超长上下文里反而开始胡说因为它被大量无关内容分散了注意力。这个结论对工程实践非常关键——窗口大只意味着“塞得下”不意味着“用得上”。1.2 上下文膨胀是雪球滚到后面谁也扛不住除了注意力分散还有成本问题。智能体每走一步会把历史记录、工具返回、中间推理堆到上下文里下一步决策又得重读一遍全部历史。我的经验是一个带搜索、写文件、调外部API的多步智能体每多执行一次工具调用上下文就可能多出几百到几千token。10步时还能忍50步时已经是天文数字。更麻烦的是推理延迟。上下文越长每次请求的耗时越长模型端到端响应越慢。跑到任务后半段你经常会发现智能体变“笨”了不是因为提示词写错了而是因为它在读一堆早就不需要的旧日志真正有用的信息被淹没在里面。这时候就算把窗口开得更大也只是把垃圾堆得更高。很多团队换更大窗口的模型本质上是想用算力掩盖记忆管理的缺失这条路走不通。1.3 信息污染才是最危险的副作用大多数人只盯着“塞不下”忽略了“塞进去了会污染判断”。一个跑了很久的智能体上下文里往往躺着之前做错的决策、过时的数据、失败尝试的中间输出。这些残渣不会自己消失它们会像桌面上堆满的旧文件一样让你翻不到现在要用的钥匙。模型基于被污染的记忆做决策轻则答非所问重则会重复犯之前已经犯过的错。我在实际项目中见过最典型的场景智能体在早期步骤里得到过一个临时结论后来这个结论已经被推翻但旧记录还在上下文窗口里于是后续每个决策都还带着那份过时信息整个任务越跑越偏最终只能从头再来。所以说无限上下文是伪需求真正的需求是“有效记忆”。与其拼命扩大窗口不如让智能体学会主动删除、压缩、归档保持每次决策只看最必要的内容。2. 跑长任务的智能体靠的是“会遗忘”的记忆架构2.1 把记忆分成三层工作记忆、短期记忆、长期记忆人脑不会把今天吃的早饭精确记到十年后智能体也不该把每个工具返回全量保存。我建议把记忆体系分成三层工作记忆当前这个步骤必须看到的最小集合比如当前子任务的描述、最近的执行结果短期记忆本轮任务内需要频繁引用的事实比如已经确认的中间结论长期记忆跨任务复用的知识比如用户偏好、业务规则、历史任务总结。分层之后模型的每一步输入只加载工作记忆短期记忆按需检索长期记忆在任务开始前注入关键背景。任务结束时短期记忆里的高价值内容会沉淀成长期记忆低价值内容直接过期淘汰。这跟人脑的记忆巩固机制很像海马体把白天的经历筛选、整合成长期记忆夜间还会反复回放没用的细节就丢掉。智能体想要稳定地跑长任务需要的正是这种“会遗忘”的结构而不是一个无限增长的垃圾场。2.2 只增不删的架构迟早会失控如果建一个记忆库却只允许写入、不允许删除那么它一定会重蹈上下文膨胀的覆辙。我见过不少团队引入RAG把历史记录全塞进向量库以为检索能解决一切。但检索范围一旦无限膨胀真正相关的片段也会被淹没在海量相似文本里相关性分数不再可靠检索结果和你想要的答案渐行渐远。RAG不是记忆管理它是记忆的“检索层”前提是你得先有一个会淘汰、会合并的记忆仓库。打个比方RAG相当于给房间装了一套搜索引擎但房间里的文件从来不扔、不整理那搜索引擎再好你依然找不到想找的文件。检索依赖的是库的健康度而库的健康度依赖删除与更新。2.3 记忆系统的四大基本操作写、读、改、删我倾向于把记忆系统当作一个正式的存储模块来设计而不是简单的一个列表。它至少要有四个能力写把新产生的执行结果、事实写入对应层级读根据当前目标和问题检索最相关的记忆片段改发现旧结论过时后能更新或纠正而不是继续留着错误版本删低价值、过时、冲突的记录能主动清理。大多数人的方案只做了前两个后两个几乎没人认真做。结果就是记录越攒越多错得越来越离谱。“会遗忘”不是缺陷而是让记忆系统保持健康的关键机制。谁先把这个机制补上谁的长任务能力就先上一个台阶。3. 让智能体学会“自己删记录”一套可落地的记忆淘汰机制3.1 先定评分标准哪些记录该留哪些该删“删哪些”不能靠直觉得有一套可量化的标准。我给项目定的评分维度通常包括时效性这个事实是什么时候产生的是否还有效引用频次后续步骤反复依赖的记录优先级自动提升来源可信度来自权威工具返回或用户明确表述的记录权重更高与当前目标的相关度跟当前子任务越近越值得保留。举个例子。销售智能体在跑一条线索跟进流程时客户在开场说的“预算大概10万左右”属于高价值事实必须进短期记忆而中途一次API查询返回的完整JSON原始报文只要能提炼出关键字段原始报文就可以直接删掉。很多工程师舍不得删就是因为没有做“信息提炼”好东西和垃圾一起堆着。3.2 设定触发条件什么时候该清理清理不能等记忆库爆了才做最好是在三种时机主动触发预算阈值触发每一步开始前检查当前工作记忆的token占比超过预设阈值就触发清理任务阶段切换从一个子任务进入下一个子任务时做一轮记忆整理主动总结点每隔N步或N条消息生成一次阶段摘要把原始对话压缩掉。触发时机设置得越早清理压力越小。我习惯把阈值设置得略保守一点比如工作记忆占到总预算的70%就开始处理而不是等到90%才动手。处理本身也需要成本留出缓冲才不至于影响主任务的流畅度。3.3 三种清理手段丢弃、压缩、归档清理不是只有“删掉”一种操作我常用的是三种手段配合丢弃低价值、已失效、临时性的记录直接丢弃操作最简单回收token最干净压缩对一段仍有参考价值但太冗长的对话做摘要用几十到几百字替代几千字的原文摘要是对阶段性信息的提炼本质上是把“详细过程”折算成“关键结论”归档高价值且跨任务复用的内容提炼成结构化条目写入长期记忆库从工作记忆中移除但仍可检索。一定要分清楚这三者的用途。丢掉的是垃圾压缩的是过程归档的是沉淀。只删不存叫失忆只存不删叫堆积。让一个专门的记忆管理模块来决策这三件事而不是让主任务顺手做可以避免主任务被记忆整理拖垮。很多人把这三种操作混成一锅粥找了个总结Agent把所有记录一股脑摘要结果要用的过程细节被压没了没用的垃圾反而被摘要保留这是最典型的翻车姿势。3.4 加一个专门管记忆的“管理员”Memory Manager我最终实践下来最有效的方案是给智能体配一个独立的Memory Manager相当于人体里的海马体。这个模块不直接参与业务决策也不负责执行主任务步骤它只做一件事决定哪些记录保留、哪些删除、哪些压缩、哪些升级为长期记忆。具体流程是这样的主智能体每完成一个动作把执行记录交给Memory ManagerMemory Manager周期性检查token消耗与阶段节点对照重要性评分对记录做处理处理完工作记忆被精简主智能体只拿到真正有价值的那一小块。整个循环很像一个“整理房间的人”你负责干活他负责让你下一次开工时桌面干干净净。这样做的好处是主智能体的输入永远保持精简决策质量稳定而且Memory Manager的决策可以被写入日志方便事后追查“这条记录为什么被删了”——这就是智能体行为审计的基础。如果你用的是现成的智能体框架比如基于Dify、Coze或者自研的Multi-Agent框架也可以把Memory Manager实现成一个专门的Agent角色挂在主工作流链路之外。3.5 一个可参考的最小实现流程我用伪流程描述一下方便你直接照着搭主智能体执行步骤产生执行记录检查当前工作记忆token数是否越过阈值或者是否处于阶段切换点把最近一段记录交给Memory Manager输出每条记录的处置建议按建议执行丢弃、压缩或归档把精简后的工作记忆刷新给主智能体将处置结果写入记忆操作日志供审计与回滚。这套流程不需要太复杂的实现一开始甚至可以用一份评分表加一个总结Agent完成。关键是形成“执行→评估→清理→再执行”的闭环而不是让记录无限累积。先跑起来再逐步细化评分规则比一次性设计一个完美方案靠谱得多。4. 动手清理时最容易踩的坑误删、压缩失真与时机错误4.1 坑一误删关键事实后续决策失去依据清理最怕误伤。有一次我让Memory Manager按“引用频次”清掉了一批低引用记录结果任务进行到后半段需要回溯一个早期细节时翻遍记忆库也找不到。原因很典型那个细节在当前阶段引用少不代表在后面阶段不需要。后来我调整了策略不再一次性删除而是把“待删除”的记录先放到一个滞后淘汰区超过一定轮次仍然没有被引用再真正删除。这个缓冲机制牺牲了一点存储空间但换来了安全性。对于几乎所有需求明确的生产任务来说这步缓冲都值得做。4.2 坑二摘要压缩失真“压缩幻觉”比原文污染更危险摘要不是无损压缩它对信息一定有取舍。大段对话被压缩成两三句话后模型很可能在摘要里脑补出原文没有的细节这是我认为最隐蔽的问题。这种“压缩幻觉”一旦进入长期记忆会在后续所有任务里被反复引用危害远大于原始记录污染。我的应对办法是摘要生成之后让同一个模型做一次事实一致性校验——把摘要与原文逐条比对有疑问就退回重新摘要。校验会增加一次调用成本但长期看非常划算。尤其是那些要沉淀进长期记忆的摘要必须做这个动作否则坏数据会像滚雪球一样在未来的任务里反复放大。4.3 坑三清理时机不对正在用的中间结果被删掉另一个容易被忽视的问题是清理时机。如果在一个子任务还没收尾时就急着清理很容易把后面步骤还要用的中间结果删掉导致任务无法回滚。我的规则是一个阶段内部原则上不清理阶段切换时统一做一次整理。这样既抑制了膨胀又不会打断正在进行的工作流。如果你是手动调度的场景我建议在每一个大型阶段结束时至少保留一份阶段总结与关键产物清单再清空过程日志。这样即使后面需要回看也不需要重新跑一遍整个阶段。4.4 验证清理效果别靠感觉靠对比实验判断记忆清理到底有没有用不能只看运行一次顺不顺利。我建议做一组固定长任务的对比实验同一份任务、同一个模型分别在“不做清理”和“做清理”两种配置下跑若干次记录四个指标任务完成率、平均决策轮次、总token消耗、异常中断次数。我曾经在一组跨阶段的信息收集与报告生成任务里试过不做清理时跑到第30步左右开始重复提问加清理后稳定跑到60步以上总token消耗反而更低因为模型不用反复读旧日志了。如果使用现成的测试基准比如AgentDojo这类强调智能体可信行为的工具集也能把记忆管理加进评测范围专门看“记录被删除后智能体还能不能完成依赖关系复杂的任务”。5. 把记忆清理做成可持续的工程习惯5.1 记忆管理逻辑要跟着任务结构调整而不是写死任务结构会变清理策略也得跟着变。比如电商客服智能体适合“按会话轮次清理每一轮都沉淀用户偏好”研发类多智能体系统适合“按阶段清理阶段结束必须交总结”教学类智能体则要保留足够多的解题轨迹清理时必须保留过程性信息否则没法给学员讲解思路。没有一种清理策略能适用所有场景先弄清你的任务里什么东西最不能丢再决定怎么清理。5.2 不管用什么框架核心都是同一套闭环不管你是用Dify搭可视化工作流、用Coze做快速原型还是从零手写Multi-Agent系统或者用Python直接控制调用流程记忆清理的核心闭环都是一样的执行、评估、清理、再执行。框架只是工具真正决定长任务跑得稳不稳的是背后有没有一套会淘汰、会更新、会归档的记忆体系。很多团队花大力气比较哪个智能体框架更好用结果框架换了几个长任务照样跑不稳问题恰恰出在记忆层没有设计。先把记忆管理做好框架选型反而是次要的事。5.3 开始可以激进一点跑通了再往回收如果你首次给智能体加记忆清理建议把淘汰阈值设得激进一些宁可多删、多压缩把上下文压到很瘦先跑通流程再根据任务表现把标准往回收。因为“删多了导致信息不足”是显性错误容易被发现而“存太多导致再次膨胀”是隐性风险跑很久才爆发。对于工程迭代来说先暴露问题再去修正永远比憋一个完美方案更快。5.4 单独开一份记忆操作日志方便审计与回滚我强烈建议给Memory Manager的每次处置都写日志记录时间、被处理记录的id、处置类型、处置原因。这不仅能帮你事后分析“任务为什么跑偏了”也是智能体行为审计的基础。审计不是找茬而是让你真正信任这个系统——你看着每天堆积的操作日志才能确认记忆库是健康的而不是一团胡乱裁剪后的烂摊子。最后说一句我自己的体会。我给项目定的规矩是每次长任务跑完都要看一份“记忆操作报告”删了什么、留了什么、摘要里有没有可疑改写。这个动作坚持了半年帮我发现了不少单看任务结果发现不了的问题也让我从“迷信更大上下文”彻底转向“把记忆管好”。如果你现在正被长任务跑崩的问题困扰不妨先别急着换更大的模型或更长的窗口给智能体配一个会自己删记录的“记忆管理员”很可能会收到意想不到的效果。