用 Git 給多個 AI Agent 同步一個會成長的大腦

2026-05-20·3 分鐘閲讀AI Agent架構開源

一個很具體的痛點

我同時在好幾台機器上跑 AI 編碼助手：MacBook 上是 Claude，服務器上是 Codex，還有幾台 Linux 跑着 Gemini 和 Hermes。每一個都很聰明，但它們彼此失憶。

我在 Mac 上跟 Claude 確認過的事——比如"項目名從 DualViewX 改成 Duovid"“我的權威郵箱是哪個”——換到服務器上的 Codex，又要從頭解釋一遍。Agent 越多，重複解釋的税越重。

我想要的不是更聰明的單個 Agent，而是讓所有 Agent 共享同一個會成長的大腦。

為什麼是 Git，而不是數據庫或 MCP server

第一反應當然是搭個服務：一個數據庫、一個記憶 API，所有 Agent 讀寫它。但我很快否決了：

多一個服務就多一個要運維、要在線、會掛的東西；
記憶的本質是文本 + 版本演化，這恰好是 Git 最擅長的；
我需要審計記憶的來源——"這條結論是哪次會話、哪個 commit 寫進去的？"Git history 天然就是答案。

所以 nestwork 的核心決定是：記憶就是一個 Git 倉庫裏的一堆 Markdown 文件。沒有插件，沒有常駐服務。每個 Agent 會話開始時 git pull --rebase，結束時把自己這次學到的東西 commit + push。

分層：誰能寫什麼

把所有記憶塞進一個文件會很快失控，所以分層，並且寫權限嚴格隔離：

queen/        # 全局行為規則與策略，人類維護，Agent 只讀
shared/       # 跨 Agent 的穩定事實（用户身份、技術棧、協作偏好）
agents/<host>/<id>/   # 單個 Agent 實例的私有記憶，只有它自己能寫
projects/<name>.md    # 項目快照 + 協作狀態
workflow/     # 跨項目可移植的方法論

關鍵約束只有幾條，但都是硬的：

一個 Agent 只能寫自己的 agents/<host>/<id>/ 目錄；
queen/ 永遠人類説了算，Agent 不許碰；
shared/ 平時對 Agent 只讀，只有在顯式"蒸餾"流程裏才被合併更新。

這套隔離讓衝突幾乎不可能發生：每個目錄只有一個寫者。即使兩台機器同時 push，改的也是不同文件。

優先級鏈：衝突時聽誰的

光有分層不夠，還得規定衝突時的優先級。nestwork 用一條單向鏈：

queen/agent-rules.md  >  queen/strategy.md  >  shared/memory.md
   >  agents/*/*/memory.md  >  projects/*.md  >  workflow/*.md

當兩層指令打架時，不做"折中合併"——而是選高優先級那條，丟掉低的。折中是 Agent 最容易犯的錯：它會試圖同時滿足兩個矛盾的要求，結果兩個都沒做好。明確的優先級鏈把這個決定從"運行時即興發揮"變成"協議層確定"。

一個反直覺的坑：高頻文件會把主分支撐爆

上線兩週後我發現倉庫膨脹到 177MB——某些 Agent 把高頻變動的 history.jsonl（每次會話都重寫、還壓縮不友好）也提交進了 main。411 個 commit，主分支體積失控。

解決方案是給這類高頻產物開單獨的孤兒分支（orphan branch），分支名裏嵌入 host 和 agent-id：

每次快照是一個無父提交，force-push 覆蓋上一次；
分支永遠只有一個 commit，遠端對象數穩定在"當前快照大小"；
因為分支名唯一，單寫者，force-push 天然無衝突。

教訓寫進協議：高頻、壓縮不友好的產物，默認放孤兒分支，不進 main。人類手寫的低頻記憶才留在主線。

它解決的真正問題

nestwork 表面是個同步工具，內核其實是一套協議：怎麼分層、誰能寫、衝突聽誰的、什麼該記什麼該忘。工具可以換，協議是資產。

現在換任何一台機器上的任何 Agent，它 pull 完就知道：我是誰、在做什麼項目、上次卡在哪、哪些決定已經拍板不要再問。失憶税降到接近零。

項目開源在 github.com/songth1ef/nestwork。如果你也在多機器、多 Agent 之間反覆解釋同一件事，也許值得一試。