面向程序员 · AI 工程连接课

Function Calling / Tool Calling：让 AI 调用工具完成任务

大模型本身擅长理解和组织语言，但它不知道实时订单、不会真正写数据库，也不能天然执行审批流。Tool Calling 的作用，是让模型把“应该调用哪个能力、需要哪些参数”用结构化方式说出来，再由业务系统安全执行。

模型负责判断 识别用户意图，决定是否需要查系统、算结果或触发流程。

工具负责确定性能力 查订单、查库存、创建工单、计算价格，这些由后端服务完成。

系统负责执行和风控 校验参数、检查权限、记录日志，必要时要求人工确认。

答案必须基于结果 工具返回什么，模型才能解释什么，不能把调用失败包装成成功。

user asks tool_calls[]

用户问题 “帮我查一下订单 O-20260612 为什么还没发货。”

模型给出工具调用请求 get_order_status({ orderId: "O-20260612" })

业务系统执行工具 后端查订单、库存、物流、异常单，返回结构化结果。

模型组织最终回答 说明原因、给出下一步，但不编造系统没有返回的信息。

01 · 先抓主线

Tool Calling 解决的是“AI 怎么连接真实世界”

没有工具调用时，模型只能根据已有上下文回答。接入工具后，模型可以请求外部系统提供实时数据或执行确定性动作，但执行权仍然在应用系统手里。

实时数据

查现在发生了什么

订单状态、库存数量、账户余额、工单进度都属于外部实时数据，不能只靠模型记忆。

确定性计算

让系统算准确结果

优惠价、税费、汇总报表、风控分数需要规则和数据，不能让模型凭感觉算。

业务动作

触发系统流程

创建工单、发送通知、提交审批、生成发票都不是“回答”，而是要走系统流程。

安全边界

把执行权收回来

模型只输出调用意图和参数。系统检查后再执行，避免模型越权操作。

一句话面试版 可直接背

Function Calling 或 Tool Calling 是一种让模型调用外部能力的机制。模型负责理解用户意图并生成结构化调用请求，应用系统负责参数校验、权限判断、真实执行和结果回传，最后模型基于工具结果生成回答。

02 · 名词别绕晕

Function Calling 和 Tool Calling 说的是同一类能力

不同平台命名略有差别。面试时不必纠结术语细节，重点是讲清楚“模型产生结构化调用请求，应用系统执行工具”。

Function Calling

更像“调用一个函数”

常见表达是把函数名称、描述、参数 schema 提供给模型。模型需要工具时，输出函数名和参数，例如 getOrderStatus(orderId)。

Tool Calling

范围更宽

Tool 可以是函数、API、检索器、浏览器、代码执行器、工作流节点，也可以是一个封装好的内部服务。

可以这样理解 工程口径

1Function Calling 强调接口形式，像给模型一份函数说明书。
2Tool Calling 强调能力边界，工具背后可以是函数、服务、搜索、数据库查询或工作流。
3企业落地时，两者的核心工程问题类似：定义清楚、校验严格、执行可控、日志可查。

03 · 架构图

模型不直接执行工具，应用层才是执行者

这点很关键。模型返回的是“我要调用哪个工具以及参数是什么”，真正执行工具的是你的后端、Agent Runtime 或编排服务。

用户提出自然语言任务，例如“查订单、补发短信、生成售后工单”。

→

应用层 拼接上下文、提供可用工具列表、控制用户身份和权限。

模型判断是否需要工具，输出 tool name 和 arguments。

→

工具执行器 校验参数、调用内部 API、处理超时和异常。

业务系统 订单、库存、CRM、知识库、审批流、消息系统等真实服务。

→

最终回答 把工具结果回传给模型，模型基于结果解释、汇总、给建议。

为什么不能让模型直接执行 边界

模型会受提示词、上下文和用户输入影响。企业系统不能把数据库写入、付款、发邮件、删除数据这类动作交给模型自由决定。正确做法是让模型提出调用请求，系统按权限、策略和审批规则执行。

04 · 工具定义

一个好工具，要让模型“知道何时用、怎么填、返回什么”

工具定义不是随便写个函数名。描述太宽泛，模型会乱用；参数太松，执行器会收到脏数据；返回不稳定，最终回答就难控制。

工具定义的 6 个字段 必备

字段	作用
`name`	工具名称，短、稳定、语义明确。
`description`	告诉模型什么情况下应该使用这个工具。
`parameters`	参数结构、类型、必填项、枚举值和限制。
`returns`	返回结构，便于模型基于字段回答。
`policy`	权限、审批、幂等、限流、敏感信息规则。
`examples`	调用样例，帮助模型学会正确使用边界。

tool schema example JSON

{
  "name": "get_order_status",
  "description": "查询指定订单的支付、库存、发货和异常状态。只用于用户询问某个订单当前进度或未发货原因。",
  "parameters": {
    "type": "object",
    "required": ["orderId"],
    "properties": {
      "orderId": {
        "type": "string",
        "description": "订单号，例如 O-20260612-001"
      }
    }
  },
  "returns": {
    "orderId": "string",
    "status": "paid | pending_stock | shipped | cancelled",
    "reason": "string",
    "nextAction": "string"
  },
  "policy": {
    "readOnly": true,
    "requiresAuth": true,
    "maskFields": ["receiverPhone", "receiverAddress"]
  }
}

05 · 完整流程

一次工具调用，不是模型一句话就结束

要把 Tool Calling 看成一条链路。任何一步出错，都会影响最终答案，所以工程上要能定位每个环节。

1 识别意图 判断用户到底要问知识、查事实，还是执行动作。

2 选择工具 从可用工具列表中选择最匹配的一个或多个工具。

3 生成参数 把自然语言里的订单号、时间、对象等转成结构化参数。

4 执行工具 应用层校验后调用 API，处理权限、超时和异常。

5 基于结果回答 把工具返回结果交给模型，生成用户能理解的最终回答。

runtime pseudo flow 伪代码

userMessage = "查一下订单 O-20260612 为什么还没发货"

modelResponse = callModel({
  messages: [userMessage],
  tools: [get_order_status]
})

if modelResponse.hasToolCall:
  toolCall = modelResponse.toolCalls[0]
  args = validate(toolCall.arguments, get_order_status.schema)
  result = executeTool(toolCall.name, args, currentUser)

  finalAnswer = callModel({
    messages: [userMessage, toolCall, result],
    instruction: "只能基于工具返回结果回答，缺失信息要明确说明"
  })

  return finalAnswer

06 · 调用决策

不是所有问题都需要工具

工具调用有成本、有延迟、有风险。设计 Agent 时，要给模型明确边界，也要在应用层做兜底判断。

应该调用工具

1用户询问实时状态，例如订单、库存、余额、任务进度。
2需要确定性计算，例如报价、汇总、规则判断。
3需要执行业务动作，例如创建工单、发通知、提交审批。
4需要查企业私有数据，例如客户资料、内部知识库、配置表。

不应该直接调用工具

1用户只是问概念解释，模型已有足够上下文可以回答。
2用户身份不明确，工具会访问敏感数据或执行高风险动作。
3缺少必要参数，应该先追问，而不是猜一个参数去调用。
4工具描述不匹配，强行调用只会制造错误结果。

面试里可以补一句 加分点

我不会只依赖模型自己决定是否调用工具。高风险工具要在应用层加规则，比如白名单、用户角色校验、二次确认、幂等 key、频率限制和审计日志。

07 · 参数校验

模型填出来的参数，必须当成用户输入处理

不要因为参数是模型生成的，就认为它可信。模型可能漏字段、填错类型、混淆对象，也可能被用户提示诱导。

类型校验

字段类型要对

字符串、数字、数组、枚举、日期范围都要检查。日期不要让模型随便生成模糊值。

业务校验

参数要合理

订单号格式、用户是否拥有该订单、金额是否超过范围，都属于业务校验。

安全校验

防止越权和注入

不要把模型参数拼 SQL。要走安全的服务接口，并结合当前登录用户做权限判断。

缺必填参数时，先追问 用户说“查一下我的订单”，但没有订单号，也没有上下文能确定订单，就应该让模型追问。

参数来自上下文时，要标记来源 例如 orderId 是用户本轮输入、历史对话、页面上下文，还是系统选择。来源不同，可信度不同。

写操作要有二次确认 取消订单、退款、删除资料、发外部邮件这类动作，要先展示影响范围并等待用户确认。

08 · 结果处理

工具返回结果，也要设计成模型容易用、系统容易审计

很多 Tool Calling 失败，不是调用失败，而是返回结果太随意。模型拿到一大段混乱文本，就容易误读、漏读或编造。

好返回的特点 推荐

1字段稳定，名称明确，例如 status、reason、nextAction。
2包含可解释字段，不只给 code，也给业务含义。
3敏感字段默认脱敏，例如手机号、地址、证件号。
4失败要有错误码和可恢复建议，别只返回“error”。

tool result example JSON

{
  "success": true,
  "data": {
    "orderId": "O-20260612-001",
    "status": "pending_stock",
    "reason": "SKU-7788 当前缺货",
    "estimatedShipDate": "2026-06-14",
    "nextAction": "等待补货，或建议用户更换同价位可发货商品"
  },
  "traceId": "tool-7f3a91",
  "source": "order-service"
}

最终回答的边界 别编

如果工具只返回“缺货，预计 6 月 14 日发货”，最终回答就不能补一句“已经给仓库加急”。除非另一个工具明确返回了加急结果，否则这就是模型编造。

09 · 多工具编排

复杂任务通常不是一个工具能完成

企业场景经常要连续查、判断、再动作。多工具编排的难点不在“能调几个”，而在顺序、依赖、失败回滚和用户确认。

串行

上一步结果决定下一步

先查订单，再查库存，再判断是否能改地址。每一步都依赖前一步结果。

并行

互不依赖可同时查

同时查订单、物流、客服工单，最后合并结果，可以降低等待时间。

人工确认

高风险动作停一下

退款、取消、发通知前，先给用户看确认页，确认后再真正执行。

查订单 get_order_status(orderId) 返回订单状态和异常原因。

→

查库存 get_inventory(skuId) 返回可用库存和补货时间。

生成方案 模型基于订单和库存结果生成可选方案。

→

用户确认后执行 confirm_and_create_after_sale(orderId, action) 创建售后单。

10 · 权限和风控

企业系统里，Tool Calling 最大的坑是“能执行”带来的风险

一旦工具能写数据、发消息、扣款、改配置，风险就不再是回答错了，而是系统真的被错误操作。

权限

按当前用户判断

模型不能替用户提升权限。工具执行时必须带当前用户身份和租户信息。

审批

高风险动作要确认

退款、删除、对外发送、批量修改这类动作，必须有确认或审批环节。

幂等

防止重复执行

网络重试或模型重复调用时，不能重复扣款、重复发券、重复创建工单。

审计

每次调用可追踪

记录用户、会话、工具、参数摘要、结果、耗时和 traceId，便于排查。

tool execution guard 策略示例

beforeExecute(toolCall, currentUser):
  assert toolCall.name in enabledToolsFor(currentUser.role)
  assert validateSchema(toolCall.arguments)
  assert checkTenantScope(currentUser.tenantId, toolCall.arguments)

  if toolCall.name in highRiskTools:
    return requireUserConfirmation(toolCall)

  return executeWithAuditLog(toolCall, currentUser)

11 · 观测和评测

工具调用要能看见、能评测、能复盘

上线后不能只看“用户满意不满意”。要拆开看模型是否选对工具、参数是否正确、工具是否成功、最终回答是否忠实于结果。

01 工具选择准确率

该调用时有没有调用，不该调用时有没有乱调用，是否选对工具。

02 参数有效率

必填参数是否完整，类型和业务规则是否通过校验。

03 工具成功率

API 成功率、超时率、重试率、下游错误率都要单独看。

04 回答忠实度

最终回答是否只基于工具结果，有没有增加工具没有返回的结论。

排查顺序 Debug

1先看用户问题和可用工具列表，确认模型有没有足够信息做选择。
2再看模型输出的 tool name 和 arguments，确认选择和参数是否合理。
3接着看工具执行日志，确认权限、超时、下游服务是否正常。
4最后看最终回答，确认模型有没有忠实引用工具返回结果。

12 · 企业案例

用“查订单未发货原因”讲清 Tool Calling

这个案例适合面试，因为它同时包含实时数据、权限、工具返回、最终解释和后续动作。

用户输入 “订单 O-20260612-001 怎么还没发货？帮我看看是不是卡住了。”

模型判断 这是实时订单问题，普通回答不够，需要调用 get_order_status。

系统执行 校验用户是否有权查看该订单，再调用订单服务和库存服务。

最终回答 告诉用户订单已支付，但 SKU 缺货，预计 6 月 14 日发货，并给出可选处理方式。

case answer 工具结果驱动回答

工具返回：
{
  "status": "pending_stock",
  "reason": "SKU-7788 缺货",
  "estimatedShipDate": "2026-06-14",
  "availableActions": ["wait", "change_item", "create_ticket"]
}

最终回答：
这笔订单已经支付成功，目前没有发货是因为商品 SKU-7788 临时缺货。
系统预计 2026-06-14 补货后发出。
你可以继续等待，也可以选择更换同价位可发货商品。
如果需要人工跟进，我可以在你确认后创建售后工单。

这个案例的讲解重点 面试友好

模型没有自己猜未发货原因，而是选择工具查真实订单。系统没有把执行权交给模型，而是先校验权限再查。最终回答没有扩大工具结果，只把缺货、预计发货时间和可选动作解释给用户。

13 · 面试问答

回答要体现“理解模型，也理解工程落地”

面试官通常不是想听术语，而是看你是否知道怎么把 AI 接到企业系统里，并且能控制风险。

Q1：Function Calling / Tool Calling 是什么？

A：它是让模型调用外部能力的一种机制。模型根据用户问题决定是否需要工具，并输出结构化的工具名和参数。真正执行工具的是应用系统，应用系统会做参数校验、权限判断、调用后端服务，再把结果交回模型生成最终回答。

Q2：为什么企业 AI 应用需要 Tool Calling？

A：因为企业系统里很多问题需要实时数据和确定性动作。比如查订单、查库存、创建工单、计算报价，这些不能靠模型记忆或猜测。Tool Calling 可以让模型负责理解意图，让业务系统负责可靠执行。

Q3：如何设计一个工具？

A：我会先定义工具适用场景，再写清名称、描述、参数 schema、返回结构、错误码和权限策略。描述要告诉模型什么时候该用，参数要可校验，返回要结构化，高风险工具还要加确认、审批、幂等和审计。

Q4：Tool Calling 有哪些风险？

A：主要风险是工具选错、参数填错、权限越界、重复执行、下游失败和最终回答不忠实。解决方式是应用层做校验和风控，把写操作放到确认流程里，并记录完整调用日志，方便复盘。

Q5：RAG 和 Tool Calling 有什么关系？

A：RAG 更偏向查资料，让模型基于知识库回答；Tool Calling 更偏向调用能力，可以查实时系统或执行动作。实际项目里两者经常一起用，比如先用 RAG 查政策，再用工具查订单状态，最后合成回答。

14 · 练习和速查

把概念落到一个可以交付的工具设计说明

练习的目标不是写代码，而是能把一个工具讲清楚。面试里能讲出这份结构，就已经有工程落地感。

练习 1

设计“查会员积分”工具

写出 name、description、parameters、returns，并说明如何校验用户权限。

练习 2

列出 5 个高风险工具

例如退款、删除客户、发送短信、改价格、批量导出，并给出确认策略。

练习 3

做一张排查表

从用户问题、工具选择、参数、执行日志、最终回答五个环节定位错误。

一页速查卡 复习

1Tool Calling 的核心：模型提调用请求，系统负责真实执行。
2工具定义要清楚：名称、描述、参数、返回、策略、示例。
3模型参数不可信：必须做类型、业务、权限和安全校验。
4写操作要谨慎：确认、审批、幂等、限流、审计一个都不能少。
5评测要拆链路：工具选择、参数有效、执行成功、回答忠实。