大模型竞争从跑分转向持续工作能力：企业评估智能体应增加哪些指标？

【软盟资讯·新闻导读】近期关于大模型落地和 AI 智能体评估的公开讨论，正在把关注点从单次问答准确率、基准跑分，转向智能体能否在真实业务中持续规划、调用工具、处理异常并完成任务闭环。中国信通院 2024 年《大模型落地路线图研究报告》将研发测试、效能评估、运维监测和运营管理纳入应用全生命周期；InfoQ 2026 年关于智能体实践评估的文章也指出，传统单轮指标难以覆盖规划、工具调用、记忆保持、故障恢复、成本与延时控制等生产问题。对企业而言，模型“答得好”只是起点，系统“做得成、跑得稳、管得住”才更接近实际价值。

从模型跑分转向任务闭环

过去，企业选型常参考模型在公开基准上的准确率、推理能力、代码能力或综合排名。这些指标仍然有价值，尤其适合做基础能力筛选，但它们回答的主要是“模型在标准题目上表现如何”，并不能直接回答“智能体能否完成一项真实工作”。

AI 智能体通常不是单一模型，而是由模型、提示词、记忆、知识库、工具或 API、业务规则和权限系统共同组成的复合系统。它可能需要拆解目标、制定步骤、调用多个工具、读取中间结果，并根据异常反馈调整计划。只要其中一个环节失效，最终任务就可能失败。

公开资料中的一个共同判断是：生产环境的智能体评估不能停留在单轮文本质量。规划逻辑脆弱、工具调用不可靠、跨会话记忆漂移、多轮行为不一致，以及面对接口错误时缺乏恢复能力，都是从演示走向业务应用时需要单独测试的问题。

因此，企业不应简单地把模型排名替换成另一个排名，而应建立与具体业务任务对应的评估框架。

企业首先要定义“完成”是什么

任务完成率是最核心的指标，但也是最容易被模糊处理的指标。企业需要先明确任务的成功标准，而不是只根据智能体是否生成了一段看似合理的文字来判断结果。

例如，在客户服务场景中，任务完成可能意味着：

• 正确识别客户问题；
• 查询到对应订单或账户信息；
• 按权限完成退款、改址或工单流转；
• 向客户给出符合规则的结果；
• 在系统中留下完整、可追溯的操作记录。

只有当关键步骤均满足要求，才应计为一次成功。若智能体回答正确，但没有完成系统操作，或者操作完成却遗漏审计记录，就不应与完整闭环等同。

企业可以把任务完成率拆成三层：

1. 最终成功率：任务是否达到业务目标。
2. 关键步骤成功率：规划、检索、工具调用、校验和提交等环节分别是否成功。
3. 无人工干预成功率：在预设权限和风险边界内，智能体是否能够自行完成任务。

这种拆解能够避免“最终结果看起来不错，却不知道中间出了什么问题”。

评估智能体持续工作的六类指标

1. 任务完成率与结果质量

任务完成率应基于真实业务样本或经过脱敏的历史任务集计算，并覆盖常见、边界和异常情况。对于开放式任务，还需要结合人工评审、规则校验或独立评判模型，判断结果是否准确、完整、合规。

不能只测平均完成率。企业还应关注不同任务类型之间的差异，例如简单查询与跨系统操作、标准流程与非标准请求、一次性任务与多轮任务之间，可能存在明显不同的表现。

2. 连续运行稳定性

智能体持续工作时，错误可能逐步累积。第一次工具调用的轻微偏差，可能在后续步骤中放大为错误决策。因此，企业需要测试：

• 多轮任务中的行为一致性；
• 长上下文下的关键信息保持能力；
• 长时间运行后的任务偏移；
• 工具返回异常时能否重试或改用替代路径；
• 任务中断后能否恢复，而不是从头开始；
• 重复执行是否产生重复写入或重复扣款。

这里的重点不是要求智能体永不出错，而是观察错误是否可发现、可隔离、可恢复。对企业来说，一个能够及时暂停并请求人工确认的系统，可能比一个偶尔给出“自信但错误”结果的系统更适合生产环境。

3. 工具调用的正确性

工具调用是 AI 智能体区别于普通聊天机器人的重要环节。评估不能只看“调用次数”，还要看调用是否正确。

建议记录工具选择准确率、参数准确率、调用顺序、权限遵循情况、失败重试次数和无效调用比例。比如，智能体是否选择了正确的查询接口，是否把客户编号和订单编号混淆，是否在得到不完整结果时错误地继续执行，是否越过审批流程直接执行高风险操作。

对于关键业务，工具调用应设置可验证的状态检查。凡是涉及付款、删除、发布、权限变更或对外发送的信息，都应要求系统在执行前后留下明确的状态证据。

4. 人工介入频率

人工介入不是单纯的负面指标。合理的人工接管可以降低风险，问题在于介入是否发生在正确的节点，以及企业是否知道介入的原因。

可以分别统计主动请求确认、异常升级、人工纠错和人工接管的比例，并记录每次介入对应的触发原因。若智能体在低风险任务中频繁请求人工确认，说明自动化效率不足；若在高风险任务中几乎不请求确认，则可能意味着风险控制不足。

更有价值的指标是“带有合理触发原因的人工介入率”，而不是片面追求零介入。

5. 单位任务成本与时延

模型调用费用只是单位任务成本的一部分。完整成本还应包括工具调用、检索、数据库访问、人工复核、失败重试、异常处理和运维监控等支出。

企业可以按照“每个成功任务”核算成本，而不是按照“每次调用”核算成本。例如，一个看似单次调用价格较低的方案，如果经常重复规划、反复调用工具或需要人工返工，最终单位成功任务成本可能更高。

同时应观察首个有效结果时延、任务总时长、P95 或 P99 等尾部时延，以及不同任务复杂度下的成本变化。对于内部知识问答，速度可能优先；对于财务审核或供应链操作，稳定性和可追溯性通常更重要。

6. 风险控制与可审计性

智能体进入企业流程后，安全指标不能作为附加项。需要评估其是否遵守身份权限、数据访问范围和业务规则，是否会泄露敏感信息，是否容易被提示注入或恶意输入误导，以及是否能够对关键决策提供过程记录。

风险控制至少应覆盖：

• 权限边界是否清晰；
• 高风险操作是否需要审批；
• 关键输入和输出是否可追踪；
• 异常行为能否告警和暂停；
• 任务日志是否足以支持复盘；
• 模型、提示词、工具和数据版本是否可回溯。

中国信通院相关报告将应用效能评估、运维监测和运营管理放在大模型落地的完整链路中，这说明评估并不是上线前的一次考试，而应成为持续运营的一部分。

把指标放进真实任务，而不是只测模型

企业可以采用“三层测试法”。

第一层是模型基础能力测试，包括知识理解、推理、代码、结构化输出和安全拒答。这一层适合做候选模型初筛。

第二层是智能体工作流测试，把真实业务拆成任务集，检查规划、记忆、工具调用、异常恢复和结果交付。测试样本既要包括正常路径，也要包括接口超时、数据缺失、权限不足和用户临时改变要求等情况。

第三层是受控生产测试，在限定人群、权限和业务范围内运行，持续记录任务完成率、人工介入、成本、时延、错误类型和风险事件。通过版本对比，判断系统升级是否真的带来业务改善。

评估方法也应组合使用：能用规则或代码验证的，就优先采用可重复的自动检查；开放式结果可以使用量规评分或独立评判模型；涉及高风险决策的任务，则应保留领域专家复核。单一评估方式很难覆盖智能体的全部行为。

公开事实、行业观点与编辑分析需要分开

从公开资料看，行业研究和实践文章已经普遍指出，传统单轮准确率不足以衡量智能体的规划能力、工具使用、长期上下文、故障恢复、成本和安全表现。这是对评估范围变化的事实性概括。

“企业应把每个成功任务的总成本作为核心经营指标”“人工介入率不应被简单追求越低越好”，则属于基于业务落地的分析判断。它们需要结合行业、流程风险和企业自身数据验证，不能被理解为适用于所有场景的统一标准。

至于智能体自主工作时长不断延长、运行成本持续下降等行业观察，企业在引用时应特别核对数据来源、测试条件和任务定义。持续运行时间、成本下降幅度和任务完成质量之间并不存在天然的正相关关系。一个能运行更久的系统，如果错误累积更多、人工返工更频繁，未必带来更高产出。

企业选型可以先做一张指标卡

在正式采购或自研前，管理者可以为每类任务建立一张指标卡，至少写清以下内容：

这张指标卡的关键，不是指标越多越好，而是每项指标都能对应一个业务决策：是否上线、是否扩大权限、是否更换模型、是否调整工作流，或者是否增加人工审核。

【软盟观察】大模型竞争从跑分转向持续工作能力，并不意味着公开基准失去意义，而是模型评测的对象正在发生变化。过去的比较更像是考察一个模型能否独立回答问题；企业真正需要的，则是判断由模型驱动的智能体能否在约束条件下完成一段可交付、可复盘、可计价的工作。这个转变会把竞争从“谁的模型分数更高”推进到“谁能把任务系统做得更可靠”。对管理者而言，最重要的不是追逐所有新指标，而是先找到最关键的业务闭环，明确成功和失败的定义，再用真实任务数据建立基线。对技术团队而言，应把评估接入开发、测试、部署和运营流程，持续观察版本变化是否改善了任务结果，而不是只在上线前做一次演示。对创业者而言，产品价值也不能只靠模型能力展示证明，还要说明节省了多少人工、减少了多少错误、承担了什么风险，以及在异常情况下如何交还控制权。最终，企业采用 AI 智能体的判断标准，应从“它能不能完成一次漂亮的演示”，转向“它能否在合理成本内，稳定完成足够多的真实任务，并且让人知道什么时候应该相信它、检查它或停止它”。