Google本应做得更好

# 我对Google期望更高 来源：https://www.minitap.ai/blog/i-expected-better-from-google 当我们在办公室听到Google发布了用于自动化移动设备的Artemis项目时，我和团队正在一起工作。我们打开仓库查看。我的反应非常直接： "什么鬼？这是我们写的代码。" 我们构建了 mobile-use（https://github.com/minitap-ai/mobile-use）作为一个开源研究实验，旨在验证AI代理能否可靠地与手机交互。我们通过二月份完成了这项工作，然后专注于一个更新、更强大的闭源版本，该版本现在为Minitap的网页和移动端质量检测提供支持。 在发布作品供人使用时，在其他项目中找到熟悉的代码是可以预期的。但发现它在Google名下，且没有注明来源，这就让人难以接受了。 然后我们查看了历史记录，在一个更早的版本中发现我们的名字。它们已被移除。 我对Google感到失望。我认为这不仅关乎我们自己的仓库，因为开源依赖于人们愿意持续分享他们的工作。这些工作如何被对待至关重要。 ## 我们识别出的内容 这些例子非常具体。连接Android设备的部分代码与我们的实现完全一致。Hopper代理的指令逐字逐句完全相同。这些匹配项在我们9月11日检查的Artemis版本中仍然存在：这是Artemis设备代码（https://github.com/google/artemis/blob/086078819209c7139d6f833cfdc6d5cc80d9f19a/artemis/clients/adb_tunnel.py#L91-L306），旁边是我们对应的代码（https://github.com/minitap-ai/mobile-use/blob/cc20e3d52bf6dac1dff07f7b894520b8aeb051b7/minitap/mobile_use/clients/adb_tunnel.py#L82-L297），以及Artemis提示词（https://github.com/google/artemis/blob/086078819209c7139d6f833cfdc6d5cc80d9f19a/artemis/agents/hopper/hopper.md）和我们对应的提示词（https://github.com/minitap-ai/mobile-use/blob/cc20e3d52bf6dac1dff07f7b894520b8aeb051b7/minitap/mobile_use/agents/hopper/hopper.md）。 关于Hopper的有趣事实：我们当时不知道该给那个代理取什么名字。我们的一位工程师让-皮埃尔（Jean-Pierre）喜欢《我的世界》（Minecraft），觉得这个名字很酷，于是我们就用了。这就是命名的理由。看到相同的指令在Google的仓库中附带着相同的名字，感觉非常熟悉。 一个让代理停留在WhatsApp内的示例，其发送新年快乐消息给Alice、Bob和Charlie的任务完全相同，注释和清理步骤也完全一致。这些内容也还在那里。可以对比Artemis消息示例（https://github.com/google/artemis/blob/086078819209c7139d6f833cfdc6d5cc80d9f19a/artemis/sdk/examples/app_lock_messaging.py#L43-L87）与 mobile-use 示例（https://github.com/minitap-ai/mobile-use/blob/cc20e3d52bf6dac1dff07f7b894520b8aeb051b7/minitap/mobile_use/sdk/examples/app_lock_messaging.py#L10-L54）。 更早的版本甚至共享了同一个bug：一个辅助函数会写入结果文件，然后在下一次运行尝试读取其自身输出时失败。我们在两个实现中重现了相同的故障（https://github.com/google/artemis/blob/206a9ce921367ca10091c79ad00e116f195850ff/artemis/utils/media.py#L47-L207）（https://github.com/minitap-ai/mobile-use/blob/cc20e3d52bf6dac1dff07f7b894520b8aeb051b7/minitap/mobile_use/utils/media.py#L30-L190）。Artemis后来修复了这个问题。 作者历史更令人费解。一个更早的包文件（https://github.com/google/artemis/blob/14e02c4c27bc5b3c0d07e9a7b3b20141d6af9348/pyproject.toml#L20-L24）列出了Pierre-Louis Favreau、Jean-Pierre Lo和Nicolas Dehandschoewercker。替换它的版本（https://github.com/google/artemis/blob/206a69ce921367ca10091c79ad00e116f195850ff/pyproject.toml#L20-L22）移除了所有这三个名字，并用另一个作者替代。该文件唯一的变化就是作者列表。GitHub的活动记录（https://github.com/google/artemis/activity?activity_type=force_push）显示，这次替换发生在八月的一次强制推送中，早于我们九月的调查。 一个更早的Artemis包文件将Pierre-Louis Favreau、Jean-Pierre Lo和Nicolas Dehandschoewercker列为作者。（https://cdn.sanity.io/images/5b5hto6c/production/8a4a9cd2ceb3a1679ca5033e6209fc7d558e81a0-1360x980.png） *我们名字出现在早期的Artemis包文件中。GitHub现在将此版本标记为已脱离；其活动记录（https://github.com/google/artemis/activity?activity_type=force_push）显示它之前位于主分支上。文件（https://github.com/google/artemis/blob/14e02c4c27bc5b3c0d07e9a7b3b20141d6af9348/pyproject.toml#L20-L24）*。 替换后的Artemis包文件列出了另一位作者，取代了三个Minitap的名字。（https://cdn.sanity.io/images/5b5hto6c/production/4fa1126fcee7ceacdca0fa09a4f800518b9d5409-1360x980.png） *替换后的作者列表。来源（https://github.com/google/artemis/blob/206a9ce921367ca10091c79ad00e116f195850ff/pyproject.toml#L20-L22）*。 Artemis也包含其自身的工程成果。它可以在同一处承认该成果以及其整合的 mobile-use 代码。然而，我们查看的 README（https://github.com/google/artemis/blob/086078819209c7139d6f833cfdc6d5cc80d9f19a/README.md）并未致谢 mobile-use。我们已将详细比较、归档文件和时间线放在一份公开的事实记录中（https://marvelous-doll-1e9.notion.site/Factual-record-of-events-Artemis-mobile-use-3d8cf438d3ea8060b4eecc83fb3854b9）。 ## 分享代码本应促进协作 我们选择开源是因为我们希望其他人能基于 mobile-use 进行构建。应该有人能沿着我们从未考虑过的方向发展它。他们应该能够改进它，将其转化为产品，或在许可条款内构建一个竞争性项目。 有一些常规方法可以做到这一点，同时保持其起源清晰。一个Fork（https://docs.github.com/en/pull-requests/reference/forks）会链接回原始项目。一个导入的副本可以记录其来源。版权和署名声明可以随代码保留。一个README可以解释哪些部分来自其他地方，以及新团队添加了什么。 其中一些是既定的工程实践。有些是许可证所要求的。用于当前比较的 mobile-use 源代码采用 Apache 2.0 许可证，其再分发条件包括保留适用的版权和署名声明，并标识变更。它还规定，当上游`NOTICE`文件包含在发行版中时，需保留其中的相关署名。Apache 2.0 第4节（https://www.apache.org/licenses/LICENSE-2.0） 这些信息对所有后来者都很有用。它帮助人们找到原始维护者，理解设计决策，报告bug，或分享修复。它为贡献者提供了他们构建了什么的记录。它让新项目能够诚实地解释自己的贡献。 我不应该需要恢复一个仓库的旧版本才能发现这种关系。维护者们已经在花费时间回答问题、审查贡献并保持项目正常运行。在一家大公司重新发布他们的作品后，还要追讨缺失的署名，这是分享的又一项成本。一个将此视为常规的生态系统，会给人们另一个停止分享的理由。 我希望有更多人发布有用的软件，并更有信心地相信他们的作品在传播时仍将得到认可。 ## 我们的基准测试结果也难以获得关注 我们已经花费数月时间，要求将我们更新的结果反映在AndroidWorld的排行榜（https://docs.google.com/spreadsheets/d/1cchzP9dlTZ3WXQTfYNhh3avxoLipqHN75v1Tb86uhHo/edit?gid=0）上。 维护者应用了我们早期的提交，最高达到91.4%，最后确认是在2025年12月。然后我们提交了94.8%，接着在1月份的评估中提交了100%。我们发送了两次跟进邮件。这四封邮件均未收到回复。我们的结果和任务追踪（https://www.minitap.ai/benchmark）可供查验。 截至9月11日，该表格仍显示 mobile-use 为91.4%，而Artemis显示为99.1%。这些是自我报告的结果；排行榜明确表示不独立验证它们。这一限定也适用于我们报告的100%。 Artemis自身的比较图表（https://github.com/google/artemis/blob/086078819209c7139d6f833cfdc6d5cc80d9f19a/docs/assets/androidworld_leaderboard.png）遗漏了我们。它包含了DroidRun，其分数与 mobile-use 相同，以及一个无关的MadeAgents项目MobileUse（https://github.com/MadeAgents/mobile-use），分数更低。 Artemis发布的AndroidWorld比较图表包含了DroidRun和MadeAgents的MobileUse，但遗漏了Minitap的mobile-use。（https://cdn.sanity.io/images/5b5hto6c/production/a6cbba90bfc6899f37b1bde27cb525fc92a322c4-2640x1380.png） *这是Artemis自己的图表。底部附近的“MobileUse”是另一个项目。来源（https://github.com/google/artemis/blob/086078819209c7139d6f833cfdc6d5cc80d9f19a/docs/assets/androidworld_leaderboard.png）*。 我们没有证据将未回复的邮件或图表遗漏与移除我们名字的行为联系起来。但这是我们试图让公共记录反映我们工作的经历的另一部分。我们希望得到对这些提交的回应，并对比较作出解释。 ## 我们已联系Google 我们已经联系了Google团队。Artemis仓库上还有一个公开议题（https://github.com/google/artemis/issues/40）。我们要求他们承认Artemis部分源自 mobile-use，为其背后的人员署名，并正确处理归属问题。当我们有实质性内容要分享时，我会更新这篇文章。 ## 让我失望的地方 **我对Google感到失望。**这家公司曾给我们带来了Kubernetes（https://opensource.google/projects/kubernetes）和TensorFlow（https://blog.google/innovation-and-ai/products/tensorflow-smarter-machine-learning-for/）。当它推出Chrome时，它明确致谢了WebKit和Firefox，写道：“我们欠许多开源项目一个巨大的人情。”Google有着正确处理此方面历史，并发布了处理他人代码的指南（https://opensource.google/documentation/reference/releasing/preparing#third-party-components）。这正是我期望更高的原因。原始的Chrome发布公告（https://googleblog.blogspot.com/2008/09/fresh-take-on-browser.html）。 **我为我的团队感到失望。**他们在 mobile-use 上完成了不可思议的工作。在十二月、一月和二月，他们专注于让这个工作成功。我看到了其中付出的努力。这些是他们的实现、他们的示例、他们那个受《我的世界》启发的奇怪代理名字。我希望他们看到自己的工作被使用并为此感到自豪。不得不去挖掘别人的仓库来证明他们写了这些代码，这真是一个糟糕的结果。 **我为开源社区感到失望。**它值得比这更好的对待。人们将自己的作品分享出来，是为了让其他人可以学习并基于其构建。这些作品背后的人和项目应该保持可见性。如果连Google的一次发布都意味着维护者必须追讨自己的署名，那么我们就是在让人们更难对分享感到满意。这不是我想参与的那种开源。 好的一面是，为Minitap提供动力的当前版本是闭源的。而且它现在已经是一个完全不同的东西了。