整理 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

开源代码被别人拿去用，并不是什么稀奇事。

但如果你发现，对方项目里 229 个文件有 228 个与自己的项目完全一致，连工程师随手起的 Agent 名字、Prompt 都一字不差；可原本写在项目里的 3 个作者姓名，还曾出现在对方的 Git 历史中，后来却被替换成了另一个名字——这就很难只用“开源代码复用”来解释了。

最近，AI 初创公司 Minitap 创始人兼 CEO Nicolas Dehandschoewercker 公开发文，指控 Google 新推出的开源移动自动化工具 Artemis 大量使用了其开源项目 mobile-use 的代码，却没有按照许可证要求保留原有署名。

更讽刺的是，这段被“拿走”的代码，曾在 Google 自家的基准测试中击败过Google。

从 AndroidWorld 第一名，到发现 Google 的 Artemis

Minitap，是一家来自法国的 AI 初创公司。2025 年，这支仅 10 人的团队打造了 mobile-use——一个能让 AI 智能体通过自然语言控制真实 Android 设备的开源项目。他们最初的目标很明确：造出世界上最好的移动端 AI 智能体。

他们不仅做到了，而且做得极其出色：mobile-use 在 Google DeepMind 维护的 AndroidWorld 基准测试中登顶第一，成为首个在该基准上实现 100% 任务成功率的智能体框架，解决了全部 116 项、覆盖 20 款真实应用的多步骤任务。

要知道，Google 自己的基线智能体 M3A 最初只能完成 30.6% 的任务，人类成功率也不过 80%。凭借这一成绩，Minitap随后完成了 410 万美元的种子轮融资，之后逐渐把重心转向更强大的闭源版本，如今相关技术已用于 Minitap 的自动化 QA 产品。

转折发生在今年 9 月：Google 发布了 Artemis，一个面向移动设备自动化的开源项目。

一开始，Minitap 团队并没有觉得有什么特别，反正 GitHub 上已有不少手机智能体项目，Artemis 看起来也像是“又一个 Phone Agent”——直到他们真正打开代码：“等等，这不是我们写的吗？”

随后，Minitap 开始逐个文件比对，结果让他们大吃一惊：Artemis 总共 229 个文件，其中 228 个文件与 mobile-use 完全一致！

在官方博客中，Minitap 列出了详细的代码对比：

• 连接 Android 设备的 adb_tunnel.py 实现完全相同；

• 一个名为 Hopper 的 Agent（最初只是 Minitap 团队的一个随意命名，居然也出现在了 Google 的代码库里），其 Prompt 与 mobile-use 中的每个字都一样；

• 还有一个用于让 Agent 停留在 WhatsApp 中的示例，其任务内容、Alice、Bob、Charlie 等名字，以及注释和清理步骤，都与 mobile-use 中的示例相同。

甚至，就连一个历史 Bug 都出现了类似痕迹：某个辅助函数会先写入结果文件，然后在下一次运行时读取自己此前生成的文件并失败。Minitap 称，他们在两套实现中复现了相同问题，而 Artemis 后续已经修复了这个 Bug。

其实单纯看到这些代码，并不是 Minitap 最在意的事情，毕竟 mobile-use 本来就是开源项目——问题出在接下来发生的事情。

在11月20-21日 · 北京万达文华酒店，「2026 奇点智能技术大会 与 C++ 及系统软件技术大会」现场，本文讨论的 AI 编程工具的能力边界、程序员的核心竞争力、研发效能与语言演进等议题，正是本届大会的核心专题——现场 70+ 一线实战技术嘉宾、18 大 AI 与系统软件专题。

扫码免费领取大会历届演讲 PPT 大礼包、Agent 实战训练营录播课——先睹为快

3 个作者名字被换掉，Git 历史中还能看到

后来，Minitap 又进一步查看 Artemis 的 Git 历史，发现了一个最令他们心寒的细节。

在 Artemis 某个较早版本的项目文件中，曾经出现过 mobile-use 的 3 个作者：Pierre-Louis Favreau、Jean-Pierre Lo、Nicolas Dehandschoewercker。

但在后来的版本里，这 3 个名字被全部替换成了另一个人。

而且，根据 Minitap 对 Git 历史的调查，相关 Commit 中被修改的部分就是作者列表，其他代码基本没有变化。Minitap 还称，这次替换发生在今年 8 月的一次强制推送（Force Push）中。

这也是整个事件最受关注的地方：“使用开源代码”与“抹掉开源代码的来源”并不是一回事。

据了解，mobile-use 使用的是 Apache License 2.0。这是一种相对宽松的开源许可证，允许使用者复制、修改、分发代码，甚至将其用于商业项目——但“宽松”并不等于“无限制”。

Apache 2.0 第 4 条明确规定，在分发源代码形式的衍生作品时，需要保留原项目中的版权、专利、商标和 attribution notices（署名/归属声明）；如果原项目包含 NOTICE 文件，其中相关的归属声明也需要在衍生作品中保留。

而 Minitap 表示，他们不仅采用 Apache 2.0，还专门提供了 NOTICE 文件，其中明确要求进行署名。

“我们不介意 Google 使用代码，但请别删掉名字”

于是，社区讨论很快从“Google 有没有复制 Minitap 代码”，转向了另一个更具体的问题：如果代码确实来自一个 Apache 2.0 项目，那么在重新发布时，原作者的署名是否被正确保留？

Minitap 的态度其实也相当明确：他们之所以开源 mobile-use，就是希望其他开发者可以拿去使用、修改甚至继续构建新产品，Google 当然也可以这么做——问题并不是 Google 用了他们的代码，而是 Google 没有正确说明代码来源，并且删除了原作者信息。

正如 Minitap 创始人兼 CEO NicolasDehandschoewercker 在博客中所说：

“在另一个项目中看到熟悉的代码，这是我们开源项目时就知道会发生的事情。不过，如果这段代码是以谷歌的名义出现的，却没有注明其来源，这种情况就让人难以接受了。”

在社区讨论中，也有网友指出，即使暂时不讨论法律层面，开源社区依然存在一个很基本的协作规则：可以复用别人的工作，但应该让后来的人知道这项工作是谁完成的。

对于程序员来说，代码仓库里的作者信息、Commit、NOTICE 和 README，并不只是几行无关紧要的文字。它们记录了项目从哪里来、谁做过什么，也让后来者能够找到原作者、理解代码背景，并继续贡献。

Minitap 创始人也表示，自己最失望的并不是 Google 用了他们的代码，而是他们不得不通过 Google 的 Git 历史，才能重新找回自己团队的名字：

“这些代码文件的背后，是一个个活生生的人。我见证了他们为此付出的努力、倾注的心血，以及他们对所构建成果的深切在乎。我希望他们能看到自己的成果被使用，并为自己的工作感到自豪。”

Google 已补上声明，但并未解释“抹名”原因

在事件曝光后，Google 很快对 Artemis 的代码进行了修改，并在项目中添加了一份声明：“本项目包含由 Minitap 公司开发的源代码”。但截至目前，Google 尚未发布一份单独的公开声明解释此前的作者信息变更。

对此，Minitap 方面认为，这个补充实际上间接证实了 Google 已经承认相关代码来自 mobile-use，只是在最初使用时未能正确履行署名义务。

值得一提的是，Minitap 创始人在博文中透露，他们曾把 mobile-use 当作开源研究项目开发，但从今年 2 月之后，团队已经转向开发更加成熟的闭源版本。也就是说，Google Artemis 即便确实使用了此前的 mobile-use 代码，也并不等于拿走了 Minitap 当前产品的全部技术成果。他直言：“Google 目前采用的部分设计理念，实际上已经落后我们当前产品大约七个月。”

或许会有人因此质疑：既然如此，那为什么还要追究？对于 Minitap 来说，他们真正想要的其实并不复杂：代码可以拿，项目可以继续做，甚至可以做得比原项目更好，但请把那些真正写下第一行代码的人留下来。

毕竟，开源最重要的东西，有时候并不只是代码本身，还有代码背后的人。

参考链接：//www.reddit.com/r/reinforcementlearning/comments/1wg1unx/google_copied_our_opensource_code_removed_our/

AI 写代码越来越快，但真正的瓶颈早已转移：上下文、评测、Review、反馈、组织协作。

11 月 20-21 日，北京万达文华酒店，2026 奇点智能技术大会「AI 原生软件研发：从 Harness 到 Loop」专题，来自腾讯 CodeBuddy&Workbuddy 团队陈秋远、北航杨健、百度 Comate 牛万鹏、滴滴金晶、腾讯任磊达等 7 位一线实践者，从代码大模型到仓库级智能体，从 Feedback Loop 到 Graph Engineering——一条链讲完。