大模型本身只能生成文本，无法查询实时库存、发送邮件或计算精确结果。Function Calling（也称工具调用）提供了一种标准化的方式：开发者向模型描述可用的工具，模型在需要时输出结构化的调用请求，由应用程序真正执行，再把结果返回给模型。 这是几乎所有 AI Agent 的基础能力。

工具调用的完整流程

  1. 声明工具：在请求中提供工具列表，每个工具包括名称、用途描述和参数的 JSON Schema；
  2. 模型决策：模型根据用户问题判断是否需要调用工具、调用哪个、参数是什么，输出一个结构化的调用请求；
  3. 应用执行：你的代码解析请求，校验参数，调用真实的接口或函数；
  4. 返回结果：把执行结果作为一条特殊消息发回给模型；
  5. 生成回答：模型结合工具结果回答用户，或者继续发起下一次调用。

关键点在于：模型从不直接执行任何操作，它只是“提出请求”。执行权始终在你的程序手里，这也是安全控制的基础。

如何设计好用的工具定义

模型是否能正确使用工具，很大程度上取决于工具描述写得好不好。

名称和描述要具体

“search” 不如 “search_orders_by_phone”；描述里写清楚这个工具适合什么场景、不适合什么场景、返回什么内容。模型完全依赖这些文字来做判断。

参数要尽量约束

能用枚举就别用自由文本，能标明格式就写清楚格式，比如日期用 “YYYY-MM-DD”。必填与选填参数要区分清楚。

工具数量要克制

一次性提供几十个工具，模型选错的概率会明显上升。可以按场景动态加载工具，或者把相似的工具合并成一个带参数的工具。

返回结果要精简

工具返回的内容会占用上下文。把数据库返回的上百个字段原样塞给模型既浪费 Token，又会干扰判断。只返回回答问题所需的字段。

参数校验与错误处理

模型生成的参数可能缺失、格式错误或超出范围。生产环境中必须：

  • 按 Schema 严格校验参数，不合规就拒绝执行；
  • 把错误信息以清晰的文字返回给模型，例如“日期格式应为 YYYY-MM-DD”，让它有机会修正；
  • 设置最大调用轮数，防止模型陷入反复调用的循环；
  • 对超时、接口异常做好兜底，告诉模型“工具暂时不可用”而不是让整个流程崩溃。

结构化输出的更多技巧可参考让大模型稳定输出 JSON。

权限与安全

工具调用把模型和真实系统连接起来，风险也随之而来：

  • 最小权限：工具只暴露必要的能力，比如查询订单的工具不应能修改订单；
  • 身份绑定：工具执行时使用当前用户的权限，而不是一个万能的服务账号；
  • 高风险操作需确认：转账、删除、对外发送等不可逆操作，应由用户明确确认后再执行，详见人在回路的设计；
  • 警惕注入：工具返回的网页、邮件等外部内容可能包含恶意指令，模型可能被诱导调用其他工具，相关防御见提示注入攻击与防御。

从单个工具到 Agent

当模型能够连续多次调用工具，并根据每次结果决定下一步行动时，它就具备了 Agent 的雏形。随着工具数量增多，如何让不同应用复用同一套工具也成为问题，MCP 协议正是为此而生。

小结

Function Calling 是让大模型连接现实世界的桥梁。好的工具设计、严格的参数校验、清晰的错误反馈和合理的权限控制，决定了工具调用在生产环境中是否可靠。先从少量、只读、低风险的工具开始，逐步扩展，是稳妥的落地路径。