Function Calling 原理

Function Calling 原理：把工具调用实现为模型选接口、应用执行、结果回灌的显式协议，通过架构、轨迹和故障重放完成验收。

学习目标

  • 能解释“Function Calling 原理”如何把工具调用实现为模型选接口、应用执行、结果回灌的显式协议
  • 能区分function calling、工具描述、input_schema、tool_choice、tool_result，并指出控制权、数据与副作用边界
  • 能固定输入与版本，沿以下证据定位首个分叉：工具列表、选择原因、调用块、参数校验、执行日志、结果块与 stop_reason
  • 能注入“把 tool_use 当成已经执行的事实，未运行工具就据此生成成功答复”，完成阻断、恢复、复位和同输入重放

来源、课程编排与适用边界

“Function Calling 原理”以Anthropic 公开全文《Building effective agents》为总纲，并用Claude Platform《How tool use works》核对本单元机制；涉及 MCP 的控制权边界再由MCP 2025-06-18 官方规范交叉检查。

这不是 Anthropic 出版的“19 章教材”。平台把公开文章、官方工具文档与协议规范重组为 19 个应用单元；下列 152 个节点是站内课程地图，不冒充原文目录。正文、代码、图表、实验和练习均为独立教学重写；产品接口、模型行为或协议版本变化时必须重新验证。

本单元的八个课程坐标

  • Function Calling 原理：这是“把工具调用实现为模型选接口、应用执行、结果回灌的显式协议”的第 1 个课程坐标；必须进入机制解释、实验观察或练习证据，不能只停在目录。
  • 先打个比方：这是“把工具调用实现为模型选接口、应用执行、结果回灌的显式协议”的第 2 个课程坐标；必须进入机制解释、实验观察或练习证据，不能只停在目录。
  • 第一个概念：工具是怎么进入模型「视野」的：这是“把工具调用实现为模型选接口、应用执行、结果回灌的显式协议”的第 3 个课程坐标；必须进入机制解释、实验观察或练习证据，不能只停在目录。
  • 第二个概念：模型怎么从菜单里挑一个——工具选择：这是“把工具调用实现为模型选接口、应用执行、结果回灌的显式协议”的第 4 个课程坐标；必须进入机制解释、实验观察或练习证据，不能只停在目录。
  • 第三个概念：挑中之后，多个调用是并排发还是排队发：这是“把工具调用实现为模型选接口、应用执行、结果回灌的显式协议”的第 5 个课程坐标；必须进入机制解释、实验观察或练习证据，不能只停在目录。
  • 动手看：模型在工具菜单里挑中一个的全过程：这是“把工具调用实现为模型选接口、应用执行、结果回灌的显式协议”的第 6 个课程坐标；必须进入机制解释、实验观察或练习证据，不能只停在目录。
  • 用代码看那份「菜单」长什么样：这是“把工具调用实现为模型选接口、应用执行、结果回灌的显式协议”的第 7 个课程坐标；必须进入机制解释、实验观察或练习证据，不能只停在目录。
  • 容易踩的坑：这是“把工具调用实现为模型选接口、应用执行、结果回灌的显式协议”的第 8 个课程坐标；必须进入机制解释、实验观察或练习证据，不能只停在目录。

术语与运行合同

、、、、。

本页不变量是：模型只提出结构化调用，真正执行和授权始终属于应用运行时。任何“成功”结论都要保存以下证据：工具列表、选择原因、调用块、参数校验、执行日志、结果块与 stop_reason，模型生成的计划或自信不能替代环境事实。

关键机制与可推翻实验

协议两侧职责不同

模型能看到名称、描述和 schema，看不到你的函数实现，也不会自动运行客户端代码。

动手验证：把执行器替换为记录器，确认模型输出本身没有副作用。

工具描述影响选择

名称相近或边界重叠会增加误选；描述要说明使用条件与禁用条件。

动手验证：用相邻意图数据集测混淆矩阵，而不是只看一个成功例。

并行调用仍要逐个验收

同一轮可有多个 tool_use，每个结果必须按标识配对并分别处理错误。

动手验证：随机改变完成顺序，验证响应不会串线。

所有停止原因都要处理

end_turn、max_tokens、refusal 与 pause_turn 不是同一种完成状态。

动手验证：为每个停止原因写状态机测试。

先预测，再操作三类证据

分步1 / 3

1. 架构与复杂度边界

在“Function Calling 原理”中切换简单基线、受控工作流与自主循环，先预测“把工具调用实现为模型选接口、应用执行、结果回灌的显式协议”在哪个阶段需要增加控制权，再比较延迟、成本、可观测性和自主性。

Architecture decision laboratory

Function Calling 原理

把工具调用实现为模型选接口、应用执行、结果回灌的显式协议

复杂度档位

不变量：模型只提出结构化调用，真正执行和授权始终属于应用运行时

受控工作流：只激活能够由收益证明的阶段1暴露工具2模型选择3解析调用4应用执行5结果回灌蓝色表示当前方案承担的责任；虚线阶段仍留在系统边界外。关键证据：工具列表、选择原因…
自主性46
延迟52
成本48
可观测78

最小可运行实现

const response = await client.messages.create({ messages, tools });
if (response.stop_reason === "tool_use") {
  const calls = response.content.filter(isToolUse);
  const results = await Promise.all(calls.map(validateAuthorizeAndRun));
  messages.push(response, toToolResultMessage(results));
} else {
  return classifyStop(response.stop_reason);
}

这段切片只暴露“把工具调用实现为模型选接口、应用执行、结果回灌的显式协议”的最小运行合同。交付版本还要补齐超时、密钥隔离、结构化日志、幂等和批量评测；缺少工具列表、选择原因、调用块、参数校验、执行日志、结果块与 stop_reason时，代码能运行也不代表本章结论成立。

练习与答案

练习

问题 1：最小证明。 怎样用最少样本证明“模型只提出结构化调用，真正执行和授权始终属于应用运行时”？

问题 2：课程覆盖。 Function Calling 原理、先打个比方、第一个概念：工具是怎么进入模型「视野」的、第二个概念：模型怎么从菜单里挑一个——工具选择、第三个概念：挑中之后，多个调用是并排发还是排队发、动手看：模型在工具菜单里挑中一个的全过程、用代码看那份「菜单」长什么样、容易踩的坑如何进入可操作验证？

问题 3：恢复闭环。 怎样证明“把 tool_use 当成已经执行的事实，未运行工具就据此生成成功答复”已经修复？

本章回顾

  • “Function Calling 原理”的主问题是把工具调用实现为模型选接口、应用执行、结果回灌的显式协议。
  • 核心不变量是模型只提出结构化调用，真正执行和授权始终属于应用运行时。
  • 首要反例是把 tool_use 当成已经执行的事实，未运行工具就据此生成成功答复。
  • 最小证据包包含工具列表、选择原因、调用块、参数校验、执行日志、结果块与 stop_reason。

名词解释

本章出现的专业名词，用大白话再讲一遍。

function calling

模型输出结构化函数请求、应用负责执行的集成模式。在“Function Calling 原理”中必须能按以下证据重新定位：工具列表、选择原因、调用块、参数校验、执行日志、结果块与 stop_reason。

工具描述

帮助模型判断何时使用某个工具的自然语言合同。在“Function Calling 原理”中必须能按以下证据重新定位：工具列表、选择原因、调用块、参数校验、执行日志、结果块与 stop_reason。

input_schema

限定调用参数形状的 JSON Schema。在“Function Calling 原理”中必须能按以下证据重新定位：工具列表、选择原因、调用块、参数校验、执行日志、结果块与 stop_reason。

tool_choice

控制模型是否自动、强制或禁用工具选择的策略。在“Function Calling 原理”中必须能按以下证据重新定位：工具列表、选择原因、调用块、参数校验、执行日志、结果块与 stop_reason。

tool_result

应用执行后送回模型的结构化结果。在“Function Calling 原理”中必须能按以下证据重新定位：工具列表、选择原因、调用块、参数校验、执行日志、结果块与 stop_reason。

阅读导航

← 结构化输出与工具调用协议 · 设计好用的工具 →

讨论

评论区加载中…