最近评测 AI Agent 的项目越来越多了，但多数 benchmark 都是固定测试集，跑完就过期。这次我们来看一个定位不太一样的项目：Computer Anthology。它不只是一套题，而是一个持续演进的 benchmark family，专门用来评估 AI Agent 在真实计算机任务中的表现。
先说最值得关注的几点：这个项目不是单个数据集，而是一组按任务类型、难度和评测目标组织的基准集合；设计上强调“持续更新”，会随着 Agent 能力提升不断补充新任务；评测覆盖的不是聊天问答，而是让 Agent 真正操作电脑完成目标任务。这意味着它可以用来衡量一个 Agent 能不能干活、能在多大程度上替代人工操作，而不是只会“说话”。
本文会围绕 Computer Anthology 的定位、适用场景、部署方式、评测任务设计、批量评测流程、结果解读和常见问题展开。如果你正在做 Agent 应用落地，或者需要一套可扩展的评测框架来量化 Agent 效果，这篇文章可以直接收藏。
1. 核心能力速览
| 能力项 | 说明 |
|---|---|
| 项目类型 | AI Agent 基准评测集（benchmark family） |
| 核心定位 | 评估 Agent 在真实计算机操作任务中的表现 |
| 设计特点 | 持续演进、任务集合可扩展、按能力维度分层 |
| 主要功能 | 任务定义、评测执行、结果记录、能力对比 |
| 运行方式 | 本地运行评测脚本 + 调用被测 Agent |
| 是否支持 API | 取决于被测 Agent 的接口方式，评测框架侧建议提供 CLI / Python API |
| 是否支持批量任务 | 建议设计批量评测任务队列 |
| 硬件要求 | 纯评测框架要求不高；本地跑 Agent 模型需要 GPU，按实际模型而定 |
| 显存占用 | 与被测模型相关，评测框架本身不直接占用大量显存 |
| 适合场景 | Agent 能力评估、版本回归、模型选型、任务难度分层 |
| 学习成本 | 中等，需要理解任务定义和评测指标 |
这里要说明：Computer Anthology 的项目源码、具体任务数量和评测脚本，以官方仓库文档为准。下面给出的部署和调用示例属于通用实践模板，实际使用时需要按项目结构替换路径和命令。
2. 为什么需要 “持续演进” 的 Agent 基准
先看行业里普遍存在的问题。前几年大家评测 Agent 主要看几个维度的选择题、多轮对话、工具调用成功率，这些评测集固定不变。但问题很快就暴露出来了：
第一，Agent 模型迭代速度很快。一个模型如果专门针对某个公开测试集做优化，很快就会“刷题刷过拟合”，分数上去不代表真实能力提升。
第二，真实计算机任务不是固定题型。让 Agent 写文件、改配置、跑命令、调试代码、操作浏览器，这类任务没有统一标准答案，只有目标和约束条件。固定 benchmark 很难覆盖这些动态场景。
第三，同一个 Agent 在不同难度任务上的表现差异巨大。把简单任务和复杂任务混在一个数据集里评测，最后只得到一个平均分，无法判断它能处理什么级别的工作。
Computer Anthology 的定位就是针对这些问题设计的。从项目命名来看，“Anthology” 本身是“选集、文集”的意思，暗示这是一个持续收录任务、持续更新版本的评测集合，而不是一次性发布的静态题库。它更像一个评测体系：不断把新任务收录进来，按难度和类型归档，让 Agent 的评测随能力提升而更新。
这种设计的好处是：
- 任务集与 Agent 能力同步演进，减少“刷题过拟合”的问题；
- 每个任务有明确的目标和检查条件，比主观问答更容易量化；
- 按任务家族拆分，可以单独看 Agent 在文件操作、命令行、浏览器操作、信息检索等维度的能力。
如果你要给自己的 Agent 做持续回归测试，这个设计思路值得参考。
3. 适用场景与使用边界
3.1 适合谁使用
- 正在开发通用 Agent 或计算机操作 Agent 的团队，需要一套可扩展评测集；
- 做模型选型的技术同学，想对比不同模型在真实任务上的表现；
- 做 Agent 应用迭代的算法工程师，需要通过回归测试防止新版本能力退化；
- 研究 Agent 评测方法的学生或研究者，需要一个任务组织和难度分层参考。
3.2 能解决什么问题
核心是三个：量化 Agent 完成真实任务的能力、追踪版本迭代中的能力变化、区分不同 Agent 在不同任务类型上的强弱项。
3.3 不适合什么场景
- 纯对话质量评测，这不是 Computer Anthology 的侧重点；
- 大规模强化学习训练数据采集，benchmark 更偏向评估而不是训练数据生产；
- 需要人工主观评分的开放创作类任务，自动化评测难以覆盖。
3.4 使用边界与合规提醒
评测任务通常涉及让 Agent 操作文件系统、访问页面、执行命令等。使用时需要注意：
- 评测环境建议使用隔离的虚拟机或容器，避免 Agent 误操作影响宿主机；
- 评测任务中如果包含版权数据或私有数据，不要公开分发，按授权范围使用；
- 如果评测内容涉及个人信息、账号信息、人脸声音等敏感数据，必须脱敏处理并获得授权；
- 不要让 Agent 在未授权的真实系统中执行任务，建议只在受控评测环境中运行；
- 对 Agent 的操作进行完整日志记录，方便审计和问题回溯。
4. 环境准备与前置条件
虽然 Computer Anthology 的具体依赖以官方仓库为准，但从 benchmark 项目的通用技术栈来看，环境准备通常包含以下几块。
4.1 基础环境
| 项目 | 建议 |
|---|---|
| 操作系统 | Linux / macOS / Windows（Linux 最稳妥） |
| Python 版本 | 3.9 / 3.10 / 3.11，具体看项目要求 |
| 包管理工具 | pip、conda 任选 |
| 磁盘空间 | 依赖和评测数据通常需要数 GB 到数十 GB，按实际任务规模而定 |
| 端口 | 默认不依赖特定端口，但跑 WebUI 或 Agent API 服务时需要确认端口空闲 |
4.2 环境检查命令
无论项目依赖是什么，先检查系统环境总没错：
# 检查系统版本 uname -a # 检查 Python 版本 python3 --version # 检查 pip 版本 pip3 --version # 检查 GPU 是否可用（如果本地跑被测 Agent 模型） nvidia-smi如果被测 Agent 使用本地模型推理，还需要确认 CUDA、PyTorch 等依赖是否安装。这里不需要一开始就配最高版本，按项目文档的 requirements 安装即可。
4.3 被测 Agent 的准备
评测框架本身不产生模型能力，它只负责下发任务并判断结果。因此需要提前准备：
- 被测 Agent 的调用方式：是本地模型服务还是远端 API；
- Agent 是否具备文件读写、命令执行等工具能力；
- Agent 的输入输出格式，评测脚本需要适配。
如果 Agent 是本地服务，评测时建议同机或同局域网部署，降低网络延迟干扰。
5. 获取与部署启动方式
5.1 获取项目
通用方式是从仓库拉取代码：
git clone https://github.com/example/computer-anthology.git cd computer-anthology安装依赖：
# 建议使用虚拟环境，避免污染系统 Python python3 -m venv .venv source .venv/bin/activate # 安装项目依赖，实际以官方 requirements 为准 pip install -r requirements.txt5.2 配置评测环境
benchmark 项目通常需要配置数据路径、任务列表和输出目录。下面是一个通用配置模板，实际字段以项目文档为准：
# config.yaml task_dir: "./tasks" output_dir: "./results" agent_endpoint: "http://127.0.0.1:8000/execute" task_tags: ["file_ops", "shell", "browser"] max_concurrency: 4 timeout_per_task: 1205.3 启动评测
从项目设计来看，推荐的方式是命令行 + 配置文件：
python run_evaluation.py --config config.yaml启动后观察输出日志，确认任务加载成功、Agent 服务连接正常。如果是第一次运行，建议先用单条任务做连通性测试。
6. 评测任务设计与功能测试
6.1 任务的基本结构
Computer Anthology 这类 benchmark family 的核心单元是“任务”。一个任务通常包含：
- 任务 ID；
- 任务描述（给 Agent 的目标指令）；
- 任务类型（文件操作、命令行、浏览器操作等）；
- 初始条件（评测环境的初始状态）；
- 成功条件（可自动检查的判定逻辑）；
- 难度等级；
- 相关标签。
任务设计得越清晰，评测结果越可信。
6.2 单条任务连通性测试
先跑一条简单任务验证链路：
# example_single_task.py # 通用示例，实际 API 需按项目接口调整 task = { "id": "local-test-001", "instruction": "在当前目录下创建一个名为 hello.txt 的文件，文件内容为 hello", "type": "file_ops", "success_condition": { "check_file": "hello.txt", "check_content": "hello" } } # 调用 Agent 执行 response = agent_client.execute(task["instruction"]) print(response)判断成功的标准：
- Agent 返回执行成功；
- 评测环境中确实生成了 hello.txt；
- 文件内容与成功条件匹配。
6.3 不同任务类型的测试维度
| 任务类型 | 测试目的 | 典型检查点 |
|---|---|---|
| 文件操作 | Agent 能否读写、重命名、删除文件 | 文件是否存在、内容是否正确 |
| 命令行任务 | Agent 能否执行命令并修正错误 | 命令执行结果、退出码、输出内容 |
| 代码修改 | Agent 能否定位并修改代码问题 | 测试用例执行是否通过 |
| 信息检索 | Agent 能否从给定资料中提取准确信息 | 答案与 ground truth 是否一致 |
| 浏览器操作 | Agent 能否完成页面点击、表单填写、结果验证 | 页面最终状态是否满足目标 |
6.4 评测稳定性验证
单条任务通过后，建议对同一任务重复运行 3 次：
- 如果结果波动大，说明任务描述存在歧义，或 Agent 推理不稳定；
- 如果多次运行结果一致，任务可以被纳入批量评测集。
任务描述必须明确、无歧义。比如“安装依赖”就不是一个合格的任务描述，应该写成“安装 requirements.txt 中的所有依赖，并验证 import 成功”。
7. 批量评测与自动化流程
7.1 批量评测的价值
单条任务只能验证连通性。真正的评测必须覆盖多个任务、多个维度，才能形成可比较的分数。批量评测要解决的问题是：不同任务、不同 Agent、不同模型版本之间如何公平对比。
7.2 批量评测任务配置
以下是一个批量评测的 JSON 配置示例：
{ "task_group": "anthology-v1-file-ops", "task_dir": "./tasks/file_ops", "agent": { "type": "local", "endpoint": "http://127.0.0.1:8000/execute" }, "runner": { "max_workers": 4, "timeout_seconds": 180, "retry_times": 2 }, "output": { "result_file": "./results/v1-file-ops.jsonl", "log_level": "INFO" } }7.3 批量评测脚本示例
# run_batch.py # 通用批量评测模板，实际实现需按项目接口调整 import json import logging from pathlib import Path from concurrent.futures import ThreadPoolExecutor logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s") def evaluate_task(task, agent_client): """执行单条任务并返回结果。""" try: response = agent_client.execute(task["instruction"]) success = check_success_condition(task, response) return {"task_id": task["id"], "success": success, "response": response} except Exception as exc: logging.error("task %s failed: %s", task["id"], exc) return {"task_id": task["id"], "success": False, "error": str(exc)} def check_success_condition(task, response): # 实际判断逻辑需要根据任务类型实现 return response.get("status") == "success" def main(): config = json.loads(Path("batch_config.json").read_text(encoding="utf-8")) task_dir = Path(config["task_dir"]) tasks = [json.loads(f.read_text(encoding="utf-8")) for f in task_dir.glob("*.json")] results = [] with ThreadPoolExecutor(max_workers=config["runner"]["max_workers"]) as executor: for result in executor.map(lambda t: evaluate_task(t, agent_client), tasks): results.append(result) result_path = Path(config["output"]["result_file"]) with result_path.open("w", encoding="utf-8") as fp: for item in results: fp.write(json.dumps(item, ensure_ascii=False) + "\n") success_count = sum(1 for r in results if r["success"]) logging.info("total: %d, success: %d", len(results), success_count) if __name__ == "__main__": main()批量评测建议遵循以下原则：
- 任务逐个写入结果文件，避免中途崩溃丢数据；
- 每个任务设置超时时间，防止个别任务卡住整个队列；
- 失败任务自动重试，并记录重试次数；
- 日志要包含任务 ID、开始时间、结束时间、执行结果。
7.4 批量任务中断恢复
批量评测任务量大了之后，中断是常见问题。建议结果文件采用 JSONL 格式逐行追加，恢复运行时通过跳过已有 task_id 来断点续跑。
8. 结果解读与性能观察
8.1 评测指标
benchmark family 的常见指标包括：
| 指标 | 含义 |
|---|---|
| Task Success Rate | 任务级成功率 |
| Dimension Score | 按任务类型分组后的子项得分 |
| Difficulty Curve | 不同难度等级下的成功率曲线 |
| Token / 步骤开销 | Agent 完成任务消耗的 token 数或操作步数 |
| 稳定率 | 同一任务重复运行结果一致的比例 |
只报告平均成功率是不够的。建议至少按任务类型和难度分组输出，这样能看出 Agent 具体在哪些环节弱。
8.2 资源与成本观察
如果被测 Agent 是本地模型推理，重点关注：
- 单任务平均延迟；
- 并发评测时的显存占用；
- 长时间评测是否出现显存泄漏或 OOM。
如果被测 Agent 是 API 服务，重点关注：
- 单任务平均 token 消耗；
- 并发请求是否触发限流；
- API 成本估算。
观察方式：
# 本地推理时，实时查看 GPU 占用 watch -n 1 nvidia-smi这里要强调：评测环境应尽量隔离，不要让评测任务与生产服务共用同一 GPU，否则显存占用和推理延迟都会互相干扰。
8.3 如何降低评测成本
- 先用小规模任务集调通流程，再跑全量评测；
- 对同一模型版本，先跑固定种子集，确认无异常后扩展；
- 合理设置并发数，过高会导致限流或 OOM，过低会浪费时间；
- 记录每次评测的配置和结果，方便回溯对比。
9. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 评测脚本启动失败 | 依赖未安装或版本冲突 | 检查报错栈和 pip 依赖树 | 按项目 requirements 重建干净虚拟环境安装 |
| 任务加载为 0 | task_dir 路径错误或任务文件格式不对 | 检查目录结构和 JSON 是否合法 | 确认任务文件路径与配置一致 |
| Agent 服务连接失败 | 服务未启动、端口错误或地址不通 | curl 检查 Agent 接口是否可以访问 | 先启动 Agent 服务，再启动评测脚本 |
| 单条任务超时 | 任务指令有歧义或 Agent 推理过慢 | 查看 Agent 日志单步执行时间 | 优化任务描述，或调大 timeout 参数 |
| 批量任务中途中断 | 内存不足、API 限流或进程被杀 | 查看日志最后一条记录和系统资源 | 结果文件做幂等记录，恢复时跳过已完成任务 |
| 评测结果波动大 | 任务描述不明确或 Agent 不稳定 | 同一任务重复运行 3 次对比 | 细化成功条件，增加判定约束 |
| 显存不够（本地推理） | 并发数过高或模型过大 | 观察 nvidia-smi 显存占用 | 降低并发数或换小模型 |
| API 评测报限流 | 并发请求超过服务限制 | 查看 API 返回的状态码和 headers | 降低 max_workers，增加重试和退避 |
10. 最佳实践与使用建议
10.1 从最小配置开始
第一次使用 Computer Anthology 或任何 benchmark family，不要直接跑全量任务。先选 5 到 10 条覆盖不同任务类型的任务跑通链路，确认评测环境、Agent 连接、成功条件判断都没有问题，再扩展任务规模。
10.2 维护一套稳定的评测基线
评测的目的是对比，不是拿绝对分数。建议固定一个评测环境快照，将以下内容纳入配置管理：
- 评测任务集的版本；
- 被测 Agent 的版本和参数；
- 评测脚本的版本；
- 随机种子（如果有）；
- 评测环境的系统状态。
只有保持这些变量可控，不同时间跑出来的结果才有可比性。
10.3 任务集要分层
把任务按难度分层是一个值得坚持的做法。简单任务用于快速回归，中等任务用于日常迭代，困难任务用于版本发布前的完整评估。分层的好处是：日常开发不需要每次跑全量评测，只有到达发布节点时才跑全套。
10.4 日志和结果可追溯
被测 Agent 的执行轨迹、评测脚本的判定依据、任务原始配置都应该完整记录。否则遇到“这周分数比上周高了 5 个点”的情况，根本说不清是模型变强了，还是任务判定条件悄悄变了。
10.5 合规使用
涉及真实系统操作、浏览器自动化、数据抓取的评测任务，一定要在隔离环境中运行。不要评测 Agent 对未授权系统的操作能力，也不要将包含敏感数据的评测集公开传播。评测完成后的执行日志如果包含个人信息，需要脱敏再归档。
11. 总结与下一步
Computer Anthology 这类持续演进的 benchmark family，解决的是 AI Agent 评测中一个很实际的问题：怎么让评测体系和 Agent 能力同步更新，避免刷题过拟合，也能分层看清能力短板。
如果你想尝试这个方向，建议从三件事开始：
第一，先跑通一条最简单任务的评测链路，确认 Agent 服务和评测脚本可以正常协作； 第二，建立一套固定版本的最小任务集，用来做日常回归； 第三，设计结果记录格式，确保每次评测的输出都可以横向对比。
最容易踩的坑是任务描述不清晰，导致评测结果随机波动；其次是批量评测没有日志和断点恢复机制，中断一次就前功尽弃。这两点提前做好，后面会省很多事。
后续可以考虑的方向包括：把 Computer Anthology 的任务按自己的业务场景做裁剪扩展、接入 CI 流程做模型版本回归、把评测结果可视化到看板，持续跟踪 Agent 能力变化。
这套思路本身值得收藏备用。无论最后选不选 Computer Anthology，把“持续演进、分层任务集、可追溯评测结果”这套方法论落到自己的 Agent 迭代流程里，都会有实际价值。
