模型仅负责将自然语言转换成绘图参数，数据处理、流程设计均由程序提前固定。本质为带有LLM节点的workflow，只服务于本人日常固定需求。提效显著，但难以扩张，适用面窄；同时因产出为python图，导致origin用户尝试意愿低。
为推广覆盖面，引入自动化数据处理和自主模板创建功能，进而推动架构从 单一workflow 转向 顶层路由+多workflow 再转向 具有上下级关系的多agent协作，最终敲定采用 单一Pi Agent Runtime。
单一agent解决了v2中多workflow流程固定、多agent状态膨胀的问题。同时选择通过覆盖常见origin模板（实现难度更低）替代自主模板创建功能，解决v1适用面窄、origin用户粘性问题。
让参考图提供固定模板之外的结构和样式信息，扩大系统可以处理的图表范围。
参考图处理成为独立流程，Renderer 迁移到 Matplotlib。模型可以先读取图片，再把观察结果转换为受限绘图参数。
一次模型输出同时混合图形结构、数据关系和视觉样式，错误难以定位。参考图、图类型判断、数据处理和绘图也开始形成不同的任务流程。
先生成 ReferenceObservation（参考图观察结果：代表模型从图片中识别出的结构与视觉证据；记录图形组成、坐标轴、系列关系和样式；在流程中作为后续参数转换的输入），再由程序限制可以进入 Renderer 的参数。同时引入 LangGraph（任务状态图：代表一轮请求的编排过程；承载当前状态、流程节点和路由结果；在流程中根据 Planner 的判断调用对应 Workflow），架构从单一 Workflow 变成顶层路由加多条 Workflow。
参考图样例证明观察、参数转换和渲染链路可以执行，但结果仍受已有图类和 Renderer 参数范围限制。
让参考图生成的结果不只服务当前图片，还能保存为新图类，并在同类新数据上继续绘图、修改和导出。
系统加入图类注册、试运行、安装和复用流程，并使用 Custom Renderer 执行新图类。
一项任务同时包含目标理解、数据准备、图类设计、实例绘图和质量检查。顶层路由只能选择整条流程，单个 Workflow 和集中式服务无法清楚管理这些职责。
多 Agent 架构在这一阶段出现。采用 Graph-orchestrated Plan-and-Execute（图编排的计划—执行架构：代表由顶层 Planner 调度多个专职 Agent 的任务结构；承载任务计划、阶段状态和各 Agent 的结构化结果；在流程中依次调用数据准备、图类设计、实例绘图和程序质量门槛），并引入 ChartCapability（可复用图类能力：代表一种可以安装和重复使用的图类；承载图形结构、数据要求、可编辑参数和渲染规则；在流程中连接图类创建、试运行、安装与实例绘图）。
端到端测试覆盖了新图类创建、安装和同类数据复用；但每增加一种结构仍可能增加专用 Renderer，多 Agent 也开始引入更多阶段状态。
让新图类通过组合已有绘图结构扩展，不再为每一种参考图单独增加 Renderer 分支。
专用 Custom Renderer 被移除，Renderer 改为按照结构层生成图表；参考图流程也重新接入图类设计链路。
模型需要同时理解参考图结构、目标数据语义和 Renderer 协议。每增加一层结构合同，Agent 之间就需要传递更多状态和中间结果。
使用 StructureUnit（受控图形结构单元：代表一种经过程序实现和校验的绘图组成；承载所需数据角色、图层关系和后端支持；在流程中由模型选择、由程序组合并交给 Renderer 执行）。顶层 Planner 下继续拆出目标理解、数据准备、图类设计和实例绘图 Agent，程序节点负责协议编译和结果校验。
独立评测覆盖了结构单元、实例复用和 Renderer 结果，部分图类可以共享同一套执行方式；多 Agent 的状态同步、修复和失败归因也随之变得更复杂。
保留模型根据任务状态继续规划的能力，同时减少固定 Workflow 和多 Agent 之间的层层转交。
Pi 先接管新图类设计，随后接管顶层工作流选择，并完成一次任务中的数据准备、proposal、确认和改图调用。
多 Workflow 仍然依赖固定分支，多 Agent 则需要维护重复上下文、阶段状态、预算和修复协议，任务越长越难保持一致。
采用 Pi Agent Runtime（单一模型工具循环运行时：代表一次可以连续调用受控工具的模型任务；承载当前上下文、工具清单、预算和每步返回结果；在流程中根据程序反馈继续选择下一项动作），数据处理、校验、渲染和版本管理仍由程序负责。
V2 完成了 Pi 工作流和端到端绘图链路验证，产品化在 V3 继续完成。自主模板创建没有进入最终发布范围，V3 改为覆盖常见 Origin 模板。