大语言模型从“会聊天”进化到“会做事”，中间隔着一条不小的鸿沟。一个Agent要在真实环境中完成任务，需要理解指令、规划步骤、调用工具、观察反馈并修正行为，这一整套能力的评估远比传统的选择题式基准复杂得多。学界目前出现了多个专门的Agent评估框架，其中AgentBench和AgentBoard是关注度较高的两个代表。前者强调多环境下的综合决策能力测试，后者主打细粒度分析与可视化。本文将详细介绍这两个框架的设计思路、核心指标和使用方法，并给出选型建议。
AgentBench：八个真实环境下的Agent能力大考
AgentBench由清华大学联合多所高校的研究团队提出，是目前覆盖面较广的系统性Agent评估框架之一。它的核心想法是：与其用模拟题目测试模型，不如把模型放进真实可交互的环境中，让它真正去“干活”。框架一共包含八个不同类型的环境，涵盖操作系统命令行（OS）、数据库操作（DB）、知识图谱问答（KG）、数字卡牌游戏（DCG）、横向思维谜题（LTP）、家庭场景模拟（HH）、网页浏览（WB）以及网页购物（WS）。
这些环境的难度梯度设计得很有讲究。比如操作系统环境中，模型需要通过一系列bash命令完成文件查找、进程管理等任务，任何一步命令执行失败都会影响最终结果；数据库环境则要求模型根据自然语言需求拼出正确的SQL语句并执行；网页浏览环境更是直接对接真实网页，考察模型处理复杂HTML结构和多跳导航的能力。这种跨环境的多样性设计，可以有效避免模型在单一任务上“刷分”的侥幸。
AgentBench引入了一个统一的指标——成功率（Success Rate），辅以整体得分（Overall Score）。整体得分是对各环境成功率加权平均后的归一化结果，方便横向比较不同模型的综合水平。实验结果显示，闭源商业模型与开源模型之间在Agent能力上存在明显差距，很多在传统榜单上表现接近的模型，放进真实交互环境后差距被显著放大。这也正是这类评估框架的价值所在：它暴露了静态基准无法反映的短板，比如多轮决策中的错误累积、长程任务中的指令遗忘等。
在部署方面，AgentBench提供了完整的环境配置脚本，部分环境依赖Docker容器运行，数据库和操作系统环境需要提前准备对应的镜像。安装流程大致如下：
git clone https://github.com/THUDM/AgentBench.git cd AgentBench conda create -n agentbench python=3.9 conda activate agentbench pip install -r requirements.txt # 根据需要启动各个环境，例如操作系统环境 cd agentenvironments/env_os docker build -t agentbench_os . python run.py --model gpt-4o --task os
需要注意的是，八个环境全部跑通的成本不低，建议按需选择重点环境进行测试，避免一次性部署全部依赖带来的环境冲突问题。
AgentBoard：细粒度分析与可视化面板
如果说AgentBench回答的是“模型行不行”，那么AgentBoard更侧重回答“模型到底在哪一步不行、为什么不行”。AgentBoard同样构建了多项交互式任务，覆盖网络浏览、工具使用、具身智能、游戏和科学推理等多个领域，但它最大的特色是提出了两个新的分析维度：分析性评估体系和进度速率指标。
进度速率（Progress Rate）是一个很巧妙的设计。传统成功率是零一结果——任务要么完成要么失败，信息量非常有限。而进度速率把任务分解为若干子目标，根据模型实际完成的子目标比例打分。举例来说，一个需要五步操作的任务，模型做对了三步后卡住，成功率为零，但进度速率是0.6，这显然更真实地反映了模型的能力边界。对于调试和改进Agent来说，这个指标的价值远大于单纯的成败判定。
分析性评估体系则从六个基础能力维度对模型进行拆解：推理、规划、工具使用、指令跟随、自我反思和知识获取。每个任务都会标注其考察的主要能力维度，评估结束后可以生成雷达图，直观展示模型在各维度上的强弱分布。这种拆解方式能帮助开发者快速定位瓶颈——是规划能力不足，还是工具调用格式频繁出错，一目了然。
此外，AgentBoard还内置了一个实时可视化面板，支持在评估过程中逐步查看模型的行为轨迹、每一步的观察输入和动作输出。这对于分析失败案例尤其有用。使用方式也比较简单：
git clone https://github.com/hkust-nlp/AgentBoard.git cd AgentBoard pip install -e . # 启动可视化面板 python visualizer/app.py --port 8080 # 运行评估并生成分析报告 python main.py --model_name your_model --output_dir ./results
评估完成后，面板会输出成功率、进度速率以及能力维度的综合图表，支持导出JSON格式的详细结果，方便接入到自动化测试流水线中。
两大框架对比与选型建议
两个框架的定位差异明显，可以从几个维度来对比。首先是环境覆盖：AgentBench的八个环境偏重系统级操作（命令行、数据库、网页），任务难度整体较高，适合检验模型在生产级场景下的硬实力；AgentBoard的任务类型更广，包含具身智能和游戏类任务，难度分布更平缓，适合做能力画像和迭代优化。其次是指标设计：AgentBench以成功率加综合得分为核心，简洁但粒度较粗；AgentBoard的进度速率和分析性评估提供的信息量明显更丰富。
第三是工程成本。AgentBench部分环境需要Docker和真实网络访问，部署相对重一些，但环境更接近真实使用场景；AgentBoard的安装更轻量，可视化开箱即用，对快速上手更友好。最后是结果可比性：AgentBench的榜单收录了大量主流模型的公开成绩，新模型可以直接对标；AgentBoard的评估报告更侧重自分析，社区对标的公开数据相对少一些。
实际选型时可以这样考虑：如果你的目标是发布一个有说服力的横向对比结果，或者重点考察模型在命令行、数据库、网页操作这类系统任务上的表现，优先选AgentBench；如果你处在Agent的迭代开发阶段，需要定位具体是哪个环节拖了后腿，或者想要细粒度的能力雷达图来指导优化方向，AgentBoard会更合适。当然，两者并不互斥，不少团队的做法是用AgentBench做定期回归测试，用AgentBoard做日常开发的诊断工具，两者配合使用效果更好。
评估之外还需要注意什么
跑分只是手段，不是目的。使用这些框架时有几个常见的坑值得提醒。第一，环境一致性问题：网页浏览类任务的页面结构会随时间变化，不同时间点的评估结果可能不可比，建议固定快照或在报告中标明评估时间。第二，提示词敏感性：同一模型在不同提示模板下的Agent表现差异可能很大，评估时应使用框架提供的标准提示，避免自行魔改导致结果失真。第三，工具调用格式的容错处理：不少失败案例并非模型“不会做”，而是输出格式解析失败，这类误差在解读结果时需要单独甄别。
另外，评估结果和实际落地效果之间也存在差距。基准环境中的任务再逼真，也无法完全覆盖真实业务中的异常分支、数据噪声和用户行为的不可预测性。比较稳妥的做法是把框架评估作为第一道筛选，再针对自己的业务场景构建小规模的私有评估集，两者结合才能对Agent能力做出相对客观的判断。评估框架的价值在于提供一把公共的尺子，而这把尺子量出来的刻度，最终还是要服务于产品和模型的持续改进。
Agent评估框架AgentBenchAgentBoard修改时间：2026-09-15 16:20:44