LLM 刚出来那会儿，大家都喜欢拿一些“刁钻”的问题去考它。最经典的一个就是：7.11 和 7.9 哪个数字更大？

你也可以翻开第一节课的check_env.py代码，试着问AI：“今天是几月几日？” 早期的deepseek会自信地给你一个离谱的答案。

那时候，AI对这类需要精确计算或实时信息的问题毫无防备，闹了不少笑话。

但到了Agent时代，这些根本不是问题。加减乘除、大小比较、日期查询，都能稳定搞定。不信你去DeepSeek官网或豆包问“今天是几月几日”，返回的都是准确结果。

为什么？因为官网和APP都在底层用到了我们这节课要讲的核心能力：Function Calling（工具调用）。

一、Function Call的历史及现状

为了解决大语言模型早期在精确计算和实时信息获取上的短板，2023年6月13日，OpenAI在发布gpt-4-0613和gpt-3.5-turbo-0613时，推出了一个革命性的设计：Function Calling。

发布这个功能之前

开发者（包括早期的LangChain用户）想让AI调用工具，只能用ReAct模式——在System Prompt里写一大段话：“你是一个可以使用工具的AI。如果你想用计算器，请输出Action: Calculator, Input: 1+1。” 这种做法充满了痛点：

• 不稳定：AI经常忘了格式，或者多打个标点符号。

• 解析难：开发者得写复杂的正则表达式去抓取AI的回复。

• Token浪费：工具描述全塞在Prompt里，占用大量上下文。

OpenAI的创新

OpenAI受Meta的Toolformer启发，通过微调让模型在底层“原生”支持了调用外部工具的能力。你不再需要在Prompt里求AI“请按格式输出”——只需要把JSON Schema传给API，模型就能极度稳定地输出结构化的JSON调用指令。

可以说，Function Calling是OpenAI将“学术界的Tool Learning”转化为“工业级API标准”的产物。它标志着AI Agent开发从“手搓Prompt的黑客时代”迈入了“标准化工程开发时代”。如今，Anthropic（Claude）、Google（Gemini）、DeepSeek等主流厂商都跟进并支持了这一标准。

二、Function Calling 基本流程

下面这张图展示了用户输入“北京今天天气如何”后，整个架构的流转：

你会发现一个重要的定律：LLM对于Agent而言，其实是无状态的。 当Agent朝LLM发起会话时，每次都需要携带历史记录才能完成多轮会话；每次都需要携带注册到Agent中的Function列表；每次都需要写System Prompt。

这带来了三个很大的负担：

1. 人设负担：每次会话都要重新声明人设，不然LLM就不知道自己是干什么的。
2. 技能树负担：每次会话都要重新声明所有Agent拥有的全技能JSON Schema，这会占用巨大的Token。
3. 记忆负担：随着对话进行，messages列表会越来越长。

进而引发一系列问题：

• 费钱：LLM按输入Token收费，第1句的历史在第100轮对话时被重复计费了100次。
• 变慢：处理的文字越多，首字延迟（TTFT）越高。
• 溢出：一旦超过模型上下文上限（比如32k或128k），模型就会报错或强制截断，导致“失忆”。
• 变蠢：Token过长时，LLM对会话关键信息的注意力会被稀释。