這是多代理浪潮裡資歷偏老的一個，在一家大型軟體廠商的研究院裡做出來，也是最早把「一群代理互相對話、直到把事情做完」這套範式搬上檯面的專案之一。不過它的現況有個前提得先講清楚：專案已進入維護模式，不再接收新功能，改由社群管理。所以這篇評測分兩半——先說它是什麼、怎麼用，再說現在該不該選它。

四塊拼圖，按深度切開

官方說明把專案切成四塊，每塊都有獨立入口。Studio 是網頁介面，不寫程式就能把代理雛型搭出來：裝一個套件、跑一條指令、指定連接埠與工作目錄就能開；它建在對話層之上，被定位成新使用者的第一站，同時也被提醒適合快速驗證想法，離生產應用還有一段距離。對話層是要寫程式的那一層，面向以會話為中心的單代理與多代理應用，要求 Python 3.10 以上，範例程式十幾行——建一個助理代理、把模型客戶端遞給它、跑一條任務，印回來。核心更靠下，是事件驅動的程式框架，面向業務流程裡確定性的工作流、多代理協作研究，以及跨語言的分散式代理。擴充套件負責把外面的世界接進來：對接模型上下文協定伺服器的元件、對接助理介面的代理、在容器裡執行模型產生程式碼的執行器，以及分散式代理執行環境。

從對話到群聊：編排模式

對話層的說明主線依序是模型、訊息、代理、團隊、人工介入、終止條件與狀態管理。這個順序本身就是一種表態：它假設你要做的是一件會持續跑下去的協作任務，所以終止條件與狀態管理各自成章，而不是當成邊角料。再往進階看，編排模式給的選項不少。選擇器群聊用一個集中、可自訂的選擇器決定下一個發言者，靠共享上下文協調；蜂群把選擇權下放，用在地化的工具選擇器讓代理之間直接交接；圖工作流換成有向圖來組織多代理流程，適合流程邊界清楚的場景。旁邊還擺著記憶與檢索增強、日誌、元件序列化、追蹤與觀測這些工程配套，以及由對話層與擴充套件搭出來的官方範例團隊——它被設計來處理網頁瀏覽、程式執行與檔案處理這類組合任務。想省事就先進 Studio 搭個雛型，想控細節就落到核心那一層自己寫事件迴圈。

維護模式這件事，比功能更該先知道

儲存庫首頁頂端的提示寫得很直白：專案已進入維護模式，不再接收新功能與增強，改由社群管理；新使用者應從官方指定的繼任專案起步，現有使用者有遷移指南可循。同一段說明指出，繼任專案是企業級的接班者，已提供生產就緒版本，具備穩定介面與長期支援承諾，涵蓋單一助理到代理叢集兩類場景，提供企業級多代理編排、多家模型供應商支援，並可透過兩套新興的代理協定實現跨執行環境互通。貢獻指引也同步收窄：目前只收缺陷修復、安全補丁與說明改進，新功能開發被引導到繼任專案去。

三層結構本身仍然清楚。核心負責訊息傳遞、事件驅動代理，以及本地與分散式執行環境，並支援 Python 與 C# 兩種語言；對話層在核心之上提供相對簡單但帶主張的介面，覆蓋雙代理對話與群聊這些常見樣式；擴充套件提供模型客戶端與程式執行等能力。配套工具是無程式碼的 Studio 與一套基準測試套件。授權走雙軌：程式碼以 MIT 發布，說明文件以知識共享署名授權發布。儲存庫數字約為 61k 顆星、9.2k 次分支、98 個發布、556 位貢獻者，被 4.3K 個專案使用，語言以 Python 為主，另有 C# 與 TypeScript。

適合誰用

三種人還適合繼續用。已有存量專案的團隊：程式在跑、模型在調，維護模式下缺陷與安全補丁照舊，遷移可以按自己的節奏安排，不必為了追新而重寫。想研究多代理協作範式的開發者：選擇器群聊、蜂群、圖工作流這三套模式各有清楚取捨，配上基準測試套件，拿來做對照實驗很合適，而且說明與範例都留在原地。以及只想快速驗證一個多代理想法的人：Studio 裝完就能拖，比從零搭編排省事得多。

反過來，有兩種情況建議直接看繼任專案。一是新立案的生產系統，尤其是需要長期支援承諾的場景——它已經明確不再加功能，把新架構放進一個凍結的框架，後續只能靠社群。二是需要企業級編排、多家模型供應商切換與跨執行環境互通的團隊，這些能力官方已經明確放到繼任專案裡。簡單說，它現在的定位是一份好用的存量資產與教學素材，而不是面向未來的起點。

選框架這件事，功能清單只是入場券；真正的分水嶺是三年後你還在不在它的支援範圍裡。