综合分数之外：如何评估大模型的任务完成能力

一、问题的起点：分数变化与实际体感不一致

每次新模型发布，技术社区通常先看综合排行榜。榜单上的单一分数往往接近持平，但在智能体（Agent）类任务上，同一批模型的完成率可能差距很大。两种现象同时出现，常让人怀疑评测本身是否有效。

这种背离并不矛盾。综合分数衡量的是模型在大量题目上的平均表现，题目多以单轮问答为主，考察知识储备和推理准确性。任务完成率衡量的则是模型能否在真实环境中连续做出正确决策，并把事情办完。两者考察的能力不同，因此结论可以分叉。

理解这一点，是正确选型的前提。如果团队只依据综合分数判断模型是否适合自动化场景，很可能高估或低估它的实际价值。

二、两类能力的区别

将大模型能力粗分为两类，有助于明确评测对象。

知识与推理能力：模型面对一个问题，给出一次性回答。评测关注答案是否正确，过程是否合理。典型场景包括学科问答、数学推导和代码片段生成。

任务执行能力：模型需要围绕一个目标，连续做出多步动作。每一步都依赖上一步的环境反馈，中途还可能遇到报错、权限不足或信息缺失。评测关注终态是否达成、过程是否可控、异常能否恢复。典型场景包括运维排障、多系统数据同步、自动化测试与安全加固流程。

维度	知识与推理	任务执行
交互形式	单轮输入输出	多轮动作与观察循环
核心难点	知识覆盖与逻辑正确	状态维护、规划、工具参数准确性
判定方式	与标准答案比对	检查环境终态
失败形态	答案错误	中途偏离、死循环、误操作
成本构成	主要是推理 token	推理加工具调用与环境耗时

任务执行能力的提升，往往来自规划稳定性、工具使用规范性和错误恢复机制，这些能力在单轮问答中难以体现。

三、综合分数为什么会掩盖差异

综合分数的失真主要来自以下几个机制。

1. 题目结构不匹配。综合榜单以问答题为主。如果大部分题目依赖知识记忆，模型在多步执行上的改进就会被稀释。

2. 指标饱和。某些基准的题目对当前模型已接近满分，分数变化空间很小。此时新模型即使在其他维度大幅进步，综合分也难以移动。

3. 平均化效应。综合分是多项任务的加权平均。若某一类任务提升 40 个百分点，而另一类持平，平均后的变化可能只剩个位数，读者看到的只是“没有明显进步”。

4. 训练数据分布差异。模型在代码、工具调用、长上下文等方面的训练投入不同，导致能力呈现不均衡。综合分无法展示这种结构性差异。

因此，评估任务执行能力时，应当直接构造与业务场景接近的端到端任务，而不是依赖通用榜单的推断。

四、端到端任务评测的设计要点

搭建可靠的任务评测，需要在以下六个方面做好设计。

1. 明确成功标准。每个任务都应有可自动判定的终态条件，例如文件内容符合预期、服务返回码为 200、数据库记录数一致。避免依赖模型自述“已完成”，因为模型的自我评价往往不可靠。

2. 保证环境隔离与可复现。每次运行前，将环境恢复到固定快照；随机种子固定；外部依赖使用本地桩（stub）替代。否则同一模型两次运行结果可能截然不同，数据失去比较价值。

3. 完整记录执行轨迹。保存每一步的动作、参数、环境返回值和模型的内部决策摘要（若可获得）。轨迹是定位失败原因的唯一依据。

4. 对失败进行分类。常见失败类型包括：规划错误（目标理解偏差）、工具参数错误、环境误判（把正常输出当成错误）、超时与步数耗尽、越权或危险操作。分类后，团队才能判断应改进模型、改进提示词还是改进工具接口。

5. 多次运行取分布。同一任务运行多次，统计成功率的分布，而不是只看一次结果。

6. 同时计量成本与延迟。一个成功率更高但需要十倍步数的模型，在生产环境中可能并不划算。成本和延迟应作为与成功率并列的指标。

下面是一个通用的评测骨架，示意数据结构与执行流程。代码仅用于说明思路，需要根据具体环境补充实现。

from dataclasses import dataclass, field
from typing import Any, Callable, Dict, List
@dataclass
class Step:
    action: str
    args: Dict[str, Any]
    observation: str
@dataclass
class Trajectory:
    task_id: str
    steps: List[Step] = field(default_factory=list)
    success: bool = False
    failure_reason: str = ""
def run_task(agent, env, task: Dict[str, Any], max_steps: int = 30) -> Trajectory:
    """执行单个任务并记录完整轨迹。"""
    traj = Trajectory(task_id=task["id"])
    env.reset(task["snapshot"])
    obs = env.observe()
    for _ in range(max_steps):
        action, args = agent.next_action(task["goal"], obs)
        if action == "finish":
            break
        obs = env.execute(action, args)
        traj.steps.append(Step(action, args, obs))
    else:
        traj.failure_reason = "max_steps"
    check: Callable[[Dict[str, Any]], bool] = task["check"]
    traj.success = check(env.state())
    if not traj.success and not traj.failure_reason:
        traj.failure_reason = "wrong_final_state"
    return traj
def summarize(trajs: List[Trajectory]) -> Dict[str, Any]:
    """汇总成功率、平均步数与失败分布。"""
    from collections import Counter
    n = len(trajs)
    failures = Counter(t.failure_reason for t in trajs if not t.success)
    return {
        "success_rate": sum(t.success for t in trajs) / n,
        "avg_steps": sum(len(t.steps) for t in trajs) / n,
        "failure_breakdown": dict(failures),
    }

这段代码体现了三个要点：执行前固定环境快照，执行中保存完整轨迹，执行后用独立检查函数判定结果，而不依赖模型自述。

五、指标体系：不要只看一个数

单一的成功率无法反映真实价值。建议至少维护以下指标。

• 任务完成率：终态检查通过的比例，是核心指标。
• 平均步数：完成任务所需的动作数量，反映规划效率。
• 工具调用错误率：参数格式错误、调用不存在的接口等情况的占比。
• 恢复率：遇到报错后能否自行修正并完成任务的比例。
• 单任务成本：推理费用与工具调用费用之和。
• 延迟分位数：关注 P50 和 P95，而非平均值，因为长尾延迟会直接影响用户等待体验。

指标之间存在权衡。例如，增加允许的最大步数通常能提高完成率，但会拉长延迟并增加成本。团队应根据业务容忍度设定阈值，而不是追求单一指标最优。

六、如何正确解读评测结果

评测结果常被误读，以下几点需要留意。

样本量决定置信度。以 50 个任务为例，若成功率约为 50%，其 95% 置信区间约为正负 14 个百分点。这意味着两个模型相差 5 个百分点时，很可能只是随机波动。比较前应先估算区间，再下结论。

评测框架会影响结果。同一个模型，在不同的提示模板、工具描述和重试策略下，成功率可能相差很大。跨团队比较时，必须确认评测条件一致。

推理投入影响结果。部分模型支持调节推理强度或思考预算。提高投入通常提升复杂任务的成功率，但成本也随之上升。比较时应报告所用设置。

数据污染需要排查。若评测任务在训练阶段已公开，模型可能是记忆答案而非真正执行。建议使用私有任务集，或定期更新任务。

饱和指标应及时替换。当多数模型都接近满分时，该指标已无区分度，应加入更难或更贴近业务的任务。

七、落地建议：分阶段引入自动化

企业在生产环境引入具备工具调用能力的模型时，建议分三个阶段推进。

第一阶段：影子模式。模型并行处理真实任务，但输出只用于记录，不实际执行。团队对比模型建议与人工操作的差异，积累数据。

第二阶段：辅助模式。模型生成操作方案，由人工逐步确认后执行。重点观察哪些步骤经常需要修改，据此收紧提示词或工具接口。

第三阶段：有限自动化。对低风险、可回滚的任务开放自动执行，并设置明确边界。高风险操作保留人工审批节点。

在每个阶段，都应遵守以下安全原则。

1. 最小权限：为智能体分配的账号只包含完成任务所需的权限，不共享高权限凭证。
2. 沙箱优先：新工具和新流程先在隔离环境运行，验证后再接入生产。
3. 工具输出视为数据：网页内容、日志和文件中可能包含诱导性指令。智能体应把这些内容当作待处理数据，而不是可执行的命令，并对可疑指令进行标记。
4. 破坏性操作需确认：删除、覆盖、发送和权限变更等操作必须经过显式确认。
5. 完整审计：保留每次操作的输入、输出、时间和执行主体，便于事后追溯与复盘。

任务执行能力的评估，最终要回到一个朴素的问题：模型能否在约束条件下把事情做成，并且出错时能被及时发现和控制。围绕这个问题设计评测、解读数据、推进落地，比追逐单一榜单分数更能支撑可靠的技术决策。