三個團隊為AI代理丟失跨倉庫上下文問題推出了相同的修復方案

三週前，Cortex 2026工程基準測試顯示，自AI採用加速以來，每次拉取請求的事故率上升23.5%，變更失敗率上升約30%。我隨即撰寫了關於這些資料及其對爆炸半徑的影響的文章。

當時我低估了語言轉變的速度。此後，術語不再是“爆炸半徑”或“服務目錄”，而是“跨倉庫上下文”。它幾乎總是與“AI編碼代理”出現在同一句子中。原因顯而易見：一旦閱讀大範圍運營AI編碼代理的團隊釋出的內容，你會發現他們不再談論AI如何提高效率，而是談論為了AI能夠在多個倉庫間安全部署而必須構建的基礎設施。

最近六週內，三個團隊發表了相同的診斷和三種不同的解決方案。它們趨同的模式比任何一個單獨方案都更有趣，並對我們如何思考代理執行時基礎設施有直接啟示。

**三個團隊的成果**

Neilos（dev.to上的@neil_agentic），3月27日。一位獨立創始人運營著超過15個倉庫，涵蓋Go、Rust、TypeScript、Python和C++，透過Telegram協調十個專門的Claude Code代理。他的文章《如何管理15+倉庫的Claude Code（而不失去理智）》直接指出：最終結果是“在會話之間複製貼上上下文，手動跟蹤哪個PR依賴於哪個，以及監護看不到全貌的代理”。

他的解決方案名為ttal，將“讀取與探索”與“寫入”分離。一個輕量級探索代理可以跨任意倉庫讀取上下文。工作代理一次只寫入一個倉庫，在隔離的git工作樹中。一個管理代理在頭腦中持有跨倉庫計劃，並將工作路由到正確的倉庫。沒有作為資料結構的依賴圖。跨倉庫協調存在於管理代理的推理和一個將名稱對映到檔案路徑的專案登錄檔中。

Mabl，4月8日。一個由25名工程師組成的團隊管理著100多個倉庫，在AI加速前每月推送200多個拉取請求和40多個生產版本。到2026年2月，39%的提交是AI輔助的，在基礎設施倉庫中這一比例達到60%。他們的文章《我們如何構建系統讓AI代理在75+倉庫間推送真實程式碼》描述了一個四層架構。其中關鍵的一層是“跨倉庫基礎”。

在跨倉庫基礎內部，有一個“倉庫協調圖”：850多行的結構化登錄檔，覆蓋79個倉庫，包含詳細的依賴圖、釋出/訂閱主題對映、資料庫表所有權和規定的釋出順序。當代理處理跨倉庫功能時，它會查詢此圖以確定哪些倉庫需要更新、合併順序（先上游庫再消費者）以及根據CODEOWNERS和依賴鏈標記哪些審查者。他們報告稱，沒有這一層，“每次代理呼叫都需要人工提供上下文”。有了它，“上下文漂移從約40%的失敗降至5%以下”。

Meta，4月6日。我本週早些時候寫過Meta部落知識引擎的文章，這裡簡略。Meta構建了一個多階段AI流水線，包含50多個專門代理，用於對映其一個大數據流水線的部落知識。最後一段揭示了重點：“我們生成了一個跨倉庫依賴索引和資料流圖，展示變更如何在倉庫間傳播。這將‘什麼依賴於X？’從多檔案探索（約6000令牌）轉變為單次圖查詢（約200令牌）。”

對於代理在規劃過程中最常見的問題之一，令牌減少了30倍。

**相同與不同**

痛點完全相同。所有三個團隊都描述了代理生成本地正確但破壞未知消費者的程式碼。Mabl稱為上下文漂移，Meta稱為部落知識，Neilos稱為代理“看不到全貌”。現象只有一個：決定變更安全性的依賴圖存在於任何單一倉庫邊界之外，也即代理的上下文視窗之外。

解決方案的差異具有啟發性。

Mabl和Meta都構建了依賴圖作為可查詢的底層。Mabl的依賴圖是一個結構化的850行登錄檔，代理在規劃時查詢。Meta的是一個解析器生成的圖索引，代理作為工具呼叫。形式略有不同，但操作模式相同：確定性結構，自動重新整理（Mabl透過登錄檔更新和CODEOWNERS，Meta透過重新解析原始碼），作為單次查詢而不是多檔案探索。圖獨立於代理，且比任何單個代理會話更持久。

Neilos的ttal採取了不同方法。跨倉庫資訊存在於管理代理的工作記憶體和一個將專案名稱對映到檔案系統路徑的TOML檔案中，架構將寫入隔離到一次一個倉庫，並在管理代理的提示中保持協調模型。這適合擁有十個代理和十五個倉庫的獨立運營者。在Mabl的規模下，同樣的問題重塑瞭解決方案。一旦有25名工程師在79個倉庫中工作，沒有單個代理的上下文視窗足以容納協調模型，而且手動登錄檔在高吞吐量下無法保持最新，因此依賴模型必須存在於任何代理之外。

我從中學到的是，依賴圖作為可查詢的底層並非風格選擇，而是問題規模化後的必然結果。三個團隊遇到了同一堵牆。兩個團隊明確構建了底層；一個透過協調處理，這在獨立規模下是正確的選擇。一旦運營代理的團隊超過那個規模，底層就是你應該構建的。

**為什麼這應該是一個原語，而不是每個團隊重新構建**

Mabl的文章幾乎理所當然地列出了這一層。Meta的文章在關於代理群體和評論遍數的部分之後，只用一段提及。兩個團隊都將其視為實現目標的基礎設施。在這兩種情況下，結構層是他們構建中最便宜、最可複用、最持久的部分。Mabl的每個倉庫的CLAUDE.md如果沒有維護者會退化。Meta的LLM生成上下文檔案如果沒有自我重新整理的評論群體也會退化。依賴圖不會退化，因為解析器在每次推送時執行。

這就引出了每一個非Meta或Mabl的團隊的問題：你真的想自己手動編寫一個850行的倉庫協調圖嗎？並在倉庫新增、歸檔、重新命名和重構時保持其更新？在50名工程師的組織中，這相當於一個全棧工程師月的工作量，以及持續維護的稅收，而這並不在任何人的工作描述中。在200名工程師的組織中，這是一個專門平臺團隊的責任，與所有其他可能工作競爭。

這個原語應屬於任何單個團隊之上。圖本身是結構化的，源自原始碼，且在所有組織中形狀相同。你真正需要的東西（哪些倉庫從哪些倉庫匯入，誰消費哪個製品，變更的傳遞爆炸半徑）無論你有50個還是500個倉庫都是相同的問題。沒有理由讓每個執行AI編碼代理的多倉庫組織都從頭編寫自己的版本。它是一個底層，而不是一個功能。

**作為API的形態**

Riftmap透過單個只讀令牌自動發現GitHub或GitLab組織中的跨倉庫依賴圖，解析十個生態系統中的清單檔案：Terraform、Docker、Helm、Kubernetes、Kustomize、Go、npm、Python、Ansible和GitHub Actions/GitLab CI（未來還會新增更多）。該圖可透過HTTP API查詢，供AI代理在規劃期間呼叫。

自然的代理流程是三次呼叫。給定代理在github.com/myorg/payments-api的克隆中工作：

1. 將本地克隆URL解析為Riftmap倉庫

curl -s "$RIFTMAP_BASE_URL/repositories/lookup?url=https://github.com/myorg/payments-api" \ -H "X-API-Key: $RIFTMAP_API_KEY"

2. 一次往返獲取上下文：倉庫 + 依賴項 + 反向依賴 + 製品 + 新鮮度欄位

curl -s "$RIFTMAP_BASE_URL/repositories/$REPO_ID/context" \ -H "X-API-Key: $RIFTMAP_API_KEY"

3. 只有真正需要時：傳遞爆炸半徑

curl -s "$RIFTMAP_BASE_URL/repositories/$REPO_ID/impact?max_depth=3&min_confidence=0.8" \ -H "X-API-Key: $RIFTMAP_API_KEY"

三次呼叫回答Mabl的倉庫協調圖和Meta的依賴索引旨在解決的問題。完整模式釋出在https://app.riftmap.dev/openapi.json。獲取一次，交給你的代理，其餘的就是型別化的httpx或fetch呼叫。Python和TypeScript版本的這些示例在代理整合文件中，以及每個響應攜帶的新鮮度合約（last_scanned_at、last_commit_sha、last_activity_at、archived），以便代理判斷圖是否過時，要麼警告使用者，要麼觸發重新掃描。

這就是今天的底層，以HTTP API形式暴露。接下來是MCP伺服器和CLI，按此順序，以便任何Claude Code、Cursor或Cline代理可以直接引入而無需編排HTTP呼叫。順序和當前狀態在公共路線圖頁面上跟蹤。

**介面比模型更持久**

此時合理的反對意見是：模型最終不會在跨倉庫推理方面足夠好，從而不再需要這些嗎？Claude 5或未來版本不會直接解決嗎？

我認為問題不會按照反對意見假設的方向發展。即使假設模型在跨倉庫推理方面持續改進，有三點依然成立。

首先，從多倉庫組織的依賴清單中進行解析，是在做一個解析器可以確定性和低成本完成的工作。即使前沿模型完美執行，每次呼叫仍需支付令牌成本，而實際上這是一個預計算的查詢。Meta的30倍令牌減少不是模型質量問題，而是架構問題。圖索引總是比重新構建更便宜。

第二，模型每六個月變化一次。依賴圖不會。穩定API後面的可查詢圖，無論呼叫它的代理是Claude 4.7、Claude 5還是2027年的任何模型，其形狀保持不變。介面比模型更持久。投資底層與投資任何特定代理的上下文策略處於不同的時間尺度。

第三，新鮮度問題是結構性的。今天訓練的模型不知道你的團隊上週建立的倉庫。昨晚掃描生成的圖知道。只要倉庫圖的變化速度超過模型重新訓練的速度，這種差距就存在，而底層就是縮小差距的方法。

模型在跨倉庫推理方面變得更好可能改變的是圖上面的層次。更好的基於驗證結構的語義推理。更好的針對已知消費者影響的自動PR審查。更好的圖本身的自然語言介面。這些都是真實的事情，並且會很重要。它們都位於底層之上，而不是替代它。

**總結**

我開始的這三篇文章，正是我構建Riftmap所需的相同模式證據，只是有更響亮的名字。工程師願意花費真正的工程時間來構建某物，意味著該物是必要的。當三個獨立團隊在兩週內發表相同的診斷時，模式就是模式。

架構賭注沒有改變。先確定性解析器。圖作為持久層。AI作為上面的層，錨定在驗證結構上，而不是重新構建它。