Google Artemis 代码争议：Minitap 称 mobile-use 署名被移除

在 Minitap 指出 Google 新近公开的 Android 自动化项目 Artemis 中存在疑似复制的代码和提示词后，Google 面临一场开源署名争议。

Google Artemis 代码争议不止涉及两个移动智能体之间的理念相似。Minitap 表示，Artemis 中出现了完全一致的实现细节，却没有可见的署名。该公司还展示了仓库历史，显示其开发者曾被列为作者，随后这些姓名消失。

这段历史构成了争议核心。Minitap 依据 Apache License 2.0 发布了 mobile-use，允许在特定条件下进行修改和商业复用。这家初创公司反对的是在来源不明的情况下疑似复用，而非 Google 开发一款竞品工具。

公开记录已经发生变化。截至 9 月 13 日，Artemis README 表示该项目包含由 Minitap 开发的源代码。这一致谢并未出现在 Minitap 9 月 11 日文章所描述的版本中。

Google 目前的致谢回应了最直观的投诉，但并未解答所有问题。剩余问题包括哪些组件源自上游、署名何时消失，以及是否遵守了全部适用的许可条件。

Minitap 在 Google Artemis 中发现了什么

Minitap 最有力的证据是匹配的代码、匹配的提示词和更早的作者列表三者的组合，而不是某一个共享的架构理念。

Artemis 和 mobile-use 都允许 AI 智能体通过自然语言指令操作手机。这种广泛的相似性说明不了太多，因为许多移动智能体都会使用截图、无障碍数据、规划循环和设备控制工具。

Minitap 的指控在实现层面更为具体。其公开说明指出，Artemis 中的 Android 连接逻辑与此前在 mobile-use 中发布的代码相匹配。

该公司还特别提到一个名为 Hopper 的智能体。在 Minitap 的系统中，Hopper 会在大量屏幕和交互历史记录中搜索与当前任务相关的信息。

Minitap 表示，Artemis 包含相同的 Hopper 提示词，其中措辞和示例均相匹配。提示词的一致性很重要，因为在智能体系统中，详细指令可以起到类似源代码的作用。

“搜索历史记录”这样的通用指令可能独立出现。但一个在结构、示例、名称、注释和清理行为上完全一致的长提示词，就更难被视为巧合。

该公司还指出了一个消息示例。它表示，两个项目采用了相同的示例姓名、注释和操作顺序。

当示例保留了功能并不要求的任意选择时，它们可以揭示来源。两种实现或许会独立连接到 Android Debug Bridge，也就是通常所称的 ADB；但它们不太可能在一段较长示例中独立选择相同的虚构细节。

Minitap 还声称，两个项目共享一个文件处理缺陷。根据其文章，Artemis 后来修正了这一行为。

共享缺陷可能构成有意义的证据，因为开发者通常会复制预期行为，而不是意外的故障模式。不过，在未完成全面且针对特定版本的比较前，读者不能将这一线索视为最终技术结论。

最具影响力的证据涉及软件包元数据。Minitap 表示，较早版本的 Artemis 软件包文件将 Pierre-Louis Favreau、Jean-Pierre Lo 和 Nicolas Dehandschoewercker 列为作者。

这些姓名对应与 Minitap 的 mobile-use 工作有关的贡献者。Minitap 表示，后续修订将他们替换为另一位作者，而相关文件其余部分保持不变。

该公司将这一替换与 8 月的一次强制推送联系起来。强制推送会重写 Git 分支的可见历史，可能将提交从分支中移除，而不会立即抹去所有底层对象或外部副本。

这一区别很重要。强制推送在仓库清理过程中很常见，但当被重写的提交包含与后续争议相关的来源信息时，其意义就不同了。

Minitap 表示，尽管该提交已不再附着于主分支，它仍通过 Git 历史恢复了早期修订。因此，该指控部分建立在历史仓库证据之上，而不只是当前文件。

目前没有法院、监管机构或独立代码审计组织就这些主张作出裁决。现有证据支持进行仔细审查，但这一指控仍是 Minitap 有记录可查的陈述。

Google 尚未在本文审阅的材料中公开解释作者信息为何被替换。它也没有提供逐文件说明，列出 Artemis 中哪些组件源自 mobile-use。

这一缺失的解释使完整还原过程成为不可能。但它并不能抹去 Minitap 所描述的可见相似性主张或早期元数据。

眼下的变化仍然具体。一支小型开源团队公开质疑了 Google 仓库，而 Google 当前的 README 现已承认其中包含由 Minitap 开发的代码。

Google Artemis 代码争议为何重要

压力落在 Google 身上，是因为其机构信誉令清晰的来源记录更加重要，而非不那么重要。

开源开发依赖于许可和署名承担不同职能。宽松许可证赋予下游开发者广泛自由，而来源记录则用于确认底层工作由谁创建。

Minitap 明确表示，欢迎复用。它反对的是，开发者不应在面对一个表面上独立的 Google 项目时，却无法得知其中部分代码来自 mobile-use。

这种担忧不止关乎认可。来源记录有助于维护者追溯安全缺陷、架构决策、上游修复和不兼容修改。

如果下游用户无法识别组件来源，他们可能会向错误的团队报告缺陷，也可能错过上游项目中已提供的修复。

评估 Artemis 的开发者需要了解哪些部分由 Google 独立维护。他们还需要知道继承行为从何处开始，以及 Google 的修改在何处产生分歧。

这些信息会影响技术尽职调查。采用设备测试智能体的团队必须评估维护责任、依赖项、许可证，以及基准测试主张的可靠性。

Google 的名称会提高外界预期，因为该公司发布了广泛的开源指导。其文档称，在代码公开前，发布审查应检查许可证头和其他必需材料。

Google 还维护 Android、Chromium、TensorFlow、Kubernetes 及许多其他广泛使用的项目。其团队经常要求外部贡献者和公司遵循结构化的许可流程。

因此，Google 组织内部的来源记录疏漏具有象征性分量。独立维护者期待最大的科技公司示范其在其他地方所要求的行为。

双方之间的不平衡进一步加剧了这种压力。一家初创公司可以发布有价值的研究和代码，但更大型的组织发布类似系统后，往往能获得更多关注。

搜索结果、社交传播和品牌认知可能迅速将一种方法与更大的发布者联系起来。即便代码依然可用，缺少署名仍可能掩盖小团队的贡献。

这正是故事中的主要反转。开源让 Google 有权基于共享成果继续构建，但同样的开放性也暴露了支持 Minitap 投诉的证据。

公开 Git 仓库会保留差异、分支、副本缓存页面、软件包文件和游离提交。重写分支无法保证早期作者记录从所有副本中消失。

这场争议也影响 Minitap 之外的贡献者。开发者是否发布有价值的成果，部分取决于他们观察下游组织如何对待来源和致谢。

宽松许可证之所以鼓励采用，是因为它们施加的商业限制更少。当使用者尊重仍然存在的有限条件，并如实传达来源时，这一模式才可持续。

如果小团队认为宽松许可发布的成果会在没有认可的情况下被吸收，他们可能会延迟公开。其他团队可能选择更严格的 copyleft 条款，或将具有战略意义的组件保持私有。

这两种回应都不必然惠及用户。当研究人员能够审查智能体、复现结果、比较策略，并跨组织边界贡献修复时，移动自动化才能得到改进。

这里的教训不是公司应避免使用开源代码，而是内部发布流程必须在代码进入经过打磨的企业仓库之前保留上游历史。

这一流程应包括来源清单、自动相似性检查、依赖记录、许可证审查和人工验证。一个可搜索的工程知识库也可以让来源信息与设计决策保持关联。

仓库维护者应在发布前记录复制的文件和实质性改编。在争议发生后补充署名，优于让它持续缺失，但无法替代清晰的开发记录。

因此，Google 面临的压力是解释整个过程，而不仅仅是保留新加入的那句话。该组织必须说明，这一遗漏究竟是孤立的发布失误，还是更薄弱的来源记录流程的证据。

当前致谢改变了故事，但没有改变历史

Google 当前的 README 承认了 Minitap，使争议从尚未解决的遗漏转变为关于署名如何及为何消失的争议。

当前 Artemis 仓库将其描述为由 Google Pixel Test Engineering Fusion 团队构建的 Android 自动化系统。它提供两种执行配置，以及面向 AI 编程助手的集成。

Flash 模式使用响应式观察与行动循环。Artemis 表示，在压缩较早的交互历史时，它通常每一步需要三到五秒。

Pro 模式使用规划和验证组件。它会在执行前根据当前界面数据检查拟议操作，并支持更长的测试工作流。

该仓库还介绍了 Model Context Protocol 集成。MCP 是一种标准接口，兼容的 AI 助手可通过它调用外部工具并接收结构化结果。

这些特性表明，Artemis 不一定是 mobile-use 未经改动的副本。一个下游项目可以将继承组件与大量原创工程工作结合起来。

这一点并不与 Minitap 的投诉矛盾。即使衍生系统增加了新接口、安全检查、执行模式或诊断功能，署名问题依然适用于被复制的部分。

当前 README 现在在其许可证部分加入了直接声明：该项目包含由 Minitap 开发的源代码。这句话链接至 mobile-use 仓库。

这是一次有意义的修正。如今访问该项目的开发者无需进行取证式搜索，就能识别出 Minitap 是上游来源之一。

不过，这一声明仍较为笼统。它没有指出哪些文件、提示词、智能体或架构组件源自 mobile-use。

它同样没有解释此前的作者元数据。如果 Minitap 的重建准确，包配置中曾出现过三名具名贡献者，之后被替换。

项目层面的署名与个人作者身份相关，但并不相同。公司致谢可以指明上游组织，却仍可能无法厘清具体开发者的贡献历史。

一份详细回应可以消除大部分不确定性。Google 可以公布相关提交序列，解释强制推送，并将继承的组件对应到其原始修订版本。

它还可以说明作者信息变更是意外、仓库迁移的一部分，还是有意进行的元数据规范化。若没有这样的说明，外部人士只能从不完整的历史中推断意图。

意图关乎公众信任，但许可证合规往往取决于具体的分发实践。疏忽遗漏与蓄意删除可能产生相似的文件，却代表着不同的组织失误。

此次更正也让“Google 目前完全未给予署名”这类简单化标题变得复杂。截至 9 月 13 日，这种说法似乎已经过时。

准确的表述应当遵循时间线。Minitap 表示，在其记录这些相似之处时，Artemis 尚未包含致谢；而当前在线仓库已对 Minitap 开发的源代码作出署名。

读者还应避免将 Google 与所有使用 Google 托管仓库的贡献者混为一谈。公开仓库可能涉及团队、承包商、转移而来的项目，以及拥有不同审查流程的个人维护者。

该仓库标明了一个 Google 团队，因此对该公司进行审视是合理的。不过，本文审阅的证据尚不足以确定是谁批准或删除了此前的名字。

正因如此，Google Artemis 代码争议应继续聚焦于记录与流程。揣测个人动机只会加剧争议，无法提升核查质量。

当前的致谢强化了 Minitap 立场中的一部分。Google 的仓库现在明确承认其中存在 Minitap 的代码。

但这并不能独立验证原始文章中描述的每一个匹配示例，也不能证明此前的 README 违反了某一特定许可证条款。

它所确立的是一种代码来源关系。如今，Artemis 并未被描述为一个完全不含 Minitap 源代码而独立开发的代码库。

这一变化减少了新用户的即时困惑。它也为维护者提供了一个起点，以便比较两个系统，并追踪未来向上游提交的修复。

Apache 2.0 允许复用，但仍须遵守条件

法律问题比伦理争议更为狭窄，因为 Apache 2.0 允许广泛复用，并不要求满足所有被要求的署名形式。

两个项目均以 Apache License 2.0 发布代码。该许可证允许用户复制、修改、分发、再许可，以及将受覆盖作品用于商业用途。

这些权限使竞争者之间的开源协作成为可能。Minitap 无法合理地声称，发布 mobile-use 就意味着 Google 不得以此为基础进行开发。

Minitap 并未提出这一论点。其文章称，团队期待项目及其贡献者获得致谢。

Apache 2.0 条款对分发作品或衍生作品的一方施加了若干条件。接收者必须获得许可证副本。

修改过的文件必须附带显著声明，说明文件已被修改。源代码分发必须保留原始源代码中相关的版权、专利、商标及署名声明。

如果原始分发包含 NOTICE 文件，其中符合条件的声明必须在适当位置保持可读。该许可证也允许下游作者添加自己的声明。

这些规则并不等同于普遍要求 README 中必须包含某一句特定文字。此前 Artemis 仓库是否违反许可证，取决于确切的上游声明、复制的文件、修改内容及分发方式。

例如，包元数据中的作者列表可能是与来源相关的证据。其法律地位取决于它是否构成许可证要求衍生源代码分发保留的声明。

同样，删除一个名字在所有情境下都不必然违法。维护者有时会修改包元数据，因为其“authors”字段描述的是当前包的所有权，而非每一位上游贡献者。

周边事实决定这种解释是否成立。Minitap 强调，据称作者列表是其所比较修订版本中唯一的实质性变化。

Apache 指南说明，置于上游 NOTICE 文件中的署名声明在下游分发中会获得特定处理。当前可见的 mobile-use 仓库在根目录列表中并未突出显示顶级 NOTICE 文件。

这一缺失并不能解决争议。相关声明也可能出现在源文件或其他受覆盖材料中，而修改文件披露仍是一项独立要求。

许可证合规与社区规范之间的差异至关重要。一种行为可能满足最低限度的法律文本要求，却仍可能显得对维护者具有误导性或缺乏尊重。

反过来，缺少项目层面的致谢本身并不能证明违反许可证。法律结论需要对所涉确切版本进行具备资质的审查。

现有记录支持将此情况描述为一场署名争议。它不足以支持将 Google 侵犯版权或窃取代码认定为既定事实。

当上游项目已授予广泛复用权利时，“窃取”尤其不够准确。真正的指控是，Google 在使用这些权利时，未能保留充分的署名与来源信息。

这一指控依然严重。宽松许可证减少了限制，但并不会抹去作者身份，也不会让原创工程变成无主之物。

采用 Artemis 的开发者应保留项目当前的许可证及对 Minitap 的致谢。他们还应在重新分发修改版本之前审查任何嵌入式声明。

组织可以将提示词与示例视为承载来源信息的资产，以避免类似争议。智能体提示词日益包含详尽程序，其对系统行为的塑造与传统代码一样直接。

因此，发布审计不应只比较依赖清单。它还应检查配置、测试夹具、提示词模板、文档示例、基准测试脚本和包元数据。

法律团队不应独自承担这一负担。最接近实现细节的工程师，往往最清楚哪些组件来自实验、内部原型或外部仓库。

最佳流程是在代码进入项目时记录其来源。发布前再进行重建更困难，而在公开指控之后重建则更加困难。

基准测试主张带来另一层摩擦

署名证据应当独立评估，因为基准测试分歧既不能证明抄袭，也不能为缺失来源信息开脱。

Artemis 表示，它在 AndroidWorld 上的任务完成率超过 99%。该基准项目评估智能体在涉及多个应用程序的 100 多项 Android 任务中的表现。

AndroidWorld 提供了一个可复现的环境，用于测试智能体是否能够完成真实的设备操作。任务可能包括更改设置、管理应用内容，以及在多步骤界面中完成操作。

基准分数可以吸引用户并建立技术可信度。当两个相关系统报告出竞争激烈的接近结果时，它也可能放大署名争议。

Minitap 表示，公开排行榜此前显示 mobile-use 为 91.4%，Artemis 为 99.1%。它称，后续提交的 mobile-use 结果达到 94.8%，之后又达到 100%。

这些数字来自 Minitap 的说法，除非基准测试维护者独立验证，否则应视为自报数据。Minitap 自身也承认这一限制。

该公司表示，它曾联系排行榜维护者，要求更新 mobile-use 的结果。它还称，在争议发生前，这些尝试并未促成所要求的更新。

没有经验证的证据将排行榜延迟与仓库署名问题联系起来。它们涉及相关组织和技术，但时间上的接近并不能证明存在协调。

这种区分至关重要。代码证据可以通过文件和历史记录进行比对，而基准测试问题则涉及评估版本、提交时间、任务配置及审查程序。

不同分数可能源于合理原因。一个智能体可能使用另一种模型、不同提示词、更新的工具、调整过的重试规则，或更新的基准测试环境。

如果没有方法论说明，一个百分比也透露不出太多信息。读者需要知道测试所用提交、模型配置、任务子集、试验次数、失败策略及评估日期。

Artemis 目前将其结果概述为超过 99%。仅凭 README 中的标题性主张，无法获得独立复现该数字所需的全部细节。

mobile-use 也提出了强劲的性能主张。其开源仓库称，它成为首个完成 AndroidWorld 100% 任务的智能体框架。

任何一种说法都不应替代经过独立审查的结果。这一谨慎同样适用于 Google 和 Minitap。

当项目共享组件时，基准测试透明度更为重要。如果一个系统继承了另一个系统的大量代码，评估者需要知道哪些改进导致了所报告的差异。

更高的分数可能来自新的安全检查或执行调度，也可能反映修订过的提示词、不同模型、重复尝试，或从上游继承的变更。

没有确切配置，观察者无法归因于性能差距。他们应避免将排行榜名次变成对谁构建了更优底层系统的裁决。

这场争议仍对 Google 的技术叙事构成压力。Artemis 将可靠性作为其决定性特征，因此透明的技术谱系将帮助用户区分继承的基础与 Google 新增的内容。

Minitap 也面临相关责任。与截图或描述性摘要相比，其抄袭指控若能得到持久的差异比对、哈希值和可复现比较支持，就会更有说服力。

发布结构化比较将使独立开发者能够检查每一处被声称的匹配。它也会揭示应归功于 Artemis 团队的重要差异。

这种平衡的审计可改善两个项目。上游维护者将更清楚地看到有用的变更，而 Artemis 用户也可以追踪重要组件的来源。

对企业买家而言，实际教训很简单。基准分数和企业品牌并不能取代对仓库的尽职调查。

团队应固定经测试的提交版本，保留许可证材料，记录模型设置，并在自己的设备上复现关键工作流。移动智能体与不断变化的界面交互，因此昨天的百分比无法保证明天的可靠性。

开发者接下来应关注什么

三项信号将决定 Google Artemis 代码争议是以已纠正的疏忽收场，还是演变为更深层的治理问题。

第一项信号是 Google 或 Artemis 维护者作出的详细回应。当前对 Minitap 的致谢很有价值，但一条时间线将回答核心的历史问题。

该回应应说明哪些文件或组件来自 mobile-use，并解释 Minitap 所述的作者字段替换及 8 月历史重写。

清晰的说明将强化外界对监督问题的解读。持续沉默则会让仓库中最不寻常的证据始终无法得到解释。

第二个信号是持续性的来源信息更新。值得关注的包括 NOTICE 文件、文件级头部注释、提交记录恢复、第三方代码清单，或对个人贡献者更充分的致谢。

并非每项措施在每个仓库中都具有法律强制性。不过，精确的来源映射将帮助下游用户履行其自身的再分发义务。

这也会让未来维护更容易。开发者可以比对上游补丁，并判断某个缺陷究竟属于 mobile-use、Artemis，还是两者兼有。

第三个信号是可复现的基准测试文档。双方都可以通过公布确切提交记录、任务配置、模型设置、重试策略和评估日志来缓和紧张局势。

独立复现将显示，Artemis 宣称的性能究竟源于其新的工程工作、共享基础、配置选择，还是这些因素的组合。

这些信号的重要性不止于一个仓库。AI 智能体开发正日益混合源代码、自然语言提示词、示例、执行轨迹和基准测试工具。

传统依赖扫描器或许能识别导入的软件包，却可能遗漏被复制的提示词文件或手动转移的代码。这一缺口使人工来源审查更加重要。

公司应为每个外部组件建立引入记录。该记录应包括来源 URL、提交哈希、许可证、声明、修改内容以及负责审查的人员。

它们也应将同一体系应用于提示词。一段较长的智能体指令即便以纯文本形式存储，也可能编码了独特的规划方法、工具规则和恢复行为。

维护者还应尽可能避免在公开发布前后进行破坏性历史变更。若必须强制推送，应说明原因，并在替代提交中保留来源信息。

这些做法都不会阻碍竞争。它们让组织能够基于宽松许可证的软件快速构建，同时使其来源仍然清晰可辨。

对于在 Artemis 与 mobile-use 之间做选择的开发者而言，这场争议不会自动产生技术上的赢家。应根据所需的平台、工作流程、模型和验证控制措施来评估每个项目。

Artemis 目前聚焦于 Android 自动化、开发者工具、诊断和多种执行配置。Mobile-use 则在其智能体框架之外，提供了更广泛的 Android 和 iOS 支持路径。

用户应在真实应用中测试两者，而不应只依赖公开的百分比数据。他们还应关注各项目如何处理问题、上游修复以及涉及安全敏感设备权限的事项。

当前的致谢意味着 Google 已经改变了面向公众呈现的来源图景。尚未解决的问题是，它是否会给出仓库历史所要求的更深入解释。

Minitap 必须继续让其证据可供独立审查。Google 必须证明，其开源流程能够识别并保留来自一个规模小得多的团队的贡献。

这才是持久的考验。新增的署名会成为事件的终点，还是成为完整公开说明 Artemis 如何组装而成的起点？