1. 从一次线上事故说起Agent 为什么需要“运行机制”凌晨两点监控告警响了。一个跑了四十多分钟的 Agent 任务在调用某个外部接口时超时进程直接挂掉。重启之后它从第一步重新开始把前面已经完成的十几个工具调用又跑了一遍白白烧掉了几十万 token还把下游系统写脏了两条数据。这不是段子是我去年真实踩过的坑。问题出在哪不是模型不行也不是提示词写得烂而是这个 Agent 根本没有“运行机制”这个概念——它只有一条从头到尾的直线逻辑没有上下文管理没有检查点没有恢复策略更没有资源管控。一旦中途断了就是全盘重来。这篇内容我想把 Agent 的运行机制彻底拆开讲清楚围绕四个核心部件上下文Context、检查点Checkpoint、任务恢复Task Recovery、循环执行与资源管控Loop Resource Control。这四个东西凑在一起才构成一个能扛住真实生产环境的 Agent。适合正在做 Agent 开发、被长任务稳定性折磨、或者准备从 Demo 走向生产的大模型工程师看。不管你是刚入门想搞懂 Agent 到底怎么跑起来的还是已经在调框架想优化执行链路下面这些拆解应该都能对上你的场景。我先把结论摆前面Agent 的稳定性不取决于模型多聪明而取决于它的运行机制设计得多扎实。模型是大脑运行机制是骨架和血液循环系统。大脑再强骨架散了照样跑不动。2. 上下文Agent 的“工作记忆”到底怎么组织2.1 上下文不是聊天记录是分层的工作台很多人一提上下文脑子里就是“把历史对话拼起来塞给模型”。这个理解在 Chatbot 场景够用但在 Agent 场景会直接翻车。因为 Agent 的上下文里不只有对话还有工具定义、工具返回结果、中间推理、任务状态、外部检索到的资料……全塞进去上下文窗口分分钟爆掉。我习惯把 Agent 的上下文分成四层从下往上层级内容生命周期是否常驻系统层角色设定、全局约束、工具清单整个任务常驻任务层当前目标、子任务拆解、进度状态整个任务常驻可压缩步骤层当前这一步的推理、工具调用与返回单步或几步滚动淘汰检索层临时拉进来的外部知识、文档片段单次使用用完即弃这个分层不是为了好看是为了解决一个核心矛盾模型需要看到全局但窗口装不下全局。系统层和任务层是“必须一直看得见”的步骤层是“最近几步看得见就行”检索层是“用的时候才拉进来”。提示如果你现在是把所有历史一股脑拼接先别急着上什么高级框架先把这四层拆开光这一步就能让你的 token 消耗降一大截。2.2 上下文窗口的预算分配给每一步留多少额度上下文窗口是有限资源得当成预算来管。假设你用的是 128K 窗口的模型我一般的分配思路是这样系统层 工具定义预留 8K15K工具越多占得越多这块基本固定任务层目标 进度摘要预留 5K10K步骤层最近 N 步完整记录预留 30K50K检索层按需注入预留 20K30K输出预留至少 8K给模型生成用加起来你会发现真正能留给“历史步骤”的其实没多少。所以步骤层必须做滚动窗口 摘要压缩最近 35 步保留完整原文更早的步骤压缩成一句话摘要。比如“第 3 步调用搜索工具拿到 5 条结果筛选出 2 条相关”——这样一句话就够了不需要把 5 条结果的原文都留着。这里有个容易忽略的点工具返回结果往往是上下文膨胀的元凶。一次网页抓取可能返回几万字的 HTML一次数据库查询可能返回几百行。我的做法是在工具层就做截断和结构化返回给模型之前先提炼成关键字段而不是把原始数据直接灌进去。2.3 上下文压缩的三种策略与取舍压缩这件事我实测下来有三种常用策略各有适用场景第一种滑动窗口淘汰。最简单只保留最近 N 轮老的直接丢。优点是实现快、无额外开销缺点是会丢关键信息如果第 2 步有个重要结论到第 20 步就被冲掉了。适合步骤之间弱依赖的任务。第二种摘要压缩。用一个便宜的小模型把老步骤总结成简短摘要。优点是保留语义、省 token缺点是多一次模型调用有延迟和成本而且摘要本身可能丢细节。适合长任务、步骤强依赖的场景。第三种结构化状态外置。把关键信息已完成子任务、已获取的关键数据、当前进度写到一个结构化的状态对象里每步都更新它模型每步只读这个状态对象而不是读全部历史。这是我最推荐的方式因为它把“记忆”从上下文里搬到了外部存储上下文只负责“当前决策所需的最小信息”。实际项目里我通常是三者混用结构化状态常驻最近几步用滑动窗口更早的用摘要。这样既控制了窗口又不会丢关键信息。2.4 上下文污染比窗口爆掉更隐蔽的坑窗口爆掉是显性问题报错就看见了。上下文污染是隐性问题它不报错但会让模型越跑越蠢。什么叫污染举几个我踩过的例子工具调用失败的错误信息一直留在上下文里模型后面反复被这个错误“暗示”开始自我怀疑早期一个错误的中间结论没被清理模型后面基于它继续推理越推越偏检索层拉进来的不相关文档没及时清掉干扰了后续判断解决办法是给上下文加“清理钩子”每一步结束后检查是否有失败信息、过期结论、一次性资料该删的删该标记失效的标记失效。这个动作看起来不起眼但对长任务的稳定性影响巨大。我做过对比加了清理钩子的 Agent 在 30 步以上的任务里最终成功率能高出两成左右。3. 检查点让 Agent 能“存档读档”的关键设计3.1 检查点到底存什么检查点这个词借自游戏存档核心思想是在任务执行的关键节点把当前完整状态持久化下来出问题时能从最近的存档点恢复而不是从头再来。那“完整状态”包括什么我列一下我实际项目里会存的东西任务元信息任务 ID、创建时间、当前状态运行中/暂停/失败/完成上下文快照当前的分层上下文内容或者至少是结构化状态对象执行进度已完成哪些步骤、当前在第几步、下一步计划是什么工具调用记录调了哪些工具、参数是什么、返回结果摘要资源消耗已用 token 数、已用时间、已调用次数幂等标记哪些操作是“已执行且不可重复”的比如已经写库、已经发消息这里面幂等标记是最容易被忽略但最致命的。如果你的 Agent 会执行有副作用的操作写数据库、发请求、改文件恢复时必须知道哪些操作已经做过了否则重放会出大问题。我前面说的那次线上事故就是因为没有幂等标记恢复后重复写了两条数据。3.2 检查点的触发时机什么时候该存档不是每一步都存那样开销太大也不是只在最后存那样等于没存。触发时机要选在“状态发生实质变化且值得保护”的节点。我的经验是这几类时机必存子任务完成时一个子任务做完是个天然的稳定状态存一次有副作用的操作执行前写库、发消息之前先存这样万一操作后崩溃恢复时知道要跳过长耗时操作前后比如一次要跑几分钟的批量处理前后都存固定步数间隔比如每 5 步存一次兜底用上下文压缩前后压缩是有损的压缩前存一份原始状态出问题能回退存储介质上轻量场景用本地文件或 SQLite 就够生产环境建议用带事务的关系库或者对象存储。关键是写入要原子不能存到一半崩了导致检查点损坏。我一般用“写临时文件 原子重命名”或者数据库事务来保证。3.3 检查点的粒度权衡存太勤和存太懒都是坑粒度这个事我踩过两头的坑。存太勤每步都存IO 开销上来了任务执行速度明显变慢尤其是检查点里包含大对象比如完整上下文的时候。有一次我把完整上下文每步都序列化落盘结果任务整体耗时增加了 40%。存太懒只在任务结束存等于没有恢复能力。中途崩了照样从头来。我的平衡点是结构化状态每步都更新轻量完整检查点按事件触发重量。结构化状态就是前面说的那个状态对象几十 KB 级别每步更新成本很低完整检查点包含上下文快照几百 KB 到几 MB只在关键节点存。这样既有细粒度的恢复能力又不会拖慢执行。3.4 检查点的版本兼容问题这个坑比较隐蔽但迟早会遇到你的 Agent 逻辑升级了检查点的数据结构变了这时候去恢复一个旧检查点直接解析失败。解决办法是给检查点加版本号并且在恢复逻辑里做兼容处理。要么做数据迁移把旧格式转成新格式要么明确拒绝旧版本并给出提示。我一般会在检查点里存一个 schema 版本字段恢复时先校验版本不匹配就走迁移或者报错绝不硬着头皮解析。注意检查点格式一旦上线就当成对外接口来对待改结构要慎重最好向前兼容。4. 任务恢复从崩溃中优雅地爬起来4.1 恢复的三种模式任务恢复不是只有一种玩法根据场景不同我把它分成三种模式模式一断点续跑。从最近的检查点继续跳过已完成的步骤。这是最理想的模式前提是检查点足够完整、操作足够幂等。适合步骤清晰、状态可序列化的任务。模式二步骤重试。不恢复到检查点而是重试当前失败的那一步。适合失败是瞬时性的场景网络抖动、限流重试一次就好了。但要注意重试次数上限和退避策略别把下游打挂。模式三任务重启。从第一步重来但复用之前已经获取的数据比如检索结果缓存避免重复的昂贵操作。这是兜底模式适合状态难以序列化、或者检查点损坏的情况。实际系统里这三种模式往往是组合使用的先试步骤重试不行再断点续跑检查点坏了才任务重启。4.2 幂等性恢复能成立的前提我反复强调幂等因为它是恢复的地基。如果操作不幂等恢复就是灾难。怎么保证幂等几个实用手段操作前查状态执行前先查“这个操作是不是已经做过了”做过就跳过唯一请求 ID给每个有副作用的操作生成唯一 ID下游系统根据 ID 去重状态机约束用状态机管理任务只有处于特定状态才允许执行特定操作重复执行会被状态机拦住补偿而非重放对于已经产生副作用的操作恢复时不是重放而是执行补偿逻辑比如撤销后重做我一般会在检查点的幂等标记里记录“操作指纹”操作类型 关键参数的哈希恢复时先比对指纹命中就跳过。这个机制救过我好几次。4.3 恢复时的上下文重建恢复不只是“从第几步继续”还要把上下文恢复到当时的状态。这里有个细节检查点里存的上下文快照和恢复时实际需要的上下文可能不完全一样。比如你存检查点的时候上下文里有最近 5 步的完整记录。恢复时你可能只需要最近 3 步因为更早的已经摘要过了。又比如恢复时外部环境可能变了工具接口升级了、数据源更新了你需要重新拉取一些信息。所以恢复逻辑里要有一个“上下文重建”步骤加载检查点里的状态对象重新组装分层上下文必要时刷新外部依赖。这一步做不好恢复后模型会“精神错乱”因为它看到的上下文和崩溃前不一致。4.4 恢复失败的兜底别让恢复本身成为故障点恢复逻辑本身也可能失败检查点损坏、依赖服务不可用、版本不兼容。这时候要有兜底不能让整个系统卡在“恢复中”。我的做法是给恢复设置超时和降级恢复尝试超过一定时间或次数就降级到任务重启模式并且记录一条告警。同时恢复失败的任务要进“人工介入队列”而不是无限重试。生产环境里无限重试是最危险的行为它会把一个小故障放大成雪崩。5. 循环执行Agent 的心跳怎么跳得稳5.1 主循环的标准结构Agent 的执行本质是一个循环观察 → 思考 → 行动 → 再观察。这个循环写起来简单但要跑得稳每个环节都得有约束。我一般的主循环结构是这样while not task_done: # 1. 检查资源预算超了就暂停 if budget_exceeded(): pause_and_checkpoint() break # 2. 组装当前上下文 context build_context(state, recent_steps) # 3. 调用模型做决策 decision llm_decide(context) # 4. 校验决策合法性 if not validate(decision): handle_invalid(decision) continue # 5. 执行动作工具调用等 result execute(decision) # 6. 更新状态与上下文 state update_state(state, decision, result) recent_steps.append((decision, result)) # 7. 按需存检查点 if should_checkpoint(state): save_checkpoint(state) # 8. 判断是否完成 task_done check_done(state)这个结构里第 1 步和第 4 步是最容易被省略但最不该省的。资源检查防止任务失控决策校验防止模型输出乱七八糟的东西直接被执行。5.2 循环终止条件怎么判断“该停了”循环最怕两件事该停不停死循环不该停停了提前结束。终止条件要设计得明确正常完成模型明确输出“任务完成”且校验通过预算耗尽token、时间、调用次数任一超限连续失败连续 N 次工具调用失败或决策无效无进展检测连续几步状态没有实质变化说明卡住了人工中断外部信号要求停止“无进展检测”是我特别想强调的。有些 Agent 会陷入“反复思考但不动手”或者“反复调用同一个工具拿同样的结果”的死循环。检测方法很简单比较连续几步的状态对象如果关键字段没变就判定无进展触发终止或换策略。5.3 循环中的状态机管理用状态机来管理循环能让逻辑清晰很多。一个典型的 Agent 任务状态机状态含义可转移到INIT初始化PLANNINGPLANNING规划中EXECUTINGEXECUTING执行中EXECUTING / WAITING / DONE / FAILEDWAITING等待外部工具返回、人工EXECUTING / FAILEDDONE完成-FAILED失败RECOVERINGRECOVERING恢复中EXECUTING / FAILED状态机的好处是每个状态允许的操作是明确的非法转移会被拦住。比如 DONE 状态不允许再执行工具FAILED 必须先经过 RECOVERING 才能回到 EXECUTING。这样能避免很多逻辑混乱。5.4 并发场景下的循环隔离单个 Agent 的循环好管多个 Agent 并发就麻烦了。热词里有人问“AI Agent 怎么扛并发”这确实是个真问题。并发下的核心原则是隔离每个任务实例有独立的上下文、独立的状态、独立的检查点。共享的只有底层的模型调用配额、工具限流这些资源池。我一般用“任务 ID”作为隔离键所有状态存储都带这个键避免串味。资源池层面要做配额分配给每个任务实例分配 token 预算、调用次数预算防止某个任务把资源吃光导致其他任务饿死。这个在框架层面通常叫“租户隔离”或“配额管理”。6. 资源管控别让 Agent 变成吞金兽6.1 三类必须盯住的资源Agent 烧钱烧资源主要烧在三处Token。最直观的成本。输入 token 随上下文增长输出 token 随推理长度增长。长任务里 token 消耗是指数级上升的因为每步都要把历史带上。时间。模型调用有延迟工具调用有延迟串起来一个任务跑几十分钟很正常。时间成本在交互式场景里尤其敏感。外部调用次数。每次工具调用可能对应一次 API 请求、一次数据库查询这些都有配额和成本。调用次数失控会直接打挂下游。这三类资源都要有实时计量 硬性上限。计量是基础没有计量就谈不上管控上限是保险丝超了就熔断。6.2 预算分配与动态调整预算不能一刀切要按任务类型分配。我的做法是给每个任务一个“资源包”token 预算根据任务复杂度预估比如简单任务 50K复杂任务 500K时间预算比如交互式任务 2 分钟批处理任务 30 分钟调用预算比如最多 50 次工具调用执行过程中动态监控消耗速率。如果发现消耗速率异常比如某一步突然吃了 30% 的预算要能及时干预——要么压缩上下文要么终止当前步骤换策略。动态调整的一个实用技巧是分级预警消耗到 70% 时记录警告并开始压缩上下文到 90% 时暂停并评估是否继续到 100% 时强制终止并存检查点。这样不会突然“猝死”而是有缓冲地停下来。6.3 限流、熔断与降级这三个词是从微服务那边借来的用在 Agent 上一样管用。限流控制单位时间内对模型和工具的调用频率。防止突发流量打挂下游也防止自己的配额被瞬间耗尽。熔断当某个工具连续失败达到阈值直接熔断不再调用它避免无谓的等待和重试。熔断后可以走降级路径比如用缓存数据代替实时查询。降级资源紧张或依赖不可用时降低服务质量而不是直接失败。比如模型调用超时降级到用规则引擎处理检索服务挂了降级到用已有上下文继续。我实测下来加了熔断和降级的 Agent在依赖服务不稳定时的任务完成率能提升不少因为它不会卡在一个坏掉的依赖上死等。6.4 成本可观测性看不见就管不住资源管控的前提是能看见。我一般会埋这些监控指标每步的 token 消耗输入/输出分开每步的耗时累计资源消耗与预算的比值工具调用的成功率与平均延迟检查点的写入频率与大小这些指标汇总到一个看板上任务跑的时候能实时看到“这个任务现在花了多少、还剩多少、卡在哪”。没有这个可观测性资源管控就是盲人摸象。提示成本可观测性不只是为了省钱更是为了定位问题。任务变慢、变贵往往是某个环节出问题的信号。7. 把四个部件串起来一个完整流程的走查7.1 从任务启动到完成的完整链路我把前面讲的四个部件串一遍走一个完整流程任务启动初始化状态机为 INIT创建任务 ID分配资源预算组装系统层和任务层上下文进入主循环状态转 PLANNING模型规划子任务执行步骤状态转 EXECUTING每步组装上下文分层 压缩、调用模型、校验决策、执行工具、更新状态存检查点在子任务完成、有副作用操作前、固定间隔等时机存检查点资源监控每步检查预算分级预警必要时压缩或暂停异常处理工具失败走重试连续失败走熔断降级进程崩溃走恢复任务完成状态转 DONE清理资源输出结果这个链路里检查点和资源监控是横切关注点贯穿始终上下文管理是每步都要做的任务恢复是异常路径才走的。7.2 一次崩溃恢复的完整复盘回到开头那个事故如果当时有完整的运行机制应该是这样处理的任务在第 15 步调用外部接口时超时崩溃。因为第 14 步存了检查点且第 15 步的操作有幂等标记标记为“未完成”恢复时加载第 14 步的检查点状态机从 FAILED 转 RECOVERING重建上下文恢复到第 14 步的状态检查第 15 步的幂等标记发现未完成允许重试重试第 15 步这次接口正常返回继续执行后续步骤状态转 EXECUTING整个过程不需要重跑前 14 步省下了大量 token 和时间也不会重复写数据。这就是运行机制的价值。7.3 不同规模场景的机制取舍不是所有场景都需要全套机制。我按规模给个取舍建议场景规模上下文检查点恢复资源管控Demo/原型简单拼接不需要不需要不需要单机小任务分层 滑动窗口关键节点存步骤重试基础计量生产长任务分层 压缩 清理事件触发 定期三种模式组合预算 熔断降级高并发平台全量机制 隔离分布式存储自动恢复 人工兜底配额 可观测性从 Demo 到生产机制是逐步加码的。别一上来就全套那样开发成本太高但也别一直停在 Demo 水平那样上不了生产。8. 实操中踩过的坑与排查清单8.1 上下文相关的典型问题问题任务越跑越慢token 消耗飙升。排查方向检查上下文是否只增不减工具返回是否做了截断摘要压缩是否生效。我遇到过一次是工具返回的 HTML 没截断每步都灌几万字进去。问题模型后期决策质量下降。排查方向检查上下文是否被污染失败信息、过期结论是否清理。加清理钩子通常能解决。问题恢复后模型行为异常。排查方向检查恢复时的上下文重建是否和崩溃前一致状态对象是否完整加载。8.2 检查点与恢复的典型问题问题恢复后重复执行有副作用的操作。排查方向幂等标记是否记录完整恢复逻辑是否正确比对指纹。问题检查点写入拖慢任务。排查方向检查点粒度是否过细是否每步都序列化大对象。改成轻量状态每步更新、完整检查点事件触发。问题旧检查点无法恢复。排查方向检查点版本兼容加 schema 版本字段和迁移逻辑。8.3 循环与资源管控的典型问题问题Agent 陷入死循环。排查方向是否有无进展检测终止条件是否完整。加连续无进展检测通常能解决。问题某个任务吃光资源导致其他任务饿死。排查方向是否有配额隔离资源池是否按任务分配。问题依赖服务抖动导致任务大面积失败。排查方向是否有熔断降级重试是否有退避和上限。8.4 一份可复用的排查速查表现象可能原因优先排查token 飙升上下文只增不减工具返回截断、摘要压缩任务变慢检查点过频检查点粒度恢复后重复副作用幂等标记缺失操作指纹比对死循环无进展检测缺失终止条件决策质量下降上下文污染清理钩子资源饿死无配额隔离资源池分配依赖抖动雪崩无熔断降级熔断阈值、降级路径这张表我基本是贴在工位上的出问题先对着扫一遍能快速定位大半。9. 几个容易被忽略的工程细节9.1 时间与顺序的一致性分布式环境下检查点的时间戳和实际执行顺序可能不一致。比如两个步骤几乎同时完成检查点写入顺序可能颠倒。恢复时如果按时间戳排序可能得到错误的执行顺序。解决办法是用单调递增的序列号而不是时间戳来标记步骤顺序序列号由单点生成保证全序。9.2 大对象的处理上下文快照、工具返回的大结果这些大对象直接存检查点会让检查点膨胀。我的做法是大对象外置把大对象存到对象存储检查点里只存引用URL 或 key。恢复时按引用拉取。这样检查点本身保持轻量写入快。9.3 敏感信息的处理上下文和检查点里可能包含敏感信息用户数据、密钥、内部接口。存储时要考虑加密和访问控制日志里要脱敏。这个在合规要求高的场景是硬性要求别等出事才补。9.4 测试恢复逻辑的方法恢复逻辑平时不跑一出问题就是关键时刻所以必须专门测试。我的做法是故障注入在测试环境故意在随机步骤杀掉进程然后验证恢复逻辑是否正确。跑个几十次能覆盖大部分边界情况。这个测试投入产出比很高强烈建议做。10. 我个人的一些实践体会搞了这么久 Agent我最大的体会是把 Agent 当成一个分布式系统来设计而不是当成一个提示词来调。提示词工程解决的是“单次调用质量”运行机制解决的是“长任务可靠性”两者完全不是一个层面的问题。很多人卡在 Agent 上不了生产不是模型不行是运行机制没搭起来。第二个体会是检查点和幂等要尽早做。这两个东西后期补的代价极大因为要改动整个执行链路。我建议从第一个有副作用的操作开始就把幂等标记和检查点加上哪怕一开始只是存本地文件。第三个体会是资源管控要有但别过度。见过一些团队把预算卡得死死的结果正常任务也跑不完。预算应该是“保险丝”而不是“紧箍咒”留足余量只在异常时起作用。最后分享一个我常用的小技巧给 Agent 加一个“执行日志”每一步的决策、动作、结果、资源消耗都记下来结构化存储。这个日志平时用于调试和复盘出问题时用于恢复做优化时用于分析瓶颈。一份日志三用性价比极高。我现在的项目里这个日志基本是标配没有它我根本不敢让 Agent 跑长任务。这套机制不是一天搭起来的我也是从“直线逻辑”一步步踩坑踩过来的。如果你现在正被 Agent 的稳定性折磨建议先从上下文分层和检查点这两个最基础的部件入手把这两个做扎实你会发现很多问题自然就消失了。
