第9章 异常处理、目标监控与资源优化

本章来源：综合自 Agentic Design Patterns 第11章（目标设定与监控）、第12章（异常处理与恢复）、第16章（资源感知优化）、第20章（优先级排序）、第21章（探索与发现中的多智能体协调）

核心问题 -- 本章要解答什么

前两章讨论了智能体如何编排流程（链式调用、路由、并行化）和如何与外部世界交互（工具使用、MCP）。但这些讨论都假设了一个理想场景：每次调用都能成功返回、系统资源充裕、任务能按预期推进。

现实远非如此。工具调用可能超时，API 可能返回错误码，LLM 可能生成不满足质量要求的输出，预算可能在任务中途耗尽，多个互相冲突的目标需要动态权衡。一个只会"执行"而不会"监控、应对和优化"的智能体，在生产环境中是脆弱的。

本章整合运行时管理的三个核心维度：目标设定与监控（智能体如何知道自己在朝正确方向前进）、异常处理与恢复（出错时如何检测、应对和恢复）、资源感知优化（如何在计算、时间和成本的约束下做出最优决策）。这三个维度共同构成了智能体的"运行时韧性"架构。

设计空间 -- 可选方案与取舍

9.1 目标设定与监控

9.1.1 为什么智能体需要明确的目标

没有目标的智能体只是一个反应式系统——收到输入就生成输出，但无法判断输出是否"足够好"。目标设定与监控模式将智能体从被动执行者转变为主动的目标驱动实体：它有一个需要达成的状态，有衡量进度的指标，有判断是否完成的标准。

这个模式的核心架构是一个迭代反馈循环：

设定目标 → 执行行动 → 评估结果 → 是否达标？
                                    ↓ 否
                              分析差距，调整策略
                                    ↓
                              重新执行行动 → 评估结果 → ...
                                    ↓ 是
                              任务完成

9.1.2 SMART 目标框架在智能体中的应用

来自管理学的 SMART 框架（Specific, Measurable, Achievable, Relevant, Time-bound）对智能体的目标设定同样适用：

• Specific（具体）：目标不是"写好代码"，而是"生成一个能通过所有单元测试的 Python 函数"
• Measurable（可衡量）：必须有可程序化检测的成功标准，如测试通过率、代码复杂度阈值、输出格式校验
• Achievable（可实现）：目标应在 LLM 的能力范围内。一个期望 LLM 一次生成完美代码的目标不如一个允许迭代改进的目标
• Relevant（相关）：子目标应服务于最终任务。避免设定导致智能体在无关方向上"精益求精"的子目标
• Time-bound（有时限）：设定最大迭代次数或超时阈值，防止智能体在无法达成的目标上无限循环

9.1.3 监控机制的设计

监控的核心问题是：谁来评判智能体的输出？ 主要有三种策略：

自我评估：同一个 LLM 既生成输出又评判质量。优点是简单直接，缺点是存在"自我认可偏差"——模型倾向于对自己的输出给出过高评价，难以发现自身的系统性错误。

分离评估：由独立的评估智能体（Critic Agent）或不同模型来评判。例如，用 GPT-4o 生成代码，用 Claude 审查代码质量。这种角色分离显著提高了评估的客观性，但增加了系统复杂度和成本。

客观验证：通过外部工具进行可程序化验证。运行单元测试、执行代码检查、验证输出格式。这是最可靠的监控方式，但仅适用于有明确可验证标准的任务。

实践中的最佳策略通常是分层组合：先用客观验证检查硬约束（格式正确、测试通过），再用 LLM 评估软约束（代码可读性、逻辑完整性）。

9.1.4 迭代代码生成：一个完整案例

以下流程展示了目标监控模式在代码生成中的典型应用：

1. 目标设定：接收编码问题和质量检查清单（简洁性、正确性、边界情况处理）
2. 初始生成：LLM 生成第一版代码
3. 自我审查：将代码和质量清单一起提交给评估 LLM，获得逐项反馈
4. 达标判断：评估 LLM 给出二值判断（True/False）
5. 迭代改进：如果未达标，将反馈注入上下文，重新生成改进版本
6. 终止条件：达标或达到最大迭代次数（如5次）

这个流程的关键设计决策在于：评估不是模糊的"好不好"，而是针对预定义的质量清单逐项检查。每次迭代都有明确的改进方向。但需要注意，当同一个 LLM 既写代码又评判质量时，它更难发现自己的系统性错误。更健壮的方案是将生成、审查、测试分配给不同的智能体角色。

9.2 异常处理与恢复

9.2.1 异常处理的三阶段模型

智能体的异常处理遵循检测-处理-恢复的三阶段架构：

错误检测（Detection）：识别异常的发生。包括：

• 工具输出校验：返回值是否为无效/格式错误
• API 错误码检查：404、500、429（限流）等
• 超时检测：响应时间超过阈值
• 输出一致性检查：LLM 输出是否偏离预期格式
• 环境状态监控：其他智能体或专用监控系统的异常检测

错误处理（Handling）：根据错误类型选择应对策略。五种基本策略：

策略	适用场景	描述
日志记录	所有错误	记录详细错误信息供后续调试分析
重试	暂时性错误（网络超时、服务限流）	使用相同或调整后的参数重新执行
回退	主路径失败	切换到备选工具或方法
优雅降级	部分功能不可用	维持核心功能，降低输出质量
通知	需要人工介入	向操作员或其他智能体发送告警

恢复（Recovery）：将系统恢复到稳定状态。四种恢复机制：

• 状态回滚：撤销错误操作的影响，恢复到上一个一致状态
• 诊断分析：深入调查错误根因，防止同类问题复发
• 自我纠正：调整计划、逻辑或参数，重新规划后续路径
• 问题升级：将复杂或严重问题委派给人类操作员或更高级系统

9.2.2 分层回退的架构实现

以下模式展示了在 Google ADK 框架中如何实现分层回退：

SequentialAgent（顺序编排）
  ├── primary_handler     → 尝试精确位置查询
  ├── fallback_handler    → 检查状态，失败时使用区域概况查询
  └── response_agent      → 综合结果，向用户呈现

这种架构的关键设计是通过共享状态协调回退逻辑：primary_handler 将成功/失败写入状态变量，fallback_handler 读取该状态决定是否接手。每个智能体的职责边界清晰——primary 负责尝试，fallback 负责兜底，response 负责呈现。

9.2.3 与反思模式的结合

异常处理与反思（Reflection）模式存在天然的协同关系。当初始尝试失败并触发异常时，不是简单地重试相同操作，而是启动一个反思过程：分析失败原因，生成改进的策略（如优化 prompt、调整参数），然后以更优的方式重新尝试。这种"失败驱动的自我改进"使异常处理从被动的错误恢复提升为主动的能力增强。

9.3 资源感知优化

9.3.1 资源约束的三个维度

实际部署的智能体系统面临三类资源约束：

• 计算资源：模型推理的 GPU/CPU 时间、内存占用
• 时间资源：用户对响应延迟的容忍度、任务截止时间
• 财务资源：API 调用成本、按 token 计费的费用

资源感知优化的核心问题是：在输出质量和资源消耗之间找到最优平衡点。不是所有任务都需要最强的模型，不是所有步骤都值得投入最多的计算。

9.3.2 动态模型切换

动态模型切换是资源优化中最直接的策略。核心思路是：用轻量模型处理简单任务，将重量级模型留给真正需要的复杂任务。

典型实现架构：

用户查询 → 复杂度分类器（路由智能体）
              ↓ simple
           快速廉价模型（如 GPT-4o-mini、Gemini Flash）
              ↓ reasoning
           强推理模型（如 o4-mini）
              ↓ internet_search
           搜索增强 + 中等模型（如 GPT-4o）

分类器本身可以有不同的实现精度：

• 简单规则：基于查询长度、关键词匹配。成本最低，但容易误判
• LLM 分类：用轻量 LLM 分析查询复杂度，输出分类结果。更准确，但增加一次额外调用
• ML 分类器：训练专用分类模型。最高效，但需要标注数据

9.3.3 顺序模型回退

当首选模型不可用（过载、限流、服务中断）时，系统自动切换到备选模型。这是异常处理与资源优化的交叉点。

{
  "models": ["anthropic/claude-sonnet-4-6", "gryphe/mythomax-l2-13b"],
  "fallback": "auto"
}

OpenRouter 等模型路由服务提供了开箱即用的顺序回退能力：按优先级列表尝试模型，某个模型失败则自动切换到下一个。最终成本和返回的模型标识符对应于实际完成计算的模型。

9.3.4 资源优化的完整技术栈

除动态模型切换外，资源感知优化包含一个完整的技术栈：

技术	作用	典型场景
动态模型切换	按任务复杂度选择模型	简单查询用小模型，复杂推理用大模型
自适应工具选择	按成本/延迟选择工具	选择免费 API 还是付费 API
上下文修剪与摘要	减少 prompt token 数	长对话历史的选择性保留
主动资源预测	预估未来负载	提前分配计算资源
成本敏感探索	优化多智能体通信成本	减少不必要的智能体间消息
学习型资源分配	根据反馈优化分配策略	持续改进路由决策
优雅降级与回退	资源不足时维持部分功能	高负载时降低输出质量但保持响应
可观测性	监控和分析 Agent 行为	Trace 分析、成本归因、性能瓶颈定位

9.4 优先级排序

9.4.1 为什么需要优先级排序

在复杂环境中，智能体面临大量潜在行动、相互冲突的目标和有限的资源。没有明确的优先级排序机制，智能体可能在低价值任务上浪费资源，错过关键的时间窗口，或在互相矛盾的目标之间无谓振荡。

优先级排序的核心要素：

• 标准定义：建立评估规则——紧急性、重要性、依赖关系、资源可用性、成本收益比
• 任务评估：根据标准对每个潜在行动打分或排序
• 调度逻辑：基于评估结果选择最优行动序列
• 动态重排序：根据环境变化（新事件、截止日期临近）实时调整优先级

9.4.2 多层次优先级

优先级排序发生在三个层次：

• 战略层：选择总体目标（"先完成 A 项目还是 B 项目？"）
• 规划层：在既定目标内排序子任务（"先搜索文献还是先写代码？"）
• 行动层：选择当前即时行动（"现在调用哪个 API？"）

这三个层次的决策粒度不同，但共享同一套评估框架。战略层更重视长期影响，行动层更重视即时可行性。

架构解析 -- 深入分析主流架构

9.5 批评智能体（Critic Agent）的架构角色

批评智能体在运行时管理中扮演着跨越目标监控和资源优化的关键角色。它不是简单的"判分器"，而是一个多功能的质量保障组件：

在目标监控中：批评智能体评估生成智能体的输出是否满足目标要求，提供具体的改进方向。这种评估比生成智能体的自我评估更客观，因为它以独立第三方的视角审视输出。

在资源优化中：批评智能体的反馈可以反向优化路由决策。如果 Flash 模型的输出被频繁评为不足，路由器就应该对类似查询使用更强的模型；如果 Pro 模型处理的某类任务被评为"过度投入"，路由器就应该将这类任务降级到更经济的模型。

在异常处理中：批评智能体可以作为异常检测的辅助手段——当输出质量持续下降时，可能指示系统存在潜在问题。

一个精心设计的批评智能体 prompt 需要明确：角色定位（评估者而非否定者）、评估维度（正确性、完整性、无偏见性）、反馈格式（结构化、可操作）、建设性原则（指出问题的同时提供改进方向）。

9.5.1 Agent 可观测性基础设施

批评智能体提供了智能层面的质量评估，但生产环境中还需要系统层面的可观测性基础设施——帮助开发者理解智能体"做了什么、花了多长时间、哪里出了问题"。

Agent 可观测性采用 Trace-Span-Metric 三层架构：

层级	含义	智能体场景中的对应
Trace	一次完整任务的端到端执行记录	从用户输入到最终输出的完整 Agent 调用链
Span	Trace 中的一个操作单元	单次 LLM 调用、工具执行、或子 Agent 调用
Metric	可聚合的数值指标	Token 消耗、延迟、成功率、成本

LangSmith（LangChain 团队）是目前最成熟的 Agent 可观测性平台。核心功能包括：完整 Trace 可视化（展示每步 LLM 调用的输入输出）、Playground 调试（修改中间步骤的输入并重新执行）、性能监控（延迟分布、Token 消耗趋势）、以及回归测试（将历史 Trace 作为测试用例）。

Langfuse 是开源替代方案，支持自托管部署。其核心优势在于数据主权——所有 Trace 数据存储在用户自己的基础设施中，适合对数据隐私有严格要求的企业场景。Langfuse 同样支持 Trace 可视化、成本追踪和自定义评估函数。

可观测性与批评智能体的集成形成了双层质量保障：可观测性基础设施提供系统级指标（延迟、成本、错误率），批评智能体提供语义级评估（输出质量、逻辑正确性）。两层信息的交叉分析能够发现单一层面难以捕获的问题——例如，"某类查询的延迟突然增加 3 倍"（系统级）+ "该类查询的输出质量未下降"（语义级）可能指示模型正在进行更深层的推理，而非系统故障。

9.6 Google Co-Scientist：探索与发现中的多维管理

Google Co-Scientist 提供了一个将目标监控、异常处理和资源优化融为一体的大型系统案例。它是一个多智能体科学研究框架，基于 Gemini LLM 构建，采用异步任务执行架构。

其核心智能体分工体现了运行时管理的多个维度：

• 生成智能体（Generation）：通过文献探索和模拟科学辩论生成初始假设
• 反思智能体（Reflection）：作为同行评审，批判性评估假设的正确性、新颖性和质量——这是目标监控的体现
• 排名智能体（Ranking）：使用基于 Elo 的锦标赛机制比较和排序假设——这是优先级排序的体现
• 进化智能体（Evolution）：持续改进排名靠前的假设——这是迭代改进的体现
• 邻近度智能体（Proximity）：聚类相似想法，辅助探索假设空间——这是资源感知探索的体现
• 元审查智能体（Meta-review）：综合所有审查的见解，识别共同模式并提供系统级反馈——这是跨维度协调的体现

该系统通过"测试时计算扩展"（test-time compute scaling）机制动态分配计算资源，将更多算力投入到更有希望的假设改进上。在验证研究中，系统对超过 200 个研究目标的分析表明，扩展测试时计算可持续提高假设质量（以 Elo 评级衡量）。

这个案例表明，运行时管理的三个维度不是独立模块，而是深度交织的系统特性。

关键实现决策 -- 工程实践中的关键选择点

9.7 终止策略的设计

迭代型智能体的一个核心问题是：何时停止？ 这需要在"追求完美"和"避免浪费"之间找到平衡。

策略	描述	风险
固定次数	设定最大迭代次数（如5次）	可能在目标即将达成时停止
达标终止	评估函数返回"通过"时停止	评估不准确可能导致过早或过晚停止
收敛检测	连续N次迭代改进幅度低于阈值时停止	可能在局部最优处停止
组合策略	达标终止 + 最大次数上限	更稳健，推荐的默认选择

组合策略是实践中的推荐默认：达标则停止，未达标但达到最大次数也强制停止，避免无限循环。

9.8 重试策略的选择

不同的错误类型需要不同的重试策略：

暂时性错误（网络超时、服务限流）：使用指数退避重试。第一次等待 1 秒，第二次等待 2 秒，第三次等待 4 秒。设定最大重试次数。

参数错误：不应直接重试相同请求。应将错误信息返回给 LLM，让其调整参数后重试。这是异常处理与反思模式的结合点。

永久性错误（权限不足、资源不存在）：立即回退到备选方案，不浪费时间在注定失败的重试上。

关键原则：将错误信息返回给 LLM，而非静默失败。LLM 可以根据错误信息做出智能决策——换用不同参数、选择备选工具、或向用户解释情况。

9.9 资源优化的粒度

资源优化可以在不同粒度上实施：

请求级优化：每个用户请求独立做路由决策。最简单，但无法利用跨请求的统计信息。

会话级优化：在一个对话会话内优化。前几轮可以用小模型建立上下文，复杂问题再切换大模型。

任务级优化：对复合任务内的不同子步骤分别优化。规划阶段用强模型，执行阶段用快速模型。这是最精细的优化粒度。

实际系统通常在任务级实施优化，因为同一个复合任务中不同步骤的计算需求差异显著。

9.10 安全边界

运行时管理需要特别关注安全边界：

• 重试上限：所有重试必须有硬上限，防止系统进入无限循环
• 资源预算：设定总成本或总 token 上限，超出时强制终止
• 回退兜底：确保回退链的末端有明确的"安全停止"——即使所有备选都失败，系统也应优雅地告知用户而非崩溃
• 人工升级通道：对于关键任务，始终保留人工接管的入口

前沿动态 -- 学术界/工业界最新进展

9.11 自适应资源分配策略

传统的资源优化依赖静态规则（"简单查询用小模型"）。前沿研究探索学习型资源分配：通过强化学习或在线学习，智能体根据历史性能数据动态调整路由策略。批评智能体的反馈被用作奖励信号——如果 Flash 模型的输出被频繁否定，系统自动提高该类查询使用 Pro 模型的概率。这种闭环优化使系统的资源效率随使用持续提升。

9.12 多智能体容错

在多智能体系统中，异常处理的复杂度显著增加。单个智能体的失败可能级联影响其他智能体。前沿研究方向包括：多智能体强化学习中的容错机制、异构多智能体 IoT 系统中的智能迁移（Intelligence Transfer）、以及基于共识协议的分布式故障恢复。

9.13 探索与利用的平衡

来自 Google Co-Scientist 的实践表明，智能体在目标追求中需要平衡"利用已知最优路径"与"探索未知可能性"。Elo 锦标赛机制提供了一种自然的平衡：排名高的假设获得更多改进资源（利用），但系统持续生成新假设并给予评估机会（探索）。这种探索-利用的动态平衡在自主研究、创意生成等开放式任务中尤为关键。

本章小结

运行时管理是智能体从"能工作"到"可靠工作"的关键跃迁。目标设定与监控给予智能体方向感和自我评估能力——它知道自己要去哪里、当前离目标多远。异常处理与恢复赋予智能体韧性——遇到错误时不是崩溃而是检测、应对和恢复。资源感知优化赋予智能体效率——在质量和成本之间做出合理权衡。优先级排序赋予智能体决策力——在多个竞争性选择中聚焦于最重要的行动。

工程实践中的核心决策包括：终止策略的设计（组合策略优于单一策略）、重试策略的选择（不同错误类型需要不同策略）、资源优化的粒度（任务级优化通常是最佳平衡点）、以及安全边界的设定（所有自动化循环都需要硬上限）。

⚠️ 已知局限：目标监控和异常处理本身的可靠性高度依赖评估器的质量。当Critic Agent使用与Producer相同的LLM时，两者共享相同的知识盲区——Critic无法发现Producer因知识缺失而产生的系统性错误。在资源优化方面，动态模型切换的路由准确率在实践中通常只有80-85%，约15%的查询会被路由到次优模型，导致质量或成本的浪费。此外，多层回退机制的测试覆盖率往往不足——许多回退路径只在极端条件下触发，平时难以验证其正确性。

这些维度不是独立存在的功能模块，而是深度交织的系统特性。批评智能体同时服务于目标监控和资源优化，回退机制同时属于异常处理和资源管理，优先级排序影响着目标追求和资源分配的每个决策。理解这种交织关系，是构建生产级智能体系统的前提。