GLM Tool Calling：工具描述与参数约束怎么写

工具调用（tool calling）效果差，问题往往不在模型，而在工具描述写得太随意。GLM-5/5.3 系列对结构化的 function calling 支持较好，thinking 模式下还会先推理再选工具，但前提是你把「什么时候用这个工具、参数填什么」讲清楚。这篇给两套可直接粘贴的写法模板，基于 BigModel API 的 tools 字段格式，细节以官方文档为准。

工具描述要回答三个问题

每个工具的 description 至少说清三件事：用途边界（什么场景该调它）、与其他工具的区别（避免选错）、返回值含义（模型拿到结果后怎么继续）。写成一句话是不够的，建议 2~4 行。

反例："description": "查询天气"——模型不知道该在什么时机调用，也不知道和「查询城市信息」怎么区分。

正例应该类似："当用户询问某城市当前天气或未来几天预报时调用。仅支持中国城市，不支持历史天气。若用户同时问穿衣建议，先调用本工具再基于返回结果回答。"

参数描述同理：query 写成 "查询关键词" 不如写成 "城市中文名，如：北京；不带省/区后缀"。GLM 在参数填报阶段主要依赖参数级 description，写得具体能显著降低幻觉参数。

模板一：单工具 + 严格参数约束

适合工具数量少、参数格式要求严的场景。关键是把约束写进 description 和枚举里，而不是指望模型自觉：

json
{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "search_flights",
        "description": "查询国内航班。当用户明确提到出发地、目的地和出行日期时调用。不支持国际航线；若用户未提供日期，先追问再调用。",
        "parameters": {
          "type": "object",
          "properties": {
            "from_city": {
              "type": "string",
              "description": "出发城市中文名，不含'市'字，如：上海"
            },
            "to_city": {
              "type": "string",
              "description": "到达城市中文名，不含'市'字，如：成都"
            },
            "date": {
              "type": "string",
              "description": "出发日期，格式 YYYY-MM-DD。'明天/后天'需结合对话中的当前日期换算"
            },
            "cabin_class": {
              "type": "string",
              "enum": ["economy", "business", "first"],
              "description": "舱位等级，用户未指定时默认 economy"
            }
          },
          "required": ["from_city", "to_city", "date"]
        }
      }
    }
  ],
  "tool_choice": "auto"
}

要点：required 只放真正必需的字段，可选项让模型按 description 里的默认规则处理；日期换算规则明确写出来，这是最容易出错的地方。

模板二：多工具场景 + 系统提示词分工

工具一多，模型容易选错。在 system prompt 里做职责划分，比堆描述更管用：

text
你有三个工具，调用规则如下：
1. search_docs：检索内部技术文档。用户问产品功能、API 用法时优先调用。
2. query_order：查询订单状态。仅当对话中出现订单号或用户明确要求查订单时调用。
3. create_ticket：创建工单。只有当 search_docs 未找到答案、且用户明确要求人工处理时才调用，调用前需向用户确认问题描述。

通用规则：
- 一次只调用一个工具，拿到结果后再决定下一步。
- 不要编造工具未返回的信息；工具返回为空时如实告知用户。
- 工具参数必须从对话上下文提取，禁止使用占位符（如 "xxx"、"待填写"）。

配合 tools 字段使用，每个工具的 description 可以写短一些，避免和系统提示词重复。GLM-5 系列在这种显式分工的写法下，多工具选择的准确率明显好于只靠 description 自描述。

参数约束的三个实用技巧

1. 能用 enum 就用 enum：状态、类型、语言这类有限取值，用枚举比在描述里写「请填入…之一」可靠得多。 2. 数值范围写进描述："取值 1~10，值越大结果越多样" 比 "temperature 参数" 有用。 3. 复杂结构用 nested object + 逐层 description：GLM 对嵌套 schema 支持不错，但层数建议控制在两层以内，太深的结构各模型的填报准确率都会下降。

另外，开启 thinking 模式对复杂多工具任务有帮助——模型会先梳理调用计划再动手，代价是延迟增加。简单查询类工具调用不必开。

常见坑

• description 里写示例值很有用："如：'2024-06-01'" 比纯格式说明更直观。
• 不要在参数里塞自由文本大类：比如让模型填 "user_intent"，拆成枚举字段更稳。
• 工具返回结果也要约束格式：返回 JSON 给模型时，在工具描述里说明返回结构，模型引用结果时不容易串字段。
• 与 GPT/Claude 对比的定位：各家对 schema 的解析细节略有差异（如 strict mode 的支持程度），同一份 tools 定义跨模型迁移时建议先小规模回归测试，以各官方文档为准。

写工具描述本质上是在写「给模型的 API 文档」：用途边界、参数含义、默认规则、异常处理，一个都不能少。把上面两套模板改成你自己的工具清单，跑几个真实 case 对比调参前后的 tool call 命中率，比凭感觉调更有效。