“ 多智能體協同將是未來智能體的主要開發形式，其相對于單智能體更靈活更強大?！?/strong>

技術是一項重實踐而輕理論的東西，但我們很多時候容易陷入重理論輕實踐；總覺得理論我懂了，做出來肯定很簡單，但事實上理論很容易懂，但真正做出來卻很難。

知行合一，在知中行，在行中知；知行是一體的，而不是割裂的。

怎么做好一個智能體

之前學習過一段時間智能體的實現，使用的是Langgraph框架，但當時只是做了一些簡單的Demo，并沒有真正應用到具體的業務場景中，因此那時覺得做一個智能體好像很簡單，而且智能體好強大。

但等到真正想把智能體應用到真實的業務場景中才發現，想做好一個智能體真的不簡單，因為到現在為止好像感覺有點無從下手。

在學習智能體開發時，那時的主要思路是按照智能體的開發模式，然后找一個簡單的案例去實現；但在真實場景中很難有那種理想模式的智能體開發，反而因為業務需求的原因，導致智能體開發變得很復雜。

以作者使用智能體改造RAG系統為例，理想情況下是給大模型配置幾個召回工具，然后讓智能體根據用戶問題去調用工具然后獲取結果；但現實的需求點是，在使用工具召回數據之后，還需要對這些數據進行處理；比如說需要給用戶端展示參考了哪些文檔，哪些內容；這時就不僅僅只是把工具召回的結果丟給模型，而是需要對召回的數據做處理；但問題是這個處理怎么做？更重要的是怎么才能做的更通用？

畢竟從技術的角度來說，我總不能每次添加一個工具，就要對智能體進行重構，這樣不論從技術上還是時間上成本都太高，而且不符合軟件設計的原則。

因此，到底怎么做好一個智能體？

首先一點是，我們要明白什么是智能體，以及智能體應該怎么做，還有就是智能體的能力邊界；孫子兵法云:“知己知彼，百戰不殆”；這句話應用到技術開發中同樣如此。

簡單來說智能體就是大模型+工具+提示詞，但這只是智能體最簡單的模式，其能實現的功能也很簡單；而面對復雜業務問題就需要對智能體進行適當的調整或者改變。

首先，以作者改造RAG為例，智能體就不能簡單的調用召回工具，然后把召回結果丟給模型；這時甚至一個智能體都無法完成這個任務，更好的解決方式可能是使用兩個智能體，也就是多智能體。

第一個智能體的任務是接受用戶請求，并處理響應結果；第二個智能體只做數據召回，其功能是根據用戶需求調用召回工具，然后把召回結果做合并，清洗，格式化等操作；之后再把結果丟給第一個智能體。

這樣就可以從技術上把用戶端和業務端分開，不論業務端怎么變化；在數據召回上都是無感的，而且可以在任何地方使用。

所以，從理論上來說多智能體開發應該是未來的趨勢，其相當于單智能體具備很多優勢；而且，多智能體可以簡單到就一句提示詞，也可以復雜到是一個ReAct智能體，甚至更復雜。

智能體是一個使用 LLM 來決定應用程序控制流的系統。隨著你開發這些系統，它們可能會隨著時間的推移變得越來越復雜，使得管理和擴展變得更加困難。例如，你可能會遇到以下問題：

• 智能體有太多工具可供使用，導致在決定下一步調用哪個工具時做出糟糕的決策
• 上下文變得過于復雜，單個智能體難以跟蹤
• 系統中需要多個專業領域（例如，規劃師、研究員、數學專家等）

使用多智能體系統的主要好處是：

• 模塊化：獨立的智能體使得開發、測試和維護智能體系統更加容易。
• 專業化：你可以創建專注于特定領域的專家智能體，這有助于提高整個系統的性能。
• 可控性：你可以明確控制智能體之間的通信方式（而不是依賴于函數調用）。

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