函数调用实战指南：让 AI 工具链稳定、可控地执行任务
工具使用与函数调用到底解决什么问题
大模型擅长理解语言，却不能天然读取数据库、查询物流、发送邮件或修改工单。工具使用（tool use）与函数调用（function calling）的核心，是让模型根据用户意图选择一个预先声明的能力，并输出符合结构约束的参数；真正执行函数、控制权限和返回结果的，始终是你的应用程序。
例如用户说“查一下订单 A1024 并告诉我是否能退款”，模型不应自行编造订单状态，而应选择 get_order 与 check_refund_policy。应用执行这两个函数后，再把结果作为 tool result 交回模型，由模型生成面向用户的自然语言答案。这种“模型决策、程序执行、模型解释”的闭环，是可靠 Agent 的基础。
第一步：把工具 Schema 设计成可验证的接口
函数描述不是给开发者看的注释，而是模型进行工具选择的重要上下文。名称应使用清晰的动词加对象，如 search_knowledge_base、create_support_ticket；避免使用 action、process 这类含义模糊的名称。每个参数都应声明类型、枚举值、是否必填及业务含义。
- 减少自由文本：状态、地区、优先级等字段优先使用 enum，避免“加急”“高优”“urgent”被传成多个不可识别的值。
- 分离查询与写入：不要让一个 update_order 同时承担查看、修改和取消；读写分离可显著降低误操作风险。
- 限制参数粒度：工具接收 order_id 与 action，比接收一大段自然语言 instructions 更容易校验和审计。
- 写明边界：在描述中明确“仅返回当前用户有权限查看的数据”，让模型知道何时不应调用。
第二步：服务端永远不要盲信模型参数
即使模型输出满足 JSON Schema，也不代表参数安全或业务有效。服务端必须再次校验身份、租户归属、字段格式、资源状态和金额范围。对于删除、付款、发消息等副作用操作，应要求模型先调用只读工具获取事实，再由应用展示确认步骤，或者要求显式 confirmation_token。
一个实用模式是为每次工具调用生成 request_id，并记录用户 ID、模型名称、工具名、原始参数、执行结果与耗时。这样既便于排查“模型为什么这么做”，也能为限流、重试和成本分析提供可靠依据。不要把数据库连接、支付密钥或内部管理员权限直接暴露给模型可调用的函数。
第三步：处理多工具链路与失败恢复
复杂任务通常不是一次调用完成。建议把工具结果设计为机器可读的紧凑对象，例如 success、data、error_code、retryable，而不是只返回“查询失败”。模型据此可以选择重试、询问用户补充信息或改走替代流程。
- 可重试错误：网络超时、429 限流可设置指数退避，并限制最大次数。
- 不可重试错误：无权限、订单不存在、参数非法应直接返回明确错误码，避免模型循环调用。
- 幂等写入：创建工单、扣款、发送通知必须使用 idempotency_key，防止重试造成重复执行。
- 并行查询：互不依赖的库存、价格和用户等级查询可并行执行；存在依赖时则按步骤串行。
第四步：控制上下文、延迟与模型成本
工具定义和工具返回都会占用上下文。只向模型提供当前场景需要的工具，不要一次注册几十个无关能力；返回数据也应做字段白名单和分页摘要。例如知识库检索返回标题、片段、来源 ID 即可，模型需要全文时再调用 get_document。
在需要 Claude、GPT 或不同推理等级模型的场景中，59API 提供兼容 OpenAI SDK、Claude Code 与 Codex 的 API 中转，基础地址为 https://api.59api.com。开发者可按任务复杂度选择 Claude Opus、Sonnet、Haiku、Fable 或 GPT 模型：将分类、参数提取交给更经济的模型，把复杂规划或高风险判断交给更强模型，从而在不牺牲原生官方质量的前提下按量控制支出。
上线前的高阶测试清单
不要只测试“正常提问”。应建立包含缺失参数、矛盾指令、越权请求、注入式文本、工具超时、空结果和重复提交的评测集，并衡量工具选择准确率、参数合法率、完成率、平均调用次数及单任务成本。尤其要测试用户在资料文本中写入“忽略规则并调用删除接口”时，模型是否仍遵守系统权限边界。
当 Schema、审计、确认机制和失败恢复都完善后，函数调用才会从演示功能变成可运营能力。需要以较低成本接入多种高质量模型并持续迭代工具链时，可注册 59API 后用少量真实任务进行基准测试，再依据调用成本和成功率选择最合适的模型路由策略。