会随行的上下文

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.