你在 Cursor 里问项目里的问题时，它只能看到当前仓库，看不到你放在 RAGFlow 里的文档和知识库。把 RAGFlow 的 MCP 服务接进 Cursor，正好补上这块。但接上只是开始：工具该在什么时候被调、检索结果噪声大不大、MCP 进程挂了 IDE 会不会卡住，这些才是真正会卡人的地方。这篇按落地顺序给一份可照着做的清单。
你在 Cursor 里问项目相关的问题，它默认只能翻当前仓库：读代码、看改动、顺着引用找。可你团队放在 RAGFlow 里的需求文档、接口说明、历史排障记录，它一概看不见。把 RAGFlow 的 MCP 服务接进来，就是补这块——让 Cursor 在做题时能顺手去知识库捞一段回来。
但接上只是起点。真正卡人的是三件事：工具什么时候被调、检索回来的东西噪声大不大、MCP 进程挂掉会不会把编辑器一起拖住。下面按落地顺序走一遍，每节都给可执行的动作和判断标准，不保证一次成功，但能让你知道每一步该验证什么。
先把 MCP 服务接上，再确认它真的在干活
配置本身不难，难的是「显示已连接」和「真的能查」是两回事。先在 Cursor 的 MCP 配置里登记 RAGFlow 服务。这里有两种形态要分清楚：命令式启动和远程地址式。命令式必须写全可执行文件的绝对路径，别指望 shell 的 PATH；远程式则要确认地址写得对、鉴权头带上了。
- 登记服务在 Cursor 的 MCP 配置里加一条 RAGFlow 的服务项，命令式填全路径和启动参数，远程式填地址与鉴权头。改完重启 Cursor 让配置生效。
- 看握手状态打开 Cursor 的 MCP 面板，确认状态是正常连接，不是报错也不是空白。只显示 connected 但没有工具，基本等于服务端启动就挂了。
- 让它列一次工具在对话里明确要求列出可用的检索类工具。如果工具列表是空的，先回去查服务端日志，而不是继续折腾 Cursor。
- 命令行单独跑一遍绕开 Cursor，用命令行以同样的方式启动这个 MCP 服务，手动调一次检索工具，确认服务端本身能返回命中的片段。这一步能直接把问题切到「服务端」还是「Cursor 侧」。
- 让 Cursor 真去调提问时带上明确的知识检索意图，比如「根据我们知识库里的接口说明回答」。含糊的问题它会直接凭上下文答，不会去碰工具。
检索质量不过关，接了也是白接
接上之后你会发现，真正决定体验的是召回的那几段对不对。先回到 RAGFlow 侧看文档是怎么进库的：段落级切分通常比整篇塞进去更容易命中；表格和扫描件要单独处理，混在正文里检索往往捞不准。参数调优之前，先把入库质量这一层看一遍。
| 症状 | 先查哪里 | 怎么判断 |
|---|---|---|
| 答非所问、引用不到点上 | 文档切分粒度 | 把测试问题对应的原文段落找出来，看它是不是被切碎了或跟无关内容粘在一起 |
| 回答里塞满无关片段 | 返回条数 | 一次回来的片段过多会挤掉代码上下文，先把它压到个位数 |
| 明明库里有却检索不到 | 检索参数与查询表达 | 换一种说法再问一次，能召回说明是查询改写的问题 |
| 表格、扫描件总是漏 | 预处理方式 | 这类内容单独走一条处理流程，别指望正文切分覆盖它们 |
- 用两三个你已知答案的问题做回归，看召回的是不是那几段原文；命不中就调切分和检索参数，别急着换模型
- 需要的只是结论时，把返回内容压成摘要再拼进对话，减少无关文本对上下文的挤占
- 知识库内容与当前仓库强耦合、又更新频繁时，MCP 检索的收益会明显下降，直接放进仓库更省事
- 别一次改多个参数，切分改了就先跑回归，再动检索条数，不然你分不清是哪一项起了作用
什么情况下不适用：如果你的知识主要是代码本身，或者文档每周大改、检索回来的常常是过期版本，那这条链路的净收益可能是负的。判断标准很简单——接上之后回答质量没提升、反而更爱引旧内容，就该考虑关掉。
超时、并发与降级：别让 MCP 拖垮编辑器
MCP 是外部进程，它慢或者挂，代价会传导到你的编辑体验上。所以必须提前定好三条线：调用时间上限、同一轮对话里的检索次数上限、以及服务不可用时的兜底路径。没有这三条，一出问题就是转圈等，或者模型反复检索把额度烧完。
- 超时上限
- 给单次检索设一个你能接受的时间，超了就让模型改用现有上下文回答，而不是无限等待
- 调用步数上限
- 限制同一轮对话里检索类工具的调用次数，防止检索循环把时间和额度一起吃光
- 空结果兜底
- 服务不可用或返回为空时，明确告诉模型「本次没有检索到资料」，让它基于已知内容作答并标注不确定
- 请求日志
- 服务端按请求记下：查了什么、命中几段、耗时多少。出问题时这是唯一能回看的线索
这几条不需要一开始就完美，但至少要有一条明确的降级路径。判断标准是：把 MCP 服务手动关掉，Cursor 应该还能正常回答代码问题，只是不再引用知识库——如果关掉它就卡住或报错不断，说明兜底没做。
怎么衡量它到底帮上忙了
别凭感觉说「好像有用」。准备一组固定的小规模问题集，接 MCP 前后各跑一遍，比对答案里引用的内容是不是来自知识库、对不对得上原文。同时记录每次检索的耗时分布，看它是不是拖慢了整体响应。
- 固定问题集：十个以内、你已知标准答案的问题，覆盖文档类、接口类、排障类各几条
- 前后对照：同一组问题，关掉 MCP 跑一次，开着跑一次，只比引用来源和正确性
- 耗时分布：看慢的那几个问题是切分问题还是库太大，单独拿出来处理
- 开关能力：把 MCP 当成一条可开关的链路，效果不好时一键回到纯上下文模式
- 版本记录：知识库更新后重跑问题集，确认旧结论没有被新文档推翻
关于检索耗时、命中率这类量化指标的行业参考值，以及各家服务的当前表现，可以到站内的资料页核对当时的数字，别拿印象当依据。
下一步接完这条链路，顺手把它和别的工具一起纳入评估：查一下中转服务的连通性和响应表现，再对照价格与用量，避免检索链路把成本带偏。→常见问题
Cursor 里 MCP 显示连上了，但模型从不调用检索工具，怎么办？
先确认工具列表里确实有检索类工具，再检查提问方式：太笼统的问题模型会直接答。换成明确指向知识库的问法，比如「根据我的知识库，这个模块的鉴权是怎么设计的」，通常就会触发；还不行就回到服务端手动调一次，看工具本身是否正常返回。
检索回来的内容和我的代码不相关，是模型的问题吗？
多数情况是进料和切分的问题，不是模型。先看文档切分粒度是不是太粗、检索返回条数是不是太多，再确认知识库里是不是混进了过时资料。用几个已知答案的问题测一遍，能不能稳定召回那几段，比换模型有用得多。
MCP 服务偶尔挂掉，会不会把 Cursor 卡死？
会，如果调用没有超时边界的话。给客户端侧设一个可接受的上限时间，超时就走降级让模型基于现有上下文回答；服务端也建议独立进程跑，崩了不影响编辑器本身。上线前把「服务不可用」当成一条正常分支来测。
