會隨行的上下文

Cursor 的索引器在 Cursor 裡非常出色。Tab 補全、行內編輯、聊天，以及那個視窗裡的代理，都已經建立在 Cursor 為開啟的工作區維護的專案索引之上。如果 Cursor 是你唯一寫程式碼的介面，而那個索引已經能找到正確的檔案，那就留在那裡。這是誠實的「原地不動」情形，也理應是本文的第一句話。

這篇文章講的是普通一週中的另一半。同一個儲存庫也會在 Claude Code 中開啟，被 Codex CLI 詢問，在第二台機器上被審查，或者被在 CI 中執行的代理查詢。問題不是「哪個索引器更好」。問題是，代理在一個視窗裡信任的地圖，和它在下一個視窗裡信任的地圖，是不是同一張。

Maguyva 就是那張會隨行的地圖。它是一個遠端 MCP 程式碼庫上下文層。代理查詢它的方式，和查詢其他任何 MCP 工具一樣。結果會以附行號的排序路徑傳回。Cursor 仍然是編輯器。移動的是上下文。

Cursor 的索引器是做什麼用的

Cursor 內建的索引存在的目的，是讓編輯器內的聊天、代理和搜尋能夠檢索相關程式碼，而不只是依賴模型原始上下文視窗所能容納的內容。這對 IDE 來說是正確的設計。這個索引是 Cursor 原生的。它不是 MCP 伺服器，也無法從任何其他用戶端存取。

它的工作方式，按照撰寫本文時 Cursor 公開文件和 Cursor 自身說法的描述是這樣的：主要的搜尋路徑不再是雲端 embedding 索引。Cursor 團隊在其社群論壇上表示，專門的語意／基於 embedding 的搜尋正在逐步淘汰，改採基於 grep 的檢索，因為現今的模型不靠它，自己就能把即時的程式碼樹搜尋得夠好。取而代之的是 Instant Grep，一個由 n-gram、倒排串列和布隆過濾器建構的本機搜尋索引，存放在一張記憶體對應的查找表中，因此查詢是在開發者自己的機器上解析的，而不是在伺服器上。

索引本身存放在儲存庫自己的 .git/cursor/ 目錄中，錨定在某個特定的 git 提交上；自那次提交以來的編輯會疊加在其之上，而不是觸發重新掃描，只有當本機狀態與索引建置時的狀態嚴重偏離時，索引才會重建。因為它位於 .git 內部，它永遠不會被追蹤，也永遠不會被推送——刪除該資料夾，索引就消失了。.gitignore 在設計上就自動受到遵守，因為只有受 git 追蹤的內容才符合條件，.cursorignore 則在讀取路徑上被強制執行。這條路徑上已經沒有伺服器端的 embedding 步驟，也沒有遠端向量資料庫。早先的文件描述了一種雲端輔助設計——分塊加密、Merkle 樹同步、團隊成員間的索引重複使用——而 Cursor 自己的團隊後來表示這種設計正在被淘汰，所以本文不再把它描述為當前狀態。

編輯器內一個突出的亮點是 Cursor 的 Explore 子代理。它可以在自己的上下文視窗中，用一個更快的模型發起多路平行搜尋，只傳回相關的發現，這樣主對話就不會被搜尋結果撐大。這是編輯器內部一項真正的優勢。保留它。

多根工作區也受支援：每個開啟的資料夾的上下文都對 Agent 可用。一些依賴 git 的功能，比如 worktree，在多根設定中會被停用，而 Cloud Agents 完全不支援多根工作區。

這些都不是離開 Cursor 的理由。這只是對一張地圖的準確描述——它在自己所處的地方非常出色。

「隨行」到底意味著什麼

當同樣的問題在不止一個用戶端上傳回同樣類型的答案，並帶有你可以開啟檢視的引用時，一張地圖就算是會隨行的。

• 在 Cursor 中：「parseConfig 定義在哪裡，誰呼叫了它？」
• 在 Claude Code 中，同一個儲存庫：同樣的問題。
• 在 Codex CLI 中，一台從未開啟過 Cursor 視窗的審查機器上：同樣的問題。
• 在一個會說 MCP 的 CI 代理中：同樣的問題，針對同一個託管的快照。

如果每個介面都建置自己的私有索引，你擁有的就不是一張地圖，而是幾份彼此漂移的快取。編輯器索引可能對磁碟上的程式碼樹是最新的。CLI 工作階段可能落後一天。CI 任務可能看的是另一份簽出的程式碼。而代理聽起來照樣自信滿滿。

Cursor 的索引器本來就不該解決這個問題。因為它活在編輯器內部，它建立的上下文就是為那個編輯器服務的。同時還需要 CLI、CI 管線或另一個編輯器的讀者，需要一個針對這些介面的獨立工具。這是一個範圍事實，不是缺陷。Maguyva 就是那個獨立的工具。

Cursor 索引器公開的語言數量，在本文可以使用的資料中沒有說明。Maguyva 公開支援 279 種以上的語言和基於文字的技術。Cursor 的定價這裡也沒有照搬；請參考他們的定價頁面。Maguyva 按工作區計費，而不是按席位，公開的方案為 $0、$19、$49 和 $149，取決於已索引的規模和工作區大小。

一張託管地圖，每個 MCP 用戶端

Maguyva 是一個遠端 MCP 伺服器。你連接 GitHub，選擇儲存庫，雲端管線會建立符號、圖邊和一張排序後的地圖。你把一個 API 金鑰新增到你已經在用的用戶端的 MCP 設定中。Maguyva 為 24 個有文件記錄的 MCP 用戶端（包括 Cursor）提供設定指南，也可以連接其他支援標準設定的 MCP 相容用戶端。

如果你在 Cursor 中工作，Cursor 設定頁面 是特定於該編輯器的路徑。同一個伺服器也服務於 Claude Code、VS Code、Windsurf、Codex CLI 等。你不需要更換編輯器。你為每個代理提供同樣的工具介面：11 個面向客戶的 MCP 工具，涵蓋搜尋、符號、依賴分析、檔案檢索、儲存庫上下文和確定性實用工作流程。語意、結構、圖和文字檢索被融合成排序結果。

這就是可移植性帶來的好處。你今天早上在 Cursor 中核實過的引用，和 Codex CLI 今晚傳回的引用形式相同。檔案路徑和行號。開啟它們。如果錯了，你會看到。如果對了，下一次編輯就有地方落腳。被認可的說法是更少的幻覺編輯，而不是承諾每一次編輯都正確。

新鮮度是公開的。快照帶有時間戳，因此代理知道自己讀到的是哪個版本的程式碼樹。重建節奏是：免費方案每天一次，付費方案每小時一次。誠實的限制是未同步的本機工作：只存在於工作樹中的編輯，還沒有進入託管地圖。無論你從哪個用戶端查詢，這個限制都是一樣的，而這正是重點所在。用戶端之間的漂移不再是第二個隱藏的限制。

文件給出了適用於每個用戶端的啟用迴圈：索引一個你已經瞭解的儲存庫，連接用戶端，問一個你能核實的問題。先在 Cursor 中做一次。再從你在審查那天真正會用的 CLI 中做一次。如果兩次回答引用的是同一個處理函式，就代表地圖確實隨行了。

兩張地圖如何並存

兩個都用。它們不是比較頁那種意義上的替代關係。

1. 讓 Cursor 的索引器繼續為磁碟上的專案工作。讓 Explore、Instant Grep 和編輯器內的代理使用它。這個迴圈是原生且快速的。
2. 在 Cursor 中把 Maguyva 新增為 MCP 伺服器，讓同一個工作階段也能查詢託管的工作區地圖。Cursor 是一個有文件記錄的 Maguyva 用戶端。你不是在兩個索引之間二選一、刪掉另一個。
3. 把同一個 Maguyva 伺服器新增到 Claude Code、Codex CLI，或任何接觸該儲存庫的其他 MCP 用戶端。一種 API 金鑰形式。一個工作區。
4. 如果某個 CI 代理相容 MCP，把它指向同一個伺服器。它會讀到和膝上型電腦一樣的、帶時間戳的快照。

編輯器索引仍然是回答「此刻這個視窗裡磁碟上有什麼」的最佳工具。託管地圖則是回答「今天要接觸這個工作區的每一個代理眼中它是什麼樣子」的最佳工具。這兩句話並不衝突。

工作區配額公布在定價頁面上：儲存庫數、已索引行數和使用者數，按工作區計費。代理和人類共享同一個使用者數。先用一個你能自己評判的儲存庫免費開始。等引用經受住了與程式碼樹接觸的考驗之後，再提升工作區規模。

本文不主張的事

本文不主張 Cursor 的索引器薄弱、不完整，或是更換編輯器的理由。本文的第一句話恰恰相反。

本文不主張 Maguyva 取代了 Instant Grep 或 Explore 子代理。那些是 Cursor 的功能。它們留在 Cursor 裡。

本文不為任何一個產品編造語言數量、延遲數字或 token 節省數字。未知的數字保持未公開。

本文不假裝未推送的本機工作已經在託管地圖裡。帶時間戳的快照讓這個限制變得可見，而不是消除它。

測試很普通。索引一個你已經瞭解的儲存庫。問一個你能核實的問題，先在 Cursor 中，再在第二個 MCP 用戶端中。會隨行的上下文，就是兩處得到同一條引用。

// same map, wherever you opened it.