在沒有本地索引器的情況下，給 AI 代理大型儲存庫的上下文

一個大型儲存庫放不進上下文視窗，而如果你曾經把膝上型電腦上的索引器指向一個真正的 monorepo，你就知道它在那裡也放不舒服——記憶體飆升，第一次索引要花一個小時，而你的代理在下一個工作階段開始時，依然在猜哪些檔案重要。

通常的答案是在編輯器旁邊執行一個索引器，對於能舒服放進一台機器的儲存庫來說，這是個不錯的答案。如果你的 monorepo 在 Cursor 中已經索引得很快，而那也是你唯一需要這張地圖的地方，那麼這篇文章沒有什麼可以補充的——跳過它就好。

這篇文章講的是另一種情況——當一個代理需要一張大型儲存庫的可查詢地圖，而你又不想為此執行本地索引器時。

什麼時候本地索引器是錯誤的工具

本地索引假定程式碼存在於查詢它的那台機器上，而在真正的 monorepo 規模下，即便在單個編輯器內部，這個假設也會變得吃緊。這個儲存庫單純就是大到你不想一直在膝上型電腦上保持熱索引：你在一個套件裡工作，而影響範圍卻在三個目錄之外，一次針對兩百萬行程式碼樹的冷啟動首次索引，不是你想經歷兩次的事——無論是在你自己的機器上，還是在一個從未複製過這棵程式碼樹的 CI 執行器上。或者，某個同事應該能查詢你在用的同一張地圖，而不必等自己的機器吃力地跑完同一個索引。

這些都不是丟棄一個好的編輯器索引器的理由。這是一個理由，說明你還應該擁有一張任何代理都能透過 MCP 查詢的託管地圖。

而規模問題比「檔案太多沒法貼上」要深得多。在一棵大程式碼樹上，有意思的問題幾乎從來不是「給我看這個檔案」——而是哪個檔案、哪個符號、哪些呼叫端、哪些測試。一個從列出 src/ 並讀取前三個結果開始的代理，會心安理得地漏掉 apps/api 裡的處理函式和 packages/sdk 裡生成的用戶端。你需要的是從整棵程式碼樹建置、再排序、並附上引用的檢索。

「大型儲存庫的上下文」到底意味著什麼

把檔案一股腦塞進提示詞不是上下文——那只是程式碼樹更小、更差的一份副本。你的代理真正需要的是提出問題，並得到帶引用的答案：這個符號定義在哪裡、誰在呼叫它，我即將修改的模組有什麼依賴它，哪個測試檔案覆蓋了這個行為，以及程式碼樹現在是什麼樣子，而不是上個季度的樣子。

這些答案必須來自一個根據你的儲存庫建置的索引，而不是模型對別人儲存庫的記憶，而且這個索引必須存在於代理上下文視窗之外的某個地方。對這個問題來說，它也應該存在於你膝上型電腦之外的某個地方。

還有一件事，指令檔案替你做不到：CLAUDE.md 和 AGENTS.md 是放置慣例和行為規範的正確地方，但它們不是一張兩百萬行程式碼樹的、活的、經過排序的、可查詢的地圖。行為用規則，事實用儲存庫智慧。

在雲端建置地圖，從任何用戶端查詢它

Maguyva 是一個遠端 MCP 程式碼庫上下文層。你連接 GitHub，選擇你的儲存庫，然後就可以放手，讓雲端管線解析程式碼樹、建立符號和圖邊、維護一張排序後的地圖——永遠不需要本地索引器。

當你推送程式碼時，變更的檔案會被增量解析，圖和排序層會按排程重建：免費方案每天一次，付費方案每小時一次。每份快照都帶有時間戳，讓你的代理能分辨自己讀到的是哪個版本的程式碼樹。這裡誠實的限制是未同步的本機工作——只存在於你工作樹中、從未推送過的編輯，還不在託管地圖裡。

然後，你把 API 金鑰新增到你已經在用的用戶端的 MCP 設定中，就完成串接。這裡有 24 個有文件記錄的 MCP 用戶端的設定指南，任何支援標準設定的其他 MCP 相容用戶端也都能連接。如果 Cursor 是你的主場，Cursor 頁面 會帶你走完那條路；同一個伺服器也服務於 Claude Code、VS Code、Windsurf、Codex CLI 等等。

你不需要更換編輯器。你給代理的是一整套工具介面——11 個 MCP 工具，涵蓋搜尋、符號、依賴分析、檔案檢索和儲存庫上下文——覆蓋 279 種以上的語言和基於文字的技術，這在一個早已不再是單一語言的 monorepo 上，比你想像的更重要。

答案會附上依據傳回，以帶行號的檔案路徑形式呈現。語意、結構、圖和文字檢索被融合成排序結果，所以像「什麼依賴 parseConfig」這樣的問題，得到的既不是一大堆 grep 輸出，也不是單一的語意片段，而是真正重要的那一小撮位置。

一份具體的操作指南

不要一上來就索引整個公司。以下是行之有效的路徑：

1. 選一個你已經很熟悉的儲存庫——一個你能手動評判的套件，勝過你手頭最大的程式碼樹。
2. 免費開始：3 個儲存庫，5 萬行索引額度，全部 11 個工具，沒有每月查詢配額。如果你的代表性儲存庫比這更大，定價頁面 按已索引規模——而不是按席位數——列出了工作區方案（$0、$19、$49、$149）。
3. 連接 GitHub，等待首次索引完成。你沒有在本機編譯任何東西。
4. 接上 MCP 用戶端——幾行設定。Maguyva 是一個遠端 MCP 伺服器，所以沒有外掛、沒有擴充套件，也不需要採用第二個編輯器。
5. 問一個你能核實的問題。「什麼依賴 parseConfig？」或者「登入工作階段過期在哪裡處理？」然後開啟被引用的 file.ext:line 結果，對照眼前的程式碼樹核對。
6. 只有在引用經受住那次核對之後，才讓代理去編輯。

如果第一個儲存庫合適，而你的程式碼樹很大，就按你的已索引行數和重建節奏提升工作區規模。人類和代理共享同一個使用者數——Maguyva 按工作區計費，而不是按席位——所以往這個迴圈裡再加一個代理不會多花你一分錢。

啟用測試和文件為任何首次執行推薦的一樣：索引一個你已經瞭解的儲存庫，問一個你能核實的問題。大型儲存庫不會改變這個測試，只會讓第一個選錯的檔案代價更高。

串接之後要留意什麼

留意三件事。新鮮度：付費方案每小時重建，免費方案每天重建，未推送的本機工作不會出現在地圖裡——這是你接受的權衡。範圍：索引一組有代表性的儲存庫，而不是每一個被歸檔的分叉儲存庫；免費方案是刻意設計成這個規模，讓你先弄清楚這些答案值不值得留下。以及驗證：一張無法引用路徑和行號的大型儲存庫地圖，只是一台更慢的猜測機器，所以在代理交付補丁之前，讓它先展示位置。

然後執行你在小儲存庫上會執行的同一個測試。索引一個你已經瞭解的儲存庫。問一個你能核實的問題。如果這張地圖是真實的，你的代理就不會再從一棵冷程式碼樹開始。

// no laptop got hot building this map.