Entire 推出專為代理人與人類協作的 Git Forge

經過一年多的努力，我們很高興推出第一個專為代理-人類協作打造的 Git forge。Entire 基於三個基礎概念構建：

1. The Trail。 與傳統以差異檢視程式碼變更的 pull request 模式不同，Trails 為開發者提供類似航空駕駛員的預覽顯示，並在每次程式碼推送時由代理自動評估並給予評分。
2. 分散式 Git 託管。 Entire 建立在一個相容 Git 的新原始碼控制伺服器上，其推送速度可比 GitHub 快 89 倍、比 Cursor Origin 快 6 倍。您可以在全球多個地區託管並複製您的倉庫，提供資料本地化與代理流量的擴充套件性。
3. Continuous Memory，一種新方法，讓代理與開發團隊將會話與提示同步到 Git 倉庫，並使這些資料持續可用且可被編碼代理搜尋。

此外，我們正打造一個開放生態系，讓開發者可為工作挑選最佳工具。起初，我們與 Buildkite 與 Depot 合作提供持續整合（CI），確保您的建置與測試流程跟上代理交付的速度。

Entire 今日已對所有開發者開放，並特別為 AI 原生團隊及其代理進行最佳化。讓我們一起進入新的多元宇宙。

使用 Trails 進行審查

在 pull request（PR）中，開發者會線上性時間軸上發布評論，並由持續整合（CI）在底部提供狀態，接著是合併按鈕。現在，程式編寫與程式碼審查正用長篇描述擾亂此時間軸。開發者會請求其編碼代理處理程式碼審查代理的回饋，然後再進行一次審查。PR 已變成僅供代理閱讀的審計日誌，未能為開發者提供決定是否自信合併的資訊。

The Trail 改變了這一點。它將相關資訊以評估分數的形式帶到頁面頂部，並於每次推送時計算。目標很簡單：提供所有必要資訊，讓您決定是否已經完成足夠多次編碼代理與審查代理之間的迴圈，達成穩定狀態；若未達成，則需再迭代。只有當信心高、風險低且所有發現已清除時，才應進行合併。

以下是 Trail 生命週期的三個步驟：

1. 啟動一個 Trail

在 Entire 上，您可以透過提交錯誤報告或功能請求啟動一個 Trail。或者，您也可以直接從代理啟動 Trail，無論實作開始前或後，都像您準備推送程式碼時開啟 PR 一樣。Trail 可以跨多個倉庫，將相關變更聚合在一起。

2. 使用 Evals 為 Trail 打分

當程式碼推送至 Trail 時，Entire 會觸發審核代理來審查提交。可以把它想像成陪審團評審滑冰表演。每個代理會在雲端沙盒中獨立執行，並提交分數與理由。例如，在 Entire 的多個倉庫中，我們使用 Security、Slop 以及 Human Review Required 評估。如果 Slop 分數為橘色，您可以指示代理根據該資料持續修正並推送，直到分數轉為綠色。每個評估都會顯示最近 5 次執行與目前執行。我們認為這很重要，因為一次性迴圈往往會漏掉關鍵問題。重複迴圈並穩定分數對代理程式成功至關重要。

在 Entire 上的每個專案都預先定義了代理程式，用於程式碼品質、安全性與程式碼雜亂，可按倉庫設定啟用。您可以透過 Entire 使用者介面或作為 .json 設定在倉庫中，來設定您自己的代理程式。在內部，Entire 使用最新模型的 Claude Code 與 Codex，並在隔離的雲端沙盒上執行，這些沙盒由 Daytona 與 E2B 提供。

3. 關閉所有發現，然後合併

每次推送時，代理還能回報具體發現與建議修復，並標示不同嚴重程度。未解決的發現始終可在 Trail 中看到，而已解決的發現則被隱藏，但可透過選單取得。這樣您就能隨時留意仍未處理的問題。發現可以由代理或人類開發者處理或忽略，您猜對了。您也可以像在 Pull Request 中一樣發布發現與評論。

為確保在未處理代理發現前不會進行合併，可為每個倉庫啟用 Gates，定義批准前必須滿足的條件。這些條件亦包含人類審批與 CI 通過。

CI 與 Buildkite 及 Depot

持續整合最早由 Grady Booch 在 1991 年提出。它對現代軟體開發生命週期的成功至關重要，使團隊能夠每天部署數百次。現在代理程式已經寫下所有程式碼，擁有 CI 作為安全防護就更為重要，以確保代理程式不會改變提示未預期的內容。因此，我們很高興能為 Trails 提供領先 CI 供應商的 一流整合，今天先從 Buildkite 和 Depot 開始。

Buildkite

在 Entire 上，CI 通常在專案層級設定，因為同一專案內多個倉庫可能共用相同基礎設施。連線 Buildkite 後，每次推送都會在 Buildkite 或您自己的基礎設施上執行建置。像在 PR 那樣，結果會以檢查方式顯示於 Trail 上，失敗的建置將阻止合併。當然，代理也可以透過 Buildkite 的 API、CLI 或 MCP 自動化整個迴圈。

若您是 GitHub Actions 使用者，您可以透過執行 bk pipeline convert 來遷移工作流程，而無需重寫。

Depot

Depot 為開發者與程式碼代理提供快速且可靠的軟體交付基礎設施，並與 GitHub Actions 相容。Depot CI 能在不介入 GitHub 的情況下執行現有工作流程。

團隊可以在幾個點選內從 Entire 連結 Depot 並在相同流程中建立 Depot 帳戶。接著 depot ci migrate 會發現您的 GitHub Actions 工作流程，將其升級為 Depot CI 工作流程，並標示需要審查的專案。伴隨指令支援匯入秘密與變數，讓遷移的工作流程可在數分鐘內執行。團隊保留已建立的工作流程，並從首次執行就獲得快速且可靠的 CI，按秒計費，速度越快成本越低。

在您所在區域託管倉庫

在分散式版本控制普及之前，倉庫及其歷史記錄存在於 Subversion 等系統上。Git 改變了這一點。開發者可以在本地建立提交與分支、合併，甚至重寫歷史，必要時再進行同步。Git 協議支援分發甚至去中心化，但 forge 卻未能實現。Git 將倉庫分發給客戶端，而各種 forge 反覆將伺服器端集中化。我們認為這種集中式模型不適合未來，因為它缺乏可擴充套件性、韌性，以及對程式碼儲存位置的控制。

從今天起，您可以在 Entire 上建立並原生託管倉庫，或從 GitHub 進行映象。Entire 由一個新的原始碼控制伺服器提供動力，並以分散式物件儲存與交易式引用資料庫擴充，仍保持與 Git 相容。 由於此架構，Entire 成為今天最快的 Git forge。根據我們的 開源基準測試，推送速度比 GitHub 快 89 倍，快 6 倍於 Cursor Origin。使用者與組織可將專案與倉庫複製到多個區域，或保留於其所在區域，例如符合資料在地化需求。我們今日已在美國、歐盟、澳洲及印度上線。

建立新倉庫

要開始，您可以透過我們的 網頁介面 或使用 Entire CLI 在您的代理程式上 建立 新倉庫。倉庫位於屬於組織或個人帳號的專案內。建立專案時，您會選擇主區域，然後將倉庫複製至一個或多個區域。

映象您的倉庫（保持 GitHub 為真實來源）

若您想讓 GitHub 保持為真實來源，沒問題。映象您的倉庫，方法是授權 Entire 的 GitHub App，然後在 Entire 上選擇倉庫與區域。您甚至可以在拉取請求上使用 Trails，正如您在 Entire 原生託管的倉庫中使用的那樣。映象時，推送流量會回傳至 GitHub。若服務中斷，Entire 會繼續從您的區域映象提供克隆與抓取，您的代理程式也可持續推送至 Entire 原生分支（任何以 entire/unmirrored/ 為字首的分支），直到 GitHub 恢復。

遷移您的倉庫

如果您想要 遷移 您的倉儲庫從 GitHub，您有兩個選項。若在美國映象，您可以在倉儲設定中點選 從 GitHub 分離，並選擇將其移動到的專案。或者，如果您想直接從 GitHub 映象而不映象，您可以使用 entire-migrate 外掛來完成此流程。當然，您也可以隨時從 GitHub 取回並推送到 Entire，無論是在本機還是作為 CI/CD 工作流程的一部分。

將會話轉為連續記憶

每天，開發者與代理程式都會做決策、發現限制、嘗試新方法，並在構建功能與修復錯誤時學習哪些有效。但大部分知識在會話結束時會消失。當您開始新會話時，代理程式會開啟新的上下文視窗，必須重新學習一切，這不僅緩慢，也很昂貴。

今天，我們推出一個新概念，稱為 連續記憶。可以這樣想：CI 將程式碼結合，CD 將其釋出，連續記憶則將理解延續。倉儲庫是代理程式唯一需要的記憶。

Entire CLI 中的兩個新指令使連續記憶成為可能：entire-graph，它對映您的程式碼如何結合，測試中可節省多達 71% 的 token；以及 entire-brain，它索引您的代理程式會話並將其附加到圖表，建立可持久的記憶，代理程式可比 grep 更快檢索程式碼庫。兩個外掛皆為開源且優先本地化，並設計為協同工作：entire-brain 以 entire-graph 的程式碼地圖為基礎。

程式碼庫地圖

entire-graph 為您的代理程式提供一張預先計算好的 Git 倉儲地圖：排名程式碼搜尋、定義、呼叫者、型別、路徑與變更影響，每項都有 file:line 個位置。內建分析器使用 tree-sitter 本地解析倉儲，並不傳送網路請求、模型呼叫或 API 金鑰查詢。

entire-brain

entire-brain 為您的倉儲建立一層持久記憶。這讓代理程式能在任何時候擁有正確的上下文，即「為什麼」背後的「什麼變更」。在底層，entire-brain 索引 entire-graph 的程式碼地圖，並將其與透過 Entire CLI 在 Git 歷史中記錄的過往代理程式會話繫結。

例如，若您正在修復一個造成帳單系統不匹配錯誤的四捨五入 bug，entire-graph 會追蹤發票計算過程中每個呼叫者和測試；而 entire-brain 則會提供代理程式對目前邏輯的意圖、已釋出的修正及其原因，或上一次有人更改時哪些測試失敗。

entire-brain 也可連線到 Entire 後端，讓您團隊的代理程式記憶存於一個共用空間，而非各自機器。每個 Trail 會顯示代理程式建立的記憶，審查者即可看到開發者做出的決策與代理程式學到的事實。要開始使用，請在倉儲中設定 entire-graph 與 entire-brain。

加入 Rebellion

我們開始一年後，對 Entire 已經成為什麼樣子以及我們的代理人正在進行什麼下一步感到無比興奮。但打造一個新的開發者平臺只能在與社群合作的情況下完成。因此，我們想聽聽您的聲音，向您學習，並與您一起改進產品。試試看吧。透過 Discord 告訴我們您喜歡什麼或想要改進的地方，讓我們一起設計未來的鍛造之地。

趁熱打鐵。歡迎加入叛亂。