GitSwarm 是什麼？Meta 用共享 Git 記憶讓 AI 代理接力，團隊如何借用這套方法

GitSwarm 探討一個很實際的問題：多個 AI 代理一起寫程式，怎麼讓其中一個留下的進度，真的被其他代理接著使用？

同時開數個代理時，可能遇到回答彼此重複，檔案相互覆蓋，最後仍由人重建工作脈絡。

Meta 研究人員的 GitSwarm 論文，把共享的 Git 版本紀錄當成持續存在的工作記憶，讓不同工作者從其他人的成果繼續往前。

這篇研究在 X 被討論，但它呈現的是特定實驗設計。成績可以幫助理解方法，不能直接當成任何團隊的保證。

我認為值得借用的，是把進度儲存成能檢查、能接手的改動。代理數量增加之前，先讓每一份成果能獨立被理解。

要讓接力成為可用的工作方式，先看版本紀錄如何保存一份能被檢查的成果。

GitSwarm 為什麼用 Git 當共享記憶？

Git 是記錄檔案版本與改動歷史的工具。它讓你知道改了哪些內容、改動從哪一版開始，也能保留不同方向的工作分支。

如果代理只在聊天裡說「已經完成」，後來接手的人可能找不到檔案、測試方法或失敗原因。對話一旦變長，重要線索也容易被埋掉。

把成果寫進版本紀錄後，其他代理可以看見具體變更。它不必只相信上一位代理的描述，而能讀取實際檔案並重新檢查。

研究所談的記憶，因此不只是儲存一段摘要。它也包含程式、測試、部分成果，以及不同改動之間的關係。

這種儲存方式的好處，是工作者失敗或停止後，已留下的內容仍然存在。下一位可以從可用部分接續，而不必重新猜整段工作怎麼開始。

研究中的工作者如何協作？

GitSwarm 論文 描述的是非同步協作。非同步意思是不同工作者依自己的進度工作，不必每一步都等待其他人。

研究採用同質工作者，也就是具備相似能力與工具的代理。它並非只靠一個中央規劃者，把所有細節分配給不同角色。

工作者會讀取共享紀錄，決定接續哪個有用成果，再產生新的改動。其他工作者能看見這些紀錄，也能選擇採用或繼續修改。

原子提交是這裡的重要概念。它指每次儲存一個相對完整的改動單位，讓接手者能理解這次改動解決了什麼問題。

例如新增一個計算函式與對應測試，可以是一個完整單位。只留下半段程式又沒有說明，其他工作者就難以判斷是否能接著用。

研究也關注不同提交之間的語意依賴，也就是某個成果在功能上需要前面的成果。這比只看檔案時間更接近真正的工作關係。

若測試必須使用上一個提交新增的函式，就應保留這個關係。接手者才知道不能只拿測試檔，卻漏掉它依賴的實作。

論文的成績，應該怎麼讀？

論文在 ProgramBench 的指定預算設定下，報告平均表現為 79.4%，相較所比較的強基準方法為 65.1%。這是同一研究脈絡中的比較。

要理解這組數字，還要一起看模型、工具、工作時間與評分方式。它不能換成「所有程式工作都提升相同比例」。

另一組 IMOProofBench-Advanced 數學證明測試使用 GPT-5.5，一次完成三十題，與 ProgramBench 是不同測試。它說明該次方法的能力，並不能保證換一批題目仍然完全成功。

研究報告成果被其他工作者重用的比例，目的在觀察是否真的出現協作。重用多，仍不等於每份成果正確，也不等於總成本一定較低。

對團隊而言，最有用的問題是自己的工作是否有可接續的小成果。若任務依賴大量默契或不可共享資料，就需要先整理這些前提。

因此先看方法如何儲存進度，再看數字有多漂亮。能否在自己的條件下獲益，最後要靠範圍明確的練習判斷。

小型團隊可以借用的三步工作流程

第一次練習可以選一項不會直接改動正式服務的小任務，例如為既有工具增加資料檢查。先準備一個獨立副本，保留原本可用的版本。

本文的流程借用共享版本記憶的概念，並沒有宣稱它就是 GitSwarm 的完整實作。小團隊仍可以由人指定範圍，先降低互相干擾。

第一步是定義共同完成標準。所有工作者都要知道輸入資料、預期輸出與不得改動的部分，避免各自做出不同理解。

例如新增檢查日期的功能，可以寫明只標示不合法日期，不能自動修正原資料。這個界線會影響實作與測試，也應寫進交接說明。

第二步是分出可以獨立檢查的改動。先處理讀取資料，再加入檢查規則，最後整理錯誤提示，比一次改完整個工具更容易接手。

第三步是讓每次儲存都帶上證據。證據可以是測試命令、結果與已知限制，讓後來者知道這份成果在哪些條件下成立。

提交說明，怎麼寫才有接力價值？

好的說明先寫具體改動，再寫檢查結果。例如「新增空日期檢查，保留原列編號。已確認三個樣本，尚未測試時區格式」。

這段話讓接手者知道功能、資料保護與剩餘工作。相較之下，「最佳化資料處理」無法說明哪些問題已解決。

可以採用以下交接表，但不必每次填成很長的報告。目的是讓另一個人能依同一份資料重現結果。

如果代理沒有完成，也應儲存已確認的部分。停止本身不是問題，沒有留下能辨識的狀態，才會讓下一位從頭來過。

但不要為了儲存進度，把秘密金鑰、真實客戶資料或個人對話放進共享版本。這些資訊不會因為改成檔案就適合被所有工作者讀取。

多個代理同時修改，怎麼處理衝突？

分支可以讓不同方向各自保留，但它不會自動判斷功能誰對誰錯。合併前仍要檢查各自的改動是否符合共同標準。

兩個代理修改同一個函式時，可能出現文字衝突，也可能沒有文字衝突卻有邏輯衝突。後者更需要測試才能發現。

例如一個代理把日期缺漏視為錯誤，另一個代理把缺漏換成今天日期，檔案或許能合併，規則卻已不一致。

此時應先回到共同完成標準，確認哪個行為得到授權。不要讓最後寫入的人，自動成為業務規則的決定者。

保留衝突前的版本，也能讓你比較兩個方案。回復應以可辨識的版本為依據，避免靠記憶重新拼出「應該可以用」的程式。

新手若還不熟悉 Git，可以先看 官方版本控制說明，從儲存與比較改動開始，不必第一天就操作複雜合併。

如何判斷共享記憶真的有幫助？

最簡單的觀察是接手時間。請一位沒有參與的人，依照提交與說明找到可用成果，記錄他需要追問幾次才知道下一步。

再看重複工作。若不同代理都重寫同一段功能，可能是共享紀錄不好找，也可能是成果缺少可採用的證據。

第三個觀察是返工原因。分類記錄規則不清、版本過舊與程式錯誤，能幫你判斷是工作流程需要調整，還是工具本身不適合。

最後算總時間。代理執行時間之外，也要加上人讀紀錄、處理衝突與驗收的時間，才能比較協作是否真的減輕負擔。

若接手更快，但合併與檢查成本大幅增加，可以先減少同時工作的數量。共享記憶的目的，是保留有用進度，代理越多並不必然越好。

怎麼設計一個小範圍練習？

選一份二十列的公開示範資料，先由人列出空白、重複與格式錯誤的預期結果，再把這份答案當成驗收基準。

第一位代理寫讀取與檢查，第二位讀取版本紀錄並補例外測試，第三位只檢查交付物。這是便於觀察的分工，不是論文中的固定角色。

在每一輪結束時，要求工作者指出採用了誰的哪個成果。若說明與實際檔案不符，就先修正交接，再擴大任務。

練習結束後保留成功版本與失敗原因。下一次換資料，便能檢查改善是否重現，而不是只依一次順利合作下結論。

接手演練：代理停止後，另一位能從哪裡開始？

假設第一位工作者完成讀檔與空白值檢查，卻沒有完成重複資料處理。接手者先讀提交說明，再開啟實際檔案確認已儲存的部分。

他應能找到讀檔方法、樣本與檢查命令。若只看到一段「已完成一半」，就需要補交接資料，不能直接猜剩餘邏輯。

接著重新執行已列出的檢查。成功結果能支援繼續使用。失敗則先確認環境與版本，避免在有問題的基礎上疊加新功能。

重複資料的規則如果尚未決定，接手者就提出需要人選擇的地方。例如相同名字不同日期，應保留兩筆還是合併，不能由程式隨意決定。

規則確認後，只新增這一類檢查，再儲存獨立提交。如此下一位既能採用原本讀檔成果，也能看懂新加入的部分。

若新功能造成空白值檢查失敗，就比較改動與先前版本。接力過程中保留的證據，此時能幫助你找到原本成立的條件。

最後請一位未參與的人，從資料與紀錄重現結果。這次演練成功，才表示交接方式對人可用，還不能保證所有代理都會同樣遵守。

什麼成果不適合立刻放進共享主線？

只有猜測原因、沒有可重現結果的改動，應先留在研究或工作分支。它可能有價值，但不能和已確認成果混在一起。

測試依賴私人環境的功能，也要先說明限制。如果只有某臺電腦的未記錄設定才能執行，其他工作者很難真正接續。

同樣地，會改變共同規則的改動，應先得到明確決定。共享記憶儲存成果，不應讓未討論的選擇悄悄成為團隊標準。

先讓主線保持可用，把未完成與待決定部分清楚區分。這能降低接手成本，也讓代理失敗時不會拖累其他工作。

GitSwarm 常見問題

可以直接下載 GitSwarm 套件使用嗎？

本文查核的是論文方法，沒有確認一套能直接重現全部實驗的官方安裝產品。不要把研究名稱當成現成服務，應先讀作者提供的實作資訊。

共享 Git 是否等於代理完全不會忘記？

版本紀錄能保留成果，但工作者仍可能沒有讀到、理解錯誤或採用過時內容。清楚的檔案與交接規則，仍是成果能被使用的前提。

沒有很多代理，這個方法還有用嗎？

即使只有一位代理與一位人類，儲存改動、檢查結果與剩餘問題，也能改善接手。先讓兩位參與者交接順利，再考慮增加數量。

先儲存可用進度，再擴大協作

GitSwarm 讓人重新注意到，代理協作的難點往往在接力。能被看見、被檢查與被採用的成果，才有機會累積成團隊能力。

先用一個小任務建立共同標準與提交說明，請另一位參與者實際接手。把接手時間與返工原因記下來，再決定是否擴大同時工作的範圍。

延伸閱讀：Claude 動態工作流程開放測試：多個代理分工，為何仍需要總預算？

延伸閱讀：Foldkit 讓 AI 前端程式有固定結構：把狀態、事件與副作用分開

資料來源

產品資訊依 第一手來源 與 官方補充文件 整理，功能與條款查核日期為 2026 年 10 月 12 日。

討論線索來自 X 原始貼文。本文操作案例是供讀者採用的練習流程，未宣稱已替讀者完成產品實測。