从演示到跑分：如何理性评估新一代大模型

每当头部大模型迎来代际更新，舆论场总会分裂成两种声音：一种被演示视频点燃，宣布“AGI 已来”；另一种盯着跑分截图，质疑“又是营销”。热闹看完，工程师真正该做的是认真算三笔账：能力的成色、评测的可信度、产业投入的量级。本文不绑定任何具体产品，而是把这三笔账抽象成一套可复用的评估方法论，帮助开发者和企业用户在下一轮模型发布潮中保持清醒。

一、第一笔账：能力成色——从“会说”到“会做”的鸿沟

1. 一个典型的错位场景

你让智能体帮你订一个网球场，它没有去查场地、比时段、完成下单，而是端出一篇《订场地的五种方法》的说明文。这就是“生成式回答”与“任务式执行”的错位：模型把“办成一件事”理解成了“写一篇关于这件事的文章”。

2. 错位背后的技术原因

• 训练目标不同：对话模型优化的是“回答得好不好”，智能体优化的是“任务办没办成”，两者的奖励信号完全不同；
• 能力栈不同：真实的任务执行需要任务分解、工具调用、环境感知、异常恢复、结果校验五层能力，任何一层缺失，模型都会退化成“只动嘴、不动手”；
• 反馈成本不同：写作质量难以自动判分，任务成败却有明确的终止条件。这决定了智能体训练必须依赖大量环境交互，而评测环境的搭建成本远高于文本数据。

3. 衡量成色的两个硬指标

从近期的公开演示看，新一代模型在同类计算机操作任务上的耗时，已经能压缩到上一代的一半左右（约75分钟降到40分钟），并且支持长时间无人值守运行。这两个指标比任何演示视频都更有分量：

• 任务耗时：反映模型的规划效率与试错成本，直接决定它能不能进入生产流程；
• 无人值守时长：反映长程任务中的错误率。没有人能盯着模型跑一小时，“不用盯”三个字，才是智能体从玩具变成工具的分界线。

因此，评估智能体能力时不要问“答得漂不漂亮”，要问四件事：办没办成、花了多久、干预了几次、花了多少钱。

二、第二笔账：跑分成色——换个考场，可以差37分

1. 现象：同一个模型，两份成绩单

某新一代旗舰模型发布时，官方展示了一项专门考察“玩没见过的游戏、边玩边学”能力的测试：它拿了99.9%，上一代只有7.8%，进步幅度惊人。但第三方评测方用标准环境重考，同一天、同一个模型，只得到62.7%。同一个“学生”，换个“考场”，差了37分。

2. 分差背后的三个技术成因

• 评测环境特异性：官方环境与模型的训练分布、内部工具链更接近，相当于“在自己熟悉的考场考试”；
• 对评测的过拟合：针对评测任务做定向优化，可以把单项分数刷得很高，但泛化到陌生环境立即回落——这说明模型学到的是“这套环境的解法”，而不是“通用的学习策略”；
• 自评与第三方的动机差异：当裁判和选手是同一方时，成绩天然需要打折扣。

3. 读懂跑分的四步法

• 看考卷：样本量够不够大（该测试“历史考生不多”）、任务分布是否覆盖真实场景、是否容易被数据污染；
• 看考场：环境由谁搭建、是否公开可复现、换环境后分数掉多少；
• 看综合榜：单项分数容易被定向优化，多任务加权的第三方综合指数更有参考价值。某第三方智能指数由9项子测试合成，该新模型排第四，前三被另一家包揽，而且它只比自家上一代高0.3分——单代进步在综合维度上其实相当有限，而紧追在后的已是一批后发追赶的模型团队；
• 看斜率：单点分数意义有限，多代模型的进步斜率才能说明团队的真实迭代速度。

4. 自建评测的代码骨架

与其争论榜单，不如自己搭一条可复现的评测管线：

# 伪代码：可复现的智能体评测骨架
WEIGHTS = {"success": 0.5, "speed": 0.2, "autonomy": 0.2, "cost": 0.1}
def evaluate(model, tasks, sandbox):
    records = []
    for task in tasks:                            # 任务抽样自真实业务
        trace = sandbox.run(
            agent=model,
            goal=task["goal"],
            tools=task["tools"],
            seed=42,                              # 固定随机种子，保证可复现
        )
        records.append({
            "task": task["id"],
            "success": checker.verify(trace, task["expect"]),  # 办没办成
            "seconds": trace.elapsed,                          # 花了多久
            "interventions": trace.human_steps,                # 干预几次
            "tokens": trace.token_usage,                       # 花了多少钱
        })
    return weighted_score(records, WEIGHTS)       # 合成"可用性分"

关键不在代码本身，而在三条纪律：任务来自真实业务、环境统一且固定、指标多维且加权。

三、第三笔账：追赶距离与产业投入

1. 头部在收敛

综合榜前几名的分差已经缩小到零点几分。这意味着单纯的“代际壁垒”正在变薄，竞争的分水岭从单点能力转向数据闭环、工程效率与生态位。对企业选型而言，“第一名比第二名强0.3分”在真实业务里几乎不可感知，真正该比较的是各候选模型在你自己业务场景上的表现。

2. 前沿是资本密集游戏

有头部团队为下一阶段训练筹措了数百亿美元量级的银团贷款。前沿模型的入场券以百亿美元计，算力、能源、数据成为新的基础设施，头部集中度会进一步提高。对中下游开发者反而是好消息：随着推理规模上量，单位智能的成本会沿规模化曲线持续下降，“用得起”的问题会先于“用得好”被解决。

3. 对架构设计的启示

模型能力会快速“通货膨胀”：今天需要精心编排才能完成的任务，明年可能一个提示词就能解决。因此不要把系统架构锚定在某一代模型的能力上限上，而应通过统一模型接入层、提示词版本管理、评测回归三件套，保持底层模型可替换——模型升级应该是“换引擎”，而不是“重建整车”。

四、落地实践清单

把“看热闹”变成“看门道”，可以落地为五条工程实践：

1. 自建评测集：从真实业务中抽取任务，覆盖高频路径与长尾路径，规模不必大，但必须代表真实分布；
2. 统一评测环境：固定沙箱、固定提示词版本、固定解码参数，否则任何分数都不可比；
3. 多维指标：成功率之外，同步记录耗时、人工干预次数、token 成本，合成“可用性分”而非“能力分”；
4. 回归评测：新模型发布后先跑回归，对比线上灰度表现，再决定是否切换与放量；
5. 善用云上工具链：评测数据与运行日志放对象存储，评测任务交给容器平台并行调度，异常通过监控告警兜底。以百度智能云为代表的云平台普遍提供模型服务、日志服务、监控告警等通用能力，可以把评测与推理管线一体化地搭在云上，避免重复自建基础设施。

五、结语

演示是宣传，跑分是参考，任务完成率才是生产力的度量衡。“AGI 时代”是否已经到来可以争论，但工程师的评估纪律不能缺席：面对任何一代新模型，先问“办没办成”，再问“考了多少分”，最后问“花了多少钱”。三问之后还能站住的模型，才值得进入你的生产环境。