PaperBanana：把方法段落餵進去，讓多代理管線畫出論文插圖
Open source implementation and extension of Google Research’s PaperBanana for automated academic figures, diagrams, and research visuals, expanded to new domains like slide generation.
秒懂
- 它是什麼？
- 這是 Google Research 論文《PaperBanana》的社群非官方實作，以兩階段多代理流程把文字描述轉成學術圖表與統計圖，支援 OpenAI、Azure、Gemini 與 Atlas Cloud 供應商。判斷重點在於它綁定外部影像生成 API，以及它與原論文的落差。
- 適合誰用？
- 如果你的痛點是方法段落反覆重畫成示意圖，而且團隊已經有 OpenAI 或 Gemini 的 API 額度，PaperBanana 值得先進 Colab 筆記本跑一次再決定要不要落地。若你在意可重現的向量輸出、或需要完全離線的管線，這條路不適合，因為影像生成端綁定外部供應商，且官方明言此實作與原論文系統可能有落差。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 6 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它想解決的是論文裡最花時間的那張圖
學術寫作有一類工作長期沒有好工具：把方法章節的散文改寫成一張能放進論文的架構示意圖，或把實驗數據整理成統計圖。作者通常先用簡報軟體拼出草稿，再來回修改版面，這個過程與研究本身的貢獻無關，卻吃掉大量時間。PaperBanana 針對的就是這段流程，輸入是一段方法描述文字與一句圖說，輸出是圖。README 把它定位為「An agentic framework for generating publication-quality academic diagrams and statistical plots from text descriptions」。
目標使用者寫得很明確：AI 科學家。倉庫主題標籤裡同時出現 neurips、arxiv、academic-research，首頁也直接寫「Automated Academic Illustration for AI Scientists」。這代表它預設使用者能讀懂方法段落、能判斷生成圖是否忠實，而不是把選圖這件事外包出去。另一條延伸路線是簡報生成，README 提到專案「expanded to new domains like slide generation」，但沒有給出對應的指令範例，這部分目前只能從敘述推測。
兩階段多代理管線與輸入優化層
README 對架構的說明只有一句：「Two-phase multi-agent pipeline with iterative refinement」。第一階段做什麼、第二階段做什麼，文件沒有展開，只留下階段數與「迭代精修」兩個線索。搭配另一條功能「Input optimization layer for better generation quality」可以推知，管線在真正呼叫影像模型之前，會先對輸入文字做一層處理。這層處理的具體內容（是補全描述、抽取構圖元素，還是轉成提示詞模板）在提供的材料裡看不到。
可以確認的是模型分工。倉庫主題含 vlm 與 text-to-image，README 說支援「Multiple VLM and image generation providers」，並在環境變數裡分別給出 GOOGLE_VLM_MODEL 與 GOOGLE_IMAGE_MODEL 兩個鍵。這表示視覺語言模型與影像生成模型是分開配置的兩個角色，VLM 負責理解與評判，影像模型負責出圖。環境變數範例把 VLM 指向 gemini-2.5-flash、影像模型指向 gemini-3-pro-image-preview，是兩個不同世代、不同用途的模型。
精修機制有兩種觸發方式。一種是 auto-refine 模式，由系統自行迭代；另一種是 run continuation，讓使用者帶著回饋接續既有的一次執行。後者對實務更有意義，因為論文插圖的修改意見通常很具體（某個箭頭方向錯了、某個模組要拆成兩塊），丟給自動精修不如直接指定。
安裝與第一次生成：從 pip 到 CLI
安裝路徑有兩條。最單純的是 pip install paperbanana。要改原始碼則從倉庫複製後執行 pip install -e ".[dev,openai,google]"，這個 extras 組合透露了相依性被切分成供應商維度，用哪家就裝哪組。
金鑰設定走 .env：複製 .env.example 之後填入 OPENAI_API_KEY 或 GOOGLE_API_KEY。Azure OpenAI 或 Foundry 的使用者要另外設 OPENAI_BASE_URL，格式是 https://<resource>.openai.azure.com/openai/v1。Gemini 有三個選配覆寫鍵：GOOGLE_BASE_URL 指向自架代理、GOOGLE_VLM_MODEL 與 GOOGLE_IMAGE_MODEL 分別指定兩個模型。不想手改檔案的人可以跑 paperbanana setup，README 說明這是給 Gemini 用的設定精靈。
生成指令的形狀是 paperbanana generate --input <檔案> --caption "<圖說>"，範例用 examples/sample_inputs/transformer_method.txt 搭配「Overview of our encoder-decoder arc」。Docker 路線則先 docker build -t paperbanana .，再以 -e GOOGLE_API_KEY 傳入金鑰；要產生圖檔得把輸入檔與輸出目錄掛進容器，範例同時掛載 method.txt 為唯讀並把 outputs 目錄掛進 /work/outputs。
批次處理是這個專案相對實用的部分。manifest 檔案支援 YAML 或 JSON，一次跑多張圖；統計圖另有 paperbanana plot-batch，每個項目對應一份 CSV 或 JSON 資料。方法論上下文可以吃 PDF，但要加裝 paperbanana[pdf]（PyMuPDF），而且能逐頁挑選。
CLI 之外的三個入口：Studio、MCP 與 Claude Code
同一個核心被包成三種介面。PaperBanana Studio 是本地 Gradio 網頁介面，用 paperbanana studio 啟動，涵蓋 diagrams、plots、evaluation、batch 與 run browser 五塊。run browser 的存在說明這個工具會累積多次執行的紀錄，而 evaluation 區塊則對應到論文本身關心的評測問題。
MCP server 是給 IDE 用的整合路徑，README 開頭的註解標明 mcp-name: io.github.llmsresearch/paperbanana，主題標籤也列了 mcp-server。另外倉庫提供 Claude Code skills，對應 /generate-diagram、/generate-plot、/evaluate-diagram 三個指令。選擇哪個入口取決於工作習慣：一次性出圖用 CLI 最快，要反覆比對與調參用 Studio，已經在編輯器裡寫論文的人則走 MCP 或 skills。
這些介面共用同一組環境變數與供應商設定，所以金鑰配置只需要做一次。反過來說，供應商設定的問題也會同時影響所有入口。
非官方實作這件事，決定了它能不能進你的流程
README 開頭有一段免責聲明，措辭相當直接：這是「unofficial, community-driven open-source implementation」，並且「not affiliated with or endorsed by the original authors or Google Research」，實作基於公開論文，「may differ from the original system」。
這段話的實務意義是：你不能拿這個倉庫的輸出當成論文方法的復現結果。如果你打算在論文中引用 PaperBanana 的評測數字或行為，必須回到 arXiv:2601.23265 對應的原始系統，而不是這個社群版本。反過來說，如果你的目的只是「幫我把方法段落畫成圖」，原版與社群版的落差就不構成阻礙。
另一個限制是輸出型態。這條管線依賴影像生成模型產出點陣圖，不是可編輯的向量圖。論文排版經常需要微調字級、線寬或配色，點陣輸出意味著這些調整得回到生成階段重跑，而不是在繪圖軟體裡拉一拉。倉庫主題裡雖然有 scientific-visualization，但這不改變輸出是影像的事實。
最後是供應商綁定。README 列出 OpenAI（GPT-5.2 + GPT-Image-1.5）、Azure OpenAI / Foundry、Google Gemini、Atlas Cloud 四家。沒有本機模型路徑，也沒有離線模式。對資料不能出境的團隊，這是硬性阻礙。
與直接用影像模型或繪圖工具相比差在哪
最直接的替代方案是把同一段方法描述貼進任何具備圖像生成能力的對話介面。差別在於流程控制：直接下提示詞是一次性的，你拿到什麼就是什麼；PaperBanana 把流程拆成輸入優化、VLM 判讀、影像生成與迭代精修幾個環節，並且提供 run continuation 讓你帶著具體回饋接續同一次執行。對於需要改五輪以上的論文插圖，這個差異會累積。
另一類替代是 TikZ、Graphviz 或 matplotlib 這類可程式化的繪圖工具。它們的優勢正好是 PaperBanana 的弱點：輸出是向量、可版控、可重現、完全離線。代價是你得自己描述拓撲與版面，而這正是 PaperBanana 想替你省下的工作。兩者不是替代關係，而是分工：結構固定、需要精確控制的圖表用程式化工具，構圖複雜、需要視覺想像的示意圖才交給生成管線。
第三類是簡報或繪圖軟體的手動排版。它沒有任何 API 成本，也不會有模型幻覺出不存在模組的風險，但無法批次化。當一個團隊要為多篇論文產出一致風格的圖時，手動路線的邊際成本降不下來。
維護成本與 MIT 授權的邊界
授權是 MIT，對整合進商業產品相對寬鬆，README 的徽章也標明這一點。要注意的是授權涵蓋的是這個倉庫的程式碼，不涵蓋你呼叫的模型供應商服務條款，也不涵蓋生成圖片的權利狀態。把 AI 生成圖放進投稿論文之前，該確認的是你所用供應商對輸出內容的商用與再散布規定，這部分不在 MIT 的範圍內，本文也不提供法律意見。
維護面上，倉庫在 2026 年 6 月連續發布 v0.2.0 與 v0.3.0，同月另有一個 bench-data-v1 標籤，是 PaperBananaBench 資料集的鏡像，最後推送時間為 2026-09-09。發布節奏看得出專案仍在推進，但也意味著 API 與設定鍵可能還在變動，鎖定版本再升級會比跟著 main 走穩妥。
真正的持續成本不在程式碼，而在推理費用。每一次生成、每一次自動精修、每一次帶回饋的重跑都會呼叫影像模型，而影像生成的單價高於純文字模型。批次 manifest 讓這件事更容易規模化，也更容易讓帳單規模化。上線前先用單張圖量測一次完整流程的呼叫次數，比事後看帳單有效。
驗證順序建議這樣排：先用 Colab 快速入門筆記本確認你的供應商與模型可用，再用自己的方法段落跑一次 generate，檢查輸出是否忠實於原文，最後才把 manifest 批次化。如果第一步就卡在模型名稱或區域端點，後面都不必談。
編輯結論
如果你的痛點是方法段落反覆重畫成示意圖，而且團隊已經有 OpenAI 或 Gemini 的 API 額度，PaperBanana 值得先進 Colab 筆記本跑一次再決定要不要落地。若你在意可重現的向量輸出、或需要完全離線的管線，這條路不適合，因為影像生成端綁定外部供應商，且官方明言此實作與原論文系統可能有落差。動手前先確認三件事：你選的供應商是否支援 README 列出的影像模型、批次 manifest 的欄位格式是否符合你的資料、以及 MIT 授權下你對生成圖片的商用範圍如何界定。
社群筆記