MaLiang-Harness

先读懂三个结论，避开三个误读

• 它不是新的 diffusion / flow 模型，也没有新训练目标；核心是在推理时编辑可执行作品和上下文。
• “无需 diffusion”表示程序路径可以不依赖 diffusion；可选图片素材仍可由图像生成或搜索提供，不能推成所有示例均为纯程序、无 bitmap。
• 对当前 revision 的自评通过是 Harness 交付门槛；GPT-6-Sol 的离线质量评估是另一层证据，不能相互替代。

来源：§3 / Eqs. 1–4、Table 3、Table 5。本页未运行论文研究实验；所有实验成绩均为作者报告。

资料身份与阅读边界

本页依据 v1 的完整正文、参考文献与 Appendix §6.1–6.5，并交叉读取同版本 arXiv HTML、原始 PDF 与固定 commit 官方仓库。PDF 正文至第 14 页，参考文献第 15 页，附录第 16–22 页。作者在 arXiv 上使用 CC BY 4.0：本页中文解释为改写与分析；原 Figure、原始英文 prompt 与表格归原作者，重排、摘录和中文说明不代表作者背书。

资料可见性缺口会影响复现：公开仓库不含完整历史生成记录、完整评测数据集与论文视觉评分流水线，不能把公开 completion 报告当成 Table 3/5 的 All Criteria 结果。详细差异见代码审计。论文未给出完整历史 system / tool / reviewer prompt，也未给出足以还原所有模型条件的统一推理配置表。

P2V Gap：可执行性无法保证视觉正确性

Paper Verified Program-to-Visual Gap 指“程序层面的正确执行”与“用户视觉要求得到满足”之间的差距。例如代码没有报错，但狐狸的脚没有站在杯沿、画笔没有触到杯柄；视频能导出，却把应先发生的动作放到了后面。可运行程序只解决了必要条件，未自动解决语义、空间、外观与时间约束。[§1，PDF pp.1–4]

为什么一次写代码、渲染一次还不够？

1. 表示选择约束了可实现的外观。 Canvas / SVG 适合明确布局和几何绘制；Three.js 或 path tracing 能表达几何、材质和光传输。后端选择属于规划的一部分，不能等到最后才补救。
2. 代码修改有视觉副作用。 修正局部几何可能破坏接触、遮挡或纹理；必须比较新的实际渲染结果。
3. 没有稳定作品状态，就很难局部修复。 一轮轮重新生成会失去已有结构、素材来源及较好的旧版本。
4. 旧证据会过期。 在 revision 8 看过的正确杯柄，不能证明 revision 9 修改后仍然正确；这是 REV 必须解决的工程问题。

Our Interpretation 论文的主要新意不是“让 LLM 写绘图代码”本身，而是把可执行作品、操作轨迹与验证证据放到同一版本坐标系中。它将视觉生成与版本控制、执行审计和测试失效管理结合，形成比单轮 code generation 更清晰的研究对象。

与相邻工作的关系

以上相关工作关系依据作者的 §2，不是本页对这些工作的独立全面综述。

Table 1：能力范围是定性声明

原 Table 1 对 T2I / T2V 采用类别级概括，没有明确逐个 baseline、输入预算或评分协议。“Process Traceability 未确立”不等于所有直接生成系统都不可能提供过程记录；“可控、可编辑”也不是该 Harness 独有。最值得保留的诚实边界是作者仅将 photorealism 标为部分支持。

PEG：作品状态是一等对象

Paper Verified 输入为自然语言 prompt \(p\) 和输出规格 \(\omega\)，可含用户给定参考图像或资产。MLLM 选择后端 \(b\)，生成、执行并修改其原生 visual program，输出图像或视频以及可追踪的源文件。多个后端共享协议，但不要求共享一个统一 scene graph。[§3.1，PDF pp.5–7]

\(S_0\) 可只有任务与规格，没有可执行内容。规划更新可追加要求，却不能在同一任务里移除或削弱已有要求；独立编辑任务若改变继承要求，需引用用户的新指令。这是防止“改答案来通过测试”的设计意图，不应只把 requirements 当成可随意重写的注释。

\(a_k\) 为拟提交修改；\(\mathcal{E}\) 在参数合法且 source revision 仍是当前版本时才 commit。每次提交获得新的 \(k+1\)，并保留上一快照。\(\mathcal{R}_b\) 是后端执行与渲染，\(I_k(t)\) 是固定 revision 在内容时间 \(t\) 的画面。\(t\) 可以推进而 \(k\) 不变；plan-only commit 也可以让 \(k\) 推进而画面不变。

Our Interpretation 这是状态机与约束接口的形式化，不是概率生成模型的 likelihood、loss 或收敛定理。论文未定义新的 trainable latent、可微 renderer loss、梯度更新或参数学习过程；MLLM 调用在运行时改变 program / plan / assets / evidence，不改变模型权重。

TGP：记录发生了什么，以及它影响哪个版本

Paper Verified \(j\) 是操作序号，\(o_j\) 为操作类型，\(x_j\) 是参数，\(y_j\) 包含返回结果或错误，\(k_j^{-},k_j^{+}\) 是操作前后的 PEG revision。非提交操作如读取、渲染和检查可满足 \(k_j^{-}=k_j^{+}\)，因此操作数量与 revision 数量并不相同。[§3.2，PDF p.7]

一条 trace 至少要回答四个问题

1. 哪次程序/资产/规划操作改变了哪些快照？
2. 截图、局部 crop 或帧序列由哪个 revision 实际产生？
3. 视频证据采样了哪些 timestamps，空间 crop 覆盖什么区域？
4. 哪些已执行的修改尚未被视觉检查，哪些审查已随着后续修改而过期？

保留实际输出很重要：即使规格给了 seed，自定义代码仍可能引入额外随机性。只保存 seed 和代码不能保证以后重渲染得到同一证据。TGP 所谓可追踪性针对显式工具操作及返回结果，不声称暴露或忠实解释模型内部推理。

Our Interpretation 日志有助于定位因果候选，却不能单独证明“这处 edit 导致了美学提升”。若一次提交同时改材质、光照、几何，仍需更细粒度 diff 或干预实验区分贡献。记录 history 是诊断基础，不能替代诊断方法。

REV：最新版本，最新证据，最新批准

恢复旧内容并不是把版本号倒退：从 \(S_r\) 恢复内容（\(r\le k\)）要创建新的 \(S_{k+1}\)，记录来源 \(r\)，继续保留当前任务要求。独立编辑任务则可从选定快照建立新的 revision 序列，保留 source run / revision 的链接，并接收新用户指令。[§3.3，PDF pp.7–8]

每个视觉要求 \(h_i\) 对应 review \(q_i=(k_i,E_i,v_i)\)：\(k_i\) 为证据 revision，\(E_i\) 为特定要求的视觉证据，\(v_i\in\{\mathrm{pass},\mathrm{fail},\mathrm{uncertain}\}\)。构图/外观可以看整图与 crop；时间要求至少使用三个不同时间戳、按时间排序且覆盖指定区间的样本。三帧不是视频连续性证明。

每次 commit，包括只改 plan，都会要求重新 review 和 checkpoint reapproval。新增 observation 或 review 本身不增加 \(k\)。这是保守的全局失效策略：实现容易解释，也可能让与画面无关的改动触发重复检查。

从一次模型调用到下一次调用，数据如何流动？

下图为依据 §3 重建的 Our Interpretation 信息流，使用 Mermaid；这是本页解释图，不是原论文 Figure。下方保留等价的文字流程。页面携带论文专用 Mermaid runtime；未进行浏览器视觉验收。

flowchart TD
  A[用户 prompt 与输出规格] --> B[初始化 PEG 状态]
  B --> C[MLLM 读取状态与当前证据]
  C --> D[拆解要求 选择后端 规划 checkpoints]
  D --> E[提交 program assets 或 plan 修改]
  E --> F{source revision 与输入合法}
  F -->|否 返回错误| C
  F -->|是| G[新 revision 保存快照与 TGP]
  G --> H[执行渲染 整图 crop 时间样本]
  H --> I[同 revision 视觉观察与逐项 review]
  I --> J{当前版本满足 Ready}
  J -->|是| K[最终导出并标记完成]
  J -->|否| L{预算尚有且可继续}
  L -->|是 局部修改或恢复历史内容| C
  L -->|否| M[停止 保留草稿或失败状态]

1. 初始化：将 prompt、输出规格和要求放入 \(S_0\)，可从空程序或旧作品开始。
2. 规划：MLLM 识别构图、对象、材料和时间事件，选择后端，建立 plan / checkpoints。
3. 动作：模型输出工具调用，修改 program、asset 或 plan；Harness 负责验证输入、revision 和合法操作。
4. 环境反馈：后端执行代码，返回错误、导出信息、整图/crop/帧序列；TGP 保存操作与实际证据。
5. 自评与上下文更新：模型将当前证据和 requirements 对照，写入 review；下一次调用使用可读取的持久状态与反馈。
6. 继续或退出：需要修改时局部编辑、重新规划或恢复旧内容，产生新 revision；Ready 通过才完成，预算耗尽只能终止，不能冒充完成。

Agent 术语分别对应什么？

Our Interpretation 从 Agent Optimization 的角度，实际优化对象是 artwork program、素材选择、plan、当前上下文与 test-time trajectory；Harness 固定提供工具和版本规则。论文没有系统搜索最优 prompt、工具定义、memory policy、evaluator 或树搜索策略，也不应把普通 iterative editing 称为已经实现的 test-time search 算法。

Algorithm 1 / 2：植物肖像如何从程序变成像素？

Paper Verified Figure 4 的 botanical portrait 在固定 PEG revision 上用 Canvas 绘制，未使用图像 assets。Algorithm 1 为简化构造，Appendix Algorithm 2 扩展四层绘制步骤；两者都不是完整 Harness agent loop。[Algorithm 1，PDF p.6] [Algorithm 2，PDF p.17]

画布为 \(1024\times576\)，\(\mathbf{c}\) 是中心像素坐标；\(s\) 为固定 seed，\(\ell\) 区分绘制层。26 个分支沿环分布，\(\epsilon_i\) 和 \(u_i\) 提供角度/半径扰动，\(\mathbf{p}_i\) 定义枝条位置。论文未给出这些噪声的完整数值分布及所有 Bézier 控制点，因此该算法是操作摘要，不是可直接运行的源代码。

为避免原文符号复用混淆，本页将花瓣层索引改写为 \(m\)：\(n_m=[8,7,6,5,4]_m\)，\(\phi_{m,j}=2\pi j/n_m+\delta_{m,j}\)。这只是说明性重命名；原 Algorithm 1/2 的 \(k\) 是花层编号，不是 PEG revision。

Our Interpretation 此例说明“程序是可组合构造表示”这件事，而没有证明模型学到了通用绘画算法。预设玫瑰坐标、人工样式规则、后端表达能力以及生成程序的长度都可能决定结果；需要检查真正生成的源码和运行轨迹才能做复杂度或可控性结论。

实验究竟测量什么？

来源：§4.1，PDF p.8、Appendix §6.2，PDF p.16。

统一分母：防止 survivor bias

下面公式是对论文报告规则的 Our Interpretation 统一记法。令 \(N\) 为全部任务数，\(s_n\in\{0,1\}\) 表示任务是否成功；\(q_{n,d}\in\{1,2,3,4,5\}\) 为成功输出在质量维度 \(d\) 的评分，图像 \(D=3\)，视频 \(D=4\)。失败任务没有质量分数。

Success 需要“输出可解码 + Harness completion checks 通过”。All Criteria 需要成功输出的每个维度都至少 4 分。成功率和质量通过率以整个任务集为分母；均值只以成功子集为分母。没有成功输出时均值与 Time/Success 未定义，不应填成零分。Token Limit 只是 failures 的一个子集，不是所有失败原因。

图像：完整结果与真正的短板

Table 2/3 按原值重建，保留全部 11 个模型与原有单位；粗体保留原表的最佳 GPT 标记，不将低成功覆盖的 DeepSeek / Kimi 均值混作全数据集最优。原表未标第二名。本页采用中性样式避免把成本表中的“数值较高”误读成“更好”。

四个应当一起看的读数

1. Astra：48/50 全部达标。 成功 50，alignment ≥4 的 48，aesthetics / composition 均为 50。因此最终两个质量失败来自 alignment，而不是执行失败。
2. GPT-6 三模型的瓶颈一致。 Luna、Sol、Astra 的成功输出全部通过美学与构图阈值，All Criteria 分别 44、46、48，与各自 alignment 阈值数一致；当前样本上的剩余差距主要是要求遵循。
3. Luna / Terra 揭示 P2V Gap。 GPT-5.6-Luna 和 Terra 都完成 46/50，但全维度达标只有 22/50 与 24/50。对 Luna，24 个“成功生成”仍不满足所有质量条件。
4. Kimi-K3 的 4.56 不能视作全面胜出。 它的 alignment 均值高于 Astra 的 4.36，但只基于 9/50 成功输出；相应全任务质量通过率仅 18%，Astra 为 96%。

前三个数值对比为据 Tables 2–3 的算术推导，非统计显著性结论。数据量小且尝试聚合不统一，不能据此给通用模型排行榜定论。

Paper Verified Figure 2 的六个轴先在全部 11 模型间排序，再分组画图；高质量/成功率更好，少时间/少 token 更好，并列用平均名次。半径为 \((12-r)/11\)，第一名在外缘。面积不是 aggregate score，径向距离不是原始效果差；早失败还可能显得“节省”。[Appendix §6.3，PDF pp.17–18]

视频：时间要求比画面漂亮更难满足

四个模型依次成功 0、3、7、13 条视频；通过全部四维度的分别是 0、0、5、10 条。Astra 的 10/13 = 76.9%，GPT-5.6-Sol 的 5/13 = 38.5%，均以全体任务为分母。若只看成功视频的条件通过率，后者是 5/7 ≈ 71.4%，但不能将它与 76.9% 偷换比较。[Table 5，PDF p.11]

• Astra 的 aesthetics 13/13，但 motion 10/13；运动是它最严格的单项瓶颈，不能用静帧质量代替视频质量。
• GPT-5.6-Sol 的成功视频 alignment / aesthetics 均为 7，composition 与 motion 各为 6，但联合达标只有 5，说明两个维度的失败样本不能简单视为同一条视频。
• Kimi-K2.6 三条成功视频全部不满足 alignment 和 motion 阈值；“成功”依然只证明满足运行和自评 gate。
• DeepSeek 的所有质量 counts 为 0，是因为无成功输出接受质量评分，不能说 judge 给每个视频打了 0 分。
• Token Limit 失败数 5、1、3、0，仅解释各模型失败的一部分。提高 token budget 可能缓解截断，却不自动解决规划停滞或视觉错误。

Our Interpretation Astra 相比 GPT-5.6-Sol 的全任务质量通过率提高约 38.46 个百分点，达标条数翻倍；代价是累计时间 2.17 vs 1.08 task-hours。每成功视频 10.00 vs 9.27 分钟仅高约 7.9%，原因是成功分母从 7 增至 13，而不是单条尝试同样便宜。

Figure 11 展示三类任务，每个模型一排5 张均匀采样帧；这只是展示方式。质量评估实际用12 帧，运行中 REV 的时间证据最低要求是至少 3 个不同时间戳。这三个数字属于不同环节，不能混为一个评估协议。

代价表能说明配置表现，不能直接给公平效率排名

以上为 Our Interpretation 记法：若 \(T_{\mathrm{cum}}\) 用小时，上式乘 60 转成分钟。原表时间经过四舍五入，因此由已打印的 2.71 小时与 6 张计算得到约 27.10，不必恰好等于原始精度计算的 27.15；不能据此声称表格错误。

Appendix §6.2，PDF p.16 明确承认预算、计时和条件不同。这些不是本页猜测，应在阅读主表时一并保留。

Our Interpretation 逐项算术还显示，不能对所有图像行默认使用同一恒等式。例如 GPT-6-Luna 的 Total Time 3.61 task-h 若除以50，应为约4.33 min/task，并非表列3.27；DeepSeek-V4.1-Flash 的同类换算约3.25，而表列1.91。附录承认混合批次/重试与不同聚合口径，但未逐模型解释这些具体差值。本页保留原表，不擅自改数或猜测分母；完整运行日志仍是澄清所需资料。此问题与前述四舍五入造成的小差异不同。

如何解释“通用能力不能完全预测视觉生成”？

Paper Verified 作者使用 2026-09-27 访问的 Artificial Analysis Intelligence Index v4.3.2 显示整数分和对应 reasoning 配置，与 All Criteria / 50 比较。11 模型 Spearman \(\rho=0.65\)；剔除 checkpoint 不确定的 DeepSeek-V4-Pro 后为 \(0.63\)。两代 Luna 的 AA 均为 37，但通过率 44% / 88%；Kimi-K3 的 AA 为 44，而通过率 18%。[§4.3 / Appendix §6.3]

Our Interpretation 数据支持“有正相关，但分数不能充分预测特定系统表现”，不支持“通用能力无关”。公共分数的 reasoning、API checkpoint、预算和本实验未必一致；V4-Pro 的公开分数为 0813 checkpoint，其与实测版本对应关系未经验证。11 个数据点、显示整数分与非统一运行条件不适合强因果推断，也没有报告相关系数置信区间。

定性案例：哪些证明了可行，哪些暴露了失败？

Figure 6：同一 prompt 的实现差异

五行依次是杯沿狐狸、山地茶屋建筑板、银杏叶小提琴兔、六个园艺机器人、温室工作台；五列是 DeepSeek-V4.1-Flash、Kimi-K2.7-Code、GPT-5.6-Sol、GPT-6-Sol、GPT-6-Astra。黑底白叉是失败 run，不是空白图质量得分。观察重点应是接触关系、主体比例、精确数量、面板结构及写实材料和扁平角色如何混合。作者认为 Astra 在这些选例中有更强材质和光照细节；这属于选例证据，不是风格覆盖的独立量化评测。

Figure 7：更强 renderer 能扩展表示，但仍会出错

早餐静物不依赖 generated image assets，先用 raster preview 确立布局，再用 path tracing 检查物理材质、面积光、反射、玻璃透射与接触阴影。修订包括支撑高度、勺子几何、减少黄偏、木纹与饼干细节；最终采样从 512 增至 1024 以降低噪声。将环状压痕替换为表面 mesh 后出现重叠伪影，再通过变薄、降低饼干基底减少它，最终图仍保留 draft 状态。它展示 PEG/TGP/REV 的诊断用途，却不是 path tracing 提升 photorealism 的受控实验。

Figure 8：细笔触不等于更写实

在不换 Canvas backend 的情况下，Astra 修改绘制 routine，让草木、石、水、木材的线条更细。整体布局保留，但草的覆盖、石头独特斑纹和山体纹理部分消失，图像仍然 stylized。写实需要协调形状、明暗和纹理，缩小笔触没有自动恢复这些关系。后续 inspection 未产生有效纠正，最终耗尽 token budget：这是论文主动展示的负结果。[§4.3，PDF pp.11–13]

(b) Construction trace in pseudocode

Require: Figure brief B, synthetic data D

Programmatic construction
 1  S ← InitCanvas(2048,1152)
 2  Draw architecture and arrows in S.                 ▷ a
 3  Draw bars from D; reserve photo cells.             ▷ b,c
 4  Draw learning curves and ablation table.          ▷ d,e
 5  Draw schematic contact-state clusters.              ▷ f

Asset generation and selection
 6  L ← [2×5, 2×5, 3×3, 2×4]
 7  for k = 1,…,4 do
 8      A_k ← GenerateAssets(B,L_k)
 9      Inspect A_k against photo requirements.
10      Record provenance; revise the next prompt.
11  end for
12  A* ← A_3                              ▷ choice in this run

Composition and verification
13  Crop and place A* in the reserved cells.
14  Overlay labels using code.
15  I ← Render(S)
16  Inspect the full image and detail crops.
17  Add notices for unresolved photo requirements.
18  I ← Render(S)
19  Q ← Review(I,B)
20  Export I as PNG; retain draft status under Q.

Figure 10：追踪来源比只看最后一张图更重要

六面板“research figure”示例用程序完成布局、架构箭头、标签、用户给定合成数据的柱状图/曲线/消融表及示意 contact-state clusters；摄影风格操作图则由图片资产生成补充。Trace 记录四次 contact-sheet 尝试：2×5、2×5、3×3、2×4，最后选第三次的 crop，用代码摆放和标注。数字图表与布局通过，但摄影例子仍不满足要求，所以保留草稿状态。

三种停滞应分开诊断

PEG 可以保存，TGP 可以看见，REV 可以拒绝过期证据，但它们不保证下一次 edit 有用。终止与完成是两个状态：预算边界能保证运行被截断，只有 successful finalization 才应标记 completed。

公开 prompt：要求足够具体，验证才有对象

Paper Verified Appendix §6.4 公开 Figure 6 的五个图像 prompt，加一个精确布局例子；§6.5 公开 Figure 11 的三个视频 prompt。论文说明原中文 prompt / 展示文字被翻译成英文呈现，评测使用原措辞；Star Delivery 同样是中文译本，其余两个视频 prompt 原本为英文。下面完整保留附录公开的英文内容与链接，不能把译文当作所有历史运行的逐字输入。

精确布局 prompt 的意义

“museum triptych exhibition board”例子要求 2048×1152、共15矩形、每个 ID 恰好一次、无重叠、坐标和颜色准确，仅用 SVG / Canvas。坐标 [x,y,width,height] 的横纵轴分别归一到0–1000。若转换为像素，\(x_{\mathrm{px}}=xW/1000\)，\(y_{\mathrm{px}}=yH/1000\)，宽高同理；这个换算是本页说明，并非新增学习模块。将两个轴都按同一像素尺度解释会错误地得到正方形布局。

原 prompt 指定 coral red #FF6B6B、sky blue #62CBE8、magenta-purple #D86BDA、golden yellow #F4C95D、mint green #72C7A0、lavender #A999E8。列表实际未分配 mint-green 矩形，不能为了“用齐配色”添加第16个。它展示文本可承载结构化约束，但不是证明所有坐标自动由确定性 checker 验证。

附录公开原始文本

英文原文依 CC BY 4.0 收录；仅调整段落/表格排版，数学尺寸用 MathJax 表示。下列 prompt 是任务输入，不是 system prompt、工具 schema 或完整 judge rubric。

没有公开的部分不能补造

论文未公开完整历史 system prompt、few-shot、所有工具定义、retry / reflection / evaluator prompt 与离线评分 rubric，也未列所有模型的 temperature、top-p、top-k、统一 decoding / sample count / API checkpoint。公开仓库的当前提示词可作为 Implementation Audit 来源，但与论文历史版本是否逐字一致必须另证。复现时尤其不能根据几条示例 prompt 推断整个50/13任务集。

固定版本的官方代码审计

核查日期：2026-10-01 UTC。范围：只下载、阅读官方代码、测试定义、文档和项目页；没有安装仓库依赖、执行仓库代码、运行模型、渲染案例或复现实验。以下 Implementation Audit 仅表示指定版本的静态源码证据。

1. 最重要的结论

1. PEG / TGP / REV 不是只存在于论文里的名称。公开实现确有内容寻址的程序/素材、不可覆盖的 revision snapshot、expected_revision 检查、保存的操作/渲染证据、当前版本 review/checkpoint 和显式 finalize gate。
2. 该 gate 验证的是「当前版本满足程序检查，且模型已提交有效格式的自评」，不是一个独立的视觉质量判别器。没有自动将 GPT-6-Sol 的实验质量分数反馈给生成器。
3. 完整实验复现仍有实质缺项：作者明确没有发布完整数据集、历史生成结果、完整视觉打分流水线和历史实验脚本。不能把 public report 的成功率当成论文的 All Criteria。
4. 公开代码比论文抽象描述更具体、更受策略限制：silent-video policy 忽略音频需求；PNG 最终导出固定 t=0；普通视频的「检查最终编码视频」主要是 prompt 指令，并非统一硬性验收项；真正强制 final-image 证据的是 Pathtrace 分支。
5. 上下文刷新、图片过期、16步批处理、恢复失败批次、可选素材策略和各种预算都影响结果。这不是只改一个 system prompt，也不是权重训练、可微逆渲染、树搜索或自动优化过的 harness。

2. 版本和资料 provenance

• arXiv：2609.34309v1，2026-09-28；从该论文 abstract 的官方项目链接解析到 https://github.com/gulucaptain/MaLiang-Harness，没有猜测仓库名称。
• 代码 HEAD / main：c811b47f63ff1748d85b2dc2e9c4169385d4b46f，提交时间 2026-09-29 11:43:38 +08:00，commit message 为 init。该提交晚于论文 v1，不能断言它就是表2–5实际运行的历史代码。
• 本次 git ls-remote --tags origin 没有返回标签。没有据此断言不存在 GitHub Release；Release 页面抓取未成功。
• package version：0.1.0；Python >=3.11，README 建议3.12。Deep Agents 0.7.15 vendor pin 为 bc3c2935650f8e8a0862d51226d986d842bd3824。
• 项目页：https://gulucaptain.github.io/MaLiang-Harness/ ，来源为 README 顶部 Project Page 链接；page 分支当时 HEAD d1572c1546b8c33edcc3b8d921cd8f11f2d95009。此处记录的是分支参考，不宣称已验证部署构建恰好来自此 commit。
• 项目页 catalog：https://gulucaptain.github.io/MaLiang-Harness/assets/catalog.js 。下载后以 JSON 数据解析，没有执行 JavaScript：45个展示 output；32个图像（包含3个明确标记 offline renderer demo），13个视频；非demo独立 case_id 共40个。catalog有原始prompt、媒体URL、尺寸、时长等，没有模型版本、完整run config、score或程序源字段。精选展示不等于已发布完整 benchmark。
• 未发现另一个独立官方数据集/补充材料下载链接。论文附录见本页相应章节；项目页含更多精选实例prompt，但不是可替代历史运行记录的 Supplement。
• 项目页视觉作者栏少列 Yu-Gang Jiang，但页面 BibTeX 与 arXiv 都列七位作者；论文网页作者以 arXiv/PDF 为准。

版本来源：pyproject、vendor provenance、缺项披露、历史实验脚本不公开

3. PEG：真实数据对象与状态转移

数据模型

Artwork 对应论文状态 S_k，含 revision、prompt、OutputSpec、allowed_backends、allow_generated_assets、requirements、plan、video_plan、objects/events/assets/asset_tasks/program，另有 workflow_policy、capability_assessment、planned_backend、components、checkpoints。没有一个所有后端共用且独立维护的 Z 字段：Scene2D的objects/motion是显式结构；Canvas/SVG/Three的几何和时间函数可直接写在程序内。这与论文「Z可嵌于P而不必独立scene representation」一致。

程序和素材保存 path + SHA-256；Scene2D 每个对象的 draw 程序也有独立hash。store.blob 保存为 blobs/.；snapshot为 versions/.json；artwork.json指向当前完整状态。_commit拒绝覆盖已有revision，并把status重置为working。

mutation与约束

mutate(expected_revision, change)：锁 → 读取当前状态 → 检查expected_revision → 应用change → revision+1 → Pydantic验证 → 新snapshot与current写入。即使change只修改plan或不改变像素，也会+1；不是把视觉上相同的状态折叠成同一revision。失败验证不会commit。

update_artwork只能更新plan/objects/events。add_requirements只追加。plan_creation若已有requirement ID的全部字段不完全一致就拒绝，随后要求checkpoints覆盖所有hard requirements（silent video audio例外见下）。因此单次生成run里不能通过普通plan工具删除或弱化既有要求。

但需求分解语义仍由模型完成。系统可以阻止删除一个已存的constraint，不能自动证明模型已经把自然语言prompt中的每个约束正确编码。CLI通常补入brief_fulfillment，以及render_clarity/video_motion；portable benchmark loader默认只补brief_fulfillment，进一步拆分交给模型。

restore与新编辑run

restore不是把revision倒回r。它从历史snapshot复制plan、video_plan、objects、events、assets、asset_tasks、program，然后使用普通mutate产生k+1；当前requirements、prompt、spec、allowed_backends、workflow权限保留。当前capability_assessment/planned_backend/components/checkpoints也未被历史内容覆盖，因而恢复到不同后端可能需要再plan才能过当前gate。

独立编辑run则复制选中snapshot的程序/素材且校验hash，revision重置0，workflow改guided，capability_assessment和checkpoints清空，保存source_run/source_revision与latest user instruction，并新增edit验收要求；新run不复制旧reviews。图像生成在edit session强制禁用，重点是继承代码、对象和既有素材。

revise_edit_requirement仅在edit.json存在时注册，只允许inherited requirement，要求instruction_quote为最新用户指令的substring并保留hard/capability字段。它并没有用独立语义验证器判断「引用是否真的授权该变化」；reason与保留无关clauses主要依赖模型遵循prompt。

证据：Artwork、commit/mutate/restore/blob、plan requirement保护、mutation scope、edit run、CLI默认要求、benchmark默认要求

4. TGP：operation、evidence与模型上下文

Registry.invoke计tool budget、验证schema，记录tool_start（名字、完整validated arguments、起始revision）；成功/失败记录tool_end（返回值/错误、耗时），mutation还另记from→to revision，部分领域工具写visual_operation。图片base64从trace中的工具返回中移除，但真实图片另存在evidence文件。它实现可追溯的显式操作，而不是隐藏思维链。

论文的tau_j是概念元组。代码不是每一步都保存一个含k−/k+的独立统一结构，而是通过tool_start、返回revision、revision事件与串行执行重建。schema validation发生在tool_start和try之前，所以参数schema本身出错不保证出现完整的一对Registry trace事件；不要写成任何错误都具有完全相同追踪格式。

Evidence含id/revision/kind/paths/timestamps/metadata。Preview保存frame_details；requirement observation关联requirement_id、parent evidence、object或crop region、timestamps。新增evidence/review不产生Artwork revision。缓存key包含整个Artwork（含revision）、times、renderer_version；plan-only revision因此也改变render缓存key。Observation复用限定当前revision。

每次MLLM调用，middleware从artwork.json重建CURRENT AUTHORITATIVE STATE，包含revision/spec/剩余budget/object/assets/components、plan/requirements、verify报告、runtime capability和workflow progress，避免把对话记忆当成状态真相。过去所有文字仍被保留在MaLiang自己的图片裁剪步骤内；同一请求图片去重，默认只保留最近4个含图片message，超过1个后续AI turn的图片从出站请求移除，已保存证据不删除。模型若需再判断必须重新observe/inspect。再上游Deep Agents自带summarization会进一步影响长上下文，所以不能笼统承诺全历史永远在模型上下文。

证据：Registry trace、Evidence schema、image context、authoritative context、upstream summarization接入

5. REV与Eq.4：硬检查到哪里为止

实际通过路径

1. plan_creation确定后端、追加要求并设checkpoints。
2. write/patch/对象/素材工具commit新版本。
3. observe_requirement(s)按每个requirement的ObservationSpec获取当前图像；temporal count=max(spec.samples,3)，在start至end间等距采样。end默认duration−1/fps。
4. 模型看图后record_review，为每个要求提交pass/fail/uncertain、explanation、evidence IDs。工具标注source=model和independent_quality_assessment=False。
5. guided visual/style/temporal的pass必须至少含一个绑定当前requirement的frames/crop，所有evidence revision必须当前，temporal必须来自自身绑定evidence的≥3 distinct timestamps。其他requirements/decoded-video/export可作补充，却不能填补自身temporal样本不足。
6. complete_checkpoint检查该checkpoint列出的要求都pass或被政策ignored，写当前revision记录。
7. export_artifact生成输出而不宣告成功；finalize_artwork调用verify后才写completed，否则返回needs_revision。普通文本说“完成”不会跳过gate。

verify具体内容

• program存在和hash；Scene2D至少一个object、每个绑定draw及hash；所有asset文件存在且hash一致。
• guided必须capability_assessment+checkpoints，实际program backend等于planned_backend，hard requirements覆盖，每个checkpoint记录等于当前revision。
• object_exists仅查对象声明；event_order仅查声明时间段排序，源码明确说不能证明可见性或实际视觉时序。
• visual/style/temporal读取当前revision reviews；fail、uncertain、未review都阻止hard要求通过。
• export必须当前revision、kind=export；PNG尺寸/格式；MP4视频stream、尺寸、fps误差<0.01、duration误差≤1/fps+0.01、实际解码帧数=ceil(duration×fps)。
• Pathtrace额外要求final模式、final quality、完成请求sample count，以及hard视觉reviews关联该final export。
• 最终 eligible_to_finalize = all technical checks && all hard requirements pass && export_id != None。

不应夸大的部分

• 对每次commit，包括只改plan：reviews()只选择当前k，旧checkpoint k不匹配，所以全部旧review/checkpoint失效，不是只失效“受影响的局部”。
• observation/review记录不是独立评价；模型可以错误相信自己完成了要求。源码没有内置GPT-6-Sol judge、审美损失、CLIP loss、critic reward或稳定的quality improvement阈值。
• inspect_video(final_export)在system prompt中被要求，但普通verify没有专门验证所有video reviews都绑定最终编码视频；requirement evidence通常由重新render原始frame得到。这与Pathtrace强制final PNG review不同。可在“实现边界”说明，不能假称所有视频必然经过编码后视觉验收。
• verify对source/assets查hash；finalize本身没有统一重查export metadata.sha256，也没有在最终gate逐个重新读取所有review引用的evidence。它在record_review时已检查证据文件存在/当前revision。公开benchmark worker另行重查export hash并完整decode，因此worker success比裸finalize多一层artifact检查。
• temporal至少3点且按区间采样，只能支持离散判断，不证明帧间连续性、碰撞一致性或完整运动质量；论文也明确承认此点。
• 视频音频例外：MP4中的audio_track requirement被标为ignored，hard=false，不要求覆盖/通过；system prompt和user message都要求只交付silent video并忽略声音请求。PNG任务若要求audio则fail。这是清楚的任务范围裁剪，不是音频能力。

证据：review绑定和k失效、requirement采样、checkpoint、完整verify、finalize、worker二次检查

6. 可执行表示、渲染器和外部模型

Pathtrace不是任意材质节点图系统：geometry枚举sphere/box/rounded_box/plane/cylinder/torus/lathe/tube/extrude/mesh；material ceramic/metal/glass/plastic/wood/liquid/matte。最多256objects、64materials、8lights；估算几何预算100万triangles；默认preview16、final128 samples，final上限1024，bounces默认6上限16。它能调材质参数，但不是学习节点拓扑或Differentiable Material Graph。

通用限制：PNG宽高32–4096；MP4每边≤1920且偶数；duration≤120s、fps≤30、每export≤3600frames；preview≤12frames；Canvas/SVG程序约250KB。PNG export实现固定t=0；任意t可作为preview，不是公开OutputSpec中的最终静帧时间参数。

视频按t_i=start+i/fps逐帧渲染，每批24帧，libx264/yuv420p/CRF18/preset fast编码，不生成audio stream。画面来自代码时间函数，不调用视频生成模型。

程序render通过独立Python worker启动Chromium；只传少数环境变量、不传API key；CSP/route拦截外部网络，Three bundle由内部地址映射到本地文件。源码自己声明这不是hardened multi-tenant sandbox，不应将浏览器隔离当成安全证明。

可选image generation是Qwen（qwen-image/qwen-image-plus）或OpenAI images API，TEXT ONLY输入；不是图像编辑、depth、segmentation或视频model。公开root config默认Qwen开启，quickstart关闭；设置enable+key+task allowance三项都满足才注册generate_asset。新编辑run关闭生成。没有发现实际内置image search工具，论文“generation or search”中search应视为概念可选方向/扩展能力，不能说此默认release已经接入搜索。

code_directed策略会要求至少一个code route、scene2d生成组合、有代码对象和目标placeholder、target region约束、conservative最多一个generated component、引用brief与给出code limitation/minimal scope。但“substantive code”“确有必要才生成”“先观察并code-refine”仍主要依赖prompt语义；相比之下code_first_repair分支真的要求current failed/uncertain observation/review。背景生成必须用户许可在prompt里声明，但其机械校验只检查layout/brief quote等，未独立判定真实用户授权语义。

证据：renderer contracts、spec limits、Pathtrace schema、video+export、worker isolation、generation注册、两种素材策略的不同机械门槛

7. Prompt、模型调用、预算、重试与恢复

公开prompt完整性

完整当前system prompt公开于agent.py L80–251，可直接链接作为全文模板；不要把它说成论文历史实验的已确认逐字prompt。模板包括CLARITY、VIDEO、code-first/component routing、素材管线、EFFICIENCY、Pathtrace、Paint、REV、自评和silent-video policy。

运行时拼接：agent.py L335–389的CURRENT AUTHORITATIVE STATE；L415–475的user内容，包含原prompt、编辑上下文、输入图和silent-video message。工具schema+description由各Capability注册生成；因此真实request不是仅这段system文字。

prompt内存在具体不一致：L96–109推荐本地Three.js，而L139–140仍说Three.js/WebGL unavailable；代码确实注册Three并给video允许它。可解释为遗留提示冲突，不能据此声称Three后端不存在。此类冲突也说明需要固定prompt版本分析结果。

渲染清晰度heuristic：Canvas/SVG拦截text draw估算px<12的小字，最多记录12示例；不测bitmap文字，也不证明遮挡后可读。Prompt推荐正文≥16px、dense CJK≥20px，两者不是同一个硬阈值。

Controller和上下文

CLI使用LangChain ChatOpenAI的Responses API，max_tokens=12000、parallel_tool_calls=False。temperature/top_p默认未显式设定；不能编造其值。create_deep_agent以StateBackend + SQLite checkpointer运作，屏蔽task delegation；是单控制模型的工具调用循环，不是多agent辩论。

recursion_limit=400、max_concurrency=1；结束状态completed/draft可在下一次模型调用前直接跳出；模型普通结束但未finalize时，若有export记录draft，否则incomplete；预算异常记录budget_exhausted，其他异常failed。single-shot/generic-agent模式也存在，但公共cross-LLM benchmark强制mode=maliang；代码有baseline模式不等于论文报告了其消融。

默认配置不等于论文setting

两者均单API timeout300s、SDK retries0、每次max output12000、max batch16、recent image messages4、replay turns1。代码Budget class默认值又不同（24/80、300k/60k等）；读者必须说明实际加载哪个config。root图像2048×1152，quickstart512²；视频默认1280×720、3s、24fps。Benchmark tasks可覆盖spec。

Meter对model/tool/frame/asset call按操作计数、对tokens依据provider返回累计；调用前查token是否已到limit，调用结束后才加实际tokens。因此总token budget可能被最后一个response越过，非严格预留每次请求最大开销。elapsed包含该run的实际经过时间；resume读取usage.json，不重置累计限制。

三种“重试”不要混用

• 工具纠错：handler error转为error/current_revision/recovery hint，模型继续修正。execute_steps最多16顺序子操作，非原子事务，每个子操作单独计tool；成功步骤不回滚。
• batch恢复：失败保存batch和未执行code；resume_steps只能在revision仍等于保存值时恢复，可替换失败step参数，先前成功步骤不重复。
• 重新运行benchmark：--resume默认跳过所有已尝试任务（包括失败）；--retry-failed必须显式给出，创建全新attempt/project，不把旧输出当新任务输入。报告分别first/latest和all-attempt成本。

Qwen还有服务job恢复：按请求fingerprint保存asset_job；超时同asset_id继续poll而不重发；POST结果不确定时阻止自动重新提交，避免重复付费。它不是为了挑最好图的无约束best-of-N。

证据：完整system prompt、create_model、loop/status/budget、Meter、batch/resume、root config、quickstart、Qwen job恢复、clarity heuristic

8. 公开评测与论文实验之间的边界

实际公开了什么

• 公共pipeline：plan冻结任务/model config、输入bytes/hash、源码fingerprints；run每job独立进程、默认2100s硬timeout；report零model calls产生JSON/CSV/MD。
• repo只附blue-circle PNG和moving-sun MP4两个任务；前者512²，后者640×360/3s/12fps。项目页另外提供精选输出及原始prompt（见第2节）。
• model client支持responses/chat_completions；temperature与extra_body仅用户显式提供才传入。
• Kimi adapter保留完整reasoning_content用于多轮Chat Completions、默认disable_streaming=True。Kimi-K3是同一实现的命名入口。
• text_only adapter严格限定deepseek-v4-pro+Responses，去掉user与tool中的所有image块，并加“没有视觉反馈、不能声称看过图或编造pass”的说明。它与其他模型的输入条件实质不同。
• worker success需要无异常、status=completed、status/evidence/artwork/validation同revision、media有效、全部technical check通过且eligible_to_finalize。
• report保留first/latest outcome、每次attempt、累计time/tokens；denominator是全部planned jobs（即未执行也会降低显示比例）。它不自动算quality，也不计算美元价格。

不能从仓库复现/证实的内容

• 50图/13视频的完整历史benchmark manifest、全部输入与全部输出、逐项质量分数、judge具体实现/全prompt、历史model/API snapshot、特定批次手工重跑脚本与记录未公开。
• review_template.csv仅创建空的brief_fulfillment/visual_quality/motion_consistency/preference/reviewer列，不是论文alignment/aesthetics/composition（+motion coherence）的完整GPT-6-Sol评分器。
• public report把first/latest尝试分开；论文Appendix披露混合多批次、重试与历史runs，但不能仅由这段说明推出一套统一best-of-N或逐样本挑选规则，也不能用当前report语义倒推历史表格。
• 同一公开harness不保证公平的等算力或等视觉输入。不同adapter、provider token accounting、API latency、素材能力、budget/profile都必须一起报告；尤其DeepSeek-V4-Pro无视觉。
• 作者package依赖部分用range；historical Python3.12 snapshot不含package hashes/platform markers，且作者明确未验证fresh跨平台安装，不能当完整lockfile。
• 本审计未运行repo测试；tests/test_guided.py和test_review_completion.py有对stale evidence、temporal samples、checkpoint invalidation和silent-audio policy的回归测试定义，这仅说明作者写了覆盖用例。

Appendix 6.2 已交叉核对的历史条件

• 图像不是统一first-attempt实验。Astra：38个新任务产生39次attempt，另加12个historical runs；总覆盖50prompt。新run用worker wall time，历史run用不含startup的elapsed generation time；Astra per-task总量（含retry）除50。
• Kimi Calls除50；Time/Task取successful tasks中位数；token统计用recorded total除successful task数。同名表头不是统一口径，不能据此作严格模型效率排名。
• 视频每model/task报告一次recorded attempt，共13任务；per-task时间/calls/tokens除13。DeepSeek用完成的64K output-limit batch，未完成32K batch被排除；Astra为historical runs。没有公开一套覆盖所有模型的完整历史budget配置。
• 23个successful视频由single reviewer基于prompt及12个有序帧评价，未正式blind；第4.1节说primarily GPT-6-Sol，但Appendix的single reviewer措辞本身没有单独明确人类/模型身份，不能补写成“单个人工标注员”。

这些是 Paper Verified 的协议披露，不是本审计复现所得；来源：论文 Appendix 6.2。

证据：worker success、plan冻结与retry、report真实列和成本定义、client设置、text-only、Kimi、dependency caveat、测试定义，未运行

9. Paper vs. Implementation 对照

10. 建议的技术定位与后续研究（Our Interpretation / Research Extension）

MaLiang-Harness优化的是test-time执行过程：模型交互上下文、工具契约、状态持久化、证据绑定、工作流门控、失败恢复和预算管理。生成过程中模型改的是program、对象/参数、plan、局部素材与review；没有更新backbone权重、训练renderer或学习统一latent。人工设计的harness本身并未被论文证明通过学习或自动搜索得到。

优先扩展：严格区分prompt instruction与程序gate；增加可配置的encoded-export证据约束；将自然语言需求解析为外部审核过的task-level checks；在不同revision上做受控局部变化和独立critic评估；比较等budget generic/single-shot/PEG-only/PEG+TGP/full-REV；报告全部attempt与多seed方差；发布manifest、历史config和judge prompts；把generation、self-review和independent quality judge分离，并测量自评误报率。连续视频可增密event boundary/occlusion采样和客观temporal checks，但不能把有限帧抽样称作连续性证明。

停止条件：本次下载和静态审计已经建立以上源码证据。没有执行测试/模型/渲染，因此不产生复现成功率、性能测量或安全保证。

复现准备：先做协议复现，再谈论文成绩

本页未调用付费模型、未执行研究代码、未渲染论文案例或重新评分，网页语法检查也不是实验复现。以下是 Our Interpretation 的可执行研究计划，公开材料不足处须保持阻塞标记。

1. 固定材料：保存 arXiv v1、公开代码 commit、依赖锁文件、浏览器/renderer/encoder 版本、字体、seed 与资产 hash。将论文历史记录与新实验严格分开。
2. 先验证 state invariants：构造极小 Canvas/SVG 图案，测试 stale source revision 拒绝、commit 单调增长、restore 保留当前 requirements、旧 review 失效、缺证据 finish 拒绝。
3. 单任务端到端：选择完整公开 prompt，记录每次模型输入输出、工具返回、截图 revision、采样时间、所有失败与预算退出，核实最终输出与 source/assets manifest 一致。
4. 统一模型条件：明确每个模型的 API snapshot、reasoning、视觉输入、token/time/tool/model-call budget、重试政策。某模型不支持视觉时独立分组报告，不能直接视作同等条件。
5. 获得完整 benchmark 和 judge：若无法取得全50/13 prompt、历史结果、评分模板和 judge snapshot，只能做新实验，不应声称复现 Table 2–5。
6. 首轮与重试分开统计：同时报告 pass@1、固定 K 次尝试预算下成功率、各次失败、best-of-K 选择规则、总 token/时间和美元费用。
7. 独立视觉评价：固定原 prompt，随机打乱输出身份，使用多 judge 与人类子集；视频增加密集采样或播放评审，报告 reviewer 一致性与置信区间。
8. 加入受控 ablation：同一模型/任务/预算，比较 no-state、no-history、stale-review-allowed、no-feedback、full Harness；将失败类型与重试成本一起报告。

优势、证据强度与可以被推翻的问题

最扎实的贡献

• 问题划分清楚：将“代码运行”与“视觉要求满足”区分，避免以输出文件存在替代成功定义。
• 协议整合有实际价值：同一 revision 标识贯通作品、edit、截图与 review；不同渲染后端可以保留自己的表示，降低统一 scene graph 的强制负担。
• 局部修订与来源追踪：显式程序支持确定位置、文字、时间与资产 provenance，Figure 10 也让未满足要求保持可见。
• 作者呈现负结果并披露混杂：Figure 8 的退化、token-budget stall，以及附录中不统一的统计口径，是评价系统边界的重要信息。
• 完成率和条件质量同时报告：读者可以识别低覆盖均值与成功但不达标的差距，而不是只看最好看的图。

关键 weaknesses

哪些“实验”其实没有发生？

Table 1 是定性覆盖比较；Figure 7 是 renderer 扩展示例；Figure 8 是单例 refinement 负结果；Figure 9 是跨模型关联分析；Figure 10 画面里的 ablation table 是合成海报内容。它们都不能替代组件 ablation，也没有建立对 diffusion / flow baselines 的同预算优越性。

下一篇工作怎样设计才更有说服力？

Research Extension 以下建议尚未在本文实现或验证：

1. 预算匹配的因果消融：相同 backbone / visual feedback / API snapshot，逐项移除持久状态、历史恢复、current-revision gate，统计质量、成功率、回滚收益与浪费调用。
2. Progress-aware stopping：联合当前未满足 requirements、代码 diff、渲染差异与 verifier confidence 检测无收益循环；比较固定预算、简单耐心阈值与 learned stop policy，防止“早停省钱但更差”。
3. Dependency-aware revalidation：将 requirement 与受影响对象/代码/时间段依赖绑定，只重验可能受影响的部分；必须额外测量漏检率，不能直接牺牲 Eq. (4) 的保守保证。
4. 确定性约束 + 感知 judge：数量、坐标、时间区间、画布规格、资产 hash 用程序检查；外观与语义用视觉评审。分解二者有助于定位是 parser、执行还是 perception 出错。
5. 更强时间验证：依据关键事件自适应采样、检查边界和接触；在稀疏帧之外报告 optical/temporal consistency 或人工完整播放，衡量短暂故障遗漏。
6. Test-time search：在有版本快照的基础上维护多个候选 edit、用独立 verifier rerank，再做成本匹配比较；当前论文的 restore 能力是基础设施，不代表已经实现 beam/tree search。
7. 资产来源和执行安全：对引入图片的来源、许可、hash、内容版本及运行环境权限单独审计；原生代码执行的安全边界不应仅凭模型“遵循工具”来保证。

对 Procedural Material Generation 有什么可迁移价值？

Our Interpretation MaLiang 不是 SBS / SBSAR 生成论文，也没有材质节点列表、CompactSBS tokenization、DiffMat loss 或可微参数拟合实验。它与 Procedural Material Generation 的联系在执行型生成的状态与验证基础设施，不能把 Figure 7 的几何/材质编辑直接称为已验证的材质图生成方法。

一个值得实验的两层优化框架

Research Extension 让 MLLM 负责离散 topology / node-type / program edit，参数优化器负责连续参数，renderer 生成多条件证据，再由 revision-aware gate 同步验证。这只是研究建议；需声明 renderer 是否可微、哪些参数有梯度、哪些指标是代理、局部修改是否破坏其他通道。

此式不是论文公式：\(G\) 是候选图拓扑，\(\theta\) 是连续材质参数，\(v\) 是视角/光照条件，\(w_v\) 为权重，\(\mathcal{C}\) 可度量复杂度或成本。关键不是堆叠更多 loss，而是每次图或参数变化后，把 evidence 与对应 revision 绑定，保留失败与回滚，并比较在同一预算下的完整有效率和材质质量。

最有区分度的评估可包括：无 bitmap 子集、超出固定节点名单的新节点/组合、不同光照与几何上的泛化、所有通道一致性、图简洁性、渲染成本、局部编辑保真和原先满足条件的回归率。MaLiang 提供组织这些检查的思路，未提供它们的实验答案。

来源索引、版本记录与未执行项目

原始 PDF SHA-256：c0372d67766c020fcff59aeceeaf01a099ed7796e72d5daef665640cb5518b95。原 Figure 1–11 来自该论文，原始图片 SHA-256、上传回执与 R2 对象记录随交付说明提供；按用户要求跳过公开 HTTP 读取验证，资源显示交由人工审核。原编号不变；本页中文 caption 为解释性改写。

• 未执行模型调用、训练、研究代码、benchmark 复跑、judge 重新评分或付费实验。
• 未进行网页浏览器截图、视觉验收或部署；结构/资源/语法检查不能代表视觉验收或数学语义验证。
• 未取得完整历史 benchmark、全部运行/评分 prompt 与完整评分流水线；公开 repo 和论文历史环境不可视为完全一致。
• 内容覆盖是完整精读目标，没有测量或声称“达到90%覆盖率”。

阅读这篇论文最值得带走的，不是一组单独的模型名次，而是一个工程原则：让修改、作品和证据共享同一版本，然后把“什么时候停止”与“什么时候真的完成”分别定义清楚。