再强调一遍，智能体是由大模型(LLM)+工具集(Tools)组合而成的

最近在做数据分析的智能体时遇到了一个问题，就是刚开始想做一个完全基于数据库表结构的数据分析智能体；但发现业务上的很多数据是通过程序代码动态计算出来的，完全通过数据库无法实现。

这个通过数据库进行数据分析的智能体使用的是vanna框架作为一个工具节点，来分析用户问题，然后由模型生成SQL语句，并调用数据库引擎执行并获取结果。

无独有偶，之前做了一个基于大模型的RAG系统，有个需求是把这个系统改造成MCP服务；但这个系统有完善的功能模块，包括登录，验证登一系列功能点。

当时由于不是太懂，想直接在这个系统上进行改造；但在改造的过程中却发现事情远远没有那么简单，首先登录验证模块怎么绕过，理论上来说登录验证模块应该置于功能模块之前，比如说网关；但现在的情况是RAG系统已经和登录验证模块耦合在了一起，如果在单独拆出来，那么成本比较高，而且还很麻烦，工作量就是一个大问题。

所以，遇到上面这两种情况应该怎么解决呢？

首先，遇到这种问题时千万不能钻牛角尖，我们应该发散我们的思维；在之前的文章中也不止一次的强调过，智能体是由模型+Tools组合而成的一个具有独立决策能力的系统；既然模型是无法取代的，那么就只能在工具上下手了。

在智能体中，工具也是一种可插拔的组件，一般情况下可以给一个智能体配备多个工具集，而工具集中的工具可以随时修改和更换；而这也为我们的系统扩展提供了广阔的空间。

以上面两个例子来说，既然直接通过库表结构无法完成数据分析的需求，那么是否可以从接口中获取统计好的数据；这样就可以绕过直接操作库表结构可能带来的问题；并且接口可以随时修改和扩展，以增强其数据分析的能力。

而从智能体的角度来说，只是把vanna的工具节点，换成接口请求的工具节点，对整个业务流程并没什么影响。而我们需要做的，只是把这个接口调用封装成一个工具(函数)即可；然后丢到智能体的工具集中。

同样，对RAG系统来说也是如此，可以单独做一个MCP服务，在服务中通过接口调用的方式去登录和访问RAG系统，这样就可以解决登录功能和RAG系统耦合的问题。你的RAG系统该怎么做还怎么做，我只需要在MCP中按照你的接口要求调用即可。

而这正应了软件开发中的那句老话——没有什么是加一层解决不了的，如果不行，那就再加一层。

智能体的核心除了大模型之外，就只剩工具了；而智能体的强大功能和扩展性都是通过工具来实现的。因此，工具才是智能体的强大的核心，毕竟再厉害的指挥官，如果手里没有部队也打不了仗。