文章

Function Calling：大模型从「对话框」走向「工具箱」的工程实践

#462 · 2026-05-20 · 21ZHAO Blog

引言

如果说 LLM 的预训练数据赋予了它“知识”，那么 Function Calling（函数调用） 则是赋予了它“手脚”。近期在开发者社区，关于如何稳定、安全地利用大模型调用外部 API 的讨论热度空前。从初期的提示词硬塞，到现在的结构化协议，Function Calling 正在成为 AI 智能体（Agent）架构中的底层标配。

关键信息

1. 技术底座：结构化输出与 JSON Schema

Function Calling 的本质不是模型直接执行代码，而是模型生成符合预定义 JSON Schema 的参数。

  • 约束逻辑：通过在 System Prompt 中定义函数名称、描述和参数结构，强迫模型在需要调用外部能力时，输出结构化的 JSON 而非自由文本。
  • 多模型兼容性：OpenAI 的 tools 模式、Anthropic 的 computer_use 以及 DeepSeek 的原生支持，虽然接口略有不同，但核心逻辑均指向“意图识别 -> 参数提取 -> 格式校验”。

2. 多跳任务（Multi-hop）与长链路执行

在复杂的业务场景中，一个用户请求往往需要多次函数调用才能完成。

  • 反馈闭环：模型生成调用参数 -> 后端执行函数并返回结果 -> 结果回传模型 -> 模型决定下一步动作。
  • 幻觉风险：在长链路中，模型可能生成不存在的函数名或错误的参数类型。目前的工程解法是引入“动态重试”和“类型守卫”。

3. 安全性与访问权限的博弈

赋予大模型调用 API 的权力，意味着它可能误删数据或泄露隐私。

  • 沙箱执行：所有高危操作（如数据库写入、文件删除）必须在受控的沙箱环境中运行。
  • 人工在环（Human-in-the-Loop）：关键操作（如金融转账、系统重写）需要通过确认机制进行二次干预。

为什么值得关注

Function Calling 代表了 AI 范式的根本性转变：

  • 从「生成」到「执行」：AI 不再只是陪聊，而是能查天气、订机票、写代码并运行。
  • 中间层机会：围绕 Function Calling 产生的“模型适配器”、“安全审计网关”和“自动化工具注册表”正在形成一个新的技术蓝海。

21ZHAO 判断

21ZHAO 认为：Function Calling 是决定 LLM 能否进入核心生产系统的分水岭。 很多团队在尝试时，最大的误区是试图让模型一次性完成复杂任务。成功的工程实践应该是“函数原子化、链路显式化”。 不要指望模型能直接理解业务逻辑，而应该提供像“乐高积木”一样的原子函数，并通过逻辑框架（如 LangChain 或自研状态机）来约束模型的行动边界。

可复用建议

  1. 坚持「原子化」函数设计：每个注册到模型的函数应只做一件事（如：获取用户信息），不要写成万能函数。
  2. 强制开启「强类型校验」：在后端接收模型输出时，必须使用 Pydantic 或类似工具进行严格的类型检查，不要直接把模型生成的 JSON 传给下游业务系统。
  3. 设计「失败降级」路径：如果模型连续三次生成错误的参数，应自动回退到人工介入模式或提供简化版的兜底选项。
  4. 保留「思维链」日志：在调试 Function Calling 时，不仅要看最终结果，更要记录模型在做出调用决策前的中间推理步骤。

可延展观察

  • 端侧 Function Calling：随着移动端 NPU 能力提升，手机本地模型是否能直接调用手机原生 API（如相机、联系人）？
  • 标准化的工具协议：是否会出现类似 HTTP 之于 Web、LSP 之于编辑器一样的“通用工具调用协议（UCP）”？

参考来源