LLM 工具调用面试题
高频问题地图
- 什么是 Function Calling？
- LLM 是如何学会调用工具的？
- Function Calling 和 Tools 有什么区别？
- 什么是 MCP？
- MCP 由哪些部分组成？
- MCP 和 Function Calling 有什么区别？
- 什么是 Skill？
- Function Calling、Skill、MCP 三者有什么区别？
- 什么是 A2A 协议？
- SSE 和 WebSocket 有什么区别？
- WebRTC 在 AI 对话流中有什么价值？
- LLM 网关解决什么问题？
- 工具调用如何做权限控制？
- 工具调用如何做安全审查？
核心概念速记
Function Calling：LLM 根据用户请求，生成结构化的函数调用请求（函数名 + 参数 JSON），由外部系统执行后把结果返回给模型。模型不直接执行函数，只输出调用意图。
Tools：Function Calling 的演进形式。一个请求可以声明多个工具，模型自主决定调用哪个工具、是否调用、调用顺序。比单个 Function Calling 更灵活。
MCP（Model Context Protocol）：Anthropic 提出的标准化协议，定义模型和外部工具/数据源之间的通信规范。组成部分包括 Host（宿主应用）、Client（协议客户端）、Server（工具/数据提供方）、Transport（通信层）。
Skill：比 Tool 更高层的概念。Tool 解决"能不能做"，Skill 解决"怎么做得专业"。Skill 包含任务流程、方法论、质量检查清单，是可复用的任务说明书。
A2A（Agent-to-Agent）：Google 提出的 Agent 间通信协议，让不同 Agent 可以发现彼此、协商任务、交换结果。
SSE（Server-Sent Events）：服务端单向推送的流式传输协议，适合 LLM token 流式输出。基于 HTTP，轻量简单。
WebSocket：全双工双向通信协议，适合需要实时交互的场景。比 SSE 重，但支持双向。
WebRTC：浏览器端到端实时通信协议，支持音视频和数据传输。在 AI 对话中可用于语音交互场景。
LLM 网关：统一管理多个 LLM 提供商的中间层，负责路由、负载均衡、降级、限流、计费、审计。
Q1：什么是 Function Calling？它解决了什么问题？
标准回答
Function Calling 是大语言模型的一种能力，让模型能够根据用户请求生成结构化的函数调用请求。具体来说，模型不直接执行函数，而是输出一个包含函数名和参数 JSON 的调用意图，由外部系统负责实际执行，执行结果再返回给模型继续推理。
Function Calling 解决了 LLM 的两个核心限制。第一个限制是"只能生成文本"：没有 Function Calling 之前，模型只能输出自然语言，无法与外部系统交互。有了 Function Calling，模型可以表达"我想调用某个函数"的意图，由外部系统执行后把结果注入对话，模型就能基于真实数据回答问题。第二个限制是"无法获取实时信息"：模型的训练数据有截止日期，无法获取实时天气、股价、数据库内容等信息。Function Calling 让模型能通过调用外部 API 获取实时数据。
从技术实现看，Function Calling 依赖于模型在训练阶段学习了如何根据工具描述生成符合参数 schema 的调用请求。模型通过工具的名称、描述和参数定义来理解工具的用途和调用方式。
面试官追问
- Function Calling 是模型原生能力还是通过微调实现的？
- 如果模型生成的参数 JSON 格式错误怎么办？
- Function Calling 的准确率受什么因素影响？
工程化理解
工程中 Function Calling 的实现需要三个环节：工具注册（定义工具的名称、描述、参数 schema 并传给模型）、调用解析（从模型输出中提取函数名和参数）、结果注入（把执行结果格式化后注入对话上下文）。参数校验是关键环节：模型生成的 JSON 可能不符合 schema 定义，需要在执行前做严格校验。错误处理也很重要：工具执行可能失败，失败信息需要回传给模型，让模型决定是否重试或换一种方式。
常见误区
- 认为 Function Calling 是模型在执行函数：模型只输出调用意图，执行的是外部系统。
- 忽略工具描述的质量：工具名称和描述直接影响模型的调用准确率，写得不清楚模型就会调用错误。
- 不做参数校验就执行：模型生成的参数可能有格式错误、类型错误、甚至恶意注入，必须校验后才能执行。
背诵版总结
Function Calling 让 LLM 能输出结构化的函数调用意图，由外部系统执行后把结果返回给模型。解决了 LLM "只能生成文本"和"无法获取实时信息"两个限制。模型不执行函数，只输出调用意图。工程实现需要关注工具描述质量、参数校验和错误处理。工具描述越清晰，模型调用准确率越高。
Q2：LLM 是如何调用外部工具的？模型负责什么，系统负责什么？
标准回答
LLM 调用外部工具的流程可以分为模型侧和系统侧两个部分。
模型侧负责理解用户意图和生成调用请求。模型根据用户输入和可用工具列表，判断是否需要调用工具、调用哪个工具、用什么参数。模型的输出是一个结构化的调用请求，包含函数名和参数 JSON。模型不执行任何实际操作，它只是在"表达意图"。
系统侧负责工具的注册、执行和结果注入。系统在调用模型前，把所有可用工具的 schema 注册到请求参数中。收到模型的调用请求后，系统解析请求、校验参数、执行工具、获取结果，然后把结果格式化后注入到对话上下文中，让模型基于工具返回的真实数据继续推理。
这种分工的核心原因是安全性和可控性。如果让模型直接执行代码或调用 API，就无法做权限控制和安全审查。通过"模型输出意图、系统负责执行"的模式，系统可以在执行前做参数校验、权限检查、敏感操作审批等安全措施。
面试官追问
- 模型怎么知道该调用哪个工具？是靠工具名称还是工具描述？
- 如果多个工具功能相近，模型选错了怎么办？
- 工具执行结果太大（如返回了大量数据），怎么处理？
工程化理解
工程中，工具的注册方式是把工具的 JSON Schema 传给模型的 API 请求。工具描述的质量直接影响调用准确率：名称要简洁明确、描述要说明用途和适用场景、参数要标注类型和必填性。工具执行结果可能很大，需要做截断或摘要处理后再注入上下文，避免超出上下文窗口。如果模型选错工具，可以通过优化工具描述、减少功能重叠、或在 Prompt 中增加选择指引来改善。
常见误区
- 认为模型能直接访问外部系统：模型只能输出文本，所有外部操作都由系统执行。
- 忽略工具描述对调用质量的影响：工具描述写得不好，模型就会调用错误或不调用。
- 不处理工具执行失败的情况：工具执行失败是常态，需要把失败信息回传给模型。
背诵版总结
LLM 调用工具分模型侧和系统侧。模型侧负责理解意图、生成调用请求（函数名 + 参数）。系统侧负责工具注册、参数校验、执行、结果注入。这种分工保证了安全性和可控性。工具描述的质量直接决定调用准确率。执行结果需要截断或摘要后再注入上下文。
Q3：Function Calling 和 Tools 有什么区别？
标准回答
Function Calling 和 Tools 本质上是同一种能力的不同演进阶段。
早期的 Function Calling 是单函数调用模式：开发者在请求中定义一个函数，模型判断是否调用这个函数以及用什么参数。模型的决策空间是"调用或不调用这一个函数"。
Tools 是 Function Calling 的演进形式。一个请求中可以声明多个工具，每个工具有独立的名称、描述和参数 schema。模型的决策空间扩展为"从多个工具中选择调用哪个、是否调用、调用顺序、是否需要连续调用多个工具"。这大大增强了模型的自主决策能力。
核心区别在于模型的决策范围。Function Calling 是"给定一个函数，要不要调用"，Tools 是"给定一组工具，选择调用哪个"。Tools 模式下，模型可以自主比较不同工具的适用性，选择最合适的工具来完成任务。这也是 Agent 架构的基础：Agent 通过 Tools 模式获得了自主选择行动的能力。
面试官追问
- Tools 模式下，模型是根据什么选择工具的？名称、描述还是参数？
- 如果工具太多（比如 100 个），模型还能准确选择吗？
- 多工具调用的顺序是模型决定的还是系统决定的？
工程化理解
工程中，Tools 模式需要解决工具数量管理和工具选择准确性两个问题。当工具数量很多时，不可能把所有工具 schema 都塞进一个请求（会超出上下文窗口），需要做工具筛选：根据用户意图预筛选出最相关的 5-10 个工具，只把这些工具注册到请求中。工具选择准确性依赖于工具描述的质量和工具之间的功能区分度。如果两个工具描述高度重叠，模型就容易选错。
常见误区
- 认为 Function Calling 和 Tools 是完全不同的技术：Tools 是 Function Calling 的演进，底层机制相同。
- 认为工具越多越好：工具太多会增加模型的选择难度，反而降低准确率。
- 忽略工具去重和冲突处理：功能相近的工具会干扰模型选择。
背诵版总结
Function Calling 是单函数调用模式，Tools 是多工具选择模式。核心区别是模型的决策范围：Function Calling 决定"要不要调用"，Tools 决定"调用哪个"。Tools 是 Agent 架构的基础，让模型获得了自主选择行动的能力。工程中需要控制工具数量、优化工具描述、处理工具间的功能重叠。
Q4：什么是 MCP？它和 Function Calling 有什么区别？
标准回答
MCP（Model Context Protocol）是 Anthropic 提出的标准化协议，定义了模型和外部工具、数据源之间的通信规范。MCP 的目标是让工具和数据源的接入标准化，避免每个应用都要为每个工具写定制的对接代码。
MCP 的架构由四个部分组成。Host 是宿主应用（如 IDE、聊天客户端），负责发起请求。Client 是协议客户端，运行在 Host 内部，负责和 Server 通信。Server 是工具和数据的提供方，实现 MCP 协议接口，暴露工具和资源。Transport 是通信层，支持 stdio、SSE、HTTP 等多种传输方式。
MCP 和 Function Calling 的区别在于层次不同。Function Calling 是模型层面的能力，定义了模型如何输出工具调用意图。MCP 是协议层面的标准，定义了应用和工具之间如何通信。Function Calling 解决的是"模型怎么表达调用意图"，MCP 解决的是"工具怎么被发现和接入"。两者是互补关系：MCP Server 暴露工具，Function Calling 让模型调用工具。
面试官追问
- MCP 的标准化价值体现在哪里？没有 MCP 之前有什么问题？
- MCP Server 怎么注册到 Host 应用中？是静态配置还是动态发现？
- MCP 的安全模型是什么？谁来控制哪些工具可以被调用？
工程化理解
MCP 的工程价值在于降低了工具接入的边际成本。没有 MCP 之前，每个工具都需要写定制的适配代码，工具和应用强耦合。有了 MCP，工具开发者只需要实现 MCP Server 接口，就能被所有支持 MCP 的 Host 应用使用。工程中需要注意 MCP Server 的版本管理、错误处理、超时控制、以及权限管理。MCP Server 可以声明自己需要的权限（如文件读写、网络请求），Host 应用负责审批和授权。
常见误区
- 混淆 MCP 和 Function Calling 的层次：Function Calling 是模型能力，MCP 是通信协议，两者解决不同问题。
- 认为 MCP 能替代 Function Calling：MCP 是工具的发现和接入标准，Function Calling 是模型的调用机制，两者互补。
- 忽略 MCP 的安全设计：MCP Server 可以执行任意代码，需要严格的权限控制和沙箱隔离。
背诵版总结
MCP 是 Anthropic 提出的标准化协议，定义模型和工具/数据源之间的通信规范。架构由 Host、Client、Server、Transport 四部分组成。和 Function Calling 的区别是层次不同：Function Calling 是模型能力（怎么表达调用意图），MCP 是协议标准（工具怎么被发现和接入）。两者互补：MCP Server 暴露工具，Function Calling 让模型调用工具。MCP 的核心价值是降低工具接入的边际成本。
Q5：工具调用如何做权限控制和安全审查？
标准回答
工具调用的权限控制和安全审查是 Agent 系统中最重要的安全环节，因为工具调用意味着模型能触发真实世界的操作。
权限控制通常分三个层次。第一层是工具级权限：在工具注册时声明该工具的权限级别，比如"只读"、"需要审批"、"禁止自动执行"。系统根据权限级别决定工具是否可以被调用、是否需要人工确认。第二层是参数级权限：对工具的参数做校验和过滤，比如文件操作工具限制只能访问特定目录，数据库查询工具限制只能执行 SELECT 语句。第三层是用户级权限：不同用户有不同的工具使用权限，管理员可以使用更多工具，普通用户只能使用安全工具。
安全审查包括调用前审查和调用后审查。调用前审查检查参数是否合法、是否包含注入攻击、是否超出权限范围。调用后审查检查执行结果是否包含敏感信息、是否需要脱敏处理后再注入上下文。
面试官追问
- 如果模型被 Prompt 注入攻击诱导调用危险工具，怎么防护？
- 敏感操作（如删除数据、发送邮件）的审批流程怎么设计？
- 工具执行结果可能包含敏感信息，怎么在注入上下文前做脱敏？
工程化理解
工程中，权限控制通常通过一个中间层实现：所有工具调用都经过这个中间层，中间层负责权限检查、参数校验、审批流程。敏感操作需要人工确认时，系统暂停执行，把操作详情展示给用户，用户确认后才继续执行。这和 Human-in-the-loop 机制结合。调用日志需要完整记录每次工具调用的输入、输出、执行时间、结果状态，用于审计和问题追溯。对于高风险工具（如代码执行、文件删除），建议在沙箱环境中执行，限制其对宿主系统的影响。
常见误区
- 不做参数校验就直接执行：模型生成的参数可能包含恶意内容（如 SQL 注入、路径遍历），必须校验。
- 认为模型不会调用危险工具：Prompt 注入攻击可以诱导模型调用任何已注册的工具，权限控制不能依赖模型的"判断"。
- 不记录工具调用日志：没有日志就无法审计和追溯，出问题时无法定位原因。
背诵版总结
工具调用的权限控制分三层：工具级（声明权限级别）、参数级（校验和过滤参数）、用户级（不同用户不同权限）。安全审查分调用前（参数校验、注入检测）和调用后（结果脱敏）。敏感操作需要人工确认，结合 Human-in-the-loop 机制。核心原则是"不信任模型输出"：所有工具调用都必须经过系统侧的校验和审批。