Function Calling ：让大模型 “连接外部世界” 的关键能力

工具定义（Function Definitions）：告诉模型 “有哪些工具可用”，核心包含三部分：
- name：工具唯一标识（如get_weather，用于后续匹配实际函数）；
- description：工具用途说明（如 “根据经纬度获取当前温度”，帮助模型判断是否匹配诉求）；
- parameters：工具所需参数（含参数类型、必填项、描述，如latitude（数字型，必填）、longitude（数字型，必填））。
用户诉求（Prompt）：用户的原始需求（如 “请告诉我天津的天气”）。

第二步：模型的核心决策的输出

模型接收信息后，完成三个关键动作：

理解匹配：判断 “用户诉求是否需要调用工具”（如 “查天气” 需要调用get_weather，“你好吗” 无需调用任何工具）；
行动选择：若需要调用，从工具清单中选中对应的工具（如选中get_weather）；
参数生成：按工具的参数定义，生成结构化参数（如从 “天津” 提取经纬度latitude=39.12、longitude=117.20）。

最终模型输出 “工具调用指令”，包含：调用的工具名、对应的参数（通常为 JSON 格式）。

第三步：结果回调（可选）

对话流场景：需将工具执行结果（如{"temperature":23,"weather":"Sunny"}）回传给模型，模型结合 “原始诉求 + 工具结果” 生成自然语言回复（如 “天津当前气温 23℃，天气晴朗”）；
非对话流场景：无需模型生成最终回复，仅需工具调用结果触发业务流程（如 “根据用户诉求生成下单参数后，直接传给订单系统完成下单”）。

2.2 影响效果的关键因素

工具描述的清晰度：description越具体，模型越容易匹配诉求（如 “获取经纬度对应的实时气温（摄氏度）” 比 “查天气” 更精准）；
参数定义的准确性：明确required（必填项）、参数类型（如number/string），避免模型生成无效参数（如少传经纬度）；
用户诉求的明确性：若诉求缺失关键信息（如仅说 “查天气” 未指定地点），模型可能无法生成有效参数，需进一步追问用户。

三、实际调用：基于 OpenAI 接口的三步落地

以 “查询天津天气” 为例，基于 OpenAI 兼容接口（如通义千问），Function Calling 的落地分为 “工具决策、工具执行、结果回调” 三步骤，核心是 “工具定义→参数生成→函数映射→结果回传” 的闭环。

3.1 第一步：工具决策与参数生成

向模型传入 “工具定义” 和 “用户诉求”，让模型判断是否调用工具并生成参数：

from openai import OpenAI

# 1. 初始化客户端（以通义千问为例）
client = OpenAI(api_key="你的密钥", base_url="https://dashscope.aliyuncs.com/compatible-mode/v1")

# 2. 定义工具（查天气函数）
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",  # 工具名
            "description": "根据经纬度获取当前气温（摄氏度）",  # 工具用途
            "parameters": {  # 参数定义
                "type": "object",
                "properties": {
                    "latitude": {"type": "number", "description": "纬度，如天津39.12"},
                    "longitude": {"type": "number", "description": "经度，如天津117.20"}
                },
                "required": ["latitude", "longitude"],  # 必填参数
                "strict": True  # 严格按参数格式生成
            }
        }
    }
]

# 3. 用户诉求
messages = [{"role": "user", "content": "请告诉我天津的天气?"}]

# 4. 发起请求，获取模型的工具调用决策
completion = client.chat.completions.create(
    model="qwen-plus",
    messages=messages,
    tools=tools  # 传入工具定义，启用Function Calling
)

# 5. 判断是否调用工具
if completion.choices[0].message.tool_calls:
    tool_call = completion.choices[0].message.tool_calls[0].function
    print("调用工具：", tool_call["name"])  # 输出：get_weather
    print("调用参数：", tool_call["arguments"])  # 输出：{"latitude":39.12,"longitude":117.20}
else:
    print("无需调用工具，直接回复：", completion.choices[0].message.content)

3.2 第二步：实际调用工具

将模型生成的 “工具名 + 参数” 映射到本地函数，执行工具逻辑（如调用天气 API、查询数据库）：

import json

# 1. 定义本地工具函数（模拟查天气，实际可对接天气API）
def get_weather(*, latitude: float, longitude: float):
    # 模拟调用外部天气接口返回结果
    return {"temperature": 23, "weather": "Sunny", "wind_direction": "South"}

# 2. 函数映射：工具名→本地函数（方便批量管理）
function_mapping = {"get_weather": get_weather}

# 3. 解析模型输出的参数，调用本地函数
tool_name = tool_call["name"]
tool_args = json.loads(tool_call["arguments"])  # 将JSON字符串转为字典
tool_result = function_mapping[tool_name](**tool_args)  # 传参并执行函数
print("工具执行结果：", tool_result)  # 输出：{"temperature":23,"weather":"Sunny",...}

3.3 第三步：结果回传给模型（获取最终回复）

将工具执行结果传入模型，让模型结合原始诉求生成自然语言回复（对话流场景必需）：

# 1. 将“模型的工具调用指令”和“工具执行结果”加入消息列表
messages.append(completion.choices[0].message)  # 告知模型之前的调用指令
messages.append({
    "role": "tool",  # 角色标记为“工具”
    "tool_call_id": completion.choices[0].message.tool_calls[0].id,  # 关联工具调用ID
    "content": str(tool_result)  # 工具执行结果
})

# 2. 再次请求模型，获取最终回复
final_completion = client.chat.completions.create(
    model="qwen-plus",
    messages=messages
)

# 3. 输出最终回复
print("最终回复：", final_completion.choices[0].message.content)
# 输出：天津当前气温23℃，天气晴朗，风向为南风

3.4 关键注意点

错误处理：若工具执行失败（如参数错误、API 超时），需将错误信息回传给模型，模型可能重试（如修正参数格式）；
函数映射安全：需验证模型输出的工具名是否在 “允许调用列表” 中，避免恶意调用未注册的函数；
非对话流场景：若仅需工具执行结果（如下单、数据写入），可跳过 “结果回传” 步骤，直接进入业务流程。

四、典型应用案例：Function Calling 的实际场景落地

Function Calling 的核心价值在 “连接外部系统”，以下是四个典型应用场景，覆盖 “信息检索、数据操作、跨系统协作”：

4.1 场景 1：联网检索（获取实时信息）

需求：用户问 “五道口附近的咖啡馆”，需先获取五道口经纬度，再搜周边 POI；
工具定义：
- get_location_coordinate：根据 “地点 + 城市” 获取经纬度（参数：location、city）；
- search_nearby_pois：根据经纬度搜周边 POI（参数：longitude、latitude、keyword）；
流程：模型先调用get_location_coordinate（输入 “五道口 + 北京”）获取经纬度，再调用search_nearby_pois（输入经纬度 +“咖啡馆”），最后整理结果回复用户。

4.2 场景 2：本地数据库查询（操作私有数据）

需求：用户问 “2023 年 10 月成交了几笔订单”，需从 SQLite 数据库中查询；
工具定义：query_db：执行 SQL 查询（参数：query（SQL 语句））；
流程：模型结合 “数据库表结构”（如orders表含create_time、status字段）生成 SQL（SELECT COUNT(*) FROM orders WHERE create_time LIKE '2023-10%' AND status=1），调用query_db执行后，将结果转为自然语言（如 “2023 年 10 月共成交 3 笔订单”）。

4.3 场景 3：跨模型协作（调用其他 AI 能力）

需求：用户问 “GPT-5 发布会有哪些亮点”，需联网搜索（用文心一言的联网能力）；
工具定义：nl_search：调用文心一言联网搜索（参数：question（用户问题））；
流程：模型判断 “需实时信息”，调用nl_search传入问题，获取文心一言的搜索结果后，整理亮点回复用户（如 “GPT-5 支持多模态实时交互，上下文窗口扩展至 100 万 token”）。

4.4 场景 4：基础方法封装（标准化工具调用）

需求：多个业务场景需使用 Function Calling，避免重复写客户端初始化、工具注册逻辑；
实现：封装ModelRequestWithFunctionCalling类，提供register_function（注册工具）、request（发起调用）方法，支持批量管理工具、自动处理 “调用→结果回传” 流程，降低重复开发成本。

五、Function Calling 带来的 “质变”：重构大模型的应用边界

Function Calling 不仅是 “一项技术”，更是重构大模型应用价值的关键，从三个维度带来 “质变”：

1. 知识层面：从 “模型内知识” 到 “真实世界知识”

大模型的知识局限于 “训练截止日期前的公开语料”，Function Calling 通过调用搜索、数据库、API，让其能获取 “实时知识”（如当天股价）、“私有知识”（如企业内部客户数据），突破知识时效性与范围的限制。

2. 行为层面：从 “文本应答” 到 “完整行动链”

大模型从 “仅输出思考结果” 升级为 “能执行完整行动”—— 即 “理解问题→选择工具→生成参数→执行工具→处理结果→给出回复” 的闭环，例如：

传统大模型：用户问 “明天北京天气适合出游吗？”，仅能基于旧数据推测；
带 Function Calling 的大模型：调用天气工具查明天北京天气（如 “25℃、无雨”），结合 “出游建议” 生成回复（如 “明天北京天气晴朗，适合户外出游，建议携带防晒用品”）。

3. 架构层面：从 “孤立模块” 到 “系统控制器”

大模型不再是 “独立的 AI 插件”，而是能融入现有信息系统的 “核心控制器”—— 例如：

电商系统：用户说 “帮我买一双 42 码的白色运动鞋”，大模型调用 “商品搜索工具”（查符合条件的商品）、“下单工具”（创建订单）、“支付工具”（发起支付），完成全流程自动化；
办公系统：用户说 “统计上周部门报销金额”，大模型调用 “报销数据库工具”（查数据）、“Excel 生成工具”（导出报表），直接生成可下载的报表文件。

4. 软件开发思想层面：从 “规则驱动” 到 “理解驱动”

传统软件开发依赖 “硬编码规则”（如 “若用户问天气，则调用天气 API，参数为城市对应的经纬度”），而 Function Calling 让开发基于 “大模型的理解能力”—— 无需预设所有场景规则，只需提供 “工具描述”，模型即可根据用户诉求自主匹配工具，降低复杂场景的开发成本（如支持千种工具的系统，无需为每种工具写触发规则）。

总结

Function Calling 的核心是 “让大模型能‘做事’，而非仅‘说话’”—— 通过定义清晰的工具接口，让大模型具备与外部系统交互的能力，从 “文本生成器” 升级为 “智能控制器”。其关键在于 “工具定义的清晰度”“模型决策的准确性”“与业务流程的融合度”，而实际应用中，需结合场景选择 “对话流 / 非对话流” 模式，平衡灵活性与稳定性。