1. 从一次线上事故说起为什么Agent的记忆和恢复比模型能力更致命去年冬天我接手过一个内部工单系统的Agent改造项目模型用的是当时第一梯队的大参数版本提示词打磨了两周单轮对话效果相当漂亮。上线第三天凌晨运维群里炸了——一个批量处理工单的Agent在跑到第47个任务时突然卡死重启后从第1个任务重新开始把已经处理过的工单又跑了一遍重复触发了十几条通知。更糟的是它当时正在调用的一个外部接口有频率限制重启后的重放直接把配额打满后续所有任务全部失败。那次事故让我彻底明白一件事Agent能不能用取决于模型Agent能不能稳定跑取决于上下文管理、检查点设计和任务恢复机制。这三样东西做不好模型再强也只是个演示玩具。后来我把这套运行机制重新梳理了一遍从上下文怎么组织、检查点什么时候落盘、任务怎么断点续跑到循环执行怎么防止失控、资源怎么管控形成了一套可以复用的完整流程。这篇就把这套东西拆开讲透不管你是刚接触Agent开发还是已经在做企业级编排应该都能从中拿到能直接抄的东西。需要先明确一点这里说的Agent指的是那种能自主规划、调用工具、多步执行直到完成目标的智能体不是单轮问答的聊天机器人。它的核心特征是有状态、有循环、有外部副作用。有状态意味着上下文会累积有循环意味着可能跑飞有副作用意味着重复执行会造成真实损害。这三点决定了它的运行机制必须比普通LLM应用复杂一个量级。2. 上下文不是聊天记录Agent执行上下文的四层结构很多人第一次做Agent会把上下文简单理解成把历史消息拼起来喂给模型。这个理解在单轮对话里没问题放到Agent里会立刻崩掉。因为Agent的上下文里混着好几类性质完全不同的信息它们的生命周期、更新频率、容量占用都不一样混在一起管理必然出问题。2.1 系统指令层最稳定但最容易被稀释系统指令层包含角色定义、行为约束、工具使用规范、输出格式要求。这部分内容在整个任务生命周期里基本不变但它有个致命问题随着对话轮次增加它会被后面的内容稀释。模型对上下文的注意力不是均匀分布的越靠前的内容越容易被忽略。我实测过一个场景系统提示里写了调用支付接口前必须二次确认跑到第30轮时模型直接跳过了确认步骤。后来我把这条约束在每轮的工具调用结果里重复注入了一次问题才解决。所以系统指令层的管理原则是核心约束不能只放在开头要在关键节点重复强化。具体做法是在工具返回结果的结构里固定带一个constraints_reminder字段把当前步骤最相关的约束再提一遍。这看起来冗余但实测能显著降低长任务里的指令遗忘率。2.2 任务状态层Agent的工作记忆任务状态层记录的是当前任务的进展已经完成了哪些子步骤、当前处于哪个阶段、有哪些中间结果。这部分是Agent区别于普通对话的核心也是检查点要持久化的主要对象。我习惯把任务状态设计成一个显式的结构化对象而不是让它散落在对话历史里。比如一个处理订单的Agent它的状态对象大概长这样{ task_id: order_20240115_001, stage: verify_payment, completed_steps: [parse_order, check_inventory, reserve_stock], pending_steps: [verify_payment, generate_invoice, notify_customer], intermediate_results: { order_amount: 1280.00, inventory_status: reserved }, retry_count: 0 }为什么要显式化因为只有显式状态才能被可靠地序列化、恢复和审计。如果状态藏在自然语言的对话历史里恢复时你得让模型重新读懂自己之前干了什么这个过程既慢又不可靠。显式状态对象可以直接反序列化Agent一启动就知道自己站在哪。2.3 工具交互层最容易撑爆上下文的部分工具调用返回的结果往往是上下文中体积最大的部分。一次网页抓取可能返回几万token的HTML一次数据库查询可能返回几百行记录。如果把这些原样塞进上下文几轮下来窗口就满了。我的处理策略是分级截断加摘要工具返回结果先经过一个预处理层超过阈值的内容做结构化摘要只保留关键字段和结论原始数据存到外部存储上下文里只放一个引用ID。需要细节时再按ID回查。这样上下文里始终是轻量索引而不是全量数据。这里有个坑要提醒摘要不能随便让模型生成因为模型摘要可能丢关键信息。我的做法是对结构化数据用规则摘要比如只保留状态码、金额、ID这些字段对非结构化文本才用模型摘要并且摘要结果要带上原文的引用方便追溯。2.4 对话历史层需要主动遗忘的部分对话历史层就是常规的user/assistant消息。在Agent场景里这部分增长最快也最需要主动管理。我的经验是不要等窗口满了才做压缩而是按任务阶段做滚动清理。每完成一个子任务就把这个子任务内部的详细对话压缩成一条结论性的消息只保留输入输出和关键决策。举个具体例子Agent在查询库存这个子任务里可能和工具来回交互了5轮完成后我把这5轮压缩成一条库存查询完成商品A库存充足剩余230件商品B库存紧张剩余8件。这样既保留了结论又释放了大量空间。提示上下文压缩的时机很关键。不要在任务执行中途压缩因为中途压缩可能丢掉当前步骤需要的细节。最佳时机是子任务边界此时上一个子任务的细节已经不再需要压缩不会影响后续执行。这四层结构理清楚之后上下文管理就从拼字符串变成了分层治理每一层有自己的更新策略和容量预算整体可控性会好很多。3. 检查点设计决定Agent能否死而复生的关键检查点这个概念在传统工作流里很常见但搬到Agent上很多人不知道该怎么设计。我见过最常见的错误做法是每轮对话结束就存一次全量状态结果存储压力巨大而且恢复时不知道该从哪个检查点续跑。3.1 检查点该存什么最小可恢复集检查点的核心目标是让Agent能从任意一个检查点恢复到一致的状态并继续执行。所以它要存的是最小可恢复集而不是全部信息。我总结的最小集包含四样东西任务状态对象就是上一节说的结构化状态包含阶段、已完成步骤、中间结果上下文快照当前上下文的分层内容重点是系统指令和任务状态层执行位置标记精确到当前正在执行哪个步骤、下一步该做什么副作用记录已经产生的外部副作用清单用于恢复时去重第四点特别重要也是最多人忽略的。Agent调用外部接口、写数据库、发消息这些都是副作用。恢复时如果不记录哪些副作用已经发生就会重复执行。我那次工单事故的根本原因就是没有副作用记录重启后全部重放。3.2 检查点的触发时机不是越频繁越好检查点存得太频繁存储和序列化开销会拖慢整个流程存得太稀疏恢复时丢失的进度太多。我的经验是按副作用边界来触发检查点而不是按轮次。具体来说在以下时机落检查点完成一个会产生外部副作用的操作之后比如成功调用了一次支付接口进入一个可能长时间运行的步骤之前比如等待外部系统回调完成一个子任务、准备进入下一个子任务时达到预设的轮次阈值时作为兜底防止长时间无检查点这样设计的逻辑是检查点的价值在于副作用不重复所以它必须紧贴副作用发生的位置。纯计算步骤之间不需要频繁存因为重算成本低有副作用的步骤之间必须存因为重放成本高甚至不可逆。3.3 检查点的存储选型别用文件用带版本的结构化存储早期我用本地JSON文件存检查点简单是简单但很快遇到问题并发任务时文件锁冲突、恢复时读到写了一半的脏数据、多实例部署时文件不共享。后来换成带版本号的结构化存储关系库或KV存储都行问题基本消失。关键设计是检查点要带版本号和任务ID做联合主键每次写入是追加而不是覆盖。这样既能追溯历史又能在恢复时选择最新的完整版本。下面是一个简化的表结构参考字段类型说明task_idstring任务唯一标识checkpoint_versionint递增版本号stagestring当前阶段state_payloadjson任务状态对象context_snapshotjson上下文快照side_effectsjson已发生的副作用清单created_attimestamp落盘时间is_completebool是否为完整检查点is_complete这个字段是防止读到脏数据的关键。写入时先写is_completefalse全部字段写完后更新为true恢复时只读is_completetrue的最新版本。3.4 恢复时的状态校验别盲目信任检查点恢复不是简单地把检查点读出来接着跑中间要做校验。我踩过的坑是检查点存的时候任务状态是库存已预留但恢复时库存预留可能已经超时释放了直接续跑会导致后续步骤基于错误前提执行。所以恢复流程里必须加一步状态重校验把检查点里的关键状态和外部系统的真实状态做一次比对不一致的话要么修正状态要么回退到更早的检查点。这一步看起来麻烦但能避免大量看起来在跑其实全错的隐性故障。4. 任务恢复的完整链路从崩溃到续跑的每一步任务恢复是检查点机制的落地环节。设计得好的恢复流程应该做到崩溃对用户无感——任务自己爬起来接着跑用户只看到稍微慢了一点。下面把这条链路拆成几个阶段讲。4.1 崩溃检测怎么知道任务挂了恢复的前提是检测到任务异常。常见的检测方式有三种心跳超时、进程退出信号、外部健康检查。我一般组合使用Agent执行过程中定期更新一个心跳时间戳监控侧发现心跳超过阈值没更新就判定为疑似崩溃同时进程退出时捕获信号主动标记任务状态。这里有个细节心跳阈值不能设太短。Agent调用外部接口可能本身就要几十秒如果心跳阈值设成30秒正常的长调用会被误判为崩溃触发不必要的恢复。我的经验值是设成最长单步耗时的2到3倍并且允许动态调整。4.2 恢复决策续跑、重跑还是放弃检测到崩溃后不是无脑恢复而是要做决策。决策依据主要是检查点的完整性和副作用的可逆性情况检查点状态副作用情况恢复策略正常崩溃有完整检查点副作用已记录从最新检查点续跑检查点损坏最新版本不完整未知回退到上一个完整检查点无可用检查点全部损坏未知从头重跑但需清理副作用副作用不可逆有检查点已产生不可逆副作用人工介入不自动恢复最后一行是关键如果已经产生了不可逆的副作用比如已经发了消息、已经扣了款自动恢复可能造成重复副作用这时候必须转人工。这个判断逻辑要写死在恢复流程里不能靠模型自己判断。4.3 续跑执行状态注入与上下文重建确定续跑后要做三件事把检查点里的任务状态注入到Agent、重建上下文、从执行位置标记处继续。上下文重建有个技巧不要恢复完整的对话历史只恢复系统指令层和任务状态层对话历史层用一条摘要代替。因为历史对话的细节对续跑通常没用反而占空间。摘要内容就是任务此前已完成X、Y、Z步骤当前处于某阶段让模型快速进入状态。状态注入时要注意幂等性。续跑的步骤如果之前可能已经部分执行过要保证重复执行不会产生额外副作用。这通常靠副作用记录来实现执行前先查副作用清单已存在的操作直接跳过。4.4 恢复后的验证确认真的接上了续跑启动后不能就不管了要验证恢复是否成功。我的做法是在续跑的前几个步骤加一个验证窗口观察Agent的行为是否符合预期状态是否正确、工具调用是否合理、有没有重复副作用。如果验证窗口内发现异常立即中止并转人工避免错误扩散。这个验证窗口的另一个作用是收集恢复质量数据。长期看恢复成功率、恢复后任务完成率这些指标能反映检查点设计是否合理是持续优化的依据。5. 循环执行Agent的永动机怎么装刹车Agent的循环执行是它强大的来源也是它危险的来源。一个没有刹车机制的循环轻则烧光token预算重则陷入死循环反复调用外部接口。这一节讲怎么给循环装上可靠的刹车。5.1 循环的三种终止条件健康的Agent循环应该有明确的终止条件而不是跑到模型觉得完成为止。我一般设置三重终止目标达成终止模型明确输出任务完成信号且状态校验通过步数上限终止达到预设的最大步数强制停止并标记为未完成资源耗尽终止token预算、时间预算或调用次数预算耗尽强制停止三重条件里步数上限是最重要的兜底。因为模型可能因为各种原因提示词歧义、工具返回异常、状态判断错误一直觉得还没完成如果没有步数上限它就会一直跑下去。我的经验值是设成预估正常步数的3倍既给足余量又能及时止损。5.2 死循环的识别重复模式检测步数上限是最后一道防线但等到触发上限时可能已经浪费了大量资源。更好的做法是在执行过程中实时识别死循环模式。常见的死循环模式有两种第一种是相同工具相同参数反复调用。比如Agent反复用同样的参数查同一个接口说明它没意识到这个操作已经做过了。检测方法是维护一个近期调用记录发现连续N次调用签名相同就告警。第二种是状态在几个值之间来回跳。比如阶段从A到B又回到A来回震荡。检测方法是记录阶段变迁序列发现周期性震荡就介入。识别到死循环后处理方式不是直接终止而是注入一条纠正提示告诉模型你刚才重复了某个操作请检查是否已经完成或换一种方式。很多时候模型只是卡住了一句提示就能拉回来。如果提示后仍然重复再终止。5.3 循环中的上下文膨胀控制循环执行会让上下文快速膨胀这是必然的。控制手段除了前面说的分层压缩还有一个关键技巧每轮循环开始时做一次上下文预算检查。如果当前上下文占用超过窗口的某个比例我一般设70%就触发一次主动压缩把已完成子任务的细节清掉。这个主动压缩和被动压缩窗口满了才压的区别在于主动压缩有充足的预算做高质量的摘要被动压缩往往只能粗暴截断丢信息。所以宁可提前压不要等到满了再压。5.4 循环的可观测性让每一步都看得见循环执行最怕的是黑盒跑飞所以可观测性必须做足。我要求Agent的每一轮循环都输出结构化的执行日志包含当前步数、当前阶段、调用的工具、工具返回摘要、状态变化、剩余预算。这些日志汇总起来就能画出任务的完整执行轨迹。有了轨迹排查问题就简单了。任务失败时直接看轨迹就能定位到是哪一步开始跑偏的不用去猜。这套日志我一般还会接一个简单的可视化把轨迹画成时间线一眼就能看出哪里卡住了、哪里重复了。6. 资源管控别让一个Agent拖垮整个系统Agent的资源消耗比普通LLM应用高得多因为它要循环、要调工具、要维护状态。如果不做管控一个失控的Agent可能吃掉大量token预算、占满外部接口配额、拖慢整个系统。这一节讲资源管控的几个层面。6.1 Token预算按任务分配按阶段扣减Token是Agent最直接的资源。我的做法是给每个任务分配一个token预算执行过程中按阶段扣减。预算分配的依据是任务复杂度简单任务给少点复杂任务给多点。扣减时记录每个阶段消耗了多少方便事后分析哪里最费token。预算快耗尽时要提前预警让Agent有机会收尾——比如把当前步骤做完、把状态存好而不是跑到一半被硬切断。这个优雅降级的设计能显著减少半成品任务。6.2 外部调用配额限流加熔断Agent调用外部接口是最容易出问题的地方。我的做法是在Agent和外部接口之间加一层调用网关统一做限流和熔断。限流保证不超过接口的频率限制熔断保证接口异常时不会无限重试拖垮系统。网关还要做调用去重同一个任务在短时间内对同一个接口的相同调用直接返回缓存结果不真正发起请求。这既能省配额又能防止Agent因为状态判断错误而重复调用。6.3 并发控制Agent数量不是越多越好多个Agent并发执行时资源竞争会变得复杂。我的经验是并发数要按最稀缺的资源来定而不是按CPU或内存。如果外部接口的配额是瓶颈那并发数就不能超过配额能支撑的数量如果token预算是瓶颈就按预算总量除以单任务平均消耗来定。并发控制还要考虑任务优先级。重要的任务优先分配资源不重要的任务排队等待。这个优先级机制在资源紧张时特别有用能保证关键任务不被低优先级任务挤掉。6.4 资源使用的审计与优化资源管控不是设完限额就完了还要持续审计和优化。我会定期分析资源使用数据找出消耗大户是哪个阶段最费token、是哪个工具调用最频繁、是哪种任务最容易超预算。找到之后针对性优化比如优化提示词减少token、给高频工具加缓存、给易超预算的任务调整策略。这套审计机制跑起来之后资源使用效率通常能提升30%以上而且能提前发现异常消耗避免小问题演变成大故障。7. 把整套机制串起来一个可复用的Agent运行时骨架前面几节分别讲了上下文、检查点、恢复、循环、资源管控这一节把它们串成一个完整的运行时骨架方便你直接参考落地。7.1 运行时主循环的伪代码结构def run_agent(task): state load_or_init_state(task) context build_context(state) while not is_terminated(state): check_resource_budget(state) check_context_budget(context) action model_decide(context, state) if action.is_tool_call: result execute_with_gateway(action) record_side_effect(state, action) context update_context(context, action, result) state update_state(state, action) if should_checkpoint(state): save_checkpoint(state, context) if detect_loop_pattern(state): inject_correction(context) return finalize(state)这个骨架的关键在于每个环节都有对应的管控点资源预算检查、上下文预算检查、副作用记录、检查点落盘、循环检测。这些管控点不是可选项而是保证Agent稳定运行的必要组件。7.2 各机制的协同关系这几个机制不是孤立的而是互相配合的。上下文管理为检查点提供快照内容检查点为恢复提供状态基础恢复依赖副作用记录做去重循环控制依赖上下文预算做压缩触发资源管控为整个循环提供边界。任何一个环节缺失整体稳定性都会下降。我见过不少项目只做了其中一两样结果就是能跑但不敢上生产。比如只做了检查点没做副作用记录恢复时会重复副作用只做了循环控制没做资源管控循环是停了但预算已经烧光。所以这套东西要成套用不能挑着用。7.3 落地时的优先级建议如果你现在要从零搭一套我建议按这个优先级来先做资源管控和循环终止保命再做检查点和恢复保稳定最后做上下文分层优化保效率。前两样是底线没有它们Agent根本不能上生产第三样是优化有了它Agent才能跑得久、跑得省。这个优先级是我踩过坑之后总结的。早期我总想着先把上下文优化做到极致结果基础管控没做好一上量就出事故。后来调整顺序先把保命的东西做扎实再慢慢优化效率整个过程稳多了。8. 几个反复踩到的坑和对应的处理经验最后分享几个我在实际项目里反复踩到的坑都是文档里不会写、但实际会遇到的。第一个坑是检查点序列化时的循环引用。任务状态对象里如果存了工具客户端的引用序列化时会报错或者产生巨大体积。解决办法是状态对象只存纯数据所有运行时依赖客户端、连接池在执行时动态注入不进状态。第二个坑是恢复后模型失忆。续跑时如果只注入状态不注入上下文模型会不知道自己之前在干什么行为变得很奇怪。解决办法是恢复时除了状态还要注入一段简短的任务背景摘要让模型快速进入角色。第三个坑是副作用记录和实际副作用不一致。有时候副作用记录写了但实际没执行成功比如接口返回失败但记录已经写了恢复时就会漏执行。解决办法是副作用记录要区分已确认和已发起两种状态只有确认成功的才算数。第四个坑是并发任务共享检查点存储时的写冲突。多个任务同时写检查点如果存储层没做好隔离会互相覆盖。解决办法是检查点按任务ID分区每个任务只写自己的分区物理隔离。第五个坑是资源预算的统计口径不一致。不同环节统计token的方式不一样导致预算判断失准。解决办法是统一在模型调用层做统计所有消耗都从这一个口子出保证口径一致。这些坑单看都不复杂但组合起来就是Agent能跑但跑不稳的根源。把每一个都处理掉Agent的稳定性会有质的提升。我现在做新项目基本会把这五条作为上线前的检查清单逐条确认能省掉大量后期救火的时间。
