GPT-5.6、Claude Opus 5、Gemini 3.7 Flash：我不会按总榜选模型

过去两个月，模型选型越来越像一件“看起来容易、实际上很容易选错”的事。

OpenAI 有 GPT-5.6 Sol / Terra / Luna，Anthropic 在 7 月 24 日发布了 Claude Opus 5，Google 8 月 13 日又把 Gemini 3.7 Flash 推到了 Coding 和 Agent 场景。

如果只看厂商发布页，你会得到三套都很漂亮的 benchmark。

问题是，你真正要上线的业务不叫 SWE-Bench，也不叫 AutomationBench。

所以这篇我不做“谁是第一”的排名。我只回答一个更实际的问题：如果今天要给企业系统选模型，我会按什么工作负载拆。

先把价格摆在桌面上

按当前官方公开价：

* Gemini 3.7 Flash 这一价格是 2026 年底前的 introductory price；2027 年起变为 $1.50 / $7.50。

先提醒一句：

Token 单价不是成本。任务成功一次要花多少钱，才是成本。

一个模型价格便宜一半，但平均要多两次重试，并不一定更便宜。

场景一：大规模企业 RAG，我优先看 Terra、Luna 和 Flash

RAG 的核心不是让模型做世界上最难的推理，而是：

看懂问题
读懂检索证据
不要乱补
按格式回答

如果检索层本身做得好，我一般不会默认使用最高价旗舰。

更合理的是先让：

GPT-5.6 Terra / Luna
Gemini 3.7 Flash

跑公司自己的问题集。

真正要测的是：

• 引用支持率；
• 数字保真；
• “不知道”是否正确；
• 长文档噪声；
• 中文专业术语；
• 一次成功率；
• 每成功任务成本。

如果一个 5 万次/天的知识助手，模型单价只差几美元/百万 Token，月底就是一笔非常现实的成本。

这里我的倾向是：先把便宜模型推到业务阈值，再把少数失败请求升级。

场景二：长周期 Coding，我会重点测 GPT-5.6 Sol 和 Opus 5

Coding Benchmark 当然有用，但我会更看重长任务中的“稳定性”。

Anthropic 在 Opus 5 的发布材料里强调长运行 Agent 和复杂软件工程任务，并公开了一批客户测试数据。例如有客户报告，某些金融建模任务中，Opus 5 相比 Opus 4.8 平均高 9 个百分点，同时减少约三分之一轮次与工具调用，并节省约 60% 时间。

这里要注意：这是厂商发布页里的客户反馈，不等于第三方统一 benchmark。

OpenAI 则在 GPT-5.6 页面公布了较强的 Coding Agent、BrowseComp、OSWorld 等数据，并特别强调更少 Token 完成长任务。

如果是我的代码仓库，我不会先问：

谁 SWE-Bench 高？

我会给两家同样的真实任务：

修一个真实 Bug
改 4—8 个文件
必须通过现有测试
增加回归测试
不能改公共接口
限制最大工具调用数

然后比较：

第一次能不能跑过
改了多少无关文件
测试覆盖是否真实
人工 Review 用时
总 Token
总工具调用
最终成本

这比总榜更接近开发团队的真实痛点。

场景三：大量 Agent Workflow，Gemini 3.7 Flash 值得单独测

Google 这次很明确地把 3.7 Flash 往 Agent 和 Workflow 方向推。

公开数据里，AutomationBench 从 3.6 Flash 的 17.0% 提到 30.4%。

30.4% 本身说明一件事：复杂 Workflow 仍然很难。

但考虑到当前 $0.75 / $3.75 的价格，它非常适合被放在：

默认 Agent 工作马

而不是只做 Router。

我会把它拿来测试：

• 邮件整理；
• 文档归档；
• CRM 查询；
• 状态更新；
• 代码辅助；
• 多工具信息收集；
• 轻量 Supervisor。

失败或高风险时，再升级到更强模型。

场景四：复杂分析和“判断”，Opus 5 与 Sol 都要跑公司自己的题

法律、财务、策略、研究这类任务，最麻烦的是没有唯一答案。

这时 benchmark 很难直接告诉你“谁更好”。

我会构建一个内部评测集：

20 条真实研究问题
20 条复杂表格分析
20 条文档冲突判断
20 条开放式决策建议
20 条必须指出不确定性的任务

评测不要只让另一个 LLM 打分。

至少加入：

事实错误数
遗漏关键条件数
引用错误数
人工修改分钟数
Reviewer是否采纳

最后一个指标很重要：

模型的价值不是“写了多少”，而是人最终愿不愿意用。

场景五：大规模低风险处理，我不会碰旗舰模型

分类、抽取、改写、标签、标题、简单总结、格式转换，这类请求如果全部上 Sol 或 Opus 5，我会认为架构有问题。

除非你的量非常小，不值得做路由。

大规模系统应该至少分两层：

低成本模型
↓失败/风险/低置信
高能力模型

进一步可以三层：

Luna / Flash
↓
Terra
↓
Sol / Opus 5

这种路由真正省钱的前提是：升级条件必须由程序和评测驱动，而不是让模型自己决定。

一个我现在会直接放进架构里的字段

每次模型调用都记录：

{
  "task_type": "invoice_analysis",
  "model": "...",
  "input_tokens": 42102,
  "output_tokens": 3890,
  "latency_ms": 8210,
  "tool_calls": 3,
  "retry_count": 0,
  "task_success": true,
  "human_edit_minutes": 2.0,
  "escalated": false
}

一两周后，不需要争论哪个模型“感觉更聪明”。

你可以直接看：

每种任务
哪个模型成功率最高？
哪个模型每成功任务成本最低？
哪个模型人工修改最少？

这才是真正的模型选型。

厂商 benchmark 要看，但要知道它回答的是什么

OpenAI 在 GPT-5.6 官方页给了大量 benchmark，Anthropic 对 Opus 5 也展示了 Frontier-Bench、AutomationBench 和客户任务数据，Google 给了 FrontierCode、DeepSWE、GDP.pdf、AutomationBench。

这些数据可以帮你缩小候选范围。

但它们不能回答：

你的 Prompt
你的知识库
你的 Tool
你的权限
你的失败模式
你的用户

所以我的选型原则一直很简单：

官方榜单用来决定“谁值得进候选池”，公司自己的任务用来决定“谁能上线”。

如果最终让我给一个最简建议：

高复杂 Coding / 长任务：重点测 Sol、Opus 5
大规模 Agent：重点测 3.7 Flash、Terra
高频低风险：优先 Luna / Flash
开放权重和私有部署：另外开一条 Kimi K3 等模型评测线

不要找“一个模型解决全部问题”。2026 年真正成熟的系统，正在从模型选型走向模型调度。

更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：

https://www.zyentor.com/