英文原文: https://argusic.com/methodology

英文版本具有约束力；如本中文版本与英文版本不一致，以英文版本为准。

最后更新 2026年10月8日.

Argusic 方法论

本文说明 Argusic 如何测试真实软件能否运行，以及如何为 AI coding agent 评分。这里的每条规则都是有意公开的：关键就在于任何人都能核查我们的工作。对这些规则的任何修改都会写入页面底部的变更日志，从下一个测试周期起生效，并且从不追溯适用。

1. 简而言之

2. 本方法回答的问题

给定一个真实的开源项目，AI coding agent 能否完全独立地安装它、启动它、逐一解决错误，并验证软件确实在运行，就像一名入职第一天、没有任何人帮助的工程师那样？

3. 为什么选用新项目

静态 benchmark 会随着答案泄露进训练数据而失效。SWE-rebench (Badertdinov et al., 2025) 让同样的 agent 分别处理 SWE-bench Verified 和该 benchmark 公开之后收集的任务，分数差距很大：其 Table 2 报告 DeepSeek-V3-0324 在 SWE-bench Verified 上解决了 39.7%，在按时间筛选的任务集上只解决了 21.3%，仅一个模型就相差 18 个百分点。Argusic 测试的是最近几周内的热门项目，并配有每月轮换的保密池，因此没有任何可供记忆的答案。

4. 测量什么

我们只测量一件事：自主让真实软件运行起来的能力。每个受测 agent 都是一个固定组合：固定版本的模型、固定版本的 harness、Argusic 公开的标准指令，以及完全相同的时间和资源限制。每个 agent 获得的条件完全一致。

5. 受测 agent

第一个周期正在进行中。agent 名单将随第一份排行榜一同公布。每个 agent 都是一套固定版本的配置，以中立的 Argusic 身份呈现；其确切版本会被记录和保存，因此榜单上的每个数字都能追溯到产生它的精确配置，并且可以应要求通过 Argusic 复现结果（见“如何复现结果”）。

6. 项目池

6a. 什么可以成为测试项目

测试项目是可以要求 agent 搭建并运行的东西。Argusic 目前测试一种类型，其设计允许在不改变结果获得方式的前提下增加其他类型：评分细则、证据规则和结论用语在所有来源之间完全相同，因此一个来源的数字与另一个来源的数字含义相同。

来源此处“可运行”的含义状态
开源仓库克隆固定的 commit，安装、启动，并验证它完成了其自身 README 所描述的工作使用中。 已测试 3669 个项目
Hugging Face 模型在固定的 revision 下载模型，并完全按照其模型卡片的说明在 GPU worker 上运行推理。当文档中的代码片段在干净的机器上产生输出、且测试者无需改写它时，即视为可运行使用中。 已测试 1 个项目
Hugging Face Space根据 Space 自身的定义构建并启动它，然后打开其界面，完成它所宣称的交互已声明，尚未开始
已发布的软件包 (npm, PyPI)将固定版本安装到一个空项目中，并运行其自身 README 中的快速入门已声明，尚未开始
厂商工具安装并启动厂商自己发布的构建版本，只遵循厂商自己的说明已声明，尚未开始
预构建的云模板按照模板自身列表页面的说明部署它，并检查它能否启动并提供其宣称的服务，测试者事先不做任何修补已声明，尚未开始
容器镜像按固定的 digest 拉取镜像，运行其自身描述中给出的命令，然后检查它是否做到了该描述所声称的内容已声明，尚未开始
MCP server按照文档安装并启动 server，连接一个客户端，并确认它列出并响应其宣称的工具已声明，尚未开始

上表的“状态”列不是手写的。每次提供本页时都会从数据库读取：当某类已发布的测试项目有了一次已记录的运行时，该来源就显示为使用中，并显示数量。这与本站其他所有数字遵循的规则相同，也意味着当一个新来源产生第一个结果时，没有人需要记得去更新本页。

Hugging Face 测试项目与仓库有两点不同，两者都随运行一并记录，而不是被淡化处理。它需要 GPU worker，所以每次尝试的成本更高，其预算也单独决定。另外，模型卡片通常记录的是一段代码片段而不是一个应用，因此经过验证的行为是“文档中的代码片段产生了输出”，而不是“产品可以工作”：运行页面会用这些原话说明属于哪种情况，评分方式不变。

表中有意写“尚未开始”而不是“即将推出”。某类来源只有在一次该类真实运行连同其证据被记录的那一天才算投入使用，早一天都不算。 在此之前，该行只是对范围的说明，绝不代表结果：对于尚未运行的来源，任何页面都不会显示结论、数量、排名或分享卡片，而本表是唯一会提到计划中来源的地方。

7. 一次测量

  1. 一台干净的一次性机器（其确切环境已公开）。它不接受任何入站连接，运行结束后即被销毁。本版本中出站网络访问不受过滤；限制一次运行的是一次性机器以及列表下方的模型密钥规则。机器只获取固定的 commit，不获取项目历史，历史不属于测试内容。
  2. agent 接到一项任务：按照公开的标准指令，让这个项目运行起来。
  3. 一个时间限制。每次运行获得恰好三种预算之一（见列表下方的表格），该次运行获得的预算显示在其运行页面上。
  4. 三次独立运行；取中间结果。如果三个结果相差超过 30%，这组结果会被标记为不稳定，并在该周期的榜单中搁置。
  5. 每次运行都保存完整的 log 和完整的终端录屏，与结果一同公布。
  6. 桌面应用在机器内部的虚拟显示器上启动（自 v1.1 起）。“启动”指应用的主进程在该显示器上启动并保持运行，或者响应了版本命令或帮助命令。不进行任何点击；测量的是软件能否在全新机器上运行起来，与对其他所有项目提出的问题相同。agent 被告知不要向其模型发送图像（自 v1.3 起）：标准模型只接受文本，而附在消息中的截图曾导致会话在提交报告之前就结束。

第 3 项的时间预算：

档位预算
standard90 分钟
heavy120 分钟
gpu120 分钟

在 v1.3 之前，standard 预算为 45 分钟：第一周中，某一天 38 次超时里有 36 次是用完全部预算时构建仍在进行，因此预算翻了一倍。heavy 档位自 v1.2 起设立，适用于被 Owner 标记为 heavy 的项目，或 GitHub 报告的仓库大小超过 500 MB 的项目，因为大型游戏或桌面应用需要这么长时间才能构建完成。需要 GPU 的项目获得同样的 120 分钟。

上面三个数字并非装饰。scripts/check-ttl-methodology.sh 会读取这张表，并与 orchestrator 实际配置的预算进行比较，若两者不一致，make test 就会失败。之所以有这项检查，是因为在 2026-09-06 到 2026-09-11 期间，运行中系统的 GPU 预算是 240 分钟，而本页写的是 120，且没有任何机制比较这两者 (ISSUE-072)。

模型密钥。agent 需要密钥来调用其模型，而一次运行会执行来自不受信任项目的代码，因此这把密钥是最值得加以限制的凭据。对于通过 Argusic 路由层访问模型的 agent，每次运行都会获得一把专为该次运行创建的密钥。 每次运行的模型密钥支出上限：3 USD。 运行结束、被取消或超时时，密钥即被删除；定时清理任务还会删除任何不再属于正在运行任务的密钥。如果无法为某次运行创建密钥，该运行不会启动并会重试；绝不会用共享密钥代替。使用模型厂商自有服务的 agent 通过 Argusic 持有的共享密钥调用该服务，而不是每次运行一把密钥；将它们迁移到每次运行一把密钥已列入我们的 backlog。上面的上限一行由 scripts/check-cost-methodology.sh 读取，若与配置值不一致，它会让 make test 失败，理由与时间预算相同。

8. 评分，满分 100

一次运行的结果为以下之一：

结果含义
pass_full已运行，并经过真实验证
pass_mock已运行，对照 mock 服务验证
fail未能安装或未能启动
timeout超时

这四条评分规则留下了一些隐含情况。它们在此处明确规定，而不只写在代码里，因为没人能读懂的规则就是没人能核查的规则。评分由一个确定性程序完成，下面每条规则都有测试覆盖；评分的任何环节都不涉及 AI 模型。

9. 从多次运行到一个榜单分数

评分针对的是一个“项目与 agent”的组合。排行榜需要每个 agent 一个数字，而如何合并属于方法论上的选择，因此在此说明。

agent 的榜单分数是其各项目中位分数的中位数。我们再次使用中位数而不是平均值，理由相同：一个灾难性的项目不应拖累一个有能力的 agent，一个侥幸的项目也不应抬高一个较弱的 agent。

有两类结果不计入该数字，但两者仍显示在榜单上，使排除是可见的而非悄无声息：被标记为不稳定的结果（见下一节），以及被标记为审查中的项目上的所有结果（见环境质量控制）。

所有结果都被排除的 agent 没有榜单分数。它会显示在底部且不带分数，而不是被移除，因为一个经过测试却没有产生任何可用结果的 agent 本身就是一个结果，把它隐藏起来会悄悄美化整个榜单。

通过率计入 agent 在该周期内的每一次尝试，包括失败和超时。见下文的独立性与不挑选结果。

10. 波动幅度与不稳定

波动幅度是三次运行的极差占其中间值的百分比：

spread = (highest - lowest) / middle * 100

当波动幅度严格大于 30% 时，这组结果被标记为不稳定。恰好 30% 不算超过 30%，仍保留在榜单上。由该公式可得两种边界情况：

11. 项目结论

榜单为 agent 排名。结论回答的是关于项目本身的另一个问题：一个新手，以 AI agent 的形式，今天能否让这个软件运行起来？

测试是自适应的，因为证据是单向的。一次通过就能证明项目可以运行；单次失败本身什么也证明不了，因为问题可能出在 agent 而不是项目。

  1. 首先，标准 agent 运行一次。任何一次通过即结束测试：完全通过得出“可运行”，对照 mock 服务通过得出“借助 mock 可运行”。已经证明能运行的东西，没有理由继续测试。
  2. 如果失败，在同一个 agent 上重试一次，以排除偶然的意外。
  3. 如果仍然失败，结论是“无法验证”，而绝不是“已损坏”：Argusic 报告的是 agent 能做到什么，并且如实说明这一点（自 v1.3 起：标准 agent 的两次完整尝试即可确定结论）。可以应要求运行更强的 agent；运行时，它的通过会使项目成为“可运行”（记录中会显示是哪个 agent 验证的），它的失败同样确定为“无法验证”。

完整尝试是指录屏显示 agent 一直工作到它自己结束或到达时间限制的尝试。被 Argusic 自身工具中途截断的尝试（harness 无法读取 agent 的报告、与项目无关的仪器错误）会被标记为无效，原因记录在该运行上，它连同证据继续公开，但不计入。

结论取任何一次尝试达到的最佳结果：

无论结论如何，每次尝试都会连同完整证据公开，只有一个例外：无法证明不含有效凭据的录屏会被扣留，其运行会重新进行（第 17 节，“安全脱敏”）。

12. Argusic 不测量什么

为防止误读，我们在此明确说明。Argusic 不测量 agent 所写代码的长期质量、其修复的安全性，也不测量深入到功能层面的产品体验。它只测量一件事：自主让真实软件运行起来的能力。

13. 独立性与不挑选结果

14. Harness 公开

harness（模型周围的脚手架、工具、指令和限制）是公开的，并且在一个周期内对每个 agent 完全相同。分数上的任何差异都必须归因于 agent，而不是底层管道。harness 的修改只在周期之间发布，并记录在变更日志中。

15. 环境质量控制

当一个项目在所有 agent 上都失败时，它会被自动标记为审查中，并在人工检查之前不计入评分：失败可能出在环境或项目，而不是 agent。共同的搭建问题绝不应被算作某个 agent 的失败。

16. 验证意味着解码，而不是探测

文件存在不是结果，读取文件头也不是检查。ffprobe -show_streams、file 和字节数统计报告的都只是容器，什么都没有解码：一个每一帧都是绿色的视频，会像正常视频一样通过这三项检查。自 v1.4 起生效的规则是：agent 报告它解码出的内容，绝不报告它预期的内容。

17. 证据完整性

两个层次，绝不混淆。

证据层是原始且永久的：每次运行都会生成真实会话的完整终端录屏，图形应用还会生成原始会话视频，外加完整的 log。每个文件在到达时都会生成指纹并永久保存。任何人都可以回放未经剪辑的完整会话。

展示层是派生的：任何社交媒体视频或图片都是证据的渲染结果。允许的编辑包括加速、为控制时长而裁剪、根据记录的“错误与修复”时间线生成字幕，以及配音。禁止的编辑包括调整事件顺序、将不同会话拼接在一起、隐藏失败，或改变 agent 所做工作的实质内容。每个公开的视频都链接回其证据。

录屏在提供之前会经过三种派生转换，它们都不会改变 agent 工作的实质内容：

对引用文本适用一种显示转换（Owner 决定，2026-09-04）：当页面显示 agent 自己的最终状态句（“测试发现了什么”）或仓库的 GitHub 描述时，作者输入的破折号会显示为逗号或句号，使页面遵循本站的标点规范。保存的报告、仓库记录、log、录屏以及从录屏渲染的图像都保持不变；文字及其顺序从不改变。

长期规则：每个数字都可追溯到一份 log，每一帧都可追溯到一段真实会话的录屏。

18. 如何复现结果

每个结果的项目一侧完全公开：测试的确切 commit、公开的环境、标准指令，以及完整的 log 和录屏。每次运行的页面都载有这些内容。agent 是一套以中立身份呈现、版本固定的 Argusic 配置；Argusic 保存其确切版本，并可以重新运行以复现结果。公开项目名单和保密池的披露将随第一份排行榜一同发布。

19. 对结果提出异议

如果维护者或实验室认为某个结果有误，可以提出异议。请将运行链接发送至 [email protected]。我们会对照其主张审查完整的 log 和录屏并回复。如果结果受到我们这边环境或搭建问题的影响，我们会重新运行，并在记录中附注更正；如果证据支持原结果，我们会解释录屏显示了什么。原始证据永远不会被编辑或删除。

20. 变更日志

每个版本上会出现两个日期，它们回答不同的问题。撰写于是该规则被写入本文档的日期。生效于是第一次实际按该规则测量运行的日期，读取自运行记录，而不是本文件。两者通常一致。不一致时，以运行记录为准并在此列出，因为一个版本先到达机器、后到达本页，正是变更日志需要披露的事情。任何版本都不会追溯适用：一次运行保留其运行当天生效的规则。

v0.2 至 v1.0 的各个版本都是在 2026-08-31 记录的，即创建第一个公开版本的那次 commit；下面它们的日期是规则本身被决定的日期，早于第一次测量。

附录：硬件估算，哪些模型放得下、速度有多快

下面的估算值显示在 Argusic 列出的适合编程、AI 和数据科学的笔记本电脑和台式机旁边。

本附录不属于上述 benchmark 规则，也不改变任何版本：它解释 Argusic 在其列出出售的笔记本电脑和台式机旁所显示的估算值，这些估算是基于厂商公布数据的算术计算，绝不是测量结果。这里的数字由一个共享文件 (lib/hardware-estimates.ts) 计算，任何数字的修改都必须在同一次 commit 中同时修改该文件及其测试。

Argusic 的硬件列表为每台笔记本电脑和台式机显示它能容纳的最大模型规模，以及其文本生成速度的上限。两者都是估算值：根据厂商公布的规格，用下面的公式计算得出。Argusic 没有在这些机器上运行过模型。当 Argusic 确实测量了某台机器时，该数字会带有实测标签，链接到其运行 log，并且绝不与估算值混在一起。

只有在每项输入都已知时才会显示估算值。如果缺少内存大小、内存类型或芯片带宽，页面会显示“未知”，而不是猜测。

输入及其来源

内存：放得下哪种规模的模型

一个模型需要为三样东西留出空间。

  1. 权重。 Argusic 假定使用 llama.cpp 的 Q4_K_M 量化，每个权重 4.8944 位 (llama.cpp quantize README)：

    2. 权重字节数 = 参数数量 x 4.8944 / 8。 示例，为计算值而非测量值：一个 70B 模型需要 42.8 GB 的权重。

  2. 上下文 (KV cache)。 依据 NVIDIA 的公式 (Mastering LLM Techniques: Inference Optimization，NVIDIA Technical Blog，2023-11-17)：

    3. 每个 token 的 KV cache 字节数 = 2 x 层数 x (头数 x 头维度) x 每个值的字节数。 现代模型在多个注意力头之间共享键/值头（分组查询注意力），因此这里的“头数”是模型实际缓存的键/值头数量。Argusic 允许 8,192 个 token 的上下文，精度为 16 位（2 字节，llama.cpp 的默认缓存类型），每个档位使用一个开放 dense 模型公布的配置：Qwen3-8B、Qwen3-14B、Qwen3-32B、Qwen2.5-72B-Instruct 和 Mistral-Large-Instruct-2411。

  3. 运行时开销。 Argusic 为推理运行时自身的缓冲区预留 1 GB。

8,192 个 token 的上下文和 1 GB 的开销是 Argusic 设定的预留量，属于策略选择而非测量结果。更长的上下文需要更多内存；在这里放得下的模型，在长得多的对话中未必放得下。

机器内存中计入多少。 独立 GPU 的显存全部计入。统一内存或系统内存中，Argusic 计入 75%，并为操作系统和其他程序留出 25%。这与 AMD 对其统一内存芯片的说法一致：128GB 中最多 96GB 可转换为显存 (AMD)，64GB 最多可分配 48GB (AMD)。

内存大小按每 GB 10^9 字节读取，与厂商标注带宽所用的单位相同。内存实际上按二进制单位计量，因此这种读法会把容量低估约 7%，使每次判定都略微保守。

根据上述规则计算得出的各档位需求：

档位权重 (Q4_K_M)上下文预留开销需要显存起步统一内存起步
7-8B4.89 GB1.21 GB1 GB7.10 GB7.10 GB9.47 GB
14B8.57 GB1.34 GB1 GB10.91 GB10.91 GB14.54 GB
27-32B19.58 GB2.15 GB1 GB22.73 GB22.73 GB30.30 GB
70B42.83 GB2.68 GB1 GB46.51 GB46.51 GB62.01 GB
120B 及以上73.42 GB2.95 GB1 GB77.37 GB77.37 GB103.16 GB

例如，8GB 的 GPU 可容纳 7-8B 档，24GB 的 GPU 可容纳 27-32B 档，64GB 的统一内存可容纳 70B 档。低于第一行的机器显示为任何档位都放不下。

速度：一个上限，而不是预测

生成每个 token 都需要从内存中把模型的每个权重读取一次，因此文本生成受限于内存带宽 (NVIDIA："Model execution is frequently memory-bandwidth bound")。由此得到一个上限：

每秒 token 数，最多 = 内存带宽 / 权重字节数。

示例，为计算值而非测量值：一款 546 GB/s 的芯片运行 Q4_K_M 的 8B 模型（4.89 GB 权重），速度不会超过约每秒 111 个 token。

实际速度总是更低。 这个上限忽略了读取上下文、计算以及软件开销所花的时间。llama.cpp discussion #4167 中收集的测量数据显示，速度随带宽上升，但低于线性增长。以 Apple silicon 上 Q4_0 的 Llama 2 7B 为例：M3 Max (400 GB/s) 每秒 66.31 个 token，M4 Max (546 GB/s) 83.06，M2 Ultra (800 GB/s) 94.27。从 400 到 546 GB/s（带宽为 1.37 倍）带来 1.25 倍的速度；翻倍到 800 GB/s 带来 1.42 倍。请把这个上限理解为“这台机器不可能比这更快”，而绝不是“这台机器以这个速度运行”。

这个上限假定为 dense 模型，即每个 token 都要读取每个权重。混合专家 (Mixture-of-experts) 模型每个 token 只读取被激活的专家，因此其运行速度可能高于按总规模推算的上限。

每美元模型内存

该列表的一种排序方式是每美元模型内存：模型内存（显存或统一内存）的 GB 数除以当前 Amazon 价格，并显示价格的日期。它回答的是“这笔钱能买到容纳最大模型的机器是哪台”。它不是质量或速度排名，佣金也从不改变它。

这些估算不是什么