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

最近在做數據分析的智能體時遇到了一個問題，就是剛開始想做一個完全基于數據庫表結構的數據分析智能體；但發現業務上的很多數據是通過程序代碼動態計算出來的，完全通過數據庫無法實現。

這個通過數據庫進行數據分析的智能體使用的是vanna框架作為一個工具節點，來分析用戶問題，然后由模型生成SQL語句，并調用數據庫引擎執行并獲取結果。

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

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

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

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

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

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

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

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

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

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

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

本文轉載自????AI探索時代??? 作者：DFires