多數代理框架給你的是一座程式庫，怎麼用自己想辦法。這一個是帶著方法論來的：首頁把它定位成企業級代理的建置與執行層，並列兩件事——業務團隊與工程團隊都能建，而平台團隊能從同一個地方治理。下面那句自我概括更直白：企業內部堆著的代理想法，靠同一個能集中治理的平台清掉。

四段流程：發現、建置、治理、優化

Discover 回答「該自動化什麼」：把數十億次代理執行中觀察到的模式，對上你的工單、聊天、應用與流程，輸出一份按投入、價值與就緒度排序的機會清單，還附一份可分享的示範，幫團隊對齊順序。Build 回答「怎麼搭」：無程式碼的視覺化編輯器可以匯出成 Python，另有追求完全掌控的程式碼優先介面、以角色分工的代理編排，以及確定性的工作流程；官方說這套引導來自 70 萬個代理工作流的模式。Govern 回答「怎麼管住」：控制面站在每一條工作流的執行路徑上，即時追蹤每一次模型呼叫、工具呼叫與記憶讀取並核算成本，另外提供角色權限與只可追加的稽核紀錄、企業級身分管理、人工審批卡點，以及執行時期的敏感資訊遮蔽與政策檢查。Optimize 回答「怎麼越跑越好」：把每一次生產執行轉成訓練資料，提供自動與人工引導的訓練、執行時期的多模型切換測試，評測則接上外部的評分服務。

每個案例都帶一個數字

客戶案例區的寫法是「場景加指標」，至少對自己在量什麼很坦白。一家食品外送平台用它豐富潛在客戶資料，每月三千餘筆。一家教育機構拿它做課程設計，開發時間少了九成。一家電子簽名廠商把多個內部系統的線索資料整合起來，首次觸達快了七成五。一個客服場景的回覆準確率達到九成五。還有一家餐飲點單服務用自動化語音測試，把品管檢查從 74 小時壓到 3 小時。官網另外聲稱財富 500 強中有 65% 的企業在用——這種比例通常取決於客戶怎麼算，值得記一筆，也值得回到自己的場景裡驗一次。

真正的骨架：代理、流程、任務

官方說明（目前版本 v1.15.22）把入門內容編成三塊。代理是可組合工具、記憶、知識與結構化輸出的執行單元。流程負責編排啟動、監聽與路由步驟，管理狀態、持久化執行，並讓長任務從中斷處續跑。任務與流程模式定義順序、階層與混合三種跑法，並帶護欄、回呼與人工介入的觸發點。換句話說，代理決定「誰來做」，流程與任務決定「用什麼順序做、出錯怎麼辦」。觸發器那一節把事件驅動補齊：可以接上郵件、團隊聊天與客戶關係系統，觸發載荷會自動傳進 crew 與 flow。企業側另有部署自動化、環境管理、邀請同事與角色權限控制。安裝很輕：一個命令列工具加一組介面金鑰就能起步，新建專案會長出以 JSON 為先的骨架，代理定義與 crew 層級設定分檔管理，也留了經典結構給偏好它的人。

適合誰用

三種團隊比較合。需要多個專職角色合作跑長鏈任務的工程團隊——研究員、寫手、審核員這種分工，crew 的抽象天生對得上。要在企業內部合規落地的平台團隊——治理、稽核、審批與遮蔽都做成了產品能力，而不是自研補丁。以及想先在本地跑、之後再決定要不要上控制面的開發者——框架本體是 MIT，儲存庫約 58.7k 星、8.5k 次分支，說明文件聲稱已有超過十萬名開發者透過社群課程取得認證。

兩件事要說在前面。「發現」與「優化」都吃平台規模累積的資料，個人開發者的用量看不出它們的價值。而多代理天生比單次呼叫更耗 token——編排之前先想清楚，哪幾個步驟真的需要一個獨立角色。

多代理框架真正的考驗，不是五個代理能不能都開口，而是它們第七次互相等待時，你有沒有一個地方可以看到卡在哪裡。