AGI分数99.9%？官方复跑仅62.7%｜评测避坑

一家前沿实验室宣称，自家模型在 ARC-AGI-3 基准上拿到 99.9% 的分数，并据此宣布接近 AGI。同一模型，换用该基准自带的官方评测软件复跑，得分只有 62.7%。相差 37.2 个百分点，几乎全部来自模型外面的那层软件。这篇博客，4sapi（https://4sapi.com）把「分数 = 模型 + 脚手架」这笔账从头算一遍。

一、开篇痛点：照着厂商分数选型，上线就露馅

选型时最常见的动作，是打开厂商的 benchmark 榜单，挑分数最高的模型接入。等到真正上线，问题接踵而至：Agent 任务开始掉链子，工具调用顺序混乱，长上下文里的早期信息悄悄丢失，同一道任务今天能成、明天不能成。回头核对才发现，厂商公布的分是 99.9%，自己在生产环境复现出来的效果，连及格线都够呛。

问题不在模型突然变差，而在公布分数时的那套评测环境，与上线时的运行环境根本不是一回事。分数既属于模型，也属于环境；只盯着分数做选型，等于把两笔账混成一笔买，上线必然露馅。这个教训换到任何一家厂商身上都成立，只是这次 99.9% 对 62.7% 的差距，把问题放到了最大。

二、原理速览：基准分数 = 模型能力 + 工程脚手架 + 评测口径

把一次评测拆开看，最终分数由三层构成。

第一层是模型能力：权重里沉淀的知识、推理、指令跟随与格式遵从，这是模型自带的，换一个环境也不会变。

第二层是工程脚手架（scaffolding / harness）：跑评测时模型外面的全部软件。agent 循环、思维链提示词、重试与自我纠错、工具调用、中间结果回灌、反思回路、任务分解，全都属于这一层。脚手架不改模型的一个权重，却能成倍放大最终得分。

第三层是评测口径：谁来跑、怎么跑、用什么评分器、采几次样、取均值还是取最大值。同一模型，口径不同，数字可以完全不同。

所以基准分数 = 模型能力 + 工程脚手架 + 评测口径。三个变量只有全部固定，分数才具备横向对比的意义；任何一个变量在对比双方之间不一致，结果就不可比。这次事件里，模型是同一个，变的只有脚手架与口径，差距却有 37.2 个百分点，等于给「工程也能制造分数」做了一次公开演示。

三、99.9% 与 62.7%：差距到底从哪里来

ARC-AGI-3 是一组以抽象推理为主的题目，官方评测软件定义了标准的读题、解题、评分流程。实验室在官方流程之上，又自建了一套 agent 脚手架：模型先理解题目，再拆解步骤，遇到失败自动重试，把中间结果回灌给模型做二次推理，最后由统一评分器计分。这套脚手架等于给模型配了一位不知疲倦的助手，把单次生成做不出的题，用多轮尝试硬推出来。

官方评测软件不带任何附加逻辑：模型生成一次，评分一次，成了就是成了，败了就是败了。同一模型，一次生成的裸成绩是 62.7%，套上脚手架之后是 99.9%。中间差的 37.2 个百分点，是工程的成绩，不是模型权重的成绩。

把同样的道理搬到生产环境：厂商公布的高分，往往建立在专有脚手架之上，而大多数接入方拿到的只是一个裸 API。用裸 API 的产出去对照带脚手架的高分，天然吃亏。反过来，如果接入方自建了一套可靠的 agent 框架，那这套框架才是自己真正的竞争力，模型反而可以按需更换。

四、三种口径对照表

三行数字摆在一起，选型该拿哪一行，答案很清楚：横向对比厂商强弱，用官方评测口径；评估自己裸 API 接入后的真实效果，用裸模型口径；厂商自建脚手架那一行，只能当作「这套脚手架能做到什么程度」的参考，永远不能当作模型自身的分数。

五、请求流图示：一次自建评测的完整链路

自建评测脚本（固定任务集 + 固定采样参数）
        │ 相同 prompt、相同 temperature、相同 max_tokens
        ▼
API 网关（中转接入的标准 OpenAI 兼容接口）
        │ 路由、负载均衡、计费统计
        ▼
模型供应商后端（同一模型）
        │ 原始生成文本
        ▼
统一评分器（与官方评测软件同款逻辑）
        │
        ▼
可比分数 + token 成本记录（用于横向对比）

这条链路的关键在两端：输入端把任务和参数焊死，输出端用同一个评分器。中间换成哪家供应商、哪个模型，都不影响评测口径，分数因此可比。网关层顺手解决三件事：多供应商路由、负载均衡、以及把每次评测的 token 消耗记进计费统计。

六、方案：我的评测四件套

踩过几次坑之后，我固定了一套评测流程，四件东西缺一不可。

第一件，固定评测脚本。同一批任务、同一个评分器，脚本版本入库，改一版记一版。任务集不固定，分数就没有意义；评分器不固定，结果就对不上账。

第二件，固定脚手架。要么全部带 agent 循环，要么全部不带，绝不在对比时偷偷给某一方加戏。想测模型本身，就全部裸跑；想测方案效果，就把同一套脚手架套到所有候选模型上，一个都不能例外。

第三件，固定采样参数。temperature 固定为 0 或同一个值，max_tokens 固定，system prompt 一字不差，上下文长度固定。采样参数一旦浮动，同一个模型自己就能跑出好几个分数，对比直接失效。

第四件，固定指标。准确率、token 成本、端到端延迟、失败重试率，四个指标一起记。只看准确率，容易忽略成本翻倍才换来的 1 个百分点；只看成本，又可能选回一个准确率垫底的模型。

四件套的目的只有一个：把「模型」和「环境」两个变量彻底分开，让每一次对比都只动一个变量。

七、从评测结果到选型决策

两套口径都跑完之后，选型决策遵循三条规则。

规则一，能力排名看官方口径。同一评测环境下谁高谁低，官方口径的排名才是公平的，厂商自建口径的排名没有可比性。

规则二，生产水位看裸模型口径。接入方拿到的通常是裸 API，裸口径分数才接近上线后的真实表现；如果计划自建 agent 框架，就用「裸模型 + 自己的脚手架」再跑一遍，而不是直接引用厂商公布的 99.9%。

规则三，分数接近时看成本。两个模型官方口径相差不到 2 个百分点时，选 token 成本低、延迟稳的那一个。高出来的那点分数，如果要用几倍的成本去换，不值得。

三条规则合在一起，就是一个可复现、可审计的选型流程：先排名，再定水位，最后算性价比。

八、接入教程：Python 自建评测脚本 + 4sapi 配置

先把 API 通路搭起来。4sapi（https://4sapi.com）提供标准 OpenAI 兼容接口，申请 key 之后，base_url 指向 https://4sapi.com/v1 即可，业务代码一行不用改。

import openai

# 固定评测环境：同一模型、同一参数、同一批任务
client = openai.OpenAI(
    base_url="https://4sapi.com/v1",
    api_key="sk-xxxx",  # 换成在中转站控制台生成的 key
)

MODEL = "模型名称"      # 控制台可查，按供应商区分
TEMPERATURE = 0.0       # 固定采样参数，横向对比期间不许改
MAX_TOKENS = 2048
TASKS = []              # 固定任务集，例如 200 条 ARC 风格样例


def run_one(task, with_scaffold=False):
    """裸模型口径：单次生成；脚手架口径：重试 + 自我校验"""
    if not with_scaffold:
        resp = client.chat.completions.create(
            model=MODEL,
            messages=[{"role": "user", "content": task["question"]}],
            temperature=TEMPERATURE,
            max_tokens=MAX_TOKENS,
        )
        answer = resp.choices[0].message.content
        return answer, resp.usage.total_tokens

    # 脚手架口径：失败后把反馈回灌给模型，最多重试 3 轮
    messages = [{"role": "user", "content": task["question"]}]
    total_tokens = 0
    answer = ""
    for _ in range(3):
        resp = client.chat.completions.create(
            model=MODEL,
            messages=messages,
            temperature=TEMPERATURE,
            max_tokens=MAX_TOKENS,
        )
        total_tokens += resp.usage.total_tokens
        answer = resp.choices[0].message.content
        check = client.chat.completions.create(
            model=MODEL,
            messages=messages
            + [{"role": "assistant", "content": answer},
               {"role": "user", "content": task["verify"]}],
            temperature=TEMPERATURE,
            max_tokens=MAX_TOKENS,
        )
        total_tokens += check.usage.total_tokens
        if check.choices[0].message.content.strip() == "PASS":
            return answer, total_tokens
        messages.append({"role": "assistant", "content": answer})
        messages.append({"role": "user", "content": "上一轮结果不正确，重新求解。"})
    return answer, total_tokens


def evaluate(with_scaffold):
    correct = total_tokens = 0
    for task in TASKS:
        answer, tokens = run_one(task, with_scaffold)
        total_tokens += tokens
        correct += 1 if answer.strip() == task["answer"] else 0
    return correct / len(TASKS), total_tokens


if __name__ == "__main__":
    bare_score, bare_tokens = evaluate(False)
    scaffold_score, scaffold_tokens = evaluate(True)
    print(f"裸模型口径: {bare_score:.1%}, token 成本 {bare_tokens}")
    print(f"脚手架口径: {scaffold_score:.1%}, token 成本 {scaffold_tokens}")

跑完这个脚本，同一模型的两口径分数与 token 成本一目了然。之后把 MODEL 换成另一家模型重复执行，就能在完全相同的评测环境下做横向对比；把两个模型的两行输出并列，选型依据直接成形。

网关侧要做三件事：一是评测任务单独建一个 key，成本单独核算；二是确认模型路由到哪家供应商，评测期间不要改路由；三是开启用量统计，把每次评测的 token 消耗留档，事后对账有据可查。

九、成本与风险提示

自建评测不是免费的。带脚手架的跑法每次都要多次采样，token 消耗通常是裸跑的几倍；200 条任务的完整评测跑完，账单会在用量统计里看得清清楚楚。我的做法是把成本也当成一个指标：分数接近的两个模型，选 token 成本低的那一个；评测本身也控制采样轮次，够出结论就停。

风险有三类。

第一类是被厂商分数误导。把带脚手架的高分当成模型能力，选型从一开始就错了，上线后所有 Agent 指标都会低于预期。

第二类是只信单点分数。单次评测有方差，同一模型同一口径多跑几遍取均值，再下结论；单点分数的置信区间往往比想象中大得多。

第三类是过拟合基准。脚手架在 ARC 这类任务上有效，换到真实业务任务集上可能完全失效；所以评测任务集必须从真实业务场景里采样，而不是照搬公开基准。

合规方面只有一条底线：全程使用合法 API 接入，网关只做路由、负载均衡与计费优化，不提供任何违规代理方案。分数再高，也不能走灰色通路。

十、检查清单

• [ ] 评测脚本版本入库，任务集与评分器固定不变
• [ ] 裸模型口径与脚手架口径分开跑，结果分开记录
• [ ] temperature、max_tokens、system prompt 全部固定
• [ ] 准确率、token 成本、延迟、失败率四个指标一起记
• [ ] 横向对比时，所有候选模型共用同一评测环境
• [ ] 厂商分数只看官方评测口径，自建脚手架分数仅作参考
• [ ] 评测用独立 key，成本单独核算，用量统计留档
• [ ] 结论用多次采样均值，不采信单次分数
• [ ] 评测任务集来自真实业务场景，不照搬公开基准

十一、总结

这次事件的核心就一句话：基准分数 = 模型能力 + 工程脚手架，二者必须分开看。同一模型在厂商自建脚手架下拿到 99.9%，在官方评测软件下只有 62.7%，说明选型与横向对比时不能只看厂商公布的分数，必须复现同等的评测环境。我的解法是评测四件套：固定脚本、固定脚手架、固定参数、固定指标，再配合 4sapi（https://4sapi.com）的标准 OpenAI 兼容接口自建评测链路，把每一分 token 成本和每一个百分点都算明白，最终落到「先排名、再定水位、最后算性价比」的选型流程上。欢迎在评论区发表想法/聊聊。