Agentic Ability 评测

Agentic Ability 评测在固定环境中测量模型调用工具、规划和完成多步任务的能力。与静态问答评测不同，它考察模型在开放环境中的自主决策、动作执行以及依据反馈修正路线的完整过程，因此也被称为智能体能力 (Agentic Ability) 评测。

智能体评测的兴起源于模型从「单轮问答」向「多轮执行」的演进：当模型不再只输出一段文本，而是要像程序一样读取环境、调用工具、观察结果并继续行动时，单纯看答案对错已经不足以反映能力。为此出现了 SWE-bench、WebArena、AgentBench 与 τ-bench 等基准，它们分别在真实软件仓库、网页环境与工具调用场景中测量智能体的成功率。这类评测的核心命题是：模型能否在「感知 -> 决策 -> 行动 -> 再感知」的闭环中稳定达成目标，而不是在某一步上碰巧答对。

快速开始¶

固定工具版本、权限、初始状态、时间和预算，报告任务成功率以及安全违规和成本。评测前先把这些变量固化，否则两次运行之间的结果不可比。

准备一个可重置的环境，通常是一个临时沙箱或容器，里面包含 Agent 可用的工具集合，例如文件操作、代码执行、网页检索或命令行。每个任务的初始状态必须是确定的：文件内容、目录结构、数据库记录和环境变量都要在每次运行前恢复到同一快照。同时限定每步动作的参数范围、单轮时间上限和任务总预算，避免 Agent 通过无限重试提高表面成功率。

运行时要完整记录轨迹，至少包含每一步的工具调用参数、返回结果、模型据此产生的下一步决策，以及最终环境状态。判定成功与否应以最终环境状态为准，而不是以模型声称完成的内容为准。汇总指标通常包括任务成功率、完成所需步数、无效或重复的工具调用次数，以及越权、数据泄漏等安全违规与总成本。

任务成功率可以形式化为：

其中 \(N\) 为任务总数，\(\mathbb{1}[\cdot]\) 为示性函数，只有当任务 \(i\) 的最终环境状态真正满足目标时才取 1。与之配套的「有效动作率」为有效工具调用次数与总调用次数之比，用来区分「想对了但动作无效」与「想错了」。

一个最小可复现的验证方式是：先跑一个只回显「已完成」但不做任何工具调用的基线模型，确认它在这些任务上得分为零；再把环境重置逻辑重复运行两次，确认两次结果一致。以下是一段固定关键变量的最小配置片段：

environment:
  image: sandbox:fixed-2024
  reset: restore_snapshot   # 每次任务前恢复同一快照
  network: blocked          # 需要外部服务时显式开启并记录版本
agent:
  tools: [list_files, rename, grep, write_file]
  max_steps: 20
  per_step_timeout_sec: 30
  total_budget: { tokens: 20000, wall_clock_sec: 600 }
scoring:
  judge: final_state        # 以最终环境状态判分，而非模型声称
  metrics: [success_rate, valid_action_rate, safety_violations]

验证成功的标准：基线「声称完成」模型在这些任务上的成功率必须为 0；对同一任务连续两次运行，成功率与轨迹完全一致，说明环境与判分已固化。

难点¶

环境随机性、外部网络和工具差异会掩盖模型差异。评测必须可重置、可审计，并区分模型失败与工具失败。这是 Agentic 评测与常规问答评测最大的不同：结果同时取决于模型、环境和工具三者。

环境随机性来自时间、进程调度、返回内容排序等不稳定因素。例如检索工具返回结果的顺序每次不同，会导致后续决策分叉。对策是把所有外部交互可模拟的部分全部注入为确定性的固定返回值，仅在无法避免时使用真实服务，并记录版本和访问时间，保证可审计。WebArena 就因此把评测环境做成可自托管、可冻结状态的网站镜像，从而把网络不确定性降到最低。

工具本身的差异也会干扰结论。同一个任务，工具描述写得清楚与否、参数是否宽松、返回结构是否规范，都会显著改变成功率。τ-bench 的核心设计之一就是把「工具调用是否正确解析、参数是否合法」与「策略是否正确」分开衡量，避免接口噪声被误读为策略失败。因此评测报告需要单列工具调用解析失败、参数错误等「工具层失败」，与「模型决策错误」分开统计，否则无法判断瓶颈究竟在工具接口还是模型能力。

案例¶

在临时文件系统中要求 Agent 重命名、检索并汇总文件。记录每步工具调用与最终状态，判定是否真正完成而非只输出声称完成。

具体任务可以这样设计：在一个空目录中放入若干命名混乱的日志文件，要求 Agent 先把它们按日期前缀重命名，再检索出包含特定错误码的条目，最后把结果汇总到一个新文件。给 Agent 提供 list_files、rename、grep 和 write_file 四个工具，并限制最多执行 20 步。

评测时记录 Agent 每一步调用的是哪个工具、传了什么参数、工具返回了什么。判分不读取 Agent 的最终回答，而是检查文件系统的实际状态：重命名后的文件名是否符合约定、汇总文件是否存在且内容只包含命中条目。这样能识别「只输出声称完成、实际什么都没改」的伪完成。一段简化的判分逻辑如下：

def score(task, final_fs, trajectory):
    ok_rename = all(f.startswith(task.expected_date_prefix) for f in final_fs.files)
    ok_summary = final_fs.has(task.summary_path) and \
                 set(final_fs.read(task.summary_path)) == task.expected_entries
    valid_actions = sum(1 for step in trajectory if step.tool_result.parsed)
    return {
        "success": int(ok_rename and ok_summary),
        "valid_action_rate": valid_actions / len(trajectory),
    }

其中 ok_rename 与 ok_summary 完全来自最终文件系统状态，valid_action_rate 来自轨迹中工具调用被正确解析的比例，二者分别对应「是否真完成」与「动作是否有效」。

常见失败点包括：重命名时未处理文件名冲突、检索时忽略了子目录、汇总时重复写入导致内容错乱。若出现大量此类失败，应优先排查工具描述是否足以让模型理解语义，而不是直接归因于模型规划能力不足。

相关主题¶

• Coding
• 强化学习