EvoMaster: A Foundational Evolving Agent Framework for Agentic Science at Scale

Paper: arXiv:2604.17406 Code: sjtu-sai-agents/EvoMaster Code reference: main @ 069631b5 (2026-05-20)

1. Motivation (研究动机)

当前科学智能体的核心矛盾不是“能不能调用 LLM 和工具”,而是“能不能把科学研究这种长周期、跨学科、反复试错的过程规模化”。论文把问题定义为 Agentic Science at Scale:如果一个 AI agent 能在数小时内完成文献调研、假设生成、实验设计、代码执行、结果分析和论文写作,那么下一步瓶颈就从单个 demo 的能力转移到大规模、跨领域构建和复用 agent 的工程架构。

论文指出现有方法有两类具体瓶颈。第一是 fragmented / siloed development:ChemCrow、MLAgentBench 等系统往往围绕单一领域和单一工具链定制,工具编排、轨迹管理、错误恢复、上下文管理等 harness 逻辑被重复实现;一个领域的改进难以迁移到另一个领域。第二是 absence of evolution:很多 agent 以 single-pass 方式执行任务,失败后不会把失败模式、调试经验、有效策略沉淀到下一轮;这与科学方法中的 hypothesis → experiment → refinement 循环不匹配。

EvoMaster 要解决的目标是构建一个面向科学智能体的 foundational harness:它既能把 Playground / Experiment / Agent / Tool / Skill / Session 等通用执行层抽象出来,降低新领域 agent 的边际开发成本,又能让 agent 在多轮执行中保留轨迹、压缩上下文、反思失败、生成局部技能或 prompt overlay,从而支持持续演化。论文强调新领域 agent 可用约 100 行 orchestration code 接入框架,这一点是它与单点 agent demo 的主要差别。

这个问题值得研究的原因在于,科学发现的很多成本来自跨轮实验的知识积累与跨领域基础设施复用。如果 harness 可复用,ML 工程、网页检索、前沿科学推理、物理/具身实验等 agent 可以共享工具协议、上下文策略、轨迹格式、运行环境和多智能体编排;如果 evolution 可复用,单次失败不再只是日志,而会变成下一轮策略、skill、prompt patch 或 tool proposal 的输入。

2. Idea (核心思想)

核心洞察:科学智能体不应被设计成一次性任务执行器,而应被设计成一个可复用、可观测、可演化的实验系统。EvoMaster 把“科学研究循环”落到工程结构上:每次运行都被配置化、轨迹化、可审计化;每个 agent 都在 reason → tool → observe → critique 的循环中工作;跨任务/跨轮的经验通过 context、skill、prompt overlay 和 trajectory digest 继续影响后续执行。

关键创新可以概括为三层:执行层用 Playground / Exp / Agent 解耦多智能体编排、单次实验生命周期和 agent 推理循环;能力层用 MCP Tool、Skill、LLM abstraction 和 Session abstraction 统一外部工具、领域知识和运行环境;演化层用 trajectory/log/artifact collector、LLM/heuristic analyzer、overlay applier 把一次 run 的经验转成 run-local skills、prompt patches 和 tool proposals。

与通用 agent 框架(如 OpenClaw)相比,EvoMaster 的根本差异不是工具数量,而是它把 scientific workflow 作为一等公民:OpenClaw 更像通用助手平台,EvoMaster 则围绕可复现实验、长周期上下文、科学 benchmark adapter、多 agent peer-review 和演化式知识积累设计。与单领域 agent(如只面向化学合成或 Kaggle)的差异在于,EvoMaster 把领域逻辑放到 Playground / config / skills 中,而把通用 harness 留在框架内,使一个领域的基础能力改进可以自动惠及其他 SciMaster agents。

3. Method (方法)

3.1 Overall framework:从 foundational inputs 到 self-evolution core

Figure 3 解读:图中间的 EvoMaster Framework 是 continuous self-evolution core,外圈把“迭代优化与知识积累循环”连接到五个关键系统:Playground Orchestrator 负责多 agent 工作流,Agent Engine 执行推理-工具-观察循环,Context Manager 维持长上下文,Trajectory System 记录实验过程,Tool / Skill System 注入工具和领域知识。底部的 foundational inputs 对应环境、智能模型和能力接口:Local Sandbox / Docker / Remote Cloud Labs,OpenAI / Anthropic / Google 等后端模型,以及 MCP servers、scientific tools、web APIs、data sources。顶部的 SciMaster ecosystem 表明这些基础设施被复用到 ML-Master 2.0、X-Master、Browse-Master、X-Master 2.0、PhysMaster、EmboMaster 等领域 agent。

EvoMaster 的框架可以理解成一个三层系统:

  • Execution ArchitecturePlayground 决定多 agent 拓扑和科学 workflow;Exp 管理一次实验的 task instance、trajectory 和结果;Agent 执行多轮 reactive loop。这个分层直接对应论文中的 Modular Composability。
  • Capability Layer:Tool System 把 builtin tools 与 MCP tools 标准化成统一 tool registry;Skill System 把领域知识以元数据常驻、细节按需加载的形式注入;LLM abstraction 允许同一 agent 在不同模型后端之间切换。
  • Evolution Layer:常规 run 会生成 trajectory/log/artifact;可选 --evolve wrapper 会先跑 baseline,再从运行目录收集 digest,生成 skills / prompt patches / tool proposals,写入 overlay config 后 rerun。

直觉上,EvoMaster 的有效性来自“把科学循环变成系统接口”。在普通 agent 中,失败只是上下文里的一段文本;在 EvoMaster 中,失败会被记录进 trajectory、压缩成 digest、被 analyzer 抽取成候选 skill 或 prompt patch,再以 overlay 形式进入下一轮。这样一来,长任务的收益不是一次性答案,而是逐轮改进的 agent 行为。

3.2 Design principles 与对应机制

Modular Composability

论文把单体 agent 系统拆成 Playground、Experiment、Agent 三层。代码中 BasePlayground 负责加载 config、初始化 session/tools/skills/agents、创建 BaseExpBaseExp 把用户任务封装成 TaskInstance,调用 agent run;BaseAgent 专注于 LLM query、tool call、context truncation 和 trajectory logging。移除这个分层后,新领域 agent 需要重复实现运行目录、工具注册、轨迹保存、模型配置和多 agent 编排,扩展成本会重新变高。

Experiment-Ready Harness

EvoMaster 把配置和可观测性放在核心路径:ConfigManager 读取 YAML 并支持 ${VAR} 环境变量替换;run.py 统一处理 --agent--config--task--task-file--parallel--run-dir--evolveBaseAgent._append_trajectory_entry 用文件锁把每一步 prompt、assistant response 和 tool responses 追加到 JSON trajectory。这里的输出不是普通日志,而是后续评估、debug 和 evolution 的可机器读取材料。

Iterative Self-Evolving

Agent Engine 的基本循环是:准备上下文 → 调用 LLM → 处理 tool calls → 写入 observation → 更新 trajectory → 决定是否 finish。论文描述为 reason → invoke tools → observe → self-critique;released code 中显式实现了 reason/tool/observe/finish 和上下文压缩,self-critique 更多由 prompt / SciMaster workflow 触发,而不是一个固定硬编码 loss。

Multi-Agent Collaborative Evolution

AgentSlots 让 Playground 以 self.agents.solverself.agents.criticself.agents.rewriter 这类 slot 访问 agent;BasePlayground 可创建多个 agent 并支持 sequential handoff、parallel exploration、peer-review cycle。HLE 的四阶段 pipeline(Solve、Critique、Rewrite、Select)就是这种结构化协作的实验体现:solver 给出候选,critic 找错,rewriter 改写,selector 选择最终答案。

3.3 评估与演化的形式化描述

论文没有给出神经网络训练 loss,也没有定义可微优化目标;它的“优化”主要是 agent workflow 的迭代改进与 benchmark 得分提升。可以把一次 agent 运行形式化为: 其中 是对话/轨迹状态, 是任务描述, 是工具集合, 是 skills, 是 LLM 与 prompt/config 参数, 是 assistant/tool action, 是 observation 或 evaluator feedback。演化 wrapper 则把完整运行轨迹 压缩为 digest,并产生 overlay: 其中 是 run-local skills, 是 prompt patches, 是 tool proposals。论文表格中的相对提升使用: 论文公式与 released code 实现差异:论文把“continuous self-evolution”作为整个 SciMaster ecosystem 的核心原则,并把 MLE-Bench / BrowseComp / HLE 的 benchmark-specific pipeline 都视为 evolution 的体现;released code 中额外提供的 --evolve 是一个可选 post-run wrapper,具体流程是 baseline run → collect digest → analyze candidates → materialize overlay config → rerun。也就是说,论文实验结果不应被简单等同于 evomaster/evolution/manager.py 的 optional wrapper;它更可能来自各 SciMaster agent 的领域 workflow 与认知缓存策略。

3.4 Pseudocode:Agent reactive loop

class EvoMasterAgent:
    def run(self, task, max_turns):
        self.initialize_dialog(task)
        for turn in range(max_turns):
            should_finish = self.step()
            if should_finish:
                self.trajectory.status = "success"
                break
        else:
            self.trajectory.status = "max_turns_reached"
        return self.trajectory
 
    def step(self):
        dialog_for_query, compacted = self.context_manager.prepare_for_query(self.current_dialog)
        if compacted:
            self.current_dialog = dialog_for_query
            self.trajectory.dialogs[-1] = self.current_dialog
 
        assistant_msg = self.llm.query(dialog_for_query)
        self.context_manager.update_usage(assistant_msg.meta.get("usage", {}))
        self.current_dialog.add_message(assistant_msg)
        step_record = StepRecord(assistant_message=assistant_msg)
 
        if not assistant_msg.tool_calls:
            if self.config.finish_on_text_response or not self.enable_tools:
                self.save_step(dialog_for_query, step_record)
                return True
            self.handle_no_tool_call()
            self.save_step(dialog_for_query, step_record)
            return False
 
        for call in assistant_msg.tool_calls:
            if call.function.name == "finish":
                step_record.tool_responses.append(ToolMessage("Task marked as finished."))
                self.save_step(dialog_for_query, step_record)
                return True
            observation, info = self.execute_tool(call)
            observation = truncate_if_too_long(observation, max_chars=30000)
            step_record.tool_responses.append(ToolMessage(observation, info=info))
            self.current_dialog.add_message(step_record.tool_responses[-1])
 
        self.save_step(dialog_for_query, step_record)
        return False

3.5 Pseudocode:Context Manager 的两级压缩

class ContextManager:
    def prepare_for_query(self, dialog):
        usable = self.config.max_tokens - RESERVED_OUTPUT_TOKENS
        if self.last_prompt_tokens > 0:
            delta = estimate_new_message_tokens(dialog, self.last_prompt_msg_count)
            tokens = int((self.last_prompt_tokens + delta) * 1.05)
        else:
            tokens = int(self.estimate_tokens(dialog) * 1.05)
 
        if tokens >= usable:
            # permanent compaction: latest-half / sliding-window / summary
            return self.truncate(dialog), True
        if tokens >= int(usable * 0.8):
            # temporary view: clear old tool outputs but keep recent turns
            return self.prune_old_tool_outputs(dialog), False
        return dialog, False
 
    def prune_old_tool_outputs(self, dialog):
        protected_recent_user_turns = 2
        prunable = find_old_tool_messages(dialog, after_user_turns=protected_recent_user_turns)
        if estimated_tokens(prunable) < PRUNE_MINIMUM_TOKENS:
            return dialog
        return replace_contents(prunable, "[Old tool output cleared]")

3.6 Pseudocode:Playground / Experiment 分层执行

class EvoMasterPlayground:
    def run(self, task_description, output_file=None, images=None):
        self.setup()  # config, session, tools, skills, agents
        self.setup_trajectory_file(output_file)
        exp = self.create_exp()
        try:
            return exp.run(task_description, images=images)
        finally:
            self.cleanup()
 
class BaseExp:
    def run(self, task_description, task_id="exp_001", images=None):
        task = TaskInstance(
            task_id=task_id,
            task_type="discovery",
            description=task_description,
            images=images or [],
        )
        trajectory = self.agent.run(task)
        result = {
            "task_id": task_id,
            "status": trajectory.status,
            "steps": len(trajectory.steps),
            "trajectory": trajectory,
        }
        self.results.append(result)
        return result

3.7 Pseudocode:optional self-evolution wrapper

class EvolutionManager:
    def run(self):
        baseline_dir = self.run_dir / "iterations" / "iter_000_baseline"
        baseline_code = self.run_agent(self.config_path, baseline_dir)
        previous_digest = collect_trace_digest(baseline_dir, self.config_path)
        current_config = self.config_path
 
        for iteration in range(1, self.iterations + 1):
            candidates = EvolutionAnalyzer(current_config).analyze(previous_digest)
            overlay = EvolutionApplier(
                project_root=self.project_root,
                source_config=self.config_path,
                artifacts_dir=self.run_dir / "evolution_artifacts",
            ).apply(candidates, current_config, iteration)
 
            evolved_dir = self.run_dir / "iterations" / f"iter_{iteration:03d}_evolved"
            code = self.run_agent(overlay.config_path, evolved_dir)
            evolved_digest = collect_trace_digest(evolved_dir, overlay.config_path)
            self.write_state(compare(previous_digest.metrics, evolved_digest.metrics))
            previous_digest = evolved_digest
            current_config = overlay.config_path
        return code

3.8 Code-to-paper mapping

Code reference: main @ 069631b5 (2026-05-20) — pseudocode and mapping based on this commit

Paper ConceptSource FileKey Class/Function
Unified entry point / experiment CLIrun.pyparse_args, run_single_task, run_tasks_parallel, main
Configuration-driven harnessevomaster/config.pyEvoMasterConfig, ConfigManager.load, get_agent_config, get_agent_llm_config
Playground orchestration layerevomaster/core/playground.pyBasePlayground, AgentSlots, _setup_session, _setup_agents, _create_exp, run
Experiment lifecycle / trajectory resultevomaster/core/exp.pyBaseExp.run, extract_agent_response
Agent reactive loopevomaster/agent/agent.pyBaseAgent.run, _initialize, _step, _execute_tool, _append_trajectory_entry
Long-horizon context managementevomaster/agent/context.pyContextManager.prepare_for_query, truncate, _prune_old_tool_outputs, is_overflow
MCP tool capability layerevomaster/agent/tools/mcp/mcp_manager.pyMCPToolManager, MCP config resolution and tool registration
Skill capability layerevomaster/agent/tools/skill.pySkillTool, SkillRegistry integration
Local / Docker session abstractionevomaster/agent/session/local.py, evomaster/agent/session/docker.pyLocalSession, DockerSession
Optional self-evolution loopevomaster/evolution/manager.pyEvolutionManager.run, _run_agent, _compare_metrics
Trace digest collectionevomaster/evolution/collector.pycollect_trace_digest, _iter_trajectory_entries, _collect_logs, _collect_artifacts
Evolution analysisevomaster/evolution/analyzer.pyEvolutionAnalyzer.analyze, _analyze_with_llm, _heuristic_candidates
Run-level evolution usagedocs/evolution.mdCLI workflow: baseline → analyze → overlay → evolved run
Browse-Master benchmark adapter exampleconfigs/browse_master/config.yamlplanner max_turns=10, executor max_turns=50, MCP web/search tools
ML-Master 2.0 config exampleconfigs/ml_master_2/deepseek-v3.2-example.yamlprefetch/draft/debug/improve/reseach/knowledge_promotion/wisdom_promotion agents, max_turns=10; metric max_turns=50
X-Master config exampleconfigs/x_master/config.yamlsolver/critic/rewriter/selector, each max_turns=50 with MCP tools

4. Experimental Setup (实验设置)

Benchmarks / datasets

  • Humanity’s Last Exam (HLE):2,500 道跨学科专家题,数学约 41%、生物/医学 11%、计算机科学 10%、物理 9%、人文社科 9%、化学 7%;近 1,000 名专家、500+ institutions、50 个国家参与,约 14% 多模态,24% 多选,其余为 short-answer exact match。
  • MLE-Bench / MLE-Bench Lite:完整 MLE-Bench 有 75 个 Kaggle ML engineering competitions,覆盖 NLP、CV、signal processing 等 15 类;论文 Lite 评估中提到 EvoMaster 大约在 22 个 Kaggle competitions 中获得 17 个 medal,OpenClaw 在 18 次有效 submission 中获得 4 个 medal。
  • BrowseComp:1,266 个复杂 web retrieval tasks,需要跨几十到上百网页检索、组合与验证信息,测试深度浏览、多步搜索和跨源综合能力。
  • FrontierScience:面向 physics / chemistry / biology 的前沿科学推理;Olympiad track 有 100 道竞赛级问题,Research track 有 60 个 PhD scientist 设计的 research subtasks,按 10-point rubric 评分。论文 Table 5 报告的是 Research track。

Compared methods / agents

主对比基线是 OpenClaw,论文称其为 2025–2026 年快速增长的开源通用 AI agent 项目。不同表格还引用 MLE-STAR-Pro-1.5R&D-AgentGPT-5.4 xhighMuse Spark 作为外部结果或辅助参照。EvoMaster 侧使用标准 SciMaster agents:HLE 用 X-Master,MLE-Bench Lite 用 ML-Master 2.0,BrowseComp 用 Browse-Master,FrontierScience 用 X-Master 2.0。

Metrics

  • Accuracy / normalized score (%):HLE、BrowseComp、FrontierScience 的主要指标;FrontierScience Research 使用平均 normalized score。
  • Valid / Above Median / Bronze / Silver / Gold / Any Medal:MLE-Bench Lite 指标,衡量提交是否有效、是否超过中位数、以及 Kaggle leaderboard medal 水平。
  • Relative improvement:以 OpenClaw 为基线计算的相对增益,公式为

Runtime / configuration

论文实验报告的运行配置是:所有实验在 NVIDIA RTX 4090 GPU server 上运行;EvoMaster 与 OpenClaw 都使用 GPT-5.4 作为 backend model,并配备 identical tools and skills;MLE-Bench 评估施加 24-hour runtime limit。论文没有公开完整的 benchmark launch YAML,因此这些 benchmark 结果的 GPT-5.4 配置来自论文正文,而不是 released repo 的默认 config。

released code 中可复核的配置示例包括:configs/browse_master/config.yaml 中 planner max_turns=10、executor max_turns=50 且 executor 使用 builtin tools 与 mcp_config.jsonconfigs/ml_master_2/deepseek-v3.2-example.yaml 中 prefetch/draft/debug/improve/reseach/knowledge_promotion/wisdom_promotion 均为 max_turns=10,metric 为 max_turns=50,local session timeout 为 86400 秒并配置 2 GPU;configs/x_master/config.yaml 中 solver/critic/rewriter/selector 均为 max_turns=50 且带 MCP tools。注意这些是 released examples,不应被等同为论文 GPT-5.4 benchmark launch config。

5. Experimental Results (实验结果)

Overall benchmark comparison

Figure 1 解读:四个 benchmark 都显示 EvoMaster 明显高于 OpenClaw。HLE 从 13.6% 提升到 41.1%,MLE-Bench Lite 从 18.2% 到 75.8%,BrowseComp 从 28.3% 到 73.3%,FrontierScience 从 18.3% 到 53.3%。这些任务覆盖闭卷专家知识、长周期 ML engineering、深度网页检索和前沿科学推理,说明改进不是某一个工具或 benchmark 的偶然收益。

Table 2 主结果如下:

BenchmarkOpenClawEvoMasterRelative Improvement
HLE13.641.1+202%
MLE-Bench (Lite)18.275.8+316%
BrowseComp28.373.3+159%
FrontierScience18.353.3+191%

MLE-Bench Lite:长周期 ML engineering

Figure 2 解读:横轴是 24 小时运行时间,纵轴是 medal rate。灰线是原始曲线,蓝线是 smoothed curve;曲线从接近 0 持续上升到约 0.55 左右,显示 ML-Master 2.0 的多阶段实验流程能在长时间内持续积累收益,而不是只在前几轮得到一次性改进。论文最终表格报告的 Any Medal 是 75.76%,说明图中的时间曲线与最终评估表使用的聚合口径不同;阅读时应把图理解为“随时间演化趋势”,把 Table 3 作为正式结果。

Table 3 中 EvoMaster 在 Any Medal 上达到 75.76%,高于 OpenClaw 18.18%、MLE-STAR 68.18%、R&D-Agent 68.18%。各指标为:Valid 100.00、Above Median 84.85、Bronze 13.64、Silver 31.82、Gold 30.30、Any Medal 75.76。论文解释最大差距来自 ML-Master 2.0 的多阶段 workflow:knowledge prefetch 获取历史经验,draft 生成初始方案,随后最多 20 轮 research-driven parallel improvement 逐步改进;hierarchical cognitive caching 覆盖 prefetch、round-level knowledge promotion 和 run-level wisdom promotion。

BrowseComp:深度网页检索

BrowseComp Overall 从 OpenClaw 的 28.33% 提升到 EvoMaster 的 73.33%,绝对增益 +45.00。分类结果为:Multi-step Reasoning 18.75 → 65.63(+46.88),Map + Search 25.00 → 75.00(+50.00),Niche Knowledge 47.05 → 88.23(+41.18),Complex Filtering 28.57 → 71.43(+42.86)。论文归因于 Browse-Master 的 Planner-Executor iterative loop:planner 根据累计发现制定下一步搜索计划,executor 调用 web search、URL fetching、PDF extraction 执行,最多 10 轮迭代,避免通用 agent 停在第一个看似合理的答案上。

FrontierScience:前沿科学推理

FrontierScience Research track 中 EvoMaster Overall 为 53.33,OpenClaw 为 18.33,GPT-5.4 为 33.00,Muse Spark 为 38.30。分学科结果为:Physics 15.00 → 55.00(+40.00),Chemistry 20.00 → 55.00(+35.00),Biology 20.00 → 50.00(+30.00)。论文说明 X-Master 2.0 是带 academic retrieval tools 的 single-agent solver,可用 Google Scholar、Semantic Scholar API、PDF reader 检索文献,在推理中反复反思和修正。限制是 Table 5 明确说受时间和计算资源限制,目前只报告 single run。

HLE:跨学科专家知识

HLE Overall:OpenClaw 13.62,GPT-5.4 xhigh 36.47,Muse Spark 40.92,EvoMaster 41.10,EvoMaster 对 OpenClaw 的绝对增益 +27.48。细分领域中 EvoMaster 在 Biology/Medicine 29.28、Chemistry 29.70、Computer Science/AI 37.05、Engineering 21.88、Math 48.16、Physics 31.68、Humanities/Social Science 44.04、Other Categories 43.18。论文特别指出 Math 的增益为 +33.10,Computer Science +24.55,Humanities +30.05,说明 Solve-Critique-Rewrite-Select pipeline 对初始答案弱、需要多步纠错的 hard instances 更有效。

Ablation / Limitations / conclusion

论文没有提供传统意义上的 component ablation table;主要证据来自跨 benchmark 的 pipeline-level comparison 与按任务类别的分解结果。可以把最接近 ablation 的解释看作:MLE-Bench 的多阶段 improvement 和 cognitive caching 支撑长周期 medal rate;BrowseComp 的 Planner-Executor loop 支撑 multi-step retrieval;HLE 的 Solve-Critique-Rewrite-Select 支撑 hard reasoning;FrontierScience 的 academic retrieval tools 支撑研究型问题。

作者明确承认的限制是 physical environments integration:当前 EvoMaster 主要面向 in silico / computational research workflows,不原生支持直接操控自动化实验设备、cloud labs 或 robotic synthesis hardware。未来需要扩展 Session abstraction,使其能安全地连接标准实验室自动化协议。另一个实验层面的 caveat 是 FrontierScience 由于资源限制只报告 single run,因此这一组结果的方差还需要后续复验。

总体结论是:EvoMaster 的收益来自“foundation + evolution”的组合,而不是单个模型后端。相同 GPT-5.4、相同工具/skills 条件下,EvoMaster 在四类能力维度上都优于 OpenClaw,说明面向科学研究设计的 harness、长上下文管理、轨迹记录、多 agent 协作和领域 workflow adapter 可以把通用模型能力转化为更稳定的 scientific agent performance。