没有最强的 LLM 了：把 Claude 4.6、GPT-5.4、Gemini 3.1 Pro 放进一个路由器

过去两年我们习惯了"先看榜单，再选一个最强的接上"。到了 2026 年春天，这个习惯不再成立——三个前沿模型在同一个月里完成迭代之后，任何一张榜单都只能解释其中一个模型为什么赢。

分化已经发生

先看实际基准。这里的数据综合自多个第三方测评（见文末来源），数据会因版本和日期有小幅差异，我只取各源都认可的方向性结论：

这张表没有一个全栈赢家。如果你把它们当成应聘者，那就是三份偏科严重的简历：

• Claude Opus 4.6：写出来的代码最干净，注释合理，适合交付给人类同事继续维护。SWE-bench Verified 领先但优势不大，一到更难的 SWE-bench Pro 就被 GPT-5.4 反超
• GPT-5.4：Agent 场景的执行者。它不一定写出最漂亮的代码，但它更擅长"跑起来"——终端命令、构建系统、计算机 UI 操作。OSWorld 超人类基线是一个信号：短期任务的端到端自动化已经越过可用门槛
• Gemini 3.1 Pro：推理和长上下文的王者。ARC-AGI-2 从前代翻倍到 77.1%，意味着抽象问题解决能力上了一个台阶；1M~2M 上下文让它几乎成为"读完整个代码库再回答"类场景的唯一选择

从"谁最强"的角度问，这三个模型谁都不是答案。从"做什么事用谁"的角度问，答案就清晰了。

一个问题：这个任务应该交给谁？

把这个问题形式化，它就是一个典型的路由问题。路由维度至少包括：

1. 任务类型（代码生成 / Agent 执行 / 长文档分析 / 推理）
2. 上下文长度（决定了哪些模型根本进不了候选名单）
3. 预算约束（按 token 计费的现实）
4. 延迟要求（Gemini 的吞吐和 GPT-5.4 的响应速度各有优势）

下面这段代码是一个最小化的路由器实现。它不依赖任何框架，只用一个决策函数决定调用哪个模型：

from dataclasses import dataclass
from enum import Enum

class TaskType(Enum):
    CODE_WRITE = "code_write"          # 写新代码、重构
    CODE_REVIEW = "code_review"        # 审阅、解释代码
    AGENT_EXEC = "agent_exec"          # 终端命令、工具调用链
    LONG_CONTEXT = "long_context"      # 大仓库理解、长文档分析
    REASONING = "reasoning"            # 抽象推理、多步逻辑
    GENERAL = "general"                # 其他

@dataclass
class RoutingRequest:
    task_type: TaskType
    context_tokens: int                # 输入 token 数量
    latency_sensitive: bool = False    # 是否对延迟敏感
    cost_sensitive: bool = False       # 是否对成本敏感

class ModelRouter:
    # 经验阈值,根据自己的账单调整
    CLAUDE_CONTEXT_LIMIT = 200_000
    GPT_CONTEXT_LIMIT = 1_000_000

    def route(self, req: RoutingRequest) -> str:
        # 规则 1: 超过 200K 的上下文只能选 Gemini 或 GPT-5.4
        if req.context_tokens > self.CLAUDE_CONTEXT_LIMIT:
            if req.context_tokens > self.GPT_CONTEXT_LIMIT:
                return "gemini-3.1-pro"
            # 200K-1M 区间:Gemini 更便宜,GPT-5.4 更快
            return "gemini-3.1-pro" if req.cost_sensitive else "gpt-5.4"

        # 规则 2: 按任务类型分发
        if req.task_type == TaskType.CODE_REVIEW:
            # 代码审阅要求可读性和注释质量
            return "claude-opus-4.6"

        if req.task_type == TaskType.AGENT_EXEC:
            # 终端/工具调用,GPT-5.4 在 Terminal-Bench 领先明显
            return "gpt-5.4"

        if req.task_type == TaskType.REASONING:
            # ARC-AGI-2 领先意味着 Gemini 对抽象推理更强
            return "gemini-3.1-pro"

        if req.task_type == TaskType.CODE_WRITE:
            # 简单代码任务用便宜的 GPT-5.4,复杂多文件重构用 Claude
            if req.cost_sensitive:
                return "gpt-5.4"
            return "claude-opus-4.6"

        # 默认回退:成本优先
        return "gpt-5.4" if req.cost_sensitive else "claude-opus-4.6"


# 使用示例
router = ModelRouter()

# 场景 A: 审阅一个 PR
req = RoutingRequest(
    task_type=TaskType.CODE_REVIEW,
    context_tokens=15_000,
)
print(router.route(req))  # claude-opus-4.6

# 场景 B: 让 Agent 跑一套 CI 修复流程
req = RoutingRequest(
    task_type=TaskType.AGENT_EXEC,
    context_tokens=30_000,
    latency_sensitive=True,
)
print(router.route(req))  # gpt-5.4

# 场景 C: 读完整个单体仓库再回答架构问题
req = RoutingRequest(
    task_type=TaskType.LONG_CONTEXT,
    context_tokens=800_000,
)
print(router.route(req))  # gemini-3.1-pro

这段代码的价值不在代码本身，而在于它强迫你回答一个问题：你的任务有哪些不同的"形状"？ 如果你发现你的所有调用都进了同一个分支，那说明你的业务根本用不到三个模型，选一个就够了。但只要你的业务覆盖了代码生成、Agent 执行、长文档这三类场景中的两类，路由就能降低 30%~60% 的 API 成本，而且几乎不损失质量。

成本数据为什么我只给方向而不给具体数字

写到这里必须说清楚一件事：我在调研过程中看到了至少三组互相矛盾的定价数据。同一个 GPT-5.4，有的源说输入 $2.5/M，有的源说 $15/M；Gemini 3.1 Pro 有的源标 $2/M，有的源标 $12.5/M。原因大致有几个：

• OpenRouter 聚合的价格和模型原厂 API 价格不同
• 不同版本（Standard / Pro / Thinking）定价差异大
• 月初月末的促销和配额变化

结论是：不要拿任何第三方博客的定价表去做预算，去官方计费页面拉最新数据，或者直接用你自己的账单反推每 1K token 的实际成本。这是这篇文章里我唯一不打算给出"标准答案"的部分。

但定价的相对关系是稳定的：

• GPT-5.4 整体最便宜，适合大流量场景
• Claude Opus 4.6 整体最贵，适合质量敏感场景
• Gemini 3.1 Pro 长上下文场景下的单位成本最低

我踩过的两个坑

坑一：只看 SWE-bench Verified 就下结论。 这是最流行的代码基准，但它的任务难度分布偏容易，对前沿模型的区分度已经不够了。真正能看出差距的是 SWE-bench Pro 和 Terminal-Bench 2.0。这也是为什么同一个 Opus 4.6 在 Verified 上看起来领先、到 Pro 上就被反超——两个榜单测的根本不是同一件事。

坑二：用基准分数线性外推到业务场景。 ARC-AGI-2 是抽象推理基准，Gemini 3.1 Pro 领先不代表它在"理解业务需求生成 SQL"这类场景也领先。真实的选型只能在你自己的任务集上回归。上面的路由器只是一个起点，它提供的是一个"怎么分类任务"的思路，不是最终配置。

接下来你可以做什么

如果你现在用的是单一模型，我建议做三件事：

1. 把最近一周的 API 调用按任务类型打上标签，看分布。如果超过 80% 集中在一类任务，继续单模型；否则路由能省钱
2. 挑一个非核心链路（比如内部工具、日志分析）先试双模型路由，观察两周的成本和质量曲线
3. 把长上下文场景单独拉出来测一次 Gemini 3.1 Pro，这是目前唯一能稳定处理 1M+ 上下文的选项

至于未来会不会出现一个重新统一所有赛道的模型？大概率会，但不是今年。当三个实验室同时把资源押在 Agent 场景上，分化会继续扩大而不是收敛。架构师的工作也随之改变——从"盯紧一家"变成"管理一个模型组合"。

参考来源（请自行以官方页面数据为准，下方链接均为撰文时可访问的第三方测评）：

• MindStudio - GPT-5.4 vs Claude Opus 4.6 vs Gemini 3.1 Pro: Real Benchmark Results
• NxCode - GPT-5.4 vs Claude Opus 4.6 for Coding: 2026 Comparison
• LM Council - AI Model Benchmarks Apr 2026
• DataCamp - Gemini 3.1: Features and Benchmarks
• LLM-Stats - AI Updates Today (April 2026)