写智能体时间久了你会发现一个规律刚上手时最怕模型“听不懂人话”做久了反而最怕模型“记不住事”。我印象最深的一次翻车是帮朋友搭一个长文档批量核查的智能体设计阶段一切正常前面十几步也跑得很稳结果跑到第二十步时模型突然把早先确认过的关键结论给改了整条复核链全部乱套。查到最后才发现不是指令写错也不是模型抽风而是上下文窗口被历史对话塞满系统把最早那几条带硬性规则的指令悄悄截掉了。从那以后我对“无限上下文”“百万级上下文”这类宣传词就多了一层警惕。窗口再大也架不住智能体一轮轮地把历史记录往里堆。长任务能不能跑得动真正决定性的因素不是窗口初始有多大而是智能体有没有“自己删记录”的本事——知道哪些该留、哪些该删、哪些该压成摘要存档。这篇文章把我这些年做长任务智能体积累的上下文管理方案完整拆开讲包括思路、代码、参数和踩坑记录给正在用 Dify、Coze或者裸写 Python 流程搭智能体的朋友做个参考。1. 为什么“窗口无限大”也撑不住长任务算清三笔账1.1 长任务消耗上下文的真实速度是一笔很容易算错的账先把“上下文窗口”和“长任务消耗”之间的关系算清楚。假设一个智能体要执行 50 步任务每一步产生约 1500 token 的消息和工具返回结果。如果没有任何管理机制第 50 步调用时上下文里需要携带前 49 步的全部内容大概就是 1500 × 49 73500 token已经逼近 80k。这还只是理想情况如果中间步骤涉及读取大段文档、抓取网页、返回表格一步就能干出上万 token几轮下来冲到几十万非常正常。很多人对上下文窗口的直觉是1M 窗口能装很多内容所以跑长任务没问题。但实际上长任务消耗上下文的速度取决于“每一步给模型喂多少”和“总共要跑多少步”两个变量。这两个数一旦大起来任何窗口都会被填满区别只是时间早晚。所谓“窗口不够用”表面看是窗口上限的问题本质上其实是“上下文增长速度”的问题。这也解释了为什么让智能体学会删记录比单纯换大窗口模型要靠谱得多。我把上下文窗口比作一个工作台窗口越大台面越宽能摊开的资料越多。但工作是连续的新资料不断往台上堆老资料不收拾台面迟早被占满更麻烦的是堆在底下的资料你反而找不到。真正决定长任务能跑多远的不是初始台面有多宽而是你愿不愿意、会不会定期收拾。1.2 大窗口的三笔隐性账单成本、速度、准度先算成本。大模型按 token 计费上下文越长单次调用的费用就越高。一个跑 30 步的长任务如果每一步都把几十万 token 的历史全量喂进去单是调用费就会比“管理好上下文”的方案高出好几倍而且是可复现地高出好几倍不是偶发现象。我自己测过一个数据整理类智能体不做任何上下文管理时跑到中途的单次调用成本已经是起步阶段的 20 倍以上。任务越复杂这个倍数越夸张因为历史是按“步数 × 单步 token”的乘积在累积。再算速度。模型处理长上下文时前期的“预填充”环节要把所有历史 token 走一遍。窗口翻一倍首 token 延迟几乎同步翻一倍。用户体感就是智能体越跑越慢从 1 秒变 3 秒变 10 秒。在交互式任务里这个延迟非常致命因为用户根本等不起在自动化批处理任务里延迟又会直接变成整体耗时的增长。我见过一个团队把窗口从 32k 升到 128k任务没多跑几步单步耗时倒是翻了两倍就是因为每一步都要把 100 多 k 的历史从头过一遍。最要命的是准度。超长上下文中模型对信息的注意力会被稀释尤其容易丢掉藏在中间位置的关键信息这就是业内常说的 lost in the middle 现象。我见过一个典型案例智能体最早收到一条硬性规则“金额大于 5000 的单子必须走人工复核”结果跑到第 40 步之后这条规则就跟没存在过一样该复核的单子直接放行了。不是模型不聪明而是这条信息在一大堆中间内容里已经排不上号了。1.3 注意力被稀释与“伪记忆”为什么长任务跑着跑着就变笨再往深一层看上下文中堆积的冗余内容会反向干扰模型的判断。信息越多注意力越分散模型可能把旧的不相关细节误当成当前状态出现“串台”。我在一个多步骤数据清洗任务里就遇到过模型错误地复用了三十分钟前一份旧数据的字段格式原因是那份旧数据的描述还躺在历史里而新数据的说明被挤到了很靠后。上下文太长时模型不是“忘了”而是“不知道该信谁”。这正是所谓的“伪记忆”问题——它记住了很多信息但无法区分哪些还有效。这里要破除一个流行幻觉无限上下文不等于无限记忆。上下文长不代表信息有效更不代表信息能被准确检索和使用。注意力机制天然偏向开头和结尾的内容中间部分会被弱化。长任务里的关键约束通常出现在开头系统提示、任务目标、硬性规则当前动作出现在结尾最新一步的执行这两处相对安全反倒是中途产生的中间结论、临时候选值、阶段性状态成为最容易丢也最容易记岔的信息。可任务的一致性恰恰依赖这些中间信息。所以只靠加大窗口解决不了“关键信息被淹没”的结构性问题这个问题只能靠主动的上下文管理来解。2. 会删记录的智能体上下文管理的三个基本动作2.1 思路转变从“全量搬运”到“分层记忆”讲“自己删记录”之前得先扭转一个观念智能体不需要把每一步都记下来它需要的是“在正确的时机拿到正确的信息”。人做长事也是这样——你不会把三个小时前查过的每个网页都背下来你只会记住结论、关键数字和下一步动作碰到需要原始细节的时候再翻回去找。对应到智能体上我把上下文管理拆成三个层次工作区当前这一步真正要用的内容比如正在处理的文本片段、当前执行步骤的指令。这部分必须全量保留缺了就没法干活。临时区最近几轮的对话和工具结果用来维持即时连贯性。这部分保留一个滑动窗口即可不需要精确到每一步。归档区已经结束的步骤、过时的中间产物、被取代的历史结论。这部分不直接进上下文而是压缩成摘要或存入外部存储等需要时再按需召回。这个分层最大的好处是上下文的体量从“和任务步数成正比”变成了“基本恒定”。不管任务跑 20 步还是 200 步工作区加临时区的总体积始终可控归档区再大也不影响当前这次调用的 token 数。项目管理里常说的“把状态外置”放在智能体上就是同一件事。2.2 动作一滑动窗口——删得最干净但最容易丢东西滑动窗口是所有上下文管理方案里最朴素的一种只把最近 N 轮对话喂给模型之前的一律不要。实现成本极低几乎所有框架都有现成参数。Dify 里的“对话历史”轮数设置、Coze 里的“记忆轮数”选项、LangChain 里的 trim_messages本质上都是滑动窗口。但滑动窗口最大的问题是“硬删”它不区分信息价值时间一久所有旧信息一视同仁地被丢出去。如果任务早期有一条关键约束N 轮之后它一定不在了。所以滑动窗口只适合对话轮次短、历史信息本身冗余度高的场景比如客服问答——用户最近几轮在聊什么才是重点昨天的问答基本没用。对长任务智能体来说纯滑动窗口大概率不够用因为长任务恰恰是“早期信息影响全程”的场景。2.3 动作二摘要压缩——让模型先“写日记”再删原文比硬删聪明一点的做法是让模型定期把过去的对话提炼成摘要。具体思路设置一个触发条件比如轮数到了 10 轮或者累计 token 超过某个阈值就先让模型把当前的历史记录快速过一遍输出一段几百字的摘要然后把原文从上下文里移除只保留摘要继续往下跑。摘要压缩最关键的点不在“压缩”这个动作本身而在“摘要里该保留什么”。我第一次做踩了坑让模型自由总结结果它写了一堆过程性描述把真正的硬信息丢了。后来我强制用模板约束摘要结构必须包含已确认的结论、关键数字、当前目标、已废弃的方案、下一步待办。这样一来后续步骤需要的信息基本都能从摘要里找到而且摘要足够紧凑几百 token 就能覆盖几十轮的成果。摘要压缩还要注意一个“递归摘要”陷阱任务太长摘要本身也会越积越多。所以摘要也要分层管理——近期的用详细摘要远期的用概要摘要时间越久远颗粒度越粗。否则到了任务后期光摘要就有几万 token压缩等于白做。这个思路跟 Git 提交记录挺像最近的 commit 写详细一点远古的 commit 只要保留个标题就行。2.4 动作三外部记忆——把关键状态从上下文里“搬出去”再往前走一步就是不要把重要状态放在上下文里而是放到外部存储向量数据库、关系型数据库、KV 存储都行需要的时候再检索回来。这相当于给智能体配了一个“档案柜”上下文只是正在用的那一页纸。外部记忆适合两类信息。一类是大块的静态资料比如知识库文档、产品手册、参考材料用向量检索按需召回另一类是动态的任务状态比如“当前处理到哪个文件”“哪些单子已经复核过了”“某个字段的最终取值是什么”用结构化字段存下来随时查询更新。相比摘要外部记忆的优势是信息不失真——摘要本质上是模型的二次理解可能有损耗数据库字段则所见即所得写入是什么读出来就是什么。劣势也有接入成本高一些需要在任务流程里显式地写“写入逻辑”和“读取逻辑”相当于给智能体开发增加了持久层设计。我的经验是越是需要强一致性的状态信息越值得花这个成本。纯粹只是“让对话更连贯”的需求用摘要就够了不必动用外部存储。3. 手把手实操给智能体装一个“上下文管家”3.1 混合方案设计三层记忆的组合策略实际做一个长任务智能体我基本都采用“滑动窗口 摘要压缩 外部记忆”的混合方案。三个动作各管一段滑动窗口负责保持最近几轮的连贯性摘要压缩负责把滑出窗口但仍有价值的历史归档外部记忆负责存放那些跨步骤、高频查询的硬状态。这里我细说一下各层之间怎么协作理解了这个协作逻辑你就能根据自己项目的特性去调整。第一层是外部记忆层它只管“事实状态”比如任务开始前把目标写进去每完成一步把关键产出更新进去模型需要的时候通过一个查询动作拉出来。第二层是摘要层它管“历史脉络”那些已经滑出窗口、但又不能扔的旧内容按照固定结构压缩成一段摘要随着任务推进不断增量更新。第三层是工作层也就是真正发给模型的 message 列表包含系统提示、摘要、近期对话、当前步骤的指令以及从外部记忆查回的最新状态。这样设计的好处是职责清晰外部记忆承担“事实查询”摘要承担“脉络理解”滑动窗口承担“即时操作”。模型每次调用看到的不是几十万 token 的流水账而是一份结构化的“简报”信息密度和信噪比都高得多。3.2 可以直接抄的核心代码我用 Python 伪代码描述这个主流程实际接入时需要根据你用的框架做适配def run_with_context_management(task): short_history [] # 临时区最近 N 轮完整消息 summary # 归档区旧历史的摘要 state_store {} # 外部状态任务关键字段 for step in task.steps: # 1. 组装本次调用系统提示 摘要 近期历史 当前指令 关键状态 messages build_messages( system_prompttask.system_prompt, summarysummary, short_historyshort_history, current_stepstep.instruction, state_snapshotstate_store ) response call_llm(messages) # 2. 从回复中抽取关键字段写入外部状态 for key, value in extract_state(response): state_store[key] value # 3. 把当前轮追加进临时区 short_history.append({role: user, content: step.instruction}) short_history.append({role: assistant, content: response}) # 4. 临时区超限后滑窗裁剪溢出的部分压进摘要 if len(short_history) MAX_ROUNDS * 2: overflow short_history[:-MAX_ROUNDS * 2] short_history short_history[-MAX_ROUNDS * 2:] new_summary summarize(summary, overflow) summary new_summary这段代码的核心逻辑就是四步执行、抽状态、滑窗、溢出不丢而是压缩。实测下来一个 60 步的长任务不做管理的方案会在第 30 步左右开始出现上下文超限提醒用这套混合方案上下文占用几乎是平稳的单次调用 token 稳定在初始阶段的 23 倍以内而不是线性增长到几十倍。关于extract_state这一步很多朋友会忽略我多说一句它可以是正则抽 ID、金额也可以是让模型按 JSON 格式输出状态字段甚至可以针对每一步定义好“要用什么状态、产出什么状态”。这一步越明确外部记忆层的价值就越大。3.3 不会写代码在 Dify 和 Coze 里也能落地不用写代码的朋友也不用着急Dify、Coze 这类平台都能做上下文管理只是功能名字不叫“删记录”而是藏在“记忆”“历史”“变量”“数据库”这些设置里。先讲 Dify。Dify 工作流里每个节点的上下文由上游节点传入默认会把上游输出全量带下去这就容易出现“链表式”的超长上下文。我建议这么处理会话型应用里把“对话记忆”的窗口轮数调到一个合理的值比如 1020 轮别贪多工作流型应用里尽量只把当前节点真正需要的字段传给下一节点不要整段文本往下传需要跨节点保存的结论用“变量”节点显式存下来而不是靠上下文隐式携带。Coze 的设置思路类似Bot 的“记忆”能力可以打开但记忆量要控制关键是配合“数据库”或“变量”来保存任务推进状态让每一步都从数据库读最新状态而不是从历史对话里翻。需要说明的是我测下来这两个平台自带的记忆功能本质上是把“历史窗口 简单摘要”帮你做了适合对话型应用如果你的长任务对中间状态有强一致性要求比如金额、ID、状态位这种不能错的字段别指望平台自动记忆老老实实把关键字段写到数据库里。平台记忆面向的是“对话不要断片”数据库面向的是“状态不能出错”这是两件事。3.4 四个关键参数的调整经验把方案落成参数时有四个数字最常需要调我给出经验值但建议你拿自己的任务跑一轮再微调。参数经验值调整方向滑动窗口轮数610 轮单轮消息越长轮数越少任务越需要“前后呼应”轮数越多摘要触发阈值历史总 token 超过 4000 触发一次阈值太低压缩频繁反而费 token太高和暴力堆上下文没区别摘要长度上限单次摘要 300500 token超出就做递归摘要旧的浓缩成一句话新的保持详细外部记忆召回数量top 35 条宁可少召回几个高精度的也别一次召回 20 条把上下文重新塞满关于调参我个人的观察是做完上下文管理之后长任务的单次调用 token 波动曲线应该是一条“锯齿状”的线——涨到阈值就被压缩咬一口而不是一路飙到爆。如果这条曲线是平滑的直线上升说明压缩根本没触发或者触发条件设得太宽松了。另外滑动窗口轮数不要和摘要触发阈值割裂地调窗口越长摘要触发得越晚两者要匹配着调否则要么窗口还没满就频繁压缩要么窗口已经撑爆了摘要还没启动。4. 跑长任务时的高频故障与排查方案4.1 上下文超限报错先别急着换长窗口模型遇到“上下文超长”“context length exceeded”这类报错很多人的第一反应是直接把模型换成 128k、256k 的长窗口版本。我建议先做三件更便宜的事。第一看是不是整段历史在重复传。很多框架自带的 memory 模块会把全局历史无脑追加而你可能又在自己的 prompt 里手动加了一遍两者叠加token 直接翻倍。第二看有没有上游节点的输出被整包透传。工作流应用里“中间产物”是最隐蔽的上下文杀手——一个 CSV 解析节点就能塞出几十 K如果把这个结果作为固定前缀传给后面每一步等于给每一步都套上了一个沉重枷锁。第三看 token 统计里大头在哪里。多数平台日志会显示 tokens 明细先分清是系统指令膨胀、历史消息膨胀还是工具返回膨胀对症下药比盲目堆参数有效率得多。按这个顺序排查下来大部分超限问题不需要换更大模型就能解决。而且换更大模型往往只是把问题往后拖成本倒是涨了一截属于治标不治本。4.2 摘要之后模型“失忆”多半是摘要缺了硬信息压缩方案上线后最常见的问题是模型在摘要之后忽然“忘了”某些关键规则。我前前后后遇到过不下三次排查之后基本就是两类原因。第一类是摘要模板没把硬信息收进去。上一节强调的“已确认结论、关键数据”如果没写进模板模型就会按自己的理解随便总结把数字丢了、把约束改了。解决方法是把摘要指令里的字段从“可写”改成“必须填”比如明确要求“金额、ID、路径等硬信息必须原样保留不得概括”。第二类原因更隐蔽摘要明明写了但后续步骤里模型根本不看摘要。问题通常出在提示词结构上——模型没有被告知“历史结论以摘要为准”。我实测一个有效的小技巧把摘要作为 system 消息放在最前面并在系统提示里加一句“历史结论以摘要为准新消息中的冲突描述以当前数据为准”。这句话看着简单但能大幅降低模型在摘要和新消息之间“二选一”时的出错概率。4.3 压缩到底省不省钱把 token 总账算明白有朋友问压缩不也要额外调一次模型吗那一步不也要花钱没错压缩本身有成本。但账要算总账每 10 轮触发一次压缩压缩一次消耗几百 token换来的是后续每一步都少传几万 token。同样跑 50 步压缩方案的总 token 开销基本是暴力方案的 30%50%而且任务越长差距越明显。不过有个例外必须提醒如果任务只有 5 步以内不要折腾压缩直接全量上下文最简单。上下文管理是给长任务用的短任务上全套机制等于给自行车装发动机徒增复杂度和延迟。道理虽然简单但我见过不少团队把上下文压缩做成常驻逻辑结果在短任务上反而拖慢了响应。4.4 长任务上下文管理常见问题速查表问题现象常见原因处理方法出现 context length exceeded历史消息整体透传或中间产物节点全量串联排查 tokens 明细给中间产物“瘦身”只传必要字段跑着跑着模型忘了早期约束滑动窗口太小或摘要未包含硬信息用摘要模板强制列出“已确认结论 关键数据”并让模型以摘要为准压缩后模型反而更糊涂摘要把过程和结论混在一起摘要模板按“结论、数据、状态、废弃项”四个分区强制结构化单次调用成本暴涨无限制的历史累积每一步都在重新读全量设置滑动窗口和摘要触发阈值让上下文总量保持恒定长任务越跑越慢预填充耗时随上下文线性增长压缩上下文体量减少每步的输入 token模型把旧状态当成新状态上下文里有太多相互冲突的过期信息用外部数据库存状态字段组装消息时只注入最新值4.5 小技巧用“对话日志”验证上下文管理是否生效最后分享一个排查和验证用的实用技巧给智能体加一个“对话日志”把每次调用实际发送的消息条数、token 数、摘要更新时间戳记录下来。不要只在报错时看日志而是在跑完一个长任务之后把 token 曲线的截图翻出来看一遍。如果曲线是锯齿状说明压缩在正常工作如果曲线直线上升说明阈值没触发或窗口设置过大如果曲线突然掉下来一大截那可能是摘要触发时把还没处理完的上下文给截断了需要检查压缩条件和任务步骤之间的衔接。我靠这个办法排查了不少问题比盯着控制台报错高效得多。强烈建议做长任务智能体的朋友都把这个日志加进自己的项目里。最后再说两句我自己的体会。做上下文管理这件事最难的其实不是技术方案而是心态上的转变不要总觉得多给模型点历史就万事大吉模型不是记性不够而是信息太杂时会不知道该信什么。让智能体学会“自己删记录”表面上是省 token、降成本本质上是在帮它建立一个更清晰的工作方式——知道每一步真正需要什么信息而不是把所有东西都背在身上。在实际项目里这套思路给我省下的时间和成本远比想象中多。希望能帮你少踩几个我踩过的坑。