大模型发布后如何看懂能力变化：从任务评测到智能体落地

一、综合分数持平，能力仍可能明显变化

综合智力分数是多项子任务的加权平均。平均值会把不同类型的能力压缩成一个数字。两个模型总分接近，可能是因为一方在知识问答上略强，另一方在长流程执行上明显更好，两者相互抵消。

因此，遇到“分数没有提升”或“分数大幅提高”这类结论，应先问三件事：测了哪些任务，任务的对错如何判定，测试条件与自己的业务是否接近。工程团队选型时，通常更关心某一类具体任务的表现，总分只能作为粗略参考。

二、把“智能”拆成可度量的能力维度

通用能力可以拆解为以下几个维度，每个维度对应不同的业务风险。

能力维度	典型任务	主要指标	常见陷阱
信息理解与问答	文档摘要、事实核对	准确率、引用可追溯性	回答流畅但事实有误
逻辑推理与计算	多步推导、数值计算	最终答案正确率、中间步骤可验证性	推导过程看似合理，结论错误
代码理解与修改	修复缺陷、补充功能	测试通过率、接口兼容性	只改动表面，破坏已有逻辑
工具调用	选择接口、构造参数、处理报错	参数合法率、错误恢复率	对错误返回视而不见，反复重试
长流程自动化	跨步骤、跨系统完成目标	端到端成功率、人工介入次数	前期小错误在后续步骤放大
环境交互	命令行、浏览器、桌面操作	操作完成率、误操作次数	对界面状态判断错误
稳定性与安全边界	指令冲突、输入含恶意内容	规则遵守率、越权次数	把外部文本当作指令执行

拆解之后，团队可以针对自己最常用的两三个维度建立评测集，而不是依赖一个笼统的排名。

三、自动化任务为什么难测，以及怎样测

自动化任务的结果体现在状态变化上。以“把一批日志按规则归档并生成统计报告”为例，判断成功需要检查文件是否存在、内容是否正确、是否误删了其他文件。只看模型的文字回复，会高估它的执行能力。

评估时建议区分三层指标。

1. 任务成功率：端到端目标是否达成，由脚本检查最终状态，而不是由模型自我声明。
2. 步骤质量：关键步骤是否合理，例如参数是否合法、是否重复执行了危险操作、是否在出错后正确回退。
3. 效率与成本：平均调用次数、耗时、token 消耗和人工介入次数。

下面是一个评测框架的骨架，演示如何在隔离环境中运行用例，并依据最终状态判定结果。

from dataclasses import dataclass
from typing import Callable
@dataclass
class TaskCase:
    case_id: str
    instruction: str
    setup: Callable      # 向沙箱写入初始数据
    verify: Callable     # 根据最终状态判定是否成功
    max_steps: int = 20
def run_case(agent, case: TaskCase, sandbox) -> dict:
    case.setup(sandbox)
    trace = []
    for _ in range(case.max_steps):
        # 观察结果只作为数据传给模型，模型输出视为待校验的建议
        action = agent.next_action(case.instruction, sandbox.observe(), trace)
        if action.type == "finish":
            break
        result = sandbox.execute(action)   # 沙箱内执行，权限受限
        trace.append({"action": action, "result": result})
    return {
        "case_id": case.case_id,
        "passed": case.verify(sandbox),
        "steps": len(trace),
        "trace": trace,          # 用于事后分析步骤质量
    }

框架只是起点，还需要注意下面几点。

• 随机性：同一用例多次运行，记录成功率的分布，而不是只看一次结果。
• 评测集泄漏：用于评测的任务不应出现在模型的训练或提示词示例中，否则分数会虚高。
• 环境差异：沙箱的网络、文件系统和权限应尽量接近生产环境，并记录差异。
• 用例覆盖：除了正常流程，还要包含异常返回、超时、字段缺失和权限不足等边缘情况。

四、从评测到落地：智能体系统的工程要点

模型能力只是系统的一部分。智能体进入生产环境后，可靠性更多取决于外围的工程设计。以下五条原则适用于大多数场景。

1. 权限最小化：只为任务分配必要的工具，读操作与写操作分开授权。
2. 高风险操作需要确认：删除数据、付款、对外发送消息、修改权限等动作，必须经过人工确认或独立的策略校验。
3. 完整可观测：记录每一步的输入、工具调用参数、返回结果和决策依据，便于复盘。
4. 可回滚：修改文件或数据库前先备份，或使用事务机制，保证失败时能恢复到已知状态。
5. 失败降级：超过步数上限或连续失败时，转交人工处理，而不是让系统反复尝试。

其中第二条最容易被忽视。安全判断应放在模型之外，由确定性的规则完成。下面的策略闸门示例说明了这一思路。

HIGH_RISK_ACTIONS = {
    "delete_file",
    "send_message",
    "change_permission",
    "transfer_funds",
}
def policy_gate(action, approver) -> dict:
    if action.name in HIGH_RISK_ACTIONS:
        if not approver.confirm(action):
            return {"status": "rejected", "reason": "未获得人工确认"}
    return {"status": "allowed"}

这段代码的要点在于，模型提出的动作只是建议。是否执行由独立的规则和人工决定。外部网页、文档和工具返回的内容同样属于数据，不能直接当作指令，否则很容易被注入恶意文本操控。

五、如何审慎看待“通用智能”类宣传

讨论人工智能时，“通用智能”常被用作宣传词，但它缺少统一的操作性定义。不同机构对能力边界的理解不同，因此一句“可能接近通用智能”很难被验证。

单项基准的高分说明模型在特定题型或环境中表现良好，不能直接推出它在其他场景同样可靠。基准题型与真实业务的分布往往存在差距，任务的步骤长度、工具种类和错误代价都可能不同。

面对厂商公布的数据，可以按下面的清单判断。

• 是否公开了测试集的版本和获取方式。
• 是否说明运行次数、方差或置信区间。
• 是否描述了提示词、工具配置和推理参数等测试条件。
• 是否有独立第三方复测结果。
• 是否报告了失败案例和典型错误类型。

缺少其中多数信息的数据，只能作为线索，不适合作为选型依据。

六、团队落地的检查清单

以下步骤可以帮助团队把评估从一次性的讨论变成持续的流程。

• 建立与业务相关的内部评测集，覆盖常见流程和边缘情况，并定期更新。
• 固定评测条件，记录模型版本、提示词、工具配置和随机种子。
• 同时比较任务质量、响应延迟和调用成本，三者需要放在同一张表里权衡。
• 为安全相关用例（越权访问、指令注入、误删数据）设置红线，未通过的版本不得上线。
• 采用小流量灰度发布，观察真实任务的成功率和人工介入率，再决定是否扩大范围。

按照这套流程，团队可以用自己的数据回答“新模型是否更适合我们”这个问题，而不必依赖发布会上的单一分数。