Google把画图时间从6小时压到3分钟

凌晨11点的Stack Overflow上，一个神经科学博士正在搜索"matplotlib PDF export cut off axis labels"。这是他的第47次实验，数据干净，故事清晰，距离投稿Nature只剩6张图。6小时后，他盯着屏幕上变形的坐标轴，开始认真考虑转行。

Google AI最新开源的PaperBanana，就是冲着这种特定崩溃场景来的。它不是又一个"自然语言出草图"的玩具，而是一个agentic（智能体）框架——输入文字描述，输出能直接塞进NeurIPS或Nature的出版级图表。GitHub热度已经起来了，但比功能更值得聊的，是它底层的架构设计。

为什么99%的"文生图"工具死在同一个坑里

这个领域的坟场很大。大多数工具死法一致：生成一个"看起来对"的初稿，然后——没有然后了。一张能用的matplotlib输出，和一张能投稿的figure之间，隔着字体渲染、色盲友好性、期刊格式规范、图例位置、分辨率至少五道坎。单轮生成跨不过去。

PaperBanana的核心判断是：图表生成是个多维度质量问题，单次生成不可靠，必须迭代。它搭了一个critic-generator（批评者-生成者）循环：Critic agent输出结构化反馈，Generator agent执行修改，直到满足出版标准或触及迭代上限。

听起来简单。效果惊人。而且这个模式可以泛化到任何"质量维度多、需要迭代优化"的任务。

四agent流水线：谁负责什么

系统拆成四个角色，交接点全是结构化数据。

Planner agent读自然语言描述+原始数据，输出技术规格：选什么图表类型、数据要不要预处理、坐标轴怎么设。Code Generator agent把规格转成matplotlib/seaborn/plotly代码。Renderer执行代码出图。然后Critic agent上场——它对照预定义的出版标准（字体大小、配色对比度、标签完整性等）逐项检查，生成修改清单。

清单回到Code Generator，循环继续。Google的测试显示，平均2.3轮迭代后通过验收，硬上限设了5轮。

关键设计：Critic的反馈必须是结构化的，不能是"看起来不太对"这种废话。系统要求它输出具体指令，比如"将x轴标签字体从8pt改为10pt以符合Nature印刷规范"或"将色板从viridis改为cividis以提升色盲可读性"。

代码怎么跑：一个可复现的示例

项目已开源。核心依赖就几个：google-adk（agent开发套件）、matplotlib/seaborn/plotly、以及一个PDF渲染器。安装后，定义figure的方式接近自然语言：

```python from paperbanana import FigurePipeline pipeline = FigurePipeline( journal_style="nature", # 或"neurips", "ieee", "cell" colorblind_safe=True, max_iterations=5 ) result = pipeline.generate( description=""" Scatter plot showing correlation between prefrontal cortex activation (fMRI beta values, x-axis) and reaction time in milliseconds (y-axis). 120 subjects, color by age group (young/old). Include regression line with 95% CI. """, data="experiment_3_cleaned.csv" ) ```

输出包含PNG预览、矢量PDF、以及完整的生成日志——哪轮改了什么、Critic当时的具体反馈，全部可追溯。审稿人追问"这个图怎么做的"时，你有完整链条。

为什么产品经理应该关注这个架构

PaperBanana的真正价值不止于救急画图。它验证了一种agent协作模式：生成-评估-迭代的闭环，用结构化接口隔离不确定性。

Planner处理模糊输入，输出确定性的技术规格。Code Generator面对确定规格，输出确定性的代码。Renderer是确定性执行。只有Critic涉及主观判断，但它的输出又被强制结构化为可执行的修改指令——不确定性被圈死在局部，不会污染整个链条。

这和传统软件开发的"编译-测试-修复"循环本质上同源，但把"测试"和"修复"都自动化了。Google ADK团队的人提到，他们内部已在把同样模式迁移到数据清洗、实验报告生成等场景。

一个有趣的细节：Critic agent的prompt工程花了团队最多时间。他们发现，让模型扮演"挑剔的期刊审稿人"比"有帮助的助手"效果更好——角色设定直接改变反馈的严格程度和具体性。

目前GitHub仓库的issue区，最常见的请求是支持更多期刊模板（Science、PNAS、arXiv预印本格式）和更多绘图后端（R的ggplot2、Python的altair）。维护者的回复很克制：先保证matplotlib生态的稳定性，再扩展。

那个凌晨11点搜Stack Overflow的博士，如果晚半年开始实验，他的第47次研究会是什么体验？