这篇是对论文 AgentBench: Evaluating LLMs as Agents 的学习笔记。
如果说传统 LLM 评测是在问“模型会不会回答问题”，AgentBench 问的是另一件事：
模型能不能在环境里连续行动，把任务做完？
这两件事差别很大。一个模型可以在单轮问答里表现很好，但一旦进入多轮环境，就会暴露出完全不同的问题：忘记目标、动作格式错、调用不存在的动作、陷入循环、遇到失败不会恢复、短期贪心导致长期任务失败。
AgentBench 的价值就在于，它把模型从静态题库里拿出来，放进一组交互环境中评测。
1. 为什么 Agent 不能只用问答评测
普通问答评测大多是这样的：
输入一个问题
模型输出一个答案
评分器判断答案对不对Agent 任务更像这样：
用户给一个目标
Agent 观察环境
选择动作
环境返回结果
Agent 再选择动作
多轮之后完成或失败这时评测重点不再只是最终文本，而是行动过程。
比如一个 OS 任务：找出某个目录下非空文件夹数量。Agent 需要生成 shell 命令，读取输出，必要时继续探索，最后提交答案。它可能不是不知道 Linux 命令，而是在某一步格式不对、路径理解错、忘记提交最终答案。
再比如 web shopping 任务：用户要找一个满足条件的商品。Agent 需要搜索、筛选、比较、进入详情页、检查约束、下单或提交结果。它每一步都可能走偏。
所以 Agent 评测必须包括环境、动作、观察、状态、终止条件和任务成功判定。
2. AgentBench 的 8 类环境
AgentBench 构造了 8 个环境，覆盖三类 grounding。
Code-grounded：
- Operating System
- Database
- Knowledge Graph
Game-grounded：
- Digital Card Game
- Lateral Thinking Puzzles
- House-Holding，也就是基于 ALFWorld 的家庭任务
Web-grounded：
- Web Shopping
- Web Browsing
这组环境的好处是，它不把 Agent 能力绑定到单一任务。OS 测命令执行和状态操作；Database 测 SQL 查询和表结构理解；Knowledge Graph 测结构化知识检索；Card Game 测策略；Lateral Thinking 测多轮询问；House-Holding 测常识和动作规划；Web Shopping/Web Browsing 测网页任务执行。
AgentBench 不是让模型在一个环境里刷高分，而是看它在不同任务形态下是否具备稳定的行动能力。
3. 它测的是哪些失败
AgentBench 论文里很重要的一点，是它不仅看成功率，也分析失败类型。
常见失败包括：
- Invalid Format：模型没有按环境要求输出动作格式。
- Invalid Action：格式对了，但动作本身不合法。
- Task Limit Exceeded：达到最大交互轮数仍未完成，或陷入重复。
- 长期推理不足：当前动作看似合理，但偏离最终目标。
- 决策能力不足：观察到新信息后不会调整策略。
- 指令遵循不足：没有遵守环境协议或用户约束。
这些失败比“回答错了”更具体，也更有调试价值。
比如 Invalid Format 高，说明模型不是任务知识不足，而是协议遵循差；Invalid Action 高，可能是动作空间描述不清或模型没有学会环境约束；TLE 高，往往说明规划和恢复能力弱。
这对工程系统很重要，因为不同失败要用不同手段修。
格式失败：加 parser、action schema、重试修复
非法动作：改工具描述、加 action mask、返回结构化错误
任务超时：改规划器、加记忆、加反思或搜索
目标偏移：加强状态摘要和任务约束4. AgentBench 的实验结论
论文评测了 API 模型和开源模型，结论大致是：顶级商业模型在复杂环境里明显更强，但距离真正实用仍有差距；许多开源模型在传统 benchmark 上看起来不错，一进 AgentBench 就暴露出多轮行动能力不足。
论文指出，阻碍可用 Agent 的关键问题包括长期推理、决策能力和指令遵循。它还观察到，高质量多轮 alignment 数据可能帮助 Agent 表现；代码训练对不同 Agent 任务的影响并不总是单向正面。
这个结论很值得注意。
很多人会以为“代码模型更适合 Agent”，因为 Agent 常常要调用工具、写命令、处理结构化输出。但 AgentBench 提醒我们，代码能力只是其中一部分。Agent 还需要目标保持、环境反馈理解、动作选择、失败恢复和多轮策略。
会写代码，不等于会行动。
5. Agent 评测应该怎么落地
我觉得 AgentBench 给工程团队的启发，可以落成五个原则。
第一，评测单元应该是任务完成，而不是单轮回答。
Agent 的结果是环境状态变化。最终回答好看，但事情没做成，就应该算失败。
第二，保留完整 trajectory。
每个评测样本都应该记录：
初始任务
每轮观察
每轮动作
工具返回
错误信息
最终状态
成功或失败原因没有 trajectory，Agent 失败就很难归因。
第三，动作必须有协议。
自然语言自由输出太难稳定执行。AgentBench 里的环境都有动作格式和动作空间。真实系统也应该尽量把工具调用、命令执行、浏览器动作结构化。
第四，失败类型要分层。
不要只记录 failed。至少拆成 format、invalid action、tool error、timeout、wrong final answer、unsafe action、user constraint violation。只有这样，评测才能指导改进。
第五，评测要覆盖不同环境。
一个 Agent 在浏览器任务强，不代表它在数据库任务强；在短任务强，不代表长任务强；在确定性工具强，不代表开放网页强。Agent 能力是场景相关的。
6. AgentBench 的局限
AgentBench 是 Agent 评测入口，但不是终点。
首先，它主要面向 text-only LLM 的交互环境。现在很多 Agent 已经进入 GUI、浏览器视觉、多模态办公软件和真实 SaaS 环境，这些需要 WebArena、VisualWebArena、OSWorld 等更多基准补充。
其次，模拟环境再真实，也和生产系统有差距。真实工具有权限、数据隐私、网络抖动、并发状态、用户中途改需求、不可逆副作用。AgentBench 不能覆盖这些复杂性。
第三，不同 scaffold 会极大影响结果。同一个模型，配不同记忆、规划、工具解析、重试策略，表现可能差很多。因此评测时要区分“模型能力”和“Agent 系统能力”。
第四，成功率之外还要看成本。一个 Agent 如果花 100 轮才完成简单任务，在产品里可能不可接受。任务成功率必须和步数、延迟、工具调用成本一起看。
7. 我的 takeaway
AgentBench 最重要的贡献，是把 LLM 评测从静态回答推进到交互行动。
它让我们看到：Agent 的关键能力不是“知道答案”，而是在环境中持续选择正确动作。这个过程中，模型要遵守协议、理解反馈、保持目标、修正错误，并在有限轮数内完成任务。
所以评测 Agent 时，我会先写下这张表：
任务目标
初始环境
允许动作
观察格式
终止条件
成功判定
失败分类
成本指标
trajectory 存档如果这些都没有，只拿几轮演示对话说 Agent “能用”，基本不可靠。
AgentBench 不会告诉你哪个 Agent 一定适合你的业务，但它给了一套正确的问题：不要只看模型怎么回答，要看它在环境里怎么行动，失败后怎么恢复，最终有没有把事情办成。
这就是 Agent eval 和普通 LLM eval 的分界线。