先划边界：这篇不打算让你用 Agent 替掉 BI 系统。真正日常要看、要交互筛选的经营看板，还是该交给 BI 或表格工具。这里解决的是另一类更磨人的需求——周期性、一次性、临时要的那几张图。
做运营、做项目管理的都懂这种痛：每周一要交一份带图的周报，图是同一批图，数据换一遍；领导临时说「把这个月三个渠道的转化画出来看看」，于是你又开一次表格软件，拖一遍数据，调一遍配色，保存，贴进文档。这类活的价值不在于「难」，而在于「重复且不能错」——一旦图上的数字和源数据对不上，汇报当场翻车。这种活本来就该交给 Agent。
第一步：先把数据口径钉死，不然图越漂亮错得越远
绝大多数「自动出图」项目死在第一步：数据本身没有稳定口径。Agent 每周读到的表结构都不一样，出出来的图自然也一版一个样。
开工前必须定下三件事：
- 数据放哪、以什么格式放。最省事的是约定一个固定目录，每周把最新的文件丢进去，文件名带日期。CSV 或 xlsx 都行，但列名必须固定——列名一改，脚本就瞎了。表格数据本身怎么读、怎么清洗合并，站内 Agent 处理 Excel 表格 有完整拆解，建议先把它跑顺再进来做图。
- 指标怎么算。「转化率」是订单数除以访客数，还是除以点击量？「活跃用户」是登录过就算，还是要产生行为才算？这些必须在文档里写死，并且写进 Agent 的指令里，而不是靠它猜。
- 时间范围与单位。是自然周还是滚动七天，金额是元还是万元，百分比保留几位。这些细节决定了图能不能直接拿去汇报。
口径写清楚这一步看着枯燥，但它决定了后面所有自动化的可靠性。口径没定，自动化只是把错误生产得更快。
第二步：图型选型，先问「要表达什么」
新手最常犯的错是有什么图用什么图。正确的顺序是先明确要表达什么关系，再选图形。可以直接把这张对照表写进 Agent 的指令里：
- 要比大小（各渠道谁多谁少）→ 横向条形图。类别名长的时候，横向比纵向好读得多。
- 要看趋势（这半年怎么走）→ 折线图。多系列对比时最多放三条线，超过就该考虑拆图或用小多图。
- 要看构成（占比各多少）→ 环形图或堆叠条。类别超过六类就别用饼图，读者根本分不清。
- 要看分布（响应时间是均匀还是长尾）→ 直方图或箱线图。只看平均值会漏掉最难受的那批用户。
- 要看相关（投放和转化是不是同向）→ 散点图。注意相关性不等于因果，别让图替你做结论。
- 要看进度达标（完成了目标的多少）→ 进度条或子弹图，比柱状图更直给。
- 要一眼看结论（这周到底还行不行）→ 单值卡 + 同比环比变化，别硬塞一张复杂的图。
还有一条纪律：一张图只说一件事。把五个指标塞进一张双轴图，看起来信息量大，实际上没人看得懂。宁可出五张小图排成一行。
第三步：出图的三条路线，按场景挑
OpenClaw 出图有三种可行姿势，各自适合不同场景：
（1）让 Agent 写代码执行。把数据路径和目标说清楚，让 Agent 生成 Python 脚本（matplotlib、plotly 这类库都行），跑出图片文件。优点是灵活度最高，任何定制样式都能做，而且脚本一旦跑通就能固化成模板反复用；缺点是第一次调样式会来回几轮，字体、边距、图例位置这些细节要磨。这是最推荐的路线。
（2）接图表类服务或工具。如果已经有现成的图表服务，可以按 OpenClaw 接 MCP 工具 的方式把它挂进来，Agent 只负责传数据和取图。这条路线的图风格统一、不用维护渲染环境，适合标准化程度高的定期报表。
（3）生成 HTML 加图表库。如果产出物本来就是网页或者要在浏览器里看，让 Agent 直接输出一个自带图表的 HTML 页面更划算，还能做交互悬浮。缺点是打印和贴进文档时不如图片省事。
实操建议：定期报表走路线一，把脚本模板固化下来；临时要的图可以走路线三，快速出个页面看结论。
第四步：中文出图的三个固定坑
用代码出中文图表，一定会撞上这几个问题，提前处理掉能省半天：
- 中文变方块。绘图库默认字体不含中文，必须显式指定系统里存在的中文字体文件，并处理负号显示异常的问题（默认字体里的负号常常也是方块）。
- 图例与标签挤压。中文标签比英文长，容易互相压住或者超出画布。解决办法是给画布留足边距，长标签考虑换成横向条形图，或者做截断加说明。
- 配色与含义。财经营收类图表要按国内习惯来：上涨用红色、下跌用绿色，跟欧美正好相反。这一点必须写进指令，否则 Agent 会用默认配色，图一发出去就被人挑错。同时避免红绿同时作为「两个并列类别」的区分色，对色觉异常的人非常不友好。
还有个小细节很容易被忽略：标题里必须带时间范围和口径。「各渠道转化率」和「各渠道转化率（2026 年第 37 周，订单数/访客数）」，后者的价值高得多——图被别人转发出去之后，还能自己说明自己。
第五步：数据校验，这是最不能省的一步
自动出图最大的风险不是图丑，是图好看但数字错，而且因为看着专业，反而没人怀疑。所以校验必须做成流程里的硬关卡：
- 数字要能回溯。图上出现的每个关键数值，都要能对应到源数据的具体位置。做不到就别上自动化。
- 合计对得上。分项加总必须等于总数，差额超过阈值就直接报错停下，不要生成图。
- 量级与单位核对。最容易出的低级错误是单位错位，把万元当元，或者把月数据当周数据，图上看起来完全正常。
- 提防坐标轴骗人。纵轴不从零开始会放大差异，看起来「暴涨」其实只涨了 2%。这类处理要明确记在图上（比如标注截断），或者干脆给 Agent 定死规则：柱状图纵轴必须从零开始，只有折线图在合理说明下才允许截断。
- 样本量要有提示。只有 8 个样本的百分比我照样能画得很漂亮，但结论几乎没有意义。样本量过小的系列该加标注甚至不出图。
- 异常值要标出来，不要悄悄抹掉。突然多出来的一个尖峰，可能是真实业务变化，也可能是数据源故障。图上标出来并附一句说明，比让人自己发现强。
这套校验逻辑相当于给出图流程加了一道门禁，思路和 变更后验证清单 是一致的：产出之前先过一遍必查项，而不是发出去再靠人眼看。
第六步：批量出图，靠目录约定而不是靠嘴说
一次出十几张图的时候，管理混乱比出图本身更耗人。建议直接用目录和命名把它管住：
- 每批数据一个独立目录，带上批次日期，源数据、生成脚本、输出图片全放一起。
- 图片按「主题-维度-批次」命名，比如「渠道转化-周对比-20260920」，不要用「chart1.png」。
- 同一批的样式参数集中在一处（颜色、字号、尺寸、边距），改一次全批生效。
- 失败要能单独重跑，不能因为第十张图出错就把前九张重做一遍。
- 输出目录只放成品，中间文件另放，避免把目录搞成一锅粥。
这套约定的价值在于：三个月后你自己回头看，也能知道哪张图是哪批数据出的。
第七步：从出图到出报告，多写一句话
图本身不构成交付物。真正省时间的是让 Agent 在图后面补上三样东西：
- 一句话结论：这批数据最值得注意的是什么，用最直白的话说。
- 异常提示：哪个数字偏离常态，可能的解释有哪些（列为候选，不要下断言）。
- 待确认项：哪些数据看起来有问题需要人工核对。
这三句话要有明确的证据约束——只能基于给定数据说，不能凭印象补充背景。报告要跟历史版本做对照，可以参考 回放对照 的思路，把「这周和上周差在哪」变成可核对的事实，而不是感觉。
最后接上定时任务，让它每周固定时间跑完并把图推给相关的人。定时任务和推送怎么配，见 OpenClaw 定时发日报周报。到这步，图这件事才算真正从「手工活」变成「基础设施」。
优缺点与适合人群
优点：重复出图的成本趋近于零；口径写在指令里，比靠人记更不容易错；历史批次留档完整，做同比环比随时能调出来。
缺点：第一次搭建要花时间调样式和校验规则，产出不是「今天配好明天就完美」；图形样式的一致性依赖模板维护，模板没人管就会慢慢走形；对需要交互筛选、下钻分析的需求，它替代不了 BI 工具。
适合：每周固定出运营周报、项目周报的团队；需要定期给上级交带图材料的人；做投研、市场分析这类大量出图岗位的同学。如果你一个月只出两次图，手工做反而更快。
一句话总结：自动出图省下的不是画图那十分钟，而是「不敢出错」的那份心力。把校验规则写进流程，图才敢自动发出去。
