StructSVG: Tree-Graph Guided Multi-Agent Text-to-SVG Generation

资料来源说明

截至 2026-11-07，论文 PDF / arXiv / ACM 页面都还没公开（会议 12 月 1–4 日在吉隆坡）。本页内容来自三处：GitHub README、开源代码 structsvg.py（3120 行）、仓库里的 2.5 分钟演示视频（方法图与结果表从视频帧截取，数字逐个核对过）。数据集、指标定义、实验细节等论文正文内容无法确认的地方，都标了“推测”。

另一点要注意：作者的 release PR 写明，开源代码是“code audit 中找到的最完整作者快照”（2026 年 4 月的版本），不一定就是跑出论文数字的那一版。后文 论文图 vs 开源代码 列出了两者的出入。

术语速查

研究动机

• 问题难在哪：SVG 是“代码形式的图像”。LLM 一口气写几百行 path，没有空间草稿，常见错误是部件漏画、前后遮挡反了、元素跑出容器；就算画对了，输出也是一堆匿名 <path>，没法说“把猫的耳朵调大一点”。
• 现有方法的问题：(1) 专门训练的 SVG 模型（OmniSVG、InternSVG、IntroSVG）语义对齐弱，主表里 CLIP 只有 0.23–0.25，远低于通用 LLM；(2) 直接让 GPT-4o / Gemini 写 SVG，画面不错，但结构是隐式的，ID Cov.≈0；(3) 单 agent 的自我修正没有结构参照，越改越乱。
• 核心 insight：先把“画什么、谁挡谁、放在哪”写成显式的树 + 图，再让 LLM 按 id 逐个落实到 SVG。规划结果同时有三个用途：生成时当蓝图，检查时当约束（违反了哪条边一查就知道），生成后当编辑句柄。

核心方法

flowchart LR
  P["Text prompt"] --> TB["TreeBuilder"]
  TB -->|"semantic_tree.json"| GB["Graph builder"]
  GB -->|"edges + draw_order"| SE["SVG Engineer"]
  SE -->|"k=3 candidates"| PF["Preflight"]
  PF --> CR["Critic"]
  CR -->|"PASS"| OUT["Editable SVG"]
  CR -->|"Tier 1"| SE
  CR -->|"Tier 2"| TB
  CR -.->|"TextGrad"| RP["Role prompts"]
  RP -.-> TB
  RP -.-> SE
          

1. Tree-Graph Planning — 文本 → 部件树 → 拓扑图

TreeBuilder 只做一件事：读 prompt，写出 semantic_tree.json（schema v2.0）。规则：叶子才有 geometry，对称物体要列出全部实例（左右眼各一个节点），fill 只能写 hex（禁止 CSS gradient 语法），同色相邻部件要加 notes 提醒描边。prompt 里还写死了三条“能力约束”：不准设计“一个形状包住另一个”（C 形身体抱住球）、不准要求两个 path 在精确坐标对接、同一区域遮挡不超过 3 层。也就是说，系统通过在规划阶段回避 LLM 画不好的几何来降低失败率。

Graph builder 是三步的混合流程：(A) 确定性地抽出所有叶子；同一父节点下相邻兄弟，若 bbox 重叠，就加一条“后者 OCCLUDES 前者”的边（兄弟顺序即图层顺序；不重叠的左右眼不加边）。(B) 调一次 LLM（temperature 0.1），只补跨父节点的边，并且只接受 5 种合法类型、只接受已存在的 id。(C) 用 Kahn 算法拓扑排序出 draw_order；如果 LLM 补的边造成环，就把跨父边整体丢掉，只保留兄弟边。

直观理解：树回答“有哪些零件、怎么分组”，图回答“零件之间谁压谁、谁装着谁”。LLM 自己不擅长维护的全局一致性（图层顺序无环）交给了 30 行 Python。

2. Part-Aligned SVG Drafting — 按 id 落实成 SVG 候选

SVG_Engineer 把整张图 JSON + draw_order + prompt + 一份 8 条的 cheat sheet 发给 LLM。cheat sheet 的关键规则：每个图节点对应的 SVG 元素必须使用节点的原 id；严格按 draw_order 写；CONTAINS 用 clipPath；对称部件定义在 <defs> 里再用 <use> 复用；有机形状用“粗描边底层 + 无描边填充上层”的双层技巧消除接缝。一次生成 k=3 个候选，温度依次为 0.2 / 0.35 / 0.5。

另一种 autoregressive 模式：沿 draw_order 每次只生成一个节点的 SVG 片段，把已画部分作为上下文，最后拼起来。代码注释承认这种模式“误差会累积，也没法做整体补丁”，所以一进入重试就强制切回 one-shot。

每个候选生成后要过 preflight：XML 合法、viewBox 固定 256、用 Playwright/Chromium 渲染成 PNG 后不能全透明、可见像素中近白占比不能 >45%（除非有深色描边）、clipPath 里不能放只有描边的几何。重试时还会算 structural drift：新旧 SVG 的 id 增删数 >5 直接判废，强制“最小补丁”。

3. Structure-aware Refinement & Selection — Critic 的四路信号

1. 选候选：调用本地 scorer 服务算 CLIP（ViT-B/32，logit/100）和 HPSv2.1。按 (round(CLIP×100), HPS) 做字典序取最大：CLIP 差 0.01 以内才看 HPS。
2. 确定性检查：对选中的那份再跑 preflight 和图约束检查。包含 / 遮挡违规单条只算警告，≥2 条才升级为 blocking（单条可能是 path bbox 近似带来的测量误差）。
3. LLM 视觉打分：把渲染 PNG、图 JSON、当前 SVG 树、历史最佳 SVG 树、指标和警告一起交给“严格的艺术总监”，返回 Structure / Occlusion / Color / Fidelity / Polish 五项分、总分 1–10、pass_ready 和修改建议。有 blocking 时总分必须 ≤4。
4. 硬门槛：CLIP ≥ 0.20 且 HPS ≥ 0.18。最终 PASS 条件为：LLM 判 pass_ready、没有任何 blocking、两个下限都过。

FAIL 时由 diagnose_failure_tier 决定打回给谁：出现遮挡 / 包含的结构违规、CLIP ≤ 0.20、或 drift ≥ 3 → Tier-2，回 TreeBuilder 改树（只改出问题的节点）；其余 → Tier-1，回 SVG_Engineer，带着 Critic 建议以低温（0.05–0.15）重写。两类重试共享一个计数器，最多 3 次。同时 TextGrad 会根据本轮失败信息改写 TreeBuilder 和 SVG_Engineer 的 role prompt（不改 Critic），下一轮指标下降就回滚到上一版 prompt。任务 PASS 后，LLM 从这次的树和 SVG 中总结“设计经验”，写入跨任务记忆 global_memory.json（只保留最近 8 条），后续任务的所有 agent 都能读到。

4. 多 agent 编排 — 其实是一条固定流水线

4 个角色：Coordinator（看门狗，只在报错、死循环、回合数用到 50% / 75% 时介入）、TreeBuilder、SVG_Engineer、Critic。每个 agent 有工具白名单和文件写权限白名单（例如只有 TreeBuilder 能写 semantic_tree.json），每一步只允许调用一个工具，用 send_message 交出控制权；单任务上限 30 个回合。正常路径是 TreeBuilder → SVG_Engineer → Critic 的固定顺序，“多 agent”实际上就是用对话来驱动一个带分支的状态机。

5. 最关键的一句话

先让 LLM 用 JSON 写出“零件清单 + 谁压谁”，用 Python 排好图层顺序，再要求 SVG 每个元素沿用零件 id；这样同一份结构既能指导生成、又能自动挑错、还能当编辑句柄。

论文图 vs 开源代码

方法图和 README 描述的系统，比开源代码实际做的事更多。读代码时要知道以下差别：

主要实验结果

• 数据集 / benchmark（推测）：代码里批量任务的默认输入文件名是 mmsvg_text_sampled.jsonl，应当是从 OmniSVG 的 MMSVG-Bench text-to-SVG 部分采样得到。表中所有成功率都是 1/150 的整数倍（98.7% = 148/150，74.7% = 112/150），推测测试集为 150 条 prompt。
• 指标：CLIP、HPS（v2.1）、Aesthetic、ImageReward、VQAScore 衡量画面与文本对齐 / 美观；ID Cov.、Edit Score 衡量结构与可编辑性（具体定义要等论文）。
• “StructSVG†-X” 表示把 X 换作所有 agent 的底座 LLM；对照组是同一 X 直接写 SVG。

主表（取自演示视频，粗体为全表最佳）。每个底座上 StructSVG 的各项指标都高于直接生成。

消融（底座 GPT-4o）

• 消融怎么读：Tree 是主要贡献（先列零件清单、补齐对称部件）。Graph 在画面指标上看不出增益，它的价值在 ID Cov. / 可编辑性和遮挡检查，但消融表里没有报告这两列。Refine 单独使用有害：没有结构参照的 self-refine 会让 VQAScore 下降，说明反馈环节必须依赖规划结果才有效。
• 结构指标：直接生成的 ID Cov. 几乎为 0，StructSVG 达到 0.38–0.88。但这个指标应该是按规划节点 id 来算的，直接生成根本没有规划，比较带有“定义上必赢”的成分。Edit Score 的提升（+1.7% 到 +6.7%）幅度要小得多。

应用：编辑 / 风格 / 动画

仓库里的生成结果（原始 SVG，可以直接打开看源码）。例如 bee.svg 的元素 id 有 stem / leaf_left / petals / bee_abdomen / bee_wing_back / bee_wing_front / bee_stinger，就是规划树的叶子。

演示视频中还有风格化（同一 prompt 加 Cartoon / B&W / Watercolor / Geometric / Pixel Art / Minimalist 后缀）和长镜头 SVG 动画（夜空云飘、海底鱼游、第一人称公路）。这些都是 demo 级展示，没有定量评测；编辑器和动画工具也都不在开源仓库中。

局限与展望

• 已知局限：README 自称 research prototype，API 返回和视觉打分都会带来逐次运行的差异；画布写死 256×256；“包裹 / 缠绕 / 精确对接 / 超过 3 层遮挡”在 TreeBuilder prompt 里被直接禁止，失败分类函数也专门设了 CAPABILITY_LIMIT_WRAP_PATH 一类。这类几何不是被解决了，而是在规划阶段被绕开了。
• 质疑者会怎么说：这可以归结为 “先写 JSON 大纲再写代码” + best-of-3 + LLM-as-judge 重试 ≤3 次。(1) 算力不对等：直接生成只采样 1 次，StructSVG 最多 4 轮 × 3 个候选 = 12 份 SVG，外加规划、打分、TextGrad 的调用，却没有同等预算的 best-of-N 对照。(2) 选择信号与评测指标重叠：候选按 CLIP 选，又用 HPS 卡下限，而主表正好报告 CLIP / HPS，这两列的提升有一部分来自“按评测指标挑选”。VQAScore、ImageReward 是独立指标，GPT-4o 上 +0.23 / +1.05 更有说服力。(3) 底座越强增益越小：Gemini / Haiku 上 CLIP 只多 0.002–0.004。(4) Graph 在消融里没有体现画面收益。(5) 成本和延迟没有报告。
• 相对已有工作，唯一实质新增的东西：把“规划节点 id = SVG 元素 id”当作硬约束，并配上可以自动检查的几何关系（bbox 包含、文档顺序 = 遮挡顺序）。这让“结构”从隐式变成可以验证、可以编辑的产物；ID Cov. 和编辑器 / 动画 demo 都依赖这一点。至于提高画面质量，主要靠树（零件清单）和多候选重试，这两种手段都很常见。
• 工程细节：python_run 工具直接 exec LLM 写的代码，没有沙箱；FAIL 时会覆盖 current_best，最终交付的是最后一轮而非最佳一轮；跨任务记忆只是“LLM 总结的 8 条经验文本”，没有验证这些经验是否有用。
• 研究趋势：text-to-SVG 目前分成两条路线。一条是训练专门的 SVG 模型（OmniSVG、InternSVG、SVGThinker 用 SVG 树做 CoT 标注训练）；另一条是训练无关的 LLM agent（Chat2SVG 用 LLM 出模板再用扩散模型细化，GVR-Coder 做 generate-verify-repair）。StructSVG 属于第二条，贡献是把 3D 领域常用的“结构化中间表示”（类似 ShapeAssembly 用程序描述部件层级与附着关系）搬到 2D 矢量图上。主表中通用 LLM 直接生成的 CLIP 已经全面超过专门训练的 SVG 模型（0.28–0.32 vs 0.23–0.25），说明这个任务的瓶颈正在从“会不会写 SVG 语法”转向“有没有结构、能不能编辑”。下一步自然是把树 / 图规划蒸馏进模型本身，或者用 ID Cov. 这类结构奖励做 RL，而不是每次推理都跑 30 回合的 agent 对话。