工具调用协议Function Calling 的 JSON 之美上一节模型学会了说要做什么。这一节我们用一套 JSON 协议把这句话变成机器能理解、程序能执行的指令。Function Calling——让模型出手的那只手本质是两次优雅的 JSON 交换。本文导航工具调用到底在解决什么问题第一份 JSONtools 工具说明书第二份 JSONtool_calls 模型的下单第三份 JSONtool 角色回填一个工具从定义到调用的全链路用 pydantic 校验这份 JSON 之美小结下节预告第 17 节。上一节我们见识了 ReAct 的舞步但那个假装调用终究是假的。这节把假变真——用 OpenAI 兼容协议里的Function Calling功能调用机制让 DeepSeek 宣布我要调用工具并给出精确的参数。先记住一句话Function Calling 不是让模型去执行函数而是让模型声明它想调用哪个函数、参数是什么——执行的事还是你的 Harness 干的。这个声明通过 JSON 传递所以叫JSON 之美。工具调用到底在解决什么问题不用工具调用你的模型永远只能输出文字。为了让它能动手你面临两个问题怎么告诉模型有哪些工具可用—— 你不能把每个工具的实现代码塞进提示词里太长、太乱。怎么让模型精确表达我要调用 get_weather(city‘北京’)—— 让模型输出自然语言帮我查一下北京的天气你的解析代码得崩溃。Function Calling 用结构化的 JSON同时解决这两难工具的说明书是 JSON Schema模型的调用意向也是结构化的 JSON。两次交换全链路就跑通了。第一份 JSONtools 工具说明书第一份 JSON 是你写进请求里的tools参数——相当于给模型递上一份菜单让它知道自己能点什么菜。每个工具是一个对象核心是function字段下的name、description、parameters{type:function,function:{name:get_weather,description:查询指定城市的当前天气返回温度和天气状况。当用户询问某地天气时使用。,parameters:{type:object,properties:{city:{type:string,description:城市名如北京、上海、深圳}},required:[city]}}}关键点name模型的点菜口令必须唯一、稳定。description决定模型会不会用它。写得越清楚做什么/何时用模型越会用对。这是第 45 节《工具描述工程》的重头戏先埋个伏笔。parameters严格遵循JSON Schema规范描述每个参数的类型、含义、是否必填。模型严格按它填参数。这个parameters里的 JSON Schema是模型能精确输出的地基。你甚至可以手写但更聪明的做法是用 pydantic 模型反射自动生成——那是第 36 节《工具注册中心》的核心现在先知道说明书长这样。第二份 JSONtool_calls 模型的下单把tools塞进请求发给 DeepSeek如果模型认为该用工具它的响应里就不再只有content而是多出一个tool_calls数组——这就是模型的下单指令{id:call_abc123,type:function,function:{name:get_weather,arguments:{\city\:\北京\}}}注意三个细节都容易踩坑id每次调用都会生成一个唯一 id回填结果时要拿它做对账告诉模型我执行了 was 你下的那一单。arguments是字符串不是对象模型返回的 arguments 是 JSON 字符串你需要先json.loads或pydantic解析成字典再去调用真实函数。一次响应可能有多个 tool_calls模型可以一次性点上好几道菜并行调用你的循环要能处理数组。模型回答时content字段可能为空“我不说话了直接干活”也可能带着一句解释。别假定 content 一定非空。第三份 JSONtool 角色回填模型下单了你的 Harness 拿到参数执行完真实函数拿到结果。然后呢必须用role: tool的消息把结果回填给模型让它看到行动的结果从而决定下一步。这就是 Observation。messages.append({role:tool,tool_call_id:call_abc123,# 必须和下单时的 id 一致content:北京现在 26℃晴朗,# 工具执行结果})回填时必须同时满足两个要求缺一个模型就看不懂tool_call_id必须等于之前 tool_calls 里那个 id对账必须把当次响应里的assistant消息含 tool_calls一起追加。也就是说模型那轮下单的 assistant 消息必须原样保留在 messages 里工具结果才能挂到它后面。这背后是 OpenAI 协议的一条硬性约束消息历史里每次 tool_calls 之后必须紧跟对应的一组 tool 消息否则报错或模型混乱。我们后面实现的 Agent Loop 会严格遵守这条。一个工具从定义到调用的全链路把所有 JSON 串起来就是一个完整的调用时序。看这张图把它刻进脑子User工具函数DeepSeekHarnessUser工具函数DeepSeekHarness请求 messages tools 说明书响应 tool_calls [get_weather(city北京)]解析 arguments (json.loads / pydantic)调用真实函数 get_weather(北京)返回 北京 26℃ 晴朗追加 tool 消息回填结果 (tool_call_idcall_abc123)响应最终文字 北京现在26℃微风输出最终答案两次 JSON 交换下单 回填撑起了整个循环。每次模型带 tool_calls 返回你就补一手工具结果模型看到结果再决定继续调用还是收尾。这个节奏就是第 16 节 ReAct 循环在协议层的实体。用 pydantic 校验这份 JSON 之美模型输出的arguments是自由意志的产物格式可能飘参数名拼错、类型错、缺字段。跨过不可信输出这道坎靠的是我们一贯的 pydantic 强类型校验用户铁律。tool_calls_demo.py —— 用 pydantic 解析并校验模型返回的工具调用第17节 运行环境Python 3.12 uv 管理 依赖 uv add openai pydantic 用法 set DEEPSEEK_API_KEY你的key uv run python tool_calls_demo.py importjsonimportosfromopenaiimportOpenAIfrompydanticimportBaseModel,Field clientOpenAI(base_urlhttps://api.deepseek.com,api_keyos.environ.get(DEEPSEEK_API_KEY),)# 1. 用 pydantic 定义工具参数的强类型结构classWeatherParams(BaseModel):city:strField(description城市名)# 2. 构造 tools 说明书此处用 pydantic 模型生成 JSON Schema 的雏形tools[{type:function,function:{name:get_weather,description:查询指定城市的当前天气,parameters:WeatherParams.model_json_schema(),# pydantic 反射生成},}]messages[{role:system,content:你是天气助手用户问天气就调用 get_weather。},{role:user,content:北京今天的天气怎么样},]respclient.chat.completions.create(modeldeepseek-flash,messagesmessages,toolstools,)msgresp.choices[0].messageprint(content:,msg.content)print(tool_calls:,msg.tool_calls)# 3. 解析并校验模型返回的参数 —— 模型不可信必须校验ifmsg.tool_calls:fortcinmsg.tool_calls:raw_argsjson.loads(tc.function.arguments)# 先把字符串变字典validatedWeatherParams(**raw_args)# pydantic 校验并转强类型print(f校验通过 → 调用 get_weather(city{validated.city!r}))真实运行一次输出大致是我用一次实测记录content: None tool_calls: [ChatCompletionMessageToolCall(idcall_1x2y3z, typefunction, functionFunction(arguments{city:北京}, nameget_weather))] 校验通过 → 调用 get_weather(city北京)注意content: None——模型这轮没说话直接下单。arguments是字符串{city:北京}我们json.loads后再用WeatherParams校验city 被强转成北京的 Python 字符串。就算模型输出{city: 123}这种类型错误pydantic 也会当场抛校验异常而不是把脏数据喂进之后的业务逻辑。这就是模型不可信、我们用校验兜底的工程哲学。model_json_schema()这个反射能力很有用但真正的工具注册中心还会有更完整的配置第 36 节细讲。小结Function Calling 两次 JSON 交换你递tools说明书模型回tool_calls下单你回填tool结果。模型不真执行只声明的意图执行永远在 Harness 侧这是 Agent 架构的安全分界。arguments是字符串要先json.loads再校验别直接当字典用。回填必须对账tool_call_id要对上且 assistant含 tool_calls消息要原样保留。模型输出不可信用 pydantic 强类型校验参数是底线脏数据进不了业务逻辑。下节预告循环转起来了但有个坏消息模型有时永远不想停——它不停地下单、下单、下单。下节我们聊什么时候算想好了循环的三种终止条件以及那个让每个 Agent 开发者头大的模型停不下来案例。如果觉得本文对你有帮助欢迎点赞、收藏、关注三连本系列持续更新中关注不迷路~