AI Agent工具调用可靠性：从“会调用”到“能交付”

很多 Agent Demo 看起来很聪明：模型识别意图、选择工具、填入参数，然后给出结果。但真实业务里，日期可能错一天，金额可能多一个零，重试可能重复发信，超时也不代表动作一定没有执行。可靠性来自边界设计，不来自一句“请谨慎调用工具”。

1. 先说结论

工具定义应像后端 API 契约一样具体：输入字段、类型、枚举、权限范围、返回状态和失败原因都要明确。不要把“其他信息”留成一个让模型自由发挥的字符串。对日期、金额、用户 ID 和外部 URL 这类字段，服务端必须再次校验。

2. 问题背景

调用流程最好分成计划、预览、执行和确认四步。只读工具可以自动运行；低风险写入可以先生成变更预览；发送、发布、删除、付款等高风险动作需要明确授权。这样模型只负责提出计划，真正有副作用的动作由服务器控制。

3. 真正的技术取舍

超时和重试是最容易被忽略的地方。一次请求超时可能意味着第三方已经成功，也可能完全没有执行。正确做法是使用幂等键、查询状态接口和退避策略，而不是简单地再发一次。每个工具还要给出可观测的执行 ID。

4. 落地方法

测试集要覆盖缺字段、权限不足、空结果、重复请求、恶意指令、供应商不可用和部分成功。评估不能只看模型选对工具，还要看参数正确率、重复调用率、人工接管率、回滚成功率和最终任务完成率。

5. 常见失败

常见失败是把工具数量当成 Agent 能力，把十几个未经治理的 API 一次性暴露给模型。工具越多，选择空间和权限风险越大。第一版应从一个窄流程开始，等日志和失败样本稳定后，再逐个增加工具。

6. FDE判断

FDE认为，工具调用的终点不是返回一段 JSON，而是一次安全、可追踪、可恢复的业务动作。模型可以做判断和编排，但契约、权限、幂等、审计和回滚必须属于平台层。

发布或采购前的检查清单

• 所有写入工具必须有服务端 schema 和权限校验。
• 高风险动作必须预览、确认并可审计。
• 重试必须使用幂等键和状态查询。
• 用重复调用率和回滚成功率评估可靠性。

下一步怎么做

先把一个只读流程改造成“只读→草稿→确认执行”的闭环。

本文依据公开资料整理，来源包括：OpenAI function calling guide。文中“FDE判断”属于编辑分析，不等同于来源原话。