GLM 5.3 Function Calling 使用指南：如何配置并调用外部工具

随着 GLM-5.3 模型在 2026 年 8 月正式上线 API，许多开发者开始将其应用于自动化代理场景。与旧版本不同的是，GLM-5.3 强制启用了深度思考功能，这意味着原本习惯通过禁用思考来降低延迟的工具调用流程需要进行调整。如果你正在开发需要调用外部工具的 Agent 应用，了解如何在强制思考的前提下正确配置 Function Calling，以及如何处理旧代码迁移，是确保应用平稳运行的关键。本篇指南将直接给出覆盖工具定义、模型请求、结果解析三步的完整流程，帮助你快速跑通 GLM-5.3 的外部工具调用。

调用 GLM 5.3 Function Calling 需要准备什么？

Function Calling 允许大模型识别用户意图，并输出结构化参数来调用外部函数。在 GLM-5.3 中，这一能力遵循 OpenAI Chat Completion 标准协议。在开始配置工具调用前，需要确保开发环境满足以下基础条件：

1. 获取 API Key：需要在智谱开放平台或 Z.ai 注册并获取有效的 API Key。
2. 安装 SDK：推荐使用官方提供的 zai-sdk Python 包，或者使用兼容 OpenAI 协议的 SDK。可以通过 pip install zai-sdk 进行安装。
3. 了解协议兼容性：GLM-5.3 的 Function Calling 使用 tools 和 tool_choice 参数来定义和控制工具调用。如果你熟悉 OpenAI 的工具调用方式，迁移到 GLM-5.3 的学习成本会很低。

需要特别注意的是，GLM-5.3 强制启用了思考功能，不再支持通过 thinking.type: "disabled" 来禁用思考。这意味着在每次请求中，模型都会进行一定程度的推理，这会影响响应延迟和 Token 消耗。

第一步：如何用 JSON Schema 格式定义工具供 GLM 5.3 调用？

要让模型知道有哪些工具可用，需要通过 tools 参数以 JSON Schema 格式定义工具。一个完整的工具定义通常包含名称、描述和参数结构。

以下是一个定义“获取天气”工具的示例：

[
  {
    "type": "function",
    "function": {
      "name": "get_weather",
      "description": "获取指定城市的当前天气信息",
      "parameters": {
        "type": "object",
        "properties": {
          "location": {
            "type": "string",
            "description": "城市名称，例如：北京"
          },
          "unit": {
            "type": "string",
            "enum": ["celsius", "fahrenheit"],
            "description": "温度单位"
          }
        },
        "required": ["location"]
      }
    }
  }
]

在这个定义中：

• name 是模型调用时使用的函数名。
• description 非常关键，它帮助模型判断在什么情况下应该调用这个工具。
• parameters 定义了函数接受的参数，模型会根据这个结构从用户的提问中提取信息并填充。

第二步：如何配置请求参数让 GLM 5.3 决定调用工具？

定义好工具后，需要组装请求参数发送给模型。除了常规的 messages 和 tools，GLM-5.3 还需要配置思考相关的参数。

tool_choice 参数用于控制模型的调用策略：

• "auto"：模型自主决定是否调用工具。
• "none"：模型不调用任何工具。
• {"type": "function", "function": {"name": "get_weather"}}：强制模型调用指定的工具。

由于 GLM-5.3 强制启用思考，你需要设置 reasoning_effort 参数。该参数支持 low、high、max 三档，默认为 max。在工具调用场景下，如果对延迟敏感，可以将其设置为 low。

以下是一个完整的 Python 请求示例：

import os
from zai import ZaiClient

client = ZaiClient(api_key=os.environ.get("ZAI_API_KEY"))

tools = [
  {
    "type": "function",
    "function": {
      "name": "get_weather",
      "description": "获取指定城市的当前天气信息",
      "parameters": {
        "type": "object",
        "properties": {
          "location": {
            "type": "string",
            "description": "城市名称"
          }
        },
        "required": ["location"]
      }
    }
  }
]

messages = [
    {"role": "user", "content": "今天北京天气怎么样？"}
]

response = client.chat.completions.create(
    model="glm-5.3",
    messages=messages,
    tools=tools,
    tool_choice="auto",
    thinking={
        "type": "enabled",
        "reasoning_effort": "low"  # 控制推理深度
    }
)

第三步：拿到模型返回的工具调用指令后，如何解析参数并执行？

当模型决定调用工具时，返回的响应中会包含工具调用的指令。你需要解析出函数名和参数，在本地执行对应的函数，然后将结果作为 tool 角色的消息再次传给模型，让模型生成最终的自然语言回复。

以下是解析与二次调用的代码示例：

import json

# 假设这是本地实现的天气查询函数
def get_weather(location):
    # 实际应用中这里应该调用真实的天气 API
    return f"{location} 今天晴，气温 25 度。"

response_message = response.choices[0].message
messages.append(response_message)

# 检查是否有工具调用
if response_message.tool_calls:
    for tool_call in response_message.tool_calls:
        function_name = tool_call.function.name
        function_args = json.loads(tool_call.function.arguments)
        
        # 执行本地函数
        if function_name == "get_weather":
            result = get_weather(**function_args)
            
            # 将工具执行结果加入消息历史
            messages.append({
                "tool_call_id": tool_call.id,
                "role": "tool",
                "name": function_name,
                "content": result,
            })
    
    # 再次请求模型，获取最终回复
    second_response = client.chat.completions.create(
        model="glm-5.3",
        messages=messages,
        tools=tools,
        thinking={
            "type": "enabled",
            "reasoning_effort": "low"
        }
    )
    
    print(second_response.choices[0].message.content)
else:
    print(response_message.content)

这个过程遵循标准的 ReAct 模式：模型思考是否需要工具 -> 调用工具 -> 接收工具结果 -> 生成最终回答。

旧代码迁移到 GLM 5.3 会遇到什么报错？怎么改？

如果你之前使用的是 GLM-5.2 或更早的版本，迁移到 GLM-5.3 时最容易遇到的报错就是关于 thinking 参数的。

常见报错：请求失败，提示 thinking 参数无效或不支持 disabled 类型。

原因：GLM-5.3 强制启用思考功能，不再支持 thinking.type: "disabled"。

修改方法：
将原来代码中的：

thinking={
    "type": "disabled"
}

修改为：

thinking={
    "type": "enabled",
    "reasoning_effort": "low"  # 或 "high", "max"
}

如果不显式设置 reasoning_effort，模型将使用默认的 max 档位，这可能导致较高的延迟和 Token 消耗。对于简单的工具调用，建议从 low 开始测试。

如何实时获取工具调用参数？如何控制推理成本？

在需要实时反馈的 Agent 场景中，流式返回工具调用参数非常重要。GLM-5.3 支持流式工具调用，需要在请求中同时设置 stream=True 和 tool_stream=True。

stream = client.chat.completions.create(
    model="glm-5.3",
    messages=messages,
    tools=tools,
    stream=True,
    tool_stream=True,  # 启用流式工具调用
    thinking={
        "type": "enabled",
        "reasoning_effort": "low"
    }
)

关于成本控制，GLM-5.3 的 API 定价与 GLM-5.2 相同：

• 输入：$1.40 / 百万 Token
• 缓存输入：$0.26 / 百万 Token
• 输出：$4.40 / 百万 Token

由于强制思考会产生额外的推理 Token，控制成本的主要手段是合理设置 reasoning_effort。在不需要复杂逻辑推理的简单工具调用场景（如查天气、查库存），使用 low 档位可以显著减少 Token 消耗和响应时间。

GLM 5.3 工具调用有哪些限制？遇到问题怎么查？

在使用 GLM-5.3 的 Function Calling 时，需要注意以下限制：

1. 模态限制：目前 GLM-5.3 仅支持文本模态，不支持直接在工具调用中传入图片或音频。
2. 协议限制：如果你订阅了 GLM Coding Plan（包括已过期的订阅），目前仅支持通过 OpenAI Chat Completion 协议调用，不能使用其他自定义协议。
3. 速率限制：平台存在并发请求数限制，具体数值按用户等级和模型类型设定。如果在高并发场景下遇到限流报错，建议检查账户等级对应的速率限制策略。

常见问题排查建议：

• 如果模型没有调用工具，检查 tool_choice 是否设为了 none，或者工具的 description 是否写得不够清晰。
• 如果参数提取错误，检查 parameters 中的 description 是否对必填字段有明确说明。

常见问题 FAQ

Q: GLM 5.3 的 Function Calling 参数格式与旧版兼容吗？
A: GLM-5.3 遵循 OpenAI 标准协议，使用 tools 和 tool_choice 参数，在工具定义和请求结构上与常规 OpenAI 兼容写法一致。但 thinking 参数有破坏性变更，必须修改。

Q: 为什么我的 GLM 5.3 请求报错提示 thinking 参数无效？
A: 因为你可能沿用了旧版的 thinking.type: "disabled"。GLM-5.3 强制启用思考，需要改为 enabled 并设置 reasoning_effort。

Q: 如何在 GLM 5.3 中降低工具调用的推理成本？
A: 将 reasoning_effort 设置为 low，可以减少推理深度，降低 Token 消耗和延迟。

Q: GLM 5.3 支持流式返回工具调用参数吗？
A: 支持。需要在请求中同时设置 stream=True 和 tool_stream=True。

Q: 订阅了 GLM Coding Plan 的用户调用 GLM 5.3 有什么限制？
A: 订阅过 GLM Coding Plan 的账号（含已过期）目前仅支持使用 OpenAI Chat Completion 协议进行调用。

选择建议：谁适合用，谁应该先观望

适合直接使用的开发者：

• 正在构建需要调用外部 API 的 Agent 应用的团队。
• 需要长上下文窗口（支持 1M 上下文）和长输出（最大 128K）的复杂任务开发者。
• 对代码生成和自动化工作流有明确需求，且愿意通过调整 reasoning_effort 来平衡延迟与效果的用户。

建议先观望或继续使用旧版的场景：

• 对响应延迟极其敏感，且不希望产生任何思考 Token 的简单工具调用场景。由于 GLM-5.3 强制思考，即使设为 low 也会有额外的推理过程，如果旧版 GLM-5.2 的禁用思考模式已经能满足需求且对成本控制要求极高，可以暂不迁移。
• 需要多模态工具调用（如直接处理图片输入并触发工具）的应用，目前 GLM-5.3 仅支持文本模态。

下一步建议：
如果你决定迁移，建议先在一个非生产环境的测试分支中修改 thinking 参数，使用 low 档位跑通基础的工具调用流程，评估延迟和效果后再逐步推向上线。