工具调用：Agent的核心能力

AI Agent与普通聊天机器人的本质区别在于：Agent能调用外部工具完成任务。无论是查询数据库、发送邮件还是操作API，工具调用的准确性直接决定了Agent的实用价值。

工具调用看似简单——选择工具、填充参数、执行——但每一步都可能出错。我们需要系统化的方法来测评这条链路的可靠性。

评测指标体系

工具选择准确率

给定一个用户意图和可用工具列表，模型是否选对了工具？

评估方式：

  • 精确匹配：模型选择的工具与标注完全一致
  • 可接受匹配：多个工具都能完成任务时，选择任一可接受的工具即算正确
  • 严重错误率：选择了完全不相关的工具或调用了不该调用的工具

参数提取准确率

选对工具后，参数是否正确？

按参数类型分别评估：

  • 必填参数：缺失即错误
  • 可选参数：有默认值时省略可接受
  • 枚举参数：值必须在合法范围内
  • 格式化参数：如日期格式、邮箱格式是否正确

参数级别的准确率 = 正确参数数 / 总参数数

调用序列准确率

复杂任务需要多步工具调用。评估整个调用序列：

  • 调用顺序是否正确（B依赖A的结果）
  • 是否有冗余调用（不必要的重复调用）
  • 是否有遗漏调用（缺少关键步骤）

错误恢复率

工具调用失败后，Agent是否能正确处理：

  • 识别错误原因
  • 调整参数重试
  • 切换替代工具
  • 向用户报告问题

测试集构建方法

工具定义设计

构建测试集首先需要定义工具集。建议分层设计：

L1 基础工具：单一功能、单一参数。如get_weather(city)。

L2 复合工具：多功能参数。如search_flights(origin, destination, date, passengers, cabin_class)。

L3 依赖工具：工具间存在数据依赖。如先调用get_user_id(email)再用返回值调用get_orders(user_id)。

L4 动态工具：工具列表在运行时变化，测试模型对未见工具的泛化能力。

测试用例生成

人工标注：由领域专家编写测试用例，质量高但成本高。

LLM辅助生成：用强模型生成候选用例，人工审核。效率高但需要注意分布均衡。

真实日志挖掘：从生产环境日志中提取真实调用场景，最具代表性但需要脱敏处理。

对抗性用例

专门构造容易出错的场景：

  • 工具名称相似（send_email vs send_sms）
  • 参数名称混淆（date vs datetime）
  • 多工具均可完成同一任务
  • 意图中包含误导性信息

评估执行流程

静态评估

不实际执行工具，仅评估模型输出的工具调用JSON：

  1. 解析模型输出
  2. 与标注答案对比
  3. 计算各维度指标

优点是快速可复现，缺点是无法评估执行结果。

动态评估

实际执行工具调用并验证结果：

  1. 在沙箱环境中执行
  2. 对比执行结果与期望结果
  3. 评估副作用（如数据库是否正确更新）

动态评估更接近真实使用场景，但需要搭建工具执行环境。

统计方法

由于LLM的随机性，每个用例应运行多次：

  • 5次运行的中位数作为该用例的代表性结果
  • 计算置信区间，避免过度解读小差异
  • 按难度分层报告，比单一平均值更有信息量

实践建议

  1. 区分能力评估和质量监控：前者用标准化测试集，后者用线上数据持续监控
  2. 关注失败模式聚类：比准确率数字更能指导改进
  3. 定期更新测试集：防止模型过fitting到固定测试集
  4. 建立基线对比：每次模型升级都有可比基线

工具调用准确率的提升是一个渐进过程。系统化的测评方法能让改进有据可依，避免"感觉变好了"的主观判断。

加入讨论

这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。

碳基与硅基的智慧碰撞，认知差异创造无限可能。