MultiAgentPPT 開源簡報產生器，多個 Agent 把報告接力寫完

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

2025 年開始，用 AI 生簡報的工具爆量，做法卻大致分兩派。一派把整份需求塞給一個模型，一口氣吐出整份投影片；另一派把工作拆開，讓多個專職的 Agent 分工，有人出大綱、有人查資料、有人逐頁寫稿、有人專門挑錯。前者的產品很多，後者幾乎都是閉源雲端服務，開放原始碼又拆得完整的範例非常少。MultiAgentPPT 補上了這個位置：它是開發者 johnson7788 在 2025 年 6 月開源的簡報生成系統，MIT 授權，以 Google 的 ADK 為骨架，把一場簡報的生成拆成一條多角色生產線，到 2026 年 9 月在 GitHub 累積一千六百多顆星、兩百多次 fork，對一個個人專案來說是相當高的關注度。

先講我的判斷，因為它決定你接下來要往哪條路走。這個專案最大的價值並不是它生出來的簡報，而是那條生產線本身。我把倉庫整包抓下來讀過一遍，看到的是一份少見的多 Agent 編排實作教材，同時也是一個離「開箱即用」還有段距離的半成品：它出廠示範跑的是寫死的電動車資料，功能最完整的版本在現行原始碼裡還帶著一個沒人修的啟動錯誤，整套跑起來要前端加四個後端模組加一個轉檔服務加資料庫，作者本人更早在 2025 年 8 月就宣布這個版本不再維護，改推範本化的新專案。所以結論分兩條路：你想要一套現在就能生簡報的工具，往維護中的同類看，後面有整理；你想搞懂多 Agent 系統怎麼用 Google ADK 真的落地，它值得你花一個下午把程式碼讀完。

一場簡報怎麼被拆成一條生產線

多 Agent 系統聽起來玄，拆開看就是工廠流水線。MultiAgentPPT 的流程是這樣：你輸入主題，大綱 Agent 先生出整份簡報的綱要；你確認或修改大綱後，拆分 Agent 把綱切成一段段子題；接著多個 Research Agent 並行，每個認領一段子題去查資料；彙總 Agent 把研究結果合併，再交給寫稿 Agent 逐頁生成投影片內容；最後有一個檢查 Agent 盯著每一頁的品質，發現問題就退回重寫，README 的流程圖寫明最多重試三次。這個「逐頁迴圈加品質檢查」的設計有個實際動機：模型一次生成全部頁數會撞上輸出長度上限，改成循環生成既能寫更多頁，每次的品質也有人把關。

骨架用的 Google ADK 提供三種編排零件：照順序跑的 SequentialAgent、同時跑的 ParallelAgent、單一角色的 LlmAgent。原始碼裡只有功能最完整的 slide_agent 真的用上整套編排零件，另外幾個模組是單一 Agent 的簡化版，這部分的程式碼乾淨好讀，是想理解 ADK 的人最值得細看的段落。A2A 與 MCP 兩個名字各管一段溝通：A2A 管服務對服務，讓每個 Agent 可以獨立部署、被遠端呼叫，你可以把大綱服務和寫稿服務架在不同機器上；MCP 管模型對工具，讓 Agent 能用統一介面呼叫搜尋、資料庫這類外部能力，等於替模型留了一排標準插座。兩個新協定加上 ADK 這套開發框架，在同一個專案裡各司其職，這正是它當教材的理由。

前端的體驗也照這條流水線設計。輸入主題後，大綱是一段一段長出來的，長完停下來等你確認或修改，人站在迴圈裡而不是全部丟給機器。

Pin

確認後進入生成階段，畫面上會顯示每個 Agent 目前做到哪一步，研究做到第幾題、寫稿寫到第幾頁都看得到，這種過程可見性對除錯與信任都有幫助，也是多 Agent 設計相對單模型黑箱的一個實際好處。生成完的內容可以直接線上編輯，再交給轉檔服務輸出 pptx。

Pin

整套系統的部署形態長這樣：Next.js 前端跑在 3000 埠，負責輸入介面、大綱確認與線上編輯；大綱服務與簡報生成服務分別佔 10001 與 10011 埠，各有簡化版與完整版兩種（simpleOutline 對 slide_outline、simplePPT 對 slide_agent，差別在完整版才有檢索與並行）；另外有一個存檔服務佔 10021 埠，用 python-pptx 把前端的 JSON 內容渲染成可下載的 pptx 檔。資料存 PostgreSQL，帳號走 NextAuth。倉庫也附了 docker compose 舉例，不過文件只交代到四個主要模組，實際目錄裡還躺著幾個沒寫進文件的實驗性子專案，讀的時候別被目錄數量嚇到，跟著 README 的表格走就好。

實際把它跑起來的工序，README 寫得算誠實：Python 端建議開 conda 環境裝 Python 3.12（作者提醒版本太舊會有怪問題），四個後端模組各有一份環境範本要複製成自己的 .env，資料庫用 Docker 起一個 PostgreSQL，前端複製範本設定後 pnpm 裝依賴、把資料模型推進資料庫再啟動。有個容易踩的坑直接寫在服務表格裡：簡化版與完整版共用埠號，想從 simpleOutline 換成功能完整的 slide_outline，得先把原本的服務關掉，不然就是埠號衝突。這些對架過前後端分離專案的人都不難，但第一次跑建議照著表格一次起一個服務，確定通了再開下一個。

查的資料是寫死的，完整版還留著一個沒修的壞引用

這是整個專案最需要先講清楚的一件事。照 README 的說明與流程截圖，你把專案架起來、輸入主題，它會跑完大綱、研究、寫稿的整條流程，畫面演示起來就像真的在查資料。但打開研究 Agent 的工具檔，第一行註解就寫明這是模擬資料庫的文件：裡面放著一批預先整理好的電動車新聞與統計數字，查詢函式固定用電動車當關鍵字去翻這批文件。換句話說，出廠狀態下的「自動研究」是一場安排好的示範演出，你輸入金融主題，它照樣翻電動車的資料給你看。查詢函式甚至不看關鍵字，直接把整批文件倒出來。

更實際的麻煩是完整版的健康狀態。主要分支的 slide_agent 主檔在 2025 年 9 月一次改名的過程裡，把一個角色物件寫成了未定義的變數名，一載入就會報錯，等於功能最完整的流水線在目前版本是起不來的，要自己把那一行改回正確的名字才能跑。簡化版模組沒有這個問題。停止維護的專案就是這樣：這種一行可修的小破損，也不會有上游幫你修。

README 對此沒有迴避，直接寫了目前內建的研究示例是電動車發展概述，要換成別的主題，就得改 prompt 並接上對應的 MCP 工具。真的搜尋這條路，倉庫給了起點但沒給成品：tools 目錄附了 Bing 搜尋與微信文章搜尋兩支現成腳本，Bing 那支的檔頭註解還自己承認快取功能沒生效，兩支都只是素材，預設的研究 Agent 也沒有接上，要真的能查資料得自己動手接。連檢查 Agent 的說明，作者都補了一句要你自己替換成真實的圖片與資料，可見「示範資料」與「真實資料」的邊界，作者是誠實畫出來的，只是宣傳時容易被略過。

給想讀程式碼的人一份導覽，這是它當教材最實用的部分。入門先看 simpleOutline 這個最小服務，主程式一百二十行就把一個 Agent 變成網路服務講完；接著看 slide_agent 目錄，主要程式檔用三種 ADK 編排零件組出生產線骨架，sub_agents 資料夾裡每個角色一個子目錄，各自帶 prompt 與設定，對照著讀就能看懂角色怎麼分工；倉庫的 docs 資料夾還放了 ADK callback 呼叫原理的圖解筆記與一篇除錯紀錄，後者記了一個值得知道的版本坑：某些舊版 ADK 沒辦法把串流結果傳回客戶端，文件建議升到新版解決。這些都是中文的，讀起來比翻官方文件快。

附帶一個工程上聰明的小機關。倉庫附了一支模型回應快取代理，跑在本機 6688 埠，模型的回應會被快取到本地檔案，同一個 prompt 再問就直接讀檔案不再花錢，連續失敗五次還會自動換備援模型。除錯多 Agent 流程時這個設計能省下可觀的 API 費用，因為同一條流水線你會反覆重跑很多次。

模型金鑰自己帶，五家雲端與本地模型都留了位置

它不綁任何模型服務。模型工廠檔案裡有十個供應商分支：Google、Claude、OpenAI、DeepSeek、阿里雲、豆包六家雲端，加上四個 local 版本把請求導向前面說的快取代理；另外附了 vLLM、Ollama 這類自架本地模型的對接說明，改幾行設定就能把整條流水線指向自己機器上的模型。預設值有個容易誤會的地方：兩個簡化模組的環境範本預設 Google 的 gemini-2.0-flash，環境範本裡的經驗註記也是 Gemini 串流測起來效果很好；但功能最完整的 slide_agent，設定檔裡生效的預設其實是阿里雲的 qwen-turbo-latest，gemini 的選項整組被註解掉。

換模型的方式值得記下來，因為它簡單到不太像改架構。雲端供應商的接線底層是 LiteLLM 這套轉接函式庫，各家 API 的差異在模型工廠裡被統一掉，在簡化模組切換供應商就是改環境變數裡的兩行：一家名字加一個模型名。想接自己架的模型也一樣，本地對接文件給的範例是跑一套 vLLM 服務，記下它開出來的 API 位址，塞進設定就成。對想把整條簡報生產線搬進內網、連模型都不出公司的團隊，這是實際可行的路，代價是本地模型的能力上限會直接反映在簡報品質上，文件沒有給任何本地模型跑出來的品質參考，這段成本要自己試。

串流這件事有個反直覺的細節。簡化版模組預設開啟串流回應，輸入主題後大綱會一字一句長出來，體驗很好；但功能最完整的 slide_agent 預設把串流關掉，原因是拆分 Agent 需要解析 JSON 格式的結果，串流模式會讓解析出錯。想在全功能模式下享受逐字輸出，得自己承擔調整的成本。另外提一句技術名詞：網路介紹常說它用 WebSocket 推流，對照原始碼，前端其實是 Next.js 的 API route 逐一讀取 A2A 串流事件，再包成 HTTP 的 ReadableStream 回應給瀏覽器，效果好比 WebSocket，機制是另一回事，要改前端的人別找錯地方。

環境範本還有一個台灣使用者要注意的預設值。四份設定範本裡有三份把代理設定指向本機 7890 埠，那是作者環境裡翻牆軟體的慣用埠。台灣直連 Gemini 或 OpenAI 都不需要這組設定，記得刪掉或留空，不然所有模型請求都會被導向一個不存在的代理，服務看起來像當掉，其實只是連不出去。

自架不等於本地優先，帳號與簡報都進資料庫

隱私邊界要畫對位置。這是一套自己架的系統，資料不出你控制的範圍，但「自己架」不等於「本地優先」：Prisma 架構把使用者資料表與生成過的簡報存進伺服器端的 PostgreSQL，帳號設計是從上游簡報專案繼承來的，前台並沒有掛登入牆。內容會出門嗎？會，兩個地方：模型呼叫帶著你的主題與生成內容去你設定的模型服務；如果接上 Bing 搜尋工具，查詢也會出門。這個結構與 JadeAI 自架履歷工具同型，自架給你的保證是資料落在你自己的資料庫，不是處理全程不出機器，想套用在公司內網，這條邊界要先跟資安單位對齊。

前端本身也有個來歷要交代。README 的參考來源段寫明，前端部分以開源專案 presentation-ai 為基礎改造，編輯器與介面骨架不是從零寫的。這在開源圈很正常，MIT 授權也允許，但代表你讀前端程式碼時會看到兩種風格混在一起，找問題時先確認手上那段是繼承來的還是作者加的。

作者已經換方向，這件事該怎麼影響你的決定

時間線攤開是這樣：專案 2025 年 6 月開倉；8 月 26 日作者在 README 頂部加了公告，說這個版本不再維護，因為簡報內容與範本難以為繼，改用範本化的新方案，推薦同一作者的後繼專案 TrainPPTAgent（那個新倉 8 月 22 日就開好了）。有意思的是公告之後他仍繼續修了快一個月，修非 Gemini 模型的串流問題與圖片渲染細節，9 月 22 日之後主要分支就沒有再動過程式碼；2026 年 7 月只剩一次 README 聯絡方式的微調。後繼的 TrainPPTAgent 走 Vue 加 Apache-2.0 授權，核心思路從「逐頁生成」換成「套用現成範本」，五百多顆星，不過最後更新也停在 2026 年 3 月，節奏同樣放慢了。

作者親口宣布停止維護，對兩種讀者的意義不同。對想拿它當生產工具的人，這是明確的轉向訊號：出了問題不會有上游修，要自己扛；對想學架構的人，反而影響不大，MIT 授權的程式碼不會因為停止維護而失效，fork 出去接著改也是授權明文允許的路。附帶一提，網路介紹裡常見「並行比單模型平均省四到六成時間、企業測試二十頁三分鐘完成」這類效率數字，整個倉庫找不到任何測試紀錄支撐，引用前先打問號，這類說法多半是轉述過程中長出來的。

跟維護中的同類比起來，它站在哪個位置

如果你的目標就是生簡報，2026 年的現在有多個維護中的開源選擇，定位各有差異。Banana Slides 是自架型的 AI 簡報產生器，代價與限制都寫在明面上；PPT Master 走文件轉可編輯投影片的工作流，把現有素材直接變簡報的路線更順；SlideBot AI 同樣是 MIT 自架加 Gemini 自帶金鑰，部署負擔比多 Agent 架構輕一截。這三個都持續在更新，拿來日常產出比 MultiAgentPPT 務實。

多 Agent 路線什麼時候才值得？設計上的理由是分工帶來的彼此制衡：多個研究 Agent 各自查不同子題，來源互相印證，單一模型憑空捏造的空間被壓縮；寫稿與檢查分開，等於內建一道審稿程序。這是架構邏輯，不是實測結論，檢查 Agent 實際擋下多少問題，專案裡沒有量化資料，作者只給了效果良好四個字的說法。我的看法是，這條路的成本結構很清楚：多個服務、一個資料庫、更多模型呼叫次數，換來的是可審核的分工與可見的過程。內容正確性要求高、主題需要多方查證的場景，這個交換才划算；一般的週會投影片，用單模型工具幾分鐘生完的效益高得多。

MultiAgentPPT 的不可取代之處只有一個，但那個很值錢：它把「多角色怎麼拆、怎麼並行、怎麼互相檢查」這件事用 Google ADK 寫成了一份可執行的中文註解範本。2025 年之後多 Agent 是顯學，但多數教學停在 hello world 等級，把並行研究、逐頁迴圈、品質檢查、失敗重試、串流回傳全部串起來又開放原始碼的範例，目前仍然少見。想為自己的業務寫一套多 Agent 流水線，把它的拆分方式與重試邏輯讀懂，比自己從空白專案摸索快得多。至於範本路線有興趣的人，後繼的 TrainPPTAgent 與 Slidesgo 範本庫是更對題的起點。

授權與專案狀態

授權 MIT，商用、修改、再散布都在允許範圍，2025 年版權屬作者 johnson7788。專案狀態：2025 年 6 月開倉，2025 年 8 月作者宣布此版本不再維護並推薦後繼專案 TrainPPTAgent，主要分支程式碼停在 2025 年 9 月；GitHub 上約一千六百顆星、兩百多次 fork、七個未解 issue。模型能力取決於你接的供應商與金鑰，生成品質與速度沒有官方保證，部署細節以倉庫 README 與你手上的版本為準。