Agent循环执行机制：上下文管理、检查点与任务恢复实战

1. 从一次任务中断说起：Agent循环执行的真实痛点

很多人第一次接触Agent开发，脑子里想的都是"给它一个目标，它自己跑完就行"。我当初也是这么想的，直到有一次跑一个需要连续调用十几次工具的长任务，跑到第七步的时候模型接口超时，整个流程直接崩掉，前面六步的结果全部丢失，只能从头再来。那次之后我才真正意识到，Agent的"循环执行"从来不是一个while循环那么简单，它背后牵扯的是上下文怎么维护、状态在哪里落盘、任务断了怎么接上、资源怎么不被跑飞这一整套工程问题。

这篇内容就是围绕这套机制展开的。我会把Agent运行时的完整链路拆成几个关键环节：上下文是怎么组织和传递的、检查点到底存什么、任务恢复的判定逻辑是什么、循环执行的控制流怎么设计、资源管控在哪些地方必须设闸。适合已经写过简单Agent Demo、但一跑到长任务就各种翻车的开发者，也适合正在设计Agent框架、需要把稳定性做上去的工程师。读完之后你应该能自己搭出一套"断了能续、跑不飞、上下文不爆"的执行骨架。

需要先说明一点：Agent的运行时机制没有唯一标准答案，不同框架（比如常见的ReAct式循环、Plan-and-Execute式编排、多Agent协作的swarm结构）实现差异很大。下面讲的是我在实际项目中反复验证过的一套通用思路，具体参数和结构你可以按自己的场景调整。

2. 上下文不是聊天记录：Agent执行上下文的真实构成

2.1 上下文窗口里到底装了什么

大部分人把上下文理解成"对话历史"，这在纯聊天场景下没错，但在Agent场景下远远不够。一个正在执行任务的Agent，它的上下文里通常同时存在五类信息，而且这五类信息的生命周期和更新频率完全不同。

第一类是系统指令，也就是定义Agent身份、能力边界、输出格式的那段固定文本。它几乎不变，但每次调用都要带上，属于"常驻开销"。第二类是任务目标，用户给的原始需求，它是整个循环的锚点，任何时候都不能丢。第三类是执行轨迹，也就是到目前为止Agent做了哪些动作、调用了哪些工具、拿到了什么返回。这一类是增长最快的，也是上下文爆炸的主要来源。第四类是工作记忆，比如中间推理结论、临时变量、当前进度标记。第五类是外部检索内容，比如从知识库或文件里拉进来的片段。

我见过不少项目把这几类东西混在一起无脑拼接，结果就是上下文迅速膨胀，模型开始"遗忘"早期指令，或者被大量工具返回的噪声淹没。正确的做法是给每一类分配明确的区域和预算。

2.2 上下文预算的分配逻辑

上下文窗口是有限资源，必须像管内存一样管它。我的经验是按比例切分，而不是等它满了再想办法。一个比较稳的分配思路是这样的：

这个比例不是拍脑袋来的。执行轨迹之所以占大头，是因为它承载了Agent"我做过什么"的认知，一旦丢失，Agent就会重复劳动或者逻辑断裂。但它同时也是最该被压缩的——早期的工具调用细节往往不再重要，可以折叠成一句结论。

提示：不要等上下文用到90%才触发压缩。我一般设在70%就开始做轨迹摘要，留出缓冲，否则一次大的工具返回就可能直接顶爆窗口。

2.3 轨迹压缩的两种做法与取舍

轨迹压缩我常用两种方式。一种是滚动摘要：把最早的若干轮执行记录交给模型，让它总结成一段"到目前为止的进展"，然后用这段摘要替换掉原始记录。另一种是结构化裁剪：不调用模型，直接按规则丢弃冗余字段，比如工具返回的原始JSON只保留关键字段，长文本只留前若干字符加省略标记。

滚动摘要质量高但费token、有延迟，而且摘要本身可能丢信息；结构化裁剪快、确定性强，但可能砍掉后面要用的细节。我的做法是两者结合：对工具返回这种"体积大、信息密度低"的内容用结构化裁剪，对推理过程这种"体积小、信息密度高"的内容用滚动摘要。实测下来这样能把上下文增长速度压到原来的三分之一左右，同时几乎不损失任务成功率。

还有一个容易被忽略的点：压缩后的上下文要保留可回溯的引用。比如摘要里写"已完成数据清洗"，最好带上原始步骤的编号，这样万一后面需要细节，还能按编号去外部存储里捞回来。上下文不是唯一的信息载体，它只是当前工作集。

3. 检查点机制：让Agent在崩溃后还能站起来

3.1 检查点该存什么，不该存什么

检查点（checkpoint）这个词听起来很重，但本质就是"在某个时刻把Agent的状态拍个快照存下来"。问题在于，存什么。我踩过的第一个坑就是什么都存，把整个上下文、所有工具返回、全部中间变量一股脑序列化，结果检查点文件巨大，写入还慢，反而拖垮了执行。

后来我总结出一个原则：检查点存的是"能重建执行现场的最小集合"，而不是"当前所有数据"。具体来说，至少要包含这几项：

• 任务标识与目标：用来确认恢复的是哪个任务。
• 当前步骤序号与阶段：Agent走到哪一步了。
• 已完成步骤的结果摘要：不是原始返回，是提炼后的结论。
• 待执行的动作队列：如果任务是规划式的，下一步要做什么。
• 关键变量快照：那些后续步骤依赖的中间结果。
• 上下文摘要：压缩后的执行轨迹，用于恢复认知。

不需要存的：完整的原始工具返回（放外部存储，检查点里只留引用）、模型的临时推理草稿、可以重新计算得到的派生数据。

3.2 检查点的触发时机

什么时候打检查点，直接决定了恢复的粒度和开销。全量高频打点会让性能崩掉，打得太稀又会导致恢复时丢失太多进度。我实践下来有三个触发点比较合理。

第一个是每个"原子步骤"完成后。所谓原子步骤，就是一次工具调用加一次结果处理，这个粒度既不会太细也不会太粗。第二个是上下文压缩前后，因为压缩改变了状态结构，这时候打点能保证恢复时上下文是一致的。第三个是高风险操作之前，比如要执行一个可能失败的外部调用、要写入关键数据之前，先存一份，失败了能回退。

打点本身要异步化。如果同步写检查点，每次都要等磁盘IO，长任务会被拖得很慢。我的做法是主流程继续跑，检查点写入放到后台队列，但要保证"步骤N的检查点一定在步骤N+1开始前落盘"，否则恢复时会错位。

3.3 检查点的存储选型

存储介质的选择取决于任务时长和恢复要求。短任务（几分钟内）用内存加本地文件就够了；长任务（小时级甚至跨天）建议用带事务的外部存储，比如关系型数据库或者对象存储加索引。

这里有个细节：检查点要带版本号和校验。我遇到过检查点写了一半进程被杀，恢复时读到一个损坏的文件，直接报错。后来加了写入时的临时文件加原子重命名，以及读取时的校验和验证，才彻底解决。另外检查点要能区分"完整快照"和"增量快照"，长任务里全量快照太贵，增量快照只记录自上次以来的变化，恢复时按顺序重放。

4. 任务恢复：判断"能不能续"比"怎么续"更难

4.1 恢复前的状态校验

任务恢复最危险的不是恢复失败，而是恢复到了一个错误的状态还继续跑。比如检查点记录的是步骤7，但实际外部副作用（比如已经发出的请求、已经写入的数据）可能已经执行到了步骤8，这时候盲目从步骤7续，就会重复执行。

所以恢复的第一步永远是校验，而不是直接加载。校验要回答三个问题：检查点是否完整可信、外部世界是否与检查点一致、任务目标是否还有效。第三个问题经常被忽略——用户可能已经取消了任务，或者目标已经过期，这时候恢复就是浪费资源。

外部一致性校验比较麻烦，通常靠幂等设计来兜底。也就是说，让每个步骤都可以安全地重复执行。比如写数据用唯一键去重，发请求带幂等token。这样即使恢复时重复跑了某一步，也不会造成副作用。这是比精确校验更省心的方案。

4.2 恢复点的选择策略

不是所有情况都从最后一个检查点恢复。我一般分三种策略：

• 从最近检查点续跑：适用于步骤之间无强依赖、副作用幂等的情况，最省事。
• 回退到某个安全点重跑：当最近检查点之后的操作可能产生了不一致副作用时，回退到更早的、确定干净的点。
• 重新规划：当环境变化太大，原计划已经不可行时，保留目标，丢弃执行轨迹，让Agent重新规划路径。

选择哪种，取决于任务的可重入性。可重入性高的任务（比如纯信息检索、纯计算）大胆续跑；可重入性低的任务（比如有外部写操作、有顺序依赖）保守回退。

4.3 恢复时的上下文重建

恢复不只是加载状态，还要把Agent的"认知"重建起来。这里有个坑：如果只恢复变量不恢复上下文，Agent会"失忆"，不知道自己之前做过什么，容易重复劳动。所以恢复时要做的第一件事，是把检查点里的上下文摘要重新注入，并且明确告诉Agent"你是从步骤N恢复的，之前已经完成了这些"。

我通常会在恢复后的第一条系统消息里加一段恢复说明，格式大概是：任务从第N步恢复，已完成步骤的结论如下，请在此基础上继续。这样Agent的行为会连贯很多。实测下来，加了恢复说明比不加，重复调用工具的概率能降一半以上。

5. 循环执行的控制流：别让Agent跑成死循环

5.1 循环的终止条件设计

Agent的主循环看起来是"思考-行动-观察"不断重复，但必须有明确的终止条件，否则就是无限烧钱。终止条件我一般设四类，任何一类触发就停：

第一类是任务完成，Agent明确输出最终结果。第二类是达到最大步数，这是硬性兜底，防止跑飞。第三类是连续无进展，比如连续几步都没有产生新的有效信息，说明卡住了。第四类是资源耗尽，token预算或时间预算用完。

最大步数这个值怎么定？我的经验是按任务复杂度估，简单任务10-15步，中等任务30-50步，复杂任务可以到100步以上，但一定要有。我见过没设上限的Agent，因为一个工具一直返回错误，它就一直重试，一晚上烧掉大量额度。

5.2 无进展检测的实现

"连续无进展"是最难判断但最有价值的终止条件。我的实现方式是给每一步算一个"信息增益"：如果这一步产生了新的工具调用结果、新的结论、或者状态发生了实质变化，就算有进展；如果只是重复之前的动作、或者返回内容和之前高度相似，就算无进展。

具体可以用简单的启发式：比较当前动作和最近几步动作的相似度，如果高度重复就计数；或者看工作记忆有没有新增有效条目。连续三次无进展就触发终止，并让Agent输出"我卡住了，原因是……"，这样至少能拿到一个可诊断的结果，而不是静默失败。

5.3 循环中的错误处理与重试

工具调用失败是常态，不能一失败就整个任务崩。我的做法是分级处理：可重试错误（网络超时、限流）自动重试，带指数退避；不可重试错误（参数错误、权限不足）不重试，直接把错误信息喂回给Agent，让它自己决定换方案还是放弃；致命错误（认证失效、依赖服务宕机）触发检查点保存并暂停任务，等待人工介入或定时恢复。

重试次数要设上限，我一般设3次，超过就升级为不可重试。这里的关键是把错误信息结构化地反馈给Agent，而不是丢一个原始堆栈。Agent需要知道"错在哪、能不能自己修"，原始堆栈对它没用。

6. 资源管控：给Agent套上缰绳

6.1 Token预算的分层控制

Token是Agent最直接的资源成本，必须分层管控。我在三个层级设预算：单次调用预算（一次模型调用最多用多少token）、单步预算（一个步骤内所有调用加起来的上限）、任务总预算（整个任务的上限）。任何一层超了都要有动作。

单次调用超了，说明上下文太大，触发压缩；单步超了，说明这一步设计有问题，可能要拆分；任务总预算快到了，就要提醒Agent"资源紧张，请尽快收敛"，或者直接进入收尾流程。这种分层控制比只设一个总数要精细得多，能提前发现问题而不是最后才发现超支。

6.2 并发与速率控制

如果Agent会并发调用工具或者并发跑子任务，速率控制就很重要。无节制的并发会打爆下游服务，也会让成本失控。我的做法是给每类外部依赖设一个并发上限和QPS上限，用信号量或令牌桶控制。

对于多Agent协作的场景，还要控制Agent数量。我见过一个任务动态生成了几十个子Agent，每个都在调模型，成本瞬间爆炸。所以子Agent的创建要有配额，并且要有回收机制，用完就销毁，不能一直挂着。

6.3 超时与熔断

每个外部调用都要有超时，这是底线。超时时间按依赖的响应特征设，快的设几秒，慢的设几十秒，但绝不能无限等。超时后按可重试错误处理。

熔断是针对"某个依赖持续失败"的情况。如果某个工具连续失败超过阈值，就暂时把它熔断，不再调用，直接让Agent走备选方案。这样能避免Agent在一个已经挂掉的服务上反复撞墙，浪费大量步骤和token。

7. 把这几块拼起来：一个可落地的执行骨架

7.1 主循环的伪代码结构

把前面几块拼起来，主循环大致长这样（伪代码，语言无关）：

def run_agent(task, checkpoint_store, budget): state = load_or_init(task, checkpoint_store) while not state.finished: if budget.exhausted(): state.finish("budget_exhausted") break if state.step_count > MAX_STEPS: state.finish("max_steps") break if state.no_progress_count >= 3: state.finish("stuck") break context = build_context(state) # 组装上下文 if context.usage() > 0.7: context = compress(context) # 压缩 save_checkpoint(state, context) # 压缩后打点 action = model.decide(context) # 模型决策 result = execute_with_retry(action) # 执行+重试 state.update(action, result) # 更新状态 if is_atomic_step(action): save_checkpoint(state, context) # 原子步骤后打点

这个骨架里，检查点、压缩、预算、无进展检测都嵌在循环里，各司其职。实际实现时，save_checkpoint要异步，execute_with_retry要带超时和熔断，build_context要按前面说的分区组装。

7.2 恢复入口的伪代码

恢复逻辑单独一个入口：

def resume_agent(task_id, checkpoint_store): cp = checkpoint_store.load_latest(task_id) if not cp or not cp.verify(): return run_agent_from_scratch(task_id) if not external_state_consistent(cp): cp = checkpoint_store.load_safe_point(task_id) state = rebuild_state(cp) state.context = inject_recovery_note(state.context, cp.step) return run_agent(state, checkpoint_store, state.budget)

关键在external_state_consistent和inject_recovery_note这两步，前者保证不会重复副作用，后者保证Agent不失忆。

7.3 几个必须监控的指标

上线之后，这几个指标要盯着：平均步数（突然变高说明Agent在绕路）、检查点写入延迟（变高说明存储扛不住）、恢复成功率（低于预期说明校验或幂等有问题）、token消耗分布（看钱花在哪了）、无进展终止率（高说明任务设计或工具质量有问题）。这些指标能帮你在问题变大之前发现苗头。

8. 几个我踩过的坑和对应的解法

第一个坑是检查点太频繁导致性能下降。一开始我每个工具调用都同步写检查点，结果长任务跑得奇慢。解法是异步写加批量落盘，并且只在原子步骤边界打点。

第二个坑是恢复后Agent重复劳动。原因是只恢复了变量没恢复上下文，Agent不知道自己做过了。解法是注入恢复说明，明确告知进度。

第三个坑是上下文压缩把关键信息压没了。有一次摘要把某个关键参数丢了，导致后续步骤全错。解法是压缩时对"关键变量"打标记，强制保留，不参与摘要。

第四个坑是没有无进展检测，Agent在一个坏工具上死磕。解法就是前面说的信息增益判断加连续无进展终止。

第五个坑是预算只在最后检查，超了才发现。解法是分层预算加实时监控，快超时提前预警。

这些坑的共同点是：它们都不会在Demo阶段暴露，只有任务变长、变复杂、跑在真实环境里才会出现。所以如果你打算把Agent用到生产，这几块机制一个都不能省。

最后分享一个我个人的习惯：每次设计一个新的Agent任务，我都会先故意在中间制造一次中断，看它能不能正确恢复。这个"破坏性测试"比任何单元测试都管用，能提前把恢复逻辑的漏洞逼出来。跑通几次之后，你对这套机制的理解会比看十篇文档都深。