失败是常态
在Function Calling系统的实际运行中，函数调用失败的概率比你想象的要高。根据我们的统计，在一个生产环境中，大约15-20%的函数调用会遇到某种形式的失败。
这些失败包括：参数错误（模型传了不正确的参数）、API超时（后端服务响应慢）、API返回错误（权限不足、资源不存在等）、模型幻觉（调用了不存在的函数）、参数缺失（模型没有提供必需参数）。
如果没有完善的错误处理机制，这些失败会导致糟糕的用户体验——系统卡住、回复错误、反复重试。
错误分类和分级
我们将函数调用错误分为三个级别：
L1-可自动恢复：参数格式错误（如日期格式不对）、参数值轻微偏差（如"北京"vs"北京市"）。这些错误可以通过自动修正来解决。
L2-需要模型理解：API返回了一个有意义但非预期的结果（如"该航班已售罄"）。模型需要理解这个结果并调整策略。
L3-需要人工介入：权限错误、系统错误、数据异常。这些错误超出了模型的处理能力，需要人工介入。
错误处理框架
Step 1: 参数验证。 在函数执行前，先验证参数的有效性。日期格式、枚举值、数值范围、字符串长度等。如果参数无效，返回具体的错误信息给模型。
Step 2: 优雅降级。 如果某个函数调用失败，不要让整个对话崩溃。给用户一个友好的回复，解释发生了什么，并提供替代方案。
Step 3: 智能重试。 对于可自动恢复的错误（L1），自动修正参数后重试。对于L2和L3错误，不要盲目重试——把错误信息反馈给模型，让模型决定下一步。
Step 4: 超时处理。 每个函数调用都应该有超时设置。如果API在2秒内没有响应，返回超时信息给模型，让模型决定是等待还是换一个方案。
Step 5: 降级路径。 如果主函数调用失败，尝试备选方案。比如，如果实时天气API失败了，尝试用缓存的数据；如果缓存也没有，就告知用户"暂时无法获取天气信息"。
模型在错误处理中的角色
模型在错误处理中扮演着"决策者"的角色。当函数调用失败时，模型需要：
- 理解错误信息（“这个航班已售罄"意味着什么？）
- 决定下一步策略（换一个航班？换一个日期？换一个目的地？）
- 与用户沟通（告知用户实际情况，征求用户意见）
这要求模型具备一定的"推理"能力，而不仅仅是"调用函数"的能力。2026年，Claude 4和GPT-4o在错误处理上的表现最好，它们能够理解复杂的错误信息并做出合理的决策。
实战案例
场景一：参数错误。 用户说"查一下北京明天的天气”，模型调用get_weather(city=“北京”, date=“tomorrow”)。API返回错误：“date必须是YYYY-MM-DD格式”。模型理解错误信息，自动修正为get_weather(city=“北京”, date=“2026-07-14”)，重试成功。
场景二：API返回"售罄"。 用户想订某个航班，模型调用book_flight，API返回"该航班已售罄"。模型理解售罄的含义，查询同航线其他航班，返回给用户：“抱歉，您选择的航班已售罄。以下是同一航线其他可用的航班…”
场景三：API超时。 模型调用search_hotels，API在2秒内没有响应。系统返回超时信息给模型。模型告诉用户：“酒店搜索系统目前响应较慢，请稍等片刻，我正在重试…”
错误处理的设计原则
快速失败：不要等待不可靠的API。设置合理的超时，快速失败，快速反馈。
用户知情：不要让用户不知道发生了什么。当函数调用失败时，告知用户，并提供替代方案。
优雅降级：即使部分功能不可用，系统的基本功能仍然应该正常工作。
记录和告警：记录所有函数调用失败的日志，设置告警规则。如果某个函数的失败率突然升高，应该立即通知到运维团队。
结论
函数调用失败不是"bug"，而是系统设计的一部分。一个好的错误处理机制，可以让你的Function Calling系统在大部分失败场景下仍然保持可用。如果你还没有认真的错误处理设计，现在就是时候了。