1. 从一次任务中断说起Agent循环执行的真实痛点凌晨两点我盯着日志里那行agent execution terminated due to error发呆。一个跑了四十多分钟的数据处理任务在第三十七步调用外部接口时超时整个 Agent 直接挂掉。更让人崩溃的是重启之后它从第一步重新开始前面三十多步的中间结果全部丢失token 白烧时间白费。这个场景我相信做 Agent 开发的人都遇到过。很多人把 Agent 想得太简单觉得无非就是大模型 工具调用 循环写个 while 循环把模型输出解析一下、执行工具、把结果塞回上下文看起来就完事了。但真正上线跑起来你会发现上下文会爆、任务会断、资源会失控、循环会跑飞。这四个问题不解决Agent 永远只能停在 demo 阶段。这篇内容我想把 Agent 的运行机制彻底拆开讲一遍核心围绕四件事上下文怎么管、检查点怎么打、任务怎么恢复、循环和资源怎么控。这不是一篇概念科普而是我踩了无数坑之后总结出来的一套可落地的运行流程。不管你是刚接触 agent 开发的新手还是已经在搭 agent 框架的老手应该都能从里面找到能直接抄作业的东西。先说清楚适用场景任何需要多步执行、长时运行、调用外部工具的 Agent 都适用比如自动化数据处理、代码生成与调试、多轮信息检索、复杂工作流编排。如果你只是做单轮问答那确实用不上这些。但只要你的 Agent 需要跑超过十步下面这些机制你迟早都得补上。2. 上下文不是越大越好分层管理与压缩策略2.1 上下文窗口的物理限制与成本账先算一笔账。假设你用的是一个 128K 上下文窗口的模型一次 Agent 任务平均跑 50 步每步工具返回结果平均 2000 token模型自己的推理输出平均 500 token。那么光是工具结果就是 10 万 token加上系统提示词、历史对话、任务描述很容易就顶到窗口上限。窗口满了会怎样两种结局要么框架直接报错提示你上下文超限要么框架悄悄做了截断把最早的内容丢掉结果模型失忆开始重复之前已经做过的步骤或者忘记任务目标。后者更可怕因为它不报错你根本不知道它已经在瞎跑了。成本账也得算。上下文长度直接决定每次调用的输入 token 数而输入 token 是计费的。一个不做任何上下文管理的 Agent跑到后期每步都要把前面所有历史重新喂一遍token 消耗是平方级增长的。我实测过一个任务做好上下文压缩之后总 token 消耗从 180 万降到了 42 万直接省了四分之三。所以上下文管理的目标很明确在保证模型能拿到完成任务所需信息的前提下把上下文压到最小。这不是可选项是必选项。2.2 上下文分层把信息按保质期分开存我的做法是把上下文分成四层每层有不同的生命周期和压缩策略。层级内容生命周期压缩策略系统层角色设定、工具定义、输出格式约束全程不变不压缩固定前缀任务层任务目标、验收标准、关键约束全程保留精简表述去冗余记忆层已完成步骤的结论、关键中间结果滚动更新摘要压缩只留结论工作层当前步骤的输入、工具返回、临时推理单步有效用完即弃系统层和任务层是锚点必须全程稳定存在否则模型会跑偏。记忆层是核心它承载了我之前干了什么、得到了什么的信息但不需要保留每一步的完整原文只需要保留结论和关键数据。工作层是临时的当前步骤处理完有用的结论提炼进记忆层原始内容就可以丢掉。这个分层的好处是压缩的时候你知道该动哪一层。工作层随便丢记忆层做摘要系统层和任务层碰都不碰。2.3 摘要压缩的实操细节记忆层的压缩我一般用滚动摘要的方式。具体做法是每完成 N 步我通常设 N5就把这 5 步的完整记录交给模型让它生成一段不超过 300 字的摘要包含做了什么、得到什么关键结果、有什么遗留问题。然后把这 5 步的原始记录从上下文里删掉换成这段摘要。这里有个坑摘要不能只让模型自由发挥必须给它结构化模板。我早期就是直接说总结一下这几步结果模型总结得天花乱坠关键的数据和 ID 全丢了后面步骤要用的时候找不到。后来我改成固定模板已完成步骤摘要 - 步骤范围第 X 步到第 Y 步 - 关键产出[具体的数据、文件路径、ID、结论] - 遇到的问题[如果有] - 对后续步骤的影响[如果有]强制模型按这个格式填关键信息就不会丢。另外摘要生成本身也要消耗 token所以别太频繁5 到 10 步一次比较合适。还有一个技巧关键数据单独存一份外部记忆。比如任务过程中生成的临时文件路径、数据库记录 ID、API 返回的关键字段这些不要只放在上下文里而是写到一个结构化的状态对象里需要的时候直接注入不依赖模型记忆。这样即使上下文被压缩关键数据也不会丢。2.4 上下文注入顺序的讲究很多人忽略了一点上下文里信息的排列顺序会影响模型的表现。同样一段内容放在开头和放在结尾模型的注意力分配是不一样的。我的经验是系统提示词放最前面任务目标紧随其后然后是压缩后的记忆层摘要最后才是当前步骤的工作内容。这样模型每次调用时先看到我是谁、要干什么再看我干到哪了最后看现在这一步要做什么逻辑链条是顺的。反过来如果把当前步骤的内容放最前面模型容易被细节带偏忘了整体目标。这个顺序问题在长任务里特别明显我调过好几次才找到这个相对稳定的排列。3. 检查点机制让Agent的每一步都可回溯3.1 检查点到底该存什么检查点这个词听起来很工程化但说白了就是给 Agent 的运行状态拍快照。问题是快照要拍哪些东西我见过有人只存了对话历史结果恢复的时候发现工具调用的中间状态没了得重新调一遍。也见过有人把整个内存对象序列化存下来结果状态对象里有个不可序列化的句柄直接报错。经过几次迭代我现在固定存这几样东西任务元信息任务 ID、创建时间、当前状态运行中/暂停/失败/完成步骤计数器当前执行到第几步这个必须精确上下文快照压缩后的记忆层 当前任务层注意是压缩后的不是全量外部状态引用所有外部资源的引用比如文件路径、数据库记录 ID、临时存储的 key而不是资源本身工具调用记录最近若干步的工具调用参数和结果用于恢复后判断这一步到底做没做错误信息如果是失败触发的检查点记录错误类型和堆栈关键原则是存引用不存实体存结论不存过程。检查点要轻量否则每次存盘都是性能负担。3.2 触发时机什么时候打检查点检查点不是越频繁越好太频繁影响性能太稀疏恢复代价大。我的策略是事件驱动 定期兜底结合。事件驱动的触发点包括每个步骤完成后这是最基本的保证任何一步失败都能从上一个成功步骤恢复调用外部工具前因为外部调用是最容易失败的地方调用前打个点失败后知道这一步没执行成功上下文压缩后压缩是个有损操作压缩完打个点万一压缩出问题可以回退关键决策点模型做出重要分支选择时打点方便回溯决策路径定期兜底就是设一个时间间隔比如每 60 秒强制打一次防止某些步骤卡住不打点。这里有个细节打检查点本身要幂等。也就是说同一个步骤重复打点不应该产生副作用。我早期用追加写入的方式结果恢复时发现有重复的检查点记录状态判断就乱了。后来改成按步骤号覆盖写入同一个步骤号只保留最新的一份。3.3 存储选型别一上来就上重型方案检查点存哪里我见过两种极端一种是用内存字典进程一挂全没了另一种是一上来就上分布式数据库结果为了存个检查点引入一堆依赖。我的建议是按阶段选型开发调试阶段本地文件系统JSON 格式一个任务一个文件简单直接方便肉眼查看单机生产阶段SQLite 或者本地 KV 存储支持并发读写性能足够分布式生产阶段才考虑 Redis 或者对象存储这时候你已经有明确的并发和持久化需求了格式上我强烈建议用JSON 或者 MessagePack别用 pickle 之类的。原因很简单可读、可调试、跨语言。你排查问题的时候能直接打开看比什么都强。提示检查点文件一定要带版本号字段。你的状态结构会随着迭代变化没有版本号的话老检查点用新代码恢复会直接崩。3.4 检查点的清理策略检查点会越积越多一个跑了几百步的任务检查点文件可能几十兆。清理策略我一般这么定保留最近 N 个检查点N 通常设 10用于快速回退每个里程碑保留一个比如每完成一个子任务保留一个用于跨阶段恢复任务成功完成后只保留最终状态和里程碑检查点中间的删掉任务失败且确认不再重试的保留最后一个检查点用于事后分析其余删掉清理动作我放在任务状态变更的时候触发而不是单独起个定时任务这样逻辑更内聚。4. 任务恢复从断点续跑而不是从头再来4.1 恢复流程的完整链路任务恢复不是简单地读检查点然后继续跑中间有一串判断要做。我把整个恢复链路拆成五步第一步加载检查点校验完整性。读出来的状态对象要先校验版本号对不对、必填字段全不全、引用的外部资源还在不在。我踩过一个坑检查点里存了个临时文件路径恢复的时候那个文件已经被清理了结果 Agent 跑到那一步直接报错。所以校验环节必须检查外部引用的有效性。第二步判断任务是否真的需要恢复。有些失败是致命的比如任务目标本身就不合法这种恢复多少次都没用。我的做法是给错误分类可重试错误网络超时、限流、可恢复错误上下文超限、工具临时不可用、致命错误参数非法、目标矛盾。只有前两类才触发恢复。第三步重建上下文。从检查点里取出压缩后的记忆层和任务层重新拼装成模型能吃的上下文。注意这里不要重新做压缩直接用存下来的压缩结果否则每次恢复的上下文都不一样行为不可预测。第四步确定恢复起点。这是最容易出错的地方。恢复起点不是简单的检查点步骤号 1因为检查点可能是在工具调用前打的那一步的工具可能已经执行了也可能没执行。我的做法是检查点里记录一个步骤状态字段标明这一步是未开始/执行中/已完成。如果是执行中恢复时要先做一次幂等性检查确认这一步的副作用是否已经产生。第五步注入恢复标记。在上下文里明确告诉模型你是从第 X 步恢复的之前完成了什么让模型知道当前处境。这个标记很重要否则模型可能重复已经做过的事。4.2 幂等性恢复机制的生命线说到幂等性这是任务恢复里最核心也最容易被忽视的问题。什么叫幂等就是同一个操作执行一次和执行多次结果是一样的。为什么重要因为恢复的时候你无法百分百确定失败的那一步到底执行成功没有。比如 Agent 调用了一个创建订单的接口请求发出去了但响应超时了。这时候订单可能已经创建成功也可能没创建。如果你直接重试可能创建出两个订单。解决思路有三个层次层次一工具本身支持幂等。调用的时候带一个唯一的幂等键比如任务 ID 步骤号服务端根据这个键去重。这是最干净的方案但需要工具侧配合。层次二执行前先查询。恢复时先调一个查询接口确认目标状态是否已经达成达成了就跳过没达成再执行。适合有查询能力的场景。层次三本地记录执行状态。在调用外部工具前先在本地记一条即将执行的日志执行成功后改成已执行。恢复时读这个日志判断。这个方案不依赖外部但要求本地记录和外部调用之间不能有太长的窗口期。我一般优先用层次一不行就层次二实在没办法才用层次三。层次三的窗口期问题在极端情况下还是会出问题只能作为兜底。4.3 恢复后的上下文重建细节恢复时重建上下文有个微妙的地方要不要把失败信息告诉模型我的经验是要但要克制。告诉模型上一步因为 XX 原因失败了现在重试能让模型调整策略比如换个工具、改个参数。但如果把完整的错误堆栈塞进去模型容易被吓到开始过度谨慎或者跑偏。我的做法是给一个精简的失败摘要失败步骤号、失败类型、一句话原因、建议的应对方向。比如第 23 步调用天气接口超时建议重试或改用备用数据源。这样模型既知道发生了什么又不会陷入细节。另外恢复后的前几步要加强监控。因为恢复点往往是问题高发区我会在恢复后的 3 步内提高检查点频率每步都打点一旦再失败可以快速回退。4.4 恢复次数与退避策略不能无限恢复。一个任务如果反复失败说明有系统性问题继续恢复只是浪费资源。我一般设两个阈值单步恢复上限同一步骤最多恢复 3 次超过就跳过或终止任务恢复上限整个任务最多恢复 5 次超过就标记为需人工介入恢复之间要有退避。第一次失败等 1 秒重试第二次等 5 秒第三次等 30 秒。这个退避对网络类错误特别有效很多限流问题等一会儿自己就好了。退避时间我一般用指数退避加随机抖动避免多个任务同时恢复造成雪崩。抖动范围取退避时间的 ±20% 左右。5. 循环执行Agent的心跳与刹车5.1 主循环的标准结构Agent 的主循环看起来简单但要写得健壮不容易。我现在的标准结构是这样的def run_agent(task, checkpoint_store, max_steps100): state load_or_init_state(task, checkpoint_store) while state.step max_steps: # 1. 检查是否应该停止 if should_stop(state): break # 2. 构建当前上下文 context build_context(state) # 3. 调用模型获取下一步动作 action call_model(context) # 4. 解析动作判断类型 if action.type tool_call: # 5. 执行前打检查点 save_checkpoint(state, phasebefore_tool) # 6. 执行工具带超时和重试 result execute_tool_with_guard(action) # 7. 更新状态 state.record(action, result) # 8. 执行后打检查点 save_checkpoint(state, phaseafter_tool) elif action.type final_answer: state.mark_complete(action.content) break # 9. 上下文管理 if should_compress(state): compress_context(state) # 10. 资源检查 check_resource_limits(state) state.step 1 return state这个结构里有几个关键点检查点打在工具执行前后、上下文压缩有独立触发条件、资源检查每步都做、循环有硬性步数上限。少任何一个健壮性都会打折扣。5.2 循环终止条件不止是任务完成新手最容易犯的错是只设一个终止条件——模型说完成了。但实际运行中循环可能因为各种原因需要停下来任务正常完成模型输出最终答案达到步数上限防止无限循环资源耗尽token 预算用完、时间超限、调用次数超限连续无进展连续 N 步没有产生新的有效信息说明卡住了检测到死循环连续几步的动作高度相似说明模型在原地打转外部中断信号用户主动取消、系统需要停机我一般把这些条件都实现任何一个触发都优雅退出并且记录退出原因。退出原因很重要它决定了后续是标记完成还是标记失败待恢复。5.3 死循环检测的实操方法死循环是 Agent 的常见病。表现是模型反复调用同一个工具、反复输出相似内容、在两个状态之间来回跳。检测方法我用了三种组合起来效果不错方法一动作指纹比对。把每一步的动作工具名 参数算一个哈希最近 5 步的哈希如果有重复就报警。这个方法简单有效能抓住大部分明显的重复。方法二状态相似度。比较连续几步的上下文状态如果相似度超过阈值比如 95%说明没有实质进展。相似度可以用简单的文本 diff 或者向量余弦相似度算。方法三进展计数器。维护一个有效进展计数每次产生新的关键信息新数据、新结论、状态变更就加一连续几步不加就报警。检测到死循环后怎么处理我的做法是先注入干预提示告诉模型你似乎在重复之前的操作请换一个思路或者说明遇到的困难。如果干预后还是重复就强制终止标记为需要人工介入。直接终止太粗暴给模型一次自我纠正的机会往往能救回来。5.4 循环中的状态机思维把 Agent 的运行看成一个状态机会让整个逻辑清晰很多。我定义的状态包括INIT初始化加载任务和检查点RUNNING正常执行中WAITING_TOOL等待工具返回COMPRESSING上下文压缩中RECOVERING从失败中恢复PAUSED暂停等待外部信号COMPLETED正常完成FAILED失败终止NEEDS_HUMAN需要人工介入每个状态有明确的进入条件、退出条件和允许的动作。比如WAITING_TOOL状态下不允许发起新的模型调用RECOVERING状态下不允许执行新的工具。这种约束能避免很多并发和时序问题。状态机的另一个好处是可观测。你监控 Agent 的时候直接看它处于哪个状态就知道它在干什么比看一堆日志高效得多。6. 资源管控给Agent套上缰绳6.1 四类必须管控的资源Agent 消耗的资源不止 token 一种。我梳理了一下至少有四类需要管控Token 预算这是最直接的。输入 token 输出 token 的总和要设一个上限。我一般按任务复杂度预估简单任务 10 万中等任务 50 万复杂任务 200 万。超了就终止。时间预算整个任务的墙钟时间上限。有些任务会卡在某个工具调用上没有时间限制的话可能挂几个小时。我一般设 30 分钟到 2 小时看任务性质。调用次数模型调用次数和工具调用次数分别设上限。模型调用次数反映思考了多少轮工具调用次数反映行动了多少次。这两个数字异常增长往往意味着死循环。并发资源如果 Agent 会并发调用工具要限制并发数。我一般设 3 到 5太高容易触发外部服务的限流太低影响效率。这四类资源要同时监控任何一类超限都触发终止或降级。6.2 预算分配与动态调整资源预算不能一刀切要按阶段分配。我的做法是把任务分成几个阶段比如信息收集分析处理结果生成每个阶段分配一个预算比例。比如总 token 预算 50 万信息收集阶段给 40%20 万分析处理给 40%20 万结果生成给 20%10 万。这样能防止某个阶段把预算吃光导致后面阶段没法进行。动态调整是指如果某个阶段提前完成省下的预算可以转移给后面的阶段。反之如果某个阶段快超支了可以提前预警让 Agent 简化后续操作。实现上我维护一个预算账本每步消耗都记账定期检查余额。余额不足时触发降级策略比如减少上下文注入量跳过非关键步骤用更简洁的输出格式。6.3 超限后的降级与终止策略资源超限不是只有终止一个选项。我设计了一个分级响应机制资源使用率响应级别具体动作 70%正常无70% - 85%预警记录日志开始精简上下文85% - 95%降级跳过非关键步骤压缩输出 95%临界强制进入收尾流程尽快产出结果超限终止保存检查点标记状态退出这个分级机制的好处是Agent 在资源紧张时会自己想办法省着用而不是突然被砍掉。很多任务在降级模式下其实能勉强完成比直接失败强。收尾流程特别重要当资源快用完时Agent 应该被引导去总结当前进展、输出已有结果而不是继续尝试完成完整任务。这样至少能拿到部分成果。6.4 资源监控的可观测性建设资源管控要落地必须有配套的监控。我一般记录这些指标每步的 token 消耗输入/输出分开累计 token 消耗和预算余额每步耗时和累计耗时模型调用次数、工具调用次数当前状态和状态持续时间检查点数量和最近检查点时间这些指标我通过结构化日志输出格式统一方便后续接入监控系统。日志里带上任务 ID 和步骤号出问题的时候能快速定位。提示资源监控的日志不要写进 Agent 的上下文否则会污染模型的输入。监控是给运维看的不是给模型看的两条线要分开。7. 把四件事串起来一个完整的运行流程7.1 从任务启动到结束的全链路把前面讲的机制串起来一个完整的 Agent 运行流程是这样的任务启动初始化状态机进入INIT加载任务定义和初始上下文。然后进入RUNNING开始主循环。每轮循环先构建上下文系统层 任务层 压缩后的记忆层 当前工作层调用模型获取动作。如果是工具调用先打执行前检查点执行工具带超时、重试、幂等保护打执行后检查点更新状态。如果是最终答案标记完成退出循环。每轮循环结束前检查是否需要压缩上下文按步数或 token 量触发检查资源使用情况四类资源都查检查是否触发终止条件完成、超限、死循环、无进展。如果中途失败进入RECOVERING状态加载最近的检查点校验完整性重建上下文确定恢复起点注入恢复标记然后回到RUNNING继续。整个过程中状态机在RUNNING、WAITING_TOOL、COMPRESSING、RECOVERING之间流转直到进入COMPLETED、FAILED或NEEDS_HUMAN。7.2 关键参数的推荐配置基于我的实践经验给一套起步配置你可以根据自己的场景调整参数推荐值说明最大步数100超过基本可以判定异常上下文压缩间隔5 步太频繁浪费 token太稀疏容易爆检查点保留数10最近 10 个用于快速回退单步恢复上限3同一步骤最多重试 3 次任务恢复上限5整个任务最多恢复 5 次退避基数1 秒指数退避的起始值死循环检测窗口5 步最近 5 步动作指纹比对并发工具调用上限3防止触发外部限流资源预警阈值70%开始精简上下文资源降级阈值85%跳过非关键步骤这套配置不是金科玉律但作为一个起点是靠谱的。跑一段时间后根据实际数据调整。7.3 常见故障与对应处理最后整理几个我遇到过的典型故障和处理方式故障一上下文突然爆掉。通常是某个工具返回了超大结果。处理方式是给工具返回加长度限制超长的先截断再进上下文完整内容存外部需要时按需读取。故障二恢复后行为异常。多半是恢复时上下文重建有问题或者恢复标记没注入。检查检查点里的上下文快照是否完整恢复标记是否明确。故障三任务卡在某一步不动。可能是工具调用没有超时机制一直挂着。给所有工具调用加超时超时后按失败处理。故障四token 消耗远超预期。检查上下文压缩是否生效检查是否有步骤在重复注入相同内容。我遇到过一次是系统提示词被重复注入了每步都加一遍白白浪费。故障五死循环检测误报。有些任务确实需要重复调用同一个工具比如轮询状态这时候指纹比对会误报。解决方法是给这类合法重复加白名单或者用状态相似度代替动作指纹。这些故障排查下来你会发现大部分问题都出在边界处理上——上下文边界、资源边界、状态边界。把边界处理好了Agent 的稳定性会有质的提升。我个人在实际操作中的体会是Agent 开发最难的不是让它能跑而是让它跑得稳、跑得省、断了能接上。前面这些机制每一个单独看都不复杂难的是把它们组合起来让它们协同工作。我的建议是先把检查点和恢复做扎实这是保命的再优化上下文管理这是省钱的最后打磨循环和资源管控这是提效的。顺序别搞反否则容易在细节里迷失。后续如果要做多 Agent 协作这套单 Agent 的运行机制依然是基础。每个 Agent 有自己的上下文、检查点、资源预算Agent 之间的通信本质上也是一种工具调用同样需要幂等和超时保护。把单 Agent 的机制吃透多 Agent 的复杂度才有办法驾驭。