MCP服务器里直接查向量库，和让模型自己调工具，到底有啥区别？

第二种我试过一阵，resource模式确实把检索逻辑固化了，模型只能被动读你给的内容，遇到需要多步筛选的问题就抓瞎。第一种虽然多轮tool call有token开销，但胜在灵活，模型自己判断要不要查、查几次，复杂问答场景下明显更稳。分块和重排基本躲不掉，文档一多不处理的话召回质量会断崖下跌，我现在是先用粗召回再塞给模型自己精排，效果比纯MCP内置好点。

第二种本质上把检索决策权收走了，长尾问题会明显变笨。建议保留工具模式，自己加个缓存层省token。

说实话我试过resource那种方案，感觉更像把MCP当成了静态文档源，模型确实没主动性，复杂问题容易答非所问。工具调用那套虽然多花点token，但至少模型能根据上下文决定查不查、查什么，效果稳很多。分块和重排你绕不开的，尤其文档多的时候，server端不做粗排，工具返回一堆垃圾片段，模型再聪明也白搭。我现在的做法是工具里塞个简单的rerank逻辑，先top20再压到5条给模型，体感比裸向量检索强不少。

其实这俩本质区别是“谁掌握检索主动权”。第一种模型自己决定查不查，确实灵活但多轮对话里token会累积，而且有时候它该查的时候不查，不该查的时候瞎查。第二种更像把数据库变成了模型的长上下文，省了工具调用开销，但前提是你得把检索结果预处理得足够好，不然塞一堆噪音进去反而干扰回答。分块和重排是肯定躲不掉的，尤其文档一多，MCP server里不做rag那套流程，效果会很难看。我目前是混合着用，高频问题走resource预加载，长尾问题靠工具按需查，感觉比单一模式稳一点。

我正好两个都试过，resource方式确实省token，但灵活度差不少，复杂问题里模型容易拿着一堆不相关的检索结果硬答。工具调用那轮开销其实没那么吓人，关键是能控制查的时机和次数，尤其多跳问答里差距挺明显。分块和重排这坑你真躲不开，不管哪种方式，MCP server里都得自己处理，建议先拿现成的RAG框架顶一下，别一上来就手搓。

第二种本质是把检索写死成被动读取，复杂场景下模型反而容易乱用上下文。分块重排绕不开，建议先小规模验证再全量接。

其实你这问题我最近也踩过，resource方式确实是把检索逻辑写死了，相当于你替模型做了“要不要查”的决定，复杂问答里容易漏上下文。工具方式虽然多一轮token，但模型自主判断触发时机反而更灵活，尤其多跳问题差异明显。分块和重排确实得自己搞，MCP这边顶多给你个标准接口，别指望现成方案。建议先小规模试两种再定，文档量大了之后重排策略影响比检索方式大得多。

第二种更像把检索嵌死在流程里，模型确实少了决定权，复杂问答容易翻车。分块重排基本跑不掉，MCP这层偷不了懒。

我也踩过这个坑，第二种确实不是把检索写死，resource更像是把数据摆在那儿让模型自己决定读不读，但实际用下来模型经常该查的时候不查，反而瞎编。第一种虽然多一轮token，但可控性强很多，复杂问答里召回质量明显更稳。文档量大的话分块和重排基本得在MCP server里自己做，别指望模型帮你兜底，这块偷懒后面全是坑。