“ 再強調(diào)一遍，智能體是由大模型+Tools工具集組合而成的；工具才是智能體強大的核心。”

最近在做數(shù)據(jù)分析的智能體時遇到了一個問題，就是剛開始想做一個完全基于數(shù)據(jù)庫表結(jié)構(gòu)的數(shù)據(jù)分析智能體；但發(fā)現(xiàn)業(yè)務(wù)上的很多數(shù)據(jù)是通過程序代碼動態(tài)計算出來的，完全通過數(shù)據(jù)庫無法實現(xiàn)。

這個通過數(shù)據(jù)庫進(jìn)行數(shù)據(jù)分析的智能體使用的是vanna框架作為一個工具節(jié)點，來分析用戶問題，然后由模型生成SQL語句，并調(diào)用數(shù)據(jù)庫引擎執(zhí)行并獲取結(jié)果。

無獨有偶，之前做了一個基于大模型的RAG系統(tǒng)，有個需求是把這個系統(tǒng)改造成MCP服務(wù)；但這個系統(tǒng)有完善的功能模塊，包括登錄，驗證登一系列功能點。

當(dāng)時由于不是太懂，想直接在這個系統(tǒng)上進(jìn)行改造；但在改造的過程中卻發(fā)現(xiàn)事情遠(yuǎn)遠(yuǎn)沒有那么簡單，首先登錄驗證模塊怎么繞過，理論上來說登錄驗證模塊應(yīng)該置于功能模塊之前，比如說網(wǎng)關(guān)；但現(xiàn)在的情況是RAG系統(tǒng)已經(jīng)和登錄驗證模塊耦合在了一起，如果在單獨拆出來，那么成本比較高，而且還很麻煩，工作量就是一個大問題。

所以，遇到上面這兩種情況應(yīng)該怎么解決呢？

模塊工具化——沒有什么是加一層解決不了的

首先，遇到這種問題時千萬不能鉆牛角尖，我們應(yīng)該發(fā)散我們的思維；在之前的文章中也不止一次的強調(diào)過，智能體是由模型+Tools組合而成的一個具有獨立決策能力的系統(tǒng)；既然模型是無法取代的，那么就只能在工具上下手了。

在智能體中，工具也是一種可插拔的組件，一般情況下可以給一個智能體配備多個工具集，而工具集中的工具可以隨時修改和更換；而這也為我們的系統(tǒng)擴展提供了廣闊的空間。

以上面兩個例子來說，既然直接通過庫表結(jié)構(gòu)無法完成數(shù)據(jù)分析的需求，那么是否可以從接口中獲取統(tǒng)計好的數(shù)據(jù)；這樣就可以繞過直接操作庫表結(jié)構(gòu)可能帶來的問題；并且接口可以隨時修改和擴展，以增強其數(shù)據(jù)分析的能力。

而從智能體的角度來說，只是把vanna的工具節(jié)點，換成接口請求的工具節(jié)點，對整個業(yè)務(wù)流程并沒什么影響。而我們需要做的，只是把這個接口調(diào)用封裝成一個工具(函數(shù))即可；然后丟到智能體的工具集中。

同樣，對RAG系統(tǒng)來說也是如此，可以單獨做一個MCP服務(wù)，在服務(wù)中通過接口調(diào)用的方式去登錄和訪問RAG系統(tǒng)，這樣就可以解決登錄功能和RAG系統(tǒng)耦合的問題。你的RAG系統(tǒng)該怎么做還怎么做，我只需要在MCP中按照你的接口要求調(diào)用即可。

而這正應(yīng)了軟件開發(fā)中的那句老話——沒有什么是加一層解決不了的，如果不行，那就再加一層。

智能體的核心除了大模型之外，就只剩工具了；而智能體的強大功能和擴展性都是通過工具來實現(xiàn)的。因此，工具才是智能體的強大的核心，畢竟再厲害的指揮官，如果手里沒有部隊也打不了仗。

本文轉(zhuǎn)載自????AI探索時代??? 作者：DFires