论文档案

论文解决的不是“再做一个排行榜”

静态 NLP 基准给模型一个输入，模型输出一次答案。Agent 任务却有状态、动作协议、环境反馈、回合上限和错误传播。AgentBench 的核心贡献，是把 LLM 作为策略放进 8 种多轮环境，用统一工具包运行 29 个 API 或开源模型，并把结束原因也纳入分析。

换句话说，它评估的是：

模型 + prompt + 动作格式 + 环境接口 + 回合预算

而不是孤立模型。论文标题说“评估 LLM”，实际分数已经包含一个轻量 harness；这正是阅读时必须辨认的混杂变量。

八个环境覆盖了什么

论文把任务分成三组：

其中五个环境由论文新建或重构。各环境任务数、平均回合和指标不同：有的用 success rate，有的用游戏分数或匹配分数。测试规模从 20 到 300 个样本不等，预计单题交互约 5–50 轮。

统一运行协议

AgentBench 使用简单 CoT，让模型在一轮中输出 Thought 与 Action，环境解析 Action 并返回观察。所有任务使用温度 0 以提高复现性，没有多次采样或复杂搜索。

这看似“朴素”，其实是基准设计的重要选择：复杂 Agent 策略会让结果更难归因。论文尽量把 harness 固定，把主要变化放在模型上。

然而固定不代表中立。动作格式、示例、回合上限、上下文截断和错误消息都会偏向不同模型。AgentBench 自己的失败分析恰好证明接口是分数的一部分。

跨任务总分怎样计算

八个环境的原始分数尺度差异很大，直接平均会让天然高分的任务主导结果。论文先让参与评估模型在每个任务上的平均得分归一到 1，再取其倒数作为固定权重，最后计算加权总分。

这使论文内横向比较更平衡，但有三个局限：

1. 权重依赖首批参评模型的能力分布；
2. 新模型的总分仍沿用历史权重，含义不等于平均成功率；
3. 总分会隐藏某个环境完全不可用的短板。

因此复现时应该同时报告总分、各环境分数和结束原因。

主要结果如何解读

论文最终版评估 29 个模型。GPT-4（0613）总分约 4.01，在 8 个环境中的 6 个领先；Claude 3 Opus 约 3.11，GLM-4 约 2.89，GPT-3.5-turbo 约 2.32。论文统计 API 模型平均总分约 2.32，不超过 70B 的开源模型平均约 0.51。

开源模型中 CodeLlama-34B-Instruct 总分约 0.96，但表现非常不均衡。这支持论文关于 code tuning 是“双刃剑”的观察：代码训练有助于格式化、数据库或操作系统任务，却可能伤害需要一般语言理解和灵活交互的任务。

这些数字只反映论文固定版本、固定 prompt 和固定环境。今天重新调用同名 API 可能已经不是相同 checkpoint；总分不能当作 2026 年模型能力表。

最有价值的贡献：把失败变成结构化数据

论文定义五种结束类型：

八个任务平均后，Task Limit Exceeded 是最主要失败原因。在一些任务上比例极高，例如知识图谱约 67.9%、卡牌游戏约 82.5%。数据库和卡牌游戏常见 Invalid Format，House-Holding 和 Web Browsing 常见 Invalid Action。

这说明一个总的“未成功”标签远远不够。Harness 需要区分：模型没理解、协议没解析、动作不可执行、环境报错、预算用尽、验证失败。只有这样才能判断应该换模型、改接口还是改控制器。

论文揭示的能力瓶颈

长程推理与决策

任务上限耗尽常表现为重复上一轮内容、在相同状态间往返、迟迟不提交。简单增加回合上限通常只会增加成本。更合理的运行时措施是检测无进展、保存状态摘要、触发重规划或终止。

指令遵循

Invalid Format 与 Invalid Action 表明，模型即使“知道答案”，也可能不能可靠使用环境协议。结构化 function calling、schema 验证和可恢复错误反馈是 Harness 的基本能力，而不是模型外围的琐碎胶水。

高质量对齐数据

论文比较同底座模型时发现，使用较高质量对话数据对齐的模型往往更强。这个观察说明 Agent 能力不只是参数量或代码量，也受到多轮指令遵循训练影响。但论文对训练数据的因果控制有限，不能据此单独归因。

用 Harness 视角重读 AgentBench

AgentBench 的设计适合做宽覆盖诊断，却不适合直接作为生产 readiness gate。一个模型在平均分上更高，不代表它能在付款、发信等高风险动作中满足可靠性要求。

建议的复现实验

完整复跑 8 个环境成本和依赖都很高。可以选 OS、Database、Web Shopping 三个互补环境：

1. 固定模型版本、temperature、system prompt 和动作 schema；
2. 每个任务至少运行 3 次，记录均值和方差；
3. 保存每轮 action、解析结果、环境状态摘要和成本；
4. 将失败分类扩展为 protocol、policy、tool、environment、planning、verification；
5. 做两组 Harness 消融：自由文本动作 vs schema；纯回合上限 vs 无进展熔断；
6. 不只报告平均分，绘制每类任务成功率和结束原因分布。

如果换模型后性能变化，要确认不是上下文长度、工具调用 API 或 tokenizer 让同一 harness 实际变成了不同接口。

局限

• 八个环境虽广，但每个环境深度有限，真实业务分布更复杂；
• 部分数据由模型辅助生成，可能存在偏差或污染；
• 各任务指标和难度不同，总分依赖人为归一化；
• 单次、temperature 0 不能测量 stochastic reliability；
• 简单 CoT harness 会低估能从专用接口、规划或记忆中获益的模型；
• API 模型版本会漂移，复现必须记录精确 checkpoint 和日期；
• 基准不专门评测权限、副作用和 prompt injection。

AgentBench 的真正遗产是把 Agent 失败从“答错了”拆成运行时可观测事件。后来的 SWE-bench、OSWorld、τ-bench 和 AgentDojo分别把真实执行、桌面状态、重复可靠性与安全攻击推进得更深。

延伸阅读

• 返回论文谱系与单篇索引
• SWE-bench：真实仓库中的执行式验收
• OSWorld：真实操作系统环境
• τ-bench：重复可靠性而非单次成功