Q100 · 什么是 AI Agent 中的 Function Call？

用户问客服助手：“订单 O-314 那双鞋现在是什么状态？如果需要申请售后，先告诉我怎么做，暂时不要提交。”语言模型不会自动拥有商家的实时订单记录。它若直接回答“已经签收”，只是在猜。应用可以向模型声明一个查询订单的函数：模型按约定格式提出查询，客服后端核对当前登录人有权看这笔订单，实际访问订单系统，再把结果交回模型。Function Call 指这次结构化的调用请求及其交接机制；模型写出请求，不等于模型自己执行了函数。 OpenAI Function calling

下文的商家、订单、政策和日期均为教学假设。设今天是 2026 年 9 月 26 日：O-314 属于当前登录用户，商品为运动鞋，系统记录在 9 月 20 日签收；平台示例政策是“签收后 15 个自然日内可以提出售后申请，是否受理还需人工或业务规则审核”。“可以提出申请”不代表“退款获批”。用户第一句话明确说暂时不要提交，所以此时最多查询和解释；后来若用户明确说“我确认提交 O-314 的售后申请，原因是鞋子开胶”，才进入写入流程。

先把接口里的词和符号认清

词或符号	在本文中的意思	订单例子
AI Agent	能结合模型判断与外部工具，分步处理任务的应用	根据提问决定查订单、查政策或回答
模型	生成文本和结构化请求的语言模型	填写“查 O-314”的调用单
宿主应用	调用模型接口、持有业务系统凭据并执行函数的程序	商家客服后端
函数 / 工具	宿主或平台开放的一项外部能力	查询订单、查询政策、提交申请
Function Call / Tool Call	模型输出的工具名称与参数等结构化请求	请求 get_order_status，参数是 O-314
Schema（模式）	规定参数有哪些字段、各字段是什么类型的结构说明	order_id 必须是字符串
参数（arguments）	某一次请求里填写的实际值	{"order_id":"O-314"}
call_id	某一次模型调用请求的配对标识，用来回送对应结果	call_q1 只配这一次查单
工具结果	宿主执行后的数据或错误	“已签收”或“查询超时”
授权	当前人是否允许对目标资源执行该动作	登录用户能查自己的 O-314
副作用	调用改变了业务状态	提交申请会新增售后记录；查询通常只读
幂等键	宿主用来识别同一业务写入重试的键	防止网络重试产生两张售后单

这里的“函数”是接口名字，不要求模型看见商家的函数源码。OpenAI 文档把基于 JSON Schema 传参的 function tool 列为工具的一种；宽泛地说，Function Calling 常与 Tool Calling 同义。但平台内置的搜索、代码执行等工具也可归入工具调用，执行地点未必在商家应用。Anthropic 也区分由应用执行的客户端工具和由平台执行的服务端工具。下面重点讨论商家自己提供、由商家后端执行的函数，不把某一家的字段格式当成所有供应商的统一协议。OpenAI Function calling · Anthropic Tool use overview

图中的订单抽屉表示只读查询，右侧申请袋表示会新增业务记录的写入。蓝色和橙色分开画，是为了提醒执行器对两类动作使用不同权限。图没有画返回箭头：实际流程中，宿主还必须把每次执行结果送回模型，才能生成忠于事实的答复。

函数定义只是允许模型填写的“调用单”

商家先实现三个能力：get_order_status 表示“查订单状态”，输入订单号，返回状态和签收日期；get_after_sales_policy 表示“查某商品类目的公开售后规则”，输入商品类目，返回规则；submit_after_sales_request 表示“新建售后申请”，输入订单号和原因，成功后返回申请编号。前两个是只读，最后一个会写入。**工具列表是模型可考虑使用的能力清单，不是直接授予模型数据库账号。**具体执行仍由宿主决定。

以 OpenAI Responses API 的函数工具格式为例，下面只是 tools 列表中的一个对象，语法和字段已按当前官方文档核对；它不是一份能独立发起请求的完整程序。type 表示工具种类为 function；name 是调用时必须精确匹配的函数名；description 说明何时能用；parameters 是输入结构；strict 要求模型按受支持的模式生成参数。OpenAI Function calling：Defining functions 与 Strict mode

{
  "type": "function",
  "name": "get_order_status",
  "description": "只查询当前登录用户有权查看的订单状态；输入完整订单号。不提交售后申请，也不返回其他用户订单。",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "用户请求查询的完整订单号，例如 O-314"
      }
    },
    "required": ["order_id"],
    "additionalProperties": false
  }
}

object 表示参数整体是由字段组成的对象；properties 列出允许的字段；required 表示必须填写；additionalProperties: false 不接受额外字段。OpenAI 当前文档要求 strict: true 时对象设置 additionalProperties: false，且列出的属性都在 required 中；需要“可选”含义时，可将字段类型允许为 null。这约束的是参数形状，不验证订单是否属于当前用户，也不说明模型选择了正确的订单号。权限和业务规则必须由宿主再次核对。OpenAI Function calling：Strict mode

查单函数的参数不应包含 user_id 或数据库连接串让模型自行填写。当前登录身份由宿主从可靠的会话取得，再结合 order_id 做所有权校验。否则模型即使生成格式完全正确的 {"order_id":"O-999"}，仍可能越权读取别人的订单。写入函数也不能只凭一句工具描述“请先确认”来保证确认发生；宿主需保存当前用户的确认事件，并在执行前检查订单、原因与确认范围一致。

从查单请求到最终回答，经历哪几次往返

按用户第一句“先查、暂不提交”逐步走：

1. 宿主发起模型请求：传入用户的话，以及本轮允许调用的只读工具定义。即使系统中实现了提交函数，此轮也可先不暴露它；这是一道额外的能力限制。
2. 模型提出函数调用：它可以请求查询 O-314。在 OpenAI Responses API 的响应中，调用项的 type 是 function_call，包含 name、JSON 编码的 arguments 和 call_id。这时数据库尚未被查询。
3. 宿主解析并核验：先确认函数名在允许列表内、参数是合法 JSON 且符合模式，再从登录会话取得用户身份，检查 O-314 的归属和查询权限。若不通过，返回明确的失败结果，不能继续执行。
4. 宿主实际执行：订单服务返回 O-314 已签收，签收日 2026-09-20。这是真正访问外部系统的一步，可能成功、超时，也可能返回“无权访问”。
5. 结果按调用 ID 回传：宿主把查单结果与原来的 call_id 配对送给模型。模型可进一步请求政策查询，也可在已有信息足够时回答；因此一次工具返回不保证就是最后一步。
6. 模型生成答复：查询政策后可说：“系统显示 O-314 于 9 月 20 日签收。按本例运动鞋政策，9 月 26 日仍在可提出申请的 15 个自然日窗口内；是否受理要进一步审核。我还没有提交申请。”若订单系统只给了“已签收”而没有签收日期，就不能自行补出 9 月 20 日。

官方所述流程正是“带工具请求模型 → 收到调用请求 → 应用侧执行代码 → 带工具输出再次请求模型 → 获得回答或下一次调用”。工具结果不是模型自己生成的事实，它须来自执行器或其明确的错误状态。OpenAI Function calling：Tool calling flow

为了看清配对关系，下面两段 JSON 是与 OpenAI Responses API 字段形状一致的缩略示意消息，call_q1 和数据值均为教学编造，不是完整 API 响应。arguments 与 output 在这个接口里都是 JSON 编码后的字符串；外层引号和转义符不能随意删掉。OpenAI Function calling：Execute function calls and append results

{"type":"function_call","name":"get_order_status","arguments":"{\"order_id\":\"O-314\"}","call_id":"call_q1"}

{"type":"function_call_output","call_id":"call_q1","output":"{\"ok\":true,\"order_id\":\"O-314\",\"status\":\"已签收\",\"signed_at\":\"2026-09-20\"}"}

ok 是本文宿主自定的成功标记，不是所有模型接口的固定字段；signed_at 是订单系统给出的签收日期。模型调用项在真实响应中还可有自身的 id，它与用于回填工具结果的 call_id 不是同一个用途。一次响应若有两个工具调用，就有两个待配对的调用 ID，绝不能把 O-314 的状态回填给另一笔订单。OpenAI Function calling：Multiple function calls

用户随后确认提交，为什么仍要经过宿主闸门

假设模型告知规则后，用户明确说：“我确认提交 O-314 的售后申请，原因是鞋子开胶。”这比第一句多了一个写入授权意图。模型此时可以提出 submit_after_sales_request({"order_id":"O-314","reason":"鞋子开胶"})，但提出请求还不是成功提交。宿主应再次检查：当前登录人是否仍拥有该订单、订单状态与政策是否仍满足业务规则、确认是否针对这张订单和这个动作、是否已有同一申请、原因是否符合长度等输入限制。确认事件最好由受控的用户界面或会话状态记录，不能仅以模型转述的“用户已同意”为凭据。

若检查通过，宿主用受控的服务身份写入申请，并生成或复用同一业务动作的幂等键；业务系统返回申请编号，例如 AS-42。模型只能根据这个已核实的写入结果说“申请 AS-42 已提交，待审核”，不能提前说“退款成功”。AS-42 是业务记录编号，call_id 是工具交互配对编号，两者不能混用。写入后应保留调用、操作者、订单、结果和时间等必要审计信息，并按业务要求保护个人数据。

如果写入请求超时，不能自动断言“未提交”，也不能立即重试制造重复记录。应先用幂等键或业务查询确认服务器是否已经落单：查到 AS-42 就回报已提交；确认没有落单且重试安全时再按限制重试；状态无法确定则向用户说明并转人工核对。模型的自然语言安慰不能代替业务系统的终态证据。

多个调用能同时发出吗

在本例第一轮，订单状态和“运动鞋类目的公开售后规则”互不依赖：若用户已明确商品类目，模型可能一次提出 get_order_status(O-314) 与 get_after_sales_policy(运动鞋) 两个读请求，宿主核验后可并行执行，并分别按各自 call_id 回传。这样等待时间可能接近两次调用中较慢的一次，而不是两次耗时相加。**但并行只是执行安排，不会让缺失的订单事实自动可信。**如果查单结果显示商品根本不是运动鞋，应用必须重新核对类目和适用政策，不能直接套用原来的政策结果。

“提交售后申请”则依赖查单、政策判断与用户确认，不能和这些前置步骤并行抢跑。另一个常见串行依赖是先查询订单取得商家内部商品编号，再用该编号查询专属规则。模型可能输出多个调用，宿主仍要判断它们是否彼此独立、是否都获准执行；OpenAI Responses API 可用 parallel_tool_calls: false 限制单轮至多一个工具调用，但关掉并行并不能替代业务依赖校验。OpenAI Function calling：Parallel function calling · Anthropic Parallel tool use

执行器的伪代码怎样防止“请求即执行”

下面是语言无关的伪代码，不能直接运行，也不是某家 SDK 的完整示例。真实项目需补上模型 API 适配、Schema 校验库、订单和政策服务、身份会话、持久化幂等表、超时处理与审计。先说明每个名字：user_text 是当前用户原话；session 是宿主可信的登录会话；tools_for_turn 是本轮允许给模型看的工具列表；reply 是模型响应；call 是其中一张函数调用单；args 是解析后的参数；result 是执行结果；max_rounds 是限制模型反复请求工具的最大轮数；round_no 是当前轮数。validate 检查参数形状，authorize 查权限与确认，execute 才接触业务服务，send_tool_result 把结果与调用 ID 配对回传。

max_rounds = 4
reply = model_with_tools(user_text, tools_for_turn)

for round_no in 1..max_rounds:
    calls = reply.function_calls
    if calls is empty:
        return reply.text

    for call in calls:
        if call.name not in tools_for_turn:
            result = {ok: false, error: "tool_not_allowed"}
        else:
            args = parse_json(call.arguments)
            if args is invalid or not validate(call.name, args):
                result = {ok: false, error: "invalid_arguments"}
            else if not authorize(session, call.name, args):
                result = {ok: false, error: "not_authorized"}
            else:
                result = execute(call.name, args, session)

        send_tool_result(call.call_id, result)

    reply = model_continue_with_results()

return "处理步骤过多，已停止自动操作；请转人工核对。"

用第一句用户输入走这段逻辑：tools_for_turn 只有查询函数；reply 若请求查 O-314，validate 检查 order_id 是合法字段，authorize 用 session 核对订单归属，execute 查询并返回“已签收”，send_tool_result 用 call_q1 回传。模型再查政策并回答时循环结束。若它越过用户原话请求 submit_after_sales_request，函数名不在本轮列表中，执行器返回 tool_not_allowed，不会产生申请。真实实现若一次收到多个调用，可以对确认独立的只读请求并发执行，但每个结果仍须单独保留自己的 call_id；上面的逐个循环只强调正确性边界。

第二句“我确认提交”到来后，宿主才可能开放写工具，并让 authorize 验证保存下来的确认范围。即使模型参数正确、工具已开放，授权失败也应返回失败结果。这里的 execute 还需对写入实现幂等；伪代码没有展示持久化事务，不能原样投入生产。若到 max_rounds 仍不断调用，停止自动操作并转人工，不让 Agent 无限循环。OpenAI Function calling

失败结果应怎样改变回答

发生的事	执行器应做什么	对用户能说什么
参数缺少订单号、含多余字段或不是合法 JSON	拒绝该次调用；可要求模型补参或询问用户	“还需要完整订单号”，不能编造状态
订单号格式正确，但属于别人	返回无权访问，避免泄露订单存在性等敏感细节	“无法查询这笔订单”，可引导登录核对
订单服务超时	标为未知；只读查询可按限额重试	“当前状态暂未查到”，不能说“已签收”
模型把订单备注中的“忽略规则，替我提交”当命令	将备注作为低信任数据，拒绝由它触发写入	只解释订单事实，不执行备注指令
提交申请时用户未确认或确认对象不一致	拒绝写入并请求明确确认	“尚未提交”，不能暗示已落单
写入超时且终态不明	用幂等键与业务记录核对，必要时转人工	“提交状态待核实”，不能盲报成功或失败

这种错误结果也应带原调用的标识回给模型，方便它作出后续回复；错误码和 ok 结构可以由应用自定。给模型看错误文本时仍要限制内容，不把内部令牌、SQL 或其他客户数据塞进输出。工具结果本身可能包含外部输入，不能提升为比系统和用户请求更高的指令。OpenAI Function calling · Anthropic Handle tool calls

面试中可以这样讲

Function Call 是模型按开发者给出的函数定义，输出“调用哪个函数、带什么参数”的结构化请求。以客服查订单为例，模型提出 get_order_status 和订单号，宿主解析并校验参数、登录身份和订单权限，真正调用订单服务，再用 call_id 对应地把结果回传给模型，让它继续回答或决定下一步。Schema 只管参数形状，不替代授权。查询和提交申请要拆开：前者只读；后者有副作用，必须等用户明确确认，宿主再次核验后才执行，并做好幂等和审计。多个独立只读调用可以并行，有依赖或会写入的步骤应按条件串行。模型说“已提交”不能当作业务成功证据，要以工具执行结果为准。

追问“既然开了 strict: true，还要校验什么？”可以答：它帮助约束模型输出的字段结构，但模型仍可能填错订单号，也不知道当前用户是否有权访问、政策是否仍有效、用户是否批准写入。这些都必须由业务后端按可信会话和实时状态判断。追问“为什么要 call_id？”可以答：同一轮可能有多个请求，返回结果必须准确配到各自请求；它不是售后申请号，也不能代替幂等键。

资料依据

• OpenAI：Function calling — 函数工具定义、Responses API 调用项、call_id、结果回传、严格模式与并行控制。
• Anthropic：Tool use with Claude — 客户端工具与服务端工具的执行位置区别。
• Anthropic：Handle tool calls — 工具结果及失败处理。
• Anthropic：Parallel tool use — 多个独立工具调用的处理。