如果你最近在开发 AI Agent 应用很可能遇到过这个场景模型在公开 benchmark 上拿到了很漂亮的分数但一放进真实的业务环境效果立刻缩水一大截。很多人第一反应是“模型不够强”或者“prompt 没调好”但再往下挖就会发现问题往往出在评测这一层——用来衡量 Agent 能力的 benchmark 本身已经失真了。AI Agent 的评测evals for AI agents正在成为整个 Agent 开发链路里最容易被低估、却又最影响迭代速度的环节。传统的静态 benchmark 就像一张固定的考卷模型考过一次之后完全可以通过记忆答案拿到高分。但真实世界的任务从来不是固定考卷。Computer Anthology 这个名字指向的正是一个更接近工业界需求的思路它不是一份一次性数据集而是一族会持续演进、持续修正、持续防污染的 benchmark 体系。这篇文章会从三个层面展开先讲清楚 Computer Anthology 这类“演进式 Agent benchmark”为什么会出现再拆解它的核心设计与传统 benchmark 的差异最后给出一个可以实际落地的、同样思路的最小评测框架实现。如果你正在做 Agent 应用、工具调用或者需要为团队搭建模型评估体系这篇文章会比较对路。即便你现阶段只想快速判断一个模型的真实能力看完也能建立一套更有价值的判断标准。1. 为什么说静态 benchmark 正在拖 AI Agent 的后腿先澄清一个容易混淆的点。很多人把“评测”当成一个附属工程觉得模型训完、把测试集跑一遍、拿个分数就结束了。但在 Agent 开发里评测不是终点而是训练与迭代的起点。如果评测分数不可信后面所有基于分数的调优决策都是空中楼阁。在实际工程里这个误解的成本很高团队花大量时间优化 prompt、调整工具调用逻辑最后发现评判标准本身是漂移的等于白做。传统 LLM benchmark 的失效主要有三个明显信号值得每个做 Agent 的人认真对待。第一个信号是数据污染。当某个数据集反复出现在预训练语料、指令微调语料、甚至公开榜单里模型完全有可能见过标准答案。静态 benchmark 很难感知这一点因为它没有“任务版本”的概念——官方加了新题旧题还在模型可以用旧题分数掩盖新题的真实能力。对 Agent 来说任务形态更复杂污染更难被发现一个包含完整操作步骤的示例如果落入训练语料后续评测就变成了一道“记忆题”而不是“推理题”。第二个信号是任务形式过于单薄。很多经典 benchmark 以多选、填空、生成一段文本为主但 Agent 的真实任务是“在环境里做决策”读写文件、调用 API、操作浏览器、编排工具链。这已经不是 token 生成问题而是一个系统工程问题。用语义理解类任务去近似评估 Agent等于用语文考试判断一个人能不能当好项目经理。Agent 评测必须考察模型与环境的交互能力而不是仅仅考察它的语言生成能力。第三个信号是分数饱和。头部模型在部分公开榜单上已经逼近 90 分甚至更高差异被压缩到很小这时候榜单分数对选型和迭代的帮助非常有限。真正能拉开差距的是那些模型没见过、需要现场推理、现场试错的新任务。所以 Computer Anthology 这类演进式 benchmark family 的核心价值不是做一个更难的静态试卷而是让评测体系永远有“新题”出现迫使模型和 Agent 系统不停地在边界上被检验。要理解 Computer Anthology首先要接受这个判断Agent 评测应该从“一次性试卷”转向“持续运行的测试工厂”。这不是锦上添花而是 Agent 工程化道路上的必备基础设施。2. Computer Anthology从“一张试卷”到“一组持续演进的选集”2.1 Anthology 到底指什么Anthology 原意是“选集”通常由多篇作品按主题或时间编排而成。Computer Anthology 这个名字本身就揭示了它的设计立场它不是一份考卷而是一个不断更新的任务合集。每一批新任务、每一个新环境、每一轮修正都会作为新版本并入这套“选集”而不是把整个体系推倒重来。可以把它理解为三个层面的设计任务层包含多种类型、多种难度、多种交互方式的 Agent 任务。任务之间有统一描述格式但执行环境可以完全不同。版本层每个任务都有版本号、创建时间、作者、依赖环境等元信息。任务会被持续增补、修订、淘汰。评估层评测结果与任务版本绑定跑分时必须同时记录任务集的 snapshot确保不同时间的分数可对比。这样做的好处是它把一个“考完就结束”的评测过程变成了持续运转的工程流程。这也是“family”这个词的含义不同任务、不同环境、不同评估目标被组织成一族相互关联的评测工具而不是孤立的数据包。2.2 演进式评测的三个核心机制从设计理念看Computer Anthology 这类演进式 benchmark family 的典型特征是防污染优先。因为任务集持续变化模型无法通过简单记忆旧题来稳定刷分。每一次新版本加入都相当于一次新的现场考试。评测任务不再只是一堆静态 JSON而变成了像代码仓库一样维护的对象有分支、有合并、有回滚。这意味着评估工作本身被纳入了一种可持续运营的轨道这是它和一次性数据集最重要的区别。第二个核心机制是版本标记。每个任务都有明确的版本号和改动历史跑分报告会记录“用的是哪个版本的任务集快照”。没有版本标记两个团队分别跑了同一个 benchmark结果却因为任务被悄悄改过而完全不可比。版本标记让“分数的历史对比”成为可能也让任务演进对结果造成的影响变得透明。第三个核心机制是环境绑定。Agent 任务的结果高度依赖执行环境同一个动作在 Ubuntu 22.04、macOS、或者离线受限容器里可能得到完全不同的结果。演进式评测会把操作系统、依赖、网络策略、工具版本都写入任务定义实现环境的可复现性。环境不可复现分数就没有讨论的意义。3. 为什么 AI Agent 评估比传统模型评测难一个量级要做 Agent 评测先要理解 Agent 评测为什么难。如果沿用文本生成的思路去设计评测任务很容易做出表面合理、实际无效的结果。Agent 任务的本质从多个方面拉高了评测难度。3.1 开放状态空间传统 NLP benchmark 把任务压缩成一个输入输出对上下文是有限的。Agent 则要在真实或模拟环境中执行多步操作每走一步环境状态都会变化后续可走的空间也随之膨胀。让 Agent“整理一份日志目录”看似简单实际涉及文件系统权限、目录结构、编码格式、异常文件、磁盘空间等大量变量。Agent 面对的不是固定选项而是接近无限的行动序列。环境状态的开放性带来两个后果一是评测覆盖不可能穷尽只能通过任务抽样的方式逼近真实能力二是不同 Agent 可能找到不同的解决方案评测器必须能识别“等价结果”而不是只认死板的标准输出。这已经超出了传统选择题判分的范畴更像在看“一个人如何应对开放式任务”。3.2 多步决策的信用分配Agent 任务往往需要 10 步甚至 30 步的连续决策。一个 20 步的任务可能前 15 步都走得很好第 16 步因为一个 API 参数写错导致整体失败。按传统“最终结果对错”的二元标准这类 Agent 会被判定为失败。但作为工程师我们更想知道它走到哪一步、错在哪里以便优化工具调用策略。这要求评测体系采集中间状态、执行轨迹和分步日志而不是只给一个总分。这也是很多团队把 Agent 评测从“自动化打分”升级为“轨迹分析”的原因。好的 Agent 评测应该能回答“模型在哪个环节最容易出问题”而不是简单告诉开发人员“这次跑挂了”。3.3 环境变量与标准模糊Agent 的同一个动作在网络可用与网络隔离的环境中结果完全不一样。依赖安装、网络策略、沙箱隔离、工具版本都会成为隐形变量。如果评测框架不做环境快照得到的分数字面相同实际不可比。测试任务里的环境漂移是 Agent 评测结果最隐蔽的噪声来源。评价标准也常常不够明确。文本生成的答案可以跟参考答案做语义比对Agent 任务却经常是“条条大路通罗马”同一个目标Agent 可以写 Python 脚本、调用 shell 命令、或者直接读日志文件。评测器需要处理多种等价路径而不是只认预设的输出。这些特性叠加在一起意味着 Agent 评测必须同时处理正确性、效率、稳定性、安全性等多个维度并且要保留足够丰富的执行轨迹供人工分析。这也是为什么单一静态 benchmark 很难真正评价一个 Agent 系统的能力不是分数设计得不够细而是它能提供的信息量天然不足。要支撑 Agent 迭代评测必须是多维的、可追溯的、和任务环境绑定的。4. Computer Anthology 与传统 benchmark 的核心差异为了更直观地理解差异可以用下面这张表做一个对照。这里的“传统 benchmark”指以 MMLU、HumanEval、GSM8K 等为代表的经典评测方式“演进式 benchmark family”则指 Computer Anthology