👨 作者简介：大家好，我是Taro，全栈领域创作者
✒️ 个人主页：唐璜Taro
🚀 支持我：点赞👍+📝 评论 + ⭐️收藏

---

---

前言

如果说 LLM（大语言模型）是一个知识渊博但关在黑屋子里的“大脑”，那么 Function Calling（函数调用） 就是你递给它的一部电话和一套工具箱。

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、Function Calling——给 AI 装上“手脚”

1.它是如何工作的？

AI 本身不能查实时天气，也不能帮你改代码。

1. 你（开发者）：给 AI 一份工具说明书（JSON 格式）。

2. 用户：问“今天南京天气怎么样？”

3. AI（大脑）：翻看说明书，发现有个工具叫 get_weather，于是它吐出一串指令：“我申请调用这个工具，参数是南京。”

4. 你的程序（手脚）：替 AI 执行代码，查到天气，再把结果告诉 AI。

5. AI：最后把冷冰冰的数据翻译成人话回馈给用户。

2. 为什么它能听懂用户的“模糊需求”？

这靠的是语义匹配。
即使你定义的参数是 location，用户说“南京”、“金陵”还是“这儿”，AI 都能通过逻辑推理，把这些词准确地“抠”出来，塞进你的函数参数里。

3.代码示例

代码如下（示例）：

# 1. 定义你的真实本地函数
def get_current_weather(location: str, unit: str = "celsius"):
    """
    获取指定城市的实时天气预报。
    
    Args:
        location: 城市名称，例如：上海
        unit: 温度单位，可选 celsius 或 fahrenheit
    """
    # 这里是连接气象 API 的真实逻辑
    return {"temp": 22, "condition": "Sunny"}

# 2. 将函数传递给 LLM (以类似 SDK 为例)
tools = [get_current_weather]
# 这里的 SDK 会自动解析函数名、注释(Docstring)作为 JSON 描述发送给 LLM

---

二、非常精妙的语义匹配过程

1. 语义向量匹配 (Semantic Matching)

当你把 get_current_weather 的描述发送给 LLM 时，它会将这段描述转化成一组复杂的数学坐标（Embedding）。

• 函数描述： “获取指定城市的实时天气预报”。

• 用户输入： “南京今天热吗？”

• 大脑运作： LLM 发现“热吗”、“天气”、“气温”在语义空间里距离非常近。它会产生一个判断：“用户的需求落在了这个函数的功能覆盖范围内。”

2. 意图槽位填充 (Slot Filling)

LLM 不仅知道要用哪个函数，还知道要把用户话里的词“抠”出来填进参数里。

在你的 JSON 定义中，你告诉了它参数 location 是字符串。

• 输入： “帮我查查南京的天气。”

• 逻辑推理： LLM 扫描这句话，发现“南京”是一个地名，刚好符合 location 参数的描述。

• 动作： 它会把“南京”提取出来，转化为 {“location”: “南京”}。

3. 概率预测与决策 (Probability & Decision)

在 LLM 生成回复的每一毫秒，它其实都在预测下一个“词”是什么。

• 通常情况下：**它的下一个词可能是“南京的天气是…”。

• 在开启 Function Calling 时：由于它看到了你注册的工具，它预测的“概率最高”的行为不再是说话，而是发起一个特殊标记（Special Token），告诉系统：“我现在要停下说话，转而输出一个 JSON 指令。”

4. 完整的“内心活动”拆解

假设用户问：“明天去杭州要带雨伞吗？”

1.检索工具栏：LLM 看到 get_current_weather 的描述里提到了“降水预测”。

2.判断逻辑依赖：它意识到自己作为一个模型，不知道明天的实时降水情况。要回答“带不带伞”，必须先拿到“降水量”。

3.提取参数：

• 地点（location）：杭州。

• 时间（虽然你没定义这个参数，但它会尝试从已有参数里匹配，或者只传地点）。

• 生成指令：它决定不直接回答，而是吐出 { “name”: “get_current_weather”, “arguments”: {“location”: “Hangzhou”} }。

---

总结

提示：这里对文章进行总结：
注册函数就像是在编写一份 API 文档，只不过这份文档的读者不是人类程序员，而是 AI。AI 阅读你的描述，决定什么时候按下那个“按钮”