从跑分到生产力：重新理解大模型基准测试与分层协作

前言
[1. Benchmark：理解模型能力的第一把尺子](#1. Benchmark：理解模型能力的第一把尺子)
- [1.1 Benchmark 解决了什么问题](#1.1 Benchmark 解决了什么问题)
- [1.2 常见评测维度与对应能力](#1.2 常见评测维度与对应能力)
- [1.3 为什么不能只看榜单第一](#1.3 为什么不能只看榜单第一)
[2. 从单一模型到分层模型系统](#2. 从单一模型到分层模型系统)
- [2.1 "哪个模型最强"不是完整问题](#2.1 “哪个模型最强”不是完整问题)
- [2.2 任务路由：把选择逻辑前置](#2.2 任务路由：把选择逻辑前置)
- [2.3 模型分层不等于质量分层](#2.3 模型分层不等于质量分层)
[3. 工具协作：从回答问题到推进任务](#3. 工具协作：从回答问题到推进任务)
- [3.1 一次工具调用的局限](#3.1 一次工具调用的局限)
- [3.2 可编程工具调用的核心价值](#3.2 可编程工具调用的核心价值)
- [3.3 ReAct 与工作流式 Agent](#3.3 ReAct 与工作流式 Agent)
[4. 真正应该核算的是总成本](#4. 真正应该核算的是总成本)
- [4.1 API 账单只是成本的一部分](#4.1 API 账单只是成本的一部分)
- [4.2 用"单位任务成本"替代"单次调用价格"](#4.2 用“单位任务成本”替代“单次调用价格”)
[5. 把模型能力接入真实工作流](#5. 把模型能力接入真实工作流)
- [5.1 从"回答质量"升级为"流程完成质量"](#5.1 从“回答质量”升级为“流程完成质量”)
- [5.2 一个可落地的四层架构](#5.2 一个可落地的四层架构)
- [5.3 设计 Agent 时的实用检查清单](#5.3 设计 Agent 时的实用检查清单)
总结

前言

每次新模型发布，讨论往往会迅速收敛到几个数字：MMLU 提升了多少，代码能力有没有超过竞品，谁在某项榜单上排名第一。这些问题当然有价值，但如果把模型真正接入业务，决定系统成败的通常不是某一项分数，而是三个更具体的问题：模型是否适合当前任务、能否稳定地完成完整流程、总成本是否可控。

这篇文章从 Benchmark 出发，先解释模型评测到底测量什么，再进一步讨论以 GPT 5.6 为代表的分层模型思路：把不同难度、不同频率和不同成本约束的任务分配给不同能力档位，并让模型通过工具、轻量程序和检查环节参与完整工作流。重点不在追逐一个"最强模型"，而在建立一套可复用的模型选型与系统设计方法。

1. Benchmark：理解模型能力的第一把尺子

1.1 Benchmark 解决了什么问题

大模型的能力不是一个单一的"聪明程度"分数。它可能知识面很广，却不擅长严谨推理；可能能写出漂亮的示例代码，却无法修复一个真实项目中的复杂 Bug；也可能英文表现优秀，但在中文专业语境下不够稳定。不同模型之间如果只靠主观体验比较，很难形成统一结论。

**Benchmark（基准测试）**的基本做法，是准备一组标准化题目，用相对固定的规则评估模型，再把结果汇总为可比较的分数。它像一组面向模型的标准考试，让"感觉更强"变成了多个维度上的可测量结果。

核心定义： Benchmark 是由标准测试题、评测规则和结果指标组成的模型能力测量体系。它提供比较基线，但不等于真实生产力。

基准测试主要有三层价值：

建立共同尺度：不同模型可以在相同题目和规则下进行横向比较。
定位能力短板：通过知识、推理、代码、数学和语言等维度，观察模型擅长什么、不擅长什么。
设置准入门槛：某项分数过低，往往说明模型在对应场景中存在明显风险，值得先排除或谨慎使用。

但它也有天然边界。标准题目通常是一次性输入、一次性输出，而真实任务可能包含澄清需求、查资料、调用工具、处理异常、复核结果和等待人工确认。考试分数描述的是模型在某类测试条件下的表现，不会自动转化成业务流程中的完成质量。

1.2 常见评测维度与对应能力

不同 Benchmark 关注的能力切片不同，理解它们的测试对象，比死记分数更重要。

评测项目	主要考察内容	典型题型	对工程选型的启发
`MMLU`	综合知识与跨学科理解	覆盖多个学科的选择题	适合观察知识广度，不能单独证明业务推理能力
`GPQA Diamond`	高难度专业推理	研究生级别的物理、化学、生物问题	更接近复杂知识推断，但不能代表工具协作能力
`HumanEval`	代码生成能力	根据题目生成可运行代码	可观察函数级编程能力，不能等价于真实项目开发
`SWE-bench`	软件工程问题解决能力	修复真实 GitHub 项目的缺陷	更贴近代码库级任务，仍需关注环境、测试与代理流程
`MATH/AIME`	数学推导与多步推理	竞赛数学题	用于观察严谨推导能力，不代表所有业务推理
`C-Eval`	中文知识与理解能力	中文学科题，覆盖多种难度	对中文场景有参考价值，还应结合行业语料验证

例如，HumanEval 关注的是模型能否写出通过测试的函数；SWE-bench 则把问题放进真实代码仓库，要求模型理解上下文、定位缺陷并完成修复。两者都属于代码评测，但对工程能力的要求并不相同。由此可见，"代码分数"本身不是一个足够精确的概念，必须先问清楚测的是哪一层代码能力。

1.3 为什么不能只看榜单第一

厂商通常会选择展示表现较好的指标，这本身并不奇怪，但容易让读者把局部最优误读成整体最优。一个模型在数学推理上领先，不代表它在中文抽取、长文档处理或工具调用上同样领先；一次离线评测中的高分，也不保证在高并发、长上下文和复杂异常下稳定运行。

因此，Benchmark 更适合作为筛选器和门槛，而不是最终排名。模型选型至少需要同时看以下三个层面：

能力是否覆盖任务要求，例如知识、推理、代码或中文理解。
过程是否能够稳定完成，包括工具调用、重试、校验和异常处理。
结果是否值得付出对应成本，包括 Token、工具调用、延迟和人工复核时间。

这也是从"模型评测"走向"系统评测"的关键一步：不再只测模型回答得对不对，还要测它能不能把任务完整、稳定、经济地做完。

2. 从单一模型到分层模型系统

2.1 "哪个模型最强"不是完整问题

传统的模型使用方式很直观：用户输入一个问题，模型返回一段回答。于是选型自然变成了"哪个模型最强"。但当模型进入生产环境后，任务之间的差异会被放大：有的请求每秒产生数千条，有的请求只需要固定字段抽取，有的请求需要同时阅读多份材料并处理矛盾信息。

让所有请求都走最强模型，会带来不必要的成本和延迟；让所有请求都走最快模型，又可能在复杂任务上牺牲质量。更合理的问题是：这个任务值得使用哪一档能力？

以 Sol、Terra 和 Luna 三个能力层级为例，可以把它们理解为一个面向任务的模型梯度，而不是简单的品牌命名：

层级	定位	适合任务	主要取舍
`Sol`	最强推理与复杂协作	多材料交叉分析、需求不清晰、需要反复调用工具并复核的任务	质量和复杂问题处理能力高，但成本、延迟更高
`Terra`	日常工作的均衡档位	文档初稿、普通代码、数据整理和常规分析	在质量、速度和成本之间取得平衡
`Luna`	快速、低成本、高频调用	分类、固定字段提取、批量预处理和简单路由	适合规模化处理，但不应承担高不确定性任务

这里最重要的不是记住三个名字，而是理解能力分层的设计思想：把模型当成一组具有不同成本和能力曲线的执行单元，让任务难度决定资源配置。

2.2 任务路由：把选择逻辑前置

在一个可落地的系统里，模型选择不应该每次都由开发者手动决定，而应该成为流程中的一个路由环节。路由器可以依据任务类型、输入规模、风险等级和失败代价，给请求分配合适的模型。

javascript 复制代码

// 路由的目标不是猜测"谁最聪明"，而是估计任务所需的能力档位。
function chooseModel(task) {
  if (task.isHighRisk || task.needsCrossDocumentReasoning) {
    return "Sol";
  }

  if (task.isHighVolume || task.outputSchema === "fixed-fields") {
    return "Luna";
  }

  return "Terra";
}

const model = chooseModel({
  isHighRisk: false,
  needsCrossDocumentReasoning: false,
  isHighVolume: true,
  outputSchema: "fixed-fields"
});

console.log(model); // Luna

这段代码虽然简单，却揭示了工程化路由的基本结构：先把任务特征结构化，再根据规则分配能力档位。生产环境中还可以加入失败升级策略，例如 Luna 输出无法通过格式校验时升级到 Terra，连续发现证据冲突时再交给 Sol。这样做的价值在于：大部分简单请求保持低成本，少量高难请求才消耗高级能力。

2.3 模型分层不等于质量分层

低成本模型并不是"没有用的弱模型"，它在边界清晰、格式固定、容错空间较大的任务上可能是最合适的选择。反过来，最强模型也不应被默认用于所有任务，因为更强的推理能力并不能消除输入噪声、错误工具结果或缺少业务约束等问题。

实际系统应该把模型能力与任务风险绑定，而不是与模型名绑定。一个常见的决策表如下：

任务特征	推荐策略	原因
输入量大、输出格式固定	低成本模型批量处理	规模与速度比复杂推理更重要
需要常规表达或整理	均衡模型完成	能力足够且成本可控
需求模糊、材料互相矛盾	强推理模型分析并复核	需要澄清、比较和多步判断
结果会影响高风险决策	强模型 + 规则校验 + 人工确认	单一模型输出不能作为充分保障

3. 工具协作：从回答问题到推进任务

3.1 一次工具调用的局限

模型本身只能处理上下文中的信息。如果需要查询数据库、浏览网页、读取文件或执行计算，就必须借助工具。最基础的流程是：模型判断需要工具，调用一次，拿到结果，再生成回答。

这种方式适合简单查询，但复杂任务往往不是"查一次就结束"。以行业研究为例，完整工作通常包括寻找资料、判断来源、整理数据、发现矛盾、补充查证、搭建结构，最后才是写结论。单次调用工具只能解决一个局部动作，下一步仍需要人工决定，整个流程很容易停在"模型给了一个答案"而不是"任务已经完成"。

3.2 可编程工具调用的核心价值

更强的工具协作能力，意味着模型不只会发起一次工具请求，还可以在工具结果返回后执行轻量程序，对中间数据进行过滤、排序、聚合或格式转换，再决定下一步行动。

javascript 复制代码

async function researchTopic(topic, tools) {
  // 第一步先获取多来源材料；并行调用可以减少等待时间。
  const sources = await Promise.all([
    tools.search({ query: topic, source: "official" }),
    tools.search({ query: topic, source: "academic" })
  ]);

  // 中间程序先去重和过滤无关内容，避免把所有噪声塞回模型上下文。
  const candidates = sources
    .flat()
    .filter(item => item.relevance >= 0.7)
    .filter((item, index, all) =>
      all.findIndex(other => other.url === item.url) === index
    );

  // 模型再基于清洗后的证据判断是否需要补查，而不是盲目继续搜索。
  const review = await tools.reason({
    topic,
    evidence: candidates,
    instruction: "找出证据冲突，并只返回需要补查的问题"
  });

  if (review.followUpQuestions.length > 0) {
    return tools.search({ query: review.followUpQuestions[0] });
  }

  return candidates;
}

这个例子展示了三个关键变化：

工具结果可以被程序化处理，模型不必直接面对全部原始数据。
模型可以根据中间结果决定下一步，流程不再局限于固定的单轮调用。
每一步都能留下可检查的中间状态，便于定位失败原因和控制风险。

需要特别区分两个概念：会调用工具，不等于可以放心运行。 工具调用的稳定性还取决于权限边界、参数校验、超时重试、结果可信度、日志记录和人工兜底。真正可靠的 Agent 不是"让模型自由操作一切"，而是让模型在清晰的工具契约与可观测流程中行动。

3.3 ReAct 与工作流式 Agent

传统 AI 更像一个问答顾问：用户问一步，模型答一步。Agent 则更接近一个协作者：理解目标、拆解任务、调用工具、观察结果、检查中间结论，并在必要时修正路径。这类"思考---行动---观察"的循环常被概括为 ReAct。

一个简化的执行循环如下：

text 复制代码

用户目标
  ↓
任务拆解：需要哪些子任务？
  ↓
选择动作：直接回答，还是调用工具？
  ↓
执行工具并取得结果
  ↓
检查结果：是否完整、可信、存在冲突？
  ├─ 否 → 补查、重试或升级模型
  └─ 是 → 汇总证据并生成结果

与自由度很高的"全自动代理"相比，工作流式 Agent 通常更适合生产环境。它可以把关键节点固定下来，把模型擅长的判断放在节点内部，同时用程序控制权限、循环次数和输出格式。

4. 真正应该核算的是总成本

4.1 API 账单只是成本的一部分

模型成本最容易被看到的是输入和输出 Token 账单，但完整任务的经济性不能只看这一项。一个看似便宜的模型，如果经常答错、反复重试或需要人工返工，最终成本可能高于一次完成任务的强模型。

可以用下面的方式建立更完整的成本模型：

AI 实际成本 = LLM API Token 账单 + 多轮提示词成本 + 工具调用成本 + 返工成本 + 人工检查时间 + 流程等待成本。

其中，人工检查时间尤其容易被忽略。对于合同字段提取、行业研究和代码修改等任务，结果是否需要人工复核、复核一次需要多久，往往比单次调用价格更能决定系统是否值得上线。

4.2 用"单位任务成本"替代"单次调用价格"

工程团队可以把成本核算单位从一次请求改成一次完整任务。例如，不问"这次调用花了多少钱"，而问"成功产出一份合格报告平均花了多少钱"。

成本项	需要记录的指标	常见优化方式
Token	输入、输出和上下文重复量	压缩上下文、只传递必要中间结果
工具	调用次数、失败次数、等待时间	缓存、并行调用、限制循环次数
返工	重试率、升级率、人工修改比例	增加结构化校验和更清晰的工具契约
人工	每个任务的复核分钟数	只让人工处理高风险或低置信度结果
稳定性	成功率、超时率和异常类型	超时、重试、降级与可观测性建设

因此，模型评测和成本评测应该放在同一张表里：质量不够，任务无法通过；质量过剩，成本和延迟又可能失去竞争力。最优解不是"永远选最强"，而是让每一类任务达到满足质量门槛的最低成本。

5. 把模型能力接入真实工作流

5.1 从"回答质量"升级为"流程完成质量"

当模型参与代码、浏览、计算机操作、文档、表格和演示等工作时，用户需要的已经不是一段孤立文本，而是一个能被使用、检查和交付的结果。例如，研究任务的交付物可能包含来源、数据表、冲突说明和报告初稿；代码任务的交付物可能包含修改、测试结果和剩余风险。

这要求系统同时管理两类状态：任务状态 与证据状态。任务状态回答"做到哪一步了"，证据状态回答"这个结论凭什么成立"。只有二者都可追踪，自动化结果才更容易被信任。

5.2 一个可落地的四层架构

可以把面向生产的模型系统拆成四层：

任务层：识别目标、输入、输出格式、风险等级和成功标准。
路由层 ：依据任务特征选择 Luna、Terra 或 Sol，必要时动态升级。
执行层：调用搜索、文件、代码、数据库等工具，并对中间结果做程序化处理。
控制层：负责权限、校验、重试、日志、人工确认和成本统计。

这四层的关系可以概括为：任务层决定"要做什么"，路由层决定"谁来做"，执行层负责"怎么做"，控制层保证"做得可控"。模型越深入业务流程，控制层的重要性越高。

5.3 设计 Agent 时的实用检查清单

在上线一个自动化流程前，建议至少确认以下问题：

检查方向	关键问题
任务边界	什么情况下可以自动完成，什么情况下必须交给人工？
模型路由	简单任务是否会误用高成本模型？复杂任务是否有升级路径？
工具权限	模型能读取和修改哪些资源？是否遵循最小权限原则？
结果校验	输出格式、事实依据和关键数值如何验证？
失败恢复	工具超时、结果为空或证据冲突时如何处理？
可观测性	能否看到每次调用、每个中间结果和最终成本？

这些问题决定了系统能否从演示走向生产。一个模型的"智能"只能提供上限，流程设计、工具契约和控制机制才决定实际下限。

总结

Benchmark 是认识大模型能力的基础工具，能够帮助我们比较知识、推理、代码、数学和中文理解等维度，但它更像准入门槛，而不是生产力排行榜。模型进入业务后，应围绕任务难度、调用频率、风险与成本进行分层：低成本模型处理边界清晰的高频工作，均衡模型承担日常任务，强推理模型处理不确定性高、需要多步协作和复核的任务。Agent 的价值也不只是生成回答，而是借助工具、轻量程序和检查环节推进完整流程。最终应以完成一个合格任务的总成本衡量系统，把 Token、工具调用、返工、人工复核和等待时间纳入评估，才能将模型真正接入可观测、可控制、可核算的生产工作流。