本文目錄
Agent 寫程式的速度，往往超過團隊決定「能不能合」的速度。有用的問題不是「某家 forge 會不會一夜取代 GitHub」，而是：誰決定 merge——AI 審查分數、CI 門檻、人工批准，還是三者組合。2026 年 10 月 26 日，Entire（CEO／共同創辦人 Thomas Dohmke）據此打開一座獨立 Git forge。官方稱 今天起對所有開發者可用。下文按 截至 2026-10-27 的發布新聞與工作流部落格整理；本站未對 GitHub、GitLab 或 Cursor Origin 做對照實測。
站內 AI 審查費用近文：CodeRabbit：至 11 月 8 日組織 Deep Scan 用量最高覆蓋 $5,000（總額 $1M）。
Trails 和 PR：頁面上到底換了什麼
經典 Pull Request 以 diff 為中心：評論沿時間線堆疊，CI 狀態靠近合併按鈕，人（以及越來越多的審查機器人）在執行緒裡爭論。Entire 部落格的論點是：當 Agent 寫了大部分改動，這條時間線更像給 Agent 回讀的稽核日誌，卻仍難給開發者一個清晰的「夠穩可以合了嗎？」信號。
Trail 是 Entire 的替代 HUD。官方材料把它寫成把需求、會話痕跡、程式碼變更與審查放在一起——更像飛行員儀表板，而不是線性評論流。工作流部落格裡的三步：
- 開 Trail。 可在 Entire 上從缺陷／需求起，也可從 Agent 在實作前或實作後起——精神上類似「準備推程式碼時開 PR」。一條 Trail 可跨多個倉庫，把相關改動收在一起。
- 每次推送打分。 審查 Agent 跑可自訂 evals，各自給出分數與理由（Entire 用花式滑冰評委作比）。Entire 稱自家許多倉庫啟用 Security、Slop、Human Review Required 等 eval；展示最近 5 次＋當前，便於看出單次雜訊。
- 清 findings，再合併。 Agent 可返回帶嚴重級別與建議修復的 findings。未解決項始終可見；已解決可隱藏但可找回。Agent 或人都可以處理或 dismiss。人仍可像在 PR 裡一樣發 findings／評論。
開源 Entire CLI 參與閉環：編碼 Agent 可按 findings 改完再推，人驗證進度。這是產品口徑摘要，不是「從此可以永遠不看高風險 diff」。
部落格寫明審查 Agent 底層可用 Claude Code、Codex 等，並在 Daytona／E2B 一類隔離沙箱中跑。下文只記為 Entire 官方說明的審查棧，不寫成站內對這兩款工具的評測背書。二者價格與用量對照見：Claude Code 和 Codex 該選哪個？價格和用量上限比一比。
Gates：分數、測試、人工批准各管什麼
Gates 是合併策略層。Entire 稱可按倉庫啟用，並可要求（舉例）：
| 控制項 | 通常回答什麼 | 單獨回答不了什麼 |
|---|---|---|
| AI 評測分數／findings | 審查 Agent 是否標了 Slop、Security、「需要人看」？未解決 findings 是否已清或 dismiss？ | 是否符合團隊威脅模型？分數是信號，≠安全保證。 |
| CI（Buildkite／Depot） | 這次推送的建置與測試是否通過？ | 測試是否覆蓋關心的失敗模式？綠燈 CI ≠ 證明正確。 |
| 人工批准 | 是否有具名的人接受剩餘風險？ | 批准人是否真讀了高風險路徑？批准是問責，不是全知。 |
說白了：分數看 Agent 審查迴路是否趨穩；CI看自動化建置／測試是否仍過；人工批准是「有人擁有這次合併」的開關。Entire 的說法是：信心夠、風險低、findings 清完再合——而不是要求人把 Agent 寫的每一行 diff 再讀一遍。這套策略是否適合受監管或高風險倉庫，只能團隊自己定。
這也解釋了為何不寫恐嚇標題。給 Agent 產出打分並設合併門檻，回答的是流程問題——人讀不過來每一筆 Agent 提交時，怎麼繼續發版。它既不是「現有託管已經過時」的證明，也不是在弄清 Buildkite／Depot 轉換是否適配 secrets 與 runner 艦隊之前，就拆掉 GitHub Actions 的理由。
GitHub 側權限與合併相關近文：GitHub Copilot Assisted Permissions 正式 GA。
Buildkite 與 Depot：CI 如何進 Trail
Entire 與 Buildkite、Depot 合作，讓建置／測試跟上 Agent 推送節奏。官方工作流要點：
- Buildkite： CI 配在專案級（常跨多倉共用）。接通後每次推送在 Buildkite 或自有基建上建置；結果作為 Trail 上的 check；失敗可擋合併。Agent 可透過 Buildkite API／CLI／MCP 閉環。GitHub Actions 使用者可用
bk pipeline convert轉換工作流，無需整份重寫。 - Depot： Depot CI 定位為跑相容 GitHub Actions 的工作流、中間不必經過 GitHub。從 Entire 接通後，
depot ci migrate發現 Actions 工作流並提升為 Depot CI，標出需人工複核項；配套命令可匯入 secrets／變數。
兩條路徑都是「CI 作為與 Agent findings 並列的門檻」，不是「CI 取代人的判斷」。本站暫時還沒有測試 Entire 的 CI 延遲或遷移成本。
託管邊界：今天私有倉，公共倉與自託管在後
按讀到的發布材料：
- 可在 Entire 上建立、遷移並原生託管私有倉庫。
- 現網區域：美國、歐盟、印度、澳大利亞（官方稱還將擴展）。
- 可從 GitHub 鏡像並保留 GitHub 為真相源，或 遷移（美國鏡像場景可 Detach；或
entire-migrate外掛；或本機 fetch／push）。 - 公共倉庫與自託管 Git 節點寫在後續／Road Ahead——不按發布日已全面可用處理。
對開源維護者與需要本地 Git 節點的企業：這次發布明確是私有倉優先。不要只憑這兩頁就規劃公共 forge 切流。
若先試用又不想立刻搬家，鏡像值得細讀。Entire 描述：授權 GitHub App、選倉與區域，甚至可在保留 GitHub 為真相源的同時，在 PR 之上使用 Trails。部落格稱服務中斷時 Entire 仍可從區域鏡像提供 clone／fetch，Agent 可向帶 entire/unmirrored/ 前綴的 Entire 原生分支推送，直到 GitHub 恢復。這是 Entire 的維運說明，不是本站做過的可用性實測——但足以分清「試用 Trails」和「離開 GitHub」不是同一決定。
廠商速度與記憶宣傳
新聞與部落格推廣兩組下文 不會寫成站內測速／稽核結論的數字：
- 推送速度： 最高約比 GitHub 快 89×、比 Cursor Origin 快約 6×，並附開源基準表（Entire 418 pushes/sec vs GitHub 4.7、Cursor 65 等）。這是廠商自報／廠商開源基準。
- Continuous Memory： 由 entire-graph（程式碼圖譜）與 entire-brain（會話記憶綁到圖譜）支撐。Entire 稱 graph 在其測試中最多約節省 71% token。同樣：廠商宣傳，不是本站做過的 token 稽核。
Continuous Memory 作為產品思路值得理解——會話與提示同步進倉庫，減少 Agent 每次新開上下文視窗的重複學習——但 71% 須標成 Entire 自測。兩篇主源也還沒有核到套餐價、席位費或 CI 按秒計費總額。本文不做購買、遷移或離開 GitHub 的建議。
選型合併流程時，怎麼讀 Trails
若痛點是「Agent 開 PR 比審查人跟得上還快」，Trails 對準的是那個瓶頸：評測分趨穩、findings 清完、CI 綠燈，再由人批准。若痛點是公共開源貢獻、自託管合規，或要一張帶價的遷移表，發布頁把這些問題留白——本站也不會編造答案。
即使尚未採用 Entire，也能先跑的清單：
- 拆開三項合併控制。 寫下組織已要求：自動審查 findings、CI 綠燈、具名人工批准；今天哪些失敗會擋合併。
- 先定義「分數」含義。 若啟用 Agent eval（在 Entire 或其他處），約定橙色 Slop 是「Agent 繼續改」還是「人必須看」。沒有門檻策略的分數只是儀表板，不是安全。
- 別把安全審查只交給分數。 把 Security eval 當分流；高風險路徑、金鑰、鑑權仍需人或專項審查。AI 審查分數 ≠ 程式碼安全保證。
- 託管要匹配倉庫形態。 私有多區域可能合適；公共開源與自託管節點現階段可能還不行。
- 推送加速與省 token 投影片先當行銷。 若數字影響預算，用自己的推送與 token 基線測。
對於 Entire 的推送延遲、Continuous Memory 的 token 節省、CI 遷移成本，以及日常 Trail 審查品質，本站暫時還沒有測試；回饋可透過網站底部的站長聯絡方式提交。