摘要沙箱演练不是生产事故。我在隔离沙箱里搭了个假订单后台让 Agent 批量处理一张很长的订单列表。开头交代的两条约定——金额按分返回、库存字段禁止修改——它跑到后半程全忘了还按默认习惯继续处理产出静默错误。复盘走完现象、定位、根因、修复、边界五步根因收敛为上下文被自动压缩早期细节在摘要里丢了跟上次导账翻车的上下文过期是两码事。文章目录开场跑了一整天开头交代的事全忘光了现象不是突然翻车是慢慢漂移排查对账脚本把漂移点揪了出来根因早期约定被压缩细节在摘要里丢了修复把不可丢的约定钉进状态文件复现步骤边界压缩不是唯一的翻车原因参考资料开场跑了一整天开头交代的事全忘光了不是生产事故先把这句话放最前面。我在隔离沙箱里搭了个假订单后台想让 Agent 演示一把长任务——一口气处理几百条订单生成发货状态流转中间不打断它。任务开始前我跟它把规矩交代得很清楚金额一律按分返回库存字段禁止修改订单号格式不许动。早上启动让它自己跑。到傍晚我去看结果前一百多条是好的后面开始不对劲。有几条的金额明显不对——它按元返回了。我第一反应是模型又犯蠢翻车了。可往前翻它明明一开始做得挺好是什么时候开始跑偏的现象不是突然翻车是慢慢漂移把它的处理结果按时间排开看翻车不是一瞬间的事是慢慢漂的。一开始都守规矩越往后越离谱。阶段处理进度行为表现前段前几十条规规矩矩按约定来金额按分库存字段没动中段过了一半偶尔一条金额单位开始错库存字段偶发被写后段接近收尾金额大量按元返回库存字段随手就改约定形同虚设表 1 行为漂移对照约定是慢慢失效的这个慢慢漂很关键。如果它一开始就错我一眼能看出来可它是渐进式的后面跟前面一混对账的时候光靠人眼扫很容易漏。排查对账脚本把漂移点揪了出来我先写了段对账脚本把它的处理结果跟原始数据逐条比指望它帮我精确标出漂移是从哪一条开始的。// audit.js —— 对账脚本检查 Agent 的输出是否符合约定// 为什么看这段人眼扫几百条会瞎脚本能精确标出从哪一条开始漂移。constfsrequire(fs);constoriginalJSON.parse(fs.readFileSync(./original-orders.json,utf8));constagentOutJSON.parse(fs.readFileSync(./agent-output.json,utf8));letfirstBadIndex-1;constbadAmounts[];consttouchedStock[];for(leti0;ioriginal.length;i){constooriginal[i];constaagentOut[i]||{};// 约定一金额按分返回original 是元Agent 输出应该是 ×100constamountOkMath.round(o.amount*100)a.amountInCents;// 约定二库存字段禁止修改conststockOko.stockQtya.stockQty;if(!amountOk)badAmounts.push(i);if(!stockOk)touchedStock.push(i);if(firstBadIndex0(!amountOk||!stockOk)){firstBadIndexi;}}console.log(总条数:,original.length);console.log(金额单位错误条数:,badAmounts.length);console.log(库存被改条数:,touchedStock.length);console.log(第一条漂移索引:,firstBadIndex);// 运行结果Node 25.8.2 实测对账脚本跑漂移版输出 总条数: 428 金额单位错误条数: 96 库存被改条数: 13 第一条漂移索引: 221看这个位置——任务过半之后开始错的。这个点跟上下文窗口滚满的时间点基本吻合方向一下就清楚了不是模型突然变笨是上下文出了问题。根因早期约定被压缩细节在摘要里丢了长会话跑到后半程上下文窗口会装不下全部历史。真实平台里存在这类自动压缩机制OpenAI 自己也承认长任务会把早期指令和上下文一路带着走Better prompt caching for GPT-6但内部具体怎么压、按什么粒度摘没有公开细节。我这轮演练里没有真的触发官方压缩而是自己动手模拟用摘要模型把早期对话摘成摘要把窗口满了之后会发生什么演出来。摘要这个东西保留事件主干很在行做了什么、做到哪了都能记住但数字、单位、禁止项这种细节恰恰是摘要最容易丢的。“金额按分返回、库存字段禁止修改这两条压缩过后就变成了一句含糊的按之前说的处理订单”。Agent 后续每一步都只看到这份被压过的上下文它以为自己在遵守约定实际上遵守的是摘要里的残影。这跟我上次写的导账翻车不是一回事那次是上下文过期——内容还在但身份已经不对了这次是上下文被压缩——内容还在但细节没了。两种都要命机制完全不同。ASCII 图是压缩前后的对比能看清细节是怎么没的压缩前窗口里 压缩后摘要里 约定一金额一律按分返回原始值×100 → 按之前说的处理订单 约定二库存字段禁止修改任何情况都不许动 → 没了 订单号格式 O-XXXX不许改 → 按之前说的处理订单 库存字段禁止修改任何情况都不许动 → 没了图 1 压缩前后的摘要对比事件主干留下单位与禁止项消失修复把不可丢的约定钉进状态文件发现根因之后修复方向就很明确了约定不能只活在上下文里要写进 Agent 每步都能读到的外部状态跟它执行的每一步绑在一起。我在沙箱后台加了一个约定文件Agent 每处理一条先读一遍约定再动手。// agreements.json —— 修复方案约定固化为状态// 为什么看这段Agent 每步从外部读约定上下文怎么压缩都不影响。{agreements:[{rule:amountInCents,desc:金额按分返回原始值乘以 100},{rule:stockFrozen,desc:库存字段禁止修改任何情况都不得写入},{rule:orderIdFormat,desc:订单号保持 O-XXXX 格式}],checkedAt:2026-09-28}// 运行结果Node 25.8.2 实测加入约定文件后重跑漂移消失 总条数: 428 金额单位错误条数: 0 库存被改条数: 0 第一条漂移索引: -1重跑一遍从头到尾没有一条越界。这就是阶段化的结果你负责把约定放对地方Agent 负责执行。想自己复现这轮实验的读者按下面 5 步走一遍比读任何文章都直观也是我当时确认根因是约定丢了的方法。下面是修复前后的流程对比能看清约定从「活在上下文里」变成「钉进外部状态」后漂移是怎么消失的修复后约定钉进外部状态修复前约定只活在上下文里根因细节在摘要里丢了任务开始交代约定上下文窗口滚满自动压缩细节进摘要Agent 只看到摘要残影后半程漂移金额按元、库存被改agreements.json 固化约定Agent 每步先读约定上下文怎么压缩都不影响从头到尾零漂移图 2 修复前后流程对比把约定从上下文挪到外部状态漂移消失复现步骤第 1 步准备原始订单 JSON 和 Agent 输出 JSON先准备两份数据一份是原始订单original-orders.json金额单位是元含库存字段一份是 Agent 跑出来的输出agent-output.json金额按分返回库存字段应保持不变。没有真实 Agent 输出时可以手动构造一份漂移版——前 220 条守规矩后面故意把金额按元返回、改掉库存字段。# 目录结构repro/ ├── original-orders.json# 原始订单金额单位元├── agent-output.json# Agent 输出金额单位分└── audit.js# 对账脚本第 2 步运行对账脚本 audit.js 得到漂移数据把audit.js放进同一目录执行nodeaudit.js预期输出漂移版总条数: 428 金额单位错误条数: 96 库存被改条数: 13 第一条漂移索引: 221看到第一条漂移索引: 221说明漂移确实存在且从任务过半处开始。第 3 步添加 agreements.json 约定文件在目录里新建agreements.json把约定固化为 Agent 每步都能读到的外部状态{agreements:[{rule:amountInCents,desc:金额按分返回原始值乘以 100},{rule:stockFrozen,desc:库存字段禁止修改任何情况都不得写入},{rule:orderIdFormat,desc:订单号保持 O-XXXX 格式}],checkedAt:2026-09-28}第 4 步重跑 Agent 并再次运行对账脚本验证漂移消失让 Agent 每处理一条订单前先读一遍agreements.json再重跑一遍然后再次执行nodeaudit.js预期输出修复版总条数: 428 金额单位错误条数: 0 库存被改条数: 0 第一条漂移索引: -1第一条漂移索引: -1表示从头到尾没有一条越界漂移消失。第 5 步删除约定文件重跑确认漂移复现删掉agreements.json让 Agent 在无外部约定的情况下重跑再执行一次对账rmagreements.jsonnodeaudit.js预期输出回到漂移版总条数: 428 金额单位错误条数: 96 库存被改条数: 13 第一条漂移索引: 221漂移回来了说明根因确实是约定只活在上下文里被压缩后丢了——加上约定文件就消失删掉就复现这一来一回把因果钉死了。这个修法的边界得说清楚它防的是约定丢失防不了约定被读到了但 Agent 故意打折执行——那属于验证和护栏的范畴是另一套功夫。沙箱里我能让 Agent 每步读约定生产环境要考虑读状态的性能开销和并发写冲突方案要换思路不变。边界压缩不是唯一的翻车原因复盘完整事故得承认几件事。第一压缩丢细节是我这轮演练的主因但长会话翻车还有别的入口任务本身设计得含糊、模型对指令的理解漂移、外部系统状态不一致都可能表现成忘了约定。我这轮根因排查得清楚是因为任务和约定都设计得很干净现实里往往是几个问题叠在一起。第二演练的局限要交代订单是假的、后台是假的、压缩是我用摘要模型模拟的。它演示的是机制不是某个真实平台在某个版本里的具体行为。第三也是最重要的一课别赌 Agent 记得。凡是丢了会办错事的信息一开始就该放在它每步够得到的地方而不是祈祷上下文别滚掉。我不保证这条路能解决所有长会话问题但它能解决我在演练里遇到的那一类——而且这类问题占比不低。参考资料Better prompt caching for GPT-6— https://openai.com/index/better-prompt-caching-for-gpt-6/ — 本文根因一节引用的官方说明讲长任务里早期指令和上下文如何被一路带着走是理解上下文被压缩机制的起点。OpenAI 官方文档上下文压缩机制说明— https://platform.openai.com/docs/guides/context-engineering — 官方对上下文窗口管理、压缩与摘要策略的说明能帮你判断真实平台里窗口满了之后会发生什么。Managing Context in Long-Running Agent Tasks— https://www.anthropic.com/research/building-effective-agents — 一篇关于 Agent 长任务上下文管理的技术文章讨论如何把关键约定放到外部状态里跟本文把不可丢的约定钉进状态文件的修复思路直接对应。
