Google Jules 結束服務：11 月 11 日轉唯讀，工作脈絡要自己帶走

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Google 於 10 月 29 日在 Jules 官方更新紀錄 公告，非同步編碼代理 Jules 將在 12 月 31 日結束服務。退場分兩段：11 月 11 日前，使用者還能繼續完成進行中的工作階段（session）；11 月 11 日之後，整個服務轉為唯讀，只能看、不能再交付新任務，直到年底服務終止。

Pin

這次退場真正會消失的東西，需要先畫清楚一條分界線。程式碼、分支與 pull request 原本就存在 GitHub，官方明言會留在原處；會跟著服務消失的，是只存在 Jules 裡的工作脈絡，包括環境變數、代理累積的記憶、排程任務、每場工作階段的提示、計畫、完整活動紀錄，以及程式修補檔。這些東西描述的是「為什麼這樣改、測試到哪裡」，接手的人少了它們，就只能從最後一份 diff 反向考古。

官方同步給了一條匯出路：安裝 Jules 命令列工具、登入，再把一段官方寫好的匯出提示交給 Claude Code 這類命令列編碼代理執行。對還在用 Jules 的人，接下來的動作可以濃縮成一句話：11 月 11 日前把能收尾的任務收完，然後儘早把資料匯出，別把匯出壓到 12 月底。

11 月 11 日和 12 月 31 日，分別管住什麼？

這兩個日期容易被簡化成「年底收攤」，但它們管的事情不同，混在一起談會排錯優先順序。

11 月 11 日管的是「還能不能做事」。官方原文寫得明確：使用者可以繼續完成工作階段到 11 月 11 日，之後 Jules 轉為唯讀直到年底。唯讀之後，正在等代理修改程式、跑測試或處理審查意見的工作都會停在原地，所以等待中的任務要在這之前收尾，別想著年底前還有機會補跑。

12 月 31 日管的是「服務還在不在」。服務終止後，唯讀入口也會跟著消失，官方匯出工具依賴的帳號資料與介面同步退場。換句話說，匯出的死線其實跟著服務走，排在 12 月中旬以後都算壓線。

還有一個容易被忽略的細節：公告只給了日期，沒有給時區與切換時刻。對排程敏感的團隊，不適合把最後一個任務壓在 11 月 11 日當天的尾端，若最後一次測試失敗，還要留時間讓代理修正與重跑，才不會遇到服務已轉唯讀、工作卻還沒收完的窘境。

先交代一下 Jules 是做什麼的，方便判斷自己受影響的程度。Jules 是 Google 在 2025 年 5 月推出的非同步編碼代理：使用者指定 GitHub 儲存庫與分支，用一段提示或 GitHub issue 上的標籤指派任務，代理把專案抓到雲端虛擬機、擬出修改計畫、實際改程式，最後交付 diff 或直接開 pull request。修 bug、補測試、升級依賴這類沒人想碰的雜活，就是它的定位。它的任務在背景執行，不佔使用者的機器，這也是「非同步」的含義：你交辦之後可以離開，回來看結果與完整的過程紀錄。

從產品脈絡看，這次退場有跡可循。Jules 上線時，官方就把它定位成了解非同步編碼代理的實驗；這次公告也重申，使用者在 Jules 上做出的東西，教會了 Google 代理開發的方向，這些學習正在塑造 Google 的各項產品，包括代理優先平台 Google Antigravity。另一個訊號是更新節奏：官方更新紀錄的上一則產品更新，停在 3 月 9 日的 Gemini 3.1 Pro 上線（Gemini 模型家族後續的迭代動態，可以參考 Gemini 4 Carbon 的發表），之後七個多月沒有新條目，直到 10 月 29 日這則退場公告。

程式都在 GitHub，還有什麼非匯出不可？

GitHub 保存的是成果，Jules 保存的是脈絡，兩邊用途不同，不能用「程式還在」安慰自己資料都安全。

官方對匯出範圍的定義是：帳號設定、環境變數、排程任務、連接的儲存庫、代理記憶、初始化腳本，以及每一場工作階段的提示、計畫、完整活動紀錄與程式修補檔。對照一下就能看出缺口的形狀：一份修改的 diff 可能已經在 GitHub，但當時安裝環境用的設定、代理為什麼選這個做法、哪一項測試還沒通過，只存在 Jules 的工作階段裡。接手的人拿得到「改了什麼」，卻拿不到「為什麼改」與「驗證到哪裡」。

匯出結果會落在使用者家目錄的 ~/jules-export，帳號設定、環境變數與排程任務會以 JSON 檔放在最上層，sources.json 列出連接的儲存庫；每個儲存庫一個資料夾，放初始化腳本、測試命令與記憶；每場工作階段也各有獨立資料夾，裡面有可以直接閱讀的 summary.md、完整活動紀錄，以及 diff 修補檔。這個分層設計很實用：先用摘要判斷這是哪件工作，真的需要細節再回頭翻活動紀錄，不必逐檔打開考古。

其中記憶與環境變數是最不能等的兩類。環境變數裡常有資料庫連線字串或 API 金鑰，少了它們，接手的工具連環境都跑不起來；記憶則記錄代理對這個專案學到的事，服務關閉後就無法重建。這兩類東西也決定了匯出結果的敏感度，後面地雷段會再回到這一點。

官方匯出怎麼跑：一段交給命令列代理的提示

匯出流程本身不複雜，但官方選擇的實作方式值得停下來看一眼，因為它影響匯出時效的長短。

先安裝官方命令列工具並登入：用 npm install -g @google/jules 裝好 Jules Tools，再執行 jules login。登入是互動式瀏覽器流程，官方的匯出提示明確要求代理「不要代我執行登入，等我說完成再繼續」，原因是這一步需要本人在瀏覽器完成 Google 帳號驗證。

Pin

接著從家目錄打開一個命令列編碼代理，官方點名的例子是 Claude Code，把官方更新紀錄裡那段匯出提示貼給它。代理會先做幾件檢查：確認 jules 指令裝好了、確認登入狀態存在（它只查鑰匙圈項目的 metadata，不碰權杖內容）；環境沒問題，才把官方隨公告提供的 Python 匯出腳本存檔執行，最後回報匯出了幾個儲存庫、幾場工作階段、幾份修補檔，以及輸出資料夾的完整路徑。若 npm 根本沒裝，提示也交代了直接停下來告訴使用者，不自行換做法。

第三件事最容易漏看：Jules 的命令列文件裡並沒有 jules export 這樣的專用指令。官方選擇的退場工具，是一段給代理讀的提示，加上一支直接呼叫內部介面的腳本。腳本會自己從 macOS 鑰匙圈（服務名稱 jules-cli）或 Linux 的 secret-tool 取出登入憑證裡的存取權杖，然後呼叫 Jules 背後的端點抓資料。官方也明說，這些端點並未文件化。這代表匯出工具的壽命跟著端點走，端點在服務退場前若變動，匯出就會失效，這是把匯出排程提前、不要拖到 12 月的最實際理由。

哪些地雷官方已經先講了？

這次公告難得地坦白，官方直接條列了「別人已經踩過的問題」，照著讀一遍可以省掉多數試誤。

GitHub 帳號要先連好。匯出裡的儲存庫資料，前提是 Jules 帳號已連接 GitHub。官方給了檢查方式：執行 jules remote list --repo，如果回 401 並提示 GitHub 問題，就到 GitHub App 安裝頁把 google-labs-jules 連上。如果從沒用 Jules 接過 GitHub 專案，可以跳過這一步，代價是匯出結果裡不會有儲存庫資料。

存取權杖的壽命只有一小時左右。官方說明權杖在登入後約一小時過期，如果所有呼叫都回 401，重新執行一次 jules login 就好；反過來，如果只有儲存庫清單回 401、其他呼叫都正常，問題通常是 GitHub 沒連接，而不是登入過期，兩種情況的解法不同。

遇到 400 或 404，先弄清楚是哪個呼叫失敗。設定、環境變數、儲存庫與記憶走內部端點，工作階段走 REST 端點，兩者都未文件化，官方的建議是指出失敗的是哪一個呼叫，別自行猜測解法重試。另外儲存庫清單本身不含初始化腳本與測試命令，腳本會從每場工作階段的輸出把它們還原出來；記憶回應是空的 {}，只表示這個專案沒有記憶，不是匯出故障。

數字對不上不一定是出錯。介面回傳的工作階段數量，可能比 jules remote list --session 列出的多，因為較舊的工作階段只在介面裡看得到；官方明說這是預期行為，不是資料重複。

env-variables.json 內含環境變數的實際值。官方明確提醒：匯出資料夾要保持私密，不要放進任何儲存庫。這一條要嚴肅看待，把整包匯出 commit 進版本庫，等於把金鑰寫進提交歷史，事後清除的成本遠高於一開始就放對位置。

驗收也有官方依據：看腳本最後印出的計數與錯誤清單（儲存庫數、工作階段數、修補檔數、錯誤數），再抽查幾件自己知道的重要工作，確認摘要與修補檔都如預期出現。目錄存在只證明腳本跑完，不證明每類資料都帶到了。

Antigravity、訂閱方案與其他沒被回答的問題

官方對去向只給了一句話：Jules 的學習正在塑造 Google 的各項產品，包括代理優先平台 Google Antigravity。這句話看得出方向，但公告沒有給功能對照表，沒有說 Antigravity 會匯入 Jules 的資料，也沒有提到訂閱怎麼處理。比較穩的讀法是把 Antigravity 當成 Google 代理開發的下一站，先別視為 Jules 的自動搬家目的地；資料要不要過去、怎麼過去，要等後續文件才算數。

訂閱這塊目前是空窗。Jules 官方方案頁列出的架構是：一個免費層，加上隨 Google AI Pro 與 Google AI Ultra 訂閱附帶的 Jules in Pro、Jules in Ultra 兩個較高層級。退場公告對這些付費權益隻字未提，而到 10 月 31 日為止，方案頁與 FAQ 頁都沒有出現退場說明，方案頁仍照常行銷各層級，首頁也還掛著試用入口。換句話說，付費用戶接下來要自己盯 Google AI 訂閱端的後續公告，別等 Jules 頁面更新。

還有幾個未確認事項，引用任何細節前要先知道：切換時刻沒有給時區；匯出依賴的未文件化端點在 12 月 31 日前是否持續可用，官方沒有承諾；npm 上 @google/jules 的最新版本 0.1.42 停在 2025 年 12 月 16 日發布，之後沒有改版，這與匯出的設計相吻合：匯出不倚賴命令列工具改版，而是由腳本直接呼叫端點。

接到下一個代理前，先把匯出內容判讀過一次

匯出完成只是把原料搬出來，能不能用，取決於判讀。有幾個地方值得在交接前逐項看過。

記憶要分類，不要照單全收。Jules 的記憶是代理對專案學到的事實，有些是穩定的專案慣例，有些只對應當時的某一次問題。全部當成新工具必須永久遵守的規則，可能把已經過時的習慣一起搬過去；比較穩的做法是逐條讀過，判斷它是慣例還是一次性脈絡，再決定要不要寫進新環境。

修補檔要核對現況。匯出裡的 diff 是某場工作階段當下的修改快照，GitHub 上的分支可能已經往前走，直接把舊修補檔重新套用，可能把已經完成的修改再做一次。初始化腳本與測試命令同樣有時間性，它們是從工作階段輸出還原的最後看到的樣子，專案若換過安裝方式，要對著最近的分支再確認一次。

交接說明自己寫一份，比整包匯出更可用。接手的工作項目最好同時說清楚目標、觸發方式、預期結果、已修改的檔案與測試命令；敏感的環境變數只留名稱與用途，值另外走安全管道。怎麼把代理說明文件寫得讓下一個代理讀得懂，Google 自己有一套建議結構，把說明拆成 AGENTS、DESIGN、SKILL 三份，在交接階段正好借用。

排程任務要逐項確認。匯出保存的是原本幾點做什麼的設定，不代表新工具會代為建立；服務入口、執行權限與通知方式換了環境都得重接，照抄舊排程之前先問一句這件事還需不需要存在。

收尾的順序建議是：把手上任務分成已交付、執行中、還沒開始三類，已交付的確認 pull request 狀態，執行中的在 11 月 11 日前收掉，還沒開始的直接換工具做。匯出排在收尾之後、但不晚於 11 月中旬，跑完核對計數與錯誤清單，再挑一件範圍小、成果明確的工作在新環境重現一次，確認接手成立，才把更大的維護工作交出去。挑下一個編碼代理時，除了功能，token 消耗與帳單成本也值得先算清楚，這類評估方法可以參考我們先前對 Particle-1 編碼代理模型 的分析。