Function Calling 与 Tool Calling

Function Calling / Tool Calling 解决的，不是“模型能不能调用接口”，而是“模型怎样把调用意图交给工程系统安全地执行”。模型可以决定想做什么，但真正的执行权、校验权和审计权，必须还在服务端。

很多人第一次看到 Tool Calling，会觉得这不过是“让模型返回一个 JSON”。这种理解太浅了。真正重要的不是 JSON 形状，而是模型、Schema、服务端和业务系统之间有没有形成清晰契约。

为什么不能让模型直接执行

模型的强项是理解意图和生成候选动作，不是绕过系统边界直接操作业务。只要动作会影响真实数据、真实权限或真实成本，执行权就不能交给模型本身。

这也是 Tool Calling 的起点：

• 模型负责判断是否要调用工具。
• 模型负责按照约定格式给出工具名和参数。
• 服务端负责校验、执行、限流、超时、幂等和审计。
• 执行结果再返回给模型，决定下一步。

少了服务端这一层，所谓“工具调用”就只是把风险从接口层搬进了 Prompt。

一次工具调用到底怎么发生

一次完整的工具调用，通常会经历下面这条链路：

用户提出目标
  -> 模型判断是否需要工具
  -> 模型输出工具名与参数
  -> 服务端校验 Schema、权限和业务规则
  -> 工具执行
  -> 返回结果给模型或前端

这里真正有价值的不是“模型调没调用成功”，而是每一步都能被系统看见和约束。你要能回答：模型想调什么、传了什么参数、服务端为什么放行或拒绝、工具最终返回了什么。

Schema 为什么不是细节，而是契约

很多初学者把参数 Schema 当成为了方便解析的辅助格式，实际上它是工具调用里最硬的约束之一。

一个好 Schema 至少会明确这些事：

• 工具到底叫什么，负责什么，不负责什么。
• 每个参数叫什么、类型是什么、是否必填。
• 参数取值有哪些范围或枚举限制。
• 哪些字段由模型提供，哪些字段必须由服务端补齐。

如果 Schema 含糊，模型就会“自由发挥”；如果 Schema 过宽，服务端就得替模型擦屁股。Tool Calling 的稳定性，很多时候不是输在模型，而是输在契约本身没立住。

服务端必须接住哪些责任

就算模型已经正确选中了工具，服务端仍然不能只做一层参数转发。至少这些责任不能外包：

• 权限校验：用户有没有资格执行这个动作。
• 业务校验：参数在业务上是否成立。
• 幂等与超时：重复调用和长时间阻塞怎么处理。
• 结果收口：工具返回的数据是否还能继续给模型看。
• 调用日志：要不要记录工具名、参数、结果、耗时和失败原因。

这也是为什么 Tool Calling 天生是一件“模型 + 后端”的事，而不是前端把 JSON 拼出来就结束。

哪些失败，不该一股脑甩给模型

工具调用失败时，最懒的做法是继续追问模型，让它自己修。生产里这通常不是好主意。你得先区分失败属于哪一类：

• Schema 错误：模型参数结构不合法。
• 权限错误：用户本来就没资格执行。
• 业务错误：参数合法，但业务上不允许。
• 系统错误：超时、限流、网络或下游异常。

只有分清失败类型，系统才能决定是让模型重试、提示用户修改、还是直接终止流程。否则你会得到一个“每次失败都看上去像模型不聪明”的假象。

什么时候其实不必上 Tool Calling

不是所有外部能力接入都值得做成 Tool Calling。下面这些情况，直接走确定性后端逻辑通常更稳：

• 调用路径固定，不需要模型参与选择。
• 参数来源明确，前端或后端自己就能构造。
• 动作成本高、风险高，不适合让模型决定是否执行。
• 你真正需要的是流程编排，不是自由决策。

换句话说，Tool Calling 适合解决“模型需要在多个能力之间做判断”的问题，不适合给每个普通接口都套一层 AI 外壳。

一句话先记住

Tool Calling 不是让模型执行工具，而是让模型提出调用意图，再由系统安全地接住它。

继续阅读

• 06-agent/001-what-is-agent.md：先回头看 Agent 为什么需要工具，但不该被工具等同。
• 07-langchain-langgraph/001-langchain-overview.md：再看这些工具、Prompt 和模型调用怎样被组织成一条实际链路。
• 10-backend-for-ai-agent/002-java-ai-architecture.md：如果你更关心服务端落地，可以继续看后端怎样接住权限、日志和执行边界。