普通问答分数高不代表 Agent 能力好。我最近在整理类似 Agents on Rails 的 LLM Benchmark Project 时最大的感受是LLM Agent 的评测真正该看的不是模型能不能说出正确答案而是模型能不能在给定边界和行动序列里把任务跑完。Agents on Rails 这个名字很直白rails 指的是轨道、边界、约束benchmark 是在这条标准化轨道上做考试。如果你正在选型大模型、做工具调用型 Agent或者想给内部系统建立一套回归评测后面这套拆解方式可以直接帮你把任务集、执行环境、判定规则和日志结构串起来。我不打算先讲榜单分数而是先解决一个更基础的问题什么样的基准测试才算真的在测 Agent。1. 为什么 Agent 评测不能直接拿普通问答分数凑合1.1 问答测的是“记得住”Agent 测的是“完得成”普通 LLM Benchmark 的典型题目是给一段知识或推理问题让模型输出答案。评测时比对答案正确性比如字母题、数学题、百科知识题。这类任务的核心是模型肚子里有没有货能不能把已经训练的推理能力调出来。Agent 任务不是这样。它会更多出现“查一下三个平台的价格取最低价并按固定 JSON 返回”这类需求。模型不是直接背答案而是要完成一连串动作从自然语言里拆出查询条件。决定调用哪个工具。传入正确的参数。拿到工具返回结果后再判断下一步。最后按照指定格式输出结论。如果评测只看最终文本是否包含想要的关键词中间步骤错了也发现不了。比如模型根本没有调用查询工具而是根据训练记忆编了一个价格最终结果可能看起来像模像样但实际任务根本没完成。普通问答评测很难抓住这种问题因为它的判定对象是“一句话”不是“一个带状态变化的过程”。1.2 轨道约束是公平评测的前提自由对话式的 Agent 评测看起来很灵活但会让不同模型之间的比较变得非常不靠谱。一个模型可能一直在解释思路但不执行另一个模型可能第一次就调用工具还有一个模型绕了五步其中两步访问了不应该访问的数据。这些路径差异会让结果无法量化。按轨道化思路设计时需要先定义清楚这几样东西允许使用的工具名单。每轮任务的最大步数。输入状态和输出状态。什么情况下算成功。什么行为算越界。这么做的目的不是限制 Agent 的真实能力展示。任何一次可复现评测都需要把不可控变量收住让模型只在同一个赛道里比赛。否则模型 A 在 2 步内完成模型 B 在 12 步内完成模型 B 的成功率也可能算 100%但成本和稳定性已经被拖垮。1.3 谁最需要这类评测第一类是做模型选型的人。他们要比较不同 LLM 在工具调用和任务执行上的差距不能只看 MMLU、GPQA 这类问答榜。第二类是 Agent 应用开发者他们频繁改 Prompt、换函数定义、调整工具返回格式需要一套回归任务保证改动不破坏已有能力。第三类是偏研究的人想通过任务集观察模型在规划、纠错、格式遵循上的边界。我个人更建议先分清目的再选任务。如果只是做问答能力摸底普通 Benchmark 够用如果想评价 Agent 能不能在边界内完成任务就必须走任务轨道化评测。2. 先拆任务把 Agent 能力切成可测量单元2.1 一项 Agent 任务包含多个能力点如果只统计最终成功率你很难回答一个问题模型到底是因为不会规划而失败还是因为不知道工具参数格式而失败。所以设计评测任务时我会先把能力拆成四个单元能力单元代表行为失败时常见表现指令理解从任务描述中提取目标、对象、约束参数缺失理解错条件动作选择判断当前该调用什么工具不调用工具或选错工具结果解释理解工具返回内容并决定下一步忽略关键字段重复调用同一工具收敛输出在允许步数内产生最终答案循环调用输出格式不符合要求每个任务跑完之后不只记成功失败还要记是哪个能力点先断掉。比如任务日志里出现“agent 第 3 步尝试调用 search但 action_input 缺少 query 字段”这属于工具调用协议问题出现“agent 在最终输出里写了一整段分析没有 required_fields”这属于格式遵循问题。2.2 成功标准必须落到状态变化上一份好的任务定义应该像验收文档不能只写一句“回答正确”。下面是一个我会直接用的最小结构字段含义是通用的不是某个项目官方格式{ task_id: order-logistics-001, goal: 根据订单号查询物流状态判断订单是否已签收, initial_state: { order_id: SO20250101 }, max_steps: 6, allowed_tools: [find_order, query_logistics], required_fields: [order_id, delivery_status, conclusion], expected: { delivery_status: signed, conclusion: yes }, validators: [conclusion_is_yes, status_matches_expected] }问题来了为什么成功标准不能只看conclusion因为模型可能跳过工具查询直接根据订单号猜结果。真实业务里这种输出毫无价值。所以 Validator 里可以再加一条must_call_query_logistics确保任务确实走过了该走的路径。2.3 任务难度要分档不要把简单任务和复杂任务混在一起算平均分。一个模型在 5 个简单任务上拿满分在 3 个长链路任务上全部失败平均分可能仍然很体面但实际部署到复杂业务里会立刻暴露问题。我的经验是把任务集分成三档L1单工具1 到 2 步可完成重点看指令理解和输出格式。L2多工具需要根据中间结果决策3 到 6 步。L3长链路需要过滤噪声、分阶段汇总、处理数据缺失最多 8 到 12 步。每档至少准备 20 到 30 条初期也可以先用 5 到 10 条快速验证流程。任务数量不够时不要急着上报准确率因为影响分数的随机波动会被误读成模型能力差异。3. 搭评测轨道从任务样例到统一流程3.1 把 Agent 交互改成状态机自由聊天式评测的问题在于Agent 输出什么都可以继续。要搭轨道就应该把流程压缩成一个循环读取任务初始状态 - 把“当前状态 可用工具 约束”发给 LLM - 模型返回动作 - 解析动作 - 如果动作是调用工具让模拟器执行并把结果追加到上下文 - 如果动作是最终答案进入结果校验 - 如果超过 max_steps按失败结束这个循环看起来简单但能保证每个模型都处在同一个可比较环境里。模型不能跳出轨道因为评测环境只接受两种输出工具调用动作和最终答案。即便模型想自由发挥环境也会把它拉回任务轨道。3.2 模型输出协议要固定很多 Agent 评测跑得不顺是因为模型返回的格式太自由。有人返回一句话“我需要查询订单”有人返回 Markdown有人尝试输出一个代码块。评测程序接收这些内容时解析成功率就会很低。稳妥做法是强制要求模型按结构化 JSON 返回。比如{ thought: 需要先根据订单号查询订单信息, action: find_order, action_input: { order_id: SO20250101 } }如果结果已确定则{ thought: 物流状态已经是 signed可以结束, action: final, action_input: { order_id: SO20250101, delivery_status: signed, conclusion: yes } }评测端把 action 解析出来后才把 action_input 转成工具调用。如果模型返回的不是合法 JSON或 action 不在允许列表内直接记一条format_error。这类样例会真实影响评测结果所以 Prompt 里必须给清晰示例不能只讲规则。3.3 模拟器和真实工具分开做 Benchmark 时我不能让你所有任务都直接调真实外部 API。原因很直接第三方接口可能变慢、限流、返回字段也可能变动最后失败的是谁分不清是模型还是外部服务所以第一版优先用模拟工具。模拟器不复杂就是预设好返回值和可变状态。比如find_order模块接收order_id返回一条固定订单记录query_logistics接收订单号根据订单状态返回物流物流节点。模拟器会让任务可重复也会让排查链路变短不会出现“上一次能成功这一次外部接口涨价导致超时”这种问题。等核心评测稳定以后再按需要增加真实工具测试但二者必须分开计分。否则把环境变量混在一起整个基准测试的可信度会下降。4. 跑批与指标怎么判断模型变强还是变贵4.1 每条任务需要记录哪些日志评测结构要在结果里保留足够信息否则后续无法复现。我通常给每个任务记录这样一批字段字段说明task_id任务编号model被测模型名称temperature温度参数run_id同一任务同一模型的多轮编号success是否通过校验error_type错误分类如 timeout、format_errorstep_count实际执行步数tool_used实际调用的工具列表total_tokens本次任务总 token 数cost_usd估算费用非必填latency_ms总耗时trace_path日志文件或 JSON 行文件路径有这些数据后一个诡异的分数才能被拆开看。同样是成功率 80%一个模型可能是格式错误占 20%另一个模型可能是工具调用后经常拿错结果这代表完全不同的整改方向。4.2 核心指标组别只设三个第一类是完成指标就是成功率。第二类是效率指标包括平均步数、工具调用次数、总耗时。第三类是成本指标包括输入 token、输出 token、估算费用。这三组指标要放在一起看不能只对比成功率。模型 A 成功率比模型 B 高 5%但平均多花 3 倍 token能否采用取决于你到底在做什么场景。如果是一个高频低级操作成本权重就会很高如果是低频高价值任务稳定性比成本更重要。另一个容易被忽视的指标是“收敛失败率”。把 max_steps 设为 6很多模型会在第 5 步才开始尝试最终输出最后一步格式出错。这其实说明模型不擅长判断“什么时候该结束”它不是知识不够是不会停。4.3 对比前先跑小样本我不建议一开始就把几百条任务全量跑一遍。样例少、识别度高时先用 5 条任务、3 个模型跑通整个链路。确认每个模型都能启动、工具能返回、结果能落盘、日志能定位再开放批量。批量跑的时候要注意不要一上来开最大并发。先看 3 个并发会不会超时再看 10 个并发会不会被限流。如果模型供应商返回llm request timed out未必是模型本身慢有时候是因为你同一秒内发了太多请求。4.4 不要只看一次输出大模型本身有随机性即使 temperature 设为 0某些服务端配置或采样参数也可能让结果不同。所以我会在固定任务集上让同一模型重复 2 到 3 次记录中位数和波动情况。如果一个任务第一次成功、第二次失败、第三次成功那它不算稳定通过。稳定通过的定义应该是多次重复中绝大多数都满足成功条件而且错误的类型集中在可控范围内。这样选型时才不会被单次跑出来的好分数误导。5. 环境隔离与可复现分数要能还原5.1 固定模型参数别让随机性背锅评测环境必须记录模型版本、Prompt 版本、工具定义版本和依赖版本。很多 Agent 项目失败后没法还原是因为改了代码但没改任务描述改了工具文档但没改 Prompt最后分数变化到底因为哪个环节无人知晓。针对 LLM 本身的随机性重复实验是最直接的应对。评测脚本可以自动在 task_id 后加-run1、-run2对同一任务执行多次后再进入指标统计。种子参数不是所有供应商都支持不能默认它有效所以重复跑比强行依赖 seed 更通用。5.2 外部页面和接口要做版本固化如果评测对象是浏览器操作型 Agent网页结构变化会让结果非常不稳定。之前跑得好好的任务某天页面按钮从idsubmit改成> LLM Agent 评测新范式：从问答分数到轨道化任务完成率
普通问答分数高不代表 Agent 能力好。我最近在整理类似 Agents on Rails 的 LLM Benchmark Project 时最大的感受是LLM Agent 的评测真正该看的不是模型能不能说出正确答案而是模型能不能在给定边界和行动序列里把任务跑完。Agents on Rails 这个名字很直白rails 指的是轨道、边界、约束benchmark 是在这条标准化轨道上做考试。如果你正在选型大模型、做工具调用型 Agent或者想给内部系统建立一套回归评测后面这套拆解方式可以直接帮你把任务集、执行环境、判定规则和日志结构串起来。我不打算先讲榜单分数而是先解决一个更基础的问题什么样的基准测试才算真的在测 Agent。1. 为什么 Agent 评测不能直接拿普通问答分数凑合1.1 问答测的是“记得住”Agent 测的是“完得成”普通 LLM Benchmark 的典型题目是给一段知识或推理问题让模型输出答案。评测时比对答案正确性比如字母题、数学题、百科知识题。这类任务的核心是模型肚子里有没有货能不能把已经训练的推理能力调出来。Agent 任务不是这样。它会更多出现“查一下三个平台的价格取最低价并按固定 JSON 返回”这类需求。模型不是直接背答案而是要完成一连串动作从自然语言里拆出查询条件。决定调用哪个工具。传入正确的参数。拿到工具返回结果后再判断下一步。最后按照指定格式输出结论。如果评测只看最终文本是否包含想要的关键词中间步骤错了也发现不了。比如模型根本没有调用查询工具而是根据训练记忆编了一个价格最终结果可能看起来像模像样但实际任务根本没完成。普通问答评测很难抓住这种问题因为它的判定对象是“一句话”不是“一个带状态变化的过程”。1.2 轨道约束是公平评测的前提自由对话式的 Agent 评测看起来很灵活但会让不同模型之间的比较变得非常不靠谱。一个模型可能一直在解释思路但不执行另一个模型可能第一次就调用工具还有一个模型绕了五步其中两步访问了不应该访问的数据。这些路径差异会让结果无法量化。按轨道化思路设计时需要先定义清楚这几样东西允许使用的工具名单。每轮任务的最大步数。输入状态和输出状态。什么情况下算成功。什么行为算越界。这么做的目的不是限制 Agent 的真实能力展示。任何一次可复现评测都需要把不可控变量收住让模型只在同一个赛道里比赛。否则模型 A 在 2 步内完成模型 B 在 12 步内完成模型 B 的成功率也可能算 100%但成本和稳定性已经被拖垮。1.3 谁最需要这类评测第一类是做模型选型的人。他们要比较不同 LLM 在工具调用和任务执行上的差距不能只看 MMLU、GPQA 这类问答榜。第二类是 Agent 应用开发者他们频繁改 Prompt、换函数定义、调整工具返回格式需要一套回归任务保证改动不破坏已有能力。第三类是偏研究的人想通过任务集观察模型在规划、纠错、格式遵循上的边界。我个人更建议先分清目的再选任务。如果只是做问答能力摸底普通 Benchmark 够用如果想评价 Agent 能不能在边界内完成任务就必须走任务轨道化评测。2. 先拆任务把 Agent 能力切成可测量单元2.1 一项 Agent 任务包含多个能力点如果只统计最终成功率你很难回答一个问题模型到底是因为不会规划而失败还是因为不知道工具参数格式而失败。所以设计评测任务时我会先把能力拆成四个单元能力单元代表行为失败时常见表现指令理解从任务描述中提取目标、对象、约束参数缺失理解错条件动作选择判断当前该调用什么工具不调用工具或选错工具结果解释理解工具返回内容并决定下一步忽略关键字段重复调用同一工具收敛输出在允许步数内产生最终答案循环调用输出格式不符合要求每个任务跑完之后不只记成功失败还要记是哪个能力点先断掉。比如任务日志里出现“agent 第 3 步尝试调用 search但 action_input 缺少 query 字段”这属于工具调用协议问题出现“agent 在最终输出里写了一整段分析没有 required_fields”这属于格式遵循问题。2.2 成功标准必须落到状态变化上一份好的任务定义应该像验收文档不能只写一句“回答正确”。下面是一个我会直接用的最小结构字段含义是通用的不是某个项目官方格式{ task_id: order-logistics-001, goal: 根据订单号查询物流状态判断订单是否已签收, initial_state: { order_id: SO20250101 }, max_steps: 6, allowed_tools: [find_order, query_logistics], required_fields: [order_id, delivery_status, conclusion], expected: { delivery_status: signed, conclusion: yes }, validators: [conclusion_is_yes, status_matches_expected] }问题来了为什么成功标准不能只看conclusion因为模型可能跳过工具查询直接根据订单号猜结果。真实业务里这种输出毫无价值。所以 Validator 里可以再加一条must_call_query_logistics确保任务确实走过了该走的路径。2.3 任务难度要分档不要把简单任务和复杂任务混在一起算平均分。一个模型在 5 个简单任务上拿满分在 3 个长链路任务上全部失败平均分可能仍然很体面但实际部署到复杂业务里会立刻暴露问题。我的经验是把任务集分成三档L1单工具1 到 2 步可完成重点看指令理解和输出格式。L2多工具需要根据中间结果决策3 到 6 步。L3长链路需要过滤噪声、分阶段汇总、处理数据缺失最多 8 到 12 步。每档至少准备 20 到 30 条初期也可以先用 5 到 10 条快速验证流程。任务数量不够时不要急着上报准确率因为影响分数的随机波动会被误读成模型能力差异。3. 搭评测轨道从任务样例到统一流程3.1 把 Agent 交互改成状态机自由聊天式评测的问题在于Agent 输出什么都可以继续。要搭轨道就应该把流程压缩成一个循环读取任务初始状态 - 把“当前状态 可用工具 约束”发给 LLM - 模型返回动作 - 解析动作 - 如果动作是调用工具让模拟器执行并把结果追加到上下文 - 如果动作是最终答案进入结果校验 - 如果超过 max_steps按失败结束这个循环看起来简单但能保证每个模型都处在同一个可比较环境里。模型不能跳出轨道因为评测环境只接受两种输出工具调用动作和最终答案。即便模型想自由发挥环境也会把它拉回任务轨道。3.2 模型输出协议要固定很多 Agent 评测跑得不顺是因为模型返回的格式太自由。有人返回一句话“我需要查询订单”有人返回 Markdown有人尝试输出一个代码块。评测程序接收这些内容时解析成功率就会很低。稳妥做法是强制要求模型按结构化 JSON 返回。比如{ thought: 需要先根据订单号查询订单信息, action: find_order, action_input: { order_id: SO20250101 } }如果结果已确定则{ thought: 物流状态已经是 signed可以结束, action: final, action_input: { order_id: SO20250101, delivery_status: signed, conclusion: yes } }评测端把 action 解析出来后才把 action_input 转成工具调用。如果模型返回的不是合法 JSON或 action 不在允许列表内直接记一条format_error。这类样例会真实影响评测结果所以 Prompt 里必须给清晰示例不能只讲规则。3.3 模拟器和真实工具分开做 Benchmark 时我不能让你所有任务都直接调真实外部 API。原因很直接第三方接口可能变慢、限流、返回字段也可能变动最后失败的是谁分不清是模型还是外部服务所以第一版优先用模拟工具。模拟器不复杂就是预设好返回值和可变状态。比如find_order模块接收order_id返回一条固定订单记录query_logistics接收订单号根据订单状态返回物流物流节点。模拟器会让任务可重复也会让排查链路变短不会出现“上一次能成功这一次外部接口涨价导致超时”这种问题。等核心评测稳定以后再按需要增加真实工具测试但二者必须分开计分。否则把环境变量混在一起整个基准测试的可信度会下降。4. 跑批与指标怎么判断模型变强还是变贵4.1 每条任务需要记录哪些日志评测结构要在结果里保留足够信息否则后续无法复现。我通常给每个任务记录这样一批字段字段说明task_id任务编号model被测模型名称temperature温度参数run_id同一任务同一模型的多轮编号success是否通过校验error_type错误分类如 timeout、format_errorstep_count实际执行步数tool_used实际调用的工具列表total_tokens本次任务总 token 数cost_usd估算费用非必填latency_ms总耗时trace_path日志文件或 JSON 行文件路径有这些数据后一个诡异的分数才能被拆开看。同样是成功率 80%一个模型可能是格式错误占 20%另一个模型可能是工具调用后经常拿错结果这代表完全不同的整改方向。4.2 核心指标组别只设三个第一类是完成指标就是成功率。第二类是效率指标包括平均步数、工具调用次数、总耗时。第三类是成本指标包括输入 token、输出 token、估算费用。这三组指标要放在一起看不能只对比成功率。模型 A 成功率比模型 B 高 5%但平均多花 3 倍 token能否采用取决于你到底在做什么场景。如果是一个高频低级操作成本权重就会很高如果是低频高价值任务稳定性比成本更重要。另一个容易被忽视的指标是“收敛失败率”。把 max_steps 设为 6很多模型会在第 5 步才开始尝试最终输出最后一步格式出错。这其实说明模型不擅长判断“什么时候该结束”它不是知识不够是不会停。4.3 对比前先跑小样本我不建议一开始就把几百条任务全量跑一遍。样例少、识别度高时先用 5 条任务、3 个模型跑通整个链路。确认每个模型都能启动、工具能返回、结果能落盘、日志能定位再开放批量。批量跑的时候要注意不要一上来开最大并发。先看 3 个并发会不会超时再看 10 个并发会不会被限流。如果模型供应商返回llm request timed out未必是模型本身慢有时候是因为你同一秒内发了太多请求。4.4 不要只看一次输出大模型本身有随机性即使 temperature 设为 0某些服务端配置或采样参数也可能让结果不同。所以我会在固定任务集上让同一模型重复 2 到 3 次记录中位数和波动情况。如果一个任务第一次成功、第二次失败、第三次成功那它不算稳定通过。稳定通过的定义应该是多次重复中绝大多数都满足成功条件而且错误的类型集中在可控范围内。这样选型时才不会被单次跑出来的好分数误导。5. 环境隔离与可复现分数要能还原5.1 固定模型参数别让随机性背锅评测环境必须记录模型版本、Prompt 版本、工具定义版本和依赖版本。很多 Agent 项目失败后没法还原是因为改了代码但没改任务描述改了工具文档但没改 Prompt最后分数变化到底因为哪个环节无人知晓。针对 LLM 本身的随机性重复实验是最直接的应对。评测脚本可以自动在 task_id 后加-run1、-run2对同一任务执行多次后再进入指标统计。种子参数不是所有供应商都支持不能默认它有效所以重复跑比强行依赖 seed 更通用。5.2 外部页面和接口要做版本固化如果评测对象是浏览器操作型 Agent网页结构变化会让结果非常不稳定。之前跑得好好的任务某天页面按钮从idsubmit改成>