Function CallingAgentJSON Schema容错设计后端工程

Function Calling 全链路：从 Schema 到容错

Function Calling 的难点不在“能否调用”，而在“调用是否可靠”。本文系统拆解参数约束、执行编排、重试回退、幂等与观测体系，给出可落地的生产级容错设计。

2026年3月4日

Synthly 团队

预计阅读 15 分钟

📷 Photo by Kelvin Valerio via Pexels

为什么“能调用”不等于“能上线”

很多团队第一次做 Function Calling 时会有错觉：

模型输出函数名；
参数是 JSON；
后端执行成功一次。

于是判断“这事成了”。

真实线上环境很快会打破这个幻觉：

参数字段偶发缺失；
工具接口慢或不稳定；
同一请求被重复触发；
某个重试策略引发连锁雪崩。

Function Calling 的核心不是“会不会调工具”，而是在不稳定世界里保持稳定结果。

一、Schema 设计：先把输入边界钉死

1）Schema 必须“可执行”，而不是“可读”

错误示例：

字段描述很详细，但没有枚举约束；
数值没有上下界；
可选字段太多，导致逻辑分支爆炸。

正确示例（简化）：

{
  "type": "object",
  "required": ["action", "priority", "items"],
  "properties": {
    "action": { "type": "string", "enum": ["create", "update", "close"] },
    "priority": { "type": "string", "enum": ["low", "medium", "high"] },
    "items": {
      "type": "array",
      "minItems": 1,
      "maxItems": 20,
      "items": {
        "type": "object",
        "required": ["id", "title"],
        "properties": {
          "id": { "type": "string", "minLength": 1, "maxLength": 64 },
          "title": { "type": "string", "minLength": 1, "maxLength": 200 }
        }
      }
    }
  },
  "additionalProperties": false
}

关键点：

枚举限制（减少歧义）
数值/长度边界（减少异常）
additionalProperties: false（防止脏字段）

2）Schema 版本化

Schema 不是一次性文件。必须有版本：

v1：基础字段
v1.1：新增可选字段
v2：破坏性变更

并提供兼容层，否则旧请求会在升级后突然失败。

二、执行编排：把“调用”变成“可控流程”

建议把执行链路拆为五步：

参数解析与校验
策略判定（是否允许执行）
工具执行
结果标准化
失败处理与记录

一个实战伪代码：

async function executeToolCall(input: unknown, context: ExecContext) {
  const parsed = validateWithSchema(input);
  const decision = policyCheck(parsed, context);
  if (!decision.allowed) return deny(decision.reason);

  const key = buildIdempotencyKey(parsed, context);
  const cached = await findExecutionResult(key);
  if (cached) return cached;

  try {
    const result = await withTimeout(callTool(parsed), 5000);
    const normalized = normalizeResult(result);
    await storeExecutionResult(key, normalized);
    return normalized;
  } catch (error) {
    return handleFailure(error, parsed, context);
  }
}