给模型接上工具的那一刻，你的系统里就多了一条隐形契约：模型承诺输出合法调用，工具承诺返回可理解的结果。生产环境里智能体最常见的故障，不是模型不够聪明，而是这条契约没谈清楚。

一、契约的三份文本

第一份是工具的 schema。名字、参数、描述都进了模型的上下文——描述写得含糊，模型就只能靠猜。经验法则是：描述要写成「给一个新同事的交接文档」，而不是「给自己看的备忘录」。把参数的单位、边界、副作用写进 schema，比在 system prompt 里堆一堆注意事项有效得多。

第二份是校验层。模型输出的参数在真正执行前必须过一遍 JSON Schema 校验，类型错了、必填缺了、取值越界了，直接拒掉并带着错误信息回炉重试。这一层属于工程侧，别指望模型「自觉」。

第三份是失败语义。工具返回错误时要给模型「可行动的错误」：404 附上可能的正确写法，超时说明是否值得重试。把堆栈直接甩给模型是最差的选择。

二、重试是门预算学

调用失败后重试，烧的是时间和 token。给每次工具调用设明确的预算：最多重试几次、单次超时多长、整条链路兜底多少秒。预算花完就升级给人处理，而不是让模型在错误里打转——智能体绕圈时消耗的 token 往往比正常路径多十倍。

另一个被低估的做法是幂等设计。写操作（下单、发消息、改数据）一定要带幂等键，否则模型因为超时而重试的那一次，就是你在生产环境里最不想看到的一次。

三、把调用当接口资产管

工具集本身要按接口资产管理：有版本、有变更记录、有测试。给每个工具写最小调用测试（真实模型、真实 schema），发版前跑一遍——模型升级后工具调用的成功率会漂移，这是比功能回归更容易被忽略的回归面。这也是之前聊 MCP 标准化 时提到的老问题：接口契约必须独立于模型存在。

小结

工具调用的可靠性 = 清晰的 schema + 工程侧校验 + 明确的失败语义 + 有预算的重试。这四件事都不贵，但每一件都在替你省「换个更大的模型」的钱。

说明：本文为公开资料的整理与评述，信息来源包括主流模型厂商的 Function Calling 文档与社区工程实践，数据以各官方原文为准。本文由 AI 辅助整理，不构成技术选型或投资建议。