跳到正文

Function Calling 消息流

Function/Tool Calling 的消息流、参数 schema 和回填原理

原题：请详细解释大模型中Function Calling机制的实现原理，包括其工作机制、流程设计、消息格式规范，以及在Agent系统中的核心作用和实际应用场景。结合实例说明其如何提升模型与外部工具的交互能力。

Agent · 百度真题

回答与解析

核心本质

Function Calling不是模型"执行"函数，而是模型生成结构化的函数调用意图（函数名+参数），由外部系统实际执行并返回结果。这是大模型从"文本生成器"升级为"决策中枢"的关键机制。

工作机制与流程

四步闭环：

  1. 声明阶段：系统向模型注册可用工具（函数名、描述、参数Schema）
  2. 识别阶段：模型分析用户意图，判断是否需要调用工具
  3. 生成阶段：如需调用，输出tool_calls结构化JSON（含id、function.name、arguments）
  4. 执行阶段：外部系统解析JSON，执行真实函数，将结果以tool消息角色回传

消息格式示例：

// 系统提示中的工具声明
{"type": "function", "function": {"name": "get_weather", "description": "...", "parameters": {"type": "object", "properties": {"city": {"type": "string"}}}}}

// 模型输出的调用请求
{"role": "assistant", "tool_calls": [{"id": "call_123", "type": "function", "function": {"name": "get_weather", "arguments": "{\"city\": \"北京\"}"}}]}

// 工具执行结果回传
{"role": "tool", "tool_call_id": "call_123", "content": "{\"temperature\": 25, \"condition\": \"晴\"}"}

在Agent系统中的核心作用

能力维度 具体作用
感知扩展 突破预训练知识边界，实时获取天气、股价、数据库等外部信息
行动执行 调用API完成订票、发邮件、操作数据库等实际动作
复杂规划 多工具链式调用（如：查天气→推荐穿搭→生成图片）
确定性输出 通过JSON Schema约束，解决纯文本输出的解析不可靠问题

典型应用场景

智能客服Agent示例：

用户：帮我查下订单12345的物流，如果明天到不了就取消
→ 模型识别需调用：query_order(12345) → get_logistics(order_id)
→ 执行后返回：预计后天到达
→ 模型决策：调用 cancel_order(12345)，生成确认话术

关键设计要点

  • Schema设计：参数描述要清晰，必填/可选明确，避免模型幻觉参数
  • 并行调用：支持单次请求多个tool_calls，提升效率
  • 错误处理：工具执行失败时，将错误信息回传模型让其重试或调整策略
  • 安全隔离：模型只生成调用意图，实际执行在沙箱环境，防止Prompt注入攻击

学习建议

建议先掌握大模型基础交互流程，再学习JSON Schema和API调用原理，通过动手实现一个简单的Function Call代理来加深理解。

口语版讲法(约4分钟)

  • 一句话定位：Function Calling让模型从文本生成器变成决策中枢
  • 边界划分：和RAG、Agent的适用场景区别
  • 工作机制：四步闭环 + 消息格式实例
  • 真实业务：智能客服处理订单取消
  • 落地风险与判断取舍

这道题其实是在问，大模型怎么从单纯的文本生成器，升级成一个能调用外部工具的决策中枢。Function Calling本质上不是让模型去执行函数，而是让模型输出一个结构化的调用意图，包括函数名和参数，真正的执行由外部系统来做。这个边界一定要清楚，模型不负责执行，只负责决策。

和相邻方案比，它的适用场景很明确。如果模型只是需要补充知识，比如回答一个事实性问题，那用RAG去检索文档库就够。但如果模型需要完成一个动作，比如查天气、订票、操作数据库，那就必须靠Function Calling。Agent系统里它又是核心，因为Agent需要感知外部世界、执行行动、做复杂规划。但真正落地的时候，往往不是单一方案，比如智能客服，既需要RAG查知识库答复客户，又需要Function Calling去查物流、取消订单，两者配合。

具体说一下工作机制，是个四步闭环。第一步声明阶段，系统向模型注册可用工具，包括函数名、描述、参数Schema。第二步识别阶段，模型分析用户意图，判断需不需要调用工具。第三步生成阶段，如果需要，模型输出一个tool calls的JSON，里面有调用ID、函数名、参数。第四步执行阶段，外部系统解析这个JSON，执行真实函数，把结果以tool角色回传给模型。举个例子，用户问“北京天气怎么样”，系统注册了get weather函数，参数是城市。模型识别到需要调用，就输出{"role": "assistant", "tool calls": [{"id": "call 123", "type": "function", "function": {"name": "get weather", "arguments": "{\"city\": \"北京\"}"}}]}。外部执行后回传{"role": "tool", "tool call id": "call 123", "content": "{\"temperature\": 25}"}。模型拿到结果再生成自然语言回复。

真实业务场景，比如智能客服处理订单取消。用户说“帮我查下订单12345的物流，如果明天到不了就取消”。模型需要先调用query order(12345)获取订单信息，再调用get logistics(order id)查物流，得到预计后天到达，于是决定调用cancel order(12345)，最后生成确认话术。这里的关键是链式调用，模型根据前一步的结果决定下一步动作。

落地的时候有几个风险点我必须特别关注。首先是Schema设计，参数描述要清晰，必填可选要明确，不然模型容易幻觉参数，比如把城市名写成“BeiJing”而不是“北京”。其次是错误处理，工具执行失败时，要把错误信息回传给模型，让它重试或调整策略，不能直接崩掉。还有就是安全隔离，模型只生成调用意图，实际执行要在沙箱环境，防止Prompt注入攻击。如果不满足这些前提，上线后很常见的情况是模型生成错误的参数导致调用失败，或者被用户恶意利用。

还有一个延伸点值得注意，就是并行调用。单次请求可以返回多个tool calls，比如同时查天气和查新闻，模型会自己判断哪些调用可以并行。这在效率提升上很有价值，但也增加了复杂度，模型可能会生成互相依赖的调用顺序。

所以我会把Function Calling看成模型和外部世界之间的翻译层，它的价值在于让模型的动作意图变得可执行、可验证。我更倾向于设计时把工具粒度做细，参数Schema做严格，同时做好错误回退，这样Agent才能稳定跑起来。

关键一句:并行调用可以同时发起多个工具请求，但需要处理好依赖关系和错误回退。

面试官还可能这样问

  1. 问法 1 · 场景切入

    我看你做过客服Agent，假设用户说‘帮我查一下上个月的订单，如果超过500元就退款’，模型需要调用两个API：先查订单，再判断金额是否触发退款。你怎么让模型知道有哪些API可用，并且能按顺序调用？

  2. 问法 2 · 层层追问

    大模型怎么做工具调用？……如果模型返回一段文本说‘调用天气API，参数北京’，你直接解析文本靠谱吗？……那有没有更结构化的方式让模型明确输出调用意图？

  3. 问法 3 · 直球架构

    请解释Function Calling的完整流程，从工具注册到模型输出tool_calls再到结果回传，消息格式具体怎么定义？在Agent里它解决了什么核心问题，比如感知扩展、确定性输出这些。

同模块相关题目