第三章模型选型不是选最强——Agent场景的特殊评估标准某金融科技团队做了一个Agent，用于自动化处理客户的开户申请

某金融科技团队做了一个Agent，用于自动化处理客户的开户申请。

他们选了当时最强的GPT-5.1——毕竟benchmark分数最高，对吧？

结果上线第一周就出事了。Agent在调用"查询客户信息"工具时，频繁返回错误的参数格式。有时候是{"customer_id": "123"}，有时候是{"id": "123"}，有时候干脆是{"name": "张三"}——而API只接受第一种格式。

工具调用失败率高达23%。

团队把模型换成了Claude Sonnet 4.6。同样的工具定义，同样的prompt，工具调用成功率直接到了98.5%。

GPT-5.1不行吗？当然不是。 在MMLU、HumanEval这些通用benchmark上，GPT-5.1依然是顶级水平。

问题出在别的地方：Agent场景的模型评估标准，和通用NLP评测完全不同。

通用benchmark不测的东西

你去看各家模型的评测报告，满屏都是这些指标：

MMLU：多学科知识问答
HumanEval：代码生成
GSM8K：数学推理
MATH：高难度数学

这些指标有用吗？有用。但它们测的是"模型聪明不聪明"，不是"模型能不能当好Agent"。

Agent对模型有3个特殊要求，通用benchmark几乎不测：

1. 工具调用准确率

这是Agent场景最核心的指标，却几乎没有主流benchmark系统测试。

工具调用不是"生成JSON"那么简单。它要求模型：

理解工具描述：从自然语言描述中理解工具的功能、参数、约束
选择正确工具：从几十个工具中选出最合适的一个
生成正确参数：参数名、类型、格式都要对
处理嵌套调用：一个工具的输出是另一个工具的输入
处理错误反馈：工具返回错误时，能正确修正

一个真实的踩坑案例：

某Agent注册了一个"发送邮件"工具，参数定义是：

{
  "name": "send_email",
  "parameters": {
    "to": {"type": "string", "description": "收件人邮箱"},
    "subject": {"type": "string", "description": "邮件主题"},
    "body": {"type": "string", "description": "邮件正文"}
  }
}

用户说："给张三发个邮件，告诉他明天的会议改到下午3点"。

GPT-5.1的输出：

{"name": "send_email", "arguments": "{\"to\": \"张三\", \"subject\": \"会议时间变更\", \"body\": \"明天的会议改到下午3点\"}"}

问题在哪？"张三"不是邮箱地址。模型没有追问，直接把名字当邮箱发了。

Claude Sonnet 4.6的输出：

{"name": "send_email", "arguments": "{\"to\": \"[需要确认张三的邮箱地址]\", \"subject\": \"会议时间变更通知\", \"body\": \"张三您好，明天的会议已改至下午3点，请准时参加。\"}"}

Claude也没有邮箱地址，但它"知道"这里需要邮箱格式，于是在参数里标注了需要确认。

这不是"聪明不聪明"的问题，是对工具调用场景的理解深度不同。

（见配图0：通用benchmark vs Agent专用评估维度）

2. 指令遵循稳定性

Agent的prompt通常很长——系统角色、工具列表、输出格式约束、安全规则、示例……动辄几千字。

模型能不能稳定遵循这些指令？通用benchmark不测这个。

一个被忽视的问题：指令遵循的"漂移"

很多Agent在对话开始时表现良好，但随着对话轮次增加，模型开始"忘记"之前的指令。

典型表现：

第1-5轮：严格按JSON格式输出
第6-10轮：偶尔漏掉字段
第11轮以后：开始输出自然语言，忽略格式要求

这不是上下文窗口不够，是指令遵循的稳定性问题。

测试方法：给模型一个复杂的输出格式要求，连续对话50轮，看格式遵循率。

模型	前10轮格式正确率	11-30轮	31-50轮
GPT-5.1	100%	96%	91%
Claude Sonnet 4.6	100%	98%	96%
Gemini 2.5 Pro	100%	94%	85%
o4	100%	97%	93%
DeepSeek V4	100%	89%	74%

数据来源：某Agent框架团队的内部测试

Claude在长对话中的指令遵循稳定性依然最好。GPT-5.1相比前代有明显提升。o4作为推理模型在长对话中表现也优于预期。

3. 上下文窗口利用效率

各家模型都在卷上下文窗口大小：128K、200K、1M、2M……

但窗口大不等于用得好。

真实情况是：很多模型在上下文超过一定长度后，推理质量明显下降。这叫"中间迷失"（Lost in the Middle）现象——模型善于利用开头和结尾的信息，但中间部分的信息经常被忽略。

一个实验：

在100K token的上下文中，把关键信息放在不同位置，测试模型的检索准确率。

信息位置	GPT-5.1	Claude Sonnet 4.6	Gemini 2.5 Pro	o4
开头（前10%）	96%	97%	94%	95%
中间（40-60%）	75%	91%	78%	82%
结尾（后10%）	93%	95%	90%	92%

数据来源：基于Lost in the Middle论文方法的复现测试

Claude在长上下文的中间区域表现依然明显更好。这对Agent很关键——Agent的记忆系统、工具返回结果、历史对话往往都在上下文的中间位置。

值得注意的是，Gemini 2.5 Pro相比1.5版本在中间区域有改善，o4作为推理模型在信息检索上也比通用模型更稳定。

模型格局：谁在Agent场景真正能打

当前的模型市场比以往复杂得多。不只是"谁更强"的问题——不同类型的模型有不同的定位。

两类模型的分化

最关键的趋势是通用模型和推理模型的分化：

通用模型（GPT-5.1, Claude Sonnet 4.6, Gemini 2.5 Pro）：快、便宜、工具调用强——适合Agent的日常执行
推理模型（GPT-5.5 Thinking, o4-mini, DeepSeek R3, Claude Opus 4.8）：慢、贵、推理深——适合Agent的复杂决策

这对Agent架构的影响是根本性的：不是选一个模型，而是选一个模型组合。

OpenAI：从GPT-5.1到GPT-5.1/GPT-5.5 Thinking

OpenAI的产品线已经清晰分化：

GPT-5.1——Agent的主力选择：

工具调用准确率大幅提升（比前代高约5%）
原生支持structured output（JSON Schema强制约束）
1M token上下文窗口
指令遵循能力是GPT系列最强的

o4——复杂推理的核武器：

在数学、代码、科学推理上碾压所有通用模型
但延迟高（单次推理可能要10-30秒）、价格贵
不适合高频工具调用，适合"思考型"决策

o4-mini——轻量推理模型：

推理能力接近o4，但速度更快、价格更低
适合需要一定推理但不需要满血o4的场景

一个典型场景：

用户："分析一下这个季度的销售数据，找出异常点，给出改进建议"

→ o4处理（需要深度推理）：分析数据、发现异常模式、制定策略
  ↓ 输出分析计划
→ GPT-5.1执行（需要工具调用）：查数据库、拉报表、格式化输出
  ↓ 输出数据
→ o4整合：基于数据给出最终建议

Anthropic：Claude Sonnet 4.6 + Claude Opus 4.8

Claude在Agent场景的优势持续扩大。

Claude Sonnet 4.6——Agent场景的新标杆：

工具调用准确率行业第一（Berkeley Tool Calling Leaderboard）
支持parallel tool calling（之前不支持，这是重大更新）
原生MCP协议支持（Anthropic主导的工具调用标准）
长对话指令遵循稳定性最好
200K token上下文窗口

Claude Opus 4.8——推理巨兽：

推理深度接近o4，但在工具调用场景上更自然
适合需要"深度思考+工具调用"的混合场景
价格是Sonnet 4.6的15倍——只在关键时刻使用

Claude的关键优势：

在Berkeley Tool Calling Benchmark上：

模型	工具选择准确率	参数生成准确率	综合成功率
Claude Sonnet 4.6	98.3%	96.1%	94.5%
GPT-5.1	97.1%	93.8%	91.2%
Claude Opus 4.8	98.1%	96.8%	95.1%
Gemini 2.5 Pro	95.6%	90.4%	86.7%
o4	93.2%	88.7%	82.5%
DeepSeek V4	92.8%	86.3%	80.1%

数据来源：Berkeley Function Calling Leaderboard，5月

注意o4的排名——推理能力强不代表工具调用强。o4在"想"的时候厉害，但在"做"的时候（生成精确的JSON参数）反而不如专门的通用模型。

Google：Gemini 2.5 Pro

Gemini 2.5 Pro是进步最快的模型。

优点：

1M token超长上下文，且中间区域利用率比1.5版本显著提升
多模态能力（视频理解、图片分析）行业领先
"思考预算"机制：可以控制推理深度，在速度和准确性之间灵活调节
价格便宜（比同级别模型低30-50%）

坑点：

工具调用格式稳定性仍不如Claude/GPT-5.1
Structured output支持不如OpenAI完善
生态工具链（MCP、SDK等）成熟度不如OpenAI/Anthropic

适合场景：需要处理超长文档、视频分析的Agent；预算有限但需要大窗口的场景。

DeepSeek：DeepSeek R3改变了开源Agent的游戏规则

DeepSeek有两款模型对Agent开发者意义重大：

DeepSeek R3——开源推理模型：

推理能力接近o4，但完全开源、可本地部署
适合对数据隐私要求高的Agent场景
思维链透明——你可以看到它"怎么想的"，这对调试Agent极有价值

DeepSeek V4——性价比之王：

价格只有Claude Sonnet 4.6的1/20
工具调用准确率持续提升（但和第一梯队仍有约10%差距）
中文场景表现优异

核心判断：如果你的Agent对数据隐私有要求，或者预算极低，DeepSeek R3/V4是唯一的选择。但在工具调用密集的生产环境，还是建议用Claude/GPT-5.1。

Qwen 3 / Llama 4：开源的另一种选择

Qwen 3：中文场景表现优异，支持MoE架构，推理效率高。工具调用能力比DeepSeek略强，但生态不如DeepSeek活跃。

Llama 4：Meta的开源旗舰，多模态能力突出。但在Agent场景的tool calling上，和闭源第一梯队仍有明显差距。

（见配图1：各模型Tool Calling能力雷达图）

混合模型架构：决策+推理+执行

早期的混合架构是"大模型决策+小模型执行"。现在架构进化成了三层：

┌─────────────────────────────────────────────────────────────┐
│                      用户请求                                │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│          推理层（o4 / Claude Opus 4.8 / DeepSeek R3）          │
│  · 复杂问题拆解                                              │
│  · 多步推理规划                                              │
│  · 异常诊断                                                  │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│        决策层（GPT-5.1 / Claude Sonnet 4.6）                    │
│  · 理解用户意图                                              │
│  · 选择工具                                                  │
│  · 生成工具调用参数                                          │
│  · 错误恢复                                                  │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│       执行层（Gemini 2.5 Flash / DeepSeek V4 / o4-mini）     │
│  · 执行简单工具调用                                          │
│  · 格式化输出（structured output）                           │
│  · 简单文本生成                                              │
│  · 数据提取和整理                                            │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                      结果整合                                │
└─────────────────────────────────────────────────────────────┘

（见配图2：混合模型架构图）

关键变化：推理层从何而来

推理模型出现之前没有推理层——因为没有好的推理模型。GPT-5.5 Thinking/R3出现后，Agent的架构多了一个维度：

简单任务：决策层直接处理，不需要推理
复杂任务：推理层先"想清楚"，决策层再"动手"

成本对比

某数据分析Agent的实际运行数据：

架构	单次任务平均成本	平均延迟	成功率
全Claude Sonnet 4.6	$0.08	6.2秒	96%
全o4	$0.35	18.5秒	97%
两层（Sonnet 4.6决策 + DeepSeek V4执行）	$0.02	5.8秒	95%
三层（GPT-5.5 Thinking推理 + Sonnet 4.6决策 + V4执行）	$0.06	9.3秒	98%

三层架构的成功率最高——因为推理层解决了之前大模型"想不清楚就乱调工具"的问题。

什么任务需要推理层

需要推理层：

多步规划（需要3步以上推理）
异常诊断（工具返回意外结果）
冲突解决（多个工具返回矛盾信息）
策略决策（不是简单的是/否判断）

不需要推理层：

单步工具调用
格式化/转换任务
信息查询和汇总
简单的条件判断

一个实现示例

class ThreeTierAgent:
    def __init__(self):
        self.reasoning_model = GPT55Thinking()              # 推理层：深度思考
        self.decision_model = ClaudeSonnet46()    # 决策层：选工具、调参数
        self.execution_model = DeepSeekV4()      # 执行层：简单任务快速处理
    
    async def run(self, user_input: str):
        # 第1步：判断任务复杂度
        complexity = await self.decision_model.complete([
            {"role": "system", "content": COMPLEXITY_PROMPT},
            {"role": "user", "content": user_input}
        ])
        
        # 第2步：复杂任务走推理层
        if complexity.level == "hard":
            plan = await self.reasoning_model.complete([
                {"role": "system", "content": REASONING_PROMPT},
                {"role": "user", "content": user_input}
            ])
        else:
            plan = complexity  # 简单任务直接用决策层的输出
        
        # 第3步：决策层生成工具调用
        tool_calls = await self.decision_model.complete([
            {"role": "system", "content": DECISION_PROMPT},
            {"role": "user", "content": str(plan)}
        ])
        
        # 第4步：执行层处理简单步骤
        results = []
        for step in tool_calls.steps:
            if step.complexity == "simple":
                result = await self.execution_model.execute(step)
            else:
                result = await self.decision_model.execute(step)
            results.append(result)
        
        # 第5步：整合结果
        final = await self.decision_model.complete([
            {"role": "system", "content": SYNTHESIS_PROMPT},
            {"role": "user", "content": str(results)}
        ])
        
        return final

关键设计点

复杂度判断：用一个轻量调用判断是否需要推理层。大部分任务不需要——推理层只在20%的任务中激活。
推理结果格式化：推理模型的输出往往是长篇思维链，需要决策层"翻译"成结构化的工具调用。
错误回退：推理层超时或失败时，自动降级为两层架构。
成本控制：o4按推理token计费，需要设置推理预算上限。
MCP标准化：三层之间通过MCP协议传递工具定义和调用结果，避免格式适配问题。

快速判断框架：什么场景用什么模型

最后，给你一个实用的判断框架。最新版。

场景1：工具调用频繁（>5次/任务）

场景2：超长上下文（>100K token）

推荐：Claude Sonnet 4.6 或 Gemini 2.5 Pro

理由：Claude在长上下文的中间区域表现更好；Gemini 2.5 Pro窗口1M且中间区域利用率提升。

注意：如果关键信息集中在开头或结尾，GPT-5.1也可以。

场景3：多模态需求（图片/视频理解）

场景4：成本敏感、工具调用少

场景5：需要稳定JSON输出

推荐：GPT-5.1（structured output）或 Claude Sonnet 4.6

理由：GPT-5.1的structured output功能最完善，可以JSON Schema强制约束；Claude的指令遵循稳定性最好。

重要变化：structured output已经从"可选项"变成"必选项"——所有主流模型都原生支持了。如果你的Agent还在用正则解析JSON输出，赶紧升级。

场景6：代码生成为主

推荐：Claude Sonnet 4.6 或 GPT-5.5 Thinking

理由：Claude Sonnet 4.6在代码+工具调用场景上综合表现最好；o4在算法设计、架构规划等需要深度推理的代码任务上更强。

场景7：需要深度推理的复杂决策

一个决策流程图

当你面对一个Agent项目，按这个顺序选模型：

需要深度推理吗？（多步规划、异常诊断）
- 是 → 推理层用o4或Claude Opus 4.8，决策层用Sonnet 4.6
- 否 → 继续判断
工具调用频率高吗？（>5次/任务）
- 是 → Claude Sonnet 4.6
- 否 → 继续判断
上下文长度需求？
- 100K → Claude Sonnet 4.6 或 Gemini 2.5 Pro
- <100K → 继续判断
成本敏感吗？
- 是 → DeepSeek V4 或两层混合架构
- 否 → GPT-5.1 或 Claude Sonnet 4.6
有多模态需求吗？
- 图片 → GPT-5.1
- 视频 → Gemini 2.5 Pro
- 无 → 继续判断
默认选择：Claude Sonnet 4.6（Agent场景综合表现最好）

小结

模型选型不是选"最强"，是选"最合适"。

关键变化：

推理模型和通用模型的分化，让Agent架构从两层变成三层
Structured output成为标配，JSON解析不再靠运气
MCP协议统一了工具调用接口，多模型协作的适配成本大幅降低
Claude Sonnet 4.6在Agent场景的全面领先，工具调用、指令遵循、长上下文三项第一

核心原则不变：没有完美模型，只有最适合场景的模型。但现在的"选模型"已经不是选一个——而是选一个组合。

第三章 模型选型不是选最强——Agent场景的特殊评估标准