
> AI 测试开发面试高频题："Function Calling / Tool Use 怎么测？"
> 工具调用是 Agent 的手脚，也是事故重灾区：模型会编造不存在的参数值，而下游 API 不会惯着它。这篇讲怎么在中间加一道契约防线。

## 一、真实场景：一个不存在的枚举值，烧掉一晚上 token

某物流公司的客服 Agent 上线了工具调用能力：用户问订单，Agent 自动调 `query_order` 查状态，符合条件再调 `create_refund` 发起退款。真实 API 的退款接口要求 `status` 字段必须是枚举值：`pending | shipped | delivered`。

某天晚上，用户问"我的订单三天没动了，帮我退款"。Agent 判断订单卡在 `shipped` 状态，发起退款调用——但它传的参数是 `"status": "shipped_today"`。一个它自己发明的枚举值。

API 返回 400。接下来发生的事才是真正的损失：错误信息被原样塞回给模型（"Bad Request"），模型看不懂哪里错了，换了个姿势再试：`"status": "已发货"`、`"status": "in_transit"`……每一次都是编的，每一次都是 400。重试逻辑没有上限，这个死循环跑了四十多分钟，直到值班同学发现 token 消耗曲线异常才手动掐掉。一次本该 3 秒完成的退款请求，烧掉了平时一整天的调用预算。

复盘发现两个叠加的坑：一是工具描述是写在 prompt 里的一段自然语言（"status 是订单状态"），没有严格 schema，模型只能猜；二是重试逻辑只判断"调用失败就重试"，不看失败原因，也不限制次数。

## 二、思路：工具调用就是接口调用，先立契约再放行

传统接口测试里，参数合法性靠 schema 校验。Function Calling 也一样——**模型生成的每次工具调用，都必须先过一道契约校验，合法才放行到真实 API，不合法就把结构化的错误喂回给模型让它自我纠正。** 这道关卡叫工具网关。

## 三、核心代码：工具网关校验 + Mock 契约测试

### 第 1 步：用 Pydantic 定义工具契约，网关统一拦截

```python
from enum import Enum
from pydantic import BaseModel, ValidationError

class OrderStatus(str, Enum):
    pending = "pending"
    shipped = "shipped"
    delivered = "delivered"

class RefundParams(BaseModel):
    order_id: str
    status: OrderStatus          # 枚举写死，模型编的值在这里就被拦住
    reason: str

TOOL_MODELS = {"create_refund": RefundParams}

def tool_gateway(name: str, raw_args: dict):
    """所有工具调用的唯一入口：先校验，再转发；非法参数不进真实 API"""
    try:
        params = TOOL_MODELS[name](**raw_args)
    except ValidationError as e:
        # 关键：把"哪里错了"结构化地告诉模型，给它自我纠正的机会
        return {"error": "invalid_params",
                "detail": [{"field": x["loc"][0], "msg": x["msg"]} for x in e.errors()]}
    return call_real_api(name, params.model_dump())
```

注意 `detail` 的设计：不是丢一句 "Bad Request"，而是明确告诉模型"status 字段取值必须是 pending/shipped/delivered 之一"。同样一次 400，喂回错误信息的质量决定了模型是"改对"还是"继续编"。

### 第 2 步：契约测试——Mock 掉真实 API，断言模型"开出的调用单"

测 Function Calling，核心不是测 API 返回什么，而是测**模型决定调用什么、传了什么**。用 Mock 工具层拦截并记录：

```python
def test_refund_call_contract():
    """用户要求退款，Agent 发起的工具调用必须参数合法、一次到位"""
    calls = []
    with mock_tool_server(record=calls):        # Mock 层拦截，不打真实 API
        agent.run("订单 A1002 三天没物流更新了，帮我退款")

    refund_calls = [c for c in calls if c["name"] == "create_refund"]
    assert len(refund_calls) == 1, f"期望调用 1 次，实际 {len(refund_calls)} 次"

    name, args = refund_calls[0]["name"], refund_calls[0]["args"]
    RefundParams(**args)      # 参数非法直接抛 ValidationError，用例失败
    assert args["order_id"] == "A1002"
```

### 第 3 步：异常分支覆盖——工具返回错误时，模型该怎么办

故障的第二个坑就在这里。把工具的错误返回也纳入测试：

```python
def test_tool_error_recovery():
    """工具返回 invalid_params 后，模型应修正参数重试，且总次数不超过 3"""
    calls = []
    with mock_tool_server(record=calls,
                          fail_first=1,                      # 第 1 次调用故意返回参数错误
                          fail_response={"error": "invalid_params",
                                         "detail": [{"field": "status",
                                                     "msg": "取值须为 pending/shipped/delivered"}]}):
        agent.run("订单 A1002 帮我退款")

    assert len(calls) <= 3, "重试未收敛，存在死循环风险"
    assert calls[-1]["args"]["status"] in {"pending", "shipped", "delivered"}
```

这条用例盯的就是"连环 400"：收到结构化错误后，模型第二次调用必须把枚举改对，而不是换个词继续编。

## 四、沉淀成方法：Function Calling 测试三层

| 层级 | 测什么 | 核心手段 |
|---|---|---|
| 参数契约层 | 模型会不会编参数 | Pydantic/JSON Schema 校验 + Mock 断言参数合法性 |
| 异常分支层 | 工具报错时会不会失控 | Mock 返回 4xx/5xx/超时，断言自我纠正、重试有上限 |
| 任务完成层 | 端到端目标达成吗 | 任务成功率 + 调用次数/成本统计 |

配套三条工程纪律：一是**工具描述必须用严格 JSON Schema**，枚举值、必填项、取值范围写死，自然语言描述"大概是个状态"就是埋雷；二是**真实 API 永远藏在网关后面**，模型的一切调用先过校验，测试环境全走 Mock；三是**每次工具调用全量落日志**（工具名 + 参数 + 返回），出问题时能像这次一样把完整的"作案过程"回放出来。

## 五、面试追问，你答得上来吗

1. 模型为什么会编造参数？怎么降低概率？——答：根因是工具描述模糊 + 模型把参数生成当"续写"。手段按性价比排序：严格 JSON Schema 带枚举和描述、给每个枚举值加注释、开启各平台的 strict 工具调用模式、把校验错误结构化喂回给模型。注意这些都只是"降低概率"，所以网关拦截这道硬防线不能省——**校验是兜底，提示词优化是减少触发。**
2. 工具调用的异常分支和普通接口的异常测试有什么不同？——答：普通接口异常测试断的是"系统返回正确错误码"；工具调用异常测试断的是**模型的下一步行为**——它是修正参数重试、换个工具、还是向用户求助？所以用例里要有行为序列断言和次数上限，防止"重试"变成"死循环烧钱"。
3. 工具的接口本身升级了（加了必填字段），你怎么保证 Agent 不崩？——答：工具 schema 进版本管理，schema 变更必须跑两遍回归：契约测试套件验证校验逻辑跟上了，黄金任务集验证模型在新 schema 下还能正确调用——这和 prompt 变更是一个道理：**工具 schema、prompt、模型是绑定的三元组，动任何一个都要回归。**

---

下一篇预告：《Agent 半夜陷入死循环，一夜烧掉上万 token——轨迹测试与熔断》


AI 测试开发面试高频题："Function Calling / Tool Use 怎么测？" 工具调用是 Agent 的手脚，也是事故重灾区：模型会编造不存在的参数值，而下游 API 不会惯着它。这篇讲怎么在中间加一道契约防线。

模型编造 API 参数，工具调用连环 500——Function Calling 契约测试

人工智能

测试

后端

FunctionCalling测试核心在于契约校验与异常恢复：用Pydantic严格定义参数枚举，网关拦截非法调用；Mock真实API，断言模型调用参数合法性与重试收敛上限，防止编造值触发死循环烧token。

代码解释

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

模型编造 API 参数，工具调用连环 500——Function Calling 契约测试-腾讯云开发者社区-腾讯云

模型编造 API 参数，工具调用连环 500——Function Calling 契约测试

模型编造 API 参数，工具调用连环 500——Function Calling 契约测试

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐