Computer Anthology这个名字第一眼看去非常像一本程序员案头书的标题。它让我想到的不是某个具体模型也不是某个排行榜而是“持续演进的 benchmark family”这组词背后的一整套评测观。过去我们评估模型通常准备一套固定试题跑完拿到分数结论就结束了。但对 AI agent 来说这套逻辑正在快速失效。一个 agent 需要理解任务、调用工具、观察反馈、决定下一步还要能在失败之后修正行为评测它的方式应该更像长期观察一个人如何工作而不是让他做一张考卷。Computer Anthology 的定位就是把评测做成一个持续演化的“任务选集”而不是一套静止的题库。这篇文章想聊的不是某个具体分数而是这种“持续演进”背后的设计逻辑、工程难点以及每个做 Agent 的人能从中学到什么。1. 为什么静态 benchmark 已经不够用了1.1 传统 benchmark 考的是“知识点”Agent 考的是“综合能力”传统 NLP 模型评测是典型的“输入–输出”模式给定一句文本预测一个标签或一段答案模型和环境之间没有多轮交互。这样的评估可以做成固定题库因为每道题都是独立的不需要考虑上下文演化。但 Agent 评测完全不同。一个 agent 在浏览器里执行任务需要读取页面、点击输入、等待加载、处理弹窗、判断下一步甚至还要在工具调用失败后重新规划。这些步骤彼此依赖前一步的小失误会累积成后一步的大失败。举个例子一个 agent 可能最后成功提交了表单但整个过程用了 50 步期间触发了 3 次权限风险甚至误点了无关区域。这种“过程性质量”在静态题库里很难被捕捉因为你只看得到最终答案看不到决策路径。所以 Agent 评测更像是“综合能力考试”而不只是“知识点考核”。综合能力考试需要多样化的任务、变化的场景、动态的环境反馈不能靠一张固定试卷走天下。1.2 静态题库的三个致命问题老化、污染、泛化失真静态题库至少有三个在 Agent 场景里尤其致命的问题。第一是任务老化。真实软件环境每个季度都在变浏览器更新了渲染逻辑某个网站的按钮位置变了旧任务描述的步骤可能已经不再符合现实。如果 benchmark 不更新它评测的能力就会越来越偏离实际使用场景。第二是数据污染。任务一公开就可能被训练数据无意收录。模型看过测试题之后分数会虚高。尤其对 agent 这种需要“在特定环境里操作”的任务如果模型见过截图、HTML 结构或任务描述它很可能会走捷径而不是真正学会解决问题。第三是泛化失真。在固定题库上得高分只能说明模型记住了这个环境里的特定解法不能说明它能处理新任务。真实世界里每个用户的操作路径都不一样agent 必须能处理“没见过的情况”。静态题库恰恰无法验证这种能力。这三大问题叠加让“持续演进”从一个可选项变成了必选项。但持续演进本身并不容易它会给评测体系带来更多工程挑战。2. “Benchmark Family”和“Anthology”背后的设计意图2.1 从一张试卷到一个任务家族Anthology 在英文里是“选集、文集”的意思。一本文学选集通常会收录不同年代、不同作者、不同风格的作品每次再版时可能增删篇目整体却始终保持一条主线。Computer Anthology 用这个词明显不只是想做一个“测试集”而是想建立一个长期生长的任务集合。一个 benchmark family 的特点是它不追求用一套题覆盖所有能力而是分领域、分难度、分版本地组织任务。类似一个家族里既有核心成员也有新加入的成员。核心任务用于长期追踪模型能力趋势新任务则不断注入当前模型还不太擅长的场景。这种结构对 agent 评测特别重要。因为 agent 的能力树很复杂有的任务考操作准确性有的考规划能力有的考错误恢复能力。一个统一的静态分数根本无法告诉你模型到底强在哪、弱在哪。而一个分层、分域的 benchmark family 能提供更清晰的“能力画像”。2.2 “不断演进”的几个可能机制我并没有见过 Computer Anthology 的项目内部实现所以这一节更像是从通用工程实践出发谈谈“持续演进”通常会由哪些机制构成。一个可持续演进的 benchmark family通常不是简单地在原文件后面加几道题而是需要一套类似开源项目的运作方式持续收集新任务来源比如真实用户操作日志、产品反馈、新工具的使用流程。经过审核与标准化把原始操作转成可重复执行的任务定义。保留稳定子集确保历史成绩仍然可以比较。建立版本发布机制每次更新都有版本号、变更日志和回滚方案。设计任务退役规则当某个任务区分度太低或已经过时时把它标记为退役或移动到历史目录。这个过程很像软件的迭代开发。如果任务更新没有版本管理没有审核流程没有回归测试那所谓的“持续演进”就只是一个宣传词而不是一个可运行的系统。2.3 为什么一个版本打天下对 Agent 尤其不成立模型榜单每年都在刷新静态 benchmark 的使用寿命越来越短。如果 benchmark 不动模型很容易过拟合分数快速饱和用户再也看不出模型之间的差异。但如果 benchmark 频繁变动每版都大量换题历史成绩又没法比较。这是评测设计里最核心的矛盾。Computer Anthology 用“family”来回应这个问题意味着它可能把任务分成多个层次一部分长期不变作为“锚定题”另一部分动态更新作为“压力测试”。两类任务共同维护才能既感知能力变化又保留历史坐标。这种设计对 Agent 尤其重要因为 Agent 的评估不只是“分数高不高”而是“这个 agent 是否在真实工作流中靠谱”。真实工作流每季度都在变一个不能跟着变化的评测系统很快就会变成模型的“历史成绩单”而不是能力的“体检报告”。3. 真正难的从来不是“出题”而是让分数有意义3.1 可复现性环境、依赖与随机性很多团队搭一个 Agent benchmark 时最花时间的不是写任务描述而是让同样的任务在同样的条件下能复现。Agent 评测往往要在浏览器、虚拟机、桌面环境或 API 沙箱里完成。运行环境稍有不同结果就会大幅波动。比如浏览器版本不同某些元素选择器可能失效依赖库版本不同工具调用行为可能变化网络延迟或随机种子不同agent 的决策路径也会不同。一个可持续演进的 benchmark必须把环境直接纳入版本管理。镜像、浏览器版本、系统依赖、初始状态都要和任务定义一起固定下来。如果一个分数无法复现那它就没有追踪价值。你连上个版本的结果都复现不了又怎么判断这次成绩提升是因为模型变强了还是因为环境变了3.2 版本切换与长期可比性当 benchmark family 发布新版本时一个很现实的问题就出现了新版分数和旧版分数怎么比常见做法是保留一个“注册任务子集”。这个子集在多个版本中保持不变无论任务池如何演进模型每次都要跑这一组注册任务。这样即使动态任务全部更新你仍然可以通过注册任务子集的分数变化判断模型能力是上升还是下降。另一种做法是随机等分任务到多个平行表单用等价变换实现分数换算。但这实现成本高而且很难保证新旧版本任务难度完全一致。对大多数团队来说保留稳定子集是更稳妥的方案。这也是 benchmark family 和普通 benchmark 的关键区别所在它不追求每个版本都完全取代上一版而是让不同版本通过共同的“锚定任务”形成一条连续的追踪曲线。没有这个机制持续演进只会制造一堆不可比的分数碎片。3.3 指标设计完成率之外还要看过程成本Agent 任务是否成功只是一个最基础的指标。真正决定一个 agent 好不好用往往要看过程成本。一个 agent 花 100 步完成任务另一个花 10 步完成最终分数如果只看成功与否两者没有区别。但在真实生产里前者会消耗大量时间、算力和 API 调用成本。一个成熟的 benchmark family应该在指标层做多维设计。下面是一个比较通用的指标框架指标维度说明为什么重要任务完成率最终成功完成任务的比例衡量整体能力的基础指标过程成本步数、工具调用数、耗时、资源消耗衡量决策效率和部署成本鲁棒性环境扰动、输入变化下的表现衡量真实场景泛化能力安全性是否触犯了约束规则、是否产生危险操作决定能否进入生产环境版本稳定性跨版本重复运行的方差衡量评测信度与模型稳定性如果只追踪一个完成率你会错过大量信息。比如 agent 可能通过大量试错才成功这在评测中没有被惩罚但在真实用户那里是灾难。多维指标能帮助你区分“碰巧会做”和“真的懂怎么做事”。4. 如果你也想为 Agent 搭一个“可持续评估池”4.1 先定边界评估的“最小环境”是什么很多人想做一个“全面评测”的 benchmark一开始就规划几十个任务覆盖各种软件。这种做法往往会在第一个月就陷入混乱。更建议先从一个小边界开始选一个你真正关心的场景比如“在测试网页上完成信息录入”然后把这个场景固化成可重复运行的最小环境。最小环境包括固定的操作系统镜像或容器镜像固定的浏览器或运行时版本固定的初始数据状态固定的任务描述模板固定的输出记录格式先不要追求大而全。一个最小且稳定的环境是后续所有演进的基础。如果环境本身每天都在变化你收集到的分数就会失去参照系。4.2 把任务池做成三个分区稳定题、动态题、哨兵题从工程经验看一个小而可持续的评估池可以按三个分区来组织。第一类叫“稳定题”是长期不变的核心任务。它们代表当前 agent 最重要的能力基线用于每周或每版本发布时复跑。稳定题不需要多二十到五十个即可核心是可复现。第二类叫“动态题”是定期新增和淘汰的任务。它们不一定非常复杂但一定要反映新出现的使用场景或工具能力。动态题的作用是防止 agent 过度拟合稳定环境逼着模型去处理没见过的情况。第三类叫“哨兵题”是一些专门用来暴露“刷题”行为的任务。比如故意设计一个模糊指令看 agent 是会主动澄清还是盲目执行故意在环境中制造一个异常按钮看 agent 是否能识别风险。哨兵题不需要大量但要有针对性它们是评测体系的“探针”。这三个分区共同构成一个可复用的任务池框架稳定题追踪长期趋势动态题推动泛化哨兵题检测反模式。4.3 用版本号管理评测集而不是覆盖式修改持续演进的 benchmark必须像代码项目一样管理版本。每个任务要有独立 ID 和版本号任务定义文件、环境配置、参考答案都要用版本控制工具管理。不要在同一个任务上原地修改。如果一个任务改了几行描述它本质上已经是一道新题你要给它新的版本号并保留旧版本记录。否则历史成绩将无从追溯。发布新版本时建议走三个动作更新变更日志写清楚新增、修改和退役了哪些任务。打 tag比如family-v0.3.0确保任何人都能 checkout 到对应的任务集。做一次“锚定回归”用稳定题确认环境变化没有引入意外波动。这套流程看起来简单但能避免绝大多数评测混乱。4.4 记录轨迹而不是只记录最终结果Agent 评测和传统模型评测最大的不同在于过程轨迹本身就是珍贵的调试数据。不要只记录一个最终成功或失败要保存完整的交互日志模型输入、工具调用、返回结果、屏幕截图、异常堆栈、时间戳。如果没有轨迹当分数突然下滑时你几乎无法定位原因。有了轨迹你可以回放整个流程看到 agent 是在哪一步走偏的是任务描述有歧义还是模型陷入了死循环还是工具返回了异常。这会让 benchmark 从“打分器”变成“调试器”。4.5 常见坑点与排查顺序在实际使用中如果你发现 agent 在某个 benchmark 版本上分数显著下降先不要怀疑模型本身。一个相对可靠的排查顺序是检查环境版本依赖、浏览器、镜像、系统库是否变化。检查任务定义新版本任务是否存在歧义、错误或不可通过的问题。检查评测接口提示模板、API 回调、工具权限是否发生意外修改。检查 agent 代码是否无意中依赖了旧环境中的特定字符串、按钮文字或 DOM 结构。检查随机性采样种子、网络延迟、测试顺序是否导致结果波动。按照这个顺序排查比直接调模型参数有效得多。大部分所谓“能力下降”其实是环境或基准变更导致的幻觉。5. 对开发者、研究者和使用者分别意味着什么5.1 作为 Agent 开发者不要把 Benchmark Family 当成题库如果你正在开发 Agent看到一个新 benchmark 后的第一反应可能是“赶紧去跑分”。这种心态可以理解但会把你的注意力带偏。持续演进的 benchmark family 之所以刻意保持动态就是为了让你无法通过背题取胜。更好的做法是把 benchmar family 当成一份“任务需求清单”。每个任务都是一条真实用户场景的压缩表达。你要从这些任务中提炼通用能力比如如何从模糊指令中提取目标如何在工具调用失败后重试如何判断风险边界。这些能力才是持续演进任务集里真正被考察的东西。当你把 benchmark 当作题库时你只会在训练集上过拟合当你把它当作需求说明书时你才有可能做出一套可迁移的决策系统。5.2 作为 Benchmark 设计者长期维护比一次性构建更消耗资源很多人低估了维护一个 benchmark 的成本。一次性构建一批任务通常只需要几个月的精力但要让它可持续演进你需要持续的运营和工程支持。一个可持续维护的 benchmark family 至少需要任务收集团队或社区贡献渠道任务审核规范确保每道新题都有明确目标和参考解法环境管理工程保证运行环境可以重建回归测试机制防止新版破坏历史任务定期发布计划和变更日志这已经是一个软件项目了而不只是“出题”。如果公司没有长期投入的打算那更建议做一个小而精的评估池而不是盲目搭一个大而无法维护的基准。5.3 作为使用者如何判断一个 Benchmark 是否真的“可持续”当你拿到一个基准测试项目如何判断它是真演进还是只发了个新版本可以从几个信号快速判断是否有公开的版本历史能看到从 v0.1 到现在的任务变化。是否把任务分为稳定子集和动态子集。是否发布过更新日志而且日志里写清楚任务增删原因。是否提供任务来源和审核流程说明。是否鼓励外部提交新任务而不是只靠内部维护。如果这些信息都稀缺那“持续演进”可能只是一个 marketing 层面的词而不是可以依赖的评测基础设施。反之如果一个 benchmark 能让你看到一条连续的能力追踪曲线那它才是真正有用的评测体系。6. 一个更深的变化评测从“考试”走向“持续观测”6.1 自适应评测当模型学会刷分评测也要学会“换题”随着 Agent 能力增强静态评测会越来越快地失效。模型可能短时间内就在稳定题上饱和甚至记住任务里的关键特征。这时候评测系统必须有能力“换题”甚至根据模型当前表现自动调整难度。“持续演进”的本质就是让评测系统和模型能力形成一种动态博弈。模型变强之后评测系统要能提出更难、更开放、更接近真实世界的任务。这种思路比传统的固定榜单更复杂但它更符合 AI agent 进入真实生产环境后的需求——真实世界本来就不会告诉你“你按这个步骤做就能完成”。6.2 评测体系的透明度与可追溯性会越来越重要当 AI agent 开始处理合同、操作财务系统、控制生产流程评测分数就不能只是一个内部参考数字了。它必须能回答更严格的问题这个任务的数据从哪里来模型在训练阶段是否见过类似环境这个分数是在哪个镜像、哪个版本、哪个参数配置下得到的一个可持续演进的 benchmark family必须像开源软件项目一样把版本、任务来源和运行环境都记录下来。只有评测结果可审计它才有资格成为信任依据。这可能是“持续演进”相对于静态题库更重要的隐藏价值它从设计上要求你维护一份完整的数字证据链。6.3 持续演进的最终目标是帮助 Agent 适应“非固定任务”真实世界的任务从来不是标准化的。每个用户的使用习惯不同每个软件系统的配置不同每个业务链路里都会出现文档里没写过的异常。Agent 要真正可用必须能在“没见过的情况”中保持合理决策。Computer Anthology 这类项目真正值得长期关注的地方不在于它某一个版本的任务有多难而在于它把评测定义成了一种持续生长的系统。它提醒我们一个 agent 是否可靠不是看它现在能完成多少固定题目而是看它面对一个不断变化的任务家族时能否持续稳定地输出正确行为。这个视角比任何一个排行榜上的数字都要重要。所以如果你也在做 Agent最高优先级的任务不是去某个静态榜单上刷到第一而是着手建立一套能长期反馈、能暴露短板、能随环境更新的评估系统。哪怕一开始只有十个任务只要它们被分成稳定题、动态题和哨兵题并且用版本管理保护起来它们就比一套庞大却永远不会更新的题库更有价值。当你的 Agent 能在一个持续演进的任务家族里保持稳定那个分数才真正配得上被记下来。
