Function Call 面试题

CodeLong2026/4/21大约 5 分钟

Function Call 面试题

RAG 的能力边界是什么？为什么需要引入 Function Call？

RAG 的局限性： RAG（检索增强生成）的工作流程是基于用户提问在知识库（向量数据库）中检索相关文档并生成答案。因此，RAG 只能回答“静态知识库里有什么”，无法处理以下企业级场景需求：

查实时数据（如：我还剩几天年假？）
查业务状态（如：订单物流到哪了？）
执行操作（如：帮我提交请假申请。）

传统方案的缺陷：

Prompt 兜底回复：在 Prompt 中写死规则（如“问年假请去 HR 系统”），死板且用户体验极差。
规则匹配意图（NLP）：在代码里写 if-else 匹配关键词。规则写不完，维护成本高，且无法应对复杂的自然语言表达。每次新增工具都要改代码重启。

为什么引入 Function Call： Function Call 的核心优势是将判断用户意图和何时调用工具的逻辑交给大模型，而将执行工具的具体逻辑留给业务代码。模型擅长理解自然语言，代码擅长执行业务逻辑，各司其职，从而让 RAG 系统从“只能查资料”升级为“能调接口、能干活”。

请简述 Function Call 的本质以及它的完整交互流程？

Function Call 的本质： 模型并不是真正地去执行函数，而是输出一个包含调用意图的 JSON（例如：“我觉得应该调 A 函数，参数是 B”）。真正执行函数操作的是开发者的本地业务代码。

完整交互流程（多轮对话）：

定义工具并请求：开发者定义好工具列表（函数名、描述、参数），将其和用户问题一起发送给模型。
模型输出调用意图（第一轮响应）：模型判断需要调用某个工具，不生成文本答案，而是输出一个包含函数名和参数的 JSON（tool_calls）。
本地执行函数：开发者的代码解析这个 JSON，执行对应的本地函数（查库、调 API 等），拿到实际的业务结果。
返回结果给模型（第二轮请求）：开发者将“第一轮的用户问题”、“第一轮的模型响应”以及“本地函数执行结果”打包，再次发送给模型。
生成最终答案（第二轮响应）：模型基于开发者返回的函数执行结果，生成最终的自然语言答案。

在 OpenAI Function Call 协议中，工具是如何定义的？模型是根据什么判断选用哪个工具的？

在协议中，工具以 JSON 数组（tools）的形式发送给模型。每个工具包含以下核心字段：

type：固定为 function。
function.name：函数名称。
function.parameters：参数定义，使用 JSON Schema 格式（包含 type、properties、required 必填项等）。
function.description（最关键依据）：函数的功能描述。

模型判断的依据： 模型判断选用哪个工具的关键依据就是 function.description。描述必须清晰、具体地说明该工具的功能、适用场景以及参数含义。如果描述含糊不清，模型很容易选错工具。

在代码层面实现 Function Call 时，第二轮请求的消息构建有什么严格要求？

在执行完本地函数并将结果返回给模型时，第二轮请求的 messages 数组必须包含完整的对话历史，且顺序和角色（role）不能错，否则模型可能无法正确生成答案。

具体需要包含以下三条消息：

第一条消息（role = "user"）：用户的原始问题。
第二条消息（role = "assistant"）：第一轮的模型响应内容，必须带上 tool_calls 字段（包含 id 和 function 意图）。content 通常为 null。
第三条消息（role = "tool"）：函数实际的执行结果（JSON字符串）。必须带上 tool_call_id 字段（与第二条消息里的 id 严格对应）。

Function Call 在 RAG 系统中有哪些常见的应用模式？如何控制它调用工具的优先级？

常见应用模式：

意图识别自动路由：定义一个 searchKnowledgeBase 工具（用于传统 RAG 检索）和其他业务 API 工具。模型根据用户问题自动判断是查知识库还是调业务接口。
混合场景（知识检索 + 工具调用）：面对复杂问题（如“我的订单支持退货吗”），模型可以先调用订单 API 获取订单属性，再调用知识库检索退货政策，最后综合两部分信息生成答案（甚至支持一次输出多个工具调用并行处理）。

工具调用优先级控制：

通过 description 引导：在工具描述中写明“优先使用此工具查询XXX”。
通过 tool_choice 参数控制：
- auto：模型自由判断（默认）。
- none：不调用工具，仅文本回复。
- required：强制必须调用工具。
- 指定特定工具名：强制模型调用某一个具体的工具。
分阶段调用：先用一个轻量级工具做需求类型分类，再提供具体的底层工具。

Function Call 在实际企业项目落地中面临哪些痛点和局限性？业界提出了什么解决方案？

痛点与局限性：

维护成本高：每个工具都需要手写繁琐的 JSON Schema 参数定义，工具变更时容易造成代码与 Schema 脱节，难以实现数据库表到工具的自动映射。
跨系统集成复杂：协议本身不解决跨语言（Java/Python等）和异构网络系统之间的工具注册和 RPC 调用问题。
权限与安全控制缺失：模型可能伪造参数或越权调用工具（如 A 查 B 的数据，或 SQL 注入）。必须在业务代码层手动编写大量的权限与参数强校验逻辑。
可观测性不足：调用链路深（模型->工具A->工具B->数据库）时，日志记录、耗时追踪和 Debug 异常困难。

业界解决方案（引出 MCP）： 为了解决 Function Call 协议“只管调用，不管管理和安全”的痛点，业界提出了 MCP（Model Context Protocol）协议。MCP 旨在提供一套统一的工具描述、动态注册发现、标准化的安全权限控制以及内置的可观测性支持，是企业级工具调用的更高级标准化方案。