Agent 原生通訊協議：從傳遞代碼，到傳遞認知

當 Agent 開始用 Git 說話：從一個 Vibe Coding 開發者的發現，到 Agent 協作的未來。 文章內容由歸藏和 Opus 4.6 的討論自動整理而成

一、一個意外的發現

最近我在維護自己的開源項目時，做了一件很自然的事：讓 AI Agent 幫我處理 GitHub 上的 Issues 和 PR。

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

但很快我發現了一件有趣的事情：給我提 Issue 的，很多也是 Agent；給我提 PR 的，也是 Agent。

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

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

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

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

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

• 命令式的 ：Issue 是任務指令，PR 是執行結果

• 結構化的 ：標簽、模板、狀態流轉，天然適合機器解析

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

Agent 不需要什么新協議，它們已經在用人類建造的最成熟的協作基礎設施來互相溝通了。

二、巧合還是必然？

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

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

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

"我們仍然依賴一個在云時代之前構建的軟件開發生命周期，它天生是為人與人協作設計的。"

他看到的問題和我看到的一樣：現有的 Git/GitHub 體系是為人設計的，Agent 在將就著用。 能用，但不夠。

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

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

先回顧一下現有的 Git 體系。Git 是一個極其優秀的版本控制系統，它忠實記錄了：

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

• Who ：誰提交的

• When ：什么時候提交的

• Where ：在哪個分支上

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

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

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

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

3.2 Entire 的 Checkpoint：給 Git 補上 "Why"

Entire 發布的第一個產品叫 Checkpoint。它的做法很聰明——不修改 Git，而是在 Git 之上增加一層語義元數據。

當你用 Agent 生成代碼并 commit 時，Checkpoint 自動捕獲并綁定到這個 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 考慮了什么、放棄了什么）   +工具調用（Agent讀了哪些文件、調了哪些 API）                + 約束條件（必須兼容什么、不能用什么）   +token 消耗（花了多少算力）   +完整對話記錄（整個session的 transcript）

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

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

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

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

不。區別在于它是結構化的、版本化的、綁定到代碼變更的。這意味著：

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

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

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

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

Entire 和 Checkpoint 指向的，其實是一個更深層的范式轉變。

舊范式

• 1

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

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

新范式

• 1

表達意圖 → Agent 生成 → Checkpoint 記錄推理 → Review 意圖和結果 → 驗證正確性

每一步都發生了質變：

表達意圖——開發者的第一步不再是打開編輯器寫代碼，而是用自然語言描述"我要什么"。"我需要一個 JWT 認證中間件，支持 refresh token，過期時間 15 分鐘，兼容現有路由結構。"意圖本身就成了工程產物。

Agent 生成——Agent 接到意圖后，讀項目結構、分析現有代碼、權衡多種方案、做出選擇、生成代碼。這個過程消耗了大量算力和推理，但在過去，這些全部是瞬態的，commit 之后只剩下 diff。

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

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

驗證正確性——正確性的驗證也在變化。Agent 可以同時生成代碼和測試；另一個 Agent 可以讀取 Checkpoint，檢查推理鏈是否自洽；業務指標可以自動驗證結果是否符合預期。

一句話總結這個范式轉變：人的角色從"寫代碼的工人"變成了"審查 Agent 思維過程的監督者"。

五、對 Agent 時代的意義

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

Agent 的世界需要自己的"互聯網"

舊世界里，HTTP 是人訪問網站的協議，構成了互聯網。新世界里，Agent 需要自己的協作協議。

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

這就是為什么 Thomas Dohmke 要把它開源，要強調"open, scalable, independent"。他不只是在做一個產品，他是在推一個協議標準。

從 2C、2B 到 2A

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

如果 Agent 是軟件的新用戶，那 Agent 之間怎么高效協作就成了最關鍵的基礎設施問題。Entire 的 Checkpoint 本質上就是在讓 Agent 之間的協作"用得爽"——不是給人看的漂亮界面，而是給 Agent 讀的結構化推理數據。

"韓信點兵"需要指揮體系

文章里還引用了一個比喻：韓信點兵，多多益善——不是因為韓信自己能打，是因為他有一套體系。

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

Entire 的三層架構——Git 兼容數據庫、語義推理層、AI 原生開發生命周期——對應的就是這個指揮體系。統一的信息存儲、共享的態勢感知、清晰的協作流程。

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

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

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

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

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

另一個直接改善是 Issue 和 PR 場景。過去有人提 Issue 問"為什么不支持 XXX 功能"，我需要憑記憶回答。現在可以查詢 Checkpoint 歷史，找到當初討論過這個功能的那次 session，直接引用當時的推理來回復——有理有據，不靠記憶。

解決了的：多 Agent 協作有了共享認知

我現在的工作流已經很復雜了：用 Git worktree 管理多個分支，每個 worktree 下面啟動 Agent Teams 完成不同的任務，然后我要審查它們的結果，決定采用哪個方案。

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

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

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

上下文窗口是有限的。

當你把每次 commit 的完整推理鏈都存下來，一個運行三個月的項目可能累積 10M tokens 的 Checkpoint 數據。而目前最好的模型上下文窗口才 200k。存下來了，但 Agent 一次看不完。

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

還沒解決的：從事后記錄到實時協調

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

比如 Agent Team 1 做到一半，決定了數據層用 Drizzle ORM——這個決定應該實時同步給正在并行工作的 Team 2 和 Team 3，而不是等 Team 1 做完 commit 了，Team 2 才讀到這個信息然后發現自己的實現不兼容。

這已經超出了 Checkpoint 的范疇，進入了 Agent 間實時通訊協議的領域。

Entire 想怎么解決這些問題

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

層次

解決什么

狀態

Checkpoint（存儲層）

信息不再丟失

? 已發布

Context Graph（語義推理層）

從海量 Checkpoint 中精準檢索

待發布

AI 原生開發生命周期

Agent 間的實時協調與工作流

待發布

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

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

七、結語

回到最初的發現：我在維護開源項目時，看到 Agent 已經在用 GitHub 互相溝通了。這件事正在自然發生，不需要任何人許可。

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

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

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

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

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

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

而 Entire 這樣的基礎設施，就是讓這種指揮成為可能的指揮系統。

地基已經打下。讓我們看看上面能建起什么。

引用：

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