大模型工具调用的基本原理是什么？为什么需要函数调用格式？
简化版
工具调用是让模型在需要外部能力时输出结构化的函数名和参数，由程序执行工具，再把结果返回给模型继续推理。函数调用格式能减少自然语言解析歧义，让权限、参数校验、重试和审计都更容易落地。
详细版
- 模型本身不直接执行工具，它只生成调用意图和参数。
- 工具 schema 描述名称、参数类型、必填字段和含义。
- 执行层负责鉴权、参数校验、调用外部系统和处理错误。
- 工具结果再次进入上下文，模型基于结果组织最终回答。
- 高风险工具必须有人类确认或代码侧权限控制。
完整版教学
这道题考察候选人是否理解 LLM 应用从“聊天”走向“可执行系统”的关键接口。
一、这题真正考什么
这道题考察候选人是否理解 LLM 应用从“聊天”走向“可执行系统”的关键接口。
面试官通常不是想听一个孤立定义，而是想看你能不能把概念、工程约束、质量风险和排查方法串起来。回答时先给边界，再讲机制，最后落到评估指标。
二、核心机制怎么工作
函数调用把开放文本生成约束成可解析的结构化动作。模型根据用户意图选择工具并填参数，编排器校验后执行，再把 observation 交回模型。这样可以让模型查询数据库、调用搜索、发起工单或计算结果，同时把危险动作关在明确边界内。
需要特别注意的是，这类问题通常有“模型侧”和“系统侧”两层含义。模型侧解释原理，系统侧解释为什么上线后会遇到成本、延迟、质量或安全问题。
三、带数字的拆解
用户问“查一下订单 A123 的物流”，模型应输出 get_shipping_status({"order_id":"A123"})，而不是编造物流状态。若 1000 次工具意图识别中 930 次选对工具、20 次参数缺失、50 次不该调用却调用，应该分别优化 schema 描述、澄清问题和调用阈值。
这个数字例子在面试里很有用，因为它能把抽象概念变成可估算的工程量。候选人如果能主动算出量级，通常比只背定义更有说服力。
工具成功率 = 成功完成工具链的请求数 / 需要工具的请求数
误调用率 = 不需要工具却调用的次数 / 不需要工具的请求数
一次工具调用 = tool_name + validated_arguments + execution_result四、流程图和工程落点
可以把它拆成下面这条链路来讲：
用户请求
|
模型判断是否需要工具
|
输出函数名和 JSON 参数
|
执行层鉴权与调用
|
工具结果返回上下文
|
模型生成最终答复工程落点通常包括三件事：第一是输入输出边界，第二是运行时成本，第三是质量验收。只要这三件事没有闭环，原理讲得再漂亮也很难变成可靠系统。
五、和相近方案怎么区分
| 方式 | 特点 | 适用场景 |
|---|---|---|
| 自然语言解析 | 灵活但不稳定 | 低风险原型 |
| 函数调用 | 结构化、可校验 | 生产级工具链 |
| 代码代理 | 可组合多步执行 | 数据分析、运维自动化 |
| 固定工作流 | 确定性强 | 合规和关键业务 |
面试时不要只说“看场景”。更好的回答是先给出区分维度，再说明每个方案为什么适合或不适合某类约束。
六、上线或训练时最容易踩的坑
- 不要让模型自己声明工具调用成功，成功与否应由执行层返回。
- 参数 schema 太宽会导致模型塞入模糊文本，太窄又会频繁澄清。
- 只在 demo 样本上验证会低估真实风险，尤其是长文本、多轮、结构化输出和安全边界。
- 指标要和业务目标绑定，否则可能出现离线分数提升、线上体验下降的情况。
七、常见误区与追问
- 误区：模型会调用工具就等于具备真实权限。 面试中要主动补上边界条件和工程后果，避免把概念讲成绝对结论。
- 误区：函数调用可以完全消除幻觉。 面试中要主动补上边界条件和工程后果，避免把概念讲成绝对结论。
- 误区：工具越多 agent 越强。 面试中要主动补上边界条件和工程后果，避免把概念讲成绝对结论。
- 追问：工具结果和用户输入冲突时应该相信谁？ 可以从数据、算法、系统和评测四个角度展开，先说判断标准，再说取舍。
- 追问：如何防止 prompt injection 诱导危险工具调用？ 可以从数据、算法、系统和评测四个角度展开，先说判断标准，再说取舍。
- 追问：什么时候应该让模型澄清而不是调用工具？ 可以从数据、算法、系统和评测四个角度展开，先说判断标准，再说取舍。
八、加强记忆
把工具调用记成“模型写工单，程序办工单”。模型负责判断和填表，执行层负责权限、真实世界动作和结果回传。
复习时建议按“定义、机制、数字、流程、对比、风险”六步默写一遍。能把这六步讲顺，就能覆盖大多数追问。