跳至主要內容

Function Calling-如何保证可靠性

在生产级 Agent 系统中，大语言模型对工具的调用并非天然可靠。

模型可能因幻觉、参数误填、格式错误或逻辑跳跃，导致工具执行失败、系统崩溃，甚至引发安全风险。

为构建高可靠性的工具调用机制，需建立一套覆盖“定义—推理—执行—修复”全链路的工程化保障体系。该体系可分为四个层级，层层递进，形成闭环。

一、结构化定义层：以强约束奠定可靠性基础

工具调用的可靠性始于对函数接口的精确定义。模型仅能依据提供的函数描述生成参数，若定义模糊，输出必不稳定。

  • 强类型约束：使用 JSON Schema 明确定义每个工具的输入参数结构，包括：

    • 字段类型（string、integer、boolean 等）

    • 是否为必填项（required）

    • 枚举值范围（enum）

    • 字符串格式（如 date-time、email）

    • 数值范围（minimum、maximum）

    示例：机票预订工具中，departure_date 必须为 ISO 8601 格式的日期字符串，禁止使用“明天”“下周”等自然语言表达。

  • 语义描述优化：函数描述是模型理解意图的核心依据，应像优化 Prompt 一样精心设计：

    • 明确触发条件：“仅当用户明确提及‘改签’或‘变更日期’时，才调用 update_flight”
    • 区分相似功能：“若用户要求‘取消订单’且未提供订单号，则提示补充；若提供订单号但状态为‘已出发’，则拒绝调用 cancel_order”
    • 避免歧义：使用“必须”“禁止”“仅限”等确定性词汇，而非“可以”“建议”

核心原则：规矩立得越细，模型越难越界。定义层是所有后续层的基石。

二、推理策略层：引导模型进行结构化思考

在模型生成参数前，需引导其进行显式推理，避免“抢答式”错误。

  • 思维链（Chain-of-Thought, CoT）：在 Prompt 中强制要求模型在调用工具前输出 thought“思考” 字段，描述其决策逻辑：

    {
  "thought": "用户要求预订从北京到上海的机票，出发日期为明天。根据工具定义，出发日期需为 ISO 8601 格式。明天是 2026-06-27，符合格式要求。目的地为上海，符合可选城市列表。调用 book_flight 工具。",
  "function": "book_flight",
  "arguments": "{\"from\": \"北京\", \"to\": \"上海\", \"departure_date\": \"2026-06-27\"}"
}

  • Few-shot 示例引导：在提示词中提供 2–3 个正反示例，展示正确与错误的调用模式：

    • ✅ 正确示例：参数完整、格式正确、逻辑清晰
    • ❌ 错误示例：缺失必填字段、使用自然语言、调用错误工具

  • 工具检索（RAG）：当 Agent 拥有大量工具（>50）时，避免全量注入。采用语义检索：

    • 将用户查询编码为向量

    • 与工具描述向量库进行相似度匹配

    • 仅将 Top-K 最相关工具提交给模型

    效果：减少上下文噪声，提升工具选择准确率，降低模型认知负荷。

三、执行护栏层：在调用前实施自动化校验与安全拦截

模型输出的 JSON 不可直接执行，必须经过严格校验。

  • 自动校验：使用 Zod 等类型校验库，对模型输出的参数进行结构化验证：

    • 检查字段是否存在
    • 验证数据类型是否匹配
    • 校验枚举值是否合法
    • 验证格式约束（如邮箱、电话、日期）
    const { z } = require('zod');

const BookFlightArgs = z.object({
  from_city: z.string().min(1, "出发城市不能为空"),
  to_city: z.string().min(1, "目的城市不能为空"),
  departure_date: z.string().regex(/^\d{4}-\d{2}-\d{2}$/, "日期格式必须为 ISO 8601：YYYY-MM-DD")
});

function validateFlightArgs(argumentsStr) {
  try {
    const parsed = JSON.parse(argumentsStr);
    return BookFlightArgs.parse(parsed);
  } catch (error) {
    if (error instanceof z.ZodError) {
      throw new Error(`参数校验失败: ${error.errors.map(e => e.message).join('; ')}`);
    }
    throw new Error(`参数校验失败: 无效的 JSON 格式`);
  }
}

// 模拟模型输出
const modelOutput = {
  arguments: '{"from_city": "北京", "to_city": "上海", "departure_date": "2026-06-27"}'
};

try {
  const args = validateFlightArgs(modelOutput.arguments);
  console.log('校验通过:', args);
} catch (e) {
  console.error(e.message);
}

  • 高风险操作人机确认：对涉及资金、权限、数据删除等操作，强制引入人工审批：

    • 生成确认请求：“系统将执行转账 5000 元至账户 XXX，是否确认？”

    • 暂停执行，等待用户点击“确认”

    • 仅在用户响应后才调用真实 API

    安全原则：模型是执行者，不是决策者。关键操作必须由人类最终授权。

四、自愈修复层：构建闭环反思与自动重试机制

即使通过校验，工具执行仍可能失败（如 API 返回错误）。此时不应直接报错，而应启动修复流程。

  • 错误回传（Error Feedback）：

    • 工具执行失败时，将原始错误信息（如 API 返回的 {"error": "invalid_date_format", "details": "Expected YYYY-MM-DD, got '明天'"} ）原样返回给模型
    • 指令：“上一次调用失败，原因如下。请根据错误信息修正参数，重新生成调用请求。”
    • 效果：模型能精准定位错误点，二次生成成功率显著提升（实测可达 70% 以上）

  • 状态反思（State Reflection）：

    • 工具执行成功后，不立即返回结果，而是要求模型评估：

      • “返回的数据是否完整解决了用户原始问题？”
      • “是否存在未覆盖的上下文？”
      • “是否需要调用其他工具补充信息？”

    • 若模型判断未达成目标，则触发新一轮推理与调用

    闭环价值：系统具备“试错—学习—修正”能力，显著提升复杂任务完成率。

总结：可靠性公式

保证 Agent 工具调用可靠性的核心公式为：

可靠性 = （高质量定义 + 严格执行约束 ）× 闭环反思机制

  • 定义层：确保输入规范
  • 推理层：确保逻辑正确
  • 执行层：确保安全落地
  • 修复层：确保容错自愈

该四层架构并非理论模型，而是工业界验证的生产级实践。工程能力要有对模型弱点的预判与系统性兜底。

贡献者: guo