RewardHarness: Self-Evolving Agentic Post-Training

Paper: arXiv:2605.08703 Code: TIGER-AI-Lab/RewardHarness Code reference: main @ 6ba0e22d (2026-05-18)

1. Motivation（研究动机）

这篇论文关注的是一个很具体但很难的任务：给 instruction-guided image editing 产出的候选图打 reward / preference 分数。相比普通图像质量判断，这类评测必须同时看三件事：是否执行了编辑指令、是否保持原图中不该改动的部分、以及结果图本身是否有 artifact 或不合理结构。现有 reward model 虽然有效，但通常依赖大规模人类偏好标注和额外参数训练；例如论文在摘要中直接把问题定义为一个 data-efficiency gap：人类往往看几十到一百个例子就能总结出评测标准，但模型通常需要几十万对比样本才能学会。

作者要解决的问题不是“再训练一个更大的 reward model”，而是把 reward modeling 改写成context evolution：冻结 evaluator/backbone，不更新权重，只让一个 Orchestrator 从少量人类偏好样本中迭代生长出一套可解释的 Skills 与 Tools Library。这样做的好处有三层。第一，它把“学会如何评审”从 weight optimization 转成 text artifact evolution，显著降低标注量需求；第二，它允许直接利用 black-box / API model 作为编排器或子评估器，而不要求拿到可训练权重；第三，它让 reward system 变成可检查、可回滚、可审计的规则与工具集合，而不是一个难以解释的标量头。

Figure 1 解读：这张图把两种范式并排摆出来。上半部分是传统 pipeline：先收集大规模 preference data，再训练 reward model，最后把它接到 RL alignment；下半部分是 RewardHarness：只拿一个小型 preference demo 集合作为 calibration set，让 Orchestrator 一边评测、一边分析 reasoning chain、一边增删改 Skills/Tools。作者真正想强调的不是“又一个 agent 系统”，而是 reward acquisition 的基本单位从“参数”变成了“上下文中的可解释 artifact”。

这个问题值得做，因为 image editing RL 正处在 reward bottleneck：生成模型本身越来越强，但 instruction fidelity、局部保真、text editing、spatial relation 这些能力很难靠一个静态 reward head 全部 cover。若能用 100 个示例就长出可用 reward system，就意味着 reward engineering 的成本从“重训练一次模型”降到“维护一套可演化库”，这对多模态后训练尤其有价值。

2. Idea（核心思想）

论文的核心 insight 可以压缩成两句话：RewardHarness 把 reward model 视为“由 Orchestrator 动态组装的评测上下文”，而不是“从大量偏好数据拟合出来的参数函数”。它通过自演化的 Skills（声明式 rubric）和 Tools（程序化视觉分析规范）来补足冻结 VLM 的评测盲区。

与现有方法最本质的差异在于：EditReward、ImageReward 这类方法的适配对象是模型参数；RewardHarness 的适配对象是Library 本身。这使得它更像一个为 evaluator 量身定制的 agentic post-training system，而不是传统意义上的 reward regression。与常见 tool-augmented LLM 也不一样，后者通常固定工具集、学习调用策略；RewardHarness 连工具本身的 specification 都会被迭代更新。

Figure 3 解读：图中左侧是 Skill，右侧是 Tool。Skill 的本质是“应该怎么判断”，包含描述、rubric、示例和优先级；Tool 的本质是“当普通 holistic judgment 不够时，应该怎么做一个有约束的视觉分析”，包括输入输出 schema、调用条件和执行协议。这个拆分很关键，因为作者认为很多评测失败不是一个统一 reward function 的数值误差，而是两类错误混在一起：一类是标准错了，需要改 rubric；另一类是看错了，需要一个更可控的视觉子程序。

3. Method（方法）

3.1 Overall framework

RewardHarness 由两个主部件组成：Orchestrator 和 Library。推理时，Orchestrator 根据 source image、editing prompt 和候选 edited images，从 Library 里挑出当前样本真正相关的 Skills/Tools，拼成上下文 $C$ ；被冻结的 Sub-Agent VLM 在这个上下文中构造 reasoning chain，并输出 preference judgment。训练时，Orchestrator 再拿 reasoning chain 和人类标注对齐，找出失败模式，提出 library update，并通过 held-out validation gate 决定是否保留。

Figure 2 解读：这张架构图把系统切成一条闭环。左边的输入是 source image、editing prompt 和一个 edited candidate；对 ranking benchmark 来说，系统会对多个 candidate 重复评分。中间的 Orchestrator 做 retrieval，把 Library 里的 Skill/Tool 子集注入 Sub-Agent 上下文；Sub-Agent 生成 reasoning chain、分数和排序。右边的 compare-and-analyze loop 再把预测与 ground truth 比较，抽取 improvement signal，回写 Library。整个框架最特别的地方是“评测器的学习”发生在 Library 而非 backbone 参数里。

直觉上，这种设计有效是因为 image-edit reward 的困难往往具有可显式命名的 failure mode：OCR 看错、左右关系看反、把 prompt 要求的 surreal content 误判成 artifact、对 background/style transformation 的保留范围判断不一致。把这些失败模式外显成 Skills/Tools，比期望一个统一 reward head 在隐空间里自动学会它们，更容易在小样本下稳定收敛。

3.2 Problem formulation

论文把任务写成： $s, π = M (I_{s}, {I_{k}}_{k = 1}^{K}, p, C),$ 其中 $I_{s}$ 是源图， $p$ 是 editing instruction， ${I_{k}}_{k = 1}^{K}$ 是 $K$ 个候选编辑结果， $s = (s_{1}, \dots, s_{K})$ 是各候选分数， $π$ 是由分数诱导的排序。论文正文说明分数与人类 rubric 对齐，排序用于 benchmark；下游 GRPO 则把单个生成样本的分数送入 reward normalization。

更重要的是，作者明确把“模型本体”和“评测能力来源”分开： $M$ 的参数固定，变化的是由 Orchestrator 组装出来的上下文 $C$ 。因此系统的可学习部分不是权重，而是 Skills/Tools 文档集合。

论文公式与 released code 实现差异：

论文方法部分按一般形式写的是 $K$ 候选打分，并声称使用与 human demonstrations 相同的 1–5 ordinal score；但 released code 的 src/sub_agent.py 实际输出是 pairwise A/B/tie，外加四个离散子分数 score_A_instruction、score_A_quality、score_B_instruction、score_B_quality，并且范围是 1–4。
released src/evaluator.py 与 scripts/run_benchmark.py 不是直接预测一个 $K$ 路排序，而是先做 pairwise judgment，再把同一 group 的所有 pair 组合回 K=2/3/4 group accuracy。这一点与论文公式中的单次多候选排序不是完全一致的实现。
因而更准确的 released-code 心智模型是：论文给出的是抽象任务定义，公开代码实现的是 pairwise comparator，再通过组合规则复现 EditReward-Bench 的 group metric。

3.3 Skills and Tools Library

Library 是一个版本化目录，底层由 src/library/__init__.py 管理，存储形式是带 YAML frontmatter 的 SKILL.md 文档。Skill 负责声明式规范，例如“先客观描述再下判断”“当 prompt 明确要求超现实内容时，不应把概念上的不真实当作 artifact 惩罚”；Tool 负责程序化视觉分析，例如 OCR、spatial/object counting、visual QA、style/culture knowledge lookup。

从 appendix 的最终导出库看，收敛结果是 3 Skills + 4 Tools：

Skills: objective-visual-description-first, realism-and-artifact-penalties, style-and-background-transformation-evaluation
Tools: text-and-ocr-analyzer, spatial-and-object-analyzer, visual-qa-tool, cultural-and-style-knowledge-oracle

这个最终结构本身就很说明问题：作者不是让 heuristic 越堆越多，而是让系统逐步把“容易 hallucinate 的判断”外包给 structured tool call，把 Skill 留给真正需要人类偏好抽象的部分。

3.4 Orchestrator / Router

论文正文写 Orchestrator 是 Claude-based LLM，并强调它在 inference 时做 routing，在 evolution 时做 chain analysis 与 library refinement。released code 中这三件事分别落在：

src/router.py: 用 Gemini 根据 prompt 选择相关 Skills/Tools
src/chain_analyzer.py: 用 Gemini 从正确/错误 chain 中抽 improvement signal
src/evolver.py: 把 signal 应用到 Library，并支持 snapshot/restore

Router 的关键点是 L1→L2 progressive disclosure：先让模型看到 Skill/Tool 的 name + description 决定是否需要，再按需把 full content 拼进上下文，避免无关规则把 prompt 上下文塞满。

def prepare_context(prompt: str, library) -> str:
    summaries = library.get_all_summaries()
    if not summaries["skills"] and not summaries["tools"]:
        return ""
 
    selected = gemini_route(
        prompt=prompt,
        skills=summaries["skills"],
        tools=summaries["tools"],
    )  # {"skills": [...], "tools": [...]}
 
    skill_docs = [library.get_full_content(name) for name in selected["skills"]]
    tool_docs = [library.get_full_content(name) for name in selected["tools"]]
    return assemble_l2_context(skill_docs, tool_docs)

论文公式与 released code 实现差异： 论文正文与 limitation 都把 Orchestrator 写成 Claude-based；但 released repo 的默认 gemini.model 是 gemini-3.1-pro-preview，src/router.py、src/chain_analyzer.py 以及 README 也都按 Gemini 编排器来描述。这意味着公开实现与论文叙述的 provider 已经发生切换。

3.5 Sub-Agent inference

Sub-Agent 是被冻结的 pluggable VLM。论文默认实验的开源 backbone 是 Qwen2.5-VL-7B-Instruct，通过 vLLM 服务；论文也给出了 Gemini-2.0-Flash 作为闭源替换。released code 中 src/sub_agent.py 的核心不是一次性输出结论，而是一个多轮 <tool> ... </tool> / <obs> ... </obs> / <answer> ... </answer> loop：

模型先尝试直接给答案；
若检测到 tool call，则调用 library.call_tool(...)，把 JSON 观测包成 <obs> 再喂回；
如此最多迭代若干轮，最后抽出 preference 与四个子分数。

def evaluate_pair(source_img, edited_A, edited_B, prompt, skill_context):
    messages = build_messages(source_img, edited_A, edited_B, prompt, skill_context)
    chain_parts = []
 
    for turn in range(MAX_TOOL_CALLS + 1):
        output = call_vllm(messages)
        chain_parts.append(output)
 
        answer = parse_answer(output)
        if answer is not None:
            answer["chain"] = "\n".join(chain_parts)
            return answer
 
        tool_call = parse_tool_call(output)
        if tool_call is None or turn >= MAX_TOOL_CALLS:
            break
 
        obs = library.call_tool(
            tool_call["name"],
            {"images": tool_call["images"], "query": tool_call["query"]},
            endpoint_pool,
        )
        messages.append({"role": "assistant", "content": output})
        messages.append({"role": "user", "content": f"<obs>{json.dumps(obs)}</obs>"})
 
    return FALLBACK_ANSWER

这里真正关键的是：Tool 不是外部传统 API，而是另一次被 system_prompt 约束的 VLM 调用。也就是说，RewardHarness 的 Tool 更像“被包装成结构化 JSON 接口的视觉子专家”，而不是硬编码算法模块。

3.6 Self-Evolution Loop

论文用 $N = 100$ 个 human preference demonstrations 作为 calibration set，分成 60 个 train / 40 个 validation。每轮迭代有五步：

在 $D_{train}$ 上跑当前 library；
根据 ranking agreement 判断对错；
分析正确链条中的有效模式与错误链条中的失败模式；
生成 add / update / delete 类型的 skill/tool proposal；
在 held-out validation 上做 gate，决定 accept or rollback。

def self_evolution_iteration(train_split, val_split, library, config):
    train_results = run_iteration(train_split, library)
    signals = chain_analyzer.analyze(train_results, library.get_all_summaries())
 
    snapshot = evolver.snapshot()
    evolver.apply_signals({"skill_updates": signals["skill_updates"], "tool_updates": []})
    val_acc_after_skills = compute_val_acc(val_split, library)
    if val_acc_after_skills < prev_val_acc - config["explore_margin"]:
        evolver.restore(snapshot)
 
    snapshot = evolver.snapshot()
    evolver.apply_signals({"skill_updates": [], "tool_updates": signals["tool_updates"]})
    val_acc_after_tools = compute_val_acc(val_split, library)
    if val_acc_after_tools < prev_val_acc - config["explore_margin"]:
        evolver.restore(snapshot)
 
    if should_prune(iteration, config["prune_every_n"]):
        prune_library(val_split, library)

公开实现还额外把 skill update 和 tool update 分成两个 phase，并支持 periodic pruning。src/pipeline.py 的 prune 逻辑是“逐个 ablate 某个 skill/tool，再看 val_acc 是否不降；若不降就删掉”，本质上是一个 held-out set 上的 leave-one-out simplification。

def prune_library(val_split, library):
    baseline_acc = evaluate(val_split, library)
    for name, entry_type in library.all_entries():
        snapshot = library.snapshot()
        library.delete(name, entry_type)
        ablated_acc = evaluate(val_split, library)
        if ablated_acc >= baseline_acc:
            keep_deleted(name)
        else:
            library.restore(snapshot)

论文公式与 released code 实现差异：

论文正文把 gate 描述成“如果 validation accuracy improve over current best 就接受，否则 rollback”；released code 实际是 val_acc_after_* >= prev_val_acc - explore_margin 即可保留，默认 explore_margin=0.075。也就是说，公开实现允许为探索保留小幅退步，而不是严格单调上升。
论文分析图基于 77 iterations，且 final selected library 在 iteration 69 达到 62.5% validation accuracy；但 released configs/default.yaml 默认只有 max_iterations: 5。这说明 repo 公开的是一个轻量复现实验/演示配置，不是论文作图时的完整长程搜索配置。
论文说最终收敛到 7 个条目；repo 中的 src/library_gemini_v* 目录保留了多个版本的导出库，但默认运行不会直接复现论文的 77-iteration trajectory，除非额外提供作者内部实验配置。

Figure 6 解读：左图展示每次 proposal 注入后 validation accuracy 的散点，以及 running best 的折线；右图展示 Skill/Tool 数量随迭代变化。最值得注意的是两点：一是中期 library 会先膨胀到 13 个条目，再进入 pruning；二是最优点不是“最多规则时”，而是经过删减后留下 7 个条目时。这支持作者的主张：问题不在于把更多 heuristic 塞进上下文，而在于把真正有效的 grounding tool 留下来。

Figure 8 解读：这张图把 iteration 10、49、69 的库组成可视化出来。早期以 Skill 为主，中期 Skill/Tool 一起膨胀，最终则变成 Tool 多于 Skill 的精简配置。它反映了一个很强的经验结论：面对 image editing evaluation，很多失败不是“原则没说清”，而是“需要一个更 grounded 的视觉查询”。

Figure 9 解读：realism-and-artifact-penalties 的演化说明 RewardHarness 不只是添加新条目，也会把错误的 rubric 边界修正掉。早期版本会粗暴惩罚所有看起来不真实的内容；后期版本加入“若 prompt 明确要求 surreal content，则概念上的不真实不应受罚”的 carve-out。这个例子很好地说明了 reward alignment 中最难的一点：用户意图与客观 realism 并不总是同一个维度。

Figure 10 解读：anti-hallucination-and-verification Skill 的作用不是直接打分，而是规定“哪些场景必须先调用 Tool 再判断”，例如 black-image detection、text reading、object-attribute verification。它体现出 Skill 与 Tool 之间的清晰分工：Skill 决定何时外包，Tool 决定如何外包。

Figure 11 解读：spatial-and-object-analyzer Tool 把复杂的空间问题转成带 typed JSON schema 的结构化视觉问答。对“左起第 4 个 surfboard”“猫脚是否在包下方”这类问题，普通 holistic reasoning 很容易 hallucinate；而有 schema 的二次 VLM 查询能把计数、朝向、位置关系拆成可核对字段。

Code reference: main @ 6ba0e22d (2026-05-18) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
Library persistence and SKILL.md schema	`src/library/__init__.py`	`Library`, `add_skill`, `add_tool`, `get_full_content`, `call_tool`
Prompt-conditioned retrieval	`src/router.py`	`Router.prepare_context`, `_assemble_context`
Frozen VLM evaluator	`src/sub_agent.py`	`SubAgent.evaluate`, `batch_evaluate`, `_parse_answer`, `_parse_tool_call`
Reasoning-chain error analysis	`src/chain_analyzer.py`	`ChainAnalyzer.analyze`
Applying / validating updates	`src/evolver.py`	`Evolver.apply_signals`, `_validate_tool_prompt`, `snapshot`, `restore`
Full self-evolution loop	`src/pipeline.py`	`SelfEvolutionPipeline.run_iteration`, `_prune_library`, checkpoint flow
Pairwise benchmark metric	`src/evaluator.py`	`evaluate_prediction`, `compute_kpair_accuracy`
Read-only benchmark runner	`scripts/run_benchmark.py`	`run_benchmark`, `evaluate_pair`, `parse_ranking`
Released public experiment config	`configs/default.yaml`	`gemini`, `evolution`, `benchmark` blocks
Actual vLLM launch defaults	`scripts/serve_vllm_multi.sh`, `.env.example`	`NUM_GPUS`, `ENDPOINTS_PER_GPU`, `BASE_PORT`, `GPU_MEM`, `MAX_MODEL_LEN`
End-to-end reproduction wrapper	`scripts/reproduce.sh`	setup → data download → serve → evolve → benchmark

4. Experimental Setup（实验设置）

4.1 Datasets and scale

AgPerry/EditReward-Data-100: 100 个 preference demonstrations，released configs/default.yaml 明确写成 train_n=60、val_n=40。这是自演化唯一用到的人类标注集。
TIGER-Lab/EditReward-Bench: 主 benchmark，按 $K = 2/3/4$ 三种候选组规模评测。released OUTPUTS.md 的示例结果对应 n_total=700/350/175 个 group，pair 数分别是 700 / 1050 / 1050。
TIGER-Lab/GenAI-Bench (image_edition, test_v1): README/OUTPUTS 明确说明论文 headline 47.4% 还需要单独跑这部分；公开样例里 genai_bench.n_total=600。
ImgEdit-Bench: 用于验证把 RewardHarness 当作 FLUX.2-klein-base-4B 的 GRPO reward signal 后，图像编辑能力是否提升。公开 repo 只保留结果表，没有放出对应 RL trainer。

4.2 Baselines

主评测表包含以下基线：

Proprietary models: GPT-4o, GPT-5, Gemini-2.0-Flash, Gemini-2.5-Flash, Claude-Haiku-4.5
Open-source models / reward models: Qwen2.5-VL-7B, Qwen2.5-VL-32B, MiMo-VL-7B, EditReward (Qwen), EditReward (MiMo)
Ours: RewardHarness with Qwen Sub-Agent, RewardHarness with Gemini-2.0-Flash Sub-Agent

下游 ImgEdit-Bench 则比较 AnyEdit、UltraEdit、Step1X-Edit、BAGEL、OmniGen2、Ovis-U1、GPT-Image-1、Flux.1 Kontext [dev]、FLUX.2-klein-base-4B 及其两种 reward-driven RL 版本。

4.3 Metrics

EditReward-Bench K-pair accuracy: 对每个 group，只有全部 pairwise comparisons 都答对，group 才算正确。src/evaluator.py 明确实现了这一点。
GenAI-Bench accuracy: pair-ranking accuracy；与 EditReward-Bench 的三项一起取平均，得到表 1 的 Avg.。
ImgEdit-Bench scores: 各编辑类别（Add / Adjust / Extract / Replace / Remove / Bg. / Style / Compose / Action）的平均分以及 Overall。

4.4 Training / serving config

能从公开代码中明确锚定的配置如下：

Sub-Agent model: Qwen/Qwen2.5-VL-7B-Instruct
Serving defaults: MAX_MODEL_LEN=16384, gpu_memory_utilization=0.85, dtype=bfloat16, limit-mm-per-prompt {"image": 5}
Launcher defaults: NUM_GPUS=4, ENDPOINTS_PER_GPU=1, BASE_PORT=8000，即默认起 4 个 vLLM endpoint
Evolution config (configs/default.yaml): train_n=60, val_n=40, max_iterations=5, batch_concurrent=128, explore_margin=0.075, augment_swap=true, prune_every_n=50, seed=42
Benchmark config (configs/default.yaml): dataset=TIGER-Lab/EditReward-Bench, max_workers=128

这里必须强调两个复现实务点：

configs/default.yaml 里的 model: block 只是 informational；真正驱动 vLLM 的是 scripts/serve_vllm_multi.sh 和环境变量。
论文图里是 77-iteration Gemini run，但公开默认配置只有 5 iterations，因此公开 repo 不是 paper-exact training config。

对下游 GRPO 实验，论文只说把 RewardHarness 用作 FLUX.2-klein-base-4B 的 reward signal；released repo 没有公开对应 trainer、优化器、learning rate、batch size、训练步数或硬件脚本，因此这部分只能记为：论文给出了结果，但公开代码未释放完整复现实验配置。

5. Experimental Results（实验结果）

5.1 Main benchmark numbers

表 1 的核心结论很直接：只用 100 个 calibration examples，RewardHarness(Gemini) 仍能在四项平均上做到 47.4，超过 GPT-5 的 42.1；RewardHarness(Qwen) 也有 45.7，高于最强开源 EditReward(MiMo) 的 44.1。

Method	K=2	K=3	K=4	GenAI-Bench	Avg.	Δ vs GPT-4o
GPT-4o	45.7	27.3	7.3	53.5	33.5	—
GPT-5	57.5	38.5	12.8	59.6	42.1	+8.6
Gemini-2.0-Flash	52.4	33.3	13.5	53.3	38.1	+4.6
Gemini-2.5-Flash	58.6	39.9	12.2	57.0	41.9	+8.4
Claude-Haiku-4.5	57.9	30.7	7.4	47.1	35.8	+2.3
Qwen2.5-VL-7B	52.7	24.7	3.4	40.5	30.3	-3.2
Qwen2.5-VL-32B	50.5	25.3	4.1	39.3	29.8	-3.7
MiMo-VL-7B	49.5	30.4	9.5	57.9	36.8	+3.3
EditReward (Qwen)	57.0	36.0	10.8	64.0	42.0	+8.5
EditReward (MiMo)	56.5	42.7	11.5	65.7	44.1	+10.6
RewardHarness (Qwen)	57.9	46.7	10.8	67.5	45.7	+12.2
RewardHarness (Gemini-2.0-Flash)	66.2	45.3	13.5	64.4	47.4	+13.9

这组结果说明两件事。第一，提升不只是 backbone 更强造成的，因为 RewardHarness(Qwen) 对同 backbone 的 EditReward(Qwen) 仍有 45.7 vs 42.0 的优势。第二，作者真正学到的是一套 task-specific evaluation procedure，而不是只靠更强通用 VLM 在 zero-shot 里硬判。

Figure 4 解读：作者挑了一个 EditReward-Bench 案例，展示 RewardHarness 与 EditReward 对同一对候选图的不同判断。RewardHarness 给人类偏好的那张图更高分，而 EditReward 失败。这个图的意义不在于单个 case，而在于说明 Skill/Tool 组合可以把“局部错误但整体还不错”和“真正更符合指令”的差异显式拆开。

5.2 Reward as downstream RL signal

论文把 RewardHarness 接进与 EditReward 相同的 GRPO pipeline，比较哪个 reward signal 更能推动 FLUX.2-klein-base-4B 的 image editing 能力提升：

Method	Add	Adjust	Extract	Replace	Remove	Bg.	Style	Compose	Action	Overall
FLUX.2-klein-base-4B	3.27	4.00	2.04	3.07	2.90	3.47	4.26	3.19	4.44	3.32
+RL (EditReward)	4.21	4.01	2.02	3.21	2.58	3.69	4.32	2.85	4.34	3.45
+RL (RewardHarness)	4.03	4.27	2.24	3.12	2.19	4.22	4.44	3.19	4.22	3.52

整体上，RewardHarness 把 Overall 从 3.32 提升到 3.52，高于 EditReward 的 3.45。类别上也有 trade-off：EditReward 在 Add / Replace 更强，但 RewardHarness 在 Adjust / Extract / Background 更好，并且在 Compose 上不伤害 base model。作者据此 argue：RewardHarness 提供了更有效的 training signal。

需要保留的复现 caveat 是：这些数字来自论文表格与 changelog，公开 repo 没有下游 RL trainer；因此我们能确认结果，不能从 repo 直接复现其训练细节。

Figure 5 解读：主文 qualitative figure 把 source image、base model、RewardHarness-RL 和 EditReward-RL 摆在一起。作者想强调的不是“所有样例都大幅更美”，而是 RewardHarness 更稳定地执行 edit instruction，同时保留无关区域与结构合理性。

Figure 7 解读：附录里的更多例子把这个趋势扩展到 Add、Adjust、Extract、Remove、Replace 多类任务。最有价值的是它揭示了 RewardHarness gain 的来源：很多 improvement 并非“整体画质更锐利”，而是 instruction execution 更准确、保留区域更稳定、背景与主体边界更少被误改。

5.3 Library evolution and ablation-style findings

严格来说，论文没有给传统“逐模块 ablation 表”，但 Figure 6/8 和 appendix case study 组成了一组很强的 mechanism evidence：

validation accuracy 从空库基线 42.5% 提升到最终 62.5%
library 中期膨胀到 13 entries = 8 Skills + 5 Tools
pruning 后最佳库变成 7 entries = 3 Skills + 4 Tools
工具在最终库中反而多于技能，表明 grounded visual verification 比继续堆叠 heuristic 更关键

从 appendix narrative 看，几个最重要的“有效组件”分别是：

text-and-ocr-analyzer：修正 text misreading / spelling / placement 类失败。
spatial-and-object-analyzer：修正 counting、左右关系、orientation 类 hallucination。
realism-and-artifact-penalties 的后期版本：避免把 prompt 明确要求的 surreal edit 错罚。
anti-hallucination-and-verification：把“先调用工具再下判断”写成强约束，降低直接想当然判断的频率。

这其实是本文最有价值的 ablation takeaway：相对 declarative rubric，程序化 tool grounding 对 image-edit reward 更重要。

5.4 Limitations

作者在 limitation 里写得很诚实，主要有三点：

Orchestrator 依赖 proprietary LLM。论文写 Claude，repo 默认则切成 Gemini；不管是哪家，核心问题都是完整 reproducibility 仍绑定外部 API。
任务域很窄。目前只验证了 instruction-guided image editing evaluation，是否能无缝迁移到 text-to-image、video editing、3D manipulation 还没证明。
小 held-out set 可能过拟合 recurring failure modes。validation gate 虽然防 regressions，但不保证找到全局最优库，也可能拒绝那些对少见 hard case 有利、对常见 easy case 轻微有害的 proposal。

我的补充限制是两条和 released code 直接相关的复现问题：

公开默认配置只有 5 iterations，不是论文 77-iteration 版本。
下游 FLUX.2-klein-base-4B 的 GRPO 训练代码和超参数没有发布，所以表 2 目前更像“结果可读、机制可理解，但实现不可复现到同等粒度”。

总体来看，这篇论文最重要的贡献不是某个单独 benchmark number，而是它给出了一个很有说服力的命题：多模态 reward acquisition 可以不从“训练一个 reward head”开始，而从“演化一套会看图、会查证、会解释的评审库”开始。 对后续视觉 RL / agentic evaluator / human preference bootstrapping 工作，这个视角很可能比表格里的 2–5 个点涨幅更持久。

Paper Notes

探索

RewardHarness: Self-Evolving Agentic Post-Training

RewardHarness: Self-Evolving Agentic Post-Training

1. Motivation（研究动机）

2. Idea（核心思想）

3. Method（方法）

3.1 Overall framework

3.2 Problem formulation

3.3 Skills and Tools Library

3.4 Orchestrator / Router

3.5 Sub-Agent inference

3.6 Self-Evolution Loop

4. Experimental Setup（实验设置）

4.1 Datasets and scale

4.2 Baselines

4.3 Metrics

4.4 Training / serving config

5. Experimental Results（实验结果）

5.1 Main benchmark numbers

5.2 Reward as downstream RL signal

5.3 Library evolution and ablation-style findings

5.4 Limitations

目录