Blender RL 任务生产：两个 repo 的总览与系统耦合

本站从零讲解 arkevo_task_scaling 和 arkevo_blender_rl。两者都在回答同一个问题：怎样大规模生产“让 AI agent 操作专业软件（Blender）完成真实工作”的 RL 任务，并可靠地给 agent 的作品打分。 前者定方法、做出第一道手工精品题；后者把方法落成可以无人值守批量跑的流水线。

30 秒版本

arkevo_task_scaling（上游 · 方法论与工具库）

定义 01–07 七阶段生产方法：Taxonomy → 原始资料准入与脱敏 → 初版任务 → 多模型试解 → 聚合审题 → 正式评测（avg@3/pass@3）→ 数据产品。提供版本指纹、合同校验、脱敏检查、指标聚合的 Python 库与 arkevo CLI。用助手 + 个案脚本完整做完了 KUKA 机器人搬运题。评分 Rule 80 / VL 20。

arkevo_blender_rl（下游 · 批量自动流水线）

四个独立进程：① 造题（模型从参考工程造题包）→ ② 求解（多模型在隔离 Harbor + Blender MCP 中解题）→ ③ 取证与异步打分（Rule 与 VLM 两条独立队列）→ ④ 增量打包（离线评审站）。组件只通过文件系统上的不可变发布物 + 交接事件通信。评分 Rule 70 / VLM 30。

零基础概念速查

后续页面会反复用到下面这些词。先扫一遍，有印象即可。

术语	含义	出现在
RL task / 任务包	一道可以让 agent 去做、并能自动打分的题：题面 + 初始文件（workspace）+ 运行环境 + 验收器 + 私有参考。	两者
instruction / 题面	像真实客户委托的自然语言需求。具体数值放在公开附件里，不塞进主题面。	两者
workspace	派发给解题 agent 的目录：`inputs/`（规格、参考图/视频、可能有起始工程）+ 空的 `outputs/`。	两者
rubric / criterion	逐条评分项，每条有稳定 ID、需求出处、方法、权重。	两者
verifier / probe	验收程序。probe 是在真实 Blender 里打开交付工程、测量几何/动画/材质的固定脚本。verifier 自己生成证据，不信任 agent 自报。	两者
Rule 通道	确定性的程序检查（尺寸、部件、关键帧、文件规格等）。	两者
VL / VLM 通道	把固定渲染图/视频交给视觉语言模型评判造型、材质、动作质量等。	两者
Harbor	RL 任务框架：负责环境、运行 agent、收集轨迹、交接产物、调用 verifier。两边都固定 `harbor==0.24.0`。详解 →	两者
RewardKit	同团队的判分组织包：执行规则与 judge、分组、合分、保存明细。	task_scaling 实际使用；blender_rl 仅“如需则薄适配”
Blender MCP	Model Context Protocol 服务，让 agent 通过工具调用操作运行中的 Blender（`mcp-for-blender==2.1.3`）。	blender_rl
Landlock / 独立 UID	Linux 内核级文件访问白名单 + 每个槽独立用户，保证解题 agent 看不到 verifier 和参考答案。	两者
校准 calibration	用正例（参考解）、缺陷样例、合理变体、未修改输入去检验 verifier 是否“该给高分给高分、该扣分扣分”。	两者
输入基线	派发 workspace 含工程时，先给未修改输入打分（`input_reward`），再看模型交付的增量 `reward_delta`。	task_scaling
avg@3 / pass@3	每个配置对每题独立解 3 次：连续 reward 的平均值；以及 3 次中至少一次成功的比例。	task_scaling
发布物 + 交接事件	不可变、带逐文件 sha256 的输出目录，加上 `handoff/<kind>/` 下的一个小 JSON 通知。是 blender_rl 组件间唯一的通信方式。	blender_rl
pipeline_ref	生产配方的身份：`pipeline_id` + `pipeline_version` + 内容指纹 `pipeline_digest`。	task_scaling（schema 两边共享）
Taxonomy	Blender 职业场景 × 工作流目录：5 类职业、6 组生产工作（MOD/ANI/TEX/MAT/SCN/PIP）、80 个工作流。每题指定一个主工作流。	两者（同一文件）

两个 repo 的关系

flowchart LR
  subgraph TS["arkevo_task_scaling · 上游方法论"]
    direction TB
    D["docs/ 协议
DESIGN · VERIFICATION · EVALUATION
SANITIZATION · PIPELINE_VERSIONS"]
    L["src/ 通用库 + arkevo CLI
contracts · versions · privacy · evaluation"]
    TX["software/blender/taxonomy.json
80 个工作流"]
    SC["schemas/task.schema.json
任务合同"]
    K["KUKA 个案
scripts · verifiers/kuka-v2 · web/kuka-task
Rule 80 / VL 20"]
  end
  subgraph BR["arkevo_blender_rl · 批量流水线"]
    direction TB
    SK["authoring skill references/
taxonomy.json · task.schema.json"]
    C1["① 造题"] --> C2["② 求解"] --> C3["③ 打分
Rule 70 / VLM 30"] --> C4["④ 打包"]
    SK --> C1
  end
  TX ==>|"字节级拷贝
sha256 相同"| SK
  SC ==>|"字节级拷贝
sha256 相同"| SK
  D -.->|"设计原则继承
文件隔离 · 自生成证据 · 需求可发现"| C1
  K -.->|"评分方案并存
不得互相替换"| C3

一句话总结耦合关系

代码零依赖、契约拷贝共享、设计原则继承、评分方案刻意解耦。两个包互不 import；arkevo_blender_rl 把上游的 taxonomy 和任务合同 schema 原样拷进自己的造题 Skill 里交给作者模型；上游定下的“文件隔离 / verifier 自生成证据 / 被评分需求必须公开可发现 / Agent 不进 rollout 判分”原则在下游的题包结构与打分器里都能找到对应实现；而两边的 Rule:VL 权重不同，README 明确要求集成时“作为独立配置，不替换 KUKA 80/20”。

并排对比

维度	arkevo_task_scaling	arkevo_blender_rl
定位	跨软件的生产方法论 + 基础工具；Blender 是第一个领域	仅 Blender 的批量生产流水线
自动化程度	CLI 只做校验和规划；完整流程由助手与个案脚本协同执行	四个长驻进程，空队列等待、流式补位、断点恢复
规模	1 道题（KUKA）完整走通	默认造题 20 槽、求解 40 槽 × 4 GPU
题目来源	真实原生工程/教程，经准入后反推阶段性起点（KUKA：保留机器人，新增搬运动画）	参考工程 + 需求资料 → 造“从零制作”题（`start_mode: from_scratch`），不公开任何 `.blend`
造题者	助手（人 + Codex）	`gpt-6.1-sol` xhigh 作者 + 全新上下文终审
解题配置	Codex + `gpt-6-astra`、Claude Code + `claude-opus-5-5`，各 3 次 × 3600s	pilot：Astra 1 + Sol 1；full：Astra 3 + Sol 3 + Opus 1；每次累计 4h
评分权重	Rule 80 / VL 20 / Agent 0（`verification.weights` 0.8/0.2/0）	Rule 70 / VLM 30（0.7/0.3/0），A 项门控
视觉评委	KUKA：`claude-opus-5-5`，固定 7 张画面	交付评分 `gpt-5.6-sol`（A/B/C 并行，4 RPM）；造题内校准评委 `gpt-5.6-terra`
取证	固定脚本渲染指定画面	静态 front/side/top/close 四视图；动态 MP4 + 16 帧；按内容哈希复用
指标	avg@3、pass@3（`evaluation.py`），输入基线与 `reward_delta`	每份交付的 total/rule/vlm 分；没有 avg@k / pass@k 聚合器
版本追溯	`pipeline_ref`（id + version + digest）、不可覆盖快照、`progress.json`	`dataset_namespace` + `revision` + 每个发布物的 `publication.json` 哈希链
脱敏	`privacy.json` + `privacy-check`，三个检查点，`coverage_pending`	封存时轨迹中替换 API key；示例工程扫描；密钥只在控制器
Blender 版本	KUKA 固定 4.0.2（worker 默认 5.2.1）	5.2.1
隔离后端	共享 Bunker worker 内 Landlock + 独立 UID + PRoot；Bunker 分配器 / Docker 待实现	本机 root 控制器 + 独立 UID + Landlock；Harbor 0.24.0
产品形态	冻结 Harbor 任务包 + 数据集页 + 任务页（`web/kuka-task`）	离线评审网页（Jinja2 模板）+ 按需 ZIP
Git 历史	2026-10-16 起，7 次提交	2026-10-24 起，6 次提交（从服务器整理同步）

阶段映射：七阶段方法论 ↔ 四组件流水线

把上游的 01–07 放在左边，下游的 ①–④ 放在右边，可以看到下游实际上把“造题 + 审题 + 校准”压缩进了一个自动化组件，而“正式评测”和“数据产品”只做了一部分。

flowchart LR
  subgraph U["task_scaling 01–07"]
    direction TB
    U1["01 Taxonomy"]
    U2["02 Raw data · 准入 · 脱敏"]
    U3["03 初版任务 + 输入基线"]
    U4["04 多模型试解"]
    U5["05 聚合审题 · 校准 · 冻结"]
    U6["06 正式评测 avg@3 / pass@3"]
    U7["07 数据产品"]
  end
  subgraph Dn["blender_rl ①–④"]
    direction TB
    B0["输入 task 文件夹
人工准备 + artifact.json"]
    B1["① 造题
作者写题 + 正例/缺陷/变体校准
check_delivery 修复环 + 独立终审"]
    B2["② 求解
pilot 1+1 · full 3+3+1"]
    B3["③ 取证 + Rule/VLM 打分"]
    B4["④ 增量打包"]
  end
  U1 -->|"taxonomy.json 原样拷贝"| B1
  U2 -.->|"未自动化：输入由人准备"| B0
  U3 --> B1
  U5 -->|"校准 + 终审在造题内完成"| B1
  U4 -.->|"pilot 模式近似试解"| B2
  U6 -->|"full 模式 Astra/Sol 各 3 次
Opus 仅 1 次 · 无聚合器"| B2
  U6 -.-> B3
  U7 --> B4

上游阶段	下游对应	覆盖程度	差异
01 Taxonomy	造题 Skill 的 `references/taxonomy.json`	完全复用	同一文件；作者模型从中选 `workflow_primary` / `profession_primary`
02 准入与脱敏	输入 task 文件夹（`artifact.json` 记录身份与 GT 哈希）	部分	下游假设输入已准备好；缺依赖时作业进入 `needs_input`。没有调用上游 `privacy-check`
03 初版任务	① 造题会话	自动化	下游只做 `from_scratch` 题；上游支持接手/细化/修复等多种阶段起点
输入基线	—	无	from_scratch 题没有输入工程，按上游协议本就 `not_applicable`
04 多模型试解	② 求解 pilot 模式	形式不同	上游试解用来发现题目问题后回到 03 修订；下游试解结果不回流造题
05 聚合审题 / 校准	① 内部：check_delivery、正例/缺陷/合理变体校准、独立终审 editorial	前移	上游审题看真实多模型产物与轨迹；下游校准在解题之前用作者构造的样例完成
06 正式评测	② full 模式 + ③ 打分	部分	Astra / Sol 各 3 次满足 @3，Opus 只有 1 次；且没有 `evaluation-plan.json`、`trials.jsonl`、avg@3/pass@3 计算
07 数据产品	④ 打包	形式不同	下游输出离线评审站和 ZIP；上游输出 Harbor 任务包 + 数据集页 + 任务页 + 证据回执

跨 repo 耦合详解

1. 数据契约：拷贝式共享（最强的耦合）

上游源文件

arkevo_task_scaling/software/blender/taxonomy.json
arkevo_task_scaling/src/arkevo_task_scaling/schemas/task.schema.json

耦合方式

文件被原样拷贝（实测 sha256 完全一致：taxonomy a7d0a0a5…，schema 779c7afd…）。下游没有任何代码从上游读取，也没有同步脚本或 CI 检查。

下游使用位置

arkevo_blender_rl/src/arkevo_blender_rl/authoring/skills/arkevo_blender_task/references/
作者模型写的 task.json 必须通过此 schema；workflow_primary 等 ID 必须来自此 taxonomy

schema 中值得注意的几个字段，以及两边如何各自使用：

字段	schema 约束	task_scaling 用法	blender_rl 用法
`verification.weights`	`rule`、`vl` 为 [0,1] 分数，`agent` 必须为 `0`	`{rule:0.8, vl:0.2, agent:0}`	`{rule:0.7, vl:0.3, agent:0}`（delivery-contract.md 规定）
`pipeline_ref`	必填，但允许 `null`；非 null 时需 `pipeline_id` + `pipeline_version` + 64 位 `pipeline_digest`	新任务必须绑定完整引用；null 显示为发布阻塞项	下游没有管线登记机制，无法提供上游意义上的 digest
`status`	`const: "draft"`	通用合同校验只支持 draft；冻结由个案证据完成	保持 draft，“冻结”由控制器的不可变发布回执表达
`criteria[].weight`	同一通道内权重	同通道合计为 1	按 100 分归一（如 0.12），而 `tests/rubric.json` 存原始重要度 5/10/20，两者需保持一致
`sanitization_policy`	必填 `policy_id` + `policy_version`	`rl-task-basic-sanitization@0.1.0`	由作者模型填写，下游不执行上游 privacy-check

漂移风险

下游 references/context-lock.json 记录了这两个文件的“快照哈希”（d323869d… / 1dc32482…），与当前文件的 sha256 不一致。实测这两个值恰好等于同一内容改用 CRLF 换行后的哈希，说明内容没变，只是在 Windows 上整理时换行符不同（docs/validation.md 提到 Windows 仅用于源码整理）。代码中也没有任何地方校验这个 lock。结论：目前内容一致，但如果上游 taxonomy 或 schema 升级，下游不会自动感知。

2. 设计原则：上游协议 → 下游实现

上游原则（task_scaling docs）	下游落地（blender_rl 代码）
文件隔离四视角：制题侧 / 解题侧 / 验收侧 / 产品侧（MODULES.md）	题包 `instruction.md` + `environment/workspace/` 给 solver；`tests/` + `private/` 只给 verifier；solver intake.py 拒绝 workspace 中 `inputs/` 以外的文件
verifier 自己生成证据，不信任 solver 的 `measurements.json`	`rule-verifier-workflow.md`：“The verifier generates evidence itself in a new private directory … Do not trust solver-produced measurements or scores.” 打分器在 Blender 中原生重放作品取证
被评分的需求必须能从题面或 workspace 中发现	造题 SKILL.md：source → public location → requirement ID → criterion ID → evidence 的私有台账；终审检查“所有 requirement ID 都被覆盖”
Agent 0%：自主探索 agent 不进 rollout 判分，只用于造题/审题	打分只有 Rule 程序 + VLM 单次判断；agent 只出现在造题和终审
校准需要合格参考、合理替代、部分完成、明确缺陷、投机样例	造题要求“正例 / 缺陷 / 合理变体”校准，authoring/publish.py 检查 `private/validation/report.json` 中回归项均 `passed` 且有 evidence
约定输出规范，按需固定脚本重渲染，不用自主探索的渲染 agent	打分器的 `view_specs`、静态四视图 / 动态 16 帧固定取证
VL 缺失时不能悄悄把 Rule 归一化成完整 reward	VLM 未完成时 `total_score = null`，不记零分
不同 verifier / 模型配置不混算	打包器要求 `score_model/score_profile/score_effort` 与队列身份一致，否则 `Scoring profile mismatch`

3. 评分方案：刻意解耦

task_scaling · KUKA 80/20

Rule 80% + VL 20%；核心失败按校准后的规则封顶（KUKA 缺陷样例封顶 0.25 或 0.4）；success 由关键交付和质量门槛独立决定。DESIGN.md 明确：“80/20 不是已验证最优值”，权重例外需记录理由并随版本冻结。

blender_rl · 70/30

Rule 0–70 分 + VLM 0–30 分；VLM 拆成 A/B/C 三项并行判断，A 判 0 时视觉分强制为 0（A 门控）。打分器硬编码校验区间。

README 原文

“本仓库维护 Blender 批量流水线的 70/30 评分方案；后续集成上游时作为独立配置，不替换其已有 KUKA 80/20 方案。”——两套分数不可直接比较，汇总报告时必须按 verifier 版本分别统计。

4. 基础设施与运行环境

组件	task_scaling	blender_rl	耦合判断
Harbor	0.24.0（KUKA 已接通独立 solver/verifier 环境）	`harbor==0.24.0`	一致
RewardKit	0.2.3，实际用于 KUKA 评分	不在依赖中；Skill 说“如需则薄适配，保留逐行结果”	下游未使用
隔离	Landlock + 独立 UID + PRoot，共享 worker 内	Landlock + 独立 UID，root 控制器	同一思路，实现独立
Blender	KUKA 固定 4.0.2	5.2.1	不同；上游强调“不能用系统默认替代固定版本”
计算资源	Bunker `4d` CPU worker，GPU 分配为 0	本地 4 卡 NVIDIA（Cycles CUDA / Eevee Vulkan）	不同；下游无法直接跑在当前上游 worker 上

5. 模型身份

模型	task_scaling 用途	blender_rl 用途
`gpt-6-astra`	试解 + 正式评测（Codex xhigh）；审题候选	求解（pilot 1 / full 3）
`claude-opus-5-5`	试解 + 正式评测（Claude Code xhigh）；KUKA 视觉评委	求解（full 模式 1）
`gpt-5.6-sol`	—	求解（pilot 1 / full 3）+ 交付 VLM 评委
`gpt-6.1-sol`	—	造题作者 + 终审
`gpt-5.6-terra`	—	造题内校准评委
`seed-2-1` / `gemini-4`	候选，未验证（`models.json` `validated:false`）	—

6. 没有耦合的地方（同样重要）

没有代码依赖：两个包互不 import，包名、CLI 名都不同（arkevo vs arkevo-author / arkevo-solve / arkevo-score / arkevo-pack）。
没有共享运行目录：上游产物在 runs/、products/（Git 忽略）；下游在配置的 root 下的 packages/ … deliveries/。
没有共享版本号：上游包 0.4.4 / 管线 0.4.4；下游包 0.1.0 / 造题 revision author-v2-from-scratch。
没有结果回流：下游的分数不会写回上游的 trials.jsonl 或进入 evaluation.py 聚合。

如果要把两者集成，需要补什么

集成清单（基于以上耦合分析推导）

契约同步：用真实 sha256（而非 CRLF 版本）重算 context-lock.json，并在测试中对比上游文件，防止 taxonomy / schema 漂移。
管线身份：为 blender_rl 登记一个上游 pipelines/<id>/<ver>.json 快照，让作者写出的 task.json 带上非 null 的 pipeline_ref。
评分配置并存：在上游 verification.json 层面把 70/30 + A 门控登记为独立 verifier 配置，与 KUKA 80/20 分开统计。
指标聚合：把下游 scores/*/score.json 映射成上游 trials.jsonl 记录（模型配置、任务版本、verifier 版本、reward、success），并预先写 evaluation-plan.json，才能用上游 evaluation.py 算 avg@3 / pass@3。注意下游没有独立的 success 二元判定。
脱敏边界：在下游造题输入、solver 派发、打包导出三个点调用上游 privacy-check，并处理 coverage_pending。
运行环境：统一或分别固定 Blender 版本；确认 GPU 资源来源（上游当前 worker 无 GPU）。

站点地图与阅读路线

如果你只有 30 分钟：本页 → blender_rl 框架总览 → task_scaling 框架总览。要动手改代码时，再进入对应的深度页。

blender_rl