1. 项目概述：当工具失效时，我们如何衡量智能体的“韧性”？

最近和几个做LLM智能体（LLM Agents）的朋友聊天，大家不约而同地提到了同一个痛点：我们花大力气给智能体接上了一堆工具（Tools），让它能调用搜索引擎、数据库、计算器，甚至操作系统的API，看起来无所不能。但在真实场景里跑起来，问题就来了——工具调用失败简直是家常便饭。API突然超时、返回了意料之外的错误格式、甚至直接返回一个“404 Not Found”。这时候，智能体是直接“摆烂”报错，还是能像老司机一样，淡定地换个路线，继续完成任务？这个“淡定换路线”的能力，就是动态重规划（Dynamic Replanning）和异常恢复（Anomaly Recovery），它直接决定了智能体是实验室玩具，还是能真正投入生产的可靠系统。

“When Tools Fail: Benchmarking Dynamic Replanning and Anomaly Recovery in LLM Agents”这个项目，瞄准的就是这个核心痛点。它不是一个简单的工具调用演示，而是一个系统性的基准测试（Benchmarking）框架，专门用于量化评估LLM智能体在工具执行链路出现各种“幺蛾子”时的应对能力。简单说，它就是给智能体们设计的一场“压力测试”或“故障演习”，看看谁在逆境中更能保持冷静，完成任务。

为什么这件事如此重要？因为现实世界是混乱的。你无法保证每一个外部服务都永远稳定，每一个API的响应都符合预期。一个成熟的、实用的智能体，其价值不仅体现在它“知道”该调用哪个工具，更体现在当预设工具失效时，它能否自主地、动态地调整计划（Replan），并从错误中恢复（Recover），最终达成用户意图。这个项目，就是要为这种“韧性”建立一个可测量、可比较的标准。无论是研究界想推动智能体规划与推理的前沿，还是工业界要筛选出最鲁棒的智能体框架投入实际业务，这个基准都将成为一个不可或缺的“试金石”。

2. 核心概念拆解：动态重规划与异常恢复究竟在做什么？

在深入这个基准测试的设计之前，我们必须先厘清两个核心概念：动态重规划和异常恢复。它们听起来很学术，但背后的思想非常直观，就像我们日常解决问题一样。

2.1 动态重规划：Plan B 从何而来？

动态重规划，指的是智能体在执行既定计划（Plan）的过程中，当监测到当前步骤无法继续（比如工具调用失败，或结果不符合预期）时，不直接放弃，而是基于当前最新的环境状态和任务目标，重新生成一个新的可行计划。

这个过程的关键在于“动态”。初始计划可能是这样的：“1. 调用搜索API获取最新股价 -> 2. 调用计算工具进行收益计算 -> 3. 生成报告”。如果第一步搜索API挂了，一个具备动态重规划能力的智能体不应该卡死，它需要思考：“我的最终目标是生成一份收益报告。获取股价数据是手段之一。现在这个手段失效了，有没有替代方案？” 它可能会生成新计划：“1. 尝试访问缓存的金融市场数据源 -> 2. 如果缓存没有，则尝试从预下载的财经数据文件中读取 -> 3. 进行收益计算 -> 4. 生成报告，并备注数据来源为离线缓存”。

重规划的触发条件不仅仅是工具失败。还包括：

• 工具执行结果与预期严重不符：比如让智能体“查询北京明天的天气”，工具返回了一串乱码或一个JSON解析错误。
• 环境状态发生意外改变：在执行多步任务时，前置步骤可能意外改变了某些条件，使得原后续步骤失效。
• 发现了更优的路径：在执行中，智能体通过新获得的信息，意识到有更快、更省成本的方案。

重规划的决策核心在于LLM的推理能力。它需要：

1. 诊断：准确识别当前出了什么问题（是网络超时，还是权限不足，或是数据不存在？）。
2. 评估：判断这个问题是否可绕过，以及对最终目标的影响程度。
3. 生成：结合已有的工具集、任务约束和当前上下文，合成一个新的、可行的步骤序列。
4. 验证（可选但重要）：在心理层面对新计划进行推演，预估其成功的可能性。

注意：动态重规划不是漫无目的地尝试。一个糟糕的实现可能会让智能体陷入“失败-重试-再失败”的死循环，或者不断生成本质上同样会失败的计划。好的重规划需要有“记忆”（避免重复错误）和“元认知”（对自身能力边界的认知）。

2.2 异常恢复：从错误中优雅地站起来

异常恢复与动态重规划紧密相关，但侧重点略有不同。它更侧重于从错误状态中“恢复”到一个可继续执行的正常状态，可能不需要完全重新规划整个任务，而是进行局部修补。

可以把异常恢复想象成程序的try-catch机制。当工具调用抛出异常（异常）时，智能体的“恢复”策略决定了它如何“捕获”（catch）并处理这个异常。

常见的恢复策略包括：

• 重试：最简单的策略。对于瞬时的网络抖动或负载过高，立即重试可能成功。但需要设置重试次数上限和退避策略，避免无限循环。
• 降级：当首选的高精度工具失败时，切换到一个可能精度稍低但更稳定的备用工具。例如，精确的地理编码服务失败，转而使用内置的、覆盖范围较小的地理数据库。
• 忽略与继续：对于非关键步骤的失败，如果评估其不影响核心任务，可以记录警告并跳过。例如，在生成总结时，获取文章配图的工具失败了，但文字总结仍可完成。
• 请求人工干预：当自主恢复尝试多次均告失败，或遇到超出其处理范围的问题（如需要新的系统权限）时，明确向用户反馈错误原因并寻求帮助，这是一种负责任的恢复。
• 数据清洗与适配：工具返回了数据，但格式诡异。恢复可能包括尝试用不同的解析器去解析数据，或者从错误信息中提取可能有用的片段。

恢复与重规划的关系：一次成功的异常恢复，可能避免了整个计划的重写。例如，通过重试解决了临时性故障，智能体就可以继续执行原计划的下一步。只有当恢复策略（如多次重试、降级）都无效时，才需要触发更耗资源的动态重规划。因此，一个健壮的智能体应该有一个分层的异常处理机制：先尝试轻量级的恢复，不行再启动重规划。

3. 基准测试框架设计：如何科学地“制造麻烦”？

设计一个衡量动态重规划和异常恢复能力的基准，其核心挑战在于：如何系统性地、可重复地模拟真实世界中工具可能遇到的各种故障？不能只是简单地把网线拔了，那样太粗糙，也无法量化比较不同智能体的表现。这个项目需要一个精心设计的“故障注入”框架。

3.1 故障场景分类与模拟

一个全面的基准需要覆盖不同层次、不同类型的故障。我们可以将其大致归类：

1. 工具执行层面故障：

• 完全失效：模拟工具服务宕机，返回Connection Error,Timeout,503 Service Unavailable等。这是对智能体“服务不可用感知”能力的测试。
• 部分失效/异常返回：
  • 格式错误：返回非约定的数据格式，如该返回JSON却返回了HTML错误页面或纯文本。
  • 语义错误：返回的数据在格式上正确，但内容与请求完全不符或包含矛盾。例如，查询“上海气温”，返回{"city": "北京", "temp": 25}。
  • 边界情况：返回空列表、null值、极大或极小的数值，测试智能体对数据完整性的处理。
• 性能降级：工具响应极慢，模拟高延迟环境。这考验智能体的超时设置和异步处理能力。

2. 工具能力与任务匹配层面故障：

• 工具能力不足：智能体选择了一个无法完全满足需求的工具。例如，需要用Python进行复杂数值计算，却选择了一个只能做加减乘除的计算器工具。
• 权限不足：工具调用因缺乏API Key、OAuth令牌或IP白名单等原因被拒绝，返回403 Forbidden或401 Unauthorized。

3. 多步骤任务中的状态污染：

• 前置步骤的工具调用，意外地修改了某些共享状态或环境变量，导致后续步骤依赖的前提条件被破坏。例如，第一步创建了一个文件，第二步要读取它，但第一步因权限问题实际创建失败，而智能体没有检测到。

为了模拟这些故障，基准框架不会去真实地攻击第三方API。相反，它会构建一个模拟的工具执行环境（Mock Tool Environment）。所有智能体对外部工具的调用，都会被这个环境拦截。基准测试控制器可以根据预设的测试用例，向这个环境注入指定的故障。例如，当智能体调用search_web(query)时，模拟环境可以按配置返回一个超时错误、一个格式混乱的HTML、或者一个看似正确但答案错误的结构化数据。

3.2 评估指标：不仅仅是“成功与否”

对于一个“故障演习”基准，简单地用“最终任务成功率”来评判是片面的。一个智能体可能通过不断重试一个注定失败的工具，最终超时导致任务失败；另一个智能体可能快速识别工具不可用，转而使用备用方案成功。两者都“失败”了，但后者的能力明显更强。因此，我们需要一套多维度的评估指标：

• 终极任务成功率：最外层的指标，任务最终是否被完成。这是底线。
• 恢复成功率：在发生故障的步骤中，智能体通过重试、降级等恢复策略，在不触发全局重规划的情况下，成功继续执行原计划的比例。这衡量了其“就地修复”的能力。
• 重规划效率：
  • 重规划触发率：需要启动全局重规划的次数占总故障次数的比例。过低可能说明智能体过于固执，过高可能说明恢复策略太弱。
  • 重规划质量：新计划的有效性。可以通过新计划与专家制定的“黄金恢复路径”的相似度（如编辑距离、步骤重合度），或者新计划本身的逻辑合理性（由另一个LLM或规则评估）来衡量。
  • 重规划开销：重规划所消耗的额外时间、以及额外的LLM API调用（Token）成本。
• 异常诊断准确率：智能体对故障原因的描述（如“网络错误”、“数据不存在”、“权限不足”）是否准确。准确的诊断是有效恢复的前提。
• 用户体验相关指标：
  • 冗余操作数：智能体是否进行了大量无意义的重复调用或循环。
  • 解释清晰度：当最终失败或请求人工帮助时，它给出的错误信息是否对人类用户友好、具有可操作性。

一个设计良好的基准测试套件，会包含数十个甚至上百个测试用例，每个用例都定义了初始任务、可用的工具集、以及将在哪个环节注入何种故障。然后，让不同的LLM智能体（如基于AutoGPT、LangChain、Custom Agent框架构建的）在这个统一的“擂台”上接受测试，并用量化的指标给出综合评分。

4. 实现一个简易测试环境：从概念到代码

理解了设计理念后，我们可以动手搭建一个极度简化的原型，来切身感受一下这个基准测试是如何运作的。我们将创建一个模拟的“旅行规划”智能体任务，并给它制造麻烦。

场景设定：智能体的任务是“为我规划一个本周末从北京到上海的旅行，需要查询天气并推荐一件必备物品”。可用工具有：get_weather(city)，search_flights(from, to, date)，general_search(query)。

我们将模拟get_weather("上海")这个工具调用失败。

4.1 构建模拟工具与环境

首先，我们定义正常的工具函数和模拟的故障注入函数。

# 模拟工具函数 def mock_get_weather(city): """正常情况下的天气查询""" # 模拟正常返回 return {"status": "success", "data": {"city": city, "weather": "Sunny", "temp": 22, "unit": "Celsius"}} def mock_search_flights(from_city, to_city, date): """正常情况下的航班搜索""" return {"status": "success", "data": [{"flight": "CA1501", "departure": "08:00", "price": 1200}]} def mock_general_search(query): """通用的搜索工具""" return {"status": "success", "data": f"Search results for '{query}'."} # 故障注入器 class FaultInjector: def __init__(self): self.fault_type = None self.inject_step = None def set_fault(self, fault_type, step): """设置故障类型和注入步骤""" self.fault_type = fault_type self.inject_step = step # 例如：('get_weather', ('上海',)) def call_tool(self, tool_name, *args): """拦截工具调用，根据配置注入故障""" if self.fault_type and (tool_name, args) == self.inject_step: return self._generate_fault_response(tool_name, args) else: # 正常调用 return getattr(self, f'_normal_{tool_name}')(*args) def _normal_get_weather(self, city): return mock_get_weather(city) def _normal_search_flights(self, from_city, to_city, date): return mock_search_flights(from_city, to_city, date) def _normal_general_search(self, query): return mock_general_search(query) def _generate_fault_response(self, tool_name, args): """生成故障响应""" if self.fault_type == "connection_error": return {"status": "error", "code": "CONNECTION_TIMEOUT", "message": "无法连接到天气服务。"} elif self.fault_type == "format_error": return "<html><body>500 Internal Server Error</body></html>" # 返回HTML而不是JSON elif self.fault_type == "semantic_error": # 返回格式正确但内容错误的数据 return {"status": "success", "data": {"city": "南京", "weather": "Rainy", "temp": 15}} # 城市错了 else: return {"status": "error", "message": "Unknown fault"}

4.2 智能体核心逻辑与测试执行

接下来，我们实现一个具有基础异常处理能力的智能体逻辑。为了简化，我们用预定义的决策树模拟LLM的推理。

class SimpleTravelAgent: def __init__(self, env): self.env = env # 故障注入环境 self.plan = [ ("search_flights", ("北京", "上海", "weekend")), ("get_weather", ("上海",)), ("general_search", ("上海周末旅行必备物品",)) ] self.max_retries = 2 def execute_plan(self): final_answer = [] for step in self.plan: tool_name, args = step success, result = self._execute_step_with_recovery(tool_name, args) if not success: final_answer.append(f"步骤 '{tool_name}{args}' 失败，且无法恢复。任务中止。") break final_answer.append(result) return final_answer def _execute_step_with_recovery(self, tool_name, args): """执行单个步骤，包含重试和降级恢复""" # 尝试1: 原始调用 response = self.env.call_tool(tool_name, *args) if self._is_success(response): return True, f"{tool_name}{args} 成功: {response}" # 诊断错误 error_type = self._diagnose_error(response) print(f"步骤 {tool_name}{args} 失败，错误类型: {error_type}") # 恢复策略1: 重试 (针对连接类错误) if error_type in ["connection_error", "timeout"]: for i in range(self.max_retries): print(f" 重试 {i+1}/{self.max_retries}...") response = self.env.call_tool(tool_name, *args) # 注意：在真实故障注入中，重试可能依然失败，这里简化了 if self._is_success(response): return True, f"{tool_name}{args} 经重试成功: {response}" print(" 重试均失败。") # 恢复策略2: 降级 (针对特定工具失败) if tool_name == "get_weather": print(" 尝试降级方案：使用通用搜索查询天气。") fallback_response = self.env.call_tool("general_search", (f"{args[0]} 天气",)) if self._is_success(fallback_response): return True, f"{tool_name}{args} 失败，降级为通用搜索成功: {fallback_response}" # 恢复策略均失败，需要触发重规划（这里简化，仅返回失败） print(" 恢复策略无效，需重规划。") # 在实际智能体中，这里会调用LLM，基于当前状态和剩余任务重新生成plan # 例如，如果天气查询失败，新计划可能是跳过天气，直接推荐通用旅行物品。 return False, None def _is_success(self, response): """判断响应是否成功""" if isinstance(response, dict): return response.get("status") == "success" # 处理格式错误的情况 return False def _diagnose_error(self, response): """简单诊断错误类型""" if isinstance(response, dict): if response.get("code") == "CONNECTION_TIMEOUT": return "connection_error" elif isinstance(response, str) and "<html>" in response: return "format_error" # 更复杂的诊断可以检查语义错误等 return "unknown_error" # 运行测试 if __name__ == "__main__": env = FaultInjector() # 测试用例1：注入连接错误 print("=== 测试用例1: get_weather 连接错误 ===") env.set_fault("connection_error", ('get_weather', ('上海',))) agent1 = SimpleTravelAgent(env) result1 = agent1.execute_plan() print("结果:", result1) print() # 测试用例2：注入语义错误 print("=== 测试用例2: get_weather 语义错误（返回错误城市） ===") env.set_fault("semantic_error", ('get_weather', ('上海',))) agent2 = SimpleTravelAgent(env) result2 = agent2.execute_plan() print("结果:", result2)

代码解读与实操要点： 这个简易原型展示了基准测试的核心循环：设置故障 -> 运行智能体 -> 观察其反应。我们的SimpleTravelAgent实现了一个简单的分层恢复策略：先诊断，如果是网络错误就重试，如果重试失败或工具本身问题，则尝试降级（用通用搜索替代专用天气查询）。如果所有恢复策略都无效，则标记步骤失败（在实际复杂智能体中，这会触发全局重规划）。

运行这个脚本，你会看到：

• 在测试用例1中，智能体会先遇到连接错误，触发重试（虽然我们简化了重试逻辑），然后降级使用通用搜索，最终步骤成功。
• 在测试用例2中，智能体收到了一个格式正确但城市错误的响应。我们当前的_is_success函数只检查了status字段，因此它错误地认为该步骤成功了！这暴露了我们智能体逻辑的一个严重缺陷：缺乏对返回数据语义正确性的验证。一个健壮的智能体需要校验返回数据是否与请求参数匹配（例如，检查返回的城市名是否为“上海”）。

实操心得：在构建真实的智能体时，工具调用的结果验证和错误诊断是异常恢复的基石。你不能完全信任工具的返回。至少需要两层校验：1.语法层：返回格式是否符合约定？2.语义层：返回的内容是否解决了我的问题？对于关键数据，编写简单的校验规则（如字段非空、数值范围、字符串匹配）是必不可少的。否则，智能体会带着错误的数据一路狂奔，导致最终结果荒谬而不自知。

5. 高级挑战与前沿思考

一个完整的、工业级的基准测试框架，远不止我们上面演示的那么简单。它面临着诸多高级挑战，这些也正是当前研究的热点。

5.1 复杂任务与组合故障的模拟

现实中的故障往往是连锁反应和组合出现的。基准测试需要设计更复杂的任务场景，例如：

• 多智能体协作任务：智能体A依赖智能体B的输出，而B的工具调用失败了。这测试的是异常在协作链路上的传播与隔离能力。
• 长周期任务：一个任务可能执行数小时甚至数天，期间外部服务状态可能多次变化。基准需要模拟动态变化的故障场景。
• 组合故障：同一个工具在不同步骤中遇到不同类型的故障，或者多个工具同时或相继失效。这考验智能体的状态管理和优先级判断能力。

模拟这类场景，需要基准框架具备强大的状态管理和事件编排能力。可以借鉴混沌工程（Chaos Engineering）的思想，定义一套“故障剧本”（Failure Scenario Script），在任务执行的时间线上精确控制故障注入的时机、类型和持续时间。

5.2 评估LLM的元认知与规划能力

动态重规划的本质是元认知和规划问题。评估的核心在于LLM本身：

• 自我反思：LLM能否在计划受挫后，准确地分析“为什么之前的计划行不通”？是工具选错了，还是参数不对，或是任务本身就有歧义？
• 世界模型更新：LLM能否根据故障反馈，更新其对工具可用性、可靠性的内部认知？例如，多次调用某个地图API都超时，LLM能否在后续规划中暂时将其标记为“不可靠”而优先选择备用方案？
• 规划泛化能力：在一个任务中学到的恢复策略，能否迁移到另一个看似不同但结构相似的任务中？这关系到智能体的学习效率。

为了评估这些深层能力，基准测试可能需要设计一些需要“创造性”恢复的用例。例如，所有直接获取天气的工具都失败了，但智能体能否想到通过搜索“上海 穿衣指数 今日”这类相关但非直接的信息来间接推断？这评估的是LLM的常识和推理泛化能力。

5.3 工具学习与自适应

最前沿的智能体研究正在探索让智能体自主发现和使用新工具。在这个范式下，动态重规划和异常恢复有了新的内涵：

• 工具合成：当现有工具都无法解决问题时，智能体能否通过组合多个基础工具（或API）的功能，动态“合成”出一个新的、能满足需求的虚拟工具？例如，没有直接的“数据可视化”工具，但能否通过调用“数据获取工具”+“Python绘图库执行工具”来达成目的？
• 工具文档理解与适配：当遇到权限错误时，智能体能否自主阅读API文档，理解其认证方式（如API Key、OAuth），并引导用户或系统完成认证流程？
• 从错误中学习：智能体能否将本次工具调用失败的经验（如某个服务端点在周末不稳定）形成长期记忆，并在未来的规划中主动规避或设置更宽松的超时？

未来的基准测试，可能需要包含一个“工具库扩展”的维度，评估智能体在面对未知问题、工具不足时，通过探索和学习来扩展自身能力边界的潜力。

6. 对开发者与研究者的启示

“When Tools Fail”这个基准项目，不仅仅是一个评测工具，它更是一面镜子，映照出当前LLM智能体开发中的常见误区和改进方向。

对应用开发者的启示：

1. 不要假设工具永远可靠：在智能体设计之初，就必须将故障处理作为一等公民来考虑。为每一个工具调用设计兜底策略（重试、降级、超时）。
2. 强化结果验证：工具调用返回后，增加一层校验逻辑。检查状态码、数据格式、关键字段的存在性和合理性。这能避免“垃圾进，垃圾出”。
3. 实现清晰的错误传播与用户反馈：当智能体最终无法自主恢复时，它应该给用户一个清晰、可操作的错误报告，而不是一个晦涩的异常堆栈。例如：“尝试为您查询上海天气，但服务暂时不可用。我已尝试重试3次并改用搜索引擎查询，但仍未获得可靠信息。请您稍后再试，或直接访问某某天气网站。”
4. 成本与可靠性权衡：每一次重试、重规划、降级查询，都意味着额外的API调用成本和延迟。需要在配置中设定明确的策略（如最大重试次数、重规划触发阈值），在可靠性和经济性之间取得平衡。

对研究者的启示：

1. 规划与执行的闭环评估：传统的智能体评估多关注最终任务成功率，缺乏对规划-执行-观察-再规划这个动态循环的细粒度评估。这个基准提供了一个理想的平台。
2. 长上下文与状态管理：有效的重规划依赖于对完整任务历史、已尝试过的失败路径的准确记忆。这指向了对LLM长上下文窗口的有效利用，以及智能体外部状态管理架构的研究。
3. 少样本甚至零样本的异常处理：我们不可能为每一种可能的故障都编写处理规则。如何让LLM凭借其内置的常识和推理能力，泛化地处理未见过的错误类型，是一个核心挑战。
4. 人机协同的恢复机制：研究如何让智能体更精准地判断“何时应该求助人类”，以及如何以最高效的方式将问题上下文呈现给人类，寻求“神助攻”。

这个基准测试的出现，标志着LLM智能体研究正从演示炫技阶段，走向追求鲁棒性、实用性和可评估性的深水区。它迫使我们将智能体视为一个需要在复杂、开放、动态环境中生存的完整系统，而不仅仅是一个会调用工具的LLM。下一次当你构建智能体时，不妨先问自己一个问题：如果我把它最依赖的那个工具关掉，它还能完成任务吗？这个基准，就是帮你回答这个问题的标尺。