谷歌 Artemis 陷代码归属争议：移动自动化 Agent 的开源边界被重新审视

谷歌开源的 Android 移动自动化 Agent Artemis，正被 Minitap 指控未经适当署名，复用了其开源项目 mobile-use 中的代码、提示词和测试用例。争议的关键不在于谷歌能不能使用开源代码，而在于它是否完整履行了许可证要求，以及一个大厂项目在吸收社区成果后，是否应该对来源、修改和贡献关系做出足够透明的说明。

这起事件发生在 2026 年 9 月 12 日。根据 IT之家援引 Neowin 的报道，Minitap 联合创始人兼 CEO 尼古拉·德汉舒韦克公开表示，Artemis 中部分实现与 Minitap 的 mobile-use 项目逐字一致，涉及 Android 设备连接、Hopper Agent 指令处理以及 WhatsApp 消息任务等内容。Minitap 还称，Artemis 软件包中原本列有其开发者姓名的文件，曾在 8 月通过强制推送被替换。

争议的核心：不是“用了开源”，而是“怎么用开源”

开源许可证是软件作者预先授予使用者的一组权利和义务，而不是放弃版权。 这是理解 Artemis 争议的第一条原则。

从目前披露的信息看，相关代码采用 Apache License 2.0。这个许可证允许商业使用、复制、修改和再发布，限制相对宽松，开发者不需要像使用 GPL 代码那样公开整个派生项目的源代码。但宽松不等于没有条件：再发布时通常仍需保留版权声明、许可证文本和相关通知，并在修改过的文件中说明改动。若项目包含 NOTICE 文件，也需要按照许可证要求保留其中的归属信息。

因此，问题并不是“谷歌用了 Minitap 的代码，所以 Artemis 就不成立”，也不是“代码已经开源，任何人都可以随便拿”。真正需要核对的是几个可验证的事实：涉事代码是否确实来自 mobile-use；Artemis 的初始公开版本是否保留了必要的版权和归属信息；被替换的文件是否属于受许可证约束的派生部分；谷歌后来补上的说明是否覆盖了完整的许可证义务；以及相关修改发生在何时、由谁提交。

Minitap 的说法尤其值得关注，是因为它指向了“逐字一致”的具体实现，而不是泛泛地声称两个项目功能相似。Android 自动化本身有不少通用做法，例如通过 ADB 连接设备、读取界面状态、调用视觉模型识别控件，但设备连接封装、Agent 指令结构、任务提示词和测试用例的组合方式，通常能够通过代码差异和提交历史进行比对。若逐字一致的范围足够大，解释为独立实现就会变得困难。

谷歌在争议出现后，已经在代码中补充说明：“本项目包含由 Minitap 公司开发的源代码。”这一步说明谷歌至少承认相关代码来源需要被标注，但它能否彻底解决问题，还要看补充内容是否同时保留了版权声明、许可证文本、修改说明和完整的作者信息。单独写一句来源说明，未必等同于完成 Apache 2.0 的全部合规要求。

Artemis 到底是什么：让 Agent 直接操作 Android

移动自动化 Agent 是能够理解自然语言任务、观察手机界面并自主执行点击、输入和跨应用操作的软件智能体。 它与传统测试框架的区别，在于后者通常依赖固定脚本、控件 ID、XPath 或坐标，而 Agent 需要根据当前页面状态动态决定下一步动作。

Artemis 的定位不是简单的录制回放工具。根据其 GitHub 项目说明，它可以连接开启 USB 调试的 Android 真机或模拟器，在 macOS、Linux 和 Windows 上运行，并通过模型完成从理解任务到执行操作的闭环。使用者可以提出类似“在 Google Maps 设置驾车路线并计算总时长，然后打开 YouTube 播放一首歌曲”的跨应用任务，系统负责拆分步骤、识别界面、执行动作并检查结果。

这类系统的技术链路通常包含四个部分：设备连接层负责通过 ADB 或模拟器接口发送指令；感知层从截图、界面层级和设备状态中提取信息；规划层将自然语言目标拆成一系列动作；执行与验证层则负责点击、输入、返回、重试，并判断任务是否完成。只要其中一个环节不稳定，最终的“完成率”就会显著下降。

Artemis 还提供 Flash 和 Pro 两种执行模式。公开资料显示，Flash 模式强调速度，适合高频回归和简单任务；Pro 模式则更偏向复杂流程，希望通过更充分的推理提高长任务成功率。项目同时支持 Gemini、Claude、GPT-4o 和 Qwen-VL 等多模态模型，并提供 MCP 集成，让开发者能够从支持 MCP 的开发工具中调用移动设备任务。

不过，不能把这些能力简单理解成“AI 已经学会使用任何手机”。移动 Agent 面对的是一个持续变化的开放环境：弹窗可能突然出现，网络状态可能改变，应用版本会更新，按钮文字会因为语言和地区不同而变化，登录、验证码和权限授权也会打断流程。一个在演示视频里成功的任务，和在数百台不同品牌、不同 Android 版本设备上稳定成功，是两件完全不同的事。

99%+ 完成率背后，基准测试争议更敏感

AndroidWorld 是用于评估 Android Agent 任务执行能力的基准测试集合，测试重点是智能体能否在真实或模拟 Android 环境中完成多步任务。 Artemis 相关资料宣称其基准任务完成率达到 99% 以上，这一数字足以让它在移动自动化领域获得关注，但也让评测的可复现性和治理方式变得重要。

Minitap 表示，自己长期要求更新 AndroidWorld 排行榜上已经过时的基准成绩，却迟迟没有得到处理；与此同时，Artemis 在 8 月更新成绩后位列第二。更敏感的是，AndroidWorld 本身由谷歌维护。

这并不能直接证明 Artemis 的成绩不可信。一个由项目维护方运营的基准测试，并不天然等于不公平；关键要看任务集合是否公开、设备和模型配置是否一致、成绩是否由第三方复核、失败案例是否披露，以及排行榜是否有明确的提交和申诉规则。但当同一家公司既维护基准，又提交参测系统，同时还被指控与竞争项目存在代码归属争议时，外界要求更高透明度是合理的。

| 对比维度 | Artemis | Minitap mobile-use | 对开发者的意义 | |---|---|---|---| | 项目定位 | 谷歌开源的 Android AI Agent 与自动化框架 | 可用自然语言控制真实 Android 设备的开源项目 | 前者更强调生态整合，后者是争议代码的来源项目 | | 许可证 | Apache 2.0 | 参考资料显示相关代码采用 Apache 2.0 | 都允许修改和再发布，但必须履行归属与通知义务 | | 操作范围 | 支持跨应用、多步骤任务和测试流程 | 覆盖设备连接、Agent 指令及消息任务等移动操作 | 都明显超出固定脚本自动化 | | 模型支持 | 支持 Gemini、Claude、GPT-4o、Qwen-VL 等多模态模型 | 早期项目重点在移动操作基础能力 | 模型替换能力影响成本、速度和任务成功率 | | 运行环境 | macOS、Linux、Windows，加 Android 真机或模拟器 | 面向真实 Android 设备控制 | 开发者可以在本地搭建实验环境 | | 公开成绩 | 相关资料称完成率超过 99%，并曾位列 AndroidWorld 第二 | Minitap 认为自己的过时成绩未被及时更新 | 排行榜需要披露版本、配置和复现条件 |

对开发者来说，99% 不是一个可以脱离测试条件单独比较的数字。任务数量、任务难度、是否允许重试、模型版本、设备状态和数据泄漏风险，都会改变结果。若测试集被公开，模型或 Agent 可能在训练或调优过程中间接见过任务；若只公布总分而不公布逐任务结果，外部用户也无法判断系统到底是“多数任务稳定完成”，还是“简单任务几乎全过、少数复杂任务完全失败”。

Minitap 的指控会如何影响开源 AI

代码归属争议是开源 AI 生态的信任问题，因为模型、提示词、测试集和工程实现都可能成为被复用的知识资产。 过去，开源合规讨论更多围绕代码库和许可证展开；现在的 Agent 项目则把边界扩展到了提示词、评测脚本、轨迹数据、工具调用协议和任务设计。

Minitap 指控的范围同时包括代码、提示词和测试用例，这意味着未来的争议不会只靠搜索几段相同代码来解决。提示词是否达到版权保护所需的独创性，测试用例是功能事实还是具有创作性的编排，Agent 轨迹是否属于可复用的数据资产，都需要结合具体内容和适用法律判断。许可证能明确授予的通常是代码相关权利，但不一定自动覆盖所有配套材料。

这也是大公司参与开源后最容易被忽略的地方：工程团队往往从多个仓库、论文、内部原型和社区项目中吸收思路，最后汇总成一个看起来全新的产品。如果依赖关系没有被系统记录，发布前的许可证扫描只检查文件头，或者项目在重构时删除了原始作者信息，技术团队可能认为只是整理代码，社区作者却会认为自己的贡献被抹去了。

从行业角度看，谷歌补充署名是必要但不充分的回应。更有说服力的处理方式应该包括：公开涉事文件的提交历史和变更范围；说明哪些代码、提示词和测试用例来自 Minitap；补充完整的版权、许可证和修改通知；解释 8 月强制推送替换作者信息的原因；对 AndroidWorld 排名进行独立复核，并提供可复现的评测配置。

如果最终证实存在许可证义务遗漏，修复并不只是把一句致谢放进 README。受影响的源文件、发布包、NOTICE 文件、第三方依赖清单和历史版本都可能需要检查。对于下游开发者而言，这些信息直接关系到他们能否放心把 Artemis 集成进测试流水线，或者将其打包到自己的产品中。

开发者现在该关注什么

使用 Apache 2.0 项目时，开发者最稳妥的做法是保留许可证、版权声明、NOTICE 文件和修改记录。 不要因为仓库首页写着“开源”就直接复制代码，更不要只保存一份当前 README。依赖项目应固定版本，记录提交哈希，并在发布物中保留第三方声明。

对于 Artemis 或其他移动 Agent，建议重点检查以下事项：

1. 确认代码来源。 查看仓库中的 LICENSE、NOTICE、版权头和第三方依赖清单，确认每个子目录是否有单独许可证。
2. 固定版本和配置。 记录 Agent 版本、模型版本、系统版本、设备型号、测试任务集合和重试策略，避免只记一个总完成率。
3. 区分演示与生产。 涉及支付、账号设置、隐私数据和消息发送的任务，必须加入人工确认、操作回滚和敏感动作拦截。
4. 验证失败模式。 不仅要看任务是否成功，还要记录错误点击、重复操作、误发消息、权限误授予和无法恢复的状态。
5. 保留贡献链路。 如果基于上游项目修改代码，应在内部文档和发布说明中标明来源、修改内容和对应提交。

移动 Agent 的价值确实很高。它有机会把传统的“写脚本—维护控件—处理版本差异”改成“描述目标—让系统观察—动态完成任务”，尤其适合回归测试、Bug 复现和跨应用流程验证。但它的工程难点也比普通聊天机器人更现实：一次错误点击可能造成真实数据损失，一次错误授权可能形成安全事件，一次不透明的评测则可能误导整个开发团队。

结论：Artemis 的技术方向值得肯定，合规透明度必须同步升级

Artemis 的技术方向有实际价值，但它能否成为可信的基础设施，取决于代码归属和评测透明度，而不只是演示效果。 谷歌把多模态模型、Android 设备控制、MCP 和自然语言任务编排放进一个开源项目，降低了移动自动化的试用门槛；对开发者来说，这比又一个只会生成测试脚本的工具更有想象空间。

但 Minitap 的指控击中了开源 AI 的薄弱环节：大模型和 Agent 项目越来越依赖社区代码、公开数据和共享评测，而行业的署名机制、贡献追踪和基准治理还没有跟上。如果代码确实逐字复用，初始版本又未完整保留作者信息，那么后续补充说明只能修复一部分问题，无法消除社区对发布流程和项目治理的疑问。

接下来最值得观察的，不是 Artemis 是否继续增加模型支持或跨平台能力，而是谷歌是否公开更完整的代码比对、版本历史和评测解释，Minitap 是否提出新的证据，以及 AndroidWorld 是否引入独立审核机制。对于移动自动化 Agent 来说，真正的竞争力不仅是把手机操作成功率做到 99%，还包括让别人能够知道这个数字怎么来的、代码从哪里来，以及在出现问题时谁应该负责。

参考来源

• IT之家：开源 AI 移动自动化项目 Minitap 指控谷歌盗用自家代码——介绍 Minitap 对 Artemis 代码、提示词、测试用例及署名问题的指控，以及谷歌补充来源说明的回应。
• Google Artemis GitHub 中文说明——项目官方文档，包含运行环境、MCP 集成、工具能力和开源许可证等信息。
• 知乎：谷歌 Agent 首次发现真实世界代码漏洞——补充观察 AI Agent 在真实软件工程和代码安全场景中的发展背景。