← Retour aux guides

GPT 与 Claude 工具调用排障：从参数校验到结果回传

先分清：模型请求调用，不等于工具已经执行

接入函数调用时，最常见的误解是：把函数定义交给模型，它就会直接查询数据库或创建订单。实际上，GPT 和 Claude 通常只生成工具名称与参数；你的程序负责校验、执行，再把结果交还模型。完整链路是声明工具→识别调用→校验参数→执行工具→回传结果→继续生成。

调试时先使用无副作用的工具，例如查询订单状态。确认闭环正常后，再接入退款、发送邮件等操作，避免一次协议错误演变成真实业务事故。

第一步：确认地址、模型与协议

59API 的服务地址是 https://api.59api.com，支持按量付费接入 GPT 与 Claude，并兼容 OpenAI SDK、Claude Code 和 Codex。配置前，应核对平台文档中的完整接口路径、模型标识和工具调用支持情况；SDK 的 base_url 是否需要包含 /v1，也以对应接入说明为准，避免路径重复。

SDK 兼容不代表所有接口的消息结构相同。下面分别说明 OpenAI 聊天补全接口与 Claude 原生消息接口。若通过兼容接口使用 Claude，应遵循该接口的格式，不要仅凭模型名称切换协议。

第二步：用最小工具定义验证参数

以查询订单为例，工具命名为 get_order_status，参数结构可写为 {"type":"object","properties":{"order_id":{"type":"string","description":"订单编号"}},"required":["order_id"],"additionalProperties":false}。这能明确输入边界，但服务端仍须验证订单编号格式和当前用户的访问权限。

• GPT 聊天补全接口：在 tools 中添加 type 为 function 的对象，把 name、description、parameters 放入 function。
• Claude 原生消息接口：在 tools 中填写 name、description、input_schema，其中 input_schema 使用上述参数结构。
• 工具描述要说明何时调用、参数含义和限制；不要把密钥或内部凭据写进描述。

第三步：按各自协议回传结果

GPT：检查返回消息中的 tool_calls，保存完整的助手消息。逐项读取 function.name，并对字符串形式的 function.arguments 做 JSON 解析和业务校验。执行后追加 role 为 tool 的消息，将 tool_call_id 对应到原调用 id，content 填入字符串形式的执行结果，再次请求模型。

Claude：从响应内容块中读取 tool_use，保存原助手内容。执行工具后，追加用户消息，其 content 包含 tool_result 块；用 tool_use_id 对应原调用 id，并在 content 中提供结果。执行失败可在结果块中设置 is_error 为 true。不要把 GPT 的 role: tool 直接套进 Claude 原生接口。

常见问题：为什么没有调用工具？

先看原始响应，而不是聊天界面的文字。模型可能认为现有信息足够，或认为工具描述与任务无关。先明确要求“查询订单 A123 的当前状态”，并使用该接口支持的 tool_choice 选项测试强制调用。若仍无调用，再排查模型支持、字段位置与参数结构；强制调用适合诊断，不必默认用于所有请求。

常见问题：参数损坏、结果被忽略怎么办？

• 参数解析失败：流式响应中的参数可能分多段到达，应按调用标识或索引聚合，结束后再解析，不能逐片当作完整 JSON。
• 工具结果被忽略：检查是否漏存原助手调用消息、调用标识是否匹配，以及回传后是否再次请求模型。
• 多个调用只处理一个：遍历全部调用，并逐一返回对应结果；存在依赖或写操作时，不要盲目并行。
• 重复执行：设置最大调用轮数、超时和重试上限。付款、退款等写操作必须使用幂等机制，并按风险要求人工确认。

怎样降低调试成本并保障安全？

日志至少记录请求标识、模型、工具名、脱敏参数、耗时和错误类别。工具超时应返回明确错误，而不是伪造成功。工具输出也属于不可信输入，不能因为返回文本要求“忽略规则”就扩大权限。

59API 提供价格较低的按量付费方案，使用原生官方品质模型、不降级，适合反复验证调用闭环；其推荐返利机制也可作为成本补充。实际开销还取决于模型、上下文长度和调用轮数，工具结果应只返回必要字段。若准备搭建测试环境，可以注册 59API，先用少量预算跑通一次查询，再比较不同模型的成功率与总费用。

Tarifs · Docs