當(dāng) Agent 開始用 Git 說話：從一個(gè) Vibe Coding 開發(fā)者的發(fā)現(xiàn)，到 Agent 協(xié)作的未來。 文章內(nèi)容由歸藏和 Opus 4.6 的討論自動整理而成

一、一個(gè)意外的發(fā)現(xiàn)

最近我在維護(hù)自己的開源項(xiàng)目時(shí)，做了一件很自然的事：讓 AI Agent 幫我處理 GitHub 上的 Issues 和 PR。

一開始只是圖省事——Issue 太多了，讓 Agent 幫我讀一讀、分分類、回復(fù)一些常見問題。PR 也是，讓 Agent 先做一輪 Code Review，幫我過濾掉明顯有問題的提交。

但很快我發(fā)現(xiàn)了一件有趣的事情：給我提 Issue 的，很多也是 Agent；給我提 PR 的，也是 Agent。

我的 Agent 在和別人的 Agent 對話。

它們用 Issue 的格式交換需求，用 PR 的格式交換代碼，用 Comment 的格式討論方案。沒有人刻意設(shè)計(jì)過這套流程，但它就這么自然地發(fā)生了。

那一刻我意識到——GitHub 正在無聲無息地變成一種 Agent 之間的通訊協(xié)議。

仔細(xì)想想，這并不意外。GitHub 天然具備 Agent 通訊協(xié)議所需要的一切特性：

• 可讀且安全 ：純文本，所有操作透明可審計(jì)

• 命令式的 ：Issue 是任務(wù)指令，PR 是執(zhí)行結(jié)果

• 結(jié)構(gòu)化的 ：標(biāo)簽、模板、狀態(tài)流轉(zhuǎn)，天然適合機(jī)器解析

• 有版本控制 ：每一次交互都被記錄，不會丟失

Agent 不需要什么新協(xié)議，它們已經(jīng)在用人類建造的最成熟的協(xié)作基礎(chǔ)設(shè)施來互相溝通了。

二、巧合還是必然？

昨天我剛和朋友聊完這個(gè)觀察，今天早上就看到一條新聞：GitHub 前 CEO Thomas Dohmke 宣布創(chuàng)立新公司 Entire，拿了 6000 萬美元種子輪，要在 Git 之上構(gòu)建 Agent 時(shí)代的開發(fā)者平臺。

有時(shí)候你模糊感知到的趨勢，突然被行業(yè)里最懂這件事的人用一家公司、一筆融資、一個(gè)產(chǎn)品確認(rèn)了——這種感覺很奇妙。

Thomas Dohmke 在公告里寫了一句話，和我的感受完全一致：

"我們?nèi)匀灰蕾囈粋€(gè)在云時(shí)代之前構(gòu)建的軟件開發(fā)生命周期，它天生是為人與人協(xié)作設(shè)計(jì)的。"

他看到的問題和我看到的一樣：現(xiàn)有的 Git/GitHub 體系是為人設(shè)計(jì)的，Agent 在將就著用。 能用，但不夠。

三、Entire 是什么，它比 Git 走到了哪一步？

3.1 Git 記錄了什么，遺漏了什么

先回顧一下現(xiàn)有的 Git 體系。Git 是一個(gè)極其優(yōu)秀的版本控制系統(tǒng)，它忠實(shí)記錄了：

• What ：哪些文件變了，每一行的 diff

• Who ：誰提交的

• When ：什么時(shí)候提交的

• Where ：在哪個(gè)分支上

但它有一個(gè)致命的缺失：Why——為什么要這么改。

在人類手寫代碼的時(shí)代，這個(gè)"為什么"勉強(qiáng)可以通過 commit message 和 PR description 來補(bǔ)充（雖然大多數(shù)人寫的都是 fix bug）。但在 Agent 時(shí)代，這個(gè)缺失被放大了一百倍——

Agent 生成了 500 行代碼，你只看到 diff，完全不知道它的推理鏈。Agent 做了一個(gè)架構(gòu)決策，選了方案 A 放棄了方案 B，你不知道權(quán)衡了什么。你給 Agent 的 prompt、約束、討論過程，在關(guān)閉終端的那一刻全部消失。

Git 保存了代碼怎么變的，但丟掉了代碼為什么這么變。

3.2 Entire 的 Checkpoint：給 Git 補(bǔ)上 "Why"

Entire 發(fā)布的第一個(gè)產(chǎn)品叫 Checkpoint。它的做法很聰明——不修改 Git，而是在 Git 之上增加一層語義元數(shù)據(jù)。

當(dāng)你用 Agent 生成代碼并 commit 時(shí)，Checkpoint 自動捕獲并綁定到這個(gè) commit SHA 上：

• 1

• 2

• 3

• 4

• 5

• 6

• 7

• 8

• 9

• 10

• 11

普通 Git Commit：  commit abc123 → diff（代碼變更）
Entire Checkpoint：  commit abc123 → diff（代碼變更）   +原始prompt（你給Agent 的指令）   +推理鏈（Agent 考慮了什么、放棄了什么）   +工具調(diào)用（Agent讀了哪些文件、調(diào)了哪些 API）                + 約束條件（必須兼容什么、不能用什么）   +token 消耗（花了多少算力）   +完整對話記錄（整個(gè)session的 transcript）

這些元數(shù)據(jù)存儲在一個(gè)獨(dú)立的 Git 分支（entire/checkpoints/v1）上，以 append-only 的方式追加。代碼本身不受任何影響，完全兼容現(xiàn)有的 Git 工作流。

本質(zhì)上，Checkpoint 把 Agent 的"想法"從黑箱變成了白箱——可追溯、可審查、可共享。

3.3 為什么這件事比"存聊天記錄"重要得多

你可能會想：這不就是把 AI 的聊天記錄存到了 Git 里嗎？

不。區(qū)別在于它是結(jié)構(gòu)化的、版本化的、綁定到代碼變更的。這意味著：

代碼審查的范式變了。 過去你打開一個(gè) PR，面對幾千行 diff，逐行讀代碼?，F(xiàn)在你可以先看 Checkpoint——Agent 接到的意圖是什么、它考慮了哪些方案、為什么選擇了當(dāng)前的實(shí)現(xiàn)。你審查的不再是"代碼對不對"，而是"思維過程合不合理"。

Agent 之間有了共享記憶。 Agent A 在一個(gè) session 里做了技術(shù)選型，session 結(jié)束后上下文消失。Agent B 接手時(shí)，可以讀取 Agent A 的 Checkpoint，直接繼承之前的決策和約束，不需要從頭推理。

決策歷史可追溯。 三個(gè)月后有人問"為什么選了 SQLite 而不是 PostgreSQL"，你不需要靠記憶，直接查那個(gè) commit 的 Checkpoint，當(dāng)初的完整討論和推理都在。

四、新范式：從"寫代碼的工人"到"審查 Agent 思維的監(jiān)督者"

Entire 和 Checkpoint 指向的，其實(shí)是一個(gè)更深層的范式轉(zhuǎn)變。

舊范式

• 1

開發(fā)者寫代碼 → commit → 開 PR → 同事看 diff → 討論 → merge

在這個(gè)流程里，代碼是核心產(chǎn)物，人的注意力集中在"這段代碼寫得對不對"。

新范式

• 1

表達(dá)意圖 → Agent 生成 → Checkpoint 記錄推理 → Review 意圖和結(jié)果 → 驗(yàn)證正確性

每一步都發(fā)生了質(zhì)變：

表達(dá)意圖——開發(fā)者的第一步不再是打開編輯器寫代碼，而是用自然語言描述"我要什么"。"我需要一個(gè) JWT 認(rèn)證中間件，支持 refresh token，過期時(shí)間 15 分鐘，兼容現(xiàn)有路由結(jié)構(gòu)。"意圖本身就成了工程產(chǎn)物。

Agent 生成——Agent 接到意圖后，讀項(xiàng)目結(jié)構(gòu)、分析現(xiàn)有代碼、權(quán)衡多種方案、做出選擇、生成代碼。這個(gè)過程消耗了大量算力和推理，但在過去，這些全部是瞬態(tài)的，commit 之后只剩下 diff。

Checkpoint 記錄推理——現(xiàn)在這些推理過程被自動捕獲。不需要你"有意識地"去記錄，不需要手動寫規(guī)則文件或技術(shù)文檔，Agent 每次 commit 時(shí) Checkpoint 自動保存。

Review 意圖和結(jié)果——你不再逐行看代碼。你看的是：意圖對不對？決策合理嗎？約束滿足了嗎？有沒有忽略什么？你審查的是 Agent 的認(rèn)知過程，而不是它寫的每一個(gè)分號。

驗(yàn)證正確性——正確性的驗(yàn)證也在變化。Agent 可以同時(shí)生成代碼和測試；另一個(gè) Agent 可以讀取 Checkpoint，檢查推理鏈?zhǔn)欠褡郧ⅲ粯I(yè)務(wù)指標(biāo)可以自動驗(yàn)證結(jié)果是否符合預(yù)期。

一句話總結(jié)這個(gè)范式轉(zhuǎn)變：人的角色從"寫代碼的工人"變成了"審查 Agent 思維過程的監(jiān)督者"。

五、對 Agent 時(shí)代的意義

把 Entire 放到更大的背景下看，它的意義超越了一個(gè)開發(fā)工具。

Agent 的世界需要自己的"互聯(lián)網(wǎng)"

舊世界里，HTTP 是人訪問網(wǎng)站的協(xié)議，構(gòu)成了互聯(lián)網(wǎng)。新世界里，Agent 需要自己的協(xié)作協(xié)議。

我在項(xiàng)目維護(hù)中觀察到的——Agent 通過 Issues 和 PR 互相溝通——是一種隱式的、低帶寬的通訊。它只傳遞了代碼和自然語言評論。Entire 想做的是把這變成顯式的、高帶寬的通訊：不僅傳代碼，還傳推理過程、上下文圖譜、決策依據(jù)。

這就是為什么 Thomas Dohmke 要把它開源，要強(qiáng)調(diào)"open, scalable, independent"。他不只是在做一個(gè)產(chǎn)品，他是在推一個(gè)協(xié)議標(biāo)準(zhǔn)。

從 2C、2B 到 2A

最近看到朋友寫的一篇文章《互聯(lián)網(wǎng)已死，Agent 永生》，里面提出了一個(gè)很精辟的概括：過去軟件服務(wù)人類消費(fèi)者（2C）或企業(yè)（2B），未來最大的客戶是 Agent（2A）。

如果 Agent 是軟件的新用戶，那 Agent 之間怎么高效協(xié)作就成了最關(guān)鍵的基礎(chǔ)設(shè)施問題。Entire 的 Checkpoint 本質(zhì)上就是在讓 Agent 之間的協(xié)作"用得爽"——不是給人看的漂亮界面，而是給 Agent 讀的結(jié)構(gòu)化推理數(shù)據(jù)。

"韓信點(diǎn)兵"需要指揮體系

文章里還引用了一個(gè)比喻：韓信點(diǎn)兵，多多益善——不是因?yàn)轫n信自己能打，是因?yàn)樗幸惶左w系。

未來人和人的差距，取決于你能驅(qū)動多少 Agent 為你工作。但驅(qū)動 1 個(gè) Agent 和驅(qū)動 100 個(gè) Agent 的難度完全不是線性增長的。沒有協(xié)調(diào)體系，100 個(gè) Agent 就是一場混亂——各自為戰(zhàn)、重復(fù)推理、互相沖突。

Entire 的三層架構(gòu)——Git 兼容數(shù)據(jù)庫、語義推理層、AI 原生開發(fā)生命周期——對應(yīng)的就是這個(gè)指揮體系。統(tǒng)一的信息存儲、共享的態(tài)勢感知、清晰的協(xié)作流程。

六、它解決了我的哪些問題，又有哪些還沒解決

解決了的：告別"人肉 Checkpoint"

作為一個(gè)重度 Vibe Coding 的開發(fā)者，我之前最痛的問題是：AI 在上下文壓縮后，記不住以前的東西。

我不得不頻繁地通過規(guī)則文件（比如 CLAUDE.md、cursor rules）去手動保存 Agent 的技術(shù)選型、架構(gòu)決策和約束條件。這些記錄是為了方便后期重構(gòu)或重大迭代時(shí)提供參考。但這個(gè)操作需要"有意識地"去做，而我經(jīng)常忘記。

Checkpoint 直接解決了這個(gè)問題——你不需要再手動記錄任何東西。 每次和 Agent 的對話、每個(gè)技術(shù)決策、每條推理鏈，都自動綁定到 commit 上，成為項(xiàng)目歷史的永久組成部分。

另一個(gè)直接改善是 Issue 和 PR 場景。過去有人提 Issue 問"為什么不支持 XXX 功能"，我需要憑記憶回答?，F(xiàn)在可以查詢 Checkpoint 歷史，找到當(dāng)初討論過這個(gè)功能的那次 session，直接引用當(dāng)時(shí)的推理來回復(fù)——有理有據(jù)，不靠記憶。

解決了的：多 Agent 協(xié)作有了共享認(rèn)知

我現(xiàn)在的工作流已經(jīng)很復(fù)雜了：用 Git worktree 管理多個(gè)分支，每個(gè) worktree 下面啟動 Agent Teams 完成不同的任務(wù)，然后我要審查它們的結(jié)果，決定采用哪個(gè)方案。

這個(gè)過程非常痛苦。六個(gè) Agent Team 的產(chǎn)出可能有幾千行代碼，我要在不同方案之間做比較，還要手動測試。Checkpoint 至少讓比較變得容易了——我不需要逐行對比 diff，我可以直接看兩個(gè)方案的推理摘要和決策依據(jù)，5 分鐘做出判斷。

還沒解決的：上下文爆炸問題

但我直覺上感覺 Checkpoint 能解決一部分問題，卻不能徹底解決 Agent 的交流和溝通問題。原因很簡單：

上下文窗口是有限的。

當(dāng)你把每次 commit 的完整推理鏈都存下來，一個(gè)運(yùn)行三個(gè)月的項(xiàng)目可能累積 10M tokens 的 Checkpoint 數(shù)據(jù)。而目前最好的模型上下文窗口才 200k。存下來了，但 Agent 一次看不完。

更關(guān)鍵的是，Checkpoint 可能會反過來更快地塞爆 Agent 的上下文。它解決了存儲問題，但引入了檢索問題——Agent 怎么從 500 個(gè) Checkpoint 里精準(zhǔn)找到它當(dāng)前任務(wù)需要的那 3 個(gè)？怎么把海量的歷史推理壓縮成有限上下文窗口內(nèi)的有效信息？

還沒解決的：從事后記錄到實(shí)時(shí)協(xié)調(diào)

Checkpoint 本質(zhì)上是"事后記錄"——Agent 做完了，commit 了，然后存一個(gè) Checkpoint。但在多 Agent 協(xié)作的場景里，我們需要的不只是事后讀記錄，還需要工作過程中的實(shí)時(shí)通訊。

比如 Agent Team 1 做到一半，決定了數(shù)據(jù)層用 Drizzle ORM——這個(gè)決定應(yīng)該實(shí)時(shí)同步給正在并行工作的 Team 2 和 Team 3，而不是等 Team 1 做完 commit 了，Team 2 才讀到這個(gè)信息然后發(fā)現(xiàn)自己的實(shí)現(xiàn)不兼容。

這已經(jīng)超出了 Checkpoint 的范疇，進(jìn)入了 Agent 間實(shí)時(shí)通訊協(xié)議的領(lǐng)域。

Entire 想怎么解決這些問題

回到 Entire 的完整愿景，Checkpoint 只是第一層地基。它的三層架構(gòu)恰好對應(yīng)了這些待解決的問題：

層次

解決什么

狀態(tài)

Checkpoint（存儲層）

信息不再丟失

? 已發(fā)布

Context Graph（語義推理層）

從海量 Checkpoint 中精準(zhǔn)檢索

待發(fā)布

AI 原生開發(fā)生命周期

Agent 間的實(shí)時(shí)協(xié)調(diào)與工作流

待發(fā)布

Context Graph 可能是最關(guān)鍵的一層。它需要做到：不是把所有 Checkpoint 塞給 Agent，而是根據(jù)當(dāng)前任務(wù)語義檢索相關(guān)的歷史上下文，并進(jìn)行分層壓縮——完整記錄、決策摘要、關(guān)鍵約束，不同場景用不同粒度。

就像人的記憶不是把所有經(jīng)歷都存著的——它有遺忘曲線、有抽象總結(jié)、有按需回憶。Agent 的 Checkpoint 系統(tǒng)也需要類似的智能檢索和壓縮機(jī)制。

七、結(jié)語

回到最初的發(fā)現(xiàn)：我在維護(hù)開源項(xiàng)目時(shí)，看到 Agent 已經(jīng)在用 GitHub 互相溝通了。這件事正在自然發(fā)生，不需要任何人許可。

Entire 做的事情，是把這種自然發(fā)生的 Agent 通訊，從隱式變成顯式，從低帶寬變成高帶寬，從"將就著用人類的工具"變成"為 Agent 時(shí)代專門設(shè)計(jì)的基礎(chǔ)設(shè)施"。

Checkpoint 是第一步——把 Agent 的思維過程從黑箱變成白箱。接下來的 Context Graph 和 AI 原生開發(fā)生命周期，才是真正讓 Agent 之間高效協(xié)作的關(guān)鍵。

但最深刻的變化可能不在工具層面，而在角色層面：

我們正在從"寫代碼的工人"變成"審查 Agent 思維過程的監(jiān)督者"。

不需要理解每一行代碼怎么寫的，但需要理解 Agent 的推理是否合理、決策是否正確、有沒有遺漏關(guān)鍵約束。這是一種全新的能力，也是一種全新的責(zé)任。

舊世界的開發(fā)者用鍵盤寫代碼。新世界的開發(fā)者用判斷力指揮 Agent。

而 Entire 這樣的基礎(chǔ)設(shè)施，就是讓這種指揮成為可能的指揮系統(tǒng)。

地基已經(jīng)打下。讓我們看看上面能建起什么。

引用：

Entire 官方介紹：https://entire.io/blog/hello-entire-world