从跑分到交付：智能代理能力评估方法

近年来，大模型能力评估正在发生一个重要变化：过去，人们往往通过知识问答、逻辑推理、数学计算、代码生成等标准化测试判断模型强弱；如今，越来越多团队开始关注另一类问题——模型能否调用工具、规划步骤、理解反馈、修正错误，并在较长执行链路中真正完成一项任务。

这种变化意味着，模型能力的核心衡量对象，正在从“单轮回答质量”逐步转向“端到端任务交付能力”。

一些新模型在综合知识与推理类测试中的成绩未必出现显著跃升，但在自动化操作、终端任务、科学分析、系统配置、安全验证等复杂场景中表现出更高的成功率。表面上看，这似乎存在矛盾：为什么传统跑分没有明显增长，复杂任务能力却大幅改善？

答案在于，两类测试测量的并不是同一种能力。

一、传统跑分衡量“会不会”，复杂任务衡量“做不做得成”

传统评测通常具有几个共同特征：

• 输入边界清晰；
• 问题规模有限；
• 输出格式相对固定；
• 主要考察单轮或少量轮次推理；
• 正确答案容易自动判定。

例如，一道数学题、一段代码补全任务或一个知识判断题，模型只需要在有限上下文内生成合理答案即可。这种评测非常重要，因为它能够反映基础语言理解、知识覆盖、逻辑推理和代码表达能力。

但生产环境中的任务通常不是这样。

一个真实需求往往包含模糊目标、多个依赖系统、动态反馈、权限限制、异常状态和长链路决策。例如：

“分析过去一周服务异常的主要原因，定位受影响模块，生成修复建议，并提交一份可审阅的变更说明。”

这个任务并不是回答一句话，而是需要完成一系列连续动作：

1. 理解目标与边界；
2. 查询日志、监控和配置；
3. 筛选异常时间段；
4. 判断相关性与因果关系；
5. 形成修复假设；
6. 调用工具验证假设；
7. 输出可审计结论；
8. 在高风险操作前请求人工确认。

在这一过程中，模型即使每一步都有较高正确率，只要其中任意一个关键环节出现错误，最终任务仍可能失败。因此，智能代理真正面对的是“累积误差”问题。

假设一个任务由 10 个关键步骤组成，每一步成功率为 95%，则完整任务的理论成功率约为：

0.95 ^ 10 ≈ 59.9%

如果任务扩展到 30 个步骤，即使单步成功率仍为 95%，最终成功率也会下降到：

0.95 ^ 30 ≈ 21.5%

这说明，长任务能力的提升不能只依赖模型在单个问题上“更聪明”，还必须依赖更稳定的规划、状态管理、工具使用、错误恢复和结果验证机制。

二、智能代理的关键升级不只是推理，而是任务闭环

判断一个模型是否适合承担复杂工作，不能只看其回答是否流畅，而应观察它能否构成稳定的任务闭环。一个成熟的智能代理通常需要具备以下能力。

1. 目标拆解能力

模型需要把自然语言目标转化为可执行的子任务，而不是直接输出一段看似合理的结论。

例如，用户提出“排查接口延迟问题”，代理应主动识别需要的信息：

• 延迟异常发生的时间范围；
• 受影响的接口或服务；
• 请求量变化情况；
• 资源利用率；
• 下游依赖状态；
• 最近发布或配置变更；
• 是否存在网络抖动、缓存失效或数据热点。

目标拆解能力决定了模型是否具备系统性分析思维。若模型只依赖关键词匹配，很容易忽略关键变量，导致结论停留在泛泛而谈的层面。

2. 工具选择能力

智能代理不应把所有问题都当作文本生成任务。面对结构化数据、日志、文件、数据库或外部服务时，模型必须判断何时应当调用工具，何时应当直接回答。

例如：

• 查询数据时应使用数据检索工具；
• 分析表格时应使用计算或代码执行环境；
• 获取实时状态时应使用监控接口；
• 修改配置前应调用变更审批流程；
• 面对高风险命令时应先模拟执行或请求确认。

工具调用的难点不在于“能不能发起调用”，而在于模型是否知道调用什么、以什么参数调用、如何理解返回结果，以及调用失败后如何处理。

3. 状态维护能力

长任务中的上下文会不断变化。模型需要记住已经完成的步骤、未解决的问题、当前假设、已获取证据以及后续计划。

可以将任务状态抽象为如下结构：

{
  "goal": "定位系统延迟的主要原因",
  "completed_steps": [
    "获取异常时间范围",
    "查询关键服务监控指标"
  ],
  "pending_steps": [
    "比对发布记录",
    "检查下游依赖错误率"
  ],
  "hypotheses": [
    {
      "name": "数据库连接池耗尽",
      "confidence": 0.62,
      "evidence": ["连接等待时间上升", "并发请求增加"]
    }
  ],
  "risk_level": "medium"
}

如果缺少可靠的状态管理，模型容易出现重复查询、遗漏步骤、前后矛盾或错误复用旧结论等问题。

4. 反馈纠正能力

真正可用的代理不能只沿着最初计划机械执行，还必须能够根据工具结果修正判断。

例如，模型起初怀疑延迟来自数据库，但监控数据表明数据库响应正常，真正的问题是下游服务重试次数激增。此时代理应当放弃原有假设，更新分析路径，而不是继续围绕错误方向生成解释。

这种能力可概括为“基于证据的动态规划”。它要求模型具备：

• 识别证据与猜测的差异；
• 判断已有结论是否被新数据推翻；
• 在失败后选择替代路径；
• 在不确定时主动补充信息；
• 对最终结论标记置信程度。

5. 结果验证能力

模型完成任务不等于生成了一段答案，而应具备最低限度的自检和验证机制。

例如，在生成配置变更方案后，代理至少应检查：

• 配置格式是否有效；
• 参数是否存在冲突；
• 变更是否超出权限范围；
• 是否影响高优先级业务；
• 是否需要灰度发布；
• 是否具备回滚方案；
• 是否已经获得人工审批。

对于代码类任务，也应尽量通过测试、静态检查、模拟运行或约束校验降低错误率，而不是将未经验证的内容直接提交到生产环境。

三、为什么综合分数不能代表生产价值

综合测试通常会将多个能力维度加权得到一个总分，但这种方法存在天然局限。

首先，不同业务对能力的权重并不相同。对于客服问答场景，语言表达和知识准确性可能更重要；对于运维自动化场景，工具调用和异常恢复能力更关键；对于研发辅助场景，代码可运行性、依赖理解和测试覆盖率往往更有价值。

其次，总分容易掩盖短板。一个模型即使在大部分题目上表现不错，只要在权限控制、工具参数生成、长上下文一致性或安全边界方面存在缺陷，就可能无法直接进入关键业务流程。

最后，许多传统测试缺少真实环境中的干扰因素，例如：

• 数据不完整；
• 工具响应超时；
• 返回字段变化；
• 多系统状态不一致；
• 权限不足；
• 输入含糊或互相矛盾；
• 用户目标中途变更；
• 外部资源不可用。

因此，企业在评估模型时，应将“基础能力分数”视为准入指标，而非最终决策依据。真正重要的是：在有限成本、可控风险和明确时限内，模型能否稳定完成业务任务。

四、建立面向生产任务的评估体系

一套实用的智能代理评估体系，至少应覆盖以下五个层面。

1. 任务成功率

任务成功率应当基于最终交付结果计算，而不是只统计模型是否输出了内容。

可以定义为：

任务成功率 = 满足验收条件的任务数量 / 总任务数量

验收条件应尽可能业务化。例如：

• 是否准确提取目标数据；
• 是否生成可执行的操作方案；
• 是否完成指定流程；
• 是否正确处理异常；
• 是否避免越权操作；
• 是否在规定时间内完成。

2. 工具调用正确率

需要检查模型是否选择了正确工具、传递了正确参数、正确处理返回结果。

可进一步拆分为：

• 工具选择准确率；
• 参数合法率；
• 调用成功率；
• 返回结果解析准确率；
• 调用失败后的恢复成功率。

对于复杂代理系统，工具调用错误往往比文本表达错误更具风险，因此应被单独监控。

3. 长任务稳定性

长任务不应只测一次，而应进行多轮重复测试，观察模型在不同输入扰动下是否保持稳定。

建议重点测试：

• 任务步骤增加后的成功率变化；
• 上下文变长后的遗忘情况；
• 中断恢复能力；
• 多次工具调用后的状态一致性；
• 任务目标变更后的重规划能力；
• 异常注入后的恢复表现。

4. 成本与时延

生产系统必须考虑资源消耗。一个任务完成率较高的方案，如果耗时过长或资源成本不可控，也难以大规模落地。

需要监控的指标包括：

• 单任务平均时延；
• 工具调用次数；
• 重试次数；
• 上下文长度；
• 单任务资源消耗；
• 并发情况下的成功率；
• 峰值负载下的降级表现。

5. 安全与可控性

对于具备执行能力的代理，安全不是附加项，而是系统设计前提。

建议建立分级权限机制：

风险等级	示例操作	建议策略
低风险	查询公开信息、生成摘要	可自动执行
中风险	查询内部日志、生成配置建议	记录审计日志，可执行但需限制范围
高风险	修改配置、创建资源、发送外部通知	必须人工确认
极高风险	删除数据、变更生产权限、执行不可逆操作	默认禁止或采用双重审批

五、智能代理的推荐工程架构

要让模型真正参与复杂业务，不能只部署一个对话接口，而应构建分层架构。

1. 交互层

负责接收用户请求、展示执行过程、呈现中间结果，并在必要时要求用户补充信息或确认高风险操作。

2. 编排层

负责任务拆解、计划生成、步骤调度、状态存储、重试控制和异常恢复。编排层不应完全依赖模型自由发挥，而应通过结构化流程控制任务边界。

3. 模型推理层

负责理解意图、生成计划、选择工具、解释结果和形成最终回答。对于关键决策，建议要求模型输出结构化结果，而不是仅返回自然语言。

例如：

{
  "action": "query_logs",
  "reason": "需要确认异常时间段内是否存在错误峰值",
  "parameters": {
    "start_time": "由任务上下文确定",
    "end_time": "由任务上下文确定",
    "filter": "错误级别日志"
  },
  "expected_result": "获取错误数量与主要错误类型"
}

4. 工具层

包括数据查询、文件读取、代码执行、日志分析、监控检索、消息通知、对象存储、容器平台、消息队列等通用能力。工具层应通过统一协议向代理暴露，并对输入参数进行严格校验。

5. 治理层

负责权限控制、审计记录、敏感信息脱敏、内容安全、异常告警、成本统计和质量评估。对于企业场景，治理层决定了代理是否能够从试验环境进入生产环境。

六、落地时应避免的几个误区

误区一：把模型当作完全自治的员工

当前智能代理更适合承担“有边界、有工具、有验收标准”的任务，而不是无限制地接管业务流程。越是涉及资金、权限、生产变更和外部沟通，越需要人机协同。

误区二：只看演示效果，不看重复成功率

一次成功的演示并不代表系统稳定。企业应使用真实但脱敏的数据集，重复执行同类任务，并记录失败类型、重试次数、人工介入比例和最终成本。

误区三：让模型直接操作高风险系统

应通过沙箱、只读权限、审批流程、灰度执行和回滚机制逐步扩大代理权限。模型可以提出建议、生成变更草案、执行预检查，但不应在缺乏约束的情况下直接执行不可逆操作。

误区四：忽视数据质量和工具质量

很多所谓的“模型问题”，实际上来自数据不完整、接口不稳定、知识库陈旧、权限设计混乱或工具返回格式不统一。智能代理的最终效果取决于模型、工具、数据和流程四者的共同质量。

七、结语：判断智能水平，应看交付而非只看答题

关于“通用智能”的讨论容易聚焦在模型是否达到某个抽象门槛，但对企业技术团队而言，更有价值的问题是：

• 它能否可靠地完成一个多步骤任务？
• 它能否在失败后自我修正？
• 它能否在权限与安全约束下调用工具？
• 它能否提供可追溯、可验证、可审计的结果？
• 它能否在成本、时延和稳定性要求下持续运行？

模型在传统测试中取得高分，代表其具备较强的基础认知与推理能力；而模型能够稳定完成复杂工作，才意味着它开始具备实际生产价值。

未来的竞争重点不会只是“谁能回答更多问题”，而是“谁能在真实业务环境中，以更少人工干预、更低风险和更高确定性，把一件事情做完”。