一、新聞

先播放一條最新新聞，通義團(tuán)隊(duì)官宣開源了兩個(gè)智能體Alias-Agent和Data-Juicer Agent。

Alias-Agent提供了RaAct，Planner，DeepResearch三種模式，以實(shí)現(xiàn)靈活的任務(wù)執(zhí)行。

DataJuicer 智能體是一個(gè)數(shù)據(jù)專員，由數(shù)據(jù)處理智能體，代碼開發(fā)智能體，MCP 智能體，數(shù)據(jù)分析與可視化智能體，問答智能體五個(gè)智能體組成。

看到這里已經(jīng)相當(dāng)炸裂了！可能很多伙伴對(duì)智能體（Agent）的范式不熟悉，還不理解ReAct、Planner、反思叭叭這些名詞。那你們就來對(duì)了地方，我用最容易理解的方式帶大家一起看下智能體內(nèi)部是什么樣子的。

?

產(chǎn)品化的智能體由多Agent，反思，計(jì)劃，推理與行動(dòng)，記憶，RAG，工具，MCP組成的。首先聊下“Multi-Agent”，它非常好玩！

?

二、Multi-Agent 的7種設(shè)計(jì)模式

要讓AI代替人工作，現(xiàn)階段的單體智能體（僅通過系統(tǒng)提示詞賦能的LLM）是很難實(shí)現(xiàn)的。我們很快意識(shí)到，要構(gòu)建高效的系統(tǒng)，需要多個(gè)專業(yè)化智能體協(xié)同工作、自主組織。為實(shí)現(xiàn)這一目標(biāo)，AI 智能體領(lǐng)域已涌現(xiàn)出多種架構(gòu)模式。多個(gè)智能體組成實(shí)現(xiàn)的，也就是Multi-Agent，發(fā)展到現(xiàn)在有7種實(shí)現(xiàn)方式。

1. 工作流模式

在《Agentic Design Patterns》中叫Prompt Chaining，每個(gè)智能體都逐步地完成輸出，比如一個(gè)生成代碼，另一個(gè)審核代碼，第三個(gè)部署代碼。每一步的輸出作為下一步的輸入。這種信息傳遞建立了依賴鏈，前序操作的上下文和結(jié)果會(huì)引導(dǎo)后續(xù)處理，使 LLM 能夠在前一步基礎(chǔ)上不斷完善理解，逐步逼近目標(biāo)解。

他非常適合應(yīng)用在工作流自動(dòng)化、ETL和多步驟推理pipeline場(chǎng)景。

?

2. 路由模式

路由模式為智能體的操作框架引入了條件邏輯，使其從固定執(zhí)行路徑轉(zhuǎn)變?yōu)閯?dòng)態(tài)評(píng)估標(biāo)準(zhǔn)，從一組可能的后續(xù)動(dòng)作中進(jìn)行選擇的模式，從而實(shí)現(xiàn)一套更靈活，并且具備上下文感知的。一個(gè)控制器智能體將任務(wù)分配給合適的專業(yè)智能體，這是上下文感知智能體路由的基礎(chǔ)，正如在MCP、A2A框架中所看到的那樣。

路由模式的實(shí)現(xiàn)有四種：

?根據(jù)LLM路由，通過提示語言模型分析輸入，并輸出指示下一步或目標(biāo)的標(biāo)識(shí)符或指令。這里有顯式路由和隱式路由兩類，顯示直接使用智能體的結(jié)構(gòu)化輸出來確定將消息路由到哪個(gè)智能體。隱式路由是將下游智能體包裝成工具函數(shù)，這樣路由智能體就可以根據(jù)用戶查詢決定調(diào)用哪個(gè)工具。

""" 偽代碼示例 """
router = ReActAgent(
    name="Router",
    sys_prompt="#角色#你是一個(gè)路由智能體。你的目標(biāo)是將用戶查詢路由到正確的后續(xù)任務(wù)，注意你不需要回答用戶的問題。
                #任務(wù)#選擇正確的后續(xù)任務(wù)，如果任務(wù)太簡(jiǎn)單或沒有合適的任務(wù)，則選擇 ``None``",
    model=ChatModel(
        model_name="gpt-4",
        api_key="",
        stream=False,
    )
)

根據(jù)Embedding路由，利用嵌入能力，將查詢路由到最相似的路徑上，適用于語義路由，即決策基于輸入的含義而非關(guān)鍵詞。

     """ 偽代碼示例 """
     def __init__(self):
        # 使用輕量級(jí)的句子編碼模型
        self.model = ChatModel( model_name="gpt-4", api_key="", stream=False, )
        
        # 定義不同的路由能力和對(duì)應(yīng)的處理函數(shù)
        self.routes = {
            'code_help': {
                'description': '編程，代碼',
                'handler': self.handle_code_question
            },
            'general_chat': {
                'description': '聊天，日常對(duì)話',
                'handler': self.handle_general_chat
            }
        }
        
        # 預(yù)計(jì)算所有路由描述的嵌入向量
        self.route_embeddings = {}
        for route_name, route_info in self.routes.items():
            embedding = self.model.encode([route_info['description']])
            self.route_embeddings[route_name] = embedding
    
    def route_query(self, user_question):        
        # 1. 將用戶問題轉(zhuǎn)換為嵌入向量
        question_embedding = self.model.encode([user_question])
        
        # 2. 使用余弦計(jì)算與各個(gè)路由的相似度
        similarities = {}
        for route_name, route_embedding in self.route_embeddings.items():
            similarity = cosine_similarity(question_embedding, route_embedding)[0][0]
            similarities[route_name] = similarity
        
        # 3. 選擇相似度最高的路由
        best_route = max(similarities, key=similarities.get)
        best_score = similarities[best_route]
        
        # 4. 調(diào)用對(duì)應(yīng)的處理器
        handler = self.routes[best_route]['handler']
        response = handler(user_question)
        
        return {
            'route': best_route,
            'confidence': best_score,
            'response': response
        }
        ....

?根據(jù)定義規(guī)則路由，硬編碼方式，根據(jù)關(guān)鍵詞、模式或結(jié)構(gòu)化數(shù)據(jù)進(jìn)行路由。此方法比 LLM 路由更快、更確定，但靈活性較低。

?根據(jù)自訓(xùn)小模型路由，采用如分類器等判別模型，在小規(guī)模標(biāo)注數(shù)據(jù)集上專門訓(xùn)練以實(shí)現(xiàn)路由任務(wù)。與向量嵌入方法類似，但其特點(diǎn)是監(jiān)督微調(diào)過程，路由邏輯編碼在模型權(quán)重中。與 LLM 路由不同，決策組件不是推理時(shí)執(zhí)行提示的生成模型，而是已微調(diào)的判別模型。LLM 可用于生成合成訓(xùn)練數(shù)據(jù)，但不參與實(shí)時(shí)路由決策。

?

3. 并行模式

每個(gè)智能體負(fù)責(zé)處理不同的子任務(wù)，例如數(shù)據(jù)爬蟲、網(wǎng)絡(luò)檢索和摘要生成，它們的輸出會(huì)合并為一個(gè)單一結(jié)果。非常適合減少高吞吐量管道中的延遲。（如文檔解析或API編排）

4. 循環(huán)模式

智能體不斷優(yōu)化自身輸出，直到達(dá)到預(yù)期質(zhì)量。非常適合校對(duì)、報(bào)告生成或創(chuàng)意迭代，在這些場(chǎng)景中，系統(tǒng)會(huì)在確定最終結(jié)果前再次思考。反思就是在此模式上進(jìn)行的優(yōu)化。

?

5. 聚合模式

許多智能體生成部分結(jié)果，由主智能體將這些結(jié)果整合為一個(gè)最終輸出。因此，每個(gè)智能體都形成一個(gè)觀點(diǎn)，而一個(gè)Master智能體將這些觀點(diǎn)匯總成共識(shí)。在RAG的檢索融合、投票系統(tǒng)等場(chǎng)景中很常見。

?

6. 網(wǎng)絡(luò)模式

這里沒有明確的層級(jí)結(jié)構(gòu)，智能體之間可以自由交流，動(dòng)態(tài)共享上下文。用于模擬、多智能體游戲以及需要自由形式行為的集體推理系統(tǒng)中。

agentscope-samples

，模擬了9個(gè)智能體的狼人殺游戲。

?

7. 層級(jí)模式

一個(gè)頂級(jí)規(guī)劃智能體，將子任務(wù)分配給工作智能體，跟蹤它們的進(jìn)度，并做出最終決策。這和經(jīng)理及其團(tuán)隊(duì)的工作方式完全一樣（很多中間件的架構(gòu)也是類似這種模式如Redis、ES、Nocas）。意圖識(shí)別就是采用此模式。

?

小節(jié)：

我們一直在思考的一件事，不是哪種模式看起來最酷，而是哪種模式能最大限度地減少智能體之間的摩擦。啟動(dòng)10個(gè)智能體并稱之為一個(gè)團(tuán)隊(duì)很容易。難的是設(shè)計(jì)溝通流程，以確保：沒有兩個(gè)智能體會(huì)做重復(fù)工作。每個(gè)智能體都知道何時(shí)行動(dòng)何時(shí)等待，使這個(gè)系統(tǒng)作為一個(gè)整體，比其任何單個(gè)部分都更智能。為此我們遵循 building-effective-agents 設(shè)計(jì)。

?

三、Multi-Agent 框架

多智能體模式將人工智能工作流構(gòu)建為一個(gè)智能體團(tuán)隊(duì)，它們相互協(xié)作，每個(gè)智能體都有明確的角色。每個(gè)智能體能夠感知輸入、進(jìn)行推理（通過思維鏈）并執(zhí)行操作以完成子任務(wù)。每個(gè)智能體通常都配置有特定角色，并且只能訪問該角色所需的工具或信息。例如，PM AGent負(fù)責(zé)需求判斷是否需要其他智能體參與，若需要技術(shù)決策則聯(lián)動(dòng)Tech lead agent。智能體將循環(huán)進(jìn)行思考（“思考……”）和行動(dòng)（“行動(dòng)……”），直到完成其工作部分的任務(wù)。如下圖

以上簡(jiǎn)單介紹了多智能體的設(shè)計(jì)模式，那么當(dāng)下是不是已經(jīng)有了成熟的架構(gòu)供我們使用呢？答案是肯定的！

?

1.AutoGPT：Github 180k Star

2.Dify： Github 118k Star

3.AutoGen： Github 51.4k Star

4.CrewAI：Github 40.1k Star

5.LangGraph： Github 20.6k Star

為什么需要使用Agent框架？

只要“問題不可完全窮舉、要跨多系統(tǒng)查證、并且需要在對(duì)話中澄清、協(xié)商、決策”，就更應(yīng)該用 Agent 框架，而不是純 Workflow。

純 Workflow 的“天花板”

Workflow 在對(duì)話中的“澄清—再?zèng)Q策—再行動(dòng)” 并不天然友好，需要把每一步提問、回答、重試都畫成節(jié)點(diǎn)，復(fù)雜而脆弱。

場(chǎng)景：用戶發(fā)起：“我的包裹還沒到，怎么辦？”

通過Workflow創(chuàng)建如下智能體：(先不期待GPT-6 會(huì)自主思考的智能體)

?意圖識(shí)別智能體：識(shí)別用戶訴求（查詢進(jìn)度/催促/投訴/報(bào)損/退貨等）

?物流狀態(tài)智能體：實(shí)時(shí)拉取承運(yùn)商狀態(tài)，判斷包裹位置、異常

?政策規(guī)則智能體：查詢當(dāng)前時(shí)段政策（節(jié)假日、大促、平日），判斷是否特殊處理

?用戶畫像智能體：判斷用戶等級(jí)、歷史行為、是否會(huì)員

?異常檢測(cè)智能體：分析是否有報(bào)損、拒收、欺詐等信號(hào)

?澄清與補(bǔ)充智能體：信息不全時(shí)自動(dòng)向用戶提問，補(bǔ)齊決策所需信息

?解決方案生成智能體：綜合所有智能體結(jié)果，輸出最優(yōu)處理方案（比如：建議等待/補(bǔ)發(fā)/賠償/升級(jí)處理/轉(zhuǎn)人工等）

智能體數(shù)量??物流狀態(tài)??用戶等級(jí)??物流政策....你的分支會(huì)爆炸。所以需要用Dify這類的可以支持動(dòng)態(tài)決策，動(dòng)態(tài)推理和澄清的智能體框架。

?

Agent 框架解決的核心問題

以 AutoGen、CrewAI 這類 Agent 框架為例，它們把“在對(duì)話里動(dòng)態(tài)規(guī)劃與調(diào)用工具”作為第一性能力：

場(chǎng)景：用戶說“我10.1買的手機(jī)現(xiàn)在還沒到，給我退貨！另外，你們的運(yùn)費(fèi)險(xiǎn)的保賬期是多久？”

一個(gè)合格的客服 Agent 團(tuán)隊(duì)會(huì)做什么？

沒有路由決策，首先會(huì)動(dòng)態(tài)匹配所有Query，對(duì)Query進(jìn)行改寫成“查詢用戶的訂單”，“用戶想要退貨”，“運(yùn)費(fèi)險(xiǎn)的保賬范圍和條款”。

1.意圖識(shí)別 + 澄清

? Planner Agent：拆出多意圖（物流異常、退貨、計(jì)費(fèi)異常、運(yùn)費(fèi)險(xiǎn)條款），先問關(guān)鍵（訂單號(hào)、地址）。

2.跨系統(tǒng)取證

? OMS/物流工具：查軌跡與 SLA；

? 計(jì)費(fèi)/支付工具：核對(duì)重復(fù)扣款交易；

? CRM：看是否 Plus、是否有歷史補(bǔ)償記錄；

?保庫：查詢運(yùn)費(fèi)險(xiǎn)

3.政策推理與合規(guī)

Policy Agent：套用“假期延誤 + Plus + 運(yùn)費(fèi)險(xiǎn)”的組合條款，評(píng)估可給的補(bǔ)償區(qū)間、是否觸發(fā)風(fēng)控人工復(fù)核。

這些動(dòng)作里，很多步驟無法事先“畫”成固定分支，需要在對(duì)話上下文里做決策、需要跨工具動(dòng)態(tài)組合、需要“問一句 → 查一下 → 再?zèng)Q定”，這正是 Agent 的強(qiáng)項(xiàng)。

?

結(jié)尾：

以上是對(duì)多智能體的總結(jié)，你會(huì)了嗎？

審核編輯 黃宇