AI Agent全栈架构

主题

高频面试题

什么是 AI Agent 中的工具调用（Tool Calling）？它的基本流程是怎样的？

这道题是 Agent 工具体系的入口题。面试官想确认你真的跑通过完整链路，而不是只会说“让模型调 API”。尤其是“模型只决策、不执行”这个边界，很多人会答错。

适合阶段：Agent 入门 / AI 应用工程面核心能力：Tool Calling · 调用循环 · 决策与执行分离

本文边界：聚焦工具调用的概念边界和四步基本流程。三家厂商的 API 协议细节见 Function Calling 函数调用规范；工具 schema 怎么写见 Tool Schema 设计；MCP 标准化协议见 MCP 协议详解；失败与重试见 错误处理与重试。

面试官角度分析，想考什么 ​

  • 什么是工具调用？
    考你能否说清它让模型从“只会生成文本”变成能影响外部世界，而不是背定义。

  • 基本流程是怎样的？模型自己会执行吗？
    考链路和边界：工具定义怎么传、模型返回什么、谁来执行、结果怎么回去；模型只输出调用请求，执行永远在应用层。

  • 调完一次就结束了吗？风险在哪？
    考循环和工程意识：结果回传后可能再调下一个工具；越权、危险参数、死循环要靠权限校验和人工审批兜住。

可直接抄走的 30 秒参考答案 ​

text
工具调用是 Agent 和外部世界交互的核心机制，让模型从“只会回答”变成“能请求外部动作”。流程可以记成四步：先把工具名称、描述和参数 schema 发给模型；模型判断需要工具时，返回工具名和参数；应用层解析后真正去调 API、查库或读文件；最后把结果回传给模型，让它继续推理或给最终答案。最容易混淆的是：模型自己不执行操作，它只是提出调用请求，真正执行、鉴权、限流、审批和审计都在应用层。

面试回答详解，知其所以然 ​

先立边界：工具调用不是“让模型去执行操作”，而是让模型输出一份结构化的调用请求，执行交给应用层。理解了“决策与执行分离”，四步流程就顺了。

1. 工具调用解决什么问题 ​

LLM 本身有三个天然限制：训练数据有截止时间、无法访问你机器上的文件和数据库、不能主动触发外部动作。没有工具调用，模型对"今天苹果股价多少"这类问题只能编一个数字。

工具调用在"会说"和"会做"之间接上了一条标准通道：模型负责判断"现在需要什么信息、该做什么动作"，外部系统负责提供真实数据和真实执行。

2. 基本流程：四步一个循环 ​

text
① 工具定义随请求传给模型
      ↓
② 模型决策：输出结构化 JSON（工具名 + 参数）
      ↓
③ 应用层解析 JSON，真实执行（调 API / 查库 / 读文件）
      ↓
④ 执行结果回传给模型 → 继续推理 → 最终回答，或回到 ②

第一步：声明工具。 你把可用工具的名称、描述、参数 schema（通常是 JSON Schema）随请求一起发给模型。模型对工具的全部认知就来自这份声明，所以描述质量直接决定调用效果。

第二步：模型决策。 模型在对话过程中判断当前需要用某个工具，返回一段结构化输出，包含工具名和参数值。关键点：模型只是"说"要调什么，它自己没有任何执行能力。

第三步：应用层执行。 你的程序解析这段 JSON，路由到对应的处理函数，真实地调 API、跑 SQL、读文件。这一步的权限校验、超时、重试都在你的代码里做。

第四步：结果回传。 把工具执行结果作为一条消息拼回对话历史，再次请求模型。模型拿到真实数据后要么给出最终回答，要么判断信息还不够、再发起下一个工具调用——所以这是一个循环，不是单次动作。

举个例子：用户问"帮我查一下苹果公司今天的股价"。

text
用户提问 → 模型返回 get_stock_price(symbol="AAPL")
        → 应用层执行查询，拿到 178.25
        → 结果回传 → 模型回答"苹果公司今天股价是 178.25 美元"

模型全程没有碰过行情 API，它只是生成了调用请求，再基于执行结果组织回答。

3. 最容易答错的一点：模型决策，应用执行 ​

把这条边界记牢：

  • 模型侧（决策）：根据工具描述和上下文，选择工具、生成参数，输出结构化 JSON。本质仍是 token 生成，所以参数可能出错，需要校验。
  • 应用侧（执行）：解析请求、真实调用外部系统、处理异常和超时、校验权限、决定结果怎么回传。所有副作用都发生在这一层。

一个直接的推论：工具调用的安全性必须建在应用层。模型说"删掉这个文件"不等于文件被删了，删不删是你的执行代码说了算——所以参数校验、权限控制、高危操作人工确认，都加在第三步。

4. 三种技术实现路线 ​

  • 原生 Function Calling：API 层直接支持，请求传 tools 数组，响应带 tool_calls 字段。模型训练阶段做过针对性对齐，格式最稳定。OpenAI 2023 年 6 月最先推出，Anthropic、Google、Mistral 相继跟进。
  • Prompt 注入方式：在 Prompt 里告诉模型"你有这些工具，需要时按这个格式输出"。不依赖 API 支持，早期开源模型和 LangChain 的 ReAct Agent 都走这条路，但 JSON 格式不稳定，需要额外的解析容错和重试。
  • MCP 协议：Anthropic 2024 年底发布的标准化方案，解决的是工具怎么接入 Agent，而不是模型怎么输出调用。工具方实现一次 MCP Server，所有支持 MCP 的 Agent 框架都能直接用，复用性大幅提升。

三者的关系不是三选一：底层模型仍通过 Function Calling 的方式输出调用请求，MCP 是在工具注册和通信层面加的一层标准。

5. 工程要点：效果和风险都掌握在你手里 ​

  • 工具描述决定调用效果。 模型靠 description 判断什么时候用哪个工具。好的描述要写清"干什么、参数含义、什么场景用"，最好加上"不适合干什么"的负面约束，能显著减少误调用。工具数量从 10 个涨到 50 个，选择准确率会明显下降，需要分组或检索式路由。
  • 并行调用降低延迟。 现代模型支持一次返回多个 tool_calls，应用层并行执行后一起回传。"查北京和上海明天的天气"串行要两个来回，并行只要一个，复杂 Agent 场景能把延迟从十几秒压到几秒。详见 并行工具调用。
  • 权限和审计是底线。 模型能调工具意味着能影响真实世界。删除数据、支付转账这类高危操作要加人工审批；所有调用要有日志和 trace，方便事后定位是模型选错工具、参数错，还是工具本身失败。

面试官追问3个问题 ​

追问一：如果模型输出的工具调用参数格式不对，JSON 解析失败了怎么办？ ​

  • 考察点：有没有真实处理过模型输出的不稳定性。
  • 回答方向：分两层。第一层解析容错：用宽松的 JSON 解析器自动修复常见格式问题（多余逗号、缺引号），LangChain 的 OutputFixingParser 就是干这个的。第二层重试：彻底失败时把错误信息拼回 Prompt，告诉模型"上次输出格式有问题，正确格式是这样"，让它重新生成，一般重试 2-3 次能收敛。再补一句：用原生 Function Calling 而不是 Prompt 注入，出错概率本身就低很多，因为模型训练时练过这个格式。

追问二：工具输出特别长怎么办？比如搜索返回了几万字。 ​

  • 考察点：上下文管理意识和成本意识。
  • 回答方向：直接全塞进上下文既浪费 token 又会干扰模型判断。简单做法是应用层截断，只取前 N 个字符；更好的做法是先用快速模型做摘要、提取关键信息再回传。搜索场景通常在工具层就做预处理，只返回最相关片段和关键数据，不把原始大段文本丢给模型。

追问三：MCP 和 OpenAI 的 Function Calling 有什么本质区别？ ​

  • 考察点：能否分清"模型侧能力"和"工具侧标准"。
  • 回答方向：Function Calling 解决"模型怎么输出调用请求"，是模型侧能力；MCP 解决"工具怎么标准化接入 Agent"，是工具侧协议。类比：Function Calling 相当于手机支持蓝牙，MCP 相当于蓝牙协议标准。有了 MCP，一个工具实现一次就能被所有支持 MCP 的框架调用，不用对每家单独适配。两者不冲突，底层仍靠 Function Calling 输出，MCP 叠在上面做标准化。

基于 MIT 协议开源

Copyright © 2026 AI Agent全栈架构