The Complete EvoX Runtime Workflow

The EvoX Runtime is not a one-off inference call, but a closed-loop execution system built for evolutionary exploration . It organizes model capabilities, tool capabilities, and environmental feedback into a continuously operating pipeline: the model proposes candidates, the Runtime turns those candidates into real computation, the environment returns observable results, the evolutionary mechanism makes selections based on them, and the persistence system distills the validated outcomes into the starting point for the next round of exploration.

The Six Links of the Closed Loop

Model proposes candidates: based on the current problem definition, historical state, and constraints, it generates candidates at the parameter, operator, strategy, and even program level, determining which entry points the search space opens from.
Tools execute and trigger environmental changes: the Runtime invokes evaluators, simulation/surrogate models, operator libraries, and workflows, converting candidates into actual computation and observable environmental changes.
Environment returns feedback: the task environment provides metrics, constraint violations, failure modes, and execution traces; these signals are used both for scoring and for guiding the next round of proposals.
Evolutionary mechanism completes selection: through population updates, mutation/crossover, Pareto or preference-based selection, it retains high-value candidates while refining or eliminating low-value ones.
Runtime organizes computation: responsible for module orchestration, state management, scheduling, heterogeneous compute allocation, and reproducible execution, decoupling algorithms from problems and enabling on-demand composition.
Persistent system inherits outcomes: saves project-level state across Agent contexts, with strict validation determining which results are persisted as a trusted baseline.

Two Easily Underestimated Mechanisms

Project-level persistence across Agent contexts: the context of a single session disappears when the conversation ends, but evolution requires accumulation across sessions. EvoX writes candidates, evaluation records, and conclusions to project-level storage, so a new Agent session can directly load the history without repeating work already done.

Strict validation and historical inheritance: not all results deserve to enter the baseline. The acceptance gate checks metrics, constraints, and reproducibility, and only the versions that pass are written into history and inherited by subsequent rounds. This makes inheritance a trusted accelerator rather than an amplifier of errors.

The Significance of the Closed Loop

With this closed loop in place, the next round of exploration does not have to start from scratch, but continues evolving on the basis of vetted outcomes. The model is responsible for proposing possibilities, while the system is responsible for validation, selection, and accumulation — this is precisely the continuously operating foundation of AI Native research.

Key Reminder

Distinguish "one generation" from "one evolution round": the former only produces candidates, while the latter also includes execution, feedback, selection, validation, and inheritance. Without any one of these links, the system cannot keep improving.

EvoX Runtime Closed-Loop Workflow Architecture Diagram

Study the EvoX Runtime closed-loop workflow architecture diagram and describe the key points you observe.

Question 1

In the EvoX Runtime closed-loop workflow, which of the following sequences of links is correct?

Candidate proposal → Runtime orchestration and tool execution → environment feedback → evolutionary selection → validation and persistence → historical inheritance, then back to the model/Agent

Historical inheritance → Runtime execution → candidate proposal → environment feedback → evolutionary selection

Environment feedback → candidate proposal → evolutionary selection → validation and persistence → Runtime execution

Candidate proposal → evolutionary selection → environment feedback → Runtime execution → historical inheritance

Question 2

What is the core responsibility of the Runtime within the closed loop?

Responsible for module orchestration, state management, scheduling, heterogeneous compute allocation, and reproducible execution, decoupling algorithms from problems for on-demand composition

Directly replacing the evaluator, providing final metrics, and deciding which candidate to adopt

Only responsible for logging, without participating in any actual computation

Responsible for proposing candidates, while the model is only responsible for execution

Question 3

If a candidate produces a constraint violation during environmental evaluation, what is the approach most consistent with the closed-loop design?

Write it directly into the project history and permanently retain it as a negative sample

Ignore the violation and only keep the result with the best primary metric

Immediately terminate the entire task and stop generating new candidates

Treat the violation as a feedback signal and pass it to the evolution and validation stages; the candidate may be eliminated or may be fixed and enter the next round

Question 4

Regarding "project-level persistence across Agent contexts," which of the following statements is correct?

It saves candidates, evaluation records, and conclusions as project-level state, so a new Agent session can directly load the historical baseline

It is equivalent to writing the model weights to disk

It is maintained by the model itself within the conversation and is unrelated to the Runtime

It only saves the context text of the current conversation and becomes invalid as soon as the session ends

Question 5

Why is "strict validation" a prerequisite for historical inheritance?

Because validation can completely replace environmental feedback

Because validation will regenerate a new batch of candidates

Because validation can speed up the Runtime's scheduling

Because only results that pass metric, constraint, and reproducibility checks are suitable to serve as a trusted baseline for inheritance by subsequent rounds

Case Study: Candidate Screening and Inheritance in a Round of an EvoX Task

Read the scenario below, then answer the questions.

A team uses the EvoX Runtime to optimize the control strategy of a simulation system. In one session, the Agent generates 40 candidate configurations; the Runtime batch-schedules simulation evaluators and surrogate models, returning multi-objective metrics (performance and energy consumption) for each candidate as well as several constraint violation records; the evolutionary mechanism retains 8 candidates along the Pareto front; the acceptance gate completes a reproducibility check on 1 of these candidates and writes it into the project history. The next session loads that history and continues mutation and optimization on the basis of this validated candidate.

1. Using the closed-loop workflow, identify what signals "environmental feedback" specifically includes in this scenario, and which links of the closed loop each of them affects.

Answer:
The feedback signals fall into three categories: ① Multi-objective metrics (performance, energy consumption) — these affect the retention and ranking in evolutionary selection, as well as the pass/fail judgment during validation; ② Constraint violation records — these determine whether a candidate is eliminated or fixed and carried into the next round, and also determine whether it can pass validation; ③ Evaluation traces and reproducibility information recorded by the Runtime — these support the acceptance gate's pass decision and provide clues for the next round of proposals. It is clear that environmental feedback serves both the current round's selection and the accumulation of capability across rounds.

2. If the team removes the acceptance gate and writes all 8 Pareto candidates into the project history, what risks would this introduce? Please explain from the perspectives of "historical inheritance" and "continuous evolution."

Answer:
① From the perspective of historical inheritance: unvalidated results may be non-reproducible, or may still carry unaddressed constraint violations. Once treated as a trusted baseline, subsequent sessions inherit questionable conclusions, and errors accumulate and amplify over time. ② From the perspective of continuous evolution: once the baseline is contaminated, mutation and optimization revolve around an erroneous starting point, raising search costs while reducing returns; meanwhile, the history becomes diluted by a large number of low-credibility entries, making it difficult for the team to determine which set is truly a usable validated conclusion. Conclusion: without strict validation, inheritance turns from an "accelerator" into an "amplifier of errors," which is why the acceptance gate is an indispensable link in the closed loop.