1. 项目概述:工具描述的工程化意义
在LLM应用开发中,工具描述(Tool Description)的质量直接影响着大模型对功能的理解和调用准确性。就像给人类同事交代任务时,模糊的指令会导致执行偏差一样,不清晰的工具描述会让LLM频繁误用API。这个问题在实际工程中尤为突出——我们团队在开发电商客服自动化系统时,就曾因为工具描述不当导致30%的API调用需要人工修正。
工具描述本质上是一种"机器可读的文档",核心包含三个关键字段:
- name:工具的唯一标识符
- description:自然语言的功能说明
- parameters:遵循JSON Schema规范的参数定义
这些描述会被转换成LLM能理解的提示词(prompt),指导模型在何时以及如何调用工具。一个典型的误用场景是:当description只写"获取用户信息"时,LLM可能在需要验证用户身份时也调用该接口,而实际上这个接口设计仅用于展示基本信息。这就是为什么我们需要像编写产品需求文档一样严谨地对待工具描述。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心字段设计原则
2.1 name字段的命名艺术
name字段不是简单的变量命名,而是LLM识别工具功能的"关键词标签"。我们在智能家居控制项目中验证过:将"light_control"改为"adjust_lighting_intensity"后,模型正确调用率提升了18%。
最佳实践:
- 采用动宾结构:如"calculate_shipping_fee"比"shipping"更明确
- 避免缩写:用"generate_report"而非"gen_rpt"
- 包含领域关键词:电商场景用"query_order_status"而非简单"get_status"
反例分析:
json复制// 问题案例
{
"name": "get_data",
"description": "获取数据"
}
这个定义会导致LLM在任何需要数据的场景都尝试调用,包括完全不适用的情况。
2.2 description的编写技巧
description需要达到"让新手开发者也一看就懂"的详细程度。我们在金融风控系统中发现,超过50字的description比简短描述减少42%的误调用。
黄金公式:
[执行条件] + [具体操作] + [
