今天早上，OpenAI實施團隊的 @shyamal在Github上開源了Swarm這個OpenAI官方的多智慧體框架。不得不說，OpenAI官方下場，獲得的社群影響就是不一樣，在微信群、朋友圈裡已經出現大量的解析文章。
這個多智慧體框架確實已經把多智慧體的關鍵，說的很透徹了，Swarm 裡面定義了兩個核心「Agents」和「Handoffs」，多智慧體的核心是在這個Handoffs上面。簡單看了下examples 之後我覺得這個多智慧體框架並不夠好，恰巧的是，我對雲原生技術很熟，借用一下雲原生的發展歷程，給這個[Swarn]框架做個簡要點評：從雲原生容器發展的歷史來看，相當於docker swarm 和 k8s， 我們需要的智慧體框架應該是k8s 這樣的一個框架，如果你是一位雲原生技術熟悉的同學很容易就知道我在說什麼了。
單Agent這塊，簡單封裝提示詞和使用函式呼叫就可以完成業務，OpenAI就一個 /api/chatcompletions 介面就幫我們搞定了，市場上大量的Agent 產品都停留在單Agent 上，但是「Handoffs」這塊，Swarm的確做的非常優雅了。
個人觀點認為他的設計還沒有我們的多智慧體框架好用，OpenAI的[Swarm]是docker swarm，我們的多智慧體框架就是k8s，我需要的是像k8s編排容器那樣編排智慧體，我們剛剛在9月26日對外發布了多智慧體的工業設計產品，詳見：智用研究院AI Agent Foundry賦能的首個多Agent驅動的工業設計平臺圓滿釋出。
多智慧體的核心難題其是不同智慧體之間的通訊問題。怎麼傳遞資訊，傳哪些資訊，這些都很重要。多個智慧體協作，也只需要在必要的時候被呼叫起來就可以了。看我們智慧體協作圖：
當我們多智慧體應用接收到使用者的請求，借用Semantic kernel的設計理念叫實現“目標導向”的AI應用，這意味著它能夠幫助確定目標，然後尋找實現這些目標的方法和步驟。在“目標導向”的方法中，首先需要確定目標，然後透過規劃器（Planner）將目標分解為一系列需要執行的任務。這些任務可以逐個執行，以實現最終目標。這個過程對於人類來說是很自然的，但對於機器來說則相對複雜。藉助LLM AI的力量，我們可以更輕鬆地實現這一過程。
這個接收到使用者請求的智慧體我們叫做路由智慧體，他負責路由到具體執行任務的任務智慧體。我們的智慧體框架的Planner 也是類似於OpenAI的Swarm的「Handoffs」處理了交接的邏輯，我們的Planner 要比Handoffs處理的更完美。OpenAI的Swarm 目前還處於實驗階段，期望他發展成為k8s 這樣的一個多智慧體編排框架：
這個框架是python寫的，大家覺得用python 寫多智慧體應用是好選擇嗎？ 我個人認為做應用開發，Python並不是好選擇，Python之所以用的多，是因為這一波人工智慧的主導者是演算法工程師，他們習慣用的程式語言是Python罷了，隨著複雜場景的人工智慧應用需求的增加，控制權逐步要回歸到應用開發者的手中，對於複雜度高、需要長期維護的應用系統還是需要用c# 、java等業務系統開發類的程式語言來主導。
