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 窗口的模型，我一般的分配思路是这样：

• 系统层 + 工具定义：预留 8K～15K，工具越多占得越多，这块基本固定
• 任务层（目标 + 进度摘要）：预留 5K～10K
• 步骤层（最近 N 步完整记录）：预留 30K～50K
• 检索层（按需注入）：预留 20K～30K
• 输出预留：至少 8K，给模型生成用

加起来你会发现，真正能留给“历史步骤”的其实没多少。所以步骤层必须做滚动窗口 + 摘要压缩：最近 3～5 步保留完整原文，更早的步骤压缩成一句话摘要。比如“第 3 步：调用搜索工具，拿到 5 条结果，筛选出 2 条相关”——这样一句话就够了，不需要把 5 条结果的原文都留着。

这里有个容易忽略的点：工具返回结果往往是上下文膨胀的元凶。一次网页抓取可能返回几万字的 HTML，一次数据库查询可能返回几百行。我的做法是在工具层就做截断和结构化，返回给模型之前先提炼成关键字段，而不是把原始数据直接灌进去。

2.3 上下文压缩的三种策略与取舍

压缩这件事，我实测下来有三种常用策略，各有适用场景：

第一种，滑动窗口淘汰。最简单，只保留最近 N 轮，老的直接丢。优点是实现快、无额外开销；缺点是会丢关键信息，如果第 2 步有个重要结论，到第 20 步就被冲掉了。适合步骤之间弱依赖的任务。

第二种，摘要压缩。用一个便宜的小模型，把老步骤总结成简短摘要。优点是保留语义、省 token；缺点是多一次模型调用，有延迟和成本，而且摘要本身可能丢细节。适合长任务、步骤强依赖的场景。

第三种，结构化状态外置。把关键信息（已完成子任务、已获取的关键数据、当前进度）写到一个结构化的状态对象里，每步都更新它，模型每步只读这个状态对象而不是读全部历史。这是我最推荐的方式，因为它把“记忆”从上下文里搬到了外部存储，上下文只负责“当前决策所需的最小信息”。

实际项目里我通常是三者混用：结构化状态常驻，最近几步用滑动窗口，更早的用摘要。这样既控制了窗口，又不会丢关键信息。

2.4 上下文污染：比窗口爆掉更隐蔽的坑

窗口爆掉是显性问题，报错就看见了。上下文污染是隐性问题，它不报错，但会让模型越跑越蠢。

什么叫污染？举几个我踩过的例子：

• 工具调用失败的错误信息一直留在上下文里，模型后面反复被这个错误“暗示”，开始自我怀疑
• 早期一个错误的中间结论没被清理，模型后面基于它继续推理，越推越偏
• 检索层拉进来的不相关文档没及时清掉，干扰了后续判断

解决办法是给上下文加“清理钩子”：每一步结束后，检查是否有失败信息、过期结论、一次性资料，该删的删，该标记失效的标记失效。这个动作看起来不起眼，但对长任务的稳定性影响巨大。我做过对比，加了清理钩子的 Agent 在 30 步以上的任务里，最终成功率能高出两成左右。

3. 检查点：让 Agent 能“存档读档”的关键设计

3.1 检查点到底存什么

检查点这个词借自游戏存档，核心思想是：在任务执行的关键节点，把当前完整状态持久化下来，出问题时能从最近的存档点恢复，而不是从头再来。

那“完整状态”包括什么？我列一下我实际项目里会存的东西：

• 任务元信息：任务 ID、创建时间、当前状态（运行中/暂停/失败/完成）
• 上下文快照：当前的分层上下文内容，或者至少是结构化状态对象
• 执行进度：已完成哪些步骤、当前在第几步、下一步计划是什么
• 工具调用记录：调了哪些工具、参数是什么、返回结果摘要
• 资源消耗：已用 token 数、已用时间、已调用次数
• 幂等标记：哪些操作是“已执行且不可重复”的（比如已经写库、已经发消息）

这里面幂等标记是最容易被忽略但最致命的。如果你的 Agent 会执行有副作用的操作（写数据库、发请求、改文件），恢复时必须知道哪些操作已经做过了，否则重放会出大问题。我前面说的那次线上事故，就是因为没有幂等标记，恢复后重复写了两条数据。

3.2 检查点的触发时机：什么时候该存档

不是每一步都存，那样开销太大；也不是只在最后存，那样等于没存。触发时机要选在“状态发生实质变化且值得保护”的节点。我的经验是这几类时机必存：

1. 子任务完成时：一个子任务做完，是个天然的稳定状态，存一次
2. 有副作用的操作执行前：写库、发消息之前先存，这样万一操作后崩溃，恢复时知道要跳过
3. 长耗时操作前后：比如一次要跑几分钟的批量处理，前后都存
4. 固定步数间隔：比如每 5 步存一次，兜底用
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 任务状态机：

状态机的好处是：每个状态允许的操作是明确的，非法转移会被拦住。比如 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 从任务启动到完成的完整链路

我把前面讲的四个部件串一遍，走一个完整流程：

1. 任务启动：初始化状态机为 INIT，创建任务 ID，分配资源预算，组装系统层和任务层上下文
2. 进入主循环：状态转 PLANNING，模型规划子任务
3. 执行步骤：状态转 EXECUTING，每步组装上下文（分层 + 压缩）、调用模型、校验决策、执行工具、更新状态
4. 存检查点：在子任务完成、有副作用操作前、固定间隔等时机存检查点
5. 资源监控：每步检查预算，分级预警，必要时压缩或暂停
6. 异常处理：工具失败走重试，连续失败走熔断降级，进程崩溃走恢复
7. 任务完成：状态转 DONE，清理资源，输出结果

这个链路里，检查点和资源监控是横切关注点，贯穿始终；上下文管理是每步都要做的；任务恢复是异常路径才走的。

7.2 一次崩溃恢复的完整复盘

回到开头那个事故，如果当时有完整的运行机制，应该是这样处理的：

任务在第 15 步调用外部接口时超时崩溃。因为第 14 步存了检查点，且第 15 步的操作有幂等标记（标记为“未完成”），恢复时：

1. 加载第 14 步的检查点，状态机从 FAILED 转 RECOVERING
2. 重建上下文，恢复到第 14 步的状态
3. 检查第 15 步的幂等标记，发现未完成，允许重试
4. 重试第 15 步，这次接口正常返回
5. 继续执行后续步骤，状态转 EXECUTING

整个过程不需要重跑前 14 步，省下了大量 token 和时间，也不会重复写数据。这就是运行机制的价值。

7.3 不同规模场景的机制取舍

不是所有场景都需要全套机制。我按规模给个取舍建议：

从 Demo 到生产，机制是逐步加码的。别一上来就全套，那样开发成本太高；但也别一直停在 Demo 水平，那样上不了生产。

8. 实操中踩过的坑与排查清单

8.1 上下文相关的典型问题

问题：任务越跑越慢，token 消耗飙升。排查方向：检查上下文是否只增不减，工具返回是否做了截断，摘要压缩是否生效。我遇到过一次是工具返回的 HTML 没截断，每步都灌几万字进去。

问题：模型后期决策质量下降。排查方向：检查上下文是否被污染，失败信息、过期结论是否清理。加清理钩子通常能解决。

问题：恢复后模型行为异常。排查方向：检查恢复时的上下文重建是否和崩溃前一致，状态对象是否完整加载。

8.2 检查点与恢复的典型问题

问题：恢复后重复执行有副作用的操作。排查方向：幂等标记是否记录完整，恢复逻辑是否正确比对指纹。

问题：检查点写入拖慢任务。排查方向：检查点粒度是否过细，是否每步都序列化大对象。改成轻量状态每步更新、完整检查点事件触发。

问题：旧检查点无法恢复。排查方向：检查点版本兼容，加 schema 版本字段和迁移逻辑。

8.3 循环与资源管控的典型问题

问题：Agent 陷入死循环。排查方向：是否有无进展检测，终止条件是否完整。加连续无进展检测通常能解决。

问题：某个任务吃光资源导致其他任务饿死。排查方向：是否有配额隔离，资源池是否按任务分配。

问题：依赖服务抖动导致任务大面积失败。排查方向：是否有熔断降级，重试是否有退避和上限。

8.4 一份可复用的排查速查表

这张表我基本是贴在工位上的，出问题先对着扫一遍，能快速定位大半。

9. 几个容易被忽略的工程细节

9.1 时间与顺序的一致性

分布式环境下，检查点的时间戳和实际执行顺序可能不一致。比如两个步骤几乎同时完成，检查点写入顺序可能颠倒。恢复时如果按时间戳排序，可能得到错误的执行顺序。解决办法是用单调递增的序列号而不是时间戳来标记步骤顺序，序列号由单点生成，保证全序。

9.2 大对象的处理

上下文快照、工具返回的大结果，这些大对象直接存检查点会让检查点膨胀。我的做法是大对象外置：把大对象存到对象存储，检查点里只存引用（URL 或 key）。恢复时按引用拉取。这样检查点本身保持轻量，写入快。

9.3 敏感信息的处理

上下文和检查点里可能包含敏感信息（用户数据、密钥、内部接口）。存储时要考虑加密和访问控制，日志里要脱敏。这个在合规要求高的场景是硬性要求，别等出事才补。

9.4 测试恢复逻辑的方法

恢复逻辑平时不跑，一出问题就是关键时刻，所以必须专门测试。我的做法是故障注入：在测试环境故意在随机步骤杀掉进程，然后验证恢复逻辑是否正确。跑个几十次，能覆盖大部分边界情况。这个测试投入产出比很高，强烈建议做。

10. 我个人的一些实践体会

搞了这么久 Agent，我最大的体会是：把 Agent 当成一个分布式系统来设计，而不是当成一个提示词来调。提示词工程解决的是“单次调用质量”，运行机制解决的是“长任务可靠性”，两者完全不是一个层面的问题。很多人卡在 Agent 上不了生产，不是模型不行，是运行机制没搭起来。

第二个体会是检查点和幂等要尽早做。这两个东西后期补的代价极大，因为要改动整个执行链路。我建议从第一个有副作用的操作开始，就把幂等标记和检查点加上，哪怕一开始只是存本地文件。

第三个体会是资源管控要有，但别过度。见过一些团队把预算卡得死死的，结果正常任务也跑不完。预算应该是“保险丝”而不是“紧箍咒”，留足余量，只在异常时起作用。

最后分享一个我常用的小技巧：给 Agent 加一个“执行日志”，每一步的决策、动作、结果、资源消耗都记下来，结构化存储。这个日志平时用于调试和复盘，出问题时用于恢复，做优化时用于分析瓶颈。一份日志三用，性价比极高。我现在的项目里，这个日志基本是标配，没有它我根本不敢让 Agent 跑长任务。

这套机制不是一天搭起来的，我也是从“直线逻辑”一步步踩坑踩过来的。如果你现在正被 Agent 的稳定性折磨，建议先从上下文分层和检查点这两个最基础的部件入手，把这两个做扎实，你会发现很多问题自然就消失了。