001｜Function Calling 原理：LLM 怎么调用外部工具

核心结论：Function Calling（方克·慎·考·灵，函数调用）不是 LLM 自己执行代码，而是 LLM 生成结构化参数，由外部系统调用工具，再把结果交给 LLM 继续推理。它让 LLM 从文本生成器变成能操作真实世界的 Agent 大脑。

一、为什么需要 Function Calling

LLM 本身只有文本生成能力。它不能查数据库、不能调 API、不能计算、不能发邮件。

但企业里的 Agent 必须能做事：

用户：帮我查一下昨天广东的销售额。
LLM 直接回答：抱歉，我查不到。
Agent 回答：好的，我调用 sales_query 工具，返回结果是 1,200,000 元。

Function Calling 就是桥接 LLM 和外部世界的关键机制。

二、Function Calling 的本质

核心流程：

用户提出问题 → LLM 判断需要工具 → 生成 JSON 参数 → 外部系统调用工具 → 返回结果 → LLM 生成最终答案

注意：LLM 不执行工具，只决定调用什么和传什么参数。

三、完整例子

工具定义：

functions = [{
    "name": "query_sales",
    "description": "当用户询问指定区域和日期的销售额时使用",
    "parameters": {
        "type": "object",
        "properties": {
            "region": {"type": "string", "description": "区域，如广东"},
            "date": {"type": "string", "description": "日期，YYYY-MM-DD"}
        },
        "required": ["region", "date"]
    }
}]

用户问'昨天广东的销售额'，LLM 返回：

{"name": "query_sales", "arguments": {"region": "广东", "date": "2026-07-14"}}

系统执行后得到 {"sales": 1200000}，再交给 LLM 生成最终回答。

四、三种实现方式对比

方式	优点	缺点
纯 Prompt 输出 JSON	兼容性好	格式不稳定，需后处理
Native Function Calling	输出稳定，结构化	依赖模型支持
框架封装（LangChain/LlamaIndex）	生态好，统一注册	增加抽象层

面试建议：优先用原生，不支持就 Prompt + 解析，生产用框架封装。

五、关键设计点

工具描述要精准，告诉 LLM 什么时候用。
参数要做 schema 校验，不合法就返回错误重试。
工具结果要明确反馈，失败也要告诉 LLM。
限制最大调用次数，防止循环。

六、常见错误与解决

错误	原因	解决
参数 hallucination	LLM 编造参数	工具描述更精确；失败后重试
选错工具	工具描述模糊	优化 description；减少工具数量
参数格式错误	模型没按 schema 输出	后校验 + 返回错误重试
不调用工具	LLM 直接回答	prompt 中明确要求使用工具

七、面试高频问答

Q：Function Calling 和直接写 Prompt 输出 JSON 有什么区别？

原生 Function Calling 是模型专门训练的能力，输出更稳定、结构更可靠。Prompt 方式兼容性更好，但容易格式错乱，需要后处理。

Q：怎么防止 LLM 调用危险工具？

三层防护：工具层只暴露只读或受限操作；Agent 层在 prompt 里约束；系统层做权限校验和审计。比如查询工具只能 SELECT。

八、一句话总结

Function Calling 是 LLM 的手和脚，让它能摸到真实世界。但真正的 Agent 还要知道什么时候调用、调用错了怎么办、怎么把结果组合起来。

下一步推荐

002｜ReAct / CoT / ToT / Plan-and-Execute：Agent 的推理模式对比
003｜MCP 协议：模型上下文协议如何统一工具生态