从跑分到执行：如何评估下一代旗舰大模型

近几年，大模型的迭代周期持续缩短。每当新一代旗舰模型出现，外界往往首先关注参数规模、上下文长度、基准测试排名以及输入输出价格。然而，对开发者和企业用户而言，真正重要的问题并不是“模型在排行榜上领先多少”，而是它能否稳定地完成真实工作，并在成本、安全和可治理性方面达到生产环境要求。

因此，评价下一代旗舰大模型，需要从“对话能力测试”转向“端到端任务能力评估”。模型不仅要理解问题、生成答案，还要能够拆解目标、调用工具、操作软件、验证结果，并在遇到异常后主动修正执行路径。

一、旗舰模型的竞争重心正在发生变化

早期大模型的能力主要体现在文本生成、知识问答和内容总结上。随着模型基础能力逐渐接近，单纯扩大参数规模带来的边际收益正在下降。新一阶段的竞争重点，开始集中在以下几个方向。

1. 从回答问题转向完成任务

回答“如何制作一份经营分析报告”，与真正读取数据、清洗异常值、生成图表、填写报告模板并完成校验，是两种完全不同的能力。

前者主要依赖语言理解和知识生成；后者则要求模型具备完整的任务执行链路：

1. 理解用户最终目标；
2. 将复杂目标拆分为多个步骤；
3. 判断每一步需要使用什么工具；
4. 获取并处理外部数据；
5. 根据执行结果调整后续计划；
6. 检查最终产物是否满足约束；
7. 在失败时定位原因并重新执行。

这意味着，未来模型的价值不再只取决于“会不会说”，而取决于“能不能做完”。

2. 从静态推理转向动态环境交互

传统基准测试通常提供清晰的问题、确定的输入和唯一或有限的答案。但真实工作环境具有更强的不确定性，例如：

• 页面结构可能发生变化；
• 文件格式可能不一致；
• 软件操作可能返回异常；
• 网络请求可能超时；
• 数据字段可能缺失；
• 用户需求可能存在歧义；
• 中间结果可能与预期不符。

真正成熟的任务型模型，需要持续观察环境状态，并根据反馈修正行为。这种“观察—计划—执行—验证”的循环，比一次性生成答案更接近人类实际工作方式。

3. 从单模型能力转向系统工程能力

在生产环境中，模型通常不是独立运行的。它需要与知识库、数据库、对象存储、消息队列、日志服务、监控告警、权限系统及企业内部应用协同。

因此，最终体验由多个环节共同决定：

• 模型是否正确理解任务；
• 工具接口是否稳定；
• 权限配置是否合理；
• 执行环境是否隔离；
• 结果校验机制是否完善；
• 异常处理是否及时；
• 审计日志是否完整。

即使底层模型推理能力很强，如果系统集成和治理机制不足，也很难直接进入生产环境。

二、不能只看综合跑分

综合跑分可以帮助开发者快速了解模型的大致水平，但不能等同于真实业务效果。不同测试集关注的能力不同，其结果很容易受到题目分布、提示方式、采样参数和评分规则影响。

1. 跑分高不代表任务成功率高

某些测试主要衡量数学、代码、知识和逻辑能力，输入通常结构清晰，输出也相对容易判定。然而，企业任务往往包含大量隐含约束。

例如，一项“整理销售数据并生成周报”的任务，可能同时要求：

• 不修改原始文件；
• 统一日期和金额格式；
• 去除重复记录；
• 标记异常增长数据；
• 按指定模板输出；
• 图表颜色符合规范；
• 报告中不得泄露敏感字段。

模型即使能够正确计算，也可能因为遗漏格式要求、误删数据或者输出位置错误而导致整个任务失败。

因此，评估时应重点测量“完整任务成功率”，而不是仅统计某一个步骤是否正确。

2. 应关注结果的稳定性而非最佳表现

同一个任务连续执行多次，模型可能得到不同结果。对生产系统来说，偶尔成功并不够，关键是能否稳定成功。

建议至少记录以下指标：

• 首次成功率：无需重试即可完成任务的比例；
• 最终成功率：允许有限次数重试后的成功比例；
• 结果一致性：多次执行的输出差异；
• 人工介入率：需要用户确认或纠错的任务比例；
• 错误恢复率：遇到异常后自主恢复的比例；
• 约束满足率：权限、格式、时限等要求的满足程度。

其中，最终成功率可以表示为：

最终成功率 = 成功完成的任务数 ÷ 总任务数

人工介入率则可用于判断模型究竟是自动化执行者，还是只提供操作建议的辅助工具。

3. 独立评测比厂商演示更有参考价值

演示通常展示经过筛选的理想场景，无法覆盖输入噪声、权限不足、文件损坏和工具异常等问题。开发者在选型时，应使用自身业务样本进行独立验证，并保存完整的输入、执行轨迹和最终结果。

特别需要避免仅凭少量案例得出结论。更合理的方式是建立分层测试集：

• 基础任务：单步、低风险、结果明确；
• 组合任务：跨文件、跨应用、多步骤；
• 异常任务：缺失字段、接口超时、格式错误；
• 高风险任务：涉及写入、删除、发布和权限变更；
• 长周期任务：需要持续执行数十分钟甚至更久。

三、“电脑操作能力”究竟包含什么

所谓电脑操作能力，并不只是识别屏幕并模拟点击。一个可用的执行型模型，至少需要具备感知、规划、操作、验证和恢复五个层次的能力。

1. 环境感知

模型需要理解当前界面状态，包括窗口、按钮、表格、表单、提示框和错误信息。对于混合界面，还可能需要结合视觉识别、文本解析和结构化页面信息。

环境感知的难点在于，界面并不总是稳定的。分辨率变化、弹窗遮挡、控件位置调整，都可能造成操作失败。因此，系统不能只依赖固定坐标，而应综合使用语义定位、结构定位和状态判断。

2. 任务规划

面对复杂目标，模型需要生成可执行计划。例如，将“完成一份项目预算分析”拆分为：

1. 读取预算文件；
2. 检查字段完整性；
3. 统一数据格式；
4. 计算预算执行偏差；
5. 标记超支项目；
6. 生成图表；
7. 填充报告模板；
8. 校验数据和结论；
9. 输出到指定目录。

计划不仅要覆盖正常流程，还应包含失败分支。例如，如果字段缺失，是终止任务、使用默认值，还是请求用户确认。

3. 工具调用与实际操作

模型可能通过结构化接口调用工具，也可能直接操作图形界面。前者稳定、可审计，适合企业系统；后者覆盖范围广，但更容易受到界面变化影响。

在条件允许时，应优先使用结构化接口。只有在目标软件没有开放接口，或者任务必须模拟人工操作时，才考虑图形界面自动化。

4. 结果验证

执行动作不等于任务完成。模型必须确认操作产生了预期结果。例如：

• 文件是否真正保存成功；
• 公式是否覆盖全部数据行；
• 图表是否引用了正确范围；
• 文档中的数字是否与数据源一致；
• 软件构建是否通过；
• 页面提交后是否收到成功状态。

缺少验证机制的智能体，很容易出现“看起来做了，实际上没有完成”的问题。

5. 错误恢复

真实环境中的失败不可避免。关键是系统能否识别失败类型，并采取合理策略。

常见恢复策略包括：

• 短暂故障采用有限次数重试；
• 输入格式错误时进行转换；
• 权限不足时停止并申请授权；
• 操作结果异常时回滚到上一步；
• 多次失败后转交人工处理；
• 保存执行现场，便于后续排查。

自动重试必须设置上限，否则模型可能陷入循环，持续消耗计算资源，甚至重复执行高风险操作。

四、长上下文并不等于无限记忆

上下文窗口不断扩大，使模型能够一次处理更多文档、代码和历史记录，但“能够放进去”与“能够准确使用”并不是一回事。

1. 长上下文的主要价值

较大的上下文容量适合以下任务：

• 分析大型代码仓库；
• 审阅多份合同和制度文件；
• 处理较长的会议记录；
• 对比跨年度业务数据；
• 保留长周期任务的执行轨迹；
• 综合多个来源生成报告。

它可以减少频繁切分材料造成的信息损失，也能降低检索结果缺少上下文的问题。

2. 长上下文的常见风险

随着输入长度增加，模型可能出现：

• 忽略位于中间位置的重要信息；
• 混淆不同文档中的相似实体；
• 引用已经失效的旧版本内容；
• 无法识别彼此冲突的指令；
• 推理延迟和调用成本上升。

因此，长上下文仍需配合文档分层、元数据标记、版本控制和关键信息摘要。不能把所有材料简单拼接后直接交给模型。

更稳妥的方式是先筛选相关信息，再构建结构化上下文，例如明确标记文档来源、时间、权限级别和版本号。

五、开发者应如何建立评估体系

企业不应使用单一排行榜决定模型选型，而应围绕自己的业务流程建立任务集。

1. 从真实业务中抽取测试任务

测试样本应来自日常工作，而不是临时编写的理想问题。可以从历史工单、标准流程、人工操作记录和异常案例中抽取任务，并进行必要的脱敏处理。

每个任务应明确：

• 输入材料；
• 预期输出；
• 必须满足的约束；
• 可使用的工具；
• 最大执行时间；
• 最大重试次数；
• 是否允许人工确认；
• 成功与失败的判定标准。

2. 同时衡量质量、成本和时延

生产系统的目标不是追求单项最高分，而是在可接受成本内获得稳定结果。单次任务总成本通常包括：

总成本 = 模型调用成本 + 工具执行成本 + 存储与网络成本 + 人工复核成本 + 失败重试成本

低价模型如果错误率较高，可能产生更多重试和人工校验，最终成本反而更高。反之，高能力模型也不应处理所有简单任务。

更合理的做法是进行分层调度：

• 简单分类、提取和格式转换使用轻量模型；
• 多步骤分析使用中等推理配置；
• 高风险、复杂决策任务使用更高推理配置；
• 涉及关键写入操作时增加人工审批。

3. 保存完整执行轨迹

对于任务型应用，日志不能只记录最终答案。至少应保存：

• 用户原始请求；
• 模型生成的计划；
• 每一步工具调用；
• 工具返回结果；
• 权限审批记录；
• 重试和错误信息；
• 最终产物；
• 用户修改和反馈。

这些数据既可用于故障排查，也可用于后续评估和优化。但日志中可能包含敏感信息，因此需要设置访问权限、脱敏规则和保留周期。

六、安全问题比模型能力更重要

当模型只能生成文本时，错误答案通常需要用户自行采纳才会产生影响；当模型获得文件写入、消息发送、程序执行或系统配置权限后，一个错误动作就可能直接造成损失。

1. 坚持最小权限原则

模型应只获得完成当前任务所需的最小权限。例如，只读分析任务不应拥有删除权限，生成草稿不应自动发布，测试环境权限也不应延伸到生产环境。

权限最好按任务动态发放，并在任务完成后自动回收。

2. 对高风险动作设置确认点

以下操作通常不应完全自动执行：

• 删除或覆盖文件；
• 批量修改业务数据；
• 对外发送消息；
• 发布公开内容；
• 修改访问权限；
• 执行资金相关操作；
• 变更生产环境配置。

系统可先让模型生成执行计划和变更摘要，再由用户确认。确认界面应清楚展示操作对象、影响范围和回滚方式，而不是只显示模糊的“是否继续”。

3. 防范间接指令攻击

模型读取网页、文档或邮件时，外部内容可能包含诱导性指令，例如要求忽略原任务、上传文件或泄露数据。系统必须区分用户指令与外部材料，不能把所有文本视为同等可信。

可采用以下措施：

• 对外部内容标记低信任级别；
• 禁止材料中的文本直接扩大权限；
• 工具调用前进行策略检查；
• 敏感数据默认不可外发；
• 高风险行为必须再次确认；
• 对输入和输出进行安全审计。

七、一个可控的任务执行框架

开发者可以将执行型应用设计为多个相互制约的模块，而不是让模型直接拥有全部权限。其逻辑可概括为：

接收任务
  ↓
解析目标与约束
  ↓
生成执行计划
  ↓
风险与权限检查
  ↓
在隔离环境中执行单步操作
  ↓
验证操作结果
  ↓
成功则继续，失败则重试、回滚或转人工
  ↓
生成结果与审计记录

对应的伪代码如下：

function runTask(task):
    plan = planner.create(task)
    for step in plan:
        risk = policy.evaluate(step)
        if risk requires approval:
            waitForHumanApproval(step)
        result = executor.runInSandbox(step)
        verified = verifier.check(step, result)
        if not verified:
            recovered = recovery.tryFix(step, result)
            if not recovered:
                audit.recordFailure(step, result)
                return handoffToHuman()
        audit.recordSuccess(step, result)
    return verifier.checkFinalOutput()

这一结构的重点不是具体实现语言，而是将规划、执行、验证、权限和审计相互分离。即使模型出现判断错误，策略层和验证层也能形成额外保护。

八、企业落地应采用渐进式路线

直接让模型接管完整业务流程，风险通常过高。更稳妥的方式是分阶段提升自动化程度。

第一阶段：只读辅助

模型仅用于搜索、总结、分析和生成建议，不允许写入业务系统。该阶段重点验证知识准确性、输出稳定性和数据安全。

第二阶段：生成草稿

模型可以生成表格、文档、代码或操作计划，但必须由人工审核后提交。该阶段可以评估内容质量和人工节省时间。

第三阶段：受控执行

模型获得有限工具权限，在隔离环境或低风险流程中执行任务。关键操作设置确认点，并保留完整日志。

第四阶段：条件自治

对于规则明确、风险较低、历史成功率较高的任务，可允许模型自动完成。系统仍需设置成本上限、重试上限、异常告警和人工接管机制。

第五阶段：持续评估

模型、提示策略、工具接口和业务数据都会变化，因此一次测试通过并不代表长期可靠。企业需要持续运行回归测试，并监控成功率、成本、时延和异常类型的变化。

九、如何理性看待下一代旗舰模型

下一代大模型值得关注的地方，不应只是参数更多、上下文更长或者榜单分数更高，而是它是否真正缩短了从“理解意图”到“交付结果”的距离。

对个人用户而言，更强的执行能力意味着模型可以协助处理表格、文档、网页和软件操作。对开发者而言，重点是工具调用稳定性、接口可控性和异常恢复能力。对企业而言，则必须同时考察数据安全、权限边界、审计能力、成本结构和持续运营风险。

可以用五个问题进行最终判断：

1. 它能否稳定完成真实任务，而非只在演示中成功？
2. 它能否解释执行计划，并接受权限约束？
3. 它能否发现错误、验证结果并主动恢复？
4. 它的综合成本是否低于现有人工或自动化方案？
5. 一旦发生异常，系统能否停止、回滚和追责？

真正有价值的旗舰模型，不一定在所有传统测试中遥遥领先，但应当在复杂任务中表现出更高的完成率、更低的人工介入率和更可靠的安全边界。大模型的竞争正在从“谁更会回答”进入“谁更能交付”的阶段，而决定其能否进入生产环境的，最终仍是可靠性、可控性与工程化能力。