[开源] 项目代码智能搜寻 MCP

强呀，大佬

额……有个东西叫cocoindex

不一样的东西

我现在对于要自己维护的索引没有兴趣

随机性太重了

有个东西叫sourcegraph……

没看懂这是什么，你是自己搭了一个服务器吗？拿官方的API key来用吗？

那时候 relace 没出 MCP

我想用就只能自己搞脚手架

太低调了 要不是孙佬的帖子里有人提到还不知道这个项目

好像很强，但是我不是很懂？是搜索哪里的智能体？全网的？哪个平台的？搜到的结果是智能体所在的网址还是相关的接口?

没那么复杂，只是项目代码搜寻

单次要求平行调用最多八个工具 (grep,…)，跑四轮回传结果

有 morph 和 relace 跟着 cc 在做这条路线

索引 + RAG 是另一条主流路线

另一个快速编辑工具简单说就是代码可以贴快点

是搜github上的智能体项目吗

搜你目前的代码库，类似 ace-mcp

只是没那么强

稳定版更新至 0.2.2，最新版更新至 0.2.3.dev2

关键内容

fast_search: 现在可以使用第三方模型进行搜寻，不限制 Relace

测试过的模型，均只简单测试 (python)

• relace: 官方专用高性能模型，耗时 15~20s，效果佳


• qwen 3 32/232b: 范围过窄，复杂情况效果不佳


• llama: 嘻嘻


• gpt-oss-120b: 普通性能，缓慢，效果普通


• mimo-v2-flash: 空回覆过于严重，平行工具调用不稳定


• minimax m2.1: 高性能，不过耗时长 (40s~50s)


• devstral-2512: 高性能，耗时普通 (20s~25s)，效果佳


• labs-devstral-small-2512: 高性能，耗时普通 (10s~20s)，效果佳，推荐

MCP 设置

必须为开发版 0.2.3.dev2 才能使用 mistral

"relace": {

  "command": "uv",

  "args": [

    "tool",

    "run",

    "relace-mcp==0.2.3.dev2"

  ],

  "env": {

    "RELACE_API_KEY": "rlc-your-api-key",

    "RELACE_BASE_DIR": "/absolute/path/to/your/project"

    "SEARCH_PROVIDER": "mistral",

    "SEARCH_ENDPOINT": "https://api.mistral.ai/v1",

    "MISTRAL_API_KEY": "",

    "SEARCH_MODEL": "devstral-2512",

    "RELACE_LOGGING": "1",

    "SEARCH_MAX_TURNS": "5",

    "RELACE_TEMPERATURE": "0.6",

  }

}

MCP Dashboard

采用 rich 实做终端机介面

在启用log之后，可以查看该 MCP 工具调用的情况

Linux log 路径: ~/.local/state/relace/relace.log

小結

暂时没时间整个项目重发一遍

不过希望有好心人能测测效果跟 ace-tool 差多少 (仅限Python ^-^)

没用mcp， 这次测了codex spark，

很奇妙 spark居然自己找到了auggie mcp而且调用了一次

虽然它token生成速度快 但是思维模式几乎跟codex一样强迫症

用时四分钟 几乎完美答案。。。。

relace

我稍微体验了一下relace的playground， 我感觉好像性能还挺强的？

大佬弃坑了么？

我准备捡起来试试看

我现在在研究用一个本地部署的devstral 2 small 24B 替代fast-ctx-mcp中的swe-grep

刚开始研究，不知会不会有坑

relace-mcp==0.2.3.dev2

请问大佬还在维护这个项目吗？想尝尝鲜

佬友，您好！我重新捡起了你这个项目，并且成功配置好语义检索了（同时开启retrieval和cloud_sync功能），先分享下我的配置：

[mcp_servers.relace]

enabled = true

command = "uv"

args = ["tool", "run", "relace-mcp==0.2.5a3"]

cwd = "<absolute_path>"



[mcp_servers.relace.env]

MCP_SEARCH_RETRIEVAL = "1"

MCP_BASE_DIR = "<absolute_path>"

RELACE_API_KEY = "rlc-xxx"

RELACE_CLOUD_TOOLS = "1"

index之后也是成功在relace的repo建立索引：

然而我通常不想天天修改MCP的选项，而且项目下的文件夹很多，而且并不是每个文件夹都是配置git的，所以佬友的freshness功能是失效了：

> 不是git仓库的话是不是每次索引都需要重建？



不是。不在 Git 仓库中，不代表每次都要全量重建索引；它主要影响的是 Relace 判断索引“是否新鲜”的能力。

你当前的 <absolute_path> 已经保存了本地同步状态：

repo_id: f9a5b9fc-fc0

tracked_files: 2003

state_saved: true



以后正常调用：

cloud_sync(force=false, mirror=false)

Relace 会利用这份同步状态比较文件，只上传新增或发生变化的文件，通常属于增量同步，不会重新上传并重建全部 2003 个文件。

没有 Git 的主要影响

Relace 无法通过 Git HEAD 快速判断代码是否变化。

所以 index_status 会显示：

freshness: unknown

hints_usable: true

needs_sync: false

这里的 unknown 不是索引不可用，而是“无法根据 commit 判断它是否和磁盘内容完全一致”。

文件改动后，需要主动执行一次 cloud_sync()。



在 Git 仓库里，Relace 可以比较当前 HEAD 和上次同步的 HEAD，直接提示索引过期。非 Git 目录没有这个信号，所以它可能不知道你刚修改了文件。

搜索结果不能绑定到具体 commit。

因此检索时会看到类似：

Sync state is missing git_head_sha

search is not pinned to a specific commit

这只影响版本可追溯性，不影响语义索引本身的使用。

日常建议

代码修改较少时，在需要准确检索前执行普通增量同步即可：

cloud_sync(force=false, mirror=false)

以下情况才需要全量同步：

cloud_sync(force=true, mirror=false)

适用于索引结果明显异常、大规模移动或重写文件、怀疑增量状态损坏。



若大量删除或重命名文件，并且希望云端也删除已经不存在的文件，则使用：

cloud_sync(force=true, mirror=true)

mirror=true 有删除云端旧文件的效果，因此只在确实需要镜像本地当前状态时使用。



所以你现在最合适的策略是：平时增量同步，不必重建；只是由于顶层不是 Git 仓库，需要由我们在重要检索前主动同步，而不能完全依赖 freshness 自动判断。 如果各项目本身分别是 Git 仓库，从索引新鲜度和 commit 可追溯性的角度，分别以项目根目录建索引会更精确；但你现在把整个 文件夹 建成统一索引，也更方便跨项目搜索。

我的问题是，能不能把MCP_BASE_DIR改成一个列表的形式，支持多项目的管理，在我代码发生修改时，自动调用cloud_sync增量同步？谢谢佬友

MCP_BASE_DIR 这个拿 AI 修一下就可以了

我个人不太想再维护这个项目

感觉 relace 没有想着墨这块

几个月前我跟着内测压缩端点 (回信直接黑洞)

现在也没放上来 ^-^

relace用起来确实有点麻烦，我也切fast-context试试吧