ASP.NET Extensions 项目中的 AI 函数调用错误处理机制优化

在 ASP.NET Extensions 项目中，开发团队近期对 AI 函数调用（Function Calling）的错误处理逻辑进行了深入讨论和优化。这项改进主要针对 AI 功能调用时的异常处理机制，旨在提供更灵活、更安全的错误处理方式，同时防止潜在的资源浪费问题。

原有机制分析

在之前的实现中，系统提供了两种基本的错误处理模式：

1. RetryOnError=false 模式

   • 当发生异常时，系统会进行最后一次尝试获取答案
   • 在此次尝试中，所有工具（tools）都不可用
   • 目的是在不要求应用开发者捕获 AIFunction 中错误的情况下，生成"抱歉，操作失败"的响应

2. RetryOnError=true 模式

   • 发生异常时，系统会持续循环直到达到 MaximumIterationsPerRequest 限制
   • 默认情况下这个限制是无限的

存在的问题

原有设计存在几个明显的不足：

1. 循环终止机制不够严格，可能导致资源浪费
2. "Retry"命名不够准确，容易引起误解
3. 配置方式不够灵活，无法满足不同场景的需求
4. 缺乏对连续错误的限制机制

优化方案

经过深入讨论，团队提出了以下优化方案：

1. 更严格的循环终止控制

• 默认将 MaximumIterationsPerRequest 设置为 10（具体数值待定）
• 新增 MaximumConsecutiveErrorsPerRequest 参数，默认值为 3
• 这些限制共同作用，可有效防止以下情况：
  • LLM 无限调用问题函数
  • 提示注入攻击导致 LLM 无限调用成功函数

2. 错误处理模式重构

• 用 FunctionInvocationErrorHandlingMode 替代原有的 RetryOnError
• 提供两种基本模式：
  • Throw：不捕获异常，直接重新抛出（适用于非聊天循环场景）
  • Retry：相当于原有的 RetryOnError=true
• 默认使用 Retry 模式，依靠 MaximumConsecutiveErrorsPerRequest 限制重试次数

3. 配置方式优化

• 将错误处理模式配置从 FunctionCallingChatClient 移到 ChatOptions
• 允许在每次调用时单独设置
• 通过类层次结构实现扩展性，支持自定义错误处理逻辑

简化后的最终方案

经过进一步思考，团队决定采用更简洁的设计：

1. 循环控制参数

   • 默认 MaximumIterationsPerRequest = 10
   • 新增 MaximumConsecutiveErrorsPerRequest = 3

2. 移除 RetryOnError 参数

   • 默认情况下，LLM 最多有 2 次额外尝试机会
   • 如需禁用重试，设置 MaximumConsecutiveErrorsPerRequest ≤ 1
   • 如需实现"最后一次无工具尝试"，可通过添加中间件实现

技术实现要点

1. 错误计数机制

   • 系统会跟踪连续错误次数
   • 当达到 MaximumConsecutiveErrorsPerRequest 限制时终止循环

2. 历史记录增强

   • 每次失败的工具调用都会在历史记录中添加错误信息
   • 帮助 LLM 在下一次尝试时调整行为

3. 中间件扩展

   • 开发者可以通过添加中间件实现自定义错误处理逻辑
   • 例如：检测到失败工具调用后，将 ToolMode 设置为 None

实际应用建议

1. 聊天场景

   • 保持默认设置，允许有限次数的自动重试
   • 利用错误信息帮助 LLM 自我修正

2. 结构化输出场景

   • 设置更严格的错误限制
   • 考虑添加自定义中间件处理特定错误类型

3. 高安全性要求场景

   • 将 MaximumConsecutiveErrorsPerRequest 设为 1
   • 快速失败并返回错误，减少潜在攻击面

这项改进使 ASP.NET Extensions 的 AI 函数调用功能更加健壮和安全，同时保持了足够的灵活性以满足不同应用场景的需求。开发者现在可以更精确地控制错误处理行为，防止资源滥用，并实现更复杂的自定义错误处理逻辑。