如何保证模型提供正确参数并可靠地调用工具？

核心回答

可靠的工具调用需要覆盖工具定义、参数检查、业务校验、执行结果反馈。模型输出一个符合 JSON 格式的调用，并不代表参数在业务上正确，也不代表工具已经执行成功。

以客户端工具为例，模型通常提出工具名称和参数，由应用执行工具，再把结果返回给模型。Claude 的工具调用文档展示了这一往返过程。

先把工具接口定义清楚

工具描述应说明用途、适用条件和参数含义。必填项、类型和枚举值应放进结构化约束，而不是只写在提示词里。下面是订单查询工具的输入约束示例：

{
  "type": "object",
  "properties": {
    "order_id": {
      "type": "string",
      "description": "用户提供的订单编号；信息缺失时先询问"
    }
  },
  "required": ["order_id"],
  "additionalProperties": false
}

上面只列出了输入 Schema，调用模型时还需按所用 API 的格式封装。MCP 中的工具也通过 inputSchema 描述输入，但应用仍需处理模型接口与工具执行之间的衔接。MCP 架构与工具发现

参数合法之后，还要检查业务条件

对于上面的订单工具，可以按以下顺序处理：

1. 检查结构。 order_id 是否存在、类型是否正确，是否包含不接受的额外字段。
2. 检查身份与权限。 当前用户是否能访问该订单。用户身份应来自可信的登录上下文，不让模型自行声明用户身份。
3. 检查业务状态。 查询结果是否有效；涉及修改时，当前状态是否允许该动作。
4. 执行并返回明确结果。 成功时返回真实数据，失败时返回可区分的原因。

即使模型使用了正确的字段名，也可能选错订单，因此业务校验不能省略。

失败后如何继续

• 缺少订单编号：向用户补问，不由模型猜一个编号。
• 参数格式有误：返回具体字段错误，允许有限次数的修正。
• 暂时性网络故障：按工具的重试策略处理，并设置超时和次数上限。
• 无权限或业务条件不满足：返回明确失败原因，不能把它当成网络故障反复重试。

对修改类工具，还需要考虑幂等性。例如一次状态更新超时后，先确认执行结果，再决定是否重试，避免同一动作被执行多次。

回答示例

例如：“我们不会只依赖模型生成参数。工具层检查 Schema，业务层校验权限和状态，执行层处理超时及幂等，最后把实际结果反馈给模型。调用成功必须以执行结果为准。”

参考资料

• Claude：Tool use overview
• MCP：Architecture overview

资料核对：2026-09-10。订单工具为示例。