PaperBanana：把方法描述变成学术插图的社区实现

它替代的是论文里那段最费时的画图工作

写论文的人大多经历过同一件事：方法部分的流程图画了三四版，每改一次架构就要重画，最后交给合作者时源文件还散在几个工具里。PaperBanana 要解决的就是这一段。输入是一段方法描述文本，输出是示意图或统计图，中间不需要你在绘图软件里手动摆框。仓库把它定位成面向 AI 研究者的自动化学术插图工具，论文本身来自 Google Research，这个仓库是社区维护的非官方实现，README 里明确写了与原作者及 Google Research 没有隶属或背书关系，实现基于公开论文，可能与原系统存在差异。目标用户是写机器学习论文的人、需要批量产出示意图的研究工程团队，以及想把出图步骤接进自动化流程的开发者。它同时提供 CLI、Python API 和 MCP server，后者意味着可以在支持 MCP 的 IDE 里直接调用。

两阶段多智能体流水线里，谁在改谁

README 对内部机制的描述只有一句：两阶段多智能体流水线，带迭代精修。可确认的组件比这句话多。流程里同时存在 VLM 和图像生成模型两类模型，分别由不同 provider 提供，配置项 GOOGLE_VLM_MODEL 与 GOOGLE_IMAGE_MODEL 是分开的，说明理解输入与产出图像不是同一个模型在做。输入侧还有一个输入优化层，README 称其作用是提升生成质量，但仓库材料没有说明这一层具体做了什么改写。精修是显式的：仓库提供 auto-refine 模式，也支持带着用户反馈继续一次运行，也就是 run continuation。这个设计把出图当成可以多轮收敛的过程，而不是一次调用。批处理走 manifest 文件，格式为 YAML 或 JSON，一次运行生成多张图；统计图有单独的 plot-batch 命令，manifest 中每一项对应一份 CSV 或 JSON 数据。方法描述还可以用 PDF 作为输入，需要可选的 paperbanana[pdf] 依赖（PyMuPDF），并支持按页选择。

从安装到出图的实际命令

安装是标准的一步：pip install paperbanana。想从源码开发则克隆仓库后执行 pip install -e ".[dev,openai,google]"，方括号里的 extras 决定了装上哪些 provider 依赖，这一点值得注意，因为默认安装未必包含你打算用的后端。密钥通过 .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 分别指定理解模型与图像模型，README 给出的示例值是 gemini-2.5-flash 与 gemini-3-pro-image-preview。也可以用 paperbanana setup 走一遍 Gemini 的配置向导。出图命令形如 paperbanana generate --input examples/sample_inputs/transformer_method.txt --caption "..."。Docker 用户先 docker build -t paperbanana .，运行时用 -e 传入密钥，把输入与输出目录挂载到容器内的 /work，例如 -v "$(pwd)/method.txt:/work/method.txt:ro" 与 -v "$(pwd)/outputs:/work/outputs"。本地还有一个 Gradio 界面，命令是 paperbanana studio，覆盖出图、统计图、评估、批处理和运行记录浏览。

几个绕不开的约束

最直接的限制是它依赖外部模型 API。方法描述、图注以及 PDF 内容都要发往 OpenAI、Azure、Gemini 或 Atlas Cloud 之一，仓库材料里没有本地推理或离线模式的说明。对未发表方法、企业内研究或受合规约束的项目，这是一道硬门槛，不是配置能绕过的。第二个约束是模型标识符本身会漂移。README 里写的是 GPT-5.2 配 GPT-Image-1.5、gemini-3-pro-image-preview 这类具体名称，这类字符串随 provider 更新而失效，仓库材料没有给出兼容性承诺或版本锁定机制。第三，精修是流程的一部分而非可选项，auto-refine 与带反馈续跑意味着单张图可能需要多轮调用，成本与耗时按轮次叠加，但仓库材料没有给出任何轮次上限或成本估算。第四，PDF 输入是可选依赖，没装 paperbanana[pdf] 时这条路径直接不可用。最后，README 自己声明这是非官方实现，可能与论文描述的原系统存在差异，因此把它的输出当作论文方法的忠实复现是不成立的。

和直接调用图像模型有什么不同

最接近的替代方案是绕开这一层，直接调用 Gemini 或 OpenAI 的图像生成接口，把图注当提示词发过去。两者差别在流水线结构上：直接调用是一次请求一次出图，模型不理解你的方法段落，也不会有人来评估结果；PaperBanana 在中间放了 VLM 做理解、放了输入优化层做改写、放了精修环节做多轮收敛，还提供评估相关的功能。代价是链路更长、依赖更多、单张图的调用次数更高。如果你的图是简单的概念示意，直接调 API 可能更快也更便宜；如果图需要准确反映方法段落里的模块关系，多一层理解与精修才有意义。另一个方向是继续用手工绘图工具，那换来的是完全可控的排版与矢量输出，代价是每次架构调整都要重画。这个仓库针对的正是后者的重复劳动，但它换来的可控性低于手工绘图。

批处理、MCP 与 Studio 各自解决什么

三个入口面向三种使用方式。批处理面向的是同一篇论文里要出多张图的情况，manifest 用 YAML 或 JSON 描述每一项，一次运行全部生成；统计图有独立的 plot-batch，每一项绑定一份 CSV 或 JSON 数据文件，这条路径适合结果图而非示意图。MCP server 面向的是编辑器内的工作流，README 提到配套的 Claude Code skills 提供 /generate-diagram、/generate-plot 和 /evaluate-diagram 三个命令，也就是说可以不出终端完成出图与评估。Studio 是本地 Gradio 界面，覆盖出图、统计图、评估、批处理和运行记录浏览，适合需要反复调参数、看历史运行的场景。三者共享同一套 provider 配置，切换入口不需要改模型设置。需要注意的是，仓库材料没有说明这些入口之间在功能覆盖上是否完全等价，尤其是评估功能只在 Studio 和 skill 中被提及。

维护节奏、许可与升级时要看的地方

仓库采用 MIT 许可，这是宽松许可，允许修改与再分发，但仓库材料没有涉及模型输出图像的版权归属，也没有说明生成内容能否用于商业出版，这部分需要自行确认，本文不构成法律意见。版本节奏上，v0.2.0 与 v0.3.0 相隔一天发布，bench-data-v1 作为 PaperBananaBench 数据集镜像在同月发布，说明项目处于活跃开发期，同时也意味着接口与配置项可能变动较快。升级时最该核对的是 .env 里的模型标识符与 base URL，因为 README 给出的模型名是具体版本号而非稳定别名，provider 侧一旦下线旧模型，配置就会失效。其次核对 extras 是否仍然覆盖你使用的 provider，安装命令里的 [dev,openai,google] 是显式列举的。仓库材料没有提供迁移指南或废弃策略，因此跨小版本升级前建议先在一个独立环境里跑通 generate 与 plot-batch 两条路径。

编辑结论

适合已经在用 OpenAI、Azure OpenAI 或 Gemini 且需要批量产出方法示意图与统计图的论文作者和工程团队，尤其是希望把生成流程挂进 IDE 或脚本流水线的人。不适合把数据保密放在首位、不能接受把方法描述发往第三方模型 API 的团队，也不适合期待一次生成即定稿的人，因为仓库本身把迭代精修设计成了流程的一部分。上手前先确认三件事：你的 provider 是否在 OpenAI、Azure、Gemini、Atlas Cloud 之列；Gemini 免费额度下的图像模型能否满足你的出图要求；以及默认 provider 与模型标识符在你安装的版本里是否仍是文档给出的那些值。

官方来源

1. Issues
2. License: MIT
3. llmsresearch/paperbanana on GitHub
4. README
5. Releases