MetaGPT 與 DeepWisdom：把整個軟體公司的 SOP 裝進 AI
AI 系列-深入介紹 DeepWisdom 創辦人吳成林與 MetaGPT，從騰訊最年輕高級研究員到打造「第一個 AI 軟體公司」——用 SOP 驅動 PM、架構師、工程師、QA 五個 Agent 協作，一句需求生出完整產品。
WRITTEN BY
- Name
- Harry Chang
你給一句話：「幫我做一個線上訂餐系統。」
接下來發生的不是一個 AI 開始寫程式，而是一整個虛擬公司啟動：
產品經理拿到需求，寫出 PRD。架構師讀完 PRD，畫出系統設計。專案經理把設計拆成任務清單。工程師照任務寫程式碼。QA 工程師寫測試，發現 Bug，工程師修正……
最後你收到的，是一個完整的 codebase、測試報告、架構文件。
這就是 MetaGPT 的設計哲學：不是讓一個 AI 更聰明，而是讓五個 AI 各司其職——就像一家真實的軟體公司。
- 為什麼你需要認識 DeepWisdom？
- 吳成林是誰？騰訊最年輕高級研究員的創業轉折
- MetaGPT 的核心哲學：SOP 即程式碼
- 五個角色，五道工序
- 共享訊息池：Agent 之間的「公告欄」
- 五角色 SOP 流水線架構圖
- MetaGPT → MGX → Atoms：商業化三部曲
- MetaGPT vs GPT-Engineer vs CrewAI
- 實用建議：三個起步行動
- 我的反思
- 參考資料 (References)
為什麼你需要認識 DeepWisdom？
在這個系列裡，我們已經看過兩種「AI 生軟體」的路線：
- GPT-Engineer（Anton Osika）：一個 AI，先問清楚需求，然後生成整個 codebase
- OpenHands（All Hands AI）：一個 AI，住在 Docker 裡，自主解決 GitHub Issue
DeepWisdom 的答案走了完全不同的第三條路：
把一家軟體公司的組織架構和標準作業流程（SOP），直接編碼進多 Agent 的協作邏輯。
當其他框架還在問「這個 AI 能做什麼工具呼叫」，MetaGPT 問的是：「一家好的軟體公司，是怎麼把一句需求變成一個可交付的產品？」
吳成林是誰？騰訊最年輕高級研究員的創業轉折
從騰訊到 DeepWisdom
吳成林（Chenglin Wu）的職涯起點，是中國科技產業的核心地帶。
他曾是騰訊最年輕的 T3.3 高級研究員，主導設計了大規模推薦系統（信息流）、搜尋引擎、知識圖譜與自然語言理解等核心專案——這些系統服務了超過 10 億用戶、處理了超過千億筆數據。
他在 KDD 2018 發表論文，在騰訊獲得「雙五星」榮譽（500 人中僅 1 人），也曾在華為 2012 實驗室工作，並擔任 Bumblebird Social 的首席科學家。
2018、2019 年，他連續入選 Forbes China 30 Under 30 與 胡潤 30x30 創業領袖。
2019 年，吳成林創辦 DeepWisdom，目標明確：用 AI 讓企業真正能夠「以一當十」。
MetaGPT 的起點：SOPs 是軟體工程的精髓
吳成林在騰訊待了多年，深刻理解一件事：一家好的軟體公司能把複雜需求變成可交付產品，靠的不是哪個天才工程師，而是一套被反覆驗證的協作流程。
PRD 怎麼寫、架構評審怎麼過、任務怎麼拆、Code Review 怎麼做——這些「標準作業程序（SOP）」，才是軟體工程組織真正的核心資產。
他的洞見是：如果 LLM 已經夠聰明，那麼真正的瓶頸不是模型能力，而是多個 Agent 之間的協作方式。而最好的協作方式，人類已經用了幾十年——那就是 SOP。
2023 年 6 月，MetaGPT 開源發布。
MetaGPT 的核心哲學：SOP 即程式碼
為什麼 SOP 如此重要？
傳統的多 Agent 框架（包括 CrewAI）讓 Agent 之間用「自然語言對話」協作。這很靈活，但問題是：自然語言充滿了歧義，Agent 很容易在一來一回中跑偏、重複、甚至互相矛盾。
MetaGPT 的解法是把對話結構化：每個 Agent 的輸出，都必須符合預定義的格式——PRD 就是 PRD，架構圖就是架構圖，任務清單就是任務清單。
下一個 Agent 拿到的，不是一段模糊的文字，而是一份可以直接執行的標準文件。
# MetaGPT 角色定義範例
from metagpt.roles import ProductManager, Architect, ProjectManager, Engineer, QAEngineer
from metagpt.team import Team
async def startup(idea: str):
company = Team()
company.hire([
ProductManager(), # 需求分析 → PRD
Architect(), # PRD → 系統設計
ProjectManager(), # 設計 → 任務清單
Engineer(n_borg=5), # 任務 → 程式碼（可並行）
QAEngineer(), # 程式碼 → 測試
])
company.invest(investment=3.0) # Token 預算（美元）
company.run_project(idea)
await company.run()
一句話啟動整個虛擬公司。 這段程式碼不是示意——它可以真實執行。
五個角色，五道工序
MetaGPT 的 SOP 流水線包含五個緊密銜接的環節：
第一道：Product Manager → PRD
輸入：「做一個線上訂餐系統」
輸出（結構化 PRD）：
- 用戶故事（User Stories）
- 需求池（Requirement Pool）
- 競品分析（Competitive Quadrant）
- 成功指標（KPIs）
第二道：Architect → 系統設計
輸入：PRD
輸出（技術規格）：
- 檔案結構清單（File List）
- 資料結構定義（Data Structures）
- API 介面定義（Interface Definitions）
- 系統架構圖（Architecture Diagram）
第三道：Project Manager → 任務清單
輸入：系統設計
輸出（執行計畫）：
- 任務分解（Task Breakdown）
- 各任務依賴關係
- 指派給對應 Engineer
第四道：Engineer → 程式碼
輸入：任務清單 + 系統設計
輸出：
- 完整的程式碼實作
- 執行結果（自動跑並檢查錯誤）
- 若有 Bug → 對照 PRD 與設計文件自我修正
第五道：QA Engineer → 測試
輸入：程式碼 + 需求
輸出：
- 測試案例（Test Cases）
- 測試執行結果
- Bug 報告（回饋給 Engineer 修正）
共享訊息池：Agent 之間的「公告欄」
MetaGPT 的通訊機制設計得非常優雅：所有 Agent 共享一個訊息池（Message Pool），每個 Agent 把自己的輸出發布到池子裡，下游 Agent 自行訂閱並讀取需要的內容。
這個設計避免了「一對一傳話容易失真」的問題——任何 Agent 都可以回頭查閱完整的上下文，而不只是自己被直接傳到的那一份資訊。
五角色 SOP 流水線架構圖
MetaGPT → MGX → Atoms：商業化三部曲
MetaGPT 的開源成功，讓吳成林看到了更大的市場機會。
| 版本 | 時間 | 定位 |
|---|---|---|
| MetaGPT（開源） | 2023 年 6 月 | 框架，給開發者用 |
| MGX（MetaGPT-X） | 2025 年 2 月 | 商業產品，Vibe Coding 平台 |
| Atoms | 2026 年 1 月 | 企業部署，商業應用導向 |
MGX 的成績：
- 上線一個月：50 萬註冊用戶
- 不靠付費行銷，達到 $100 萬 ARR
- 2025 年 9 月：月訪問量 120 萬次，每日生成 App 超過 10,000 個
融資里程碑：
2025 年上半年，DeepWisdom 完成兩輪融資，投資方包含：
- 螞蟻集團（Ant Group）
- 凱輝基金（Cathay Capital）
- 錦秋基金（Jinqiu Fund）
- 百度風投（BV Baidu Ventures）
- 概念基金（Concept Fund）
合計約 2.2 億人民幣（約 3,000 萬美元）。
MetaGPT vs GPT-Engineer vs CrewAI
三個框架都用了「角色」的概念，但出發點完全不同：
| 面向 | CrewAI | GPT-Engineer | MetaGPT |
|---|---|---|---|
| 角色設計目的 | 任意任務協作 | 無角色，單一 Agent | 軟體公司 SOP |
| 通訊方式 | 自然語言對話 | 單一 Agent | 結構化文件傳遞 |
| 輸出物 | 任意格式 | 完整 Codebase | PRD + 設計 + 程式碼 + 測試 |
| Git 整合 | ❌ | ❌ | ❌ |
| 適合場景 | 一般自動化任務 | 快速生成新專案 | 完整軟體開發流程 |
| 學術背書 | ❌ | ❌ | ICLR 2024 Oral |
| GitHub Stars | ~50K | ~52K | ~58K |
簡單記：CrewAI 是角色扮演，GPT-Engineer 是一鍵生成，MetaGPT 是流程工程化。
實用建議：三個起步行動
步驟 1：把需求寫成一句完整的產品描述
MetaGPT 的 PM Agent 擅長把「模糊需求」轉成具體 PRD，但你的起點越清楚，整個流水線的品質越高。試著用這個格式：「做一個給 [目標用戶] 使用的 [產品類型]，核心功能是 [1-3 個主要功能]。」
步驟 2：用 investment 參數控制成本
company.invest(investment=3.0) # 最多花 $3 美元的 Token
MetaGPT 的完整流水線 Token 消耗不小，從小預算開始，確認輸出方向對了再加大。
步驟 3：先讀 PRD，再看程式碼
MetaGPT 生成的 PRD 和架構文件，本身就很有參考價值。即使你最後不用它生成的程式碼，讀一遍 AI 怎麼詮釋你的需求、怎麼設計系統，對釐清自己的想法非常有幫助。
我的反思
讀完吳成林和 MetaGPT 的故事，我最深刻的感受是：他是這個系列裡，背景最「工業規模」的創辦人。
Andrew Ng 來自學術界，Harrison Chase 來自 ML 新創，Peter Steinberger 來自 B2B SDK。吳成林來自騰訊——一家真正以幾十億用戶規模運作軟體產品的地方。
在那種規模下工作，你會深刻理解：讓一個天才工程師加班，解決不了系統性問題。讓一套好的 SOP 跑起來，才能讓整個組織可預測、可複製、可擴展。
MetaGPT 的設計，就是這個認知的直接延伸：最有效的 AI 協作，不是讓 AI 更聰明，而是讓 AI 遵循一套被驗證過的人類工作流程。
這讓我想到一個對比——CrewAI 的 João Moura 說：「給 AI 一個角色。」MetaGPT 的吳成林說：「給 AI 一套流程。」
角色是靜態的身份，流程是動態的行為規範。有了流程，角色才能真正地協作，而不只是表演。
回到這個系列的脈絡：Andrew Ng 定義框架、Harrison Chase 工程化、João Moura 角色化、Anton Osika 民主化——而吳成林的貢獻是：
把幾十年的軟體工程組織智慧，壓縮進一個 Multi-Agent 的協作協議。
這不只是一個 AI 工具，而是一次對「如何大規模複製軟體工程能力」的嘗試。
參考資料 (References)
官方資源
延伸閱讀