从模型跑分到任务闭环：AGI能力如何被验证

近年来，人工智能模型的竞争重点正在发生变化。早期评测主要关注模型能否正确回答知识问答、数学推理和语言理解题目；而在更复杂的应用场景中，用户真正关心的往往不是模型能否给出一个漂亮答案，而是它能否理解目标、拆解任务、调用工具、处理异常，并最终交付可验证的结果。

这也是为什么某些新一代模型在综合智力评分上提升并不明显，却可能在自动化、科学研究、代码操作和长流程执行等任务中表现出明显进步。表面上看，模型似乎没有实现传统意义上的“全面碾压”；但从系统工程角度看，它的能力边界可能已经从“单轮问答系统”转向“可持续执行任务的智能代理”。

一、综合跑分为什么不能代表全部能力

综合评测通常会把数学、语言、常识、逻辑和知识问答等多个维度压缩成一个分数。这种方式便于横向比较，也适合观察模型在通用认知任务上的基本水平，但它存在三个局限。

第一，很多测试是静态的。模型只需要阅读题目、生成答案，任务完成过程通常不包含文件操作、外部检索、代码运行、环境配置和结果校验。现实工作却很少是“一问一答”，更多时候需要连续执行多个步骤。

第二，综合分数容易掩盖能力结构。一个模型可能在知识问答上提升明显，但在工具调用和长任务规划上变化不大；另一个模型可能在普通题目上差异有限，却能更稳定地完成复杂工程任务。两个模型的总分接近，并不意味着它们在实际使用中的价值相同。

第三，静态测试难以衡量失败恢复能力。真实任务中经常出现权限不足、输入格式异常、外部服务超时、代码运行报错和数据不完整等问题。高质量智能系统不应只在理想条件下给出正确答案，还要能够识别错误、调整策略并继续推进。

因此，综合智力分数更适合作为基础能力指标，而不能直接等同于系统级智能水平。

二、真正的跃迁可能发生在“任务闭环”

所谓任务闭环，可以概括为以下过程：

1. 理解目标与约束；
2. 将目标拆解为多个可执行步骤；
3. 选择合适的工具或数据源；
4. 执行操作并读取中间结果；
5. 根据结果调整后续计划；
6. 对最终产物进行验证；
7. 在失败时回滚、重试或请求人工介入。

传统语言模型通常擅长前两步，能够生成计划和文字说明，但不一定能稳定完成后续步骤。新一代系统的核心改进，可能就在于让模型具备更强的过程控制能力。

例如，用户要求生成一份数据分析报告时，模型不仅要写出分析结论，还需要确认数据文件是否完整，检查字段类型，执行统计计算，识别异常值，生成图表，并核对报告中的数字是否与原始数据一致。只要其中任何一步出错，最终结果就可能失去可信度。

从这个角度看，模型能力可以抽象成：

任务成功率
= 目标理解能力
× 规划能力
× 工具调用成功率
× 中间结果判断能力
× 错误恢复能力
× 最终验证能力

这并不是严格的数学公式，而是一个工程上的观察：任何一个环节过弱，都会显著降低最终任务完成率。

三、为什么自动化和长任务指标更值得关注

自动化评测通常不只检查答案，还会检查模型是否真正完成了操作。例如，模型可能需要修改配置文件、运行测试、定位错误、生成补丁，再通过自动化检查。此类任务更接近软件开发、数据处理和运营管理中的真实工作。

长任务执行尤其能体现模型的系统能力。短任务中，即使模型偶尔犯错，也可能凭借上下文重新纠正；但当任务持续几十步甚至更久时，模型必须长期保持目标一致性，避免偏离原始要求。

评估长任务时，至少应关注以下指标：

• 一次完成率：不依赖人工干预时，任务能否从头到尾完成；
• 步骤准确率：每个关键动作是否符合预期；
• 错误恢复率：出现异常后能否选择正确的修复路径；
• 上下文保持能力：执行较长流程后，是否仍能遵守最初约束；
• 结果可验证性：输出是否包含足够证据，能够被程序或人工复核；
• 资源使用效率：完成任务消耗的时间、调用次数和计算资源是否可接受。

这些指标比单纯的知识问答分数更接近企业实际收益。因为企业最终购买的不是一段文本，而是问题解决效率、流程自动化程度和交付质量。

四、科学推理与代码执行体现了不同层次的智能

科学任务和代码任务经常被放在一起讨论，但二者考察的能力并不完全相同。

科学推理强调假设构建、变量控制、证据解释和结论边界。模型需要区分已知事实、合理推断和未经验证的猜测，还要能够设计实验或提出可检验方案。

代码执行则更加重视精确性和反馈循环。一个看似合理的程序，只要存在语法错误、边界条件缺失或资源泄漏，就可能无法运行。因此，优秀的代码代理不能停留在生成代码，还要主动运行测试、读取报错、修改实现，并确认修复没有引入新的问题。

在企业环境中，建议把科学推理和代码执行拆成不同的测试集。例如：

• 给出一组实验数据，要求模型提出解释并说明证据；
• 给出不完整的程序，要求模型补全并通过测试；
• 让模型处理格式混乱的数据，观察其清洗策略；
• 让模型在受限权限环境中完成任务，检查安全边界；
• 给出错误日志，要求模型定位根因而非只提供表面修复。

通过这种方式，可以避免把“语言表达能力”误判为“工程执行能力”。

五、安全能力不能只看是否拒绝回答

安全评估也需要从单轮问答扩展到连续交互。一个系统即使能够拒绝明显危险请求，也不代表它在复杂环境中足够安全。

更可靠的安全测试应覆盖：

• 权限边界是否清晰；
• 是否会执行未经确认的高风险操作；
• 是否能够识别提示注入和恶意指令；
• 是否会泄露系统提示、凭证或内部数据；
• 是否能对外部内容进行可信度判断；
• 是否会在不确定时主动暂停并请求确认；
• 是否保留完整的操作日志和审计记录。

在代理系统中，安全控制不能全部依赖模型自身判断。更稳妥的方式是采用“模型决策 + 工具权限 + 策略网关 + 审计系统”的多层架构。

例如，删除数据、修改生产配置、发送外部消息等操作，应设置明确的权限等级。模型可以提出操作计划，但真正执行前还要经过规则检查，必要时要求人工确认。这样即使模型判断失误，也能将影响范围限制在可控范围内。

六、如何判断一个模型是否接近AGI

“AGI”目前仍缺乏统一、可操作的工程定义。如果只把它理解为“在所有考试中得分很高”，容易忽略真实任务中的关键能力。更合理的判断框架，应该同时考察以下维度：

1. 跨领域迁移

模型能否将一个领域中的推理方式迁移到新问题，而不是依赖固定模板。

2. 持续自主执行

模型能否在较少人工干预的情况下，完成多步骤、长周期任务。

3. 工具与环境适应

面对陌生接口、不同数据格式和新的操作环境，模型能否快速建立有效策略。

4. 自我校验与纠错

模型能否发现自己的错误，区分不确定性，并通过测试或证据进行验证。

5. 目标一致性

在任务持续时间变长、上下文不断增加时，模型能否始终遵守约束，不随意改变目标。

6. 安全与可控

模型能力增强后，是否仍然能够被授权、监控、暂停和审计。

只有当这些能力同时达到较高水平时，才有资格讨论其是否接近通用人工智能。单项成绩极高，或者某个演示效果惊艳，都不足以证明系统已经实现AGI。

七、企业应该如何设计自己的评测体系

企业在引入智能代理时，不应直接照搬公开榜单，而应建立与业务流程一致的评测集。具体可以分为四层。

第一层是基础能力，包括文本理解、结构化输出、数学计算和常识判断。

第二层是工具能力，包括文件读写、数据库查询、接口调用、代码执行和结果解析。

第三层是流程能力，包括任务拆解、跨步骤记忆、异常恢复、并发处理和人工协作。

第四层是生产能力，包括安全合规、成本控制、稳定性、可观测性和故障回滚。

测试数据最好来自真实业务中已经脱敏的历史任务，并明确成功标准。例如，不能只要求模型“生成报告”，而应检查报告是否引用了正确数据、计算是否准确、结论是否有证据、格式是否满足交付要求。

同时，还要记录失败样本。失败原因可以进一步分类为理解错误、计划错误、工具错误、权限错误、验证不足和安全拦截。只有建立这样的错误分类体系，团队才能知道究竟应该更换模型、优化提示、增加工具约束，还是重构整个流程。

结语：从“会回答”走向“能负责地完成”

新一代大模型的价值，正在从语言生成质量扩展到复杂任务的完成能力。综合跑分没有大幅上升，并不意味着模型没有发生代际变化；真正重要的是，它是否能够在开放环境中持续理解目标、规划行动、调用工具、处理异常并验证结果。

因此，判断模型是否接近AGI，不能只看一个总分，也不能只看一次演示。更可靠的方法，是观察它能否在不同领域、不同工具和不同约束下稳定完成任务，并且在能力增强的同时保持安全、透明和可控。

对于开发者和企业而言，未来的重点也不应只是寻找“回答最像人的模型”，而应构建完整的任务评测体系、权限体系、审计体系和人机协作机制。只有当模型的智能真正转化为可验证、可复用、可追责的工作成果时，AGI才不再只是一个概念，而会逐渐成为可以被工程化衡量的系统能力。