在云原生 Agent 架构中,Function Calling 是连接大模型与后端微服务的核心桥梁。模型能否准确、稳定地生成工具调用指令,直接决定了 AI 应用在生产环境中的可靠性。
最近在一个电商 AI 客服项目中,我们遇到了一个棘手问题:三个模型(Claude 4.6、GPT-5.4、Gemini 2.5)面对同一套 API Schema,表现差异远超预期。有的模型把嵌套 JSON 序列化成字符串,有的在该并行调用时选择串行,还有的直接输出格式错误的 JSON。
这促使我们做了一次系统性的横向评测,并基于结果设计了一套面向生产环境的多模型调度方案。
我们从实际 API 调用场景出发,设计了 900 个测试用例,每个模型跑 3 轮取均值:
测试使用标准 JSON Schema 定义工具接口,模拟典型的电商后端 API:
{
"tools": [
{
"name": "search_products",
"description": "商品搜索接口,支持分类筛选和价格区间",
"parameters": {
"type": "object",
"properties": {
"query": { "type": "string", "description": "搜索关键词" },
"category": {
"type": "string",
"enum": ["electronics", "clothing", "food"]
},
"price_range": {
"type": "object",
"properties": {
"min": { "type": "number", "description": "最低价(元)" },
"max": { "type": "number", "description": "最高价(元)" }
}
},
"sort_by": { "type": "string", "enum": ["price", "rating", "sales"] }
},
"required": ["query"]
}
},
{
"name": "create_order",
"description": "创建订单,需要完整的收货地址",
"parameters": {
"type": "object",
"properties": {
"product_id": { "type": "string" },
"quantity": { "type": "integer", "minimum": 1 },
"shipping_address": {
"type": "object",
"properties": {
"city": { "type": "string" },
"street": { "type": "string" },
"zip": { "type": "string" }
},
"required": ["city", "street"]
}
},
"required": ["product_id", "quantity", "shipping_address"]
}
}
]
}模型 | 基础调用 | 参数补全 | 接口编排 | 复杂参数 | 意图拒绝 | 异常恢复 | 综合得分 |
|---|---|---|---|---|---|---|---|
Claude Opus 4.6 | 99.5% | 94.2% | 91.3% | 96.7% | 97.0% | 88.3% | 94.5% |
GPT-5.4 | 99.0% | 96.1% | 93.7% | 91.2% | 95.0% | 92.7% | 94.6% |
Gemini 2.5 Pro | 98.5% | 90.8% | 86.4% | 84.3% | 93.0% | 85.0% | 89.7% |
Claude 和 GPT 综合几乎持平,但各有明显偏科。
Claude 在嵌套 JSON 参数的处理上表现最好(96.7%)。面对 shipping_address 这种多层结构,输出格式几乎不会出错。
但 Claude 在多接口编排时倾向于串行——即使两个 API 调用之间没有数据依赖,它也有 8.7% 的概率选择"先调一个、等返回、再调下一个"。这在云端架构中意味着多消耗一轮 RTT(往返时延),对延迟敏感的场景需要注意。
另外,Claude 在 tool_choice: "auto" 模式下约 3% 的概率会跳过工具调用直接文本回复。生产建议:关键链路用 tool_choice: "required" 兜底。
GPT 的并行调用能力确实领先。测试场景:"查北京明天天气 + 搜适合户外的外套",GPT 能稳定并行发起两个独立请求:
[
{ "name": "get_weather", "arguments": { "location": "北京", "date": "2026-03-26" } },
{ "name": "search_products", "arguments": { "query": "户外外套", "category": "clothing" } }
]在微服务架构中,这种并行能力可以直接减少 Agent 的端到端响应时间。
但 GPT 有个需要在 API Gateway 层做兜底的问题:嵌套 object 类型参数约 8.8% 的概率被错误序列化为字符串:
// 期望
{ "price_range": { "min": 100, "max": 500 } }
// 实际(偶发)
{ "price_range": "{\"min\": 100, \"max\": 500}" }Gemini 单价最低,简单场景表现正常。但嵌套参数的 JSON 格式错误率达到 15.7%——漏逗号、多逗号、括号不匹配,这些在 API Gateway 的参数校验层会直接触发 400 错误。
在需要严格 JSON 输出的云端流水线中,使用 Gemini 必须配套更强的参数修复中间件。
在 API Gateway(如 Kong / APISZ / 自研网关)中增加 Function Call 参数校验中间件:
import json
import re
def sanitize_tool_arguments(raw_args: str | dict) -> dict:
"""统一处理三家模型的参数格式差异"""
if isinstance(raw_args, dict):
# 检查是否有字符串化的嵌套对象(GPT 偶发问题)
for key, value in raw_args.items():
if isinstance(value, str) and value.startswith('{'):
try:
raw_args[key] = json.loads(value)
except json.JSONDecodeError:
pass
return raw_args
if isinstance(raw_args, str):
# 修复 Gemini 常见的 JSON 格式问题
cleaned = re.sub(r',\s*}', '}', raw_args)
cleaned = re.sub(r',\s*]', ']', cleaned)
return json.loads(cleaned)
raise ValueError(f"Unexpected argument type: {type(raw_args)}")一个被严重低估的优化手段——把 Schema 的 description 写详细:
{
"price_range": {
"type": "object",
"description": "价格筛选区间,JSON 对象格式。示例:{\"min\": 100, \"max\": 500}",
"properties": {
"min": { "type": "number", "description": "最低价格,单位人民币元" },
"max": { "type": "number", "description": "最高价格,单位人民币元" }
}
}
}这个改动把 GPT 的嵌套对象错误率从 8.8% 降到了 2.1%,Gemini 的格式错误也下降了约 40%。在 API Schema 管理平台上维护好 description,是投入产出比最高的优化。
根据请求复杂度动态选择模型,是降本增效的关键:
def select_model(request_context):
tool_count = len(request_context.available_tools)
has_nested = any(has_nested_params(t) for t in request_context.available_tools)
if tool_count > 3 and not has_nested:
return "gpt-5.4" # 多接口编排强
elif has_nested:
return "claude-4.6" # 嵌套处理稳
elif request_context.cost_sensitive:
return "gemini-2.5" # 简单场景省钱
else:
return "claude-4.6" # 默认选稳定性云端 Agent 的重试策略需要把模型切换纳入考虑:
async def call_with_fallback(primary_model, messages, tools):
fallback_chain = {
"claude-4.6": ["gpt-5.4", "gemini-2.5"],
"gpt-5.4": ["claude-4.6", "gemini-2.5"],
"gemini-2.5": ["gpt-5.4", "claude-4.6"],
}
models = [primary_model] + fallback_chain[primary_model]
for model in models:
try:
response = await model_call(model, messages, tools)
parsed = sanitize_tool_arguments(response.arguments)
if validate_against_schema(parsed, tools):
return parsed
except (JSONDecodeError, ValidationError) as e:
log_fallback(model, e)
continue
raise AgentError("所有模型均调用失败,触发人工兜底")在 System Prompt 中显式声明调用策略,对 Claude 尤其有效:
API 调用规则:
- 多个 API 之间无数据依赖时,必须并行调用
- 有依赖关系时串行调用,并注明依赖链
- 每次调用必须包含完整参数,不得省略 required 字段加入这段提示后,Claude 的不必要串行调用减少了 60%。
基于 900 用例 × 3 轮的实际消耗:
模型 | Token 消耗 | 基础费用 | 含重试总费用 | 重试成本占比 |
|---|---|---|---|---|
Claude Opus 4.6 | 2.48M | $41.7 | $43.2 | 3.6% |
GPT-5.4 | 2.41M | $38.5 | $39.8 | 3.4% |
Gemini 2.5 Pro | 2.55M | $22.3 | $26.1 | 17.0% |
Gemini 单价低但重试成本高,实际性价比取决于业务复杂度。简单 CRUD 场景选 Gemini 没问题;涉及复杂参数结构的场景,Claude 和 GPT 的低重试率反而更省钱。
如果你需要在一套架构中灵活切换多个模型,可以考虑使用统一的 API 管理层。我们在这次评测中就是通过 ofox 的多模型路由来管理不同厂商的 API 调用——统一 endpoint、统一鉴权、统一监控,省去了分别维护多套 SDK 的运维负担。
Function Calling 在云端 Agent 架构中的地位越来越核心,选对模型、做好防御性编程、设计合理的路由和降级策略,是保障生产可靠性的三大支柱:
别迷信单一模型的 benchmark 分数,在自己的 API Schema 上实测才是王道。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。