提前 5 天，它敢说是 5 级

三段代码一字不差，连彩蛋名都搬了过来

9 月 11 日，Minitap 核查 Google 的 Artemis 仓库，锁定三处与自家 mobile-use 重合的代码段——从 Android 设备连接实现到 WhatsApp 场景，连让 agent 给 Alice、Bob、Charlie 发新年祝福的清理步骤和注释都对得上。版本号停在 3.6.3，作者栏却从三个 Minitap 工程师的名字，换成了 "somew1nd" 和一个 Outlook 邮箱地址。

Hopper 这个名字本身就是 Minitap 团队埋的私人彩蛋——有人爱玩 Minecraft，顺手拿来用了。Google 仓库沿用同一个名字、同一段指令，作者看到后说得很直白："very familiar"。

旧版本里还有一段 bug：helper 先写结果文件，下一轮再读自己刚写的输出时直接报错。Minitap 在两份代码里复现了同一次失败，后来 Artemis 把它修了。

一次 force push，三行名字凭空消失

2026 年 8 月，Artemis 仓库做了一次 force push，把 package 文件里 Pierre-Louis Favreau、Jean-Pierre Lo、Nicolas Dehandschoewercker 三个名字换成另一作者。GitHub 活动记录还留着这次推送的痕迹，main 分支上已经看不到旧版本——普通访问者打开仓库，看到的是替换后的样子。

Minitap 拿到 GitHub 活动记录后发现，commit 里唯一变化就是那三行署名，其他 228 个文件原样未动。Git 把这版旧 commit 标成 detached（脱离任何分支）——意思是它曾经存在，但不再指向任何活跃分支，没有引用就会被回收。

package 文件里的 author 字段是 npm 读取的元数据，下游只要 npm install，署名就跟着包走。新加一个 author 字段，两个名字并存的概率会变大，所以一次完整覆盖更彻底。

Apache 2.0 许可证第 4 条要求：再分发时必须保留原有的版权声明、署名声明，并在修改文件上做出标注。这三行名字既是被覆盖掉的归属证明，也是许可证要求保留的内容。

许可证写得很清楚，可这条规矩常被当空气

Apache 2.0 允许你拿走代码、拿去赚钱、改成另一个名字——但不允许你抹掉来源。第 4 条写明：再分发时保留版权与归属声明，标明修改；如果上游有 NOTICE（许可证附带的归属声明文件），里面的人名也要一起带过去。

Minitap 在文章里把这件事拆成两半：fork（把别人的代码仓库拷一份到自己名下继续改）在 GitHub 上天然留一条回链，导入的副本可以在注释里写明出处，README（项目自述文件）可以列出哪些部分来自哪里——这些是工程惯例；而上面这些保留动作里，有一部分是 Apache 2.0 第 4 条强制规定的，不是礼貌问题。Minitap 说得直白：有些是工程惯例，有些是协议要求。守规矩不是大公司的恩赐，条款里本来就有。

归属信息不只是法律义务。它帮新人找到原作者、弄懂某个设计决策、回报一个 bug、提交一个修复；给贡献者留下一份"我造过这个"的记录，也给新项目一个交代自己贡献的机会。

而维护者本来就在花时间回 issue、审 PR、维持项目运行，在大公司重新发表他们的代码之后，还得再去追讨"请把名字加回来"——这笔成本，是开源生态给贡献者额外加上去的。

四封邮件之后，榜首还是 Minitap 之外的名字

91.4% 停在榜上，94.8% 和 100% 没被收，四封邮件没有一封收到回复。

AndroidWorld 排行榜上一次收录 mobile-use 的成绩是 91.4%，最后一次确认时间 2025 年 12 月。之后 Minitap 提交了 94.8%，再之后是其自测的 100%——这两次跟进邮件加上前两次提交，合计四封邮件，没有一封收到回复。截至 9 月 11 日，榜单上 mobile-use 一栏仍停在 91.4%，Artemis 显示 99.1%。同一张榜上，两个数字隔着 7.7 个百分点，前者是原项目最后一次被收录的成绩，后者是把它并进自家产品的那一方的成绩。Minitap 同时指出，AndroidWorld 排行榜本身写明"结果为自报、未经独立核验"，这一限定同样适用于他们自报的 100%——这是一份自报成绩，不是已经过第三方复测的厂商跑分（模型方自行测试并公布的成绩）。

Artemis 自家那张对比图里也没有 mobile-use。图中只列了同分的 DroidRun，以及一个名称相近但和这件事无关的 MadeAgents 项目 MobileUse。一份本应说明"我们比谁做得更好"的图，把同样跑 AndroidWorld 的原项目整个跳过了。

可验证的观察点有三个：榜首是否补收 94.8% 和 100% 这两档成绩；Artemis 的 README 是否在 9 月 12 日之后加入对 mobile-use 的署名；AndroidWorld 维护方是否就"结果未经独立核验"这条限制给出过任何说明。

想自己看一眼？三组链接照着点

Minitap 把全部证据做成了公开材料，读者点开就能验。

先看 Minitap 在 minitap.ai/blog 发的原文，拉到底会看到两组并排链接：Artemis 设备连接代码 vs. mobile-use 设备连接代码，Artemis 的 Hopper prompt vs. mobile-use 的 prompt。把两个文件各自打开，对照 prompt 文本——Minitap 说的是"word for word"，逐字一致，眼睛扫一遍能验。WhatsApp 例子也有一组：Artemis messaging example 对比 mobile-use example，给 Alice、Bob、Charlie 发"Happy New Year"那条 demo，注释、清理步骤都摆在那里。然后看 author 列表的替换：打开 mobile-use 那一侧，Pierre-Louis Favreau、Jean-Pierre Lo、Nicolas Dehandschoewercker 三个名字齐全；再打开被替换后的 Artemis 版本，作者变成"somew1nd"配一个 Outlook 邮箱，整个 commit 只动了 author 列表这一个字段。

要走深一步，GitHub 的 activity record 显示这次替换发生在 2026 年 8 月的一次 force-push，发生在 Minitap 9 月调查之前。

force-push 在 Git 协作里会覆盖历史，所以"事后还能不能看到旧版"取决于仓库是否在 force-push 前被 fork 或被引用——Minitap 给出的 detached 版本号 3.6.3 正是这种残留痕迹。

旧 bug 也还能复现：把 mobile-use 的旧 commit checkout 出来跑一遍，照原 blog 的复现脚本做，能看到那个错误信息。这一步适合愿意装依赖、配 Android 调试环境的读者。

最后要承认一件事：上述观察全部基于 Minitap 自家整理的材料和 GitHub 上仍可访问的 commit 历史，没有第三方独立审计。代码匹配是否"实质相似"涉及法律判断，Apache 2.0 第 4 条的保留署名义务是否被满足也看法庭怎么认定。Google 截至目前没有公开回应。

如果你不是工程师，也可以做一件事：等 Google 的下一份 README 更新，或者等 Pixel Test Engineering 团队任何形式的公开说法。开源争议里，仓库 README 改一行字、加一个 Credit 段落，是最低成本的澄清信号。README 在 9 月 11 日之后悄悄补上 mobile-use 的出处，才说明 Google 认了这层关系；在此之前，不补只说明它还没打算在文档层面回应。