移动端 AI 智能体赛道上，一场关于技术所有权与开源伦理的风暴正在发酵。2026 年 9 月 11 日，初创团队 Minitap 正式公开指控 Google 新发布的自动化项目 Artemis 严重抄袭其开源项目 mobile-use，并提供了详实的代码历史铁证。这绝非单纯的算法思路撞车，而是一次性质恶劣的代码搬运：Artemis 不仅照搬了连接底层的核心模块与调试提示词，更在发布前夕通过一次 Git 强制推送，物理抹去了三位原创工程师的名字。

当大模型加速走向手机界面控制，巨头与小团队的工程差距并没有外界想象的那么巨大。在此次事件中，Google Pixel 内部团队为了追逐基准跑分，直接吸纳外部初创团队的研发成果，却在代码合规上粗暴跨越了底线。这暴露出巨头在敏捷发布与模型上下文协议集成的高压下，内部开源治理流程已然形同虚设。

偶然发现的代码孪生与物证链条

事情起源于 Google 内部 Pixel-Test-Engineering Fusion 团队发布的 Artemis。该项目主打利用 ADB、视觉坐标与模型上下文协议（MCP）在实体设备上实现应用操作，上线后迅速在 GitHub 斩获约 900 颗星标与近 100 次 Fork。在开发者社区讨论中，许多人初看其 Flash 与 Pro 双模式调度，给出了极高评价。

随手借用的游戏代号，成了无法抹除的代码孪生物证(示意图)
随手借用的游戏代号，成了无法抹除的代码孪生物证(示意图)

但当 Minitap 团队打开该仓库时，映入眼帘的却是完全一致的代码实现。在与 Android 设备建立底层通道的 adb_tunnel.py 模块中，从建立连接到数据封包的处理逻辑近乎逐行对应。更具特异性的是命名与提示词：Minitap 工程师 Jean-Pierre 当初因个人喜好、随手借用游戏《Minecraft》命名的 Hopper 智能体，其全套系统提示词在 Artemis 仓库中字句不差地复现。

代码考古：Artemis 与 mobile-use 的特异性重合证据 特异性标识：Hopper 提示词 源于工程师游戏爱好的命名与全套 Prompt 逐字照搬，未作任何重新编写 逻辑克隆：测试用例与历史 Bug WhatsApp 给 Alice/Bob/Charlie 发信示例 媒体工具写入后读取失败的同源缺陷 关键痕迹：Git 元数据与署名抹除 2026 年 8 月通过 force push 替换 pyproject.toml 文件 三位原创作者姓名被蒸发，整体文件未保留来源说明与致谢

除了命名，业务样例与工程缺陷也成了无可辩驳的指纹。在测试应用锁定的场景中，Artemis 保留了完全一致的 WhatsApp 样例，连向 Alice、Bob 与 Charlie 发送新年祝福的假数据以及清理逻辑都原封未动。更具说服力的是一处媒体读写 Bug：辅助工具在写入结果文件后，因格式解析错误而在二次读取时崩溃，该缺陷在两份代码中表现出完全一致的报错轨迹，直到后期 Artemis 才单独修补。

一次推翻“架构自然趋同”的强制推送

在此类纠纷中，大厂通常会以基准测试驱动下的技术方案趋同作为抗辩理由。特别是在 AndroidWorld 涵盖 20 款应用、共计 116 项操控任务的标准环境下，使用无障碍层、视觉层次与 ADB 的工程选型确实存在收敛可能。早期的外部第三方评估也曾倾向于认定两者不存在直接抄袭，仅仅是技术路线一致。

然而，深埋在 Git 提交历史中的痕迹击碎了这种解释。在 2026 年 8 月的一次 Git 强制推送之前，Artemis 的配置文件 pyproject.toml 中清晰记录着 Pierre-Louis Favreau、Jean-Pierre Lo 以及 Nicolas Dehandschoewercker 三位 Minitap 开发者的全名。这次强制推送唯一的改动，就是将这三位作者删除并替换为另一位人员，随后在公开发布的 README 中彻底隐去了来源信息。

事件演进线：从论文破局到署名蒸发 2026 年 2 月 arXiv 论文公开 AndroidWorld 跑分 100% 2026 年 8 月 Git Force Push 强行移出 3 位原作者署名 2026 年 9 月 Artemis 上线并遭指控 Minitap 公开全套事实证据

这表明 Artemis 并非从零编写，而是在引入了 mobile-use 原型分支的基础上演进而来。Minitap 于 2026 年 2 月 8 日在 arXiv 发表论文，宣布其六智能体架构在 AndroidWorld 测评中达到 100% 成功率；其开源项目已累积约 2800 颗星标。Google 团队在自身实现 99%+ 跑分成绩并制作对比图表时，不仅未回复对方提交最新成绩的往来邮件，甚至在官方图表中刻意遗漏了 Minitap 的成果，转而并列了其他同分或低分项目。

抹去提交记录容易，但代码逻辑中留下的工程指纹无法被轻易清洗。
  • 风险.采用被污染开源基建的下游团队，随时面临不可预期的合规清理与重构成本。

宽松协议不是洗稿通行证与工程审查失守

在软件工程中，许多人存在误区，以为宽松协议等同于可以任意处置。事实上，两款项目均遵循 Apache License 2.0。虽然该协议允许修改和闭源商业化，但其第四条明确规定，再分发者必须保留原项目的所有版权、专利与归属声明，且修改处需提供说明。

撕开表层贴纸，底层被掩盖的原厂版权钢印清晰可见
撕开表层贴纸，底层被掩盖的原厂版权钢印清晰可见

Minitap 虽然在其项目声明中请求使用者保留对 Minitap, Inc. 的致谢，并注明这属于社区倡议性质，但 Apache 2.0 对原始作者版权声明的保留是法定约束。当 Google 团队强行洗去原作者署名并将版权标记更改为 2026 Google LLC 时，其行为已在法理上踩入了开源许可违约的深水区。

Code
协议合规红线：
Apache 2.0 赋予商用与修改自由的前提，是完整保留原始 NOTICE 与版权声明；
一旦主动剥离原作者署名，再分发行为即刻丧失合法授权基础。

Google 拥有业界成熟的开源办公室（OSPO）和内部合规流程，历史上无论在 Chrome 致敬 WebKit，还是对外输出 TensorFlow，都曾是开源规范的标杆。此次 Artemis 的合规失守，更像是一线工程团队在面对模型操控界面的内外部竞争压力时，走的一条激进捷径。开发人员将经过验证的成熟实验组件整包引入，却在剥离敏感提交历史时采取了掩耳盗铃的粗糙手段。

  • 建议.企业评估引入开源端侧自动化框架时，必须先行穿透审查其上游提交树的知识产权纯洁度。

对于普通开发者与企业用户而言，端侧智能体已是兵家必争之地。但依赖抹去来源所换取的快速发布，给下游应用者带来了巨大的隐患。目前，Minitap 已在 Artemis 仓库发起 Issue 并递交事实档案，要求 Google 正式更正归属声明。巨头若想挽回社区信誉，正视白纸黑字的代码起源是唯一的解法。