工具调用实战：让模型真正调用你的业务接口
发布于 2026-10-01
工具调用实战：让模型真正调用你的业务接口
让模型"输出一段 JSON"只是演示，真正的生产用法是工具调用（Function Calling / Tool Use）：模型决定调用哪个函数、传什么参数，你的程序执行后再把结果回填给模型。这一步跨过去，AI 才能查库存、开工单、读数据库。
一、Schema 是给模型看的接口文档
工具描述的质量直接决定调用准确率。三个要点：
名字用动词短语：getorderstatus 比 order 清楚得多；
描述写清"何时用"：模型靠描述判断是否该调这个工具，写清触发场景与不适用场景；
参数逐个写说明：类型、是否必填、取值范围、单位（元还是分、秒还是毫秒）。
枚举值一定要用 enum 约束。让模型自由填写状态这类字段，等于把脏数据直接引进系统。
二、参数永远不可信
模型给的参数可能格式正确但语义错误：把"上海"填进手机号字段、把负数当金额。服务端必须做三层校验：类型与范围 → 业务规则 → 权限归属。
权限归属最容易被忽略：用户 A 让模型"查订单 12345"，你得先确认这笔订单属于 A。工具调用绕过了界面，但绝不能绕过鉴权。
三、幂等：模型可能重复调用
多轮对话里，模型因为没拿到预期结果而重试同一次调用非常常见。有副作用的工具（下单、退款、发消息）必须携带幂等键：
服务端先查这个键是否执行过，执行过就直接返回上次结果。这样即使模型重试十次，业务也只发生一次。
四、错误要"回填"，不要抛出
工具执行失败时，把异常直接抛给上层，模型只会反复重试同一个错误。正确做法是把错误整理成结构化结果回填：
带上 retryable，模型才能判断"换个参数重试"还是"告诉用户办不了"。
五、给循环设上限
模型调工具 → 拿到结果 → 再调工具，是个天然的循环。必须显式设上限：
单轮对话的最大工具调用次数；
单个工具的执行超时；
整个请求的总时长上限。
超过上限就返回当前已有结果并说明原因，避免一次请求无限消耗额度。
六、把工具调用记进日志
每次调用至少记录：工具名、参数摘要、耗时、成功与否、是否命中幂等、消耗的 token。线上排查"为什么模型没查到数据"时，这份日志是唯一线索。
工具调用是把模型接入业务系统的主干道。Schema 写清楚、参数当不可信处理、幂等兜底、错误可回填——这四件事做到，AI 功能才算真正可用。