大家好，我是浩哥，这是我输出AI agent面试专题第四章，后面还有六期。建议加入粉丝，后面粉丝可见。

导语：本题型考察工具调用的工程落地——LLM 网关治理、外部工具接入可靠性、Function Calling 的运行时机制与训练原理。这是 AI 应用开发岗的高频重灾区：很多人能熟练写 tool_calls 代码，却说不清网关解决什么横切问题、运行时谁决策谁执行、能力到底是"涌现"还是"训出来"的。面试核心在于把"会用"升级为"懂原理 + 知取舍"。

• 2026年最新AI agent面试（01）_Agent基础与推理范式
• 2026年最新AI agent面试（02）_MultiAgent与记忆
• 2026年最新AI agent面试（03）_工具协议MCP_A2A_FC
• 2026年最新AI agent面试（04）__工具工程网关外部
• 2026年最新AI agent面试（05）_RAG基础应用
• 2026年最新AI agent面试（06）_RAG文档与检索
• 2026年最新AI agent面试（07）_大模型架构基础
• 2026年最新AI agent面试（08）_大模型训练评测
• 2026年最新AI agent面试（09）_AI编程ClaudeCode
• 2026年最新AI agent面试（10）_通信与行业动态

总目录可见 2026年最新AI agent面试（0）概述篇

Q1. LLM 网关层到底解决了什么本质问题？为什么不能只用 Nginx/普通 API 网关？ ［来源：京东］

• 核心答案：LLM 网关是架在业务应用与各厂商模型 API 之间的中间层，对所有出入流量做集中拦截与治理。它的定位不是"反向代理 + 负载均衡"——这两件事 Nginx/Envoy 就能做——而是解决大模型场景特有的横切关注点（cross-cutting concerns）：多模型统一接入、密钥与配额集中管控、成本可观测、以及语义层面的缓存与安全防护。没有网关时，每家厂商的 SDK、鉴权方式、参数格式差异会渗透进每个业务服务，导致密钥散落、重复造轮子（重试/限流各写各的）、成本黑箱、换模型/改配额都要动业务代码等一连串痛点；网关用"一个地方统一管"把这些痛点系统性消解。

• 核心答案（架构级表述）：从架构视角看，网关把"应用 -> N 个模型 API"的网状直连，收敛成"应用 -> 网关 -> 模型"的星型拓扑。业务代码只认识网关（通常暴露 OpenAI 兼容接口），底层换模型、做 A/B 测试、切成本敏感模型对业务层完全隐形，只需改网关路由配置。这正是它区别于普通网关的本质：它天然理解 token 这一 LLM 核心计量单位，能围绕 token 做配额、计费、缓存与审计，而普通 API 网关只理解 HTTP 请求，不理解语义与 token 经济。

• 关键点 / 展开：

  1. 多模型统一接口（路由透明化）：网关暴露统一 OpenAI 兼容协议，业务代码零改动即可在 GPT-4o / Claude / 国产模型间切换，支撑 A/B 测试、成本优化、模型迭代与灰度。
  2. API Key 集中管理（鉴权）：真实密钥只存网关一处，业务侧拿网关分配的虚拟 Key，杜绝密钥散落在各服务配置文件/本地机器导致的泄漏事故（如离职员工遗留 Key 被扫、一夜烧掉数千美元账单）。
  3. 限流与配额（配额隔离）：按团队虚拟 Key 设置独立 token 日预算（如研发 100 万、产品 50 万），某团队超额即返回 429，避免单点脚本死循环吃光全公司额度、误伤其他业务。
  4. 成本追踪与可观测性（计费/审计）：集中记录每次调用的 token 用量、响应时间、错误率，天然对接 Langfuse/Prometheus，回答"哪个接口最烧钱、各团队用了多少、P95 延迟多少"，让成本优化有依据。
  5. Prompt 安全过滤：网关层统一做 prompt 注入检测、个人隐私信息（身份证/手机号）脱敏、内容安全审核，安全策略一处更新、所有接入点自动获得保护，杜绝"某服务漏了检测"。
  6. 语义缓存（LLM 网关亮点能力）：用 embedding 把问题转成向量，在向量库做相似度检索（阈值通常 0.85–0.95），命中即跳过模型直接返回历史答案，省 token 又降延迟；需配合 TTL（实时数据如天气/股价几分钟、FAQ 数天）与强实时/个性化请求绕行策略。
  7. 负载均衡与故障转移（可靠性兜底）：给同一模型名配置主备路由（OpenAI 主、Azure/Anthropic 备），主路由连续失败达阈值自动切换，业务层无感知，是生产多活保障手段。

• 常见追问：

  1. “语义缓存和普通 HTTP 缓存区别在哪？相似度阈值怎么调？” —— 精确匹配 vs 向量近似匹配；阈值过高缓存形同虚设、过低会答非所问，需按场景调参与配 TTL。
  2. “如果自研 LLM 网关，你会优先实现哪几个模块？” —— 鉴权/密钥管理、配额限流、成本计量、统一路由四件是地基，语义缓存与安全过滤是增值，先保可用与可控再谈优化。

• 2026 延伸：可选框架生态——LiteLLM（开源 Python，100+ 模型，社区最活跃，需关注安全公告与版本锁定）、One API（Go，国产模型支持好、部署简单）、Bifrost（Rust，2026 新兴高性能低延迟）、PortKey（商业+开源托管）、Kong AI Gateway（基于 Kong 扩展）。来源名：LLM 网关框架选型实践。

Q2. 什么是 Function Calling？运行时原理与流程是怎样的？为什么说"大模型自己不会去调 API"？ ［来源：字节］

• 核心答案：Function Calling 是一套"模型决策、代码执行"的结构化工具调用机制：开发者用 JSON schema 描述工具（名称、用途、参数），连同用户问题一起传给模型；模型若判断需要工具，则不直接输出自然语言，而是输出结构化的 tool_calls JSON（要调哪个函数、参数是什么）；宿主代码解析并执行真实函数，把结果以 role: "tool" 消息塞回对话，模型再生成最终答案。它把"靠解析自然语言判断意图"的脆弱做法，固定成可解析、可标准化的协议（OpenAI 2023 年推出，Claude/Gemini/Qwen 等均已支持）。

• 核心答案（架构级表述）：运行时本质是"两轮对话 + 中间执行"的闭环，关键认知是模型只负责决策、不负责执行——LLM 没有访问网络/文件系统的权限，它只输出"我要调这个工具、参数是这个"的指令，真正跑函数、查库、访问网络的是宿主程序。这种分工让工具调用既灵活又安全：宿主侧可做权限控制、参数校验、执行沙箱等防护。面试中"它自己去调 API"这类回答会被冷笑，因为混淆了决策与执行边界。

• 关键点 / 展开：

  1. 三个角色分工：开发者是"HR"写 schema（工具说明书）；模型是"经理"读完说明书决定调哪个、参数填什么；宿主代码是"员工"真正执行并把结果汇报回来。模型全程只下指令。
  2. Schema 设计是准确率命门：description 字段是模型判断"要不要调、怎么填参"的唯一依据，写得越清晰准确（含格式、示例、限制条件）选择越准，例如"查询指定城市的实时天气，含气温/天气状况/风向风速，仅支持中国大陆城市"远胜"获取天气"。
  3. 完整闭环：① 传入 tools + 用户问题 → ② 模型若 finish_reason == "tool_calls" 则输出结构化调用请求（明确信号"我需要工具、还没答案"）→ ③ 宿主代码解析参数执行函数 → ④ 结果以 tool_call_id 对应的 role: "tool" 消息回填，再次调模型得最终答案。
  4. tool_choice 控制策略：auto（模型自判要不要调）、required（强制调）、或指定具体函数，按场景约束模型行为。
  5. 并行工具调用：tool_calls 是列表，一次可返回多个调用（如"查北京和上海天气"），宿主并行执行后一次性回填，避免串行等待、显著降低总耗时。
  6. 外部工具可靠性设计（工程要点）：宿主侧必须做参数校验（防止模型填错类型/越界）、超时与重试（指数退避处理 429/503）、执行沙箱与权限收敛、工具失败兜底（调用失败如何告知模型让其换路或直答）、以及结果截断（超长返回需裁剪避免撑爆上下文）。

• 常见追问：

  1. “模型输出的参数不可信怎么办？怎么保证工具调用安全？” —— schema 层约束 + 宿主层强校验 + 沙箱执行 + 工具白名单，绝不把模型输出直接当成系统命令执行。
  2. “工具调用失败 / 超时，模型不知道怎么办，怎么设计？” —— 把失败原因作为 tool 消息回填让模型自我纠正，或降级到直接回答/兜底话术，避免无限重试循环。

• 2026 延伸：来源名——Agent 工具可靠性实践（参数校验、重试退避、执行沙箱、失败自愈是当前多 Agent 落地的标配工程）。注意 Function Calling 是运行时的具体实现形式，与 MCP（工具接入协议）、Agent Skill 等是不同层次概念，易在追问中被交叉考察。

Q3. 大模型到底是怎么"学会"调用外部工具的？SFT 和 RLHF 各自起什么作用？ ［来源：美团 / 腾讯］

• 核心答案：工具调用能力不是"参数够大就涌现出来"的——预训练完全在文本空间做 next-token 预测，从未见过"输出可解析 JSON 调用请求"这种模式，没训练的模型遇到"查天气"只会说"我需要调天气 API"而非产出 JSON。它是后天分两阶段"教"出来的：SFT 教会"怎么调"（模仿示范学会识别工具、判断要调、输出规范 JSON），RLHF 教会"什么时候该调"（用人类偏好反馈塑造边界感，避免简单问题也去调工具）。运行时的 Function Calling 只是这套能力被调用时的具体表现。

• 核心答案（架构级表述）：SFT 解决"会不会"——喂几十万到上百万条完整调用示范（System 工具说明书 + User 提问 + Assistant 结构化 JSON 调用请求 + Tool 结果 + Assistant 最终回答），让模型学会整套流程。但 SFT 样本里"该调"占绝大多数，模型会过拟合"积极调用"，对"1+1 等于几"也去查手册，边界感弱。RLHF 解决"该不该"——生成多样回答（调/不调/填错参）让人类打分，训练奖励模型（会打分的裁判），再用强化学习优化主模型，让它学会"能直接答就不调工具、需实时数据/执行操作才调"。RLAIF 用 AI 反馈替代人工打分，成本低、业界常用。

• 关键点 / 展开：

  1. 破除误区：涌现 ≠ 工具调用：涌现（量变引起质变）指理解与推理能力提升，但"输出可解析结构化 JSON"是预训练语料里不存在的模式，必须专项训练，两者不能混淆。
  2. SFT 训练样本构造：一条样本包含 System（工具定义）、User（提问）、Assistant（关键的正确答案=结构化 JSON 调用请求）、Tool（模拟执行结果）、Assistant（最终自然语言回答）五段式，让模型学"识别定义→判断要调→规范输出"。
  3. 数据来源：人工标注（成本高、质量好，做种子数据）+ 强模型（如 GPT-4）批量生成再人工抽查（成本低、量大，业界主流）。
  4. SFT 的短板：只会动作、不懂边界，简单问题也尝试调工具、工具失败不会处理——因为训练信号只告诉"这是正确答案"，没告诉"不调也是一种正确"。
  5. RLHF 四步法：①生成多种回答覆盖各种情况 → ②人类标注员评判哪种更合理（记录偏好）→ ③训练奖励模型（从人类偏好中"蒸馏"出打分标准，标注员水平不稳则奖励模型方向会歪）→ ④强化学习优化主模型，使其倾向高分（边界感准确）行为。
  6. 运行时复用：上线后每次调用仍是"传 schema+问题 → 模型输出 tool_calls → 代码执行 → 结果回填 → 模型作答"的 Function Calling 闭环，与训练两阶段解耦，可独立迭代模型与工具。

• 常见追问：

  1. “奖励模型如果打分标准歪了会怎样？怎么保证 RLHF 方向正确？” —— 主模型会被带偏，所以标注员一致性、奖励模型校验、以及 RLHF 与 SFT 的配比都很关键；可辅以 RLAIF 与规则约束兜底。
  2. “不用 RLHF，只靠 SFT + 拒识样本（显式构造’不该调’的反例）行不行？” —— 可以部分缓解（在 SFT 数据里加"直接回答"的样本建立初版边界感），但精细的边界权衡仍靠反馈信号，RLHF/RLAIF 难以完全替代。

• 2026 延伸：来源名——Function Calling 训练范式（SFT 教格式与流程、RLHF/RLAIF 教边界与拒识，是当前主流闭源/开源模型工具调用能力的标准训练路径）。

📌 本题型速记 Checklist

• 网关定位：星型拓扑中间层，统一治理所有模型出入流量；区别于 Nginx 的本质是理解 token 经济。
• 网关七职责（鉴权/限流/计费/审计/路由 + 安全 + 语义缓存）：密钥集中、配额隔离、成本可观测、Prompt 过滤、语义缓存、故障转移。
• 语义缓存 = embedding 向量近似匹配（阈值 0.85–0.95）+ TTL 配实时性，是 LLM 网关区别于普通网关的亮点。
• Function Calling 铁律：模型只决策、代码才执行；运行时是"两轮对话 + 中间执行"闭环。
• Schema 的 description 是模型判断准确率命门，参数说明要写清格式/示例/限制。
• 外部工具可靠性：宿主侧必须做参数校验、超时重试（指数退避）、执行沙箱、失败自愈、结果截断。
• 训练两大阶段：SFT 教"怎么调"（会动作）、RLHF 教"该不该调"（边界感），缺一不可。
• 涌现是语言/推理能力，≠ 工具调用能力；结构化 JSON 输出必须专项训练。
• RLHF 四步：多样生成 → 人类打分 → 训奖励模型 → 强化学习优化；标注员不稳则奖励模型方向会歪。
• RLAIF 用 AI 反馈替代人工，是 RLHF 低成本变体，业界常用；可与拒识样本配合建立初版边界感。