Esc
输入关键词开始搜索
News

ARIS: Autonomous Research via Adversarial Multi-Agent Collaboration

ARIS: Autonomous Research via Adversarial Multi-Agent Collaboration

原文链接:https://arxiv.org/abs/2605.03042 项目主页:https://github.com/wanshuiyin/Auto-claude-code-research-in-sleep 发布日期:2026-05-04

速查卡

项目内容
一句话总结ARIS 不主张“让一个更强的模型独立做完研究”,而是把研究流程拆成可检查的工作流,并默认用不同模型家族做 executor / reviewer 对抗协作,再叠加证据到 claim 的三阶段审计。
核心对象这是一套 autonomous ML research harness,不是新基座模型,也不是新的 benchmark 训练方法。
系统规模v0.4(2026 年 4 月)包含 65+ 个 Markdown skill、5 条端到端 workflow、6 个 MCP model bridge、4 级 effort preset、每项目 4 类 research wiki 实体。
assurance 重点三阶段 evidence-to-claim audit、五遍 scientific editing、proof checker、视觉 PDF review、citation audit。
部署证据论文报告 3 个已测试 executor 平台、3 个适配平台;一次约 8 小时的 overnight run 完成 4 轮 review-revise、20+ GPU 实验,内部 reviewer score 从 5.0 提到 7.5/10。
论文性质以系统设计与早期部署经验为主,没有给出 compute-matched controlled benchmark。
关键词research harness, cross-family review, claim ledger, manuscript assurance, persistent wiki, skill orchestration

核心 Insight

ARIS 的核心判断非常激进,但也很清楚:

  1. 单 agent 做长周期研究,默认不可靠。 论文把主要风险定义为“plausible unsupported success”——看起来成功、实际上证据链不完整,或者论文 claim 已经跑到实验支持范围之外。
  2. 问题不只是模型能力,而是 harness 设计。 真正决定研究 agent 是否靠谱的,是信息怎么存、怎么取、怎么让 reviewer 看到原始材料,而不是只看权重大小。
  3. review 不能继续沿用 executor 的叙事。 reviewer 必须直接读 artifact、结果文件、代码或论文源码,而不是先听 executor 摘要,否则审的是 framing,不是事实。

这也是 ARIS 和很多“自动科研 agent”最不同的地方:它不把 review 当最后一轮润色,而是把 assurance 提前做成系统层默认机制。

方法详解

整体架构:三层 research harness

ARIS 把系统拆成三层:

  1. Execution layer

    • 65+ 个以 SKILL.md 编写的 Markdown 技能;
    • 通过 MCP 接多类模型;
    • research wiki 做持久化项目记忆;
    • FigureSpec + renderer 做确定性画图。
  2. Orchestration layer

    • 5 条 workflow:Idea Discovery、Experiment Bridge、Auto Review Loop、Paper Writing、Rebuttal;
    • 提供 checkpoint 恢复、effort preset、reviewer routing。
  3. Assurance layer

    • 三阶段 evidence-to-claim 审计;
    • 五遍 scientific editing;
    • proof-checker;
    • visual PDF review;
    • citation audit。

论文把这三层分别对应到三个系统瓶颈:

  • persistent research state
  • modular execution
  • independent assurance

五个设计原则

1. Heterogeneous models over single-model self-refinement

ARIS 默认推荐 executor 和 reviewer 来自不同模型家族。论文给出的默认组合是 Claude family 执行 + GPT family 审稿,或者反过来;也可接 Gemini、MiniMax,以及通过通用 OpenAI-compatible bridge 接 GLM、Kimi、DeepSeek。

作者的论证不是“异构一定更强”这一经验定律,而是更保守的工程判断:同家族模型在生成和审查时更容易共享偏差,异构 reviewer 更可能暴露 executor 没注意到的问题。

2. Modular skill files over monolithic agents

每个能力主要由单文件 SKILL.md 描述,包含:

  • YAML frontmatter
  • 输入输出
  • 流程步骤
  • 质量门槛
  • 失败处理指令

这意味着系统不是靠一个巨型 prompt end-to-end 硬跑,而是把研究过程拆成可替换、可复查的最小单元。

3. Composability over fixed pipelines

skills 可以按 workflow 编排,支持参数覆盖与 checkpoint 恢复。论文强调 plain-text artifact contract:例如 IDEA_REPORT.mdEXPERIMENT_LOG.mdNARRATIVE_REPORT.md 在不同 skill 之间传递状态。

4. Portability over vendor lock-in

skill 库是纯文本分发,不依赖平台专属 runtime;同一批 SKILL.md 在 Claude Code、Codex CLI、Cursor 上都可复用,不需要改文件级定义。

5. Persistent memory over ephemeral context

每个项目维护 research wiki,存四类实体:

  • papers
  • ideas
  • experiments
  • claims

并通过 8 种 typed relation 形成轻量知识图:extendscontradictsaddresses_gapinspired_bytested_bysupportsinvalidatessupersedes

作者特别强调:把失败想法也写入 wiki,能避免 system 在多 session 中反复重提同一死路。

训练策略 / 系统运行策略

这篇论文不是模型训练论文,没有给出预训练、SFT 或 RL 训练配方。更准确地说,ARIS 的“策略”体现在运行时编排而不是参数更新:

1. Cross-model critique-to-action loop

executor 先产出 artifact;reviewer 按 rubric 给分并返回 action items;executor 修订;convergence check 决定是否再来一轮。

默认停止条件:

  • reviewer score 超过阈值,默认 6/10
  • 且 critical review items 已解决
  • 或达到最大轮数,默认 4

2. Reviewer independence protocol

reviewer 不是看 executor 摘要,而是直接读被引用文件。这样可以降低 reviewer 被 executor framing 带偏的风险。

3. Reviewer configuration

论文定义两条正交轴:

  • access scope

    • document-only
    • artifact-augmented
    • repository-level
  • context policy

    • fresh:每轮新线程,无历史上下文
    • cross-round:跨轮保留记忆,重点验证修复是否完成

其中 paper-claim-audit 与 auto-paper improvement loop 要求 fresh reviewer,以抑制确认偏差。

4. 自动调试与兜底诊断

实验失败时:

  • 先归类到预定义 error class;
  • 执行该类 remediation;
  • 最多重试 3 次;
  • executor 至少尝试 2 种不同修复策略;
  • 若仍失败,可调用第三个独立模型做 rescue diagnosis。

assurance 机制详解

三阶段 Evidence-to-Claim Audit Cascade

Stage 1: /experiment-audit

审计 evaluation code 与输出,重点查 5 类问题:

  1. model-derived reference labels
  2. self-normalized scores
  3. phantom results
  4. dead-code / unused-metric inflation
  5. scope inflation

输出:

  • EXPERIMENT_AUDIT.md
  • machine-readable JSON summary

这是 advisory 审计,不会直接硬停工作流,但后续 stage 会继承其 warning / failure 状态。

Stage 2: /result-to-claim

把每条候选实验结论映射成 claim verdict:

  • supported
  • partially supported
  • invalidated

并生成 claim ledger。如果 Stage 1 标成 fail,则该 claim 不能在完整意义上被标记为 fully supported。

Stage 3: /paper-claim-audit

fresh zero-context reviewer 直接读论文 LaTeX 源码、原始结果文件和配置文件,逐条核对 quantitative claims。论文给出的典型错误类型包括:

  • numerical mismatch
  • cherry-picking best seed
  • config mismatch
  • aggregation / delta arithmetic error
  • scope overclaim

每条 claim 会得到如 exact_matchrounding_oknumber_mismatchconfig_mismatchmissing_evidence 等结构化状态。

Manuscript assurance

除了 claim 审计,论文还做了 4 个论文质检模块:

  1. 五遍 scientific-editing pipeline

    • clutter removal
    • active voice
    • sentence structure
    • terminology consistency
    • numerical consistency
  2. /proof-checker

    • 20 类 issue taxonomy
    • 严重度拆成 proof status 与 impact 两轴
    • 输出 proof-obligation ledger
  3. visual PDF review

    • reviewer 同时看 LaTeX 源码与编译 PDF
    • 检查 figure readability、caption 对齐、layout、table formatting、color consistency
  4. /citation-audit

    • existence
    • metadata correctness
    • context appropriateness

其中第三项最关键,因为它检查“这篇文献是否真的支撑你现在这句话”,而不只是 bib 信息真不真。

与现有方法区别

与 AI Scientist / Agent Laboratory / data-to-paper 的差异

维度既有系统(按文中对照)ARIS 的做法差异含义
executor-reviewer 关系多数没有显式 cross-family 机制,或只做 partial adversarial review默认 cross-family reviewer-executor separation目标是降低同分布偏差与自我背书
流程结构常是端到端强耦合skill + artifact contract + workflow每一步更可替换、更可审计
持久记忆多数没有 per-project 结构化 wiki4 类实体 + 8 类关系能跨 session 累积负结果与 claim 状态
assurance常只有 review 或 traceability 的局部机制三阶段 claim 审计 + 写作 + 引用 + proof + PDF 质检把“证据是否支持论文”前置成系统职责
portability常依赖某一平台或框架纯文本 skill,跨多个 executor 环境降低平台锁定

作者给出的 feature comparison

SystemCross-family policyAdversarial reviewComposable skillsE2E research workflowsAssurance stackCross-platform portability
AI Scientistnonepartial×partial×
AI Scientist-v2nonepartial×partial×
Agent Laboratorynone××××
data-to-papernonepartial×✓(数据到论文)partial×
AutoGennone×partial×××
MetaGPTnonepartialpartial×××
OpenHandsnone×partial×××
ARISdefault✓†

注: 指论文声称已在 3 个平台测试,并为另外 3 个平台提供适配指南。

实验结果表格

表 1:系统实现规模(论文 Table 1)

ComponentScope
SkillsMore than 65 Markdown-defined files
Workflows5 end-to-end (+ full pipeline command)
Model bridges6 MCP bridges (Codex, Oracle, Claude, Gemini, MiniMax, llm-chat)
Tested executors3 (Claude Code, Codex CLI, Cursor); 3 adapted
Assurance stack3-stage audit cascade + manuscript quality
Persistent memoryPer-project research wiki (4 entity types)
Effort presets4 levels (lite / balanced / max / beast)
DependenciesNone for skills; single binary for CLI

表 2:workflow library(论文 Table 2)

WorkflowInputOutputKey Skills
1. Idea DiscoveryResearch directionRanked idea reportresearch-lit, idea-creator, novelty-check, experiment-plan
1.5. Experiment BridgeExperiment planRunning code + resultsexperiment-bridge, run-experiment, monitor-experiment
2. Auto Review LoopDraft + resultsImproved paperauto-review-loop, research-review, analyze-results
3. Paper WritingNarrative reportCompiled PDFpaper-plan, paper-figure, paper-write, proof-checker, paper-claim-audit, paper-compile, auto-paper-improvement-loop
4. RebuttalPaper + reviewsPaste-ready rebuttalrebuttal (7-phase pipeline with 3 safety gates)

表 3:deployment footprint(论文 Table 3)

DimensionCurrent Status
Executor platforms3 tested + 3 adapted (6 total)
Reviewer models6+ (GPT, Gemini, GLM, MiniMax, Kimi, DeepSeek)
GPU backends4 (local, SSH, Vast.ai, Modal)
Venue templates9 families
Free-tier API accessModelScope (no paid API keys required)
Community contributions30+ contributed skills across robotics, hardware, communications, math

论文唯一给出的“运行型证据”

指标数值 / 描述
overnight run 时长约 8 小时
review-revise 轮数4
internal reviewer score5.0 → 7.5 / 10
GPU experiments20+
行为效果移除了证据不充分的 claims

作者明确强调:这些都是 observational evidence,不能因果归因到 ARIS,也不能据此证明 cross-family review 必然优于 same-family。

消融 / 可扩展性

论文没有做标准消融

ARIS 没有像训练论文那样给出 ablation table,例如“去掉 reviewer / 去掉 claim audit / 去掉 wiki”后的性能变化。作者在 Appendix E 只提出未来的 controlled benchmark protocol,而没有在本文中完成。

论文给出的可扩展性线索

  1. skill 库扩张:从初始发布的 21 个 core skills 增长到 65+。
  2. 跨平台适配:3 个 tested executors + 3 个 adapted executors。
  3. effort presetlite / balanced / max / beast 通过提高 breadth、depth、iteration 做运行时扩展,而不是改 reviewer 的 reasoning budget;Codex reviewer 仍固定用 xhigh。
  4. meta-optimization prototype
    • 被动事件记录到 .aris/meta/events.jsonl
    • /meta-optimize 分析 override 最多的参数、重复失败的工具、review score plateau
    • reviewer 打分至少 7/10 才把 patch 推荐给用户
    • 永不自动应用 harness 修改

SOTA 对照矩阵

严格说,ARIS 不是在统一 benchmark 上报告 SOTA 分数的论文,因此不能把它写成“研究 agent SOTA 已被证明”。更准确的矩阵是:论文在功能维度上把自己定位成当前少见的“默认跨模型对抗审稿 + 显式 assurance stack + 可组合 skill + 持久 wiki”的 research harness。

维度ARIS 的结论证据类型
Cross-family review 默认化系统设计与默认配置
多阶段 evidence-to-claim assurance技能与 workflow 描述
结构化持久 research memorywiki 设计 + 4 类实体 / 8 类关系
多平台可移植性3 tested + 3 adapted
Benchmark SOTA论文未声称,也未做 controlled benchmark不适用

复现评估

维度评分(1-5)说明
开源可得性⭐⭐⭐⭐GitHub 已公开,论文提供项目页。
系统透明度⭐⭐⭐⭐⭐skill、workflow、audit stage、review policy 都写得很细。
复现实验性结论⭐⭐因为本文主要是系统报告,缺少 controlled benchmark。
工程复杂度⭐⭐⭐⭐⭐需要多模型路由、artifact contract、wiki、审计工具链、LaTeX/PDF 流程。
研究使用价值⭐⭐⭐⭐对长周期研究 agent 设计非常有启发,尤其适合高风险 claim 管理。

复现建议

如果要复现,最应该先做的不是全量跑五条 workflow,而是先验证三条“硬机制”:

  1. reviewer independence protocol 是否真的阻止 executor framing;
  2. claim ledger 是否能稳定把 result 与 manuscript claim 对齐;
  3. fresh reviewer 与 cross-round reviewer 在不同场景下是否有明显 trade-off。

批判性分析

这篇论文最强的地方

  1. 把失败模式定义得很具体。 “plausible unsupported success” 这个概念抓住了长周期 agent 最危险的问题:不是报错,而是一本正经地错。
  2. 把 assurance 从附加组件升成 workflow 默认层。 这比“最后找另一个模型 review 一遍”要系统得多。
  3. 对 portability 和 inspectability 很克制。 用纯文本 skill + 文件系统状态,降低了框架黑箱化。

主要局限

  1. 没有 controlled benchmark。 论文自己承认,目前没有 compute-matched 比较来回答“cross-family 究竟比 same-family 强多少”。
  2. 部署证据是 observational,不是因果证据。 一次 overnight run 很能说明系统能跑,但不能说明设计选择最优。
  3. reviewer bias amplification 仍然存在。 如果 reviewer 偏好某种方法,loop 可能让论文向该偏好过拟合。
  4. repository-level review 有隐私风险。 论文明说敏感代码库不应直接外发给外部 API reviewer,本地 reviewer 还没实现。
  5. 系统复杂度高。 你得到的是更高 rigor,但也得到更高 orchestration 成本、更多 failure mode 和更多 API / tool dependencies。

独立判断

ARIS 真正新颖的不是“多 agent”三个字,而是把 autonomous research 的可信度问题拆成:

  • 产物生成
  • 证据审计
  • 论文陈述核对
  • 视觉与引用质检

也就是说,它把“研究自动化”从单纯追求 throughput,推进到开始认真处理 accountability。这条路线未必最快,但明显更接近真正能用于科研协作的系统形态。