Computer Anthology 是一个持续演进的 AI Agent 基准测试家族。这个项目解决的核心问题很直接市面上的 AI 代理评测大多是一次性的静态题库模型刷完一遍就能拿高分但换一个真实工作流就不行了。Computer Anthology 试图用一套不断扩充、不断更新的任务集持续衡量 AI 代理在真实计算机环境里完成复杂任务的能力。如果你正在做 AI Agent 开发、RAG 应用、自动化工具调用或者想评测自己接的模型能不能稳定跑完长链路任务这篇内容可以作为你快速搞清楚这个 benchmark 怎么用、怎么跑、怎么不踩坑的参考。下面先把它和传统 benchmark 的差异讲清楚再按实际落地顺序拆开准备环境、跑通单条任务、批量评估、排查失败最后聊怎么把“持续演进”变成自己团队的评测习惯。1. Computer Anthology 是什么AI Agent 评测不该只看静态题库1.1 它和传统 benchmark 的核心差异传统 benchmark 通常是固定题库。你下载数据跑一遍得到分数然后排名。这种做法的优点是公平缺点也很明显容易被刷。模型可以通过记忆、模式匹配或者针对题目格式的过拟合拿到高分但真正放进一个需要操作文件、调用命令、读取网页、处理报错的真实任务里表现经常断崖式下降。Computer Anthology 的核心设计思路是持续演进。任务会不断加入场景会变化评分方式也会随版本调整。换句话说它更像一个长期跟踪测试而不是一次性的期末考试。我实际跑的时候发现“持续演进”这四个字并不只是宣传点它会直接影响你评测的姿势。比如你不能把上一轮的分数直接拿来跟下一轮比必须保留版本快照。这个细节后面会单独讲。1.2 这类评测真正要回答的问题AI Agent 和文本问答不一样。问答模型只需要给一个最终答案Agent 要在环境里做动作写文件、改代码、执行命令、访问接口、观察输出然后决定下一步。静态题库很难准确覆盖这种“动作序列的正确性”。如果题目总是同一批Agent 就能学会一些作弊策略比如检测到特定关键词就直接跳过执行。持续增加的题目让这种过拟合变难也让评估结果更接近真实能力。所以 Computer Anthology 关心的不是一个模型“知不知道答案”而是“能不能在一台真实的计算环境里把任务做完”。评价一个 Agent 通常要看这几类指标任务完成率最终环境状态是否符合要求输出文件是否正确。过程效率用了多少步、多少次工具调用有没有绕远路。鲁棒性中间出错时能否恢复报错后会不会正确重试。成本调用了多少 token执行了多长时间。这类持续演进家族一般会把上面几类指标落成一个可比较的数值。具体怎么聚合要看对应版本的说明。我实测时更关注的是分任务的成功和失败明细而不是只看总分。总分容易掩盖局部短板比如某个模型在文件操作类任务上非常差但总分被其他简单任务拉回来了。1.3 它适合谁不适合谁适合的场景你在做 Agent 的持续迭代每改一次 Prompt、每换一个模型都需要一个相对稳定的测试集来观察变化。你在做模型选型想比较几个模型在“真实计算机任务”上的完成差异。你刚进入 Agent 开发想建立一套初始评测基线至少知道自己的系统在哪个环节弱。不适合的场景你只是想测单轮对话、文本生成质量。这类基准的任务更偏操作型、长链路单条任务可能要好几分钟甚至更久用来测对话生成是杀鸡用牛刀。你只需要简单判断“模型能不能正确回答知识题”那就选 NLP 类的静态题库更直接。你没有固定评测周期只是临时跑一次。持续演进的题库版本在变分数不好跨版本对比如果不对快照你连自己上个月跑的结果都解释不了。2. 跑之前先确认清楚环境、模型接入和任务配置2.1 评估体系通常需要的运行条件输入材料没有给出具体安装包和硬件要求所以这里只能给一个通用判断框架落地时你要以实际拿到的版本说明为准。一般来说这类评测体系会提供一个或多个容器环境每个任务可能是独立的沙箱。你需要准备能运行容器或虚拟化环境的机器Linux 优先。macOS 和 Windows 也能跑但要注意文件权限和换行符差异很多诡异报错就是这两个问题引起的。足够的磁盘空间。每个任务可能包含项目代码、配置文件、依赖缓存批量跑的时候磁盘增长很快。内存和 CPU 要看题目规模。如果只是跑几个样例8GB 内存一般够用。如果要并行跑整个任务族建议优先加内存而不是只加 CPU。如果需要接入外部大模型就要准备 API key并且确认网络出口稳定。很多 Agent 任务失败并不是模型不行而是调用外部模型时超时或额度不够。2.2 如何把待测 Agent 或模型接进来不同 benchmark 家族接入方式不一样但通常可以抽象成几类你在自己的 Agent 代码里调用评估器提供的工具接口。你把 Agent 打包成服务评估器直接调用你的 API。你写一个适配器把任务描述翻译成 Agent 的输入格式再把 Agent 的输出翻译回评估器需要的动作。我建议第一次接入时先选一条最简单的任务而不是把所有任务都接进来。这样可以快速验证协议是否打通。很多人在这一步踩坑原因不是模型能力差而是动作格式不匹配。比如评估器要求 Agent 返回结构化 JSON你的 Agent 却输出了 Markdown解析就会失败评分自然是 0。这时候不要急着怪模型先看协议层。协议不通能力再强也白搭。2.3 第一批任务要选什么配置怎么写如果你能自己选任务优先选一条“执行路径短、输入输出格式明确”的任务。比如创建文件、修改文本、运行某个命令并检查输出。这种任务容易做断言也容易排查。一个典型的配置和评测运行参数大致长这样注意这是通用示例具体字段以你拿到的版本说明为准# 假设评估器有一个命令行入口 python -m computer_anthology.run \ --task sample_task_id \ --agent my_agent \ --workdir /tmp/bench_workspace \ --output-dir ./results \ --max-steps 30几个关键参数要注意--max-steps限制 Agent 最大动作步数防止死循环。设置太小模型可能来不及完成任务太大则坏任务会拖很久。--timeout单条任务超时时间。给太长批量跑很慢给太短模型可能做不完。--workdir任务执行的工作目录。Agent 只能在这个目录里操作避免污染宿主机。--output-dir结果输出目录。最后评分、日志、屏幕记录都会落在里面。还要确认任务里的依赖是否能正常安装。有些任务要求下载特定版本的工具网络不稳定时容易卡住。我一般会先跑一个空 Agent让它直接返回固定输出用来验证评测器本身能正常完成“失败路径”再用真实 Agent 跑成功路径。这个习惯能帮你区分“评测器坏了”和“Agent 没答对”非常有用。3. 单条任务怎么跑通从启动到结果落盘3.1 启动评测的最小流程第一步先检查环境变量和模型接入。确认 API key 已经配置或者本地模型服务已经启动。第二步确认作业目录有执行权限尤其不要在回收站、网络挂载盘之类的目录里跑。第三步选一条样例任务单线程跑不要开并行。成功启动的标志不是“命令行不报错”而是看到评测器创建了独立工作区Agent 开始收到第一条任务提示并逐步产生动作日志。如果启动后只有任务文本没有动作输出大概率是 Agent 协议没接好。我会在启动后等几秒去任务工作目录里看一眼有没有生成临时文件。这一步能很快判断评测器是否真的把环境创建出来了比盯着命令行输出更可靠。3.2 怎么判断任务真的“跑通了”跑通有两个层面很多人会把它们混在一起。流程层面Agent 完成了若干动作最后评测器生成了结果文件没有抛异常。任务层面Agent 的最终环境状态符合要求拿到 pass 标记或 1.0 分。我判断任务跑通时会先看流程层再看任务层。如果流程正常但没有 pass这是真实的能力差距值得分析。如果流程层就挂了说明环境、协议或依赖有问题不值得分析模型能力。这一步能省下大量排查时间。3.3 输出目录和日志里该留下什么建议至少保留以下内容Agent 完整轨迹日志。每一步动作、观察、思考都要能回放。评测器的原始输出。包含开始时间、结束时间、耗时、退出码。工作目录快照。尤其是任务结束时文件列表这样能反向检查 Agent 到底创建了什么、改了什么。请求次数和 token 消耗。如果你关心成本这组数据不能少。这些日志在后续排查时非常有用。当你准备写技术报告、做团队周报或对比模型版本时有完整日志才能解释分数变化的原因。只留一个总分是远远不够的。3.4 一个常见反例任务描述和文件系统差异有一个反例让我印象很深。任务要求“将 config.txt 里的端口号从 8080 改成 9090并启动服务”。Agent 在日志里看起来一直在修改文件最后评测器却判定失败。后来发现工作目录里有大小写不同的两个 config 文件Agent 改了Config.txt评测器检查的是config.txt。这不是模型笨而是任务描述边界不够清晰或者评测器在 Linux 下只认精确文件名。遇到这种情况先确认环境里的文件系统差异再做能力结论。在 Windows 上不区分大小写的路径到 Linux 上就可能变成两个文件。Agent 评测里这种细节非常多习惯了就好。4. 从单条任务到批量评估吞吐、失败和一致性4.1 批量评估前要设定的参数单条跑通之后再开批量。这个顺序不能反。批量评估要控制几个参数并发数取决于你机器的内存、CPU 配额以及外部 API 的限流。不要一上来就开 16 并发。我一般先设 2跑几条看资源占用和失败率再逐步调高。重试次数网络抖动、外部接口超时很常见建议设 1 到 2 次。但要注意有些任务本身具有不可逆副作用比如创建资源、发送文件重试前要保证状态可恢复。超时单任务超时要在平均值和最大值之间取一个合理值。给太小长任务全部失败给太大坏任务会把队列拖死。不要一上来就开最大并发。先用 2 并发跑几条确认日志、输出目录、资源占用都正常再逐步往上加。4.2 结果表怎么看哪些分数不可信批量评估结束后的输出通常是 CSV 或 JSON 表格包含任务 ID、模型名、得分、耗时、状态。看表格时先看状态分布再看平均分。如果大量任务状态是 timeout 或 error平均分就没有意义应该先修复环境再重跑。分数不可信的几种情况输入文件用了错误编码Agent 读不了内容最终得分低。评测器断言语写得过于严格比如要求完全一致的字符串而任务本身就允许多种答案。任务里包含外部网络请求波动大同一 Agent 不同时间跑分数明显不同。这些情况下先修正评测条件再谈模型能力。不然你会因为一个编码问题误判整个模型的真实水平。4.3 一致性和可重复性持续演进 benchmark 的一个特点就是版本变化。你跑了一版结果升到新版本后可能任务集变了旧分数和新分数不能直接比较。因此批量评估时建议每次评估都记录 benchmark 的版本号或 commit 号。记录模型版本、Prompt 版本、Agent 代码版本。保留完整结果文件和日志而不是只保留总结分数。我自己的习惯是给每次评估打一个 tag比如agent_v0.3_prompt_v2_anthology_v1.2_run1。这样后面回查的时候一句话就能定位是哪次跑出来的。听起来有点繁琐但没有这套记录持续演进反而会成为你的负担。4.4 资源占用怎么看批量跑的时候不要只盯着分数还要看资源。建议每隔一段时间记录内存、CPU、磁盘占用。如果内存持续上涨可能是单条任务的工作区没有被回收跑完几十条之后机器开始卡。如果磁盘占用暴涨检查是否每个任务都缓存了模型权重或依赖。出现这种情况可以在批量脚本里增加资源清理步骤把已结束任务的临时文件删掉。另一个容易被忽略的是网络连接数。如果你接入的是外部模型 API高并发会导致大量请求同时发出很容易触发限流。这时候增加并发并不会提速反而会让超时和失败率上升。5. 报错和低分不一定代表模型不行按这个顺序排查5.1 第一层看评测环境是不是题目自身没起来排查时不要先怀疑模型。最先看的是评测器有没有正常创建沙箱依赖有没有安装成功任务文件有没有下载完整。一个很常见的现象是任务需要 Python 3.10但基础镜像里只有 3.8Agent 执行命令直接失败得分低。这时候关掉这个环境相关的任务看剩下的任务分数是否正常。如果其余任务分数都不错说明问题在环境不在 Agent。5.2 第二层看 Agent 的日志是卡住、报错还是超时查看轨迹日志可以帮助区分三类情况Agent 完全没有产生工具调用只是反复输出思考。这可能是调用接口格式不对模型没理解该用什么工具或者工具列表没有正确传入。Agent 尝试了多次工具调用但每次都失败。看看具体是什么错误是权限、路径、命令不存在还是输出格式不会被解析。Agent 长时间停在一个步骤上。可能是模型陷入循环或者等待某个外部接口长时间没有响应。日志里出现频率最高的错误通常就是瓶颈所在。先解决高频错误比东一榔头西一棒子要有效得多。5.3 第三层看评分逻辑是不是任务判据太严或者太松评估器本身也可能有 bug。判断方法是人工按正确方式执行一遍任务看能否 pass。如果人工能 pass 但 Agent 不能可能是 Agent 能力问题。如果人工执行几乎不可能 pass那就检查评测器的断言逻辑是不是写得太苛刻。持续演进的题库偶尔会加入新任务但这些任务的判据不一定经过充分校验。我遇到过一个问题任务要求输出“一份 CSV 报告”评测器却只接受特定列名连大小写都要求严格一致。这种低分就不应该算在模型头上。遇到异常低分先去看评测器的断言代码再下结论。5.4 第四层看模型本身的幻觉和步骤规划如果环境、日志、评分都正常再回到模型侧。Agent 模型常见的失败模式是幻觉化工具调用。具体表现包括调用了不存在的命令、自己编造文件名、把任务描述里的示例直接当成输出。另一种是长链路任务里忘记上下文做了两步之后开始重复执行第一步。这类问题通常要靠 Prompt 结构、工具上下文压缩、或者切换到长上下文模型来解决。这里也要提一句模型产生幻觉不一定完全是模型的问题。任务描述太长、工具返回信息过多、历史记录截断都会让模型丢失关键信息从而生成看似合理但实际错误的动作。实际调优时我会先看上下文里有没有被截断的迹象。5.5 排查顺序可以记成一句话“环境、日志、评分、模型”。不要一开始就换模型或调 Prompt先把前三层确认清楚。很多时候你以为 Prompt 写得不好其实是任务文件名大小写错了。这里放一个引用方便你贴在笔记里排查 Agent 评测问题时固定顺序是环境、日志、评分、模型。环境出问题就只看环境日志有异常就顺藤摸瓜评分可疑就人工试跑最后才轮到模型调优。6. 把“持续演进”用起来让评测跟着你的 Agent 一起长6.1 自定义任务如何提交一个贴近真实业务的新题Computer Anthology 这类持续演进的家族通常允许社区或用户贡献新任务。如果你在内部团队使用建议把真实业务中的高频操作场景抽象成任务。例如你做数据分析工具可以新增一条“读取 CSV、清洗空值、生成汇总图表并保存到指定目录”的任务。抽象时要给出三个要素明确的任务描述。告诉 Agent 当前环境里有什么文件需要完成哪些操作最终要得到什么。可检查的成功条件。不要只写“处理数据并输出结果”要写清楚最终文件的路径、格式、关键字段内容。干净的执行沙箱。任务依赖的环境要能在空目录里重建不要依赖 Agent 之前留下的临时状态。自建任务的另一个好处是可以沉淀团队内部的评测标准。新同学进来之后先跑一遍内部任务集就能快速了解系统哪些地方容易踩坑。6.2 定期重跑和基线对比持续演进的评测体系要配合固定节奏使用。建议每完成一轮 Agent 迭代就重跑一遍基线任务集并记录分数变化。同时在任务集更新后先用上一次的 Agent 版本重跑一遍确认新任务集对旧版本的难度变化。否则你无法判断分数下降是因为 Agent 退化还是因为题目变难了。可以做一个简单的基线表时间评测版本Agent 版本成功数总任务数成功率备注2024-XXv1.2v0.3-prompt2345068%新任务集上线后同步重跑2024-XXv1.2v0.4-prompt1415082%主要优化了错误重试2024-XXv1.3v0.4-prompt1395571%新增任务导致成功率下降需要分析这种表在团队协作时非常有用能快速定位是哪一次改动把成功率拉低了。如果没有版本记录这张表根本填不出来。6.3 这种评测方式的边界持续演进也有代价。进度追踪和跨版本可比性变难因为你不能只看一个总分必须保存完整的评测快照。另外任务难度没有标准化新增任务可能太简单导致分数暴涨空欢喜一场。更稳妥的做法是保留一组固定的核心任务作为长期基线再叠加一组动态任务作为能力扩展。也有研究者在做自我改进型 Agent依赖的不只是单次评测分数还有经验积累和长周期反馈。这种方向对评测体系提出了更高要求任务不仅要能测出当前能力还要能支持 Agent 在完成任务后沉淀经验再在后续任务中复用。持续演进的任务集合天然适合做这类实验但它不是一个简单开箱即用的工具需要你投入评测工程化的工作。最后还要提醒一点不要把这个评测当作业务验收的唯一标准。它能反映 Agent 在通用计算机任务上的完成能力但真实业务还有数据权限、安全合规、用户反馈、维护成本等因素。评测分数高只能说明在任务覆盖范围内具备一定能力不能简单等价于“可以上线”。如果你正在做 Agent我建议先不要急着追最新分数榜单而是把自己的任务集跑熟把失败文件翻一遍再决定下一步优化方向。把单任务跑稳、批量评估跑通、失败日志留好这套流程比任何单项指标都更能说明问题。