AutoResearchClaw: Self-Reinforcing Autonomous Research with Human-AI Collaboration

Paper: arXiv:2605.20025
Code: aiming-lab/AutoResearchClaw
Code reference: main @ bc9dd501 (2026-05-21)

1. Motivation（研究动机）

这篇论文的核心问题不是“能不能让 LLM 自动写一篇论文”，而是更尖锐的：一个 autonomous research agent 在真实研究闭环里，能否像人类研究者一样从失败、质疑、返工和跨项目经验中变强。作者认为现有系统大多把科研简化成一条线性流水线：给定题目，生成假设，写代码，跑实验，写论文。这个抽象太干净，因此忽略了真实科研中最常见、也最决定质量的部分：假设经常不够可检验，代码经常因为依赖或设计错误失败，初步结果常常不能支撑原来的 claim，而写作阶段又最容易把“跑出来的数字”和“想证明的故事”混在一起。

论文把这些失败归纳成三类系统性缺口。第一，很多 autonomous research 系统是 single-agent 或弱协作的，缺少在假设阶段主动制造反对意见的机制。AI Scientist v2 这类系统可以从 idea 到 paper 走完整流程，但在假设质量和实验可证伪性上主要依赖一个模型链路；如果初始 idea 很弱，后续代码和写作反而会把这个弱点包装起来。第二，系统常常在 execution failure 后停止，或者只做局部修 bug，不能判断应该继续 refine、换实验设计，还是回到 hypothesis generation 做 pivot。AIDE-ML 更像强代码/实验 agent，但它不承担完整论文写作与科研判断闭环。第三，既往系统的“经验”通常只存在于一次 run 内部；即使某个任务中发现了常见坑，例如所有 ablation 退化成同一个条件、指标完全相同、citation 无法验证，下一次任务也未必能显式继承这些教训。

AutoResearchClaw 的动机因此是把科研 agent 从“线性任务执行器”改造成“自我强化的研究组织”。这里的 self-reinforcing 有两个含义：一是在单次研究中，系统持续用 debate、verification、HITL gate 和 Pivot/Refine 决策修正自身轨迹；二是在多次研究之间，系统把失败、修复、人工反馈、引用验证结果抽象成 lesson store，以 time-decayed 的方式注入新任务。作者强调，人类研究者真正有价值的不是一次就做对，而是能识别“这个结果不支持我的假设”“这个 baseline 缺了”“这个数字不该写进论文”“这个领域需要专门软件栈”等信号。AutoResearchClaw 试图把这些信号制度化。

这篇工作也试图纠正 automated science 评测中的一个偏差：仅看代码能否运行或最终论文是否像样是不够的。真正关键的是 claim-data alignment：论文里的每一个数值、对比、结论是否能追溯到实验日志和结果文件。为此作者提出 ARC-Bench，一个 25-topic、CPU 可执行、十分钟级别的 ML benchmark，并把评价拆成 Code Development、Code Execution 和 Result Analysis。Result Analysis 权重最高，因为自动科研最危险的错误不是代码报错，而是代码跑完后系统写出看似合理但没有实验支撑的科学叙事。

2. Idea（核心思想）

AutoResearchClaw 的核心思想可以概括为：把自主科研拆成 23 个有 contract 的 stage，并在关键 stage 插入四类“纠偏机制”——multi-agent debate、self-healing execution、verified reporting、human-in-the-loop，同时用 cross-run evolution 把纠偏经验沉淀下来。它不是只提出一个新 planner，也不是只增强代码生成器，而是把研究流程中容易失真的位置都变成显式控制点。

第一类纠偏是 debate。系统在 hypothesis generation 使用三类角色：Innovator 负责提出大胆方向，Pragmatist 负责检查可行性和实验成本，Contrarian 负责攻击假设的漏洞；综合器再把它们压缩为 2—4 个可证伪 hypothesis，附带 testability criteria 和 required baselines。在 result analysis 阶段也有三类角色：Optimist、Skeptic、Methodologist。Optimist 寻找积极解释，Skeptic 挑战过度结论，Methodologist 检查实验设计和统计有效性。这种设计的关键不是“多问几个 LLM”，而是把 disagreement 作为结构化输入，让写作前先区分 supported claim 与 unsupported claim。

第二类纠偏是 self-healing execution。论文不是把实验失败都当作同一种错误，而是引入 complexity routing：如果实验复杂度高于阈值 τ=0.6，系统把实现交给外部 AI coding agent；否则使用内置 multi-phase code agent，先做 per-file blueprint，再按 dependency order 生成代码，最后通过 AST/static validation gates。运行阶段被放进 sandbox：依赖安装和数据下载可以有网络，正式实验执行阶段关闭网络，并通过 read-only harness 记录指标。这让系统能修代码，但不能在结果阶段随意更改 judge 或伪造外部资源。

第三类纠偏是 verification。AutoResearchClaw 把实验结果写入 verified numeric registry：均值、标准差、seed-level measurement、condition name、relative improvement 等都被注册成可允许的数字及其变体。论文写作 agent 只能只读访问这些注册值；写完后，verifier 会抽取 strict sections（Results、Experiments、Evaluation、Ablation 等）中的数字，拒绝 registry 中不存在或无法容忍匹配的数值。引用也做四层验证：CrossRef DOI、OpenAlex fuzzy title、arXiv lookup、Semantic Scholar fallback，再由 LLM 判断 relevance，明显 hallucinated 的 citation 会被移除。

第四类纠偏是 HITL。作者没有把 human feedback 设计成“全程人工批准”，而是比较七种 intervention mode：Full-Auto、Gate-Only、Thorough、CoPilot、Step-by-Step、Pre-Experiment、Post-Experiment。论文最重要的结论之一是：最好的 HITL 不是最多人工介入，而是在高杠杆节点介入。CoPilot 只在 idea workshop、baseline navigator、paper co-writer 等少数位置给人工输入，却显著优于 Step-by-Step。

最后，cross-run evolution 让系统避免“每次从零开始”。每次 run 结束后，系统从修复日志、Pivot/Refine 决策、HITL feedback、verification failure 中抽取 lesson，每条 lesson 有 category、severity 和 mitigation。新任务开始时按时间衰减权重检索相关 lesson 注入 prompt；这不需要模型微调，但让 agent 的 prompt context 带有机构记忆。论文声称这种记忆是 self-reinforcing 的关键，因为它让错误不只是局部 bug，而能变成未来任务的约束。

3. Method（方法）

Figure 1 解读：这张图把 AutoResearchClaw 画成三段主流程：Discovery、Experimentation、Writing。橙色节点是 HITL gate，底部的 evolution layer 则表示经验跨 run 回流。它最重要的信息是：系统不是在写作阶段才“包装结果”，而是在 hypothesis、experiment design、execution、analysis、paper revision 和 citation verification 中都设置了可中断、可回滚、可验证的控制点。

3.1 23-stage research state machine

论文把完整流程定义为 23 个 stage。Discovery 阶段从 Topic_Init、Problem_Decompose、Search_Strategy、Literature_Collect 到 Literature_Screen，再做 Knowledge_Extract、Synthesis、Hypothesis_Gen 和 Experiment_Design。Experimentation 阶段包括 Code_Generation、Resource_Planning、Experiment_Run、Iterative_Refine、Result_Analysis 和 Research_Decision。Writing 阶段包括 Paper_Outline、Paper_Draft、Peer_Review、Paper_Revision、Quality_Gate、Knowledge_Archive、Export_Publish 和 Citation_Verify。

这些 stage 的意义不只是方便展示，而是为 rollback 和 gate 提供离散锚点。例如 paper/code 中都把 Pivot 指向 Hypothesis_Gen，把 Refine 指向 Iterative_Refine；这样 Research_Decision 不再只是“继续/停止”，而能选择回到哪一层重做。论文默认 N_p=2 个 pivot budget 和 N_r=10 个 refine budget，防止 agent 在坏假设或坏代码上无限循环。代码侧的 researchclaw/pipeline/stages.py 也把 Literature Screen、Experiment Design、Quality Gate 标成 gate stages，说明人类介入不是任意插入，而是 stage contract 的一部分。

3.2 Multi-agent debate

Hypothesis debate 的流程是角色并行生成、综合器压缩、HITL guidance 注入。伪代码如下：

def generate_hypotheses_with_debate(context, llm, hitl_guidance):
    roles = PromptManager().debate_roles_hypothesis()  # Innovator, Pragmatist, Contrarian
    perspectives = _multi_perspective_generate(llm, roles, context)
    if all_failed(perspectives):
        perspectives = _default_hypotheses(context)
    synthesis = _synthesize_perspectives(llm, perspectives, prompt="hypothesis_synthesize")
    if hitl_guidance.exists():
        synthesis = apply_guidance(synthesis, hitl_guidance)
    save("hypotheses.md", synthesis)
    return parse_falsifiable_hypotheses(synthesis)

Result debate 与 hypothesis debate 类似，但输入换成实验结果、refinement log、condition summaries 和 seed confidence intervals。Optimist、Skeptic、Methodologist 的分工让系统在 paper draft 之前先问三个问题：数字中最强的正面发现是什么；哪些 claim 被数据削弱；实验方法是否足以支持这些结论。代码中 _execute_result_analysis 会把 stage 13 的 refinement_log.json、best metrics、condition summaries 和 warning 合并后再触发 debate，而不是只看最终 stdout。

3.3 Self-healing execution 与 complexity routing

论文定义实验复杂度 c∈[0,1]，来自六个维度：architectural depth、file count、domain difficulty、dependency chains、historical failure rate、control-flow complexity。released code 在 opencode_bridge.py 中把这个思想实现为加权打分： $c=0.25c_{component}+0.20c_{file}+0.20c_{domain}+0.15c_{condition}+0.10c_{failure}+0.10c_{dependency}.$ 如果 c >= 0.6，系统推荐 beast_mode，交给外部 OpenCode bridge；否则使用内置 code_agent。这点很关键：作者没有让一个通用 generator 处理所有实验，而是先判断实验是否需要更强的工程代理。_execute_code_generation 会注入 package/hardware/compute/dataset/multi-seed/BenchmarkAgent/domain/API docs 等上下文，生成后进行 validation 和 auto-repair；如果配置启用 OpenCode，则复杂任务走外部 coding agent。

Iterative refine 的控制逻辑可以写成：

def iterative_refine_stage(code_files, experiment_plan, sandbox, requested_iters):
    max_iters = min(requested_iters, 10)
    best_metric, best_files = None, code_files
    no_metric_runs, no_improve_runs = 0, 0
    for step in range(max_iters):
        prompt = build_refine_prompt(code_files, experiment_plan, previous_errors=True)
        candidate = llm_improve_code(prompt)
        candidate = merge_with_supporting_modules(candidate, best_files)
        if not validate_code(candidate):
            candidate = iterative_repair(candidate)
        result = sandbox.run(candidate, network_disabled=True)
        if runtime_failed(result):
            candidate = repair_from_stderr(candidate, result.stderr)
            result = sandbox.run(candidate, network_disabled=True)
        metrics = parse_metrics(result)
        if not metrics:
            no_metric_runs += 1
            if no_metric_runs >= 3: break
            continue
        if improves(metrics, best_metric):
            best_metric, best_files = metrics.primary, candidate
            no_improve_runs = 0
        else:
            no_improve_runs += 1
            if no_improve_runs >= 2: break
    save("refinement_log.json", best_metric, diagnostics=True)
    return best_files, best_metric

这段伪代码对应代码中的 _execute_iterative_refine：它会限制迭代次数、处理 timeout、合并 extracted files、保持 entry point、跑 static validation、调用 sandbox、检测 identical ablation 或 no-metrics 情况，并把 experiment_final/ 作为后续分析输入。这里的 self-healing 不只是 try/except，而是在每次失败后把错误转成下一轮 prompt 的诊断信号。

3.4 Verified registry、citation verification 与 anti-fabrication

Verified registry 是这篇论文最值得借鉴的安全设计。系统先从 experiment summary、condition summaries、metrics summary、pairwise difference、relative improvement 和 refinement log 中抽取数值，再生成允许的 rounding / percentage variants。写作阶段只能引用这些注册值。之后 verifier 对 strict sections 做数字抽取，如果某个 number 无法与 registry 在容差内匹配，就拒绝或插入 placeholder。

def build_verified_registry_and_verify(run_dir, paper_tex):
    registry = VerifiedRegistry.from_run_dir(run_dir, best_only=True)
    registry.add_variants(rounding=True, percentages=True, relative_improvements=True)
    report = verify_paper(
        paper_tex,
        registry=registry,
        strict_sections=["Results", "Experiments", "Evaluation", "Ablation"],
        tolerance=0.01,
    )
    if report.has_unverified_numbers_in_strict_sections():
        reject_export(report)
    return report

引用验证也服务同一个目标：论文不能把不存在或不相关的 citation 放进 bibliography。论文写的是四层 API 验证；代码侧在 _review_publish.py 中解析 cite keys、查找缺失引用、用 title overlap 和 external API 结果 cross-validate，无法解析的 citation 会被移除。这个机制限制了自动写作中常见的 bracket pseudo-citations 和 hallucinated bibliography。

3.5 HITL、SmartPause 与 cross-run evolution

HITL 不是单个开关，而是七种介入模式。SmartPause 会估计当前 stage 是否值得暂停。代码中的 confidence signal 把质量、模型自信、novelty risk、历史 rejection rate 和 stage criticality 组合起来： $C=0.30q+0.25r+0.15(1-n)+0.10(1-h)+0.20(1-k).$ 当 C 低于阈值（默认 0.7）时，系统暂停并请求人类输入。这个公式体现了论文对 HITL 的理解：越关键的 stage、越新奇且历史上越容易被拒绝的模式，越值得打断自动流程。

Cross-run evolution 的核心是 lesson 权重： $w(l)=s(l)\cdot \exp \left(-\ln 2\cdot \frac{\Delta t}{T_{1/2}}\right),T_{1/2}=30\text{days}.$ 也就是说，高 severity 的近期 lesson 会更强地注入新 prompt；老 lesson 会自然衰减。代码 evolution.py 会从 failed/blocked stages、pivot/refine decisions、stderr warning、NaN/Inf metrics 等处抽取 lesson，再构建 “Lessons from Prior Runs” overlay。

def smart_pause_and_evolve(stage, state, lessons, history):
    signal = ConfidenceSignal.from_stage(stage, state, history)
    if signal.overall_confidence < SmartPause.threshold:
        human_feedback = request_hitl(stage, state)
        state = apply_feedback(state, human_feedback)
    new_lessons = extract_lessons(state.logs, state.decisions, state.verification_failures)
    store.add(new_lessons)
    overlay = store.retrieve_relevant(state.topic, weight="time_decay")
    return inject_prompt_overlay(state.next_prompt, overlay)

3.6 Code mapping 与 paper-vs-code audit

Paper Concept	Source File	Key Class/Function
23-stage pipeline and rollback	researchclaw/pipeline/stages.py	Stage, GATE_STAGES, DECISION_ROLLBACK, MAX_DECISION_PIVOTS
Hypothesis debate	researchclaw/pipeline/stage_impls/_synthesis.py	_execute_hypothesis_gen, _multi_perspective_generate, _synthesize_perspectives
Result analysis debate	researchclaw/pipeline/stage_impls/_analysis.py	_execute_result_analysis, debate_roles_analysis, _execute_research_decision
Complexity-based code routing	researchclaw/pipeline/stage_impls/_code_generation.py, researchclaw/pipeline/opencode_bridge.py	_execute_code_generation, score_complexity, OpenCodeBridge
Sandbox execution and refinement	researchclaw/pipeline/stage_impls/_execution.py	_execute_experiment_run, _execute_iterative_refine, refinement_log.json
Numeric verification	researchclaw/pipeline/verified_registry.py, researchclaw/pipeline/paper_verifier.py	VerifiedRegistry, verify_paper, strict-section number rejection
Citation verification and export	researchclaw/pipeline/stage_impls/_review_publish.py	_resolve_missing_citations, missing citation removal, bibliography pruning
Smart HITL pauses	researchclaw/hitl/smart_pause.py	ConfidenceSignal, SmartPause.should_pause
Cross-run evolution	researchclaw/evolution.py	LessonEntry, extract_lessons, EvolutionStore.build_overlay
ARC-Bench judging	experiments/arc_bench/scripts/judge.py	run_llm_judge, artifact discovery, strict scientific reviewer prompt

代码审计后，论文与 released code 的主机制基本一致：23-stage enum、debate roles、complexity routing、iterative repair、verified registry、SmartPause、evolution store 和 ARC-Bench judge 都有可定位实现。一个实现层面的差异是 Citation_Verify 的位置：论文把它画成第 23 阶段；代码仍保留 Stage.CITATION_VERIFY=23 和阶段 contract，但在 export/publish 实现中已经执行缺失引用解析、无效引用移除和 bibliography pruning，并在 stages.py 注释里强调 hallucinated citations 必须 block export，而不是作为 noncritical stage 继续放行。因此 released code 更像把 citation verification 前移/并入 Stage 22 的发布门，而不是完全独立到最后再检查。

4. Experimental Setup（实验设置）

论文的评测分三条线。第一条是 experiment-stage ARC-Bench：25 个 CPU 可执行、十分钟级别的 ML research topics，覆盖 tabular ML、optimization、dimensionality reduction、NLP、AutoML、Gaussian process kernels、topic modeling、semi-supervised learning、dynamical systems、anomaly detection、feature selection、causal discovery、learning-to-rank 等。每个 topic 需要真实比较方法、运行实验、输出结构化 quantitative artifact，而不是只写 toy script。

第二条是 end-to-end pipeline evaluation：从 idea 到 paper 的完整流程。作者强调 judge 不只看最终 LaTeX 是否能编译，而是读取 code、metrics artifacts、README/claims、rubric 和 manifest；它要检查 implementation correctness、number grounding、verdict-data consistency 和 coverage。rubric 分三类：Code Development (CD) 权重 25、Code Execution (CE) 权重 25、Result Analysis (RA) 权重 50。严格总分为： $\text{overall\_strict}=\frac{{\sum }_l{w}_l{s}_l}{100},\text{results\_only}=\frac{{\sum }_{l\in CE\cup RA}{w}_l{s}_l}{75}.$ RA 权重最高，说明作者认为“是否正确解读结果”比“代码是否看起来完整”更接近科研质量。

第三条是 scientific-domain extension：20 个非纯 ML 任务，包括 10 个 high-energy physics、7 个 systems biology、3 个 statistics。这个设置用来测试 AutoResearchClaw 是否只是会做通用 ML benchmark，还是能通过 domain profiles/adapters 进入依赖特殊软件栈的领域。论文附录列出 domain support matrix：ML bank 有 8 个 profiles，HEP-ph 有 native profile，Bio 和 Chem 有多个 adapter/profile，Economics、Math、Computational Neuroscience 也通过 ML+adapter 支持。

Baselines 包括 AI Scientist v2 和 AIDE-ML。Agent Laboratory 没有被纳入 fair-input 的端到端执行比较，因为它不提供同等自主 execution pipeline。所有方法使用相同 LLM backbone GPT-5.3-codex、相同 sandbox/time budgets。需要注意，这不是神经模型训练论文，因此没有传统意义上的 learning rate、batch size、optimizer、GPU hours 等训练超参数；实验控制变量主要是 benchmark topics、judge rubric、sandbox/time budget、LLM backbone、HITL mode 和 agent components。代码侧可复查的配置来源包括 experiments/arc_bench/config/*、experiments/arc_bench/scripts/judge.py、config.researchclaw.example.yaml 和 pipeline stage implementations。

ARC-Bench 的 judge 采用两个 agent reviewers 独立评分；如果 per-leaf disagreement 超过 0.20，会重新 adjudicate；平均 per-leaf 绝对差小于 0.10 的情况也会被 audit。这种设计比简单 LLM-as-judge 更严格，因为 judge 被要求同时读 artifact 和 claim，并且对每个 rubric leaf 给出分数。

5. Experimental Results（实验结果）

5.1 Main ARC-Bench results

System	Code Dev	Code Exec	Result Analysis	Overall
AutoResearchClaw (CoPilot)	0.968	0.578	0.523	0.648
AutoResearchClaw (Full-Auto)	0.938	0.562	0.442	0.596
AIDE-ML	0.958	0.415	0.336	0.511
AI Scientist v2	0.712	0.442	0.261	0.419

主结果显示，AutoResearchClaw (CoPilot) 总分 0.648，比 AI Scientist v2 高 54.7%，比 AIDE-ML 高 26.8%。更重要的是 RA：CoPilot 的 Result Analysis 为 0.523，而 AI Scientist v2 只有 0.261，相对提升 100.4%。这说明系统提升并不主要来自“代码写得更像样”，因为 AIDE-ML 的 Code Dev 也达到 0.958；真正差异在 execution 后能否把数字变成可信科学结论。Full-Auto 也强于 baselines，但比 CoPilot 低，说明人类在少量关键节点介入确实提高了结果解释和最终质量。

论文还报告有效运行数：Full-Auto 在 25 个 topic 中有 2 个没有有效结果，AI Scientist v2 有 6 个失败。这与 self-healing 的定位一致：AutoResearchClaw 不保证每个 hypothesis 都正确，但能显著减少因环境、依赖、代码结构或实验控制错误导致的无效结果。

5.2 HITL mode comparison

HITL mode	Valid papers	Mean Q	Accept rate	Interventions
Full-Auto	8/10	4.03	25.0%	0
Gate-Only	10/10	5.03	50.0%	3
CoPilot	8/10	7.27	87.5%	6
Thorough	7/10	4.86	42.9%	8
Step-by-Step	10/10	5.19	50.0%	23
Pre-Experiment	8/10	4.28	37.5%	3
Post-Experiment	6/10	5.08	50.0%	3

HITL 实验的结论是：人工介入的质量比数量重要。CoPilot 的 Mean Q 达到 7.27、Accept rate 达到 87.5%，显著高于 Step-by-Step 的 5.19 和 50.0%。论文正文还提到 CoPilot 使用 19 个 targeted interventions，而 Step-by-Step 需要 29 个 intervention；表格中的 Interventions 列给出的是模式级/运行级计数（CoPilot 6、Step-by-Step 23）。这两个数字口径略有差异，但方向一致：全程逐步审批并不会自动提高科研质量，反而可能在低价值节点浪费人类注意力。

Gate-Only 值得单独看：它只在 Literature Screening、Experiment Design、Quality Gate 三个门介入，却能把 valid papers 提高到 10/10，accept rate 从 Full-Auto 的 25% 提到 50%。这说明最少量 gate 已经能避免大量结构性错误；但如果要获得最高质量，还需要 CoPilot 式的高杠杆支持，例如 idea workshop、baseline navigator 和 paper co-writer。

5.3 Scientific-domain extension

System	Biology	Statistics	HEP-ph	Overall
AutoResearchClaw (CoPilot)	0.912	0.898	0.489	0.867
AIDE-ML	x	0.452	x	0.090
AI Scientist v2	x	0.418	x	0.084

跨领域结果显示，AutoResearchClaw 在 Biology 和 Statistics 上分别达到 0.912 和 0.898，在 HEP-ph 上为 0.489，总体 0.867。Baselines 在 HEP/Biology 上基本失败，主要原因是缺少 domain-specific software 和 adapter。这个实验支持作者关于 domain profile 的主张：自主科研系统不能只会普通 Python/ML stack；进入 HEP 或 biology 时，软件栈、数据格式、实验约束和 baseline 选择都需要被显式编码。

5.4 Component ablations

Variant	Completion	Quality	Accept	Fabrication?
Full system	10/10	5.62	3/10	No
w/o Debate	10/10	4.25	1/10	No
w/o Self-Healing	6/10	4.83	1/6	No
w/o Evolution	9/10	5.14	2/10	No
w/o Verification	10/10	5.48	5/10	Yes
w/o Debate & Healing	4/10	3.47	0/4	No

Ablation 解释了主结果来自哪里。去掉 Debate 后质量从 5.62 降到 4.25，是最大质量损失；论文给出 p=0.003，说明多视角质疑确实改善 hypothesis 和 result interpretation。去掉 Self-Healing 后 completion 从 10/10 降到 6/10，是最大可靠性损失；这表明 execution failure 是 autonomous research 的主要断点。去掉 Evolution 后 completion 和 quality 都小幅下降，说明跨 run lesson store 提供的是渐进可靠性收益。最有意思的是 w/o Verification：completion 仍为 10/10，quality 5.48，accept 甚至 5/10，但出现 fabrication。也就是说，如果 judge 或人类只看“论文好不好看”，没有数字 registry，系统可能写出更顺滑但不可信的论文。

Figure 2 解读：这个 case study 比平均分更能说明问题。Full-Auto 在 T10 cross-validation strategy 任务中成功跑完并生成 51 个 metrics，却出现 silent semantic collapse：所有 CV 策略报告完全相同的 zero bias/variance，实验没有真正比较任何东西。CoPilot 通过人工和系统纠偏，记录九条 selection pipelines、57 个 metric keys，并产生非零 contrast，因此同一任务评分从 4.0 提升到 8.0。

T10 案例揭示了 verification 的边界：numeric registry 可以保证论文里的数字来自日志，但不能保证实验设计本身有区分度。如果所有条件都退化成同一个实现，registry 仍会认为这些零值是“真实数字”。因此 AutoResearchClaw 需要 debate、HITL 和 condition-breadth checks 一起工作：verification 防止编造，debate 检查结论，HITL 发现 baseline/condition 的语义问题。

5.5 Failure modes、writing artifacts 与局限

论文对失败案例也做了分类。13 个 invalid canonical HITL runs 中，11 个失败在 Stage 17 paper_draft。失败子类包括：没有真实 metrics；环境或依赖破裂，例如 imblearn、LightGBM；dataset/resource failure；以及 design/aggregation pathology。写作质量审计还发现若干自动论文常见 artifact：abstract before \maketitle 出现 20/20，Markdown-style figure captions 被写成 section headings 出现 17/20，duplicated figure file 出现 16/20，learned skills/a-evolve 泄漏出现 9/20，bracket pseudo-citations 出现 2/20。LaTeX compile rate 也不是满分：step-by-step 为 4/5，full-auto 为 3/5。

这些失败说明 AutoResearchClaw 仍然不是“自动科学家”。它更像一个把科研流程制度化的 agentic research workbench：能提高 hypothesis scrutiny、execution robustness、result grounding 和少量人工介入的效率，但仍需要人类对研究意义、伦理边界、领域可行性和最终论文质量负责。作者也明确指出，工具可能带来 submission flooding 风险；当前 runs 的 LLM 成本约为 3—15 美元，成本下降后更需要 publication policy 和 reviewer-side detection/triage。

从方法论角度看，这篇论文最可迁移的贡献不是某个单点算法，而是一套 anti-fabrication-oriented agent design pattern：每个阶段有 contract，关键阶段有反方视角，执行失败有有限预算的 repair/pivot，写作数字来自 registry，引用必须可验证，经验必须进入下一次 prompt。对于后续 agentic research 系统，AutoResearchClaw 给出的启发是：不要只优化“能不能自动产出论文”，而要优化“失败是否被看见、数字是否可追溯、claim 是否被证据约束、人工注意力是否花在真正高杠杆的位置”。