超越提示詞：為 AI Agent 引入版本控制

與 AI Agent 互動的當前工作流程往往感覺像是一場豪賭。你提供一個提示詞，Agent 執行了一系列變更，然後突然一個資料夾消失了，或者一個關鍵功能被重寫了。當你問「你為什麼要這樣做？」或「這項變更是什麼時候發生的？」時，Agent 通常很難提供精確的答案，因為它缺乏對自身演進路徑的結構化記憶。

這正是 re_gent 旨在填補的空白。透過為 AI Agent 引入專用的版本控制系統 (VCS)，該專案尋求將 git 的嚴謹性——二分搜尋 (bisecting)、回溯 (rewinding) 與審計 (auditing)—帶入 Agent 式執行 (agentic execution) 的非決定性世界中。目前支援 Claude Code，re_gent 試圖將 Agent 行動背後的「意圖」正式化，讓開發者能將 Agent 會話視為一系列可追蹤、可逆轉的提交 (commits)。

問題所在：Agent 會話的「黑箱」

大多數開發者將 AI Agent 作為高速實作引擎。然而，隨著會話複雜度的增加，幾個痛點也隨之浮現：

缺乏來源證明 (Provenance)： 在漫長的會話中，很難精確指出特定的邏輯變更是在何時引入的。
「復原」的掙扎： 雖然某些 IDE 提供基本的復原功能，但要撤銷跨多個檔案的複雜 Agent 驅動變更，通常需要人工介入或重新啟動整個會話。
缺失的意圖： 標準的 git commits 追蹤的是「變更了什麼」，但它們並不總是能捕捉到 Agent 在特定提示詞-回應週期中，其內部推理過程中的「為什麼」。

辯論：專用 VCS 與標準 Git

「為 Agent 提供 Git」的提議在開發者社群中引發了重大辯論，主要集中在當 Agent 已經精通標準 Git 時，是否有必要使用專用工具。

支持標準 Git 的觀點

許多批評者認為，Agent 已經擁有數十年的 Git 使用訓練數據。從這個角度來看，專用的 VCS 是多餘的。有些人建議問題不在於缺乏工具，而是在於缺乏正確的工作流程。例如，有些開發者使用「Agent 鉤子 (agent hooks)」——透過自動化腳本觸發 git add . 與 git commit 並附上所使用的工具描述——來維護變更歷史。

「我認為 git 更多的是一種針對 AI 垃圾內容 (slop) 的防禦與品質控制手段，而不是應該被自動化的東西。」

這種情緒凸顯了一個關鍵的緊張關係：對自動化的渴望與對人工監督的需求之間的拉鋸。許多開發者偏好在將變更提交到永久歷史之前先手動審查 Agent 的變更，以避免「AI 垃圾內容」污染程式碼庫。

支持專用層的觀點

專用 Agent VCS 的支持者認為，Agent 的互動粒度與人類開發不同。一次人類的 commit 可能代表一個完成的功能，但 Agent 可能需要十次迭代的提示詞才能達到相同的狀態。

將每一次提示詞-回應週期追蹤為「微提交 (micro-commit)」可以提供一種粒度，這種粒度在主要專案歷史中會顯得雜亂，但在偵錯 Agent 的推理過程時卻極其寶貴。正如一位貢獻者所提到的，像 Jujutsu (jj) 這樣的工具已經提供了自動提交功能，讓開發者能更容易地比較提示詞之間的 diffs，而不會弄亂最終的分支歷史。

關於 Agent 可審計性的替代方案

圍繞 re_gent 的討論引發了幾種管理 Agent 狀態與意圖的替代策略：

計畫驅動實作 (Plan-Driven Implementation)： 與其使用直接的「提示詞 $\rightarrow$ 實作」流程，有些人建議採用「提示詞 $\rightarrow$ 計畫 $\rightarrow$ 實作」階段。透過在程式碼旁提交一份具體的計畫檔案，將「為什麼」作為儲存庫中的一等公民進行記錄。
內容定址儲存 (Content-Addressed Storage)： 一些新興工具正朝著基於 DAG (有向無環圖) 的提交歷史與 CRDT (無衝突複製資料類型) 發展，以允許 Agent 在團隊間協作並進行點對點的歷史同步。
會話索引 (Session Indexing)： 與其使用 VCS，有些開發者依賴於索引會話日誌 (例如在 ~/.codex/sessions)，讓 Agent 能搜尋自己的歷史紀錄來尋找先前的對話或決策。

結論：邁向 Agent 式治理的道路

無論解決方案是像 re_gent 這樣的獨立工具、與現有 Git 工作流程更緊密的整合，或是轉向以計畫為基礎的開發，共識是清晰的：隨著 Agent 從簡單的聊天介面轉向自主貢獻者，對可審計性的需求至關重要。從「黑箱」執行轉向透明、有版本紀錄的歷史，不僅僅是為了方便——它是擴展 AI Agent 在專業生產環境中的必要條件。