九大AI Agent代码库扫描：证据驱动注册表发现了什么

大多数 AI Agent 目录只回答一个问题：谁的 pitch 做得好？但如果一个 Agent 要替你行事（订票、读文件、调用工具），这个问题就问错了。真正该问的是：代码实际在做什么，以及我们不知道什么？

这就是我构建 Metal Mantra 的原因——一个关于 AI Agent 的公开报告库。

你粘贴一个公开的 GitHub 仓库和一个官方域名。确定性规则读取源代码，并围绕五个加权维度生成公开报告：

每条推断都指向一条规则和一个文件。扫描器中不含 AI，所以同一个仓库会得到相同的结果。（AI 只出现在一个地方：一个可选的框，根据买家描述对 Agent 排名。它从不参与评分。）

我不会打破的规则

等级是对公开源代码的自动化信号，而不是安全认证。每份报告都包含一个明确的"本报告未建立"部分：运行时安全性、现实世界能力、是否适合你的用例。

这听起来像是免责声明，但它就是产品本身。一个悄悄把启发式规则变成印章的注册表比没有注册表更糟糕，因为人们会停止阅读。

九份真实报告的样子

发布时，注册表中包含九份知名开源 Agent 的报告。分数从 69 到 84 不等（满分 100）。没有人接近满分，也没有人接近零分，这正是对严肃项目进行静态分析所期望的结果：它发现的是缺失的护栏、松散的 schema 和无界循环，而非灾难性漏洞。

比分数更有用的是扫描器承认它不知道的东西。每份报告都显示有多少文件符合条件、实际读取了多少文件。"部分选择"会被明确标记。

教给我们最多的 bug

在我们最初的扫描中，我们按归档顺序读取前 80 个符合条件的文件。对于像 agents SDK 这样的 monorepo，那 80 个文件都是示例和文档。扫描器实际上是在根据演示代码对框架进行评分，结果在一个最知名的 Agent SDK 上未能通过"这是 Agent 吗？"的检查。

修复方案很无聊但很重要：在限制文件数量之前先对文件进行排序（产品源代码优先，然后是未分类文件，接着是示例、文档和工具），并扩大 Agent 检测规则以识别常见的 SDK 导入。这个教训可以推广：在证据驱动的系统中，采样策略是声明的一部分。如果你不能说清楚你读了什么，你就不能说清楚你发现了什么。

商业 Agent 很少发布源代码。对于这些，owner 在他们自己的 GitHub Actions job 中运行我们的扫描器。它只发送规则 ID 和计数，通过 GitHub 的 OIDC token 进行身份验证。服务器从自己的规则目录重建每个发现，因此调用者可以省略发现，但不能美化它们。报告被标记为"CI-attested"，明显弱于我们自己运行的扫描。

任何公开仓库的第一次扫描都是免费的：metal mantra.io/scan。如果你维护一个 Agent，告诉我哪些规则感觉不对。方法是公开的，到目前为止最好的 bug 报告来自那些不同意某条推断的人。