他們在 Google ARTEMIS 裡發現自己的程式碼——還有一個抹掉他們名字的 Force-Push

定調這整起事件的那句話，不是出自 Google 工程師之手，而是來自巴黎行動代理人新創 Minitap 的執行長 Nicolas Dehandschoewercker。他在 2026 年 9 月 11 日發布的部落格文章中寫道：「我們打開 Google 的 Artemis 儲存庫，認出了自己為 mobile-use 寫的程式碼。接著我們在版本歷史裡找到了自己的名字——以及把這些名字移掉的那次提交。」

Google 在本月稍早開源了 ARTEMIS，一個能將自然語言指令轉化為可靠 Android 自動化操作的框架。它可與 Antigravity、Codex、Claude Code 等 AI 編程助手整合，並宣稱在 AndroidWorld 基準測試上達到 99% 以上的成功率。這個由 Pixel 測試工程團隊打造、發布在 google GitHub 組織下的儲存庫，幾天內就累積了 3,400 顆星並獲得一片好評。然後，Minitap 的工程師打開了它，用他們執行長的話說：「搞什麼？這是我們寫的。」

Minitap 說他們發現了什麼

Minitap 將 mobile-use 作為開源研究實驗來打造——目的是讓 AI 代理人能可靠地與手機互動——並以 Apache 2.0 授權釋出。團隊一路做到 2026 年 2 月，之後將重心轉向更新的閉源版本，也就是如今驅動其商業產品的核心。公開儲存庫則如開源慣例般留在網路上。

根據 Minitap 的文章，ARTEMIS 與 mobile-use 的重疋既非泛泛也非巧合，而是具體到近乎逐字：

• 裝置連線程式碼。 連接 Android 裝置的部分程式碼「與我們的實作完全一致」。
• Hopper 代理人的提示詞。 這個代理人的系統指令「一字不差」。順帶一提，Hopper 這名字出自《當個創世神》——工程師 Jean-Pierre Lo 覺得這名字很酷。看到同樣的名字搭配同樣的指令出現在 Google 的儲存庫裡，「感覺非常熟悉」。
• Alice/Bob/Charlie 範例。 一個讓代理人停留在 WhatsApp 內的示範任務，有一樣的目標——向 Alice、Bob 和 Charlie 傳新年快樂訊息——連註解和清理步驟都相同。
• 同一個 bug。 兩個專案的舊版本都有一個會先寫出結果檔案、下一次執行時卻讀不回自己輸出而失敗的輔助函式。Minitap 說他們在兩個實作中重現了同樣的故障。ARTEMIS 後來修掉了它。

最嚴重的指控則關於作者身分。ARTEMIS 一個較早版本的套件檔案列出三個名字：Pierre-Louis Favreau、Jean-Pierre Lo 與 Nicolas Dehandschoewercker。取代它的版本將三個名字全部移除，換上另一位作者。檔案中唯一的變更就是作者名單。Minitap 表示，GitHub 的活動紀錄顯示這次替換是透過八月的一次 force-push 完成——早於他們九月的調查。而截至 9 月 11 日他們檢查時，README 並未提及 mobile-use。

為什麼授權條款重要

這是故事從「尷尬」升級到「後果嚴重」的轉折點。Apache 2.0 是全球使用最廣的開源授權之一，它刻意採取寬鬆立場——但寬鬆不等於免署名。授權條款第 4 條要求再散布者保留適用的版權與歸屬聲明，並標明對程式碼所做的變更。Minitap 的文章指出，做到這些有現成且通行的方法：fork 會連回原始專案、引入的副本可以註明來源、版權與歸屬聲明隨程式碼保留、README 可以說明哪些部分來自他處。

「不應該需要復原儲存庫的舊版本，才能發現這層關係，」文章如此主張。這個框架重要，因為它點出了歸屬失靈的真正成本。維護者早已在回答問題、審閱貢獻、維持專案運作上投入大量無償時間。當一家市值破兆的公司重新發布了他們的作品，而他們還得花好幾天重建 git 歷史來證明自己寫過什麼，「分享」就開始像一樁賠本生意。Dehandschoewercker 寫道：「一個把這種事變成常態的生態系，等於再給人們一個停止分享的理由。」

排行榜的另一條線

故事還有一條更安靜的支線：基準測試。Minitap 表示，他們花了數月想讓自家較新的 AndroidWorld 成績反映在公開排行榜上。維護者套用了他們較早的提交，成績到 91.4%，最後一次確認是 2025 年 12 月。之後 Minitap 提交了 94.8%，又在一月的評測中提交了 100%，並追加了兩封後續信件——四封電子郵件，全部石沉大海。截至 9 月 11 日，排行榜上 mobile-use 仍停在 91.4%，ARTEMIS 則顯示 99.1%。兩者都是自行回報；排行榜明言不做獨立驗證。

與此同時，ARTEMIS 自己的比較圖表完全省略了 mobile-use——卻列入了成績相同的 DroidRun，以及一個名字撞在一起的無關專案 MadeAgents「MobileUse」（成績較低）。Minitap 很謹慎地聲明，沒有證據將未回覆的郵件或圖表遺漏與移除名字一事連結起來。但整體看來，這幅圖像像是一家小公司掙扎著要讓公開紀錄反映自己的工作——程式碼上是，基準測試上也是。

Google 的往績是雙面刃

對 Minitap 來說最刺痛的是，Google 歷來在歸屬這件事上做得很好。這家公司給了世界 Kubernetes 和 TensorFlow。推出 Chrome 時，它明確感謝了 WebKit 與 Firefox：「我們受惠於許多開源專案。」Google 甚至公開了自己處理第三方程式碼的準則。「正因如此，我才期待更好，」文章寫道。

對生態系的好消息是，糾正機制看來正在發揮作用——儘管緩慢。在 Minitap 於 ARTEMIS 儲存庫提出公開 issue 之後，Google 開了一個恢復署名的 pull request，而這則故事衝上了 Hacker News 第三名，引發的正是歸屬規範賴以生存的那種公眾檢視。一份包含詳細比對、封存檔案與時間線的公開事實紀錄，可供任何人檢驗。Minitap 的訴求有三：承認 ARTEMIS 部分衍生自 mobile-use、為背後的人員署名、修正歸屬資訊。

還有一個重新框定整起事件的競爭力註腳：如今驅動 Minitap 產品的 mobile-use 版本已是閉源，用執行長的話說，「現在已經是完全不同的怪獸了」。他留給 Google 的最後一句話是：「你們晚了七個月。」

為什麼這件事不只是一個儲存庫的事

開源 AI 正處於一個尷尬的時刻。實驗室開放模型權重，卻對訓練資料與方法保密；會抓取、混搭、重新發布程式碼的代理人，如今已是開發流程的常態。在這種環境下，歸屬不是官僚式的挑剔——它是讓下一位維護者決定「公開發布到底值不值得」的機制。Apache 2.0 說你可以拿走程式碼，也說你必須交代它從哪裡來。

如果一家擁有 Google 工程紀律與開源血統的公司，都可能發布一個 README 省略直接上游依賴的儲存庫——同時上游作者眼睜睜看著自己的名字透過 force-push 從套件檔案裡消失——那麼對更小的維護者而言，教訓是灰暗的。制衡的力量是輿論：這則故事之所以傳開，是因為 Minitap 記錄了一切、封存了證據、公開了時間線。歸屬爭議過去若能解決，多半是悄悄解決；現在，它們是在 Hacker News 上、拿著收據解決的。

值得持續關注的，是那些尚未解答的問題。Pixel 測試工程團隊裡是誰決定替換作者名單？有沒有人審核？Google 會對排行榜提交做出實質回應，還是只處理程式碼歸屬？ARTEMIS 的 README 最終會不會變成 Apache 2.0 一直以來期望的樣子——讓原作者的名字回到屬於他們的位置？