> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 工具复杂性对AI代理的影响
- URL: https://www.hubwiz.com/blog/tool-complexity-impacts-on-ai-agents/
- Published: 2025-02-24T03:53:32.000Z
- Updated: 2025-02-24T03:53:32.000Z
- Description: 本文将注意力转向选择准确性——AI代理为给定任务选择正确工具并生成正确的调用规范的能力。
- Author: admin
- Tags: APPLICATION, AGENT, #Import 2026-10-14 14:41

在我们之前的[讨论](https://medium.com/@achan2013/how-many-tools-functions-can-an-ai-agent-has-21e0a82b7847?ref=hubwiz.com)中，我们探讨了AI代理可以处理的工具数量（“数量”）如何影响令牌消耗。现在，我们将注意力转向**选择准确性**——AI代理为给定任务选择正确工具并生成正确的调用规范的能力。随着工具数量和复杂性的增加，选择准确性可能会下降，导致效率低下、错误和糟糕的用户体验。

在这篇文章中，我们将研究“质量”：

- 工具**描述**如何影响准确性。
- **界面复杂性**在工具选择中的作用。
- 减少选择挑战的**架构策略**。
- 编写有效工具描述和参数的**最佳实践**。

在本讨论中，我们关注**单次交互工具选择**——在这种情况下，AI必须在一个交互中选择正确的工具，而不依赖于之前的对话历史。

## 1、工具数量对选择准确性的影响

AI代理可以访问的工具越多，选择正确的工具就越困难。两个关键的研究基准突显了这一挑战：

> **Nexus功能调用排行榜**

**Nexus功能调用排行榜（**[**NFCL**](https://huggingface.co/spaces/Nexusflow/Nexus%5FFunction%5FCalling%5FLeaderboard?ref=hubwiz.com)）评估AI模型的功能选择。比较不同类别的结果可以揭示工具数量如何影响选择准确性。

- **VirusTotal类别** → 包含**12个简单的API（因此有12个工具）用于分析可疑文件和URL。由于每次请求只需要一个函数调用**，选择相对简单。
- **OTX类别** → 包含**9个API**与Open Threat Exchange交互。它也是一个简单的基准，模型通常能实现**高精度分数**。

**结论：**即使VirusTotal和OTX都有简单的API，模型在OTX上的表现也优于VirusTotal。VirusTotal工具数量的增加可能是性能下降的原因。

> **最近的ReAct代理基准测试（2025年2月）**

Langchain团队最近发布的一项[实验](https://blog.langchain.dev/react-agent-benchmarking/?ref=hubwiz.com)评估了**ReAct代理**的表现，测试了AI代理在添加更多工具和指令时的表现变化。

- 实验发现，**随着领域（工具类别）数量的增加，准确性下降**。
- 需要**多个函数调用**的任务看到的准确性下降更大。

实验设置：

- **测试了5个模型：**claude-3.5-sonnet, gpt-4o, o1, o3-mini, llama-3.3–70B
- **每个领域运行30项任务两次：**日历调度（4个工具）和客户服务（9个工具）
- 添加无关领域后重新运行相同任务：最终测试有14个领域和117个工具

**结论：**从1到14个领域的准确性大幅下降

- **日程安排任务：**
- **gpt-4o的准确性从单个领域和4个工具的43%下降到7个领域和51个工具的仅2%。**
- **llama-3–3–70b在所有情况下都失败了。**
- **客户服务任务：**
- **gpt-4o的准确性从单个领域和9个工具的58%下降到7个领域和51个工具的仅26%。**
- llama-3–3–70b从1个领域到7个领域的准确性从21%下降到0%。

这些发现强调了拥有**太多工具**——特别是当**结合不相关的工具**且**缺乏预选择策略**时——会显著降低性能。

**Composio函数调用基准**

上述性能评估中的一个共同点是，通过更好的提示和工具描述可以提高准确性。例如，[Composio函数调用基准](https://github.com/ComposioHQ/Composio-Function-Calling-Benchmark/blob/master/README.md?ref=hubwiz.com)测试了50个函数调用问题，每个问题必须从8个函数模式中选择。基准评估了几种模式优化技术，并测量了由此产生的准确性，范围从大约**33%（无优化）到大约74%（应用多种优化）**，这是一个显著的改进。有关所有优化技术的详细描述可以在基准网页上找到。

在类似实验中，[Gentoro](https://github.com/gentoro-GT/Composio-Function-Calling-Benchmark?ref=hubwiz.com)创建了更贴近特定提示的等效函数，然后运行相同的基准测试。结果显示所有测试用例的准确性达到100%，证明了设计符合用户需求的工具比简单地镜像API接口更有价值。通过定义更接近用户与系统交互方式的接口，该实验能够实现卓越的性能和准确性。然而，这种方法需要额外的实施努力，因为它涉及对业务使用案例的更深入理解，并调整API签名以优化不同的使用场景。

**结论：**工具设计与其描述和优化一样重要，对选择准确性成功至关重要。有效地平衡以用户为中心的设计与计算效率将在开发能够在广泛使用场景中持续提供高性能结果的工具方面发挥关键作用。

## 2、界面复杂性对选择准确性的影响

选择正确的函数只是第一步。下一个挑战是**生成正确的函数输入**。三个关键因素影响准确性：

- 工具参数的数量（更多的参数会增加混淆）。
- 工具界面中使用的数据结构的复杂性。
- 工具规格说明是否详尽。

> **NVD库与VirusTotal和OTX**

对[NFCL中的NVD库类别](https://huggingface.co/spaces/Nexusflow/Nexus%5FFunction%5FCalling%5FLeaderboard?ref=hubwiz.com)进行的分析发现，模型在NVD库类别上的表现不如VirusTotal或OTX。

- **NVD库类别**只包括**两个API**，所以选择应该很简单。
- 然而，每个API有**30个参数**，使得AI难以正确映射输入。
- **结论：这表明即使工具集很小**，如果参数设计太复杂，也会导致选择错误。

## 3、如何编写有效的工具描述和参数

[**伯克利函数调用排行榜（BFCL）**](https://gorilla.cs.berkeley.edu/blogs/12%5Fbfcl%5Fv2%5Flive.htm?ref=hubwiz.com)提供了有关函数调用中参数数量和复杂性如何影响AI模型性能的宝贵见解。在第二版中，平均参数数量为**四个参数**，最复杂的函数有**28个参数**。这种参数数量的变化直接影响模型准确选择和执行函数的能力。

- 此外，BFCL V2强调，在实际应用中，模型需要从多个选项中选择适当函数的情况更为普遍。这强调了设计具有可管理参数数量的函数以增强选择准确性和整体性能的重要性。
- **结论：**良好的工具描述可以显著提高选择准确性。让我们看一些例子。

> 示例1：模糊/不清楚的数据定义

如果工具需要多个输入，使用基于JSON模式的**结构化数据定义**可以使AI更容易选择和正确使用。

❌ **坏例子：**

```
{   
  “name”: “stock_info”,   
  “description”: “Get stock market data.”,   
  “parameters”: {   
    “ticker”: “Stock symbol”,   
    “date”: “Date”   
  }   
}

```

🔴 *为什么这是坏的？*

- 函数名称太通用。
- 描述没有澄清提供的股票数据是什么。
- 没有指定日期或股票代码输入的格式。

✅ **好例子：**

```
{   
  “name”: “get_stock_data”,   
  “description”: “Retrieves real-time or historical stock market data, including price, volume, and trends.”,   
  “parameters”: {   
    “ticker”: {   
      “type”: “string”,   
      “description”: “Stock symbol of the company (e.g., ‘IBM’ for IBM.).”   
    },   
    “date”: {   
      “type”: “string”,   
      “format”: “YYYY-MM-DD”,   
      “description”: “Date for historical stock data retrieval (leave blank for real-time data).”   
    }   
  }   
}

```

🟢 *为什么这更好？*

- **精确的函数名称**（“get\_stock\_data”明确表示检索）遵循“{操作}*{实体}*{数据}”的约定。 ——虽然没有固定的规则来命名一个函数，但我们可以遵循简单的格式，如“**{操作}*{实体}*{数据}**”，例如“get\_stock\_quote”、“update\_product\_price”、“query\_flight\_schedule”、“update\_account\_address”。
- **扩展的描述**（指明实时或历史数据）。
- **结构化的参数**（确保AI正确解释输入）。

> 示例2：差的工具描述与有效的工具描述

❌ **差的工具描述：**

```
{   
  "name": "weather_info",   
  "description": "Get weather details for a location.",   
  "parameters": {   
    "location": "User's location",   
    "unit": "Unit of temperature"   
  }   
}

```

🔴 *为什么这是坏的？*

- **模糊的函数名称**（“weather\_info”没有指明检索什么信息）。
- **不清楚的描述**（什么样的天气详情？当前天气还是预报？）。
- **差的参数描述**（“unit”是指摄氏度/华氏度吗？）。

✅ **好的工具描述：**

```
{   
  “name”: “get_weather_data”,   
  “description”: “Retrieves the current temperature, humidity, and forecast for a given location.”,   
  “parameters”: {   
    “location”: {   
      “type”: “string”,   
      “description”: “City name or geographic coordinates for which weather data is requested.”   
    },   
    “unit”: {   
      “type”: “string”,   
      “enum”: [“Celsius”, “Fahrenheit”],   
      “description”: “Preferred unit for temperature display.”   
    }   
  }   
}

```

🟢 *为什么这更好？*

- **清晰且描述性的函数名称**（“get\_weather\_data”指明它检索天气数据）。
- **详细的描述**（澄清提供的信息）。
- **定义良好的参数**（包括类型、有效值和详细描述）。

> 示例3：简单的参数设计与复杂的参数设计（采购用例）

让我们举一个例子，AI代理选择工具以**在采购系统中查找产品**。

**❌ 过于复杂的参数结构（对AI来说更难处理）**

```
{   
  “name”: “search_product_catalog”,   
  “description”: “Finds products in the procurement catalog based on various filters.”,   
  “parameters”: {   
    “category”: {   
      “type”: “object”,   
      “properties”: {   
        “department”: {   
          “type”: “string”   
        },   
        “subcategory”: {   
          “type”: “string”   
        }  
      },   
      “description”: “Department and subcategory of the product.”   
    },   
    “specifications”: {   
      “type”: “object”,   
      “properties”: {   
        “brand”: {   
          “type”: “string”   
        },   
        “material”: {   
          “type”: “string”   
        },   
        “size”: {   
          “type”: “string”   
        }   
      },   
      “description”: “Product specifications.”   
    },   
    “price_range”: {   
      “type”: “object”,   
      “properties”: {   
        “min_price”: {   
          “type”: “number”   
        },   
        “max_price”: {   
          “type”: “number”   
        }   
      },   
      “description”: “Minimum and maximum price range.”   
    },   
    “availability”: {   
      “type”: “string”,   
      “enum”: [“in_stock”, “out_of_stock”, “backorder”],   
      “description”: “Availability status.”   
    }   
  }   
}

```

🔴 *为什么这是坏的？*

- **太多的嵌套字段**（例如，category → subcategory，specifications → \[brand, material, size\]）。
- **迫使AI推理深层对象结构**，增加了出错的风险。
- **由于深度嵌套导致更高的令牌使用量**。

**✅ 简化，对AI友好的结构（更好地提高选择准确性）**

```
{   
  “name”: “search_product_catalog_by_brand”,   
  “description”: “Finds a product in the procurement catalog based on simple filters.”,   
  “parameters”: {   
    “query”: {   
      “type”: “string”,   
      “description”: “Keywords for searching the product (e.g., ‘office chair ergonomic’).”   
    },   
    “category”: {   
      “type”: “string”,   
      “description”: “Main product category (e.g., ‘Office Supplies’, ‘Furniture’).”   
    },   
    “brand”: {   
      “type”: “string”,   
      “description”: “Preferred brand name (optional).”   
    },   
    “price_min”: {   
      “type”: “number”,   
      “description”: “Minimum price filter.”   
    },   
    “price_max”: {   
      “type”: “number”,   
      “description”: “Maximum price filter.”   
    },   
    “availability”: {   
      “type”: “string”,   
      “enum”: [“in_stock”, “out_of_stock”, “backorder”],   
      “description”: “Filter by product availability.”   
    }   
  }   
}

```

🟢 *为什么这更好？*

- **将嵌套字段扁平化为简单的参数**（没有复杂的对象结构）。
- **使用灵活的“查询”参数**而不是强制结构化输入。
- **缩小选择范围**（例如，“按品牌”）而不是支持所有可能的选择标准。
- **通过减少深度嵌套来简化决策复杂性**。

## 4、关于工具复杂性的指导原则？

没有硬性限制你可以在给定工具中包含多少参数或多深的嵌套结构，但这里有一些一般性的指导原则：

- **1–5个参数且无嵌套（1层）** → 模型易于管理。
- **6–10个参数最多2层嵌套** → 输入错误的可能性增加，尤其是在没有结构化指导（即未使用JSON模式）的情况下。
- **10个以上参数或超过2层嵌套** → 错误映射参数的风险高，尤其是在没有结构化指导的情况下。

## 5、提高工具选择准确性的策略

**✅ 1\. 通过更好的提示和工具描述提高准确性**

**减少参数数量**

- \*\*只包含必要的输入。\*\*删除冗余或可选字段。
- 如果某个参数**很少被需要**，将其作为**可选默认值**处理，而不是每次都要求。
- **将复杂的操作拆分成多个工具**，每个工具参数较少，并在描述或新工具集中明确说明。

**展平嵌套结构**

- 不要使用**深层嵌套的对象**，尽可能使用基于字符串的表示。
- 将多个相关参数合并成**一个字段**（例如，类别而不是部门和子类别）。

**使用枚举列表减少自由形式的输入**

- 如果参数的有效值有限，**使用枚举列表**而不是让AI生成自由文本。
- 示例：

```
{   
  “availability”: {   
    “type”: “string”,   
    “enum”: [“in_stock”, “out_of_stock”, “backorder”],   
    “description”: “Filter by product availability.”   
  }   
}

```

- **为什么？** AI不需要推断可接受的值。

**预格式化复杂数据以减少认知负担**

- 使用基于JSON模式的**预结构化格式**，而不是要求AI组成复杂的输入。
- 示例：不要要求一个结构化的**JSON对象**用于产品规格，而是允许一个**单一的格式化字符串**（“品牌: Logitech, 颜色: 黑色, 尺寸: 中号”）。

**✅ 2\. 层次化工具选择：子代理和监督者**

不要让单一的AI代理处理所有工具，而是使用**针对特定领域的子代理**，由**监督代理**路由请求。

🔹 **示例：**

1. 用户请求**财务数据**。
2. **监督代理**路由到**财务代理**。
3. **财务代理**选择正确的API（例如，股价与预算分析）。

✅ 3\. 动态工具激活

不要在每次请求中发送所有工具，而是根据用户查询**预先过滤工具**。

🔹 **示例：**

- 如果用户询问**天气**，只有天气相关的工具应该被发送。
- 如果查询是关于**金融**，则省略天气工具以提高选择准确性。

✅ 4\. 监控和微调模型性能

- **跟踪误分类率**（哪些工具被错误选择以及原因？）。
- **根据失败模式**优化工具描述和参数。
- **尝试不同的LLM**（某些模型在选择方面表现更好）。

### 6、最终想法

工具选择准确性对于构建可靠的AI代理至关重要。**主要收获：**

- **过多的工具**会降低准确性——尽可能使用层次化选择。
- **模糊的工具描述**会导致选择错误——确保名称、描述和参数的清晰性。
- **复杂的工具界面**会增加混淆——优化参数结构并使用动态激活。

---

原文链接：[How Tool Complexity Impacts AI Agents Selection Accuracy](https://achan2013.medium.com/how-tool-complexity-impacts-ai-agents-selection-accuracy-a3b6280ddce5?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处