GitHarness 是什麼？讓 AI 記住需求版本，改規格時不用整份重做

你請 AI 做一份報告，接著改了對象、刪了章節，又補上新的資料。AI 有時會把舊要求帶回來，有時則把已經完成的部分全部推倒重做。GitHarness 研究試圖解決這種多輪工作問題：把每一版需求與對應成果一起保存，收到新指令時，從仍然有效的狀態接著做。

這個想法近期在 X 被分享，因為它把大家熟悉的 Git 版本管理帶進 AI 代理記憶。Git 通常用來記錄程式修改，研究則把版本、分支與回到舊狀態的概念，用於持續變動的任務。重點是讓代理知道哪些要求已經過期、哪些工作還值得保留。

論文在多種模型、工作流程與任務的組合中比較表現，顯示版本化記憶有助於處理中途修改。這不表示任何聊天工具都已經具備相同能力，也不代表把對話存成檔案就能重現結果。本文會用報告與程式修改的例子，拆解 GitHarness 如何運作，以及實際導入時最需要確認的事情。

AI 為什麼會把已刪掉的要求寫回來？

一般對話把訊息按時間一路接下去，模型需要從整段內容理解目前任務。當要求很短，這種方式十分方便。當使用者反覆新增、撤回或替換條件，對話中就會同時存在多個版本，模型必須自行判斷哪一個仍然有效。

假設最初的要求是寫給工程師，後來改成給第一次接觸 AI 的家長。舊對話仍有很多技術細節，新要求則需要白話說明。如果代理只把所有訊息當作同樣重要的參考，它可能在結尾重新加入已經刪掉的專業段落。問題不只在記憶容量，也在缺少明確的版本關係。

另一種處理方式，是每次需求改變都從頭開始。這能降低舊內容混入的機會，卻會浪費仍然有效的研究、表格與程式修改。使用者只是改掉一個地區，代理卻重新查完所有資料，時間與工具費用都會增加，成果還可能引入新的差異。

GitHarness 想把這兩種代價一起處理：保留有效工作，也切開已經失效的部分。它需要的不只是「記得更多」，而是記得每一份成果當時是為了哪些要求建立的。這讓需求改變後的復用有依據，不能只看文字內容是否相似。

GitHarness 的核心：把需求與工作一起存成版本

依照原始研究，GitHarness 會保存任務要求與相對應的工作狀態，並在更新要求時選擇可延續的版本。這可以理解為替代理建立一段有分支的工作歷史，每一個節點都帶著當時的規格與成果。

commit 是 Git 裡的一次版本紀錄，branch 則是從某個狀態展開的新路線。研究借用這些概念，讓代理不必永遠從最後一則訊息形成的狀態繼續。若最新狀態包含已被撤回的要求，系統可以回到更合適的版本，再按新需求展開。

判斷「更合適」並不等於挑最早版本或文字最相似的版本。它需要檢查新需求與舊狀態在語意上是否相容，也就是舊成果是否仍符合目前條件。曾經完成的工作可以復用多少，取決於改動影響的範圍與狀態紀錄是否完整。

研究也包含用來處理版本選擇的 GitAgent，並透過強化學習改善相關決策。強化學習是依結果回饋調整行為的訓練方式。這裡的訓練與底下負責解題的模型分工，不能把它說成每一個接入的模型都被重新訓練過。

因此，GitHarness 與在提示詞加一句「請忽略舊要求」有本質上的實作差異。提示詞依然需要模型從長對話推理，版本機制則額外維護工作狀態與選擇程序。兩者可以配合，但單純照抄研究名稱，不會讓原本的聊天工具自動具備分支記憶。

用一份市場報告理解：哪些工作可以保留？

假設原本要整理台灣與日本市場，後來改成只研究台灣，並要求保留三年的趨勢表。這是本文的示意情境。有效的版本處理應保留台灣資料與趨勢表，移除日本分析，重新確認比較方式是否因國家減少而改變。

如果代理選擇了包含兩國比較結論的最新狀態，就需要辨識哪些段落依賴日本資料。若它回到只有台灣原始資料的較早版本，可能更容易避開過期結論，但也可能少了後來完成的表格。選擇版本的工作，就是在相容性與成果復用之間找出合理起點。

再假設你把時間改成最近一年，原本三年的表格就不能照搬。這時候保留表格格式可能有用，保留整份數據卻可能違反新要求。版本管理不能只把檔案視為完全可用或完全不可用，還要知道哪些成果受哪些條件影響。

使用者也可以讓這件事更容易：改需求時說清楚「撤回什麼、保留什麼、新增什麼」，比只說「換個方向」更容易判斷。這是一種一般工作溝通建議，不是保證任何工具都能完美處理。版本記錄提供結構，清楚的指令則提供判斷依據。

論文測試了什麼？不要把單一省成本案例當保證

研究建立 MTAgentBench，涵蓋數學、資料查詢、搜尋、程式與研究等多輪任務，並把不同代理工作流程與模型組合起來比較。多輪任務的重點是中途會收到需求更新，代理要在保留工作與遵守新條件之間做決定。

研究比較的工作流程包含 TCRAG、StackPlanner 與 OpenHands，模型則包含 Qwen3-32B 與 DeepSeek V4 Flash。把五類任務、三種流程與兩個模型組合起來，共有三十個測試設定。這些設定提供了比單一聊天示範更廣的觀察，但仍然是研究定義的環境。

token 是模型處理文字的計量單位，會影響部分服務的費用與處理時間。減少 token 有時代表少做無效推理，但不能直接等同於所有成本按相同比例下降。工具執行、檔案下載、外部查詢與版本儲存，可能另有時間和費用。

X 摘要中特別強調某一設定大幅降低程式任務的 token 用量。這類數字很適合引起注意，實際選工具時卻應回到自己的需求：你的變更通常是局部修改，還是整個目標重設？如果多數任務沒有可保留的狀態，版本復用的收益自然可能較小。

與長上下文、摘要記憶相比，有什麼不同？

長上下文指模型一次能處理較多內容，讓更多歷史訊息進入判斷。它能減少因資料放不下造成的遺漏，卻不會自動說明哪一版要求有效。把一百頁舊文件全部塞進模型，也可能同時塞進互相矛盾的規格。

摘要記憶會把長對話整理成較短紀錄，降低閱讀負擔。它的品質取決於摘要是否保留重要變更：如果撤回條件沒有被寫清楚，舊要求仍可能延續。版本化方式則試圖讓狀態與變更關係更明確，使系統有機會回到適當的起點。

這些方法不是互斥選項。版本紀錄也可能搭配摘要，讓每個狀態更容易閱讀。但不能因為有了版本結構，就省略原始資料與完成證據。對來源密集的研究任務，保存引用文件版本，仍然比只保留代理的一句結論可靠。

程式代理使用版本記憶，還要處理真實檔案

程式工作特別容易讓人把 GitHarness 與現有 Git 混為一談。現有 Git 能保存檔案差異與提交歷史，研究還要處理使用者要求、代理工作狀態與恢復決策。程式碼版本正確，不代表代理理解的需求版本也正確。

假設你要求先改登入頁，後來撤回設計，只保留錯誤修正。代理需要分清楚哪些改動屬於新介面，哪些是獨立修正。若它只是回到某次提交，可能同時丟掉有價值的修正。有效的復用需要建立需求與檔案變更的關係，再以實際測試確認保留下來的內容。

外部行動則更不能被當成可任意倒帶的對話狀態。寄出的郵件、更新的客戶資料或已付款的訂單，不會因為代理回到舊版本就自動撤回。導入時應分開記錄內部思考、檔案成果與對外操作，讓恢復狀態不會誤導系統重複執行已完成的行動。

對長時間工作的代理，還應保存環境資訊。資料來源、工具版本與權限都可能變，昨天相容的狀態未必適合今天的檔案。重新開始某個版本之前，確認輸入仍可讀、條件仍適用、操作沒有重複，是讓版本記憶真正服務工作的重要一步。

一般團隊如何評估，才不會只看漂亮示範？

可以先整理十幾個真實變更情境，例如刪除範圍、增加條件、替換資料、改成果格式與撤回前一步。每個案例保留最新有效規格，以及哪些舊成果可以合理復用。這些答案不一定能完全自動產生，初期由熟悉工作的成員標記比較容易建立可靠基準。

接著比較三種處理方式：直接延續、每次重做，以及具備版本選擇的流程。記錄最後是否符合要求、重用哪些成果、用多少時間，以及是否發生外部操作重複。只比較 token，可能選到最省文字卻最常做錯的方式。

最後，把復用錯誤與重做浪費分開看。沿用一份已過期資料，和多花幾分鐘重查資料，對不同工作可能有不同影響。企業應依任務的重要性決定取捨，不能假設所有工作都以少用 token 為最高目標。版本管理的價值，是讓取捨有證據可看。

常見問題：GitHarness 可以解決所有 AI 記憶問題嗎？

我只是在聊天，需要安裝版本系統嗎？

不一定。對短任務，清楚說明最新要求與撤回條件，通常比引入複雜系統更容易執行。當工作涉及大量檔案、多次改規格與長時間工具操作，版本化狀態才更值得評估。研究方法的價值，應和任務複雜度一起判斷。

有版本記憶，AI 就不會忘記重要資料嗎？

不會因此得到完全可靠的記憶。保存什麼、摘要如何建立、版本如何選擇，都可能出錯。更有效的做法是讓重要條件有清楚的來源與驗收方式，並在成果完成後再次核對。結構化記錄減少部分混亂，仍需要結果檢查。

它可以把已經執行的操作全部還原嗎？

研究中的狀態恢復不能直接等同於現實世界的交易還原。檔案可能有可恢復版本，外部服務則需要自己的取消或回復機制。對會寫入系統的代理，操作日誌與重複執行保護是額外需求，不能只靠記憶分支處理。

結語：AI 記憶的重點，也包括知道什麼已經過期

GitHarness 把長對話中的需求變動，轉成有版本關係的工作狀態。它希望代理保留仍然有效的成果，遇到新要求時選擇合適起點，而不是盲目沿用所有歷史或每次全部重做。這為多輪代理工作提供了值得追蹤的研究方向。

對使用者而言，最容易立即採用的習慣是把每次變更說清楚，並保存目前有效規格。對開發團隊而言，則是把需求、成果、資料版本與外部操作連起來驗證。當 AI 不只記得做過什麼，也能判斷哪些仍然成立，長時間合作才更有機會保持一致。

官方資料來源

• GitHarness 原始研究論文
• X 討論線索