Function Calling是什么？——为什么AI知道答案，却什么也做不了？

大剑师^_^兰特

493人浏览 · 2026-06-27 11:45:00

大剑师^_^兰特 · 2026-06-27 11:45:00 发布

《AI不是魔法》

写给软件工程师的AI工程课

第五堂：Function Calling到底是什么？

这一篇适合谁：

如果你好奇AI为什么突然能调用工具、想理解它背后的原理、以及它和RAG有什么区别——那么这一篇值得看完。

上一堂课，我们知道：

RAG不是让AI变聪明，而是让AI学会查资料。

这一堂课，我们继续回答：

为什么AI知道那么多，却什么也做不了？

一个客服机器人上线了。它已经接入了RAG，知道公司的所有政策。

客户问：

“我的订单已经延期10天了，能帮我退款吗？”

AI回答：

“根据公司政策，延期超过7天的订单可以申请退款。建议您联系客服处理。”

客户继续问：

“你不是客服吗？你不能直接帮我退吗？”

AI回答：

“很抱歉，我无法操作退款系统。请您拨打客服热线。”

AI说错了吗？没有。它知道退款流程，知道政策允许，知道客户符合条件。

但它没有退款按钮。它不能点。

这，就是 Function Calling 出现的原因。

一、LLM真正拥有的能力，始终只有一种：预测下一个Token

前三篇我们一直在讲一件事：LLM的本质，是在预测下一个Token。

它可以把“退款流程”说得清清楚楚，可以把“如何调用退款API”的代码写得明明白白。

但它不能自己调用那个API。

为什么？

因为：

查数据库，不属于预测Token
调API，不属于预测Token
发邮件，不属于预测Token
执行脚本，不属于预测Token
操作浏览器，不属于预测Token

这些能力，必须来自LLM之外。

LLM只有一个输出通道：文字。它什么都知道，但什么都做不了。

整个过程可以用一张图来表示：

用户：帮我查一下订单状态
    ↓
LLM
    ↓
输出一段文字：“建议您登录官网查看”
    ↓
结束

它不会自己继续。它只能“说”，不能“做”。

二、Function Calling的本质：让AI学会借用能力

Function Calling，就是给AI一个“可以调用工具”的能力。

它的工作原理，不是AI自己去执行代码，而是：AI决定“需要调用什么工具”，然后把调用请求发出来，由外部系统执行，执行结果再送回AI，AI再基于结果继续回答。

整个过程可以用一张图来表示：

用户：帮我查一下订单状态
    ↓
LLM分析意图：需要查询订单系统
    ↓
LLM生成函数调用请求：
  get_order_status(order_id="12345")
    ↓
外部系统执行查询
    ↓
返回结果：{status: "delayed", estimate: "2026-07-01"}
    ↓
结果进入LLM的Context（Context更新）
    ↓
LLM基于更新后的Context继续预测
    ↓
输出：“您的订单目前延迟，预计7月1日送达。需要帮您催单吗？”

注意看：工具不会直接回答用户。工具只负责返回结果。真正组织答案的，仍然是LLM。

工具返回的结果，变成了一段新的Context。LLM基于这个更丰富的Context，重新预测下一个Token。

Prompt、RAG、Function Calling，看起来解决的是三个不同的问题，但它们最终都在做同一件事：不断丰富LLM当前的Context。

因为LLM从来不会直接面对世界，它只能面对当前的Context。

Context越丰富，Prediction越准确。

三、RAG和Function Calling的区别

很多人会问：RAG和Function Calling有什么区别？它们不都是让AI获得更多信息吗？

区别在于：

RAG解决的是“知不知道”的问题。 AI不知道公司政策，RAG帮它查到。
Function Calling解决的是“能不能做”的问题。 AI知道该退款，但它不能操作退款系统。

用一个人来类比：

RAG是给AI一本参考书，让它知道不知道的知识。
Function Calling是给AI一部电话，让它能打电话查信息、发指令、办事情。

两者可以协同工作：

用户：我的订单延迟了，能帮我退款吗？
    ↓
RAG：查询公司政策 → “延期超过7天可以退款”
    ↓
Function Calling：调用退款API → 发起退款流程
    ↓
LLM：基于政策知识和操作结果，组织最终回答
    ↓
输出：“已为您发起退款，预计3个工作日到账。”

RAG让AI知道该做什么。Function Calling让AI真的去做。

至此，我们可以画出一张总图，把前五篇的全部内容串起来：

用户
    ↓
Prompt
    ↓
丰富Context
────────────
RAG
    ↓
丰富Context
────────────
Function Calling
    ↓
丰富Context
────────────
LLM
    ↓
Prediction
    ↓
Answer
    ↓
Action

四、一个真实的工程案例

一个开发团队用AI辅助运维。开发同学说：

“帮我部署一下测试环境。”

没有Function Calling时，AI只能回答：

“请执行以下命令：kubectl apply -f test-env.yaml”

然后开发同学自己复制命令，自己去终端执行。

有Function Calling时，AI可以直接调用部署工具：

deploy_test_env(env_name="test", version="v2.1")

工具执行部署，返回结果：

{status: "success", url: "http://test.internal.com"}

AI再告诉开发同学：

“测试环境已部署完成，访问地址是 http://test.internal.com”

LLM负责决定要做什么。Tool负责真正把事情做完。

真正改变世界的，从来不是Token，而是Tool。

一个一分钟实验

先问AI一个问题：

现在几点？

如果AI没有获取时间的能力，它可能回答“我不知道”或者给出一个估计。

然后，你告诉它：

现在时间：14:38

再问：

距离18点还有多久？

AI这次能准确回答：3小时22分钟。

这个实验让你亲身体验Function Calling的本质：不是AI自己获得了新能力，而是外部数据进入了它的Context，它基于更丰富的Context做出了更好的预测。

工程师容易踩的坑

🚫 错误做法：
让AI直接调用生产环境的API，没有任何权限控制和验证。

为什么错：
AI可能生成错误的参数，或者在不恰当的时机调用API，导致数据损坏或安全问题。

✅ 正确做法：
为AI可调用的函数设置明确的权限和参数校验。AI只负责决定“调用哪个函数、传什么参数”，执行权交给受控的外部系统。

今天记住这一句话

LLM负责决策，Tool负责执行。

如果今天只带走一个观点，那就是：Function Calling没有改变LLM，它只是第一次让LLM能够影响真实世界。

系列阶段总结

走到这里，我们已经完成了整个系列上半部分的五篇文章。回顾一下我们走过的路：

第一篇回答：
为什么AI会胡说八道？
——因为它在预测Token。

第二篇回答：
为什么一句话就能改变AI？
——因为Prompt在构建Context。

第三篇回答：
为什么AI看起来像理解了语言？
——因为Transformer让预测更高效。

第四篇回答：
为什么企业不用ChatGPT直接回答客户？
——因为RAG让AI先查资料再回答。

第五篇回答：
为什么AI知道答案却什么也做不了？
——因为Function Calling让AI能调用工具。

到这里，我们已经理解了今天几乎所有AI应用的四个基础能力：预测、上下文、知识、工具。

真正复杂的AI系统，不过是在这四种能力之上继续组合。

接下来的篇章，我们将进入下半部分：当这些能力开始组合，会发生什么？

下一篇预告：

今天，每个AI应用都有自己的Tool格式。OpenAI一套，Anthropic一套，Google又一套。

一个工具往往只能适配一个模型。如果有100个模型、1000个工具，就需要写10万次适配。

有没有一种“USB接口”一样的标准，让所有模型都能使用所有工具？

下一篇，我们聊MCP。