做过长任务 Agent 的人大概率都遇到过同一个场景对话开头的那几步还像模像样订单信息、用户需求、流程约束都记得清清楚楚但任务执行到中后段它突然开始“自由发挥”——要么把已经处理完的步骤又做一遍要么对着一个中间分支无限深挖要么把最初的用户诉求忘得一干二净最后交回来一份看起来完整、实际上目标早偏了的结果。我排查过很多这类“跑偏”案例结论几乎一致模型本身没太大问题问题主要出在上下文工程上。上下文工程并不是把“很多信息塞给模型”这么简单它要解决的是长任务中“哪些信息进窗口、进多少、以什么顺序进、过期信息怎么退出、关键信息怎么不被冲淡”这一整套闭环。这篇就结合我自己在多个项目里的调优经历拆解 4 个被反复验证有效的方法以及它们背后的原理和可以直接照抄的实操细节。正在做多步骤 Agent、流程自动化、长文档处理或者被 Agent 对话漂移搞到头秃的人应该都能从中找到思路。1. 先搞清楚“跑偏”到底是怎么发生的上下文窗口里的信息衰减上下文工程的第一个原则是别急着堆信息。你只有先明白为什么 Agent 会在几十步之后突然“轴”起来才知道该往哪个方向修。1.1 上下文窗口不是内存更像一块不断被擦写的白板很多刚上手的人会把上下文窗口理解成一个“无所不包的大背包”觉得只要把历史对话、中间结果、角色设定全塞进去模型就能随时调用。但实际上上下文窗口是一块有一定容量的白板而长任务里每一步产生的中间信息都会往上写。写的东西一多最早的、最边缘的内容就会被挤到非常靠后的“注意力盲区”里。模型在做下一步预测时理论上能看到窗口里的全部内容但注意力分布天然不均匀。窗口中间靠后的内容权重通常最高而窗口非常前端或非常末尾的信息在长序列里经常是“看到了但没真正参与决策”。我自己做过一个粗略测试把一个 10 万 token 的长对话压缩到窗口中部和同样内容放在窗口前部后续任务完成度差了接近三成。这不是模型蠢而是长序列注意力天然有这种倾斜。所以“跑偏”的第一层含义是信息还在窗口里但它在注意力层面已经“隐形”了。你以为是模型失忆其实是上下文排布让重要信息落在了注意力盲区。1.2 三种最常见的跑偏模式记错、盯偏、绕圈根据我看到的现场表现长任务跑偏基本可以归成三类排查的时候非常有用记错目标任务初始要求被后续大量中间内容覆盖Agent 后续生成的每一步都“沾一点”原始目标但整体已经偏离。典型表现是最后交付物的结构和最初需求对不上比如要的是分析报告最后做成了数据清洗日志。盯偏细节Agent 被某个中间发现吸引无限深挖某个分支任务把主流程晾在一边。典型表现是某一步骤的执行轮数远超预期子步骤数量膨胀产出却和主目标无关。绕圈重复Agent 回到已完成的步骤重新生成一遍类似内容或者反复修正同一个中间结果始终进不到下一步。典型表现是日志里出现连续的重复动作函数调用记录高度雷同执行时间明显拉长。这三类问题通常不是单一原因而是多个上下文管理点同时失守。但只要把上下文工程的几根柱子立起来它们会同时被压下去一大半。1.3 哪些任务最容易踩雷也不是所有任务都容易跑偏。我总结下来低风险任务通常具备“步骤短、状态少、结果可验”三个特征比如单轮问答、简单文书改写、一次性代码生成。高风险任务则普遍长这样任务步骤超过 15 到 20 步且步骤之间没有强依赖关系Agent 可走的路太多任务过程中需要不断吸收外部数据、文件内容或用户新输入上下文处于持续增长状态最终结果没有一个绝对客观的对错标准比如“写一份有洞察的分析”“整理一份尽量全面的材料”这类任务跑偏了也不容易被立刻发现多个子目标并行推进彼此之间还要共享某些中间结论。如果你的任务命中了两条以上先别急着换更大的上下文窗口。窗口再大注意力倾斜的问题依然存在只是延后爆发。真正该做的是从上下文工程层面把信息流管起来。2. 方法一用显式任务状态替代模糊记忆第一个方法也是我认为最核心的一个不要让 Agent 去“回忆”自己做到哪了而是把当前进度和后续计划作为一种强制结构直接写进上下文。2.1 为什么“状态”比记忆可靠模型没有真正意义上的“状态”。你在对话里问它“你刚才进行到哪一步了”它能答出来是因为它在重复解析历史上下文而不是在读取一个内部寄存器。这意味着一旦历史上下文被压缩、被截断、被大量新信息冲淡它对自己“进行到哪一步”的判断就会失真。解决办法很简单把隐式记忆变成显式状态。所谓显式状态就是一段结构化的文本或数据例如“当前步骤5 / 总步骤9已完成A、B、C待完成D、E、F当前依赖D 需要 C 的结果”。这段状态在每一轮执行结束后被更新并在下一轮作为“粘在窗口最前端”的强制输入。我习惯把它类比成协作办公场景里贴在最上方的项目看板。人之所以不会做一半忘了目标不是记忆力好而是任务拆解、进度标注和下一步提醒这些外部脚手架在持续起作用。Agent 也需要同样的人工脚手架。2.2 落地方案状态块 检查点 进度断言具体落地我分三块来做定义状态块 在系统指令里预留一个固定字段比如CURRENT_STATE格式固定为[任务目标] 一句话还原最终要交付的结果。 [已完成步骤] 按顺序列出已完成的关键动作每条不超过一行。 [当前步骤] 现在正在执行的步骤以及该步骤的输入依赖。 [下一步骤] 紧接着要执行的步骤以及预计输出。 [风险提示] 当前上下文里值得注意的矛盾信息或缺失信息。这个状态块在每一轮 Agent 执行之后由主调度代码重写而不是依赖模型自己改。模型只负责读它、在它的约束下推进。设置检查点 在任务的“大里程碑”处比如完成数据收集、完成初稿、完成第一轮校验把当前中间产物写成一个独立的持久化记录。检查点的作用不只是防崩溃更是给后续步骤提供“重新锚定”的坐标。一旦发现 Agent 开始绕圈调度层可以直接把状态块回滚到最近的检查点重新注入而不是从头再来。加进度断言 在每一轮执行前让模型根据状态块生成一个简短断言“我确认当前正在执行第 X 步理由是……”这个动作看起来很笨但在界面上阶段效果异常显著。它强迫模型在做下一步之前先对自身位置做一次显式确认能明显降低绕圈和跳步概率。2.3 这里最容易翻车的三个坑状态块不是加了就完事实际用起来有几个细节需要特别注意。第一个坑是状态块被“淹没”。如果状态块放在系统指令末尾而后面的每一步历史对话都很长状态块照样会落进注意力盲区。所以我建议把状态块放在上下文的最前端紧跟在系统指令的核心约束后面并且每一轮都重新重复注入一次而不是让它随着对话自然滚动到后面。第二个坑是状态描述写得太啰嗦。状态块只应该包含“当前这一个时间点”的决策信息不要把过去十步的详细日志都贴进去。写得太细和上下文过长是同一个问题注意力照样被摊薄。已完成的步骤列个标题就行细节放在检查点记录里。第三个坑是让模型自己维护状态。我见过很多方案让 Agent 输出“new_state”字段再把这段字段拼回去当下一轮状态。短期对话没问题长任务里模型一旦误判错误状态就会被不断放大最终完全丢失真实进度。正确做法是主流程代码里有一份状态数据模型的输出只是建议是否更新、怎么更新由代码判断。3. 方法二对长历史做分层压缩保留决策链而不是流水账第二个方法是处理“上下文过长”的常规手段——压缩。但我观察到很多人压缩的姿势不对把压缩做成了单纯删减结果重要决策依据被连坐删除Agent 照样跑偏。3.1 上下文压缩要分清“流水账”和“决策链”我把上下文里的信息分成两类流水账和决策链。流水账指的是过程性记录比如“第 8 步读取了文件 A第 9 步调用了接口 B第 10 步返回了标题列表……”这类信息对理解当前任务已经不重要了留着只会占窗口。决策链则是“为什么做出当前选择”的关键依据比如“因为用户说要优先控制成本所以模型在第 6 步选择了低成本的方案 B”“用户在第 12 步否掉了旧逻辑原因是兼容性要求”。这些信息一旦丢失后续步骤就会失去判断方向等同于失忆。所以压缩的原则只有一条把流水账扔掉把决策链留下来。我见过不少失败案例压缩时按时间窗口简单截断把 20 轮前的对话直接砍掉。用户最初提的关键约束往往就埋在那堆早期对话里砍完之后 Agent 立刻变了一个人设拼命追求它自己以为的目标。3.2 分层压缩的具体操作我会在系统里维护三个层级的上下文原始层完整保留全部原始对话和执行记录只用于回溯不参与模型推理摘要层把决策链提炼成一段 300 到 800 字的动态摘要随着任务推进不断更新状态层也就是上一节说的状态块只放当前这一步需要的直接信息。模型每轮真正读取的是“系统指令 状态块 摘要层 最近 2 到 3 轮原始交互”。原始层是给调试用的不让它进推理上下文。这样即使任务执行了 50 步模型看到的上下文长度也保持在一个稳定范围注意力不会因为窗口膨胀而失控。摘要层的更新节奏我建议采用“关键转折必更新日常步骤累积更新”。用户提出新要求、切换了开关、确认了一个重要结论、推翻了一个旧结论这些事件一发生就立刻写进摘要。常规步骤比如“读取文件”“处理了其中一段”先攒着等摘要本身快超出目标长度时再压缩一轮。3.3 摘要到底怎么写效果差异巨大同样一段历史让模型“总结一下”和让模型“提取后续决策必须保留的约束与依据”得到的效果完全不同。前者会输出一堆正确的废话比如“用户提出了一些需求”“模型完成了一些操作”后者才会产出真正可用的决策链。我平时用一段固定模板来做摘要请基于以下历史记录提取对后续任务仍然重要的信息严格按照以下格式输出不要补充评论 1. [持久目标]用户最终要达成的结果以及不可违背的硬性约束 2. [关键决策]已作出的、影响后续步骤的选择及原因 3. [未决问题]尚未解决、需要后续继续跟进的争议或缺口 4. [关键事实]后续任何一步都可能用到的实体信息例如账号、日期、文件路径、数值口径。注意一个细节摘要里不要出现“用户说”“模型说”这类过程描述只保留命题本身。越接近“决策数据”的摘要后续轮次引用起来越不容易因转述损耗而失真。压缩之后还应该做一次“关键约束回填校验”。压缩前先圈出几个绝对不能丢的关键点比如原始需求、硬性约束、否决项压缩后人工或脚本检查这些点是否还在摘要里。这一步看似繁琐但能在早期拦截大部分“压着压着就跑偏”的问题。4. 方法三选择性注入控制每一轮的上下文“配比”第三个方法解决的是上下文里“不加区分地全塞”的问题。很多时候 Agent 跑偏不是信息不够而是无关信息太多把决策信号压低了。4.1 上下文多不等于好注意力的稀释效应模型在做每一步判断时其实是在窗口所有信息上做加权。如果窗口里塞了 30% 相关信息、70% 背景噪音那么即使相关信息的绝对量很大它的决策权重也会被噪音分摊。最典型的场景是长文档处理把整份一百页的文档全部塞进上下文再让 Agent“找出与当前问题相关的内容并处理”它非常容易抓住文档前几章的高频词而忽略真正需要关注的后半部分。这就像开会时桌上堆了一百份资料其中只有三份和本次议题相关。多数人反而会翻到最上面的那份就开始照着做而不是花半小时把一百份全看完再决定重点。Agent 也这样而且它更吃这个亏。4.2 按需检索 局部上下文的注入流程我的做法分四步把外部长内容先做切块和向量化也就是先建一个“外部资料库”不让原始文档进主上下文每执行到一个步骤先根据该步骤的输入需求生成检索词去资料库里取回最相关的 3 到 5 个片段把取回的片段和当前步骤的指令、状态块拼成一个临时上下文块供这一步单独使用这一步结束后临时上下文块就丢掉了不需要跟着主上下文长期保留。这套流程在长文档总结、多文件分析、知识库问答类任务里效果非常明显。它的本质是把“让模型从大海捞针”改成“先把针捞出来再让模型看针”。检索词本身的生成也很重要。我见过直接用“上一步输出全文”当检索词的做法结果检索回来一堆同义反复的片段。更有效的做法是让模型先生成“当前这一步需要什么样的信息”比如实体词、时间范围、信息类型再用这套结构化条件去做检索。条件越具体取回的片段越贴题后续 Agent 也就越不容易被无关内容带偏。4.3 注入顺序和边界条件取回片段之后放在上下文什么位置也有讲究。我的习惯是放在状态块之后、最近历史之前。因为窗口最前端的注意力权重通常较高状态块锚定“我在哪”紧接着放“这一步需要的外部信息”再往后放最近对话执行链路就比较顺。还要特别注意一个边界条件当检索结果与状态块里的“未决问题”冲突时以哪个为准。我在方案里规定检索结果只能作为参考信息不覆盖状态块里的已确认决策。如果二者冲突Agent 必须先停下来向调度层或用户确认而不是擅自按新检索结果推翻旧结论。这个规则能避免一种很隐蔽的跑偏——“被一个错误的检索片段带歪”。另外一个常见误区是检索只做一次。长任务推进过程中Agent 需要的知识会持续变化。我建议每个大步骤都重新跑一次检索而不是一开始把一堆资料塞进窗口让它“备用”。备用信息越少注意力越集中跑偏概率越低。5. 方法四设计系统级元上下文让 Agent 在高处“校准”前三个方法处理的是“具体信息怎么放”第四个方法处理的是一个更抽象层面Agent 对自己身份、边界和评判标准的定义。我把它叫做系统级元上下文。5.1 元上下文让 Agent 有一个“不会过期的自我定位”长任务跑偏到后期常见的一种表现是 Agent 开始把自己“当成了另一个人”。比如本来是做数据分析的 Agent到第 30 轮的时候突然开始输出营销文案本来是帮用户整理资料的 Agent突然开始给建议、做评价。这种“身份漂移”往往就是你最开始定义角色时的那段描述被几百轮后续内容彻底盖住了。解决办法是把角色、边界、评价标准单独抽出来作为一份“元上下文”在每一轮都重新注入。这份元上下文不需要很长但必须包含三个要素我是谁当前这个 Agent 承担什么角色服务对象是谁我绝不做什么哪些边界行为一旦出现就必须停止比如“不要修改用户原始数据”“不要执行超出需求范围的步骤”我如何判断完成什么状态代表当前步骤真正做完、可以进入下一步这个判断标准最好能对应到具体的可检查条件。我习惯把这份元上下文放在所有输入的最前端并且比状态块还要靠前。无论后面发生什么模型每一轮开口之前都会先“看见”自己是谁、边界在哪。这个动作对身份漂移的抑制效果比任何现场纠偏都稳定。5.2 规划与自我检查把“校准”变成流程动作元上下文不能只是静态文本还要配合动态的规划与自检动作。在主任务启动时我会让 Agent 先输出一份完整规划包括预计步骤、每步输入、每步输出、每步完成标志。这份规划本身也是一段重要上下文并且要放在状态块和摘要之间。后续步骤如果溢出了规划范围调度层就能及时发现并干预。在每个里程碑检查点我会额外让模型回答三个问题当前产出距离最终目标还有多远最近三步中有没有哪一步偏离了规划偏差原因是什么最初的需求约束是否仍全部有效有没有被新信息覆盖这三个问题不需要每次都注入完整历史只要给模型看状态块、摘要和最近几轮记录它就能做出判断。实际跑下来这三个问题能提前暴露大部分跑偏风险尤其是那种“已经偏了但所有人没发现”的风险。更激进一些还可以设置双通道校验一个通道是执行 Agent负责生成另一个通道是校验 Agent负责看执行 Agent 的产出和目标之间是否对齐。校验 Agent 不修改内容只输出“继续 / 修正 / 终止”三类信号。两个通道共享同一份元上下文和状态块但使用不同的指令措辞能降低“自己看自己”的盲区。5.3 四个方法如何拼成一套完整方案单独强调某一个方法都有点“单腿走路”。我实际跑下来的组合方式是用显式状态块锚定当前进度用摘要层和检索把有效信息压到最少但最关键用元上下文固定角色和边界用规划和自检查找偏差头。这一套下来Agent 的上下文结构基本固定为系统级元上下文角色 / 边界 / 完成标准 → 初始任务驱动终极目标 / 核心需求 → 状态块当前步骤 / 已完成 / 下一步 → 选择性注入当前步骤相关的外部资料 → 动态摘要决策链 → 最近 2 到 3 轮原始历史 → 当前用户输入每次执行一个新步骤时调度层重新拼装这份上下文而不是让模型在一条持续变长的历史里自己翻滚。这样既控制了窗口长度也保证了每个环节的信息数量和质量都处于可控状态。6. 真实调优记录一个长流程任务从连续跑偏到稳定收敛理论讲完分享一次比较完整的调优过程。这个案例我改了任务背景和细节但结构和踩点都是真实的参考价值不打折。6.1 任务场景与初始痛点这是一个多阶段的业务材料整理任务。输入是一批格式混杂的素材文件最终要交付一份结构完整、结论可靠的整理结果。任务步骤包括素材读取、分类、去重、主干抽取、辅助信息补全、结构重组、结论生成以及最终一致性检查拆完有接近 30 个执行节点。最初版本里我只做了一件事把初始需求写进系统提示然后把素材全部塞进上下文让 Agent 一步一步往下做。结果是每跑到第 12 步左右就开始出岔子。总结后的主要异常有三类明明已经完成了素材分类后面整理的时候又把已分好类的素材重新按新标准分了一遍对某个辅助信息分支过度查阅把主干分析晾了二十多分钟交付文本开头还在按最初需求口径组织到了后半部分突然按另一个口径写而且没有任何说明。日志里最典型的一幕是Agent 在第 15 轮重新“发现”了第 4 轮就已经确认过的分类口径并且把它当成新信息写进了后续逻辑。这本质上是早期决策链没有进入长期可见区等于白做了。6.2 调优过程一套方案渐次加进去我没有一次性把所有方法都堆上去而是按“状态 → 压缩 → 检索 → 元上下文”的顺序逐个加便于观察每个措施独立带来的改善。第一轮只加了状态块和检查点。改动之后Agent 已经很少出现“重新分类”这类进度回跳因为状态块里明确写着“分类已完成当前处于主干抽取阶段”。但新的问题浮出来摘要层还没建早期用户口径信息仍然被大量过程性内容稀释Agent 在后期仍会偶尔偏离初始口径。第二轮加了动态摘要专门把“消费口径、排除项、结构偏好”这些关键约束提取到摘要层。这个改动稳住了一大半偏口径的问题。代价是摘要本身需要持续维护如果某一次摘要生成质量不高后续几轮都会受影响。第三轮加了选择性检索。素材不再整体塞进上下文而是按需取片段。上下文长度肉眼可见地降下来了单轮延迟明显改善也因为噪音减少Agent 围绕主干推进的连贯性变好了。第四轮加了元上下文和规划自检。这次改变的是“支柱”跑偏率被压到了很低的水平。最直观的表现是哪怕中间有人为插入一次“无关联的闲聊”Agent 也能回到主线继续执行不会因为这段插入而被带走。6.3 数据与经验调优前后的对比数据大致是这样的初始版本在测试集上跑偏率约为四成也就是每 5 次长任务运行就有约 2 次需要人工干预加入完整方案后跑偏率降到不足一成。平均执行轮数也从原来的 28 轮降到 19 轮因为绕圈的消耗被大幅压缩。但这套方案也不是零成本。摘要有维护成本状态块和检索需要写调度代码双通道校验更是接近双倍模型调用。所以在实际项目里我会建议“看症状下药”如果只是偶尔绕圈先加状态块如果早期口径会被冲淡加摘要如果窗口过长加检索如果身份漂移明显再加元上下文。全上固然效果好但至少有一半项目用不到那么重的手段。7. 常见问题与排查技巧实录最后整理一份我在交流群里、项目评审里被问得最多的问题以及对应的排查思路。这些问题几乎每个做 Agent 的人都会遇到。7.1 问题现象与根因速查表表面现象常见根因优先排查方向任务后段忘记初始需求早期决策链被后续内容稀释摘要层有没有保住“持久目标”和“硬性约束”反复重做已完成步骤缺少显式进度状态状态块是否存在、是否每轮刷新、是否放在窗口前端被无关资料带偏上下文里噪音太多是否做了按需检索是否把全部资料塞进窗口角色身份漂移行为越来越不像原本的 Agent元上下文位置靠后或被覆盖系统指令里的角色边界是否每轮重新注入单个步骤执行轮数异常膨胀子目标缺少完成标准检查点里有没有明确的“本步完成标志”结果格式符合要求但内在逻辑错位中间结论没有回填校验关键步骤后是否做“产出 vs 目标”一致性检查7.2 排查顺序和三个易被忽略的细节遇到“跑偏”我建议按“状态 → 摘要 → 检索 → 元上下文”的顺序排查而不是先怀疑模型能力。因为前四项在工程上都可控调整成本也低。有三个细节特别容易被忽略。第一个是状态块该放的位置。很多人加了状态块却放在历史对话末尾那等于没加。上下文窗口的注意力重心通常在开头附近状态块一定要放在开头那一小段区域并且每轮固定出现不要移动位置。第二个是摘要更新时机。摘要不能只在“上下文太长”时才更新而要在关键事件发生时立刻更新。很多漏掉的口径约束往往是延迟更新期间被新对话覆写掉的。第三个是检索词的生成。直接用原问题去检索经常捞回一堆表面上相关、实际不解决当前子问题的片段。先让模型生成“当前步骤需要哪些信息”再基于这个生成结果去检索效果会好一个档次。7.3 排查过程中的备注技巧我在排查长任务问题时一定会给每轮日志导出三个字段当前输入、当前状态块、当前摘要。这三份数据拼在一起基本就能还原出模型在这一轮“看到的决策基础”。如果能看到模型跑偏前状态块没变、摘要也没变那就不是上下文问题可能要重新审视模型能力或工具调用逻辑。另一个好用的调试技巧是在任务中途人为插入一条与主题无关的输入比如突然问一句“顺便帮我查一下另一个东西”。一个上下文结构够稳的 Agent 会明确区分“这是新增任务”还是“当前主任务的依赖信息”并给出下一步处理建议而一个上下文结构不稳的 Agent 会直接把这条输入当成主线的一部分开始痛苦纠结。这条技巧我用来当压力测试比单纯看正常流程更快暴露上下文管理的薄弱点。做长任务 Agent上下文工程不需要一次上多重的方案但“信息怎么放”这件事值得反复打磨。每个要素最终都会反映在任务的稳定性上早一点把白板管清楚后面就能少当很多次救火队员。