LLM工具调用速记：从Function Calling到MCP实战指南-优快云博客

1. 什么是“LLM工具调用速记”？它解决的不是技术问题，而是认知断层

你有没有过这种体验：刚学完Function Calling的概念，打开Dify文档看到 tools 字段配置，脑子是清楚的；可一到写真实业务逻辑——比如让模型查天气再生成周报——就卡在“该不该把城市名传给工具？要不要先做地址解析？返回的JSON字段名和我定义的对不上怎么办？”这些地方。这不是代码写错了，是 工具调用链路上的认知颗粒度太粗 。所谓“LLM工具调用速记”，不是教你怎么写JSON Schema，而是帮你把从Prompt设计、工具注册、参数映射、错误兜底到结果后处理这一整条链路，拆解成可触摸、可复现、可纠错的最小动作单元。它面向的不是理论研究者，而是每天要交付一个能调用数据库+发邮件+读Excel的Agent原型的工程师、产品原型师，甚至是有Python基础的运营同学。

核心关键词里，“LLM”是能力基座，“工具调用”是行为动词，“Function Calling”是技术实现机制，“MCP”是当前最活跃的协议层抽象（尤其在Figma、Trae、DevSpace等工具生态中高频出现），“Agent”则是最终形态。这五个词不是并列关系，而是层层包裹的洋葱结构：LLM提供语言理解与生成能力 → Function Calling是LLM与外部世界交互的“握手协议” → MCP是这套协议在多工具协同场景下的标准化封装 → Agent是调用行为被组织、编排、监控后的完整执行体。速记的本质，就是把这层叠关系压缩成一张随时能掏出来对照的“操作地图”。比如看到“figma mcp token在哪获取”，背后实际是“MCP客户端如何向Figma插件服务端完成身份鉴权”；看到“dify的sql查询内容太多导致llm返回不稳定”，本质是“LLM在Function Calling响应阶段对超长SQL结果的截断策略与重试机制缺失”。所有热搜词，都是这个链条上某个节点暴露出来的具体痛感。这篇文章不讲大模型原理，不堆API文档，只聚焦一件事：当你面对一个真实工具调用需求时，从零开始，每一步该想什么、做什么、防什么。

2. 工具调用不是“加个tools字段”，而是重构整个交互范式

2.1 为什么传统Prompt工程在工具调用面前失效了？

很多人以为工具调用只是“在Prompt里加一段描述+一个JSON Schema”，这是最大的认知陷阱。传统Prompt工程的核心是 单向指令传递 ：你告诉模型“做A”，模型输出“A的结果”。而工具调用引入了 双向状态流转 ：你告诉模型“做A”，模型说“我需要参数X”，你提供X，模型调用工具，工具返回Y，模型再基于Y生成最终回答。这个过程里，模型不再是终点，而是 中间协调器 。它的输出不再直接面向用户，而是面向下一个执行环节——可能是另一个工具、可能是你自己写的回调函数、也可能是MCP协议栈里的路由模块。

举个真实例子：某电商后台需要“根据用户ID查订单，再查对应商品库存，最后生成发货建议”。如果用纯Prompt，你会写：“请查询用户ID为12345的订单，然后查这些订单里商品的库存，最后给出是否能发货的建议”。LLM大概率会编造库存数据，因为它的训练数据里没有实时库存接口。而工具调用方案必须拆解为三个明确动作：

调用 get_orders_by_user_id(user_id: str) → 返回订单列表
对每个订单中的 product_id ，调用 get_stock_by_product_id(product_id: str) → 返回库存数
汇总结果，调用 generate_shipping_suggestion(orders_with_stock: list) → 返回建议文本

这里的关键转变在于： 模型的输出目标从“生成正确答案”变成了“生成可执行指令” 。它不需要知道库存API怎么认证，只需要按约定格式输出 {"name": "get_stock_by_product_id", "arguments": {"product_id": "P789"}} 。这个JSON结构本身，就是新范式下的“机器语言”。

2.2 Function Calling的底层契约：三要素缺一不可

所有主流框架（OpenAI、Anthropic、Ollama、Dify、LangChain）的Function Calling机制，都依赖三个硬性契约：

Schema契约 ：工具的JSON Schema必须精确描述输入参数类型、必填项、枚举值。比如 temperature 字段不能只写 "temperature": "0.7" ，而必须声明 "temperature": {"type": "number", "minimum": 0, "maximum": 2} 。我见过太多人因为漏写 "required": ["user_id"] ，导致模型传空字符串，下游服务直接500。
语义契约 ：模型必须理解工具名称和参数名的业务含义。 get_user_profile 和 fetch_user_data 在Schema上可能完全一样，但模型调用时会倾向选择前者——因为它在训练数据中更常与“用户资料”关联。这就是为什么Dify里建议工具名用 snake_case 且带业务前缀（如 crm_get_contact_by_email ），而不是 api_call_1 。
时序契约 ：调用必须严格遵循“请求→等待→响应→处理”四步。模型不能一边调用数据库，一边生成回复草稿。OpenAI的 tool_choice="auto" 模式会在模型判断需要工具时自动暂停输出，等你返回结果后再继续。如果你在回调里延迟返回（比如查库存耗时2秒），模型会卡住2秒——这直接影响用户体验。很多“llm返回不稳定”的问题，根源其实是工具响应超时未设兜底，导致整个调用链断裂。

提示：不要迷信“auto”模式。在高并发场景下，显式控制 tool_choice 更可靠。比如先用 tool_choice="none" 让模型判断是否需要工具，确认后再切到 tool_choice={"type": "function", "function": {"name": "get_orders"}} ，避免模型在不需要时强行生成无效调用。