Make It Heavy：把問題交給多個 AI 智能體同時分析再整合答案

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Make It Heavy 是一個用 Python 寫的開源指令列框架。你把一個問題丟進去，它會先把問題拆成數個子問題，分派給多個 AI 智能體（agent）同時處理，最後再把各自的結果合成一份整合過的答案。整個過程跑在終端機裡，背後透過 OpenRouter 這個模型 API 聚合服務來呼叫你指定的語言模型。

這篇文章的基礎，是我把專案的 GitHub 原始碼、授權條款全文、以及完整提交紀錄都讀過一遍，並沒有實際安裝執行。所以下面講的是這個框架在設計上做什麼，以及它的原始碼透露出哪些會影響你判斷的事實，而不是跑起來之後的效能或穩定度評測。如果你要的是實測結果，這篇給不了。

一個查詢在框架裡怎麼走完一圈

從原始碼看，整個流程分四個步驟。你輸入一段問題之後，框架先呼叫一個模型產生幾條不同角度的子問題，預設是四條，例如問「某人是誰」，它會自動拆成職業背景、技術貢獻、影響力分析、事實查核這類各自獨立的研究方向。接著框架用 Python 的執行緒池（ThreadPoolExecutor）把這幾條子問題丟給各自獨立的 agent 平行處理，每個 agent 都能呼叫同一套工具。等全部跑完，再交給一個合成步驟，把多個視角的答案整合成一份最終回應。

幾個從原始碼能確認的設計細節值得知道。平行 agent 的數量不是寫死的，你在 config.yaml 裡的 parallel_agents 改數字就能調，README 也提醒要把數量配合你的 OpenRouter 用量上限。每個 agent 最多迭代十次（agent.max_iterations 預設值），每一次迭代都可以呼叫工具，所以實際發出的 API 請求遠不止「四個 agent 等於四次呼叫」這麼單純。工具系統是熱插拔的，你只要在 tools/ 目錄放一個繼承 BaseTool 的 Python 檔，框架就會自動載入，內建的工具包含用 DuckDuckGo 做網頁搜尋、數學計算、讀寫本機檔案、以及標記任務完成。

如果問題拆解那一步失敗了（例如模型回傳的不是合法 JSON），框架有內建的退 fallback，會直接用幾條固定的制式子問題頂上去，不會整個流程掛掉。這點從 orchestrator.py 的例外處理可以確認。

config.yaml 還透露了一個重要的客製化空間：問題拆解的提示詞（question_generation_prompt）和最後合成的提示詞（synthesis_prompt）都是寫在設定檔裡的，不是寫死在程式碼。這表示你可以改變框架「怎麼拆問題」和「怎麼整合答案」這兩個最影響成果的步驟。另外還有一個 aggregation_strategy 設定，預設值是 consensus，名稱暗示它走的是讓多個 agent 的視角往共識方向收攏的策略。這些都是你不執行程式也能從設定檔直接讀到、拿來判斷這個框架彈性的依據。

框架提供兩種跑法。uv run main.py 是單一 agent 模式，就是一般的問答加上工具呼叫，適合簡單任務。uv run make_it_heavy.py 才是多 agent 編排模式，也是這個專案主打的重點。兩種模式共用同一套工具和同一個 agent 實作，差別只在於有沒有外掛那層問題拆解和平行整合的邏輯。

官方提供的架構示意

README 裡畫了一張流程圖，把上述步驟視覺化成：使用者輸入進到問題產生器，產出四條研究子問題，分別對應研究、分析、替代視角、查核四個 agent，四個 agent 平行跑完之後，全部匯進一個合成器，輸出最終答案。README 還給了一個具體例子：問「Pietro Schirano 是誰」，系統會自動產出職業背景、技術貢獻、替代視角、身分查核四條子問題，再各自交給一個 agent 去研究。

這張圖和這個例子證明的是編排模式真的存在於專案裡，也就是框架確實會做拆解、平行、合成這三件事。但有幾件事是只看原始碼和文件無法證明的。輸出品質就是其一：多 agent 平行跑出來的答案有沒有比單一模型直接回答更好、合成結果會不會互相矛盾，這些只有實際跑了才知道。穩定度也一樣：框架面對模型逾時、API 限流、回傳格式異常這些狀況時的容錯表現，README 裡的故障排除段只列了幾個常見錯誤的制式解法，不代表它在各種邊界情境都能撐住。至於和競品的比較，它能不能做出比 AutoGen 或 CrewAI 更好的分析，目前沒有任何對稱的測試基準可以佐證，README 本身也沒有做這類宣稱。

跑一次要花多少 API 用量

這是很多人最該先算清楚的一點。框架的運作邏輯決定了它的 token 消耗是單次問答的好幾倍。以預設四個 agent 為例，每一次「heavy 模式」查詢至少會產生：一次問題拆解呼叫、四次 agent 執行、一次合成，加起來最少六次模型呼叫。而且每個 agent 在迭代過程中還會帶著工具呼叫的結果繼續對話，實際次數只會更多。

你用的是自己的 OpenRouter API key，費用直接算到你帳上。模型可以在設定檔裡換，實際 config.yaml 的出廠預設是 moonshotai/kimi-k2（Moonshot AI 的 Kimi K2），你也可以換成其他 OpenRouter 支援的模型。值得留意的是工具清單裡的網頁搜尋用的是 DuckDuckGo（透過 ddgs 套件），這層不用另外申請 key，所以 agent 做搜尋這件事本身不會產生額外費用。真正吃 token 的是每一次模型呼叫，而多 agent 編排的本質就是把一次問答放大成好幾倍的模型用量。

這種「自己填 key、自己挑模型、自己吸收成本」的做法和不少開源 AI 工具的思路一致，例如同樣走 BYOK 模式的 開源 RSS 聚合平台 rss-aigc 也是把模型選擇權與帳單責任一起交還給使用者。好處是你對資料流向和成本有完全的掌控，代價是你得自己盯著用量，而且你丟進去的問題內容會經過 OpenRouter 傳到你所選的模型供應商，不會只停在你本機。如果你對 OpenRouter 這類模型聚合閘道不熟，可以先理解成它是一個讓你用同一個介面呼叫上百種模型的代理層，概念上和 OmniRoute 這類 AI 閘道工具 是同一類服務。

整個框架其實很小

從依賴清單和檔案結構可以看出這個專案的輕量程度。requirements.txt 只列了五個套件：用來呼叫模型 API 的 openai、用來抓網頁的 requests 與 beautifulsoup4、用來讀設定檔的 pyyaml、以及 DuckDuckGo 搜尋用的 ddgs。整個框架的核心是 main.py（單一 agent 模式）、make_it_heavy.py（多 agent 模式）、agent.py（單一 agent 實作）、orchestrator.py（多 agent 編排邏輯），外加一個放工具的 tools/ 目錄，合計大約七百行 Python。

Pin

這個規模的好處是很容易讀懂，一個下午就能把整個編排邏輯看完，當作學習「多智能體協作」這個模式的入門教材非常合適。但也正因為精簡，它稱不上那種經過大量實戰考驗、有完整抽象層的生產級框架。

如果你要的是成熟的多智能體開發平台，業界已經有幾個定位完全不同的選擇。微軟的 AutoGen 提供對話式多智能體協作和事件驅動的工作流程；CrewAI 走角色分工路線，讓你定義不同身分的 agent 和彼此的先後順序；LangGraph 則把 agent 流程模型化成可分支、可循環的狀態圖，支援記憶、檢查點和中斷後接續。這三個框架都有狀態管理、錯誤重試、可觀測性這類生產環境會用到的基礎設施。Make It Heavy 沒有這些。它的定位是一個把「拆問題、平行跑、再合成」這個核心想法濃縮到最少程式碼的展示專案，讓你一眼就看懂整個編排在幹嘛。它無意取代上述任何一個框架。把它的層級放在「可讀的教學範本」而非「可組裝的積木庫」，你對它的評價就會準確很多。

授權條款不是標準的 MIT

專案的 LICENSE 檔案標題寫的是「MIT License with Attribution Requirement for Large-Scale Commercial Use」。以 MIT 為底，但多了一條額外條款：如果你的產品或服務使用者超過十萬人，就必須在文件或關於頁面之類看得到的地方，標註原作者 Pietro Schirano 的名字以及使用 Make It Heavy 框架的說明。

這條附加條款讓 GitHub 自動偵測把它的授權分類標成 NOASSERTION，也就是非標準 SPDX 認證。對絕大多數個人研究和中小型專案來說影響不大，但如果你打算把它整合進大型商業產品，這個出處標示義務要先放進考量。要強調的是，多數人看到 repo 會直覺喊「MIT 開源」，但親自查過 LICENSE 全文才會發現這個差異。

專案爆紅之後就停住了

從 GitHub 的提交紀錄來看，整個專案的全部五次提交集中在 2025 年 7 月 15 日到 16 日，大約十八小時之內。最後一次提交的訊息是更新 README。到現在為止，專案沒有任何一次正式發布（release），沒有測試檔案，也沒有貢獻者指南之外的開發活動。目前 repo 累積了超過一千一百個 star、一百八十幾個 fork，同時掛著八個未關閉的 issue 沒有人處理。高關注度和高 fork 數說明了這個想法打中了很多人，但不等於有人在持續維護。

Pin

這是一個典型的「週末原型爆紅然後停滯」的軌跡。對你的決策影響是：別期待這個專案會修你遇到的問題、別期待它會跟上 OpenRouter 或模型 API 的介面變動、也別把產品線綁在一個已經一年多沒動的相依套件上。把它當作一份可讀的參考實作來研究是合理的，當作長期依賴的基礎建設就不太負責任。這也是為什麼前面一直強調它的價值在於示範那個編排模式。

自己花十分鐘就能驗證的事

如果你讀到這裡還在猶豫要不要裝來用，有一個幾乎不用成本的核對動作。直接打開 repo 看 orchestrator.py 的 decompose_task、run_agent_parallel、aggregate_results 這三個函式，對照 config.yaml 裡的提示詞和迭代次數設定，再看一下 commit 歷史的分佈。十分鐘之內你就能自己判斷兩件事：這個編排模式是不是你想要的那種、以及這個專案的維護狀態你能不能接受。

如果看完覺得這個模式值得用，但這個 repo 不值得依賴，最務實的做法是把它的編排邏輯當範本，用自己的程式碼重新實作一份符合你需求的版本，畢竟核心邏輯就那麼幾百行。如果你只是想理解「多智能體平行分析」到底是怎麼運作的，這個 repo 已經足夠讓你看懂整件事。若你想進一步比較同類的 AI 智能體工具，可以參考我們介紹過的 OpenWork 桌面 AI 智能體 或 Vibe Kanban AI 程式開發智能體，看看不同形態的 agent 工具各自適合什麼場景。

總結一句：Make It Heavy 示範了一個用極少程式碼就能做到多智能體平行分析的清楚範本，它的價值是可讀、可學。把它當作理解編排邏輯的教材來讀，收穫會最多；至於長期維護和生產環境的信賴度，前面提過的停滯狀態與授權附加條款已經說明了它的限制。如果你要的是有人持續維護、有效果保證的方案，業界現成的框架會是更穩的選擇。