Function Calling 工具调用机制

可视化演示

展示大模型Function Calling完整调用流程（用户提问→模型输出工具调用→外部执行→结果返回→模型回复），以及多轮工具调用的上下文管理机制。

原理概述：从纸上谈兵到动手办事

以前的 AI 像一位只会纸上谈兵的顾问——聊起天气头头是道，却从没看过窗外一眼。Function Calling 像是给这位顾问配了一部直达世界的电话，让他真的能订餐厅、查库存、发邮件。在传统大模型对话里，模型只能接收文本、输出文本，既无法访问实时数据，也无法触发任何外部操作。Function Calling 机制改变了这一点：当模型判定需要外部信息或动作时，它会在回复中输出一个结构化的“工具调用意图”，而不是普通文本。这个意图包含两样东西：想调用哪个工具，以及传给该工具的参数。真正执行工具的是你的应用代码，而不是模型本身。

这套设计的精髓是“决策与执行分离”：模型扮演高智商的指挥官，代码扮演忠实执行者。OpenAI 等厂商在 API 中提供了 tools 参数，让开发者把工具清单传给模型。模型阅读清单后，若认为某个函数能解决问题，就会在返回体中携带 tool_calls 字段。

一旦管家确认需要外援，就把主人的需求转成服务卡上的标准话术——这正是模型输出 tool_call 的过程。理解了这个“决策”与“执行”的分工，你就抓住了 Function Calling 最关键的一根主轴。

工具定义Schema：给管家一本服务手册

管家手册里，每张服务卡都写清楚“师傅专长”和“需要材料”。模型能读的“服务卡”就是工具 Schema。为了让模型在几百个候选函数中挑对那一个，开发者必须把每个工具翻译成结构化描述，通常采用 JSON Schema 格式：声明函数名、函数用途、参数含义与类型、哪些参数必填。这个翻译的产物就是函数 Schema。

以 OpenAI 格式为例，每个工具定义包含 type: “function“、function.name、function.description、function.parameters。模型依据 description 来决定何时调用该函数，依据 parameters 来生成合法的参数 JSON。若描述模糊，模型会选错工具；若参数限定不严，模型可能编造缺失字段。实践中，推荐把边界条件写进描述里，例如”当用户询问某城市当天温度时调用”。

服务卡写得越清楚，管家拨号时越不会张冠李戴——Schema 质量直接决定工具调用的成败。很多线上事故的根源，不是模型不够聪明，而是“服务卡”写得含糊。

调用请求流程：一次规范的电话

管家确认要找外援后，第一步是拨通电话——把需求转成电话线上能传输的“话术”。这就是请求中的消息构造。Function Calling 并不是一套独立的离线模型，而是在对话 API 上加了一个 tools 参数。调用时，应用把历史消息与工具清单一起发送给模型 API。模型阅读后决定：要么继续聊天，要么返回一个或多个工具调用。

一次典型的请求流程为：构造 messages（system、user、历史 tool 消息）→ 附加 tools 列表 → 调用 chat completions 接口 → 检查响应中的 tool_calls 字段。若存在，取出函数名和 arguments；若不存在，直接使用 content 作为回复。这个流程由应用层驱动，模型端始终保持无状态，每次请求都携带完整上下文。

电话拨通了，管家报出需求，总机（模型）判断“这事该转接到工具部门”——于是响应里就有了 tool_calls。你的代码收到这个信号后，从“对话模式”切换到“执行模式”。

返回值解析：把成品交回管家

师傅干完活，把成品交回给管家。管家得先确认“这个结果是对应哪张单子的”，再整理进小本本。对应到代码里，就是工具结果的解析与回传。当模型返回 tool_calls 后，应用代码接管：解析 arguments JSON 字符串，按函数名分发到真实函数，拿到返回值后，以 role: "tool" 的消息追加回对话。

具体而言，需要读取 tool_call.id 作为本次调用的唯一标识；用 JSON.parse 解析 arguments；调用函数获得结果；然后构造一条 tool 角色消息，包含 tool_call_id 和结果内容，发给模型。模型看到 tool 消息后，结合之前的问题生成面向用户的可读回答。此处最常见的错误是忘记携带 tool_call_id，导致消息匹配失败、模型不知道结果属于哪次调用。

管家把成品贴上订单号（tool_call_id）记进小本本里，之后才能向主人准确汇报。解析与回传看似琐碎，却是连接“模型世界”与“真实世界”最关键的一环。

多轮调用管理：连环电话与小本本

办一件事往往要打一串电话：先问财务、再订酒店、最后安排接机。每一次沟通结果都必须记在小本本上，否则后面的大脑就断片了。单次工具返回还不够时，模型会继续发起新的工具调用，形成多轮循环。这种“调用→回传→再调用”的模式让 Agent 能完成复合任务。

实现的核心是消息累积。每一轮都把模型的 tool_calls 消息和工具结果消息追加进 messages，再重新调用模型。循环的终止条件是模型不再返回 tool_calls，而是给出纯文本回复。为防止异常死循环，工程上必须设置最大轮数上限，同时可以支持一次返回多个并行 tool_calls 来减少往返时延。

小本本越记越厚，管家的大脑从不断片——这正是多轮工具调用的精妙与代价：记忆完好，但账单（token）也越来越厚。优秀的 Agent 设计会尽量合并步骤、减少往返次数。

错误处理策略：电话打不通怎么办

谁也保不齐电话打不通、师傅说材料不对。真正的管家不会懵在原地，而是把状况记进小本本，再想办法补救。工具调用涉及网络、权限、数据格式等多个环节，失败在所难免。成熟的 Function Calling 应用会把“错误也当成一种结果”回传给模型，让模型基于错误信息调整方案后重试。

常见错误包括：参数 JSON 非法、函数抛异常、网络超时。工程策略通常为：先用 try/except 包裹函数执行；捕获异常后构造格式化的 error 消息，作为 tool 结果返回；设置超时与重试次数；若模型反复失败且超过轮数上限，则降级为人工处理或向用户如实说明。核心原则是：永远不要把崩溃留给调用方，而是把错误变成模型可读的输入。

管家把“师傅关机了”如实记下，转头告诉你“这单可能需要明天再办”——错误处理让 AI 变得诚实而从容，而不是假装成功。好的错误处理，是把不可控的故障转化为可控的对话。

安全与限制：保险箱与厚厚的电话簿

服务热线解决了很多问题，但管家也面临新考验：陌生人假冒主人怎么办？保险柜钥匙该给谁？电话簿厚到看不完怎么办？Function Calling 虽然强大，却引入了新的攻击面。模型可能被工具结果中的恶意文本诱导（Prompt 注入），也可能被用户引导去调用高权限工具。同时，每个工具的 Schema 描述都会占用 token，工具越多请求越贵。

工程上建议：遵循最小权限原则，模型只提供“意图”，权限校验放在应用层；对工具返回内容做过滤，必要时用独立消息角色区分“工具数据”与“指令”；限制工具数量，把高频工具的 Schema 短描述化；对敏感操作要求二次确认。成本方面，可以用近似公式估算每次请求的 token 开销。

管家业务能力再强，主人也不能把保险箱钥匙随手放在桌上——能力越大，边界设计越重要。安全不是上线后的补丁，而是架构阶段就要埋下的地基。

应用场景：管家真正独当一面

从纸上谈兵到独当一面，装上电话簿的管家终于能真正办事了。Function Calling 已经渗透到 AI 应用的方方面面：从最简单的天气查询，到复杂的业务系统集成与自主规划 Agent。典型场景有三类：一是数据查询服务，模型把用户的自然语言转成结构化查询参数，调用数据库或第三方 API；二是业务集成，模型直接触发工单创建、订单取消、邮件发送等内部系统操作；三是 Agent 多步规划，模型自主分解任务，反复调用多个工具直至目标完成。参考 [OpenAI Function Calling 文档](0)，这套范式已经成为 Agent 类应用的标准底座。

装了电话簿的管家，终于登上了“高级 Agent”的舞台——他不再只是哲学家，更是能办实事的首席助理。理解了这个最小公式，你就理解了当下大模型应用层最壮阔的风景。

AI 应用场景

Python 演示

import jsonimport random # 工具定义 schema (类似 OpenAI 的 tools 参数)TOOLS = [    {        "type": "function",        "function": {            "name": "get_weather",            "description": "查询指定城市的当前天气",            "parameters": {                "type": "object",                "properties": {                    "location": {"type": "string", "description": "城市名, 如 杭州"}                },                "required": ["location"]            }        }    },    {        "type": "function",        "function": {            "name": "add_todo",            "description": "添加一条待办事项",            "parameters": {                "type": "object",                "properties": {                    "task": {"type": "string", "description": "待办内容"}                },                "required": ["task"]            }        }    }]  def get_weather(location):    """模拟天气查询接口"""    conditions = ["晴", "多云", "小雨"]    return json.dumps({        "location": location,        "condition": random.choice(conditions),        "temp": random.randint(15, 35)    })  def add_todo(task):    """模拟待办写入接口"""    return json.dumps({"status": "ok", "task": task, "id": random.randint(1000, 9999)})  def run_tool(name, args):    """根据函数名分发到真实函数"""    if name == "get_weather":        return get_weather(args["location"])    if name == "add_todo":        return add_todo(args["task"])    return json.dumps({"error": "unknown tool: " + name})  def mock_llm(messages, tools):    """模拟大模型返回: 有工具结果就收尾, 否则按关键词发起调用"""    has_result = any(m["role"] == "tool" for m in messages)    if has_result:        return {"content": "好的, 天气已查好, 待办也记上了。", "tool_calls": []}    text = messages[-1]["content"]    calls = []    if "天气" in text:        calls.append({            "id": "call_001",            "function": {"name": "get_weather", "arguments": '{"location": "杭州"}'}        })    if "待办" in text or "记账" in text:        calls.append({            "id": "call_002",            "function": {"name": "add_todo", "arguments": '{"task": "买牛奶"}'}        })    return {"content": None if calls else "好的, 我知道了。", "tool_calls": calls}  def main():    messages = [{"role": "user", "content": "帮我查杭州天气, 并把买牛奶记到待办"}]    for _ in range(3):        resp = mock_llm(messages, TOOLS)        if not resp["tool_calls"]:            print("[最终回复]", resp["content"])            break        for call in resp["tool_calls"]:            fn = call["function"]            args = json.loads(fn["arguments"])            result = run_tool(fn["name"], args)            print("[工具执行]", fn["name"], "->", result)            messages.append({"role": "assistant", "content": None, "tool_calls": [call]})            messages.append({"role": "tool", "tool_call_id": call["id"], "content": result})  if __name__ == "__main__":    main()

1. TOOLS = [...]工具清单就是给模型读的“服务手册”，上面写清每个函数的能力。
2. "description": "查询指定城市的当前天气"描述决定模型何时选中这个工具，选型全靠它。
3. def run_tool(name, args):真正执行函数的分发中心，模型不执行代码，你的代码才执行。
4. json.loads(fn["arguments"])把模型给的 JSON 字符串转成 Python 对象，这是“翻译官”的一步。
5. messages.append({"role": "tool", ...})工具结果回传，模型才知道“这件事办完了”。
6. if not resp["tool_calls"]:没有工具调用就说明该收尾了，这是循环终止的判据。
7. for _ in range(3):最大轮数兜底，防止模型陷入无休止的工具调用死循环。

常见误区

面试题