当AI不再只是“工具”，而是能主动规划、调用工具、反思修正的智能体，人机协作的边界正在被彻底重写。从单点任务到自主闭环，Agent技术正推动AI从“被动响应”迈向“主动创造”。

最近做项目，有个挺头疼的事儿，就是需要通过 MCP 来调用知识库。

说实话，之前我对这种调用方式一直是持否定态度的。

为什么呢？

因为是否使用 MCP，主要依靠大语言模型的自主性。大家做 AI 产品的都知道，这里面有很大的不确定性。模型今天心情好可能给你调了，明天心情不好，它可能就不调用。

这种不确定性，直接导致了知识问答准确率的降低。这对于我们做 B 端产品来说，其实挺致命的。所以之前，我更倾向于使用 API 的方式来直接调用，简单粗暴，指哪打哪，逻辑都在代码里写死了，稳。

但是，当业务开始复杂起来，当知识库不仅仅是一个功能，而是成为一个独立的中台服务，要支撑各个场景、各个产品的时候，问题就来了。

如果全走 API，那就是典型的强耦合。前端业务稍微变一下，调用方得改，我们做服务的也得跟着改接口。两边都得动，谁也跑不了。 这种感觉就像是两个人绑着腿赛跑，互相牵制，工作量成倍增加。

所以，为了实现知识库和上层应用的解耦，让架构更灵活一点，我发现还是有必要使用 MCP 的。这一步，迟早得迈出去。

那么，怎么解决这个让我们头大的不确定性呢？

这段时间折腾下来，从目前我了解的情况看，主要有这么几个路子，也算是踩坑之后的经验总结吧：

第一，PE（提示工程）优化，这是基本功。

这里分两头抓。一方面是在 MCP Server 定义工具的时候，把工具的描述写得清清楚楚。你得像教实习生一样，告诉模型：这个工具是干嘛的，什么情况下用。

另一方面，是在写大模型的 System Prompt 时，要能引导它去使用 MCP。甚至为了保险起见，给一些 Few-shot，让大模型知道，看到这类问题，别犹豫，直接给我调工具。

第二，强制调用，把拒绝大模型自主决策。

有些场景下，我们不能让大模型自主决策，因为它的决策有可能出错。第二种方式呢，就是强制使用工具。通过参数改变大模型的设置，让它必须调用某个 MCP 工具。

那这种方式实际上也一定能够实现工具的调用，绝对稳。但是呢，也有副作用，在某些不太适配的场景上，它可能也会硬生生地去调用工具，这就显得有点呆。

第三，设计路由，这是我现在觉得最靠谱的方案。

简单说，就是设计一个分流器。我们区分出来，什么场景下坚决不要用 MCP，什么场景下可以让大模型自主决策，什么场景下必须调？

具体的做法是，在进大模型之前，先用一个特定的小模型去判断用户的意图。

也就是说，先用特定的模型去判断：用户是不是在问知识库里的东西？如果判断某一个路径必须调用 MCP server，那么我就不经过大模型的思考，直接强制调用。

这样既规避了模型不调工具的风险，还能适配不同场景，节省 token，提升响应速度。