AI Agent工程实践（第42部分）：执行循环与异常处理

引言

第41部分我们深入拆解了Agent的规划系统——从目标定义到执行蓝图的生成机制。规划给出了「做什么」和「怎么做」的蓝图，但蓝图本身不会自动变成结果。本文聚焦规划之后同样关键的工程环节：执行循环（Execution Loop）与异常处理（Exception Handling）——Agent如何一步步执行计划、如何感知偏差、如何从故障中恢复，以及如何构建一个具备「工业级可靠性」的执行闭环。

如果说规划是Agent的「大脑前额叶」，那么执行循环就是「小脑+脑干」——负责将抽象计划转化为具体动作序列，处理时序协调、状态同步、错误恢复等底层问题。生产环境中，一个Agent能否稳定运行，80%取决于执行循环的设计质量。

一、执行循环的核心模型

1.1 经典执行循环：Sense-Think-Act

Agent执行循环的底层模型可以追溯到机器人学中的Sense-Think-Act（感知-思考-行动）循环。在LLM Agent语境下，它演化为：

• Perceive（感知）：从环境获取最新状态（工具返回值、外部API响应、用户追问、传感器数据等）
• Reason（推理）：LLM基于当前状态+历史上下文+计划，决定下一步动作
• Act（执行）：调用具体工具/API，对外部环境产生副作用
• Observe（观察）：捕获执行结果，更新内部状态，进入下一轮循环

这个循环看似简单，但工程实现中充满了设计决策点：循环终止条件是什么？超时如何处理？状态如何持久化？每一步的原子性如何保证？

1.2 两种循环拓扑

根据应用场景不同，执行循环有两种基本拓扑：

（a）同步串行循环（Synchronous Sequential Loop）

每个Think-Act周期完成后才进入下一步。优势是状态简单可控，劣势是当步骤之间存在可并行性时，浪费大量等待时间。适用于步骤间有严格依赖关系的任务链。

（b）异步并行循环（Asynchronous Parallel Loop）

支持多个Act同时执行，通过Future/Promise或回调机制收集结果。优势是吞吐量和延迟大幅优化，劣势是状态一致性、死锁检测、错误传播路径复杂。适用于可以DAG编排的任务流。

1.3 执行循环的状态机模型

生产级Agent需要将执行循环建模为显式状态机，而非隐式依赖LLM的「直觉」。核心状态包括：

• IDLE：等待新任务
• PLANNING：正在生成/更新执行计划
• EXECUTING：正在执行某个步骤
• WAITING：等待外部响应（异步工具调用）
• REASONING：重新评估/调整计划
• RECOVERING：正在处理异常/重试
• PAUSED：等待人工确认（Human-in-the-Loop）
• COMPLETED：任务正常完成
• FAILED：任务失败（不可恢复）
• CANCELLED：任务被取消

每个状态转换都应触发事件，用于日志追踪、可观测性指标和外部系统集成。

二、计划执行的模式选择

2.1 Plan-then-Execute模式

Agent先生成完整计划，然后严格按照计划顺序执行。这是第41部分讨论的分层规划与执行的典型实现。

适用场景：目标明确、步骤可枚举、环境变化小的结构化任务（如数据处理流水线、代码生成）。

工程挑战：计划一旦生成就「难以回头」——如果中间步骤发现前提假设错误，需要触发重规划（Replanning），这正是异常处理要解决的核心问题。

2.2 Interleaved Execution（交错执行）模式

执行和推理交替进行：执行一步→观察结果→推理下一步→再执行。ReAct模式是典型代表。

适用场景：环境动态变化、信息不完整、需要根据反馈调整方向的探索性任务（如互联网搜索、代码调试）。

工程优势：天然支持适应性——每一步的结果都可以修正后续路径，不存在「死守计划」的问题。

2.3 混合模式：Plan-Guided Interleaving

生产中最实用的做法是两者的结合：高层保持计划骨架（子目标序列），底层在每个子目标内采用交错执行。

这种模式兼顾了Plan-then-Execute的方向性和Interleaved Execution的灵活性，是目前主流Agent框架（LangGraph、CrewAI、AutoGen）默认推荐的执行策略。

三、异常分类与处理架构

3.1 七类执行异常

Agent执行过程中可能遇到的异常可分为七个层次：

1. 工具级异常：HTTP超时、429限流、500服务器错误、返回格式不匹配、参数校验失败
2. LLM级异常：上下文溢出、幻觉输出、格式违规、超时无响应、成本超限（Token预算耗尽）
3. 状态级异常：计划与实际偏差、状态转换非法、状态丢失、并发冲突
4. 环境级异常：网络分区、依赖服务不可用、存储空间不足、权限失效
5. 逻辑级异常：死循环检测、计划死锁（步骤间循环依赖）、目标漂移
6. 安全级异常：越权访问尝试、敏感数据泄露、提示注入攻击检测
7. 业务级异常：结果不符合预期质量标准、用户中途变更需求、业务规则冲突

3.2 分层处理架构

每种异常需要不同层次的处理策略，形成洋葱模型——从内到外依次尝试处理，无法处理时向外层传递：

• L1 - 本地重试：工具调用层面的指数退避重试（针对瞬时故障）
• L2 - 降级执行：切换备选工具/备选方案/简化路径
• L3 - 计划调整：修改当前计划（跳过/替换/新增步骤）
• L4 - 重规划：完全重新生成计划
• L5 - 人工介入：暂停等待人工决策
• L6 - 优雅终止：记录当前状态并安全退出

四、重试机制与退避策略

4.1 指数退避与抖动

瞬时故障（网络抖动、服务短暂过载）的标准处理方式是指数退避重试（Exponential Backoff）：第1次等待1秒，第2次2秒，第3次4秒，以此类推。但纯指数退避会导致「重试风暴」——多个Agent实例在同一时刻同时重试。引入抖动（Jitter）可以分散重试时间：delay = base * backoff^attempt + random(0, jitter_max)。

4.2 可重试性判定

不是所有错误都值得重试。关键判断标准：

• 可重试（Idempotent-Safe）：GET请求、幂等写入（PUT）、状态查询——可直接重试
• 需特殊处理：非幂等POST请求——需先确认前次是否成功，或使用幂等键/去重机制
• 不可重试：参数错误、权限不足、资源不存在——重试无意义，应立即进入降级路径

4.3 重试预算与熔断

每个任务分配一个重试预算（Retry Budget），比如单步骤最多重试3次、整个任务全局重试预算不超过15次。超过预算后不再重试，直接进入降级或人工介入。

熔断器（Circuit Breaker）模式适用于依赖外部服务的场景：当某个工具的失败率超过阈值时（如5次调用中4次失败），在一段时间内直接拒绝调用该工具（快速失败），自动切换到备选工具，同时定期发送「探测请求」检查服务是否恢复。

五、超时管理与执行监护

5.1 四级超时体系

每个执行步骤都需要多个维度的超时控制：

1. 单步工具调用超时：单次API调用的最大等待时间（如30秒）
2. 单步总耗时超时：包含重试在内的单步骤最大总时间（如90秒）
3. 子目标超时：完成一个子目标的最大时间（如5分钟）
4. 任务级超时：整个Agent任务的最大执行时间（如30分钟）

低层级超时触发重试/降级，高层级超时触发重规划或人工介入。

5.2 Watchdog模式

执行循环需要一个看门狗（Watchdog）线程，持续监控以下指标：

• 是否超过各级超时阈值
• 是否陷入死循环（相同步骤重复N次以上）
• Token消耗速率是否异常
• 内存/队列深度是否超过警戒线
• 是否有「进度停滞」迹象（长时间无新步骤输出）

Watchdog一旦检测到异常，立即向主循环注入中断信号，强制进入RECOVERING状态。

六、Checkpoint与状态持久化

6.1 为什么需要执行Checkpoint

Agent执行是长时运行过程，随时可能因崩溃、超时而中断。没有Checkpoint的Agent在重启后必须从零开始，之前的执行成果全部丢失。

6.2 Checkpoint设计三要素

• 快照粒度：每个步骤完成时做一次快照（细粒度，存储开销大）；每个子目标完成时做一次（粗粒度，丢失中间状态）
• 快照内容：执行状态机状态、已完成步骤及结果、当前步骤上下文、LLM调用历史、Token消耗统计、执行时间线
• 恢复策略：确定性步骤可跳过（使用上次输出），非确定性步骤必须重做，LLM调用步骤根据幂等性决定

6.3 LangGraph的Checkpoint实现

LangGraph提供了生产级的Checkpoint机制：每个节点执行后自动持久化状态到数据库（Postgres/SQLite/内存），支持按checkpoint_id回滚到任意历史状态，也支持「时间旅行」调试——从任意中间状态重新执行。这是目前开源Agent框架中最成熟的CheckPoint方案之一。

七、Human-in-the-Loop执行中断

7.1 何时需要人工介入

• 置信度低于阈值（LLM对当前步骤不确定）
• 安全护栏触发（检测到敏感操作）
• 预算耗尽预警（Token/时间即将超限）
• 计划重大变更（重规划改变了超过N个步骤）
• 用户主动中断（通过UI/API发送暂停信号）

7.2 中断点设计

优秀的Agent执行框架会在以下位置预置可中断点（Interrupt Points）：

• 步骤执行前（Plan-then-Execute模式）
• 工具调用前（涉及副作用的操作）
• 步骤语义单元完成后（交错执行模式）
• 重规划决策前

中断点本质上是一个状态机转换事件：EXECUTING → PAUSED，附带完整的当前状态上下文。

7.3 恢复机制

人工确认后恢复执行时，Agent需要：

1. 读取中断时的完整状态快照
2. 将人工反馈（批准/拒绝/修改指令）合并入上下文
3. 根据反馈决定下一步：继续原计划/执行修改后计划/重规划
4. 状态转换：PAUSED → EXECUTING

八、可观测性与执行追踪

8.1 执行追踪的三个层次

（a）步骤级追踪（Step-Level Trace）

每个工具调用、每次LLM推理、每个状态转换都记录为一个Span，包含输入输出、耗时、Token数、调用的工具名。这是最基本的追踪粒度，对应Langfuse、Phoenix Arize等工具的默认追踪级别。

（b）决策级追踪（Decision-Level Trace）

记录Agent在关键决策点的「为什么」——为什么选择了这个工具、为什么决定重试、为什么触发了改计划。需要LLM在决策时同步输出推理过程（Rationale）并持久化。

（c）语义级追踪（Semantic-Level Trace）

追踪用户意图到最终结果的完整链路：原始请求→意图理解→计划生成→步骤执行→中间结果→最终输出。这是端到端调试和用户体验分析的关键。

8.2 关键可观测指标

• 成功率：任务完成率 / 步骤成功率 / 工具调用成功率
• 延迟：端到端延迟P50/P95/P99 / 单步延迟分布 / LLM推理延迟
• 成本：每任务Token消耗 / 每步骤Token消耗 / 累计成本
• 循环指标：重试率 / 重规划率 / 人工介入率 / 死循环检测次数
• 质量指标：结果正确率 / 用户满意度 / 幻觉率

九、工程实践中的九大陷阱

陷阱1：无超时保护——某个工具调用卡住导致整个Agent挂起。解决：所有外部调用都必须设置超时，异步调用使用Future.get(timeout)。

陷阱2：无限重试——某个步骤因永久性错误反复重试到预算耗尽。解决：区分可重试错误和不可重试错误，后者立即进入降级。

陷阱3：上下文污染——重试时将之前的错误输出又重新喂给LLM，导致幻觉累积。解决：每次重试使用干净的上下文窗口，仅保留必要信息。

陷阱4：丢失执行状态——进程崩溃后所有中间结果丢失。解决：实现Checkpoint机制，每个步骤完成后持久化。

陷阱5：计划刚性——计划执行过程中环境变化但Agent死守原计划。解决：在关键checkpoint设置计划偏差检测，偏差超过阈值触发重规划。

陷阱6：错误传播放大——某个步骤的错误结果作为下一步的输入，导致雪崩。解决：每个步骤输出增加Schema校验和语义校验，不通过时立即中断。

陷阱7：Token黑洞——执行步骤过多导致上下文溢出或Token预算耗尽。解决：设置Token预算上限，超出时触发摘要压缩或人工介入。

陷阱8：并发安全——多个Agent实例或同一Agent的多个子任务并发修改共享状态。解决：乐观锁/悲观锁/无锁数据结构，关键状态变更使用原子操作。

陷阱9：缺失决策追踪——没有决策级追踪，出问题后无法定位「当时为什么这么决定」。解决：强制LLM在关键决策点输出Rationale并持久化。

十、生产级执行循环架构

综合前述所有设计原则，一个生产级Agent执行循环应包含以下九个层次：

1. 接口层：接收用户请求，创建任务实例，分配唯一trace_id
2. 规划层：生成或加载执行计划（步骤序列/DAG）
3. 调度层：从就绪队列取出待执行步骤，处理依赖关系
4. 执行层：实际调用工具/API，带超时和重试
5. 监护层：Watchdog持续监控，检测异常
6. 恢复层：异常处理策略引擎（重试→降级→重规划→人工介入）
7. 持久化层：每个步骤完成后的Checkpoint存储
8. 可观测层：全链路追踪、指标采集、日志聚合
9. HIL交互层：人工确认通道与状态同步

每一层都可以独立扩展和替换，形成插件化架构。这种分层设计使得工程团队可以逐步演进——先从执行层+监护层开始，逐步加入持久化层和可观测层，最终构建完整的九层体系。

十一、2026年执行循环前沿趋势

• 自适应执行（Adaptive Execution）：Agent根据历史执行数据动态调整超时阈值、重试预算、并发度等参数，形成自我优化的执行引擎
• 预测性监护（Predictive Watchdog）：通过LLM预测当前步骤是否会失败（基于相似历史模式），提前介入而不是事后补救
• 分布式检查点（Distributed Checkpointing）：多Agent协同任务的跨节点状态一致性保障，基于Raft/Paxos协议实现Agent状态机复制
• 形式化验证集成：关键安全路径的执行逻辑做形式化验证，保证「不会进入非法状态」，从数学层面消除特定类别的异常
• eBPF内核级监护：利用eBPF技术在内核层面监控Agent的系统调用，捕获传统监控手段无法感知的底层异常

十二、总结与决策框架

执行循环与异常处理是Agent从「实验室demo」走向「生产级系统」的必经之路。在选择具体实现方案时，建议按以下五个维度评估决策：

• 任务确定性高→Plan-then-Execute；低→Interleaved Execution
• 容错要求高→每个步骤加Checkpoint+重试+降级；低→简单重试即可
• 延迟敏感高→异步并行+预取；低→同步串行简化状态管理
• 调试需求强→三级追踪全开；弱→仅步骤级追踪
• 人机协作深→全程可中断+多级人工确认；浅→仅关键决策点中断

第41篇解决了「该做什么和怎么做」（规划），本篇解决了「做的时候出了问题怎么办」（执行与容错）。下一篇我们将进入第43部分：Agent安全与对齐护栏——从提示注入到行为边界的工程防线。