团队在办公室时听说谷歌（Google）发布了 Artemis，一个用于自动化移动设备的项目。我们打开仓库翻看，第一反应几乎是脱口而出：这不是我们写的东西吗。我们做过 mobile-use，一个开源研究实验，想看看 AI 智能体能否可靠地与手机交互，一直做到 2 月，之后转去做更新、更强的闭源版本，如今它为 Minitap 的 Web 与移动端 QA 提供支持。

那天我和团队在办公室，听说 Google 发布了一个用来自动操作移动设备的项目 Artemis。我们打开仓库翻看，我的反应几乎是脱口而出：

「什么鬼？这是我们写的。」

mobile-use 是我们做的一个开源研究实验，想看看能不能让 AI agent 可靠地与手机交互。我们做到二月，之后转向一个更新、更强的闭源版本，现在它支撑着 Minitap 的 Web 和移动端 QA。

把作品公开给别人用，本来就会在别的项目里撞见熟悉的代码。但看到它以 Google 的名义出现，又不说明来源，就难接受得多。

接着我们去查历史记录，在较早的版本里找到了我们的名字。后来它们被删掉了。

我对 Google 感到失望。这件事不只关乎我们一个仓库，因为开源取决于人们愿不愿意持续分享，而这些作品被怎样对待，是有分量的。

我们认出了什么

例子很具体。连接 Android 设备的部分代码与我们的实现完全一致。Hopper agent 的指令一字不差。截至 9 月 11 日我们检查的 Artemis 版本，这些重合依然存在：Artemis 的设备代码对照我们的，Artemis 的 prompt对照我们的。

关于 Hopper 有个好玩的事：我们当初不知道该给这个 agent 起什么名字。工程师 Jean-Pierre 喜欢 Minecraft，觉得这名字酷，就这么定了。这就是全部理由。在 Google 的仓库里看到同样的名字配着同样的指令，感觉太熟悉了。

一个把 agent 限制在 WhatsApp 内的示例，同样是要给 Alice、Bob、Charlie 发新年祝福，注释和清理步骤都一样。它也还在。对比 Artemis 的消息示例和 mobile-use 的示例。

更早的版本甚至共享同一个 bug：某个 helper 写出结果文件，下一次运行时读取自己的输出就会失败。我们在两个实现里都复现了同样的失败。Artemis 后来把它修好了。

作者历史更难理解。早期的一个包文件列着 Pierre-Louis Favreau、Jean-Pierre Lo 和 Nicolas Dehandschoewercker。替换它的版本把三个名字全部删掉，换成了另一个作者。而文件唯一的改动就是作者列表。GitHub 的活动记录显示，替换发生在八月的某次 force push，早于我们今年九月的调查。

早期 Artemis 包文件里我们的名字。GitHub 现在把这个版本标记为 detached；其活动记录显示它此前位于主分支。

替换之后的作者列表。

Artemis 里也有它自己的工程工作。它完全可以在同一个地方既致谢这些工作，也致谢它采用的 mobile-use 代码。但我们检查的 README 没有提到 mobile-use。我们把详细对比、存档文件和时间线放进了公开的事实记录。

分享代码本该让协作更容易

我们选择开源，是希望别人能在 mobile-use 之上继续建设。有人应该能把它带向我们想不到的方向，可以改进它、把它做成产品，或者在许可证允许的范围内做一个竞争项目。

做到这些的同时保留来源，有很多常规做法：fork 会链回原项目；导入的副本可以注明出处；版权与署名声明可以随代码保留；README 可以说明哪些部分来自别处、新团队又加了什么。

其中一些是既定的工程实践，一些是许可证的要求。当前用于对比的 mobile-use 源码采用 Apache 2.0，其再分发条件包括保留适用的版权与署名声明、标明改动，也包括在分发中包含上游 NOTICE 文件时保留其中相关的署名。Apache 2.0 第 4 条

这些信息对所有后来者都有用。它能让人找到原维护者、理解某个设计决定、报告 bug 或分享修复，也给贡献者留下一份自己做过什么的记录，让新项目能诚实地说明自己的贡献。

我不该为了弄清这层关系，去翻出仓库的旧版本。维护者本来就要花时间回答问题、审阅贡献、让项目继续运转。被更大的公司重新发布作品之后还要追讨缺失的署名，是分享的又一项成本。一个让这种事变成常态的生态，会让人多一个不再分享的理由。

我希望更多人发布有用的软件，并且更有信心地认为，作品流传出去后仍会被承认。

我们的基准测试成绩也很难被听到

我们此前已经花了几个月，要求把更新的成绩反映到 AndroidWorld 的排行榜上。

维护者更新了我们早先提交的成绩，最高到 91.4%，最后一次确认在 2025 年 12 月。之后我们提交了 94.8%，接着在一月的评测中提交了 100%。我们又发了两封跟进邮件。这四封邮件都没有回复。我们的结果和任务轨迹可以公开查看。

截至 9 月 11 日，表格上 mobile-use 仍显示 91.4%，而 Artemis 出现在 99.1%。这些都是自报成绩；排行榜明确说明不会独立核实。这一限定同样适用于我们报告的 100%。

Artemis 自己的对比图把我们略去了。图里包含 DroidRun，分数与 mobile-use 相同，还有一个无关的、MadeAgents 的 MobileUse 项目，分数更低。

这是 Artemis 自己的图表。底部那个「MobileUse」是另一个项目。

我们没有证据把未回复的邮件或图表遗漏，与删除我们名字这件事联系起来。但这也是我们试图让公开记录反映自己工作的一部分经历。我们希望那些提交得到回应，也希望这张对比图有个解释。

我们已经联系了 Google

我们已经联系了 Google 团队，也在 Artemis 仓库上提了公开 issue。我们要求他们承认 Artemis 部分衍生自 mobile-use，给背后的人署名，把署名问题纠正过来。有实质进展我会更新这篇文章。

让我失望的地方

我对 Google 失望。这家公司给了我们 Kubernetes 和 TensorFlow。当年发布 Chrome 时，它明确致谢了 WebKit 和 Firefox，写道：「我们欠许多开源项目一份巨大的人情。」Google 历来做得不错，还发布过处理他人代码的指引。正因如此，我才期待更多。

我为我的团队失望。他们在 mobile-use 上做得非常出色。整个 12 月、1 月、2 月，他们都扑在这件事上。我看到了其中投入的努力。这些是他们的实现、他们的示例、他们那个从 Minecraft 来的古怪 agent 名字。我希望他们看到这些工作被使用，并为此骄傲。要挖别人的仓库才能证明是自己写的，这结果实在很糟。

我为开源社区失望。它值得比这更好的对待。人们把作品放出来，是为了让别人学习、在此基础上继续做。那些作品背后的人和项目，理应保持可见。如果连 Google 的一次发布都要让维护者去追自己的署名，我们就更难让人对分享有好感。这不是我想参与的那类开源。

好消息是，如今支撑 Minitap 的版本是闭源的，而且已经完全不是同一个东西了。Google，你晚了七个月。下次直接要个 demo 吧。

多数评论质疑 Google 未署名使用他人代码并疑似通过强制推送掩盖，少数人提醒原标题并未指称偷窃、需谨慎定性，另有声音更关注内部流程与公司文化。

认为 Google 违背“不作恶”并疑似掩盖

• 早期包文件列出三位原作者，后在 Artemis 项目中被强制推送仅替换为另一作者，且仅改动作者列表，社区认为这看起来像抹去贡献并尝试掩盖（较多人）。 > 他们现在正试图掩盖这件事（@harshavamsi）
• 以“不作恶”自诩的广告公司却使用未署名代码，引发讽刺，有人以“最好发起革命”的玩笑表达不满情绪（较多人，玩笑代表社区情绪）。

提醒标题夸大且原文未指盗窃

• HN 标题被指编辑化，实际文章标题为“我对 Google 期望更高”，原文并未使用偷窃等词，不宜直接预设侵权（少数人）。 > 原页面标题其实是“我对 Google 期望更高”，本文并未使用偷窃这类词（@RossBencina）
• 也有用户认为证据虽看似严重，但是否存在无辜解释仍值得疑问（少数人）。

关注事件背后的内部流程与公司文化

• 无论法律责任如何，更值得关注的是 Google 内部何种角色参与、何时知情及应对，借以观察当前工程文化（少数人）。 > 我感兴趣的是这事如何发生、涉及哪些 Google 角色、各自何时知情及做了什么（@neilv）

有价值的补充

• 社区有人贴出强制推送后的具体改动：新作者署名变为“somew1nd”及一个 Outlook 邮箱，以反讽语气称“看起来合法”，提供了追踪线索。