A Comprehensive Survey on LLM-Guided Evolutionary Search

1. Introduction

Large language models (LLMs) and vision-language models (VLMs) have shown strong capability across many application settings, including strategic games [1], scientific literature analysis [2,3], robotics and embodied control [4,5,6,7], and autonomous driving [8]. Many recent works also improve LLM capability through a wide range of training-time and inference-time methods [9,10,11]. However, open-ended problems remain difficult. When the desired answer is not already contained in training data, or when the solution space is too large for a single response to directly locate a high-quality result, one-shot generation becomes unreliable. This challenge is especially visible in scientific discovery, heuristic design, and new algorithm development, where progress often requires repeated search rather than isolated prediction.

Combining LLMs with evolutionary search has recently emerged as a promising paradigm for such open-ended optimization and discovery problems. FunSearch first showed that LLM-generated program variations, filtered by executable evaluation, can support mathematical discovery over code [12]. AlphaEvolve substantially generalized this closed loop to broader code artifacts, richer feedback, and wider scientific and algorithmic discovery settings [13]. Figure 1 shows representative overviews of these two foundational systems. Building on this foundation, later systems have already produced striking results across multiple domains: AlphaEvolve discovers the first improvement to $4\times 4$ matrix multiplication after 56 years and also improves classical open constructions such as Erdos’s minimum overlap problem and the 11-dimensional kissing number [13]; ThetaEvolve obtains new best-known bounds on open problems highlighted by AlphaEvolve, including circle packing and the first autocorrelation inequality [14]; and SR-SCIENTIST improves scientific equation-discovery baselines by absolute margins of 6%–35% across multiple scientific domains [15]. These results suggest that LLM-guided evolutionary search (LLM-ES) is no longer a collection of isolated demonstrations, but an emerging framework for long-horizon optimization over structured artifacts.

Subsequent systems expanded this line in multiple directions, including more structured research loops, sample-efficient program evolution, and adaptive search control [14,16,17]. The same paradigm has also begun to appear in applications such as architecture discovery, systems optimization, scientific equation discovery, and broader scientific modeling [15,18,19]. As a result, both the methodological design space and the range of target domains have grown rapidly. Figure 2 outlines the development timeline of LLM-ES from 2023 to 2026.

LLM-ES builds upon the iterative paradigm of traditional evolutionary computation (EC), while fundamentally extending how candidate solutions are generated and evolved. Traditional EC already provides the basic search backbone of initialization, evaluation, selection, variation, and replacement [20,21,22]. LLM-ES inherits this iterative structure, but changes the variation mechanism itself. Instead of relying only on hand-designed numerical or symbolic operators, it uses LLMs to generate, rewrite, patch, critique, or fuse structured artifacts such as code, heuristics, prompts, and workflows. This makes the search process far more semantically expressive, while also introducing new system-design questions about prompt construction, model usage, evaluation interfaces, search control, and maintained search state. Figure 3 compares the classical and LLM-guided evolutionary workflows.

Before the emergence of LLM-ES, stronger LLM performance was often pursued through more capable generation procedures. One line of work improves a single response by eliciting better reasoning or searching over thought states, as in chain-of-thought prompting [23], self-consistency [24], and related reasoning-time search methods such as Tree of Thoughts [25]. Another line uses more complex multi-step workflows, such as tool-using agents in ReAct [26], self-reflection loops in Reflexion [27] and Self-Refine [28], or multi-agent interaction [29], to iteratively refine outputs within one task episode. These methods can be highly effective, but they usually seek the answer to a question through single or multiple reasoning paths within one episode. LLM-ES extends beyond this setting by introducing an external search loop in which candidate artifacts are repeatedly generated, evaluated, preserved, selected, and reused under longer-horizon search pressure.

Despite this fast progress, the field still lacks a dedicated survey. Existing papers usually emphasize domain breakthroughs or task-specific engineering choices. Related broader discussions mostly address adjacent areas instead, such as medical and healthcare LLMs [30,31] and VLMs for robotics [7]. There are also broader surveys on the interplay between LLMs and evolutionary computation or evolutionary optimization [32,33,34]. However, these works do not systematically organize the design space of LLM-guided evolutionary search itself. To the best of our knowledge, this article is the first survey devoted specifically to LLM-ES. Our goal is therefore to organize current work around the key design dimensions that determine how an LLM-guided evolutionary system actually operates, while also summarizing its representative applications and resources.

The remainder of this paper is organized as follows. We begin from problem formulation, then move through the core layers of the evolutionary process, and finally review applications, open-source frameworks, and benchmarks. Within that middle part, population design provides the maintained search state, parent selection and candidate generation define how new candidates are produced from it, prompt construction integrates these search signals for model invocation, and evaluation closes the loop, while exploration-exploitation control acts across the search process as a cross-cutting design dimension. We conclude with open challenges and future directions.The organizational structure of this survey is visualized in Figure 4.

2. Problem Formulation of LLM-Guided Evolutionary Search

Like classical evolutionary computation (EC), LLM-guided evolutionary search solves an optimization problem by iteratively searching over a feasible space of candidate solutions. At a high level, the two paradigms share the same evolutionary logic: maintain candidate solutions, evaluate them under an objective, and use the evaluation results to guide the generation and retention of better candidates over time. However, LLM-guided systems differ substantially from classical EC in both the search space and the concrete search process. Instead of operating mainly on low-level numerical or symbolic encodings, LLM-ES searches over more expressive solution forms such as code, prompts, and workflows; instead of relying only on hand-designed mutation and crossover operators, they incorporate prompting, LLM generation, execution feedback, and memory or archive mechanisms into the optimization loop.

2.1. Optimization Search Problem Definition

The search problem can be formalized as an optimization problem over a feasible set:

$$x^{*}\in \arg \underset{x\in \mathcal{X}}{\max }F\left(x\right).$$

(1)

Here, $\mathcal{X}$ denotes the search space, namely the set of candidate solutions that satisfy the constraints of the task, and F denotes the objective function. In LLM-guided evolutionary search, the role of the evolutionary system is to propose new feasible candidates $x\in \mathcal{X}$ and use evaluator feedback to search for better solutions under F.

In both LLM-ES and traditional EC, the search problem can be divided into three categories according to the form of the objective function. The simplest case is single-objective optimization, where

$$F:\mathcal{X}\to \mathbb{R},$$

(2)

so each candidate is assigned one scalar score and the search aims to maximize this value. This remains the default in many code and systems optimization settings such as Magellan, KernelEvolve, and SAT heuristic discovery [35,36,37]. A second regime is multi-objective optimization, where

$$F:\mathcal{X}\to {\mathbb{R}}^m,$$

(3)

and improvement is defined through a vector of competing criteria rather than one scalar score. In this case, selection is usually based on Pareto dominance rather than a total ordering [38,39,40]. A third regime is quality-diversity optimization. Here, the evaluator further exposes a behavior descriptor,

$$b:\mathcal{X}\to \mathcal{B},$$

(4)

and the goal is not only to optimize $f\left(x\right)$ but also to populate different regions of behavior space $\mathcal{B}$ with high-quality elites [41,42,43]. In other words, single-objective search seeks one best solution, multi-objective search seeks a trade-off set, and QD search seeks a repertoire of behaviorally distinct high-performing solutions.

From the perspective of optimization objectives, the categorization of classical evolutionary search and LLM-guided evolutionary search is broadly similar. In contrast, the two paradigms differ much more substantially in the form of the evolving object. A systematic comparison of their evolving objects is presented in Table 1. In classical evolutionary optimization, the evolving object often takes the form of real-valued vectors, discrete sets, or symbolic structures. In the LLM-guided literature, the dominant case is an evolving object over code, where candidate solutions are executable programs, heuristics, or algorithmic components [13,18,37]. A broader class uses evolving objects over code templates with tunable parameters, where the template is evolved while the parameters are optimized separately by an additional procedure or optimizer [35,40,44]. Closely related are systems that evolve executable generators, namely higher-level executable artifacts which, like templates, are not themselves the final task solution but instead act as solution-producing generators [45,46,47]. Another class uses structured solution abstractions as the evolving object, where candidate solutions are represented through high-level structured descriptions whose components must be further realized into complete solutions [48,49,50,51]. Other works use prompts, policies, or workflow structures as evolving objects, thereby moving beyond task solutions towards optimization process design [52,53,54].

2.2. Classical Evolutionary Search Workflow

For ease of comparison with LLM-guided evolutionary search, this subsection briefly reviews the main workflow of classical evolutionary computation (EC). More comprehensive overviews of EC can be found in [63].

Formally, the population at generation t can be written as a finite set of candidate solutions

$$P_t=\left\{x_t^{\left(1\right)},x_t^{\left(2\right)},\dots ,x_t^{\left(N\right)}\right\}\subseteq \mathcal{X},$$

(5)

where N denotes the fixed population size. The evolutionary transition from $P_t$ to $P_{t+1}$ is characterized by a composite operator $\mathcal{T}$, which decomposes into three modular sub-operators:

$$P_{t+1}=\mathcal{T}\left(P_t\right)=\mathcal{R}\left(P_t,\mathcal{V}\left(\mathcal{S}\left(P_t\right)\right)\right),$$

(6)

and the three operators are formally defined below.

Selection Operator $\mathcal{S}$: This operator takes the current population $P_t$ as input and selects parent configurations $A_t$:

$$\mathcal{S}\left(P_t\right)=A_t.$$

(7)

For example, under fitness-proportionate selection, the sampling probability of any individual $x\in P_t$ is proportional to its objective value $F\left(x\right)$, which biases the search toward promising regions and forms the basis of exploitation in traditional EC.

Variation Operator $\mathcal{V}$: This operator takes the selected parents $A_t$ as input, applies variation mechanisms to the selected parents, and produces an offspring set:

$$\mathcal{V}\left(A_t\right)=O_t.$$

(8)

Two common instances are mutation and crossover. Mutation introduces random perturbations to a parent, which is widely adopted in evolution strategies [57]:

$$x^{\prime }\sim \mathcal{M}\left(x\right),x^{\prime }=x+ϵ,ϵ\sim \mathcal{N}(0,{\sigma }^{2}I),$$

(9)

Crossover recombines genetic information from two parents to produce novel offspring and is a core operation in GA and DE [56,58]:

$$x^{\prime }\sim \mathcal{C}(x^{\left(i\right)},x^{\left(j\right)}),$$

(10)

Compared with mutation, crossover can more effectively combine high-quality traits from different individuals.

Replacement Operator $\mathcal{R}$: This operator takes the tuple $(P_t,O_t)$ as input and produces the next population through a replacement rule:

$$\mathcal{R}(P_t,O_t)=P_{t+1}.$$

(11)

The replacement mechanism determines how information from the current population and the offspring population is combined, and plays a central role in convergence control and elitism preservation [20].

From a distributional perspective, the classical evolutionary search workflow can be viewed as a density evolution process over $\mathcal{X}$. Let $p_t\left(x\right)$ denote the probability density of the population at generation t. Selection reweights the density by fitness, and variation acts as a diffusion kernel, forming a unified distributional optimization framework that is orthogonal to the semantic generation paradigm of LLMs.

2.3. LLM-Guided Evolutionary Search Workflow

In contrast to the hand-coded operator pipeline of traditional EC, LLM-guided evolutionary search redefines the variation mechanism via conditional semantic generation of large language models[12,13]. It leverages the contextual reasoning and code synthesis capabilities of LLMs to implement semantic-level evolution, which extends the search space to structured artifacts such as programs, prompts and algorithms.

The LLM-guided evolutionary loop can be formalized as a population-conditioned generative process. It replaces the traditional variation operator $\mathcal{V}$ with an LLM-driven variation operator ${\mathcal{V}}^{\Phi }$, where the prompt builder $\Phi$ conditions generation on population information[13]. The complete one-step evolutionary transition is defined as:

$$P_{t+1}=\mathcal{R}\left(P_t,{\mathcal{V}}^{\Phi }\left(\mathcal{S}\left(P_t\right)\right)\right),$$

(12)

where $\mathcal{S}$ and $\mathcal{R}$ play the same roles as in the classical workflow.

LLM-Driven Variation Operator ${\mathcal{V}}^{\Phi }$: This operator maps the selected parent set to a generated offspring set through prompt-conditioned LLM generation:

$${\mathcal{V}}^{\Phi }(P_t,A_t)=O_t.$$

(13)

The prompt builder $\Phi$ first maps the selected parent set to a prompt set,

$$Z_t=\Phi \left(A_t\right),$$

(14)

which compiles parent solutions and other relevant information into representations that bridge the evolutionary population state and the semantic generation space of LLMs[32]. The LLM then maps this prompt set to generated candidates in the structured search space $\mathcal{X}$ through semantic sampling,

$$O_t=\mathrm{LLM}\left(Z_t\right).$$

(15)

From a comparative perspective, the essential difference between the LLM-ES workflow and the classical evolutionary workflow lies in the variation mechanism: traditional EC relies on fixed syntactic perturbations, while LLM-guided search adopts adaptive semantic generation. This paradigm shift enables the framework to handle high-dimensional discrete structured search spaces such as program code, and naturally supports multi-objective optimization, quality-diversity search and cross-domain generalization [32].

3. Population

In LLM-guided evolutionary search, the population marks the current search frontier and provides promising parents for generating new candidates. In later search steps, the main editable solution and any auxiliary reference solutions are typically sampled from the maintained population through some selection mechanism. In this sense, population is a basic component of the LLM-ES workflow. Existing studies have explored this design space from several main aspects, including population structures, elite archives, and replacement mechanisms.

3.1. Population Structures

As evolution proceeds, increasingly many individuals are produced and evaluated. Newly generated individuals represent the current frontier of the search, while earlier historical individuals may preserve search branches that have not yet been fully explored but still contain potential value. For this reason, different algorithms maintain the population with different data structures. Figure 5 shows the main population structures existing in literatures.

3.1.1. Single-Individual Populations

The simplest population structure is a single-individual regime. Here each iteration may still generate multiple temporary candidates for comparison, but the system repeatedly refines only one current candidate across iterations. [37] and [64] are representative examples: the search state remains centered on one incumbent artifact, with only better validated variants carried forward. This design is close to hill-climbing or $(1+\lambda )$ search, and it is attractive when evaluation is expensive or when the main goal is iterative refinement of one artifact.

The main advantage of this population structure is its simplicity: storage, selection, and replacement are all straightforward, and search effort remains tightly focused on the current best direction. Its main limitation is the lack of persistent diversity, which makes the search more vulnerable to local optima and prevents potentially valuable historical branches from being retained for later reuse.

3.1.2. Flat Multi-Individual Populations

When only one individual is maintained, potentially useful historical branches are easily discarded. Storing multiple individuals makes it possible to preserve alternative search directions and reuse them later as parents or references for further generation. Therefore, a second regime stores multiple individuals in a flat form. The storage itself is unstructured, but it can be ordered according to the scores of the individuals. This population structure is very common in the current literature, with representative examples including AlphaResearch [16], ThetaEvolve [14], and X-evolve [65].

Some algorithms allow the individuals generated at each iteration to be continuously stored in the population. AlphaResearch [16], for example, is closer to an append-only candidate pool coupled with a best-so-far tracker. Others maintain a fixed population size, such as ThetaEvolve [14] and [66], which impose clearer survivor pressure through bounded ranked archives.

3.1.3. Island-Structured Populations

When a flat population is evolved as a whole, search may gradually concentrate on a narrow region and reduce the diversity of the maintained candidates. To mitigate this issue, many studies introduce island-structured populations as an explicit mechanism for diversity maintenance. The basic idea is to partition the population into multiple islands, let each island evolve mostly independently, and periodically allow information exchange across islands through migration or related coordination mechanisms.

ShinkaEvolve [67], TIDE [60], and [68] all distribute candidates across local subpopulations and then coordinate search through migration or reseeding. Compared with flat archives, this design makes diversity preservation a property of the population layout itself rather than an accidental byproduct of stochastic sampling.

Migration is introduced to let useful discoveries spread across islands without fully merging their local search trajectories. It therefore provides a mechanism for balancing local specialization and global information sharing. Existing studies mainly differ in two aspects. First, the migration schedule may be fixed or adaptive. AdaEvolve [69], MadEvolve [40], and AgentLTV [38] all adopt fixed migration intervals, while TIDE [60] triggers migration adaptively according to stagnation and structural similarity between islands. Second, the migrated object also varies across systems. Some methods transfer executable candidates directly, such as the top programs in AdaEvolve [69], high-fitness programs in AgentLTV [38], a fraction of the best members in MadEvolve [40], and non-best candidates in ShinkaEvolve [67]. TIDE [60] instead distinguishes between direct elite-code transfer and higher-level insight transfer. In topology, ring-based transfer is common, as in AdaEvolve [69] and MadEvolve [40].

3.1.4. Genealogically-Structured Populations

Genealogical structure is better viewed as an additional organizational layer rather than a standalone alternative to the population structures above. It does not conflict with flat or island-structured populations, and can be maintained together with them. In general, however, maintaining an explicit genealogical structure is most natural when the algorithm preserves relatively complete historical solutions instead of retaining only the current active population.

Some systems record only the parent-child relation between each child and its main editable candidate. In this case, the genealogical structure forms a tree [70] or, when multiple roots are maintained, a forest [71]. Other systems additionally record the relation between a child and its reference candidates. In that case, the resulting structure is no longer limited to a tree and becomes closer to a graph [72].

Genealogical structure is often combined with flat multi-individual populations [72,73,74], where the maintained genealogy helps organize branching search trajectories and guide which candidate should be expanded next. It can also be combined with island-structured population designs. In AgentLTV [38], the tree and the islands belong to different stages: a single MCTS tree is searched first, and its best program is then passed to multiple islands for later refinement. In CODEEVOLVE [75], each island maintains its own tree-structured solution lineages internally.

3.2. Elite Archives

Elites are candidate solutions with particularly strong, and often the best, observed performance under the current evaluation criterion. Their maintenance involves both updating the elite set when better candidates appear and preserving selected elites across subsequent search steps. In many LLM-ES systems, this functionality is handled by an elite archive, which forms a logical structure distinct from the main population even when the two may partially overlap in implementation. Maintaining such an archive is useful because it preserves historically important search information, especially the strongest solutions discovered so far and the search paths associated with them. A further point worth noting is that, under island-structured populations, elite archives can also implicitly support communication across islands. According to how many elites are stored and how the archive is maintained, existing designs can be categorized into single-elite archives, multi-elite archives, and quality-diversity archives. Table 2 summarizes these archive styles.

3.2.1. Single-Elite Archives

Single-elite maintenance is commonly used in hill-climbing systems or best-so-far tracking mechanisms embedded within larger search pipelines. The SAT heuristic-discovery framework is the clearest example, since only a strictly better executable offspring replaces the incumbent [37]. In such systems, the archive degenerates to one current best solution, and all evolutionary pressure is concentrated on improving or defending that incumbent.

Even when the broader system stores more information, a single-elite view may still be embedded inside a larger archive. AlphaResearch, for example, keeps a broader trajectory and candidate pool, but it also maintains an explicit best-so-far program that acts as the clearest elite summary of search progress [16].

3.2.2. Multi-Elite Archives

Multi-elite archives store several strong candidates rather than one winner. In this regime, the archive acts as a repository of high-quality solutions, so later search steps can draw on more than one promising direction at a time. Many systems in this category maintain a fixed-size top-k-style archive, including VRPAgent [76], FM Agent [77], and [66]. ShinkaEvolve and AdaEvolve instead maintain per-island archives of strong programs rather than one shared archive [67,69]. This design supports both exploitation of strong candidates and reuse of alternative ideas without collapsing search to a single incumbent.

The concrete role of the archive can still vary across systems. In VRPAgent, the elite set is used directly for biased crossover and elite mutation [76]. In FM Agent, the elite pool guides later sampling and coordination [77]. In ThetaEvolve [14] and [66], the elite subset serves as the main source of reusable high-quality candidates for later iterations.

3.2.3. Quality-Diversity Archives

Conventional elite archives emphasize global quality, but may easily discard structurally different candidates that are not currently top-ranked. Quality-diversity elites instead maintain one elite per niche or cell defined by a descriptor function beyond the objective value itself. AlphaEvolve [13], CodeEvolve [75], SEA-TS [70], and [78] illustrate this pattern. Their importance lies in preserving heterogeneous solution modes, especially when a single global ranking would collapse the population into one narrow region of the search space.

Compared with multi-island populations, quality-diversity archives maintain diversity through explicitly defined semantic niches or descriptors, instead of just different search branches.

3.3. Replacement Mechanisms

As iteration proceeds, more new candidates are produced and need to interact with the maintained population and archive. Accordingly, a suitable replacement mechanism is needed to update the population and archive over time. Common patterns include incremental insertion, elitist replacement, and generational replacement,whose core workflows are compared in Figure 6.

3.3.1. Incremental Insertion

Incremental insertion continuously adds newly generated candidates into a population or an archive, causing the reusable search history to grow over time. In this setting, selection pressure is shifted away from strict survivor filtering and toward later-stage parent selection or retrieval, which must identify promising prior candidates from an increasingly large population pool. AlphaResearch, Strategic Search, and X-evolve follow the direct append-only candidate-pool form [16,65,79]. SIDiffAgent is a slightly different variant: it incrementally stores compressed trajectory records rather than raw candidates, and these records still function as reusable search memory for later generation [80]. This mechanism preserves historical coverage and facilitates retrospective analysis.

3.3.2. Elitist Replacement

Elite replacement primarily governs updates to elite archives. It determines whether a newly evaluated candidate should replace or enter an existing elite entry according to the archive criterion, thereby maintaining a compact set of high-quality historical solutions for later reuse. This category includes top-k retention and MAP-Elites-style cell-wise replacement.

The choice of mechanism depends on the problem setting and the maintained population structure. ThetaEvolve [14], ShinkaEvolve [67], and AdaEvolve [69] all maintain bounded sets of strong candidates, in which replacement is performed in an individual-by-individual manner through top-k style retention. TIDE [60] applies a related idea at the batch level. By contrast, CodeEvolve [75] and SEA-TS [70] represent quality-diversity archives in a MAP-Elites style: a candidate is mapped into a descriptor cell and replaces the incumbent only when it is better within that cell.

3.3.3. Generational Replacement

Generational replacement updates the maintained population generation by generation using newly produced batches of candidates, rather than continuously accumulating candidates over time. In this regime, the current population serves as the parent pool for generating the next batch, after which it is replaced entirely by the newly formed generation while the previous population is discarded.

[81] is a typical example of pure population refresh: each iteration constructs a new candidate set from the current one, and only the refreshed set is carried forward to the next iteration. In contrast, [82] uses a more selective variant: it still refreshes the parent pool generation by generation, but only a filtered subset of the newly produced candidates is retained as the next generation.

4. Parent Selection

Populations and archives preserve the evolving search history of an LLM-ES system. However, only a small subset of these accumulated candidates can be reused when generating new offspring. In evolutionary computation, different parent-selection strategies induce different search biases and therefore directly influence the balance between broad exploration and focused refinement [63]. The same issue remains central in LLM-guided evolutionary systems, but the reused objects are often substantially more heterogeneous than in conventional EC. A framework may select candidates for direct inheritance, retrieve historical solutions as contextual references, or dynamically switch among multiple selection strategies depending on the current search stage and optimization objective.

Consequently, parent selection in LLM-ES is not only about choosing high-performing candidates, but also about deciding what forms of historical search information should be reused, how they should be retrieved, and how different selection mechanisms shape the overall search dynamics.

4.1. Selection Mechanisms

Existing methods can first be grouped by the kind of signal used in selection itself. Table 3 provides a compact overview. Some of these mechanisms are primarily used for choosing the main parent, some are more common for choosing auxiliary references, and some appear in both roles.

4.1.1. Uniform Selection

The simplest case is uniform selection, where a parent is chosen without explicit preference for stronger candidates, or with only a minimal structural restriction on the candidate pool. This includes purely random sampling as well as designs where the eligible pool is fixed in advance and the parent is drawn uniformly from the currently maintained candidate set.

Several systems contain this pattern, at least in one part of their search process. One form samples a single parent uniformly, as in AdaEvolve during exploration [69,83], and the uniform branch of [91]. Another form samples multiple parents uniformly and uses them jointly, as in [92] and [84]. Such strategies emphasize broad exploration because they avoid early concentration on a small set of already strong solutions, but they also make relatively weak use of accumulated quality information.

4.1.2. Score-Based Selection

Score-based selection directly uses raw objective values to choose the next parent. Typical forms include proportional sampling, softmax sampling, roulette-wheel selection, and other mechanisms that depend on the numerical magnitude of the evaluation signal itself. Compared with uniform selection, score-based selection emphasizes exploitation because it biases reuse toward candidates that already achieve high measured performance.

Several systems contain this pattern. Under proportional sampling, the probability of selecting a candidate $x\in P_t$ can be written as

$$\mathbb{P}(x\mid P_t)={\displaystyle \frac{F\left(x\right)}{{\sum }_{x^{\prime }\in P_t}F\left(x^{\prime }\right)}},$$

(16)

which is the basic form used by systems such as GRACE, ImprovEvolve, and GigaEvo [42,85,86]. A second common form is softmax sampling,

$$\mathbb{P}(x\mid P_t)={\displaystyle \frac{\exp \left(F\right(x)/\tau )}{{\sum }_{x^{\prime }\in P_t}\exp (F\left(x^{\prime }\right)/\tau )}},$$

(17)

where $\tau$ is a temperature parameter, as in LoongFlow and related temperature-controlled variants [39,87]. [93] uses stochastic universal sampling over fitness-weighted candidates. MCCE [94], REvolution [39], and Lark [95] also include fitness-based or roulette-wheel-style parent sampling.

4.1.3. Rank-Based Selection

Rank-based selection uses only the relative ordering among candidates rather than the raw magnitude of their scores. Compared with score-based selection, its main advantage is that it does not depend on the specific scale of the returned scores, and is therefore less sensitive to score calibration, rescaling, or task-dependent variation in score magnitude. Typical forms include top-k choice, percentile filtering, champion-challenger selection, bucketed ranking, and top/bottom curation.

Many LLM-ES systems use rank-based reuse. A common pattern is to first define a rank-based candidate subset $S\left(P_t\right)$, and then sample uniformly within that subset:

$$\mathbb{P}(x\mid P_t)=\left\{\begin{array}{cc}{\displaystyle \frac{1}{\left|S\right(P_t\left)\right|}},\hfill & x\in S\left(P_t\right),\hfill \\ 0,\hfill & \mathrm{otherwise},\hfill \end{array}\right.$$

(18)

where $S\left(P_t\right)$ may denote the top-k subset, a percentile-filtered subset, or another rank-defined elite set. A common pattern is that $S\left(P_t\right)$ is defined inside a maintained archive: ThetaEvolve [14] samples from a reranked program archive, SR-SCIENTIST [15] from the top-k equations in an experience archive, and PolicySmith and RankEvolve [88,96] from top-performing solution archives. Other rank-based systems are less naturally summarized by this formula. For example, [97] uses a champion-challenger style repository, OPTAGENT directly passes the top-N queries to the next generation as parents [98], and [99] explicitly reuses top- and bottom-ranked historical functions as contrastive references. Rank-based choice is especially natural when raw scores are noisy, task-dependent, or not easily comparable across search stages, because it preserves ordering information without overcommitting to score magnitude.

4.1.4. Search-Statistic-Based Selection

Search-statistic-based selection uses search-controller statistics rather than ordinary score or rank. Its main advantage is that it can incorporate signals beyond current solution quality. These signals may include uncertainty, visit history, estimated future potential, or learned utility scores derived from the search history itself. As a result, this mechanism is better suited to settings where the parent should be chosen as the next expansion point of an ongoing search process, rather than simply as the currently strongest candidate. Typical examples include UCT, PUCT, UCB-style utilities, frontier priorities, progress-aware scores, Thompson-sampling-style utilities, learned utility scores, and related tree or bandit statistics.

This pattern is particularly visible in tree- or frontier-based frameworks. For example, [100] and SEA-TS [70] both select parent nodes under a UCT-style tree policy, while AgentLTV [38] uses PUCT in its first stage. [91] extends this pattern in a different direction by learning a contrastive concept-level likelihood-ratio score from high- and low-performing programs and using this learned utility to reweight parent sampling. Related search-statistic-based choice also appears in TIDE [60], FELA [101], and [74], where parent selection is embedded into a broader decision process over branches, operators, or frontier actions. These designs illustrate that parent selection can itself be part of a learned or adaptive search controller rather than merely a survivor-reuse heuristic.

4.1.5. Structure-Based Selection

Structure-based selection chooses candidates according to how the population is organized, such as tree position, island membership, cell neighborhood, lineage position, or other structure-defined relations. Its main advantage is that it can preserve locality in the search organization itself, rather than relying only on score, rank, or generic search statistics.

This pattern appears more often in auxiliary-reference construction. Examples include SEA-TS [70], QuantEvolve [102], and CVEvolve [103], where references are drawn from nodes, lineages, or neighborhoods defined by the maintained population structure. The common idea is that structural proximity within the maintained search organization is itself treated as reusable search information.

4.1.6. Evaluator-Metadata-Based Selection

Evaluator-metadata-based selection chooses candidates according to metadata returned by the evaluator, such as failure types, counterexamples, diagnostic labels, verifier outputs, or other attached records. Its advantage is that it makes reuse directly responsive to what recent evaluation has revealed, so later generation can be conditioned not only on prior successes but also on informative mistakes.

This mechanism also appears primarily in reference selection. Representative cases include [66,104] and [64], where evaluator-derived failures, diagnostics, or counterexamples are selectively resurfaced for later search steps.

4.1.7. Semantic-Similarity-Based Selection

Semantic-similarity-based selection chooses candidates by semantic relevance, similarity matching, or related memory lookup. Its main advantage is that it can resurface historically useful context in a query-dependent way, instead of relying only on global score, rank, or fixed structural relations.

This mechanism is currently more visible in auxiliary-reference reuse. In such cases, the query is usually formed from the current search state itself, such as the current task instance, the selected parent candidate, the current partial solution, or the latest trajectory context. Representative examples include ContextEvolve [19] and SIDiffAgent [80], where historical exemplars or prior trajectories are retrieved by similarity to the current context, and ASAP [90], where related historical optimization cases are retrieved for similar model and hardware settings.

4.2. Selection-Mechanism Control

When multiple selection mechanisms coexist in the same framework, an additional design question arises: what determines which mechanism is used at the current step? Existing systems mainly address this issue in two ways. Some dynamically switch among selection mechanisms according to the current search regime, most commonly to balance exploration and exploitation. Others assign different mechanisms to different selection roles, such as choosing primary parents versus retrieving auxiliary references.

4.2.1. Mode-Controlled Selection-Mechanism Control

The first pattern is to let the active selection mechanism depend on the current search mode. In such systems, the selection target may remain the same, but the system changes how that target is sampled when it wants broader exploration or more focused exploitation.

This pattern is especially clear in AdaEvolve and RankEvolve. AdaEvolve uses different main-parent sampling rules under exploration and exploitation, switching between broader local-archive sampling and stronger fitness-biased reuse [69]. RankEvolve likewise alternates among several parent-selection strategies, including uniform, elite-oriented, and weighted sampling from the current island [88]. The main advantage of this design is that it allows one framework to combine the robustness of broad sampling with the efficiency of stronger selective pressure, rather than fixing one parent-selection bias for the entire run.

4.2.2. Object-Specific Selection-Mechanism Control

The second pattern is to let the active mechanism depend on the reuse role that the selected candidate will play. This is particularly important in LLM-ES systems because the prompt often reuses historical candidates in more than one way. Within a single iteration, the main editable parent, auxiliary reference solutions, retrieved search trajectories, and evaluator-derived diagnostic cases may each be selected using different mechanisms.

In current systems, this logic often takes the form of selecting the main editable candidate through one mechanism and auxiliary references through another. This design appears in [99], CODEEVOLVE [75], and SEA-TS [70]. The main advantage is that it lets the system match the selection mechanism to the role of the reused object.

Some systems combine both forms of control. AdaEvolve is one example because it distinguishes main parents from inspirations while also changing parent-selection behavior across exploration and exploitation modes [69]. More structurally special systems such as X-evolve also mix different control logics across different reusable objects and different levels of the search process [65].

5. Candidate Generation Mechanism

After parent candidates are selected, the search process proceeds to decide how the next candidate should be generated from them. This is analogous to classical EC, where different operators determine the number of parents involved and the relation between parents and offspring. In LLM-ES, the corresponding decision is realized through prompt-conditioned LLM calls rather than through hand-coded variation operators.

5.1. Candidate Generation Mechanisms

The generation mechanism determines whether the offspring is produced from scratch, by broadly rewriting one parent, by locally editing one parent, or by fusing multiple parents. These choices define the effective parent cardinality and the degree of continuity between parent and offspring. As summarized in Figure 7, four common mechanisms appear in the current literature: from-scratch generation, large-scale modification, localized modification, and multi-parent fusion.

5.1.1. From-Scratch Generation

The simplest generation mechanism is from-scratch generation. Under this mechanism, the prompt asks the LLM to propose a new candidate directly from the task description, retrieved knowledge, or initialization context, without editing any candidate parent. The generation therefore relies mainly on the LLM’s background knowledge together with human prior guidance embedded in the prompt. Population-Evolve [81] and QuantEvolve [102] are representative examples. Under this generation style, the effective parent cardinality is usually zero. Some systems may still expose retrieved examples or domain heuristics, but these function as prompt priors rather than genealogical parents [81,90].

5.1.2. Large-Scale Modification

A second family uses the prompt to request a large-scale modification of an existing solution. This mechanism uses an existing solution as the basis for generation, but only preserves a limited portion of its content and allows broad revisions at the level of an entire function, algorithm, policy, or other structured artifact. This mechanism gives the LLM more freedom to propose substantial conceptual changes while still retaining some continuity with the current solution. [105], DeltaEvolve [106] and AdaEvolve [69] all exemplify this pattern.

The most common form is unary rewrite: one parent is selected and broadly rewritten into a descendant. [105], ThetaEvolve [14], and AdaEvolve [69] all follow this pattern, where a selected parent is revised at a relatively coarse granularity rather than edited through local patches. Some systems additionally introduce other reference solutions besides the rewritten parent. DeltaEvolve [106], EvolveSignal [107], and EvoSLD [44] are useful examples.

Because the resulting offspring may differ substantially from the parent, this mechanism tends to preserve less local continuity during search. As a result, its exploit capability is similar to from-scratch generation and is relatively weak.

5.1.3. Localized Modification

A third family uses the prompt to request a localized modification of the parent through patches, search/replace blocks, explicit diffs, or other tightly scoped edits. Compared with large-scale modification, this mechanism preserves more of the parent and constrains the generated change to a smaller region, which makes the search process easier to control. It is therefore better suited to targeted improvement and more stable refinement. AlphaEvolve [13] is the canonical case, since its operator is grounded in structured SEARCH/REPLACE edits rather than unconstrained regeneration. CodeEvolve [75], RankEvolve [88], and GigaEvo [86] follow the same broad logic, and ShinkaEvolve [67] includes a comparable diff-edit mode within a broader hybrid framework.

This family is again predominantly unary in genealogy: one parent is directly edited, even when several archived references are shown alongside it. AlphaEvolve augments the editable target with inspiration programs from its database [13]. CodeEvolve adds nearby ancestors and inspiration solutions around the target parent [75]. RankEvolve further enriches the prompt with additional contextual references from an island-based MAP-Elites setting [88].

The limitation of localized modification is that the search can become overly concentrated around the current parent. Small edits are less suitable for structural rewrites or larger conceptual changes, and repeated local refinement may make it harder to escape a nearby local optimum. As a result, this mechanism often needs to be combined with broader generation modes or more diverse parent selection to maintain sufficient exploration.

5.1.4. Multi-Parent Fusion

The fourth family performs fusion, namely synthesizing a child by combining information from multiple parent candidates. The advantage of this mechanism is that it can combine complementary information from different parents, rather than refining only one existing search branch. It is therefore more suitable for cross-branch recombination and for constructing offspring that inherits useful traits from multiple prior solutions. VRPAgent [76,108], and [92] all implement explicit multi-parent combination. ShinkaEvolve [67] likewise includes a crossover mutation mode, and TIDE [60] provides recombination-style operators inside a broader operator portfolio.

Fusion can be implemented at different levels. At the code or structure level, VRPAgent uses crossover to directly recombine heuristic operators within a fixed metaheuristic framework [76]. At a more semantic level, the adversarial imitation-learning work prompts the LLM to combine and refine parent programs according to their structural and behavioral properties, so the offspring is generated through semantic recomposition rather than explicit code splicing [92]. Pareto-Grid-Guided search further inserts reflective feedback before fusion, so parent heuristics are first analyzed and then recombined under additional guidance [108]. TIDE extends this line further by separating exploratory crossover from backbone extraction, and by reusing fusion as a reset mechanism that reconstructs a high-quality seed from accumulated search experience [60].

5.2. Generation Mechanism Selection

The four generation mechanisms discussed above each have their own strengths and limitations. Using different mechanisms at different stages of search can therefore help exploit their respective advantages. Some systems accordingly combine multiple generation mechanisms within their evolutionary process. This in turn raises the question of when to use which mechanism. Especially when computational budget or LLM calling budget is limited, the mechanism selection strategy largely determines the evolutionary behavior of LLM-ES. Different works design different selection strategies for this purpose.

5.2.1. Fixed Selection

The simplest design is to fix the use of generation mechanisms in advance, either through explicit probabilities over an operator portfolio or through a predetermined operator pipeline. ShinkaEvolve directly specifies probability vectors over diff edits, full rewrites, and crossover mutation [67]. MadEvolve follows the same pattern with a configurable mix of differential patches, full rewrites, and synthesis [40]. [108] likewise keeps a fixed mutation–crossover split, with semantic clustering only constraining crossover pairing. VRPAgent is fixed at the pipeline level: crossover generates offspring, while mutation is reserved for elite refinement [76].

The limitation of fixed selection is that the allocation is decided before the run and remains unchanged throughout search. As a result, it cannot react when different generation mechanisms become more or less useful at different search stages, and may waste budget on mechanisms that are less effective.

5.2.2. Scheduled Selection

Scheduled selection assigns different generation mechanisms to different stages of the evolutionary process. AgentLTV is a representative case. It follows a two-stage search process, where the MCTS stage mainly expands the search tree through mutation-style candidate edits on existing programs, while the subsequent evolutionary algorithm stage introduces a evolutionary process with crossover and mutation [38]. A similar stage-wise design appears in [99], where early iterations reduce reuse of historical candidates to encourage broader exploratory generation, and later iterations reintroduce prior candidates to support more refinement-oriented generation.

5.2.3. Adaptive Selection

Scheduled selection requires the stages to be predefined in advance, which relies on human prior knowledge and is relatively less generalizable across different problems. Adaptive selection instead updates the choice of generation mechanism online according to the observed search process.

Representative examples include [79], where a Strategist decides at each iteration whether the Implementor should refine, combine, or innovate; TIDE, which uses an explicit operator menu with two crossover-style strategies (E1, E2) and three mutation-style strategies (M1, M2, M3) and selects among them with UCB [60]; and REvolution, which maintains a strategy menu whose exact contents depend on whether the current subpopulation contains failed or successful designs, and updates strategy choice by a hybrid UCB-Softmax rule [39]. In general, adaptive selection bases this decision on observed search feedback, such as recent operator outcomes, search progress, or the current state of the maintained population. Its goal is to allocate the available generation mechanisms more appropriately to the current search regime, thereby improving the balance between exploration and refinement.

6. Prompt Builder

After parent candidates and candidate generation mechanisms have been determined, LLM-ES still needs to organize them together with task information into the actual prompt consumed by the LLM. This is the role of the prompt builder. It determines what task information is visible, how selected parent context is embedded, how generation intent is expressed, and how additional prior solutions are presented as references.

The prompt builder is realized through prompt templates, namely concrete textual scaffolds that organize the relevant information into the input presented to the LLM. Although the detailed contents of these templates vary substantially across systems, templates intended to elicit the same type of output often share a similar structure. In existing multi-agent LLM-ES systems, these different output types are typically associated with different roles. Such roles can be divided into coordination, planning, candidate generation, and reflection, which in turn correspond to different prompt structures. Figure 8 illustrates a representative workflow in which these roles interact and iteratively exchange information to produce candidate solutions. We therefore organize the discussion mainly through the major prompt structures associated with these roles.

6.1. Candidate-Generation Prompt Structures

Candidate-generation prompts are the main interface through which LLM-ES produces new candidate solutions. In multi-agent settings, they are commonly associated with candidate generation roles. Their structure typically combines a small set of mandatory sections with optional contextual sections. Figure 9 shows a representative candidate-generation prompt structure.

In such structures, the mandatory sections consist of task description, code interface, and response format. The task description specifies the optimization target and the evaluation requirements. The code interface defines the executable form of the candidate to be generated or revised, including its required inputs, outputs, and functional structure. The response format specifies how the LLM should present the returned candidate. A representative example appears in [99]. Its prompt specifies the optimization target through a task-description block, constrains the editable candidate through a code-interface block, and fixes the LLM output through a response-format block.

Besides these required sections, candidate-generation prompts often include several optional blocks. Unless the candidate is generated from scratch, the prompt needs to provide a main parent candidate. This candidate serves as the base object to be evolved or revised, and it is placed in the editable artifact block. Another optional block is auxiliary context, which contains solution-related information that is not itself the editable target. Its main role is to provide additional search information around the current generation step. This may take the form of prior solutions, retrieved exemplars, historical records, hardware specifications, profiler outputs, or previous feedback [13,38,109]. Constraints and guidance can specialize the generic task statement into domain-specific feasibility rules [100], encode implementation constraints or operational guidance [83,93] or add directional instructions [13,69,109]. By injecting human prior knowledge into the prompt, this block can narrow the effective search region and improve search efficiency.

6.2. Reflective and Meta-Guidance Prompt Structures

Direct candidate generation may be unstable, may provide limited control over search direction, and often relies on pre-defined human guidance, which motivates an intermediate step in which the LLM first generates reflection or guidance before subsequent candidate generation. These prompts are commonly used when the search loop needs intermediate analysis or higher-level directional guidance before the next candidate is produced. In multi-agent settings, reflective prompts are mainly associated with reflection roles, whereas meta-guidance prompts are mainly associated with planning roles. Figure 10 illustrates a representative reflective or meta-guidance prompt structure. Such prompts are usually organized around four sections: a target artifact that specifies the object under analysis, evidence that provides supporting observations or traces, an analysis request that states what the model should infer or recommend, and a response format that constrains the returned output. Across both reflective and meta-guidance prompts, this shared scaffold remains the same, while the functional difference mainly lies in the specific content of the analysis request.

Reflective prompts analyze current candidates and their observed outcomes. These prompts usually include an artifact under analysis, some evidence such as evaluation traces, logs, comparison pairs, or previous runs, and a request for structured diagnosis or reflection. ASAP is a clear example: its analyzer prompt consumes experiment metadata and profiling outputs and produces a structured bottleneck report [90]. AgentLTV likewise includes prompts that compare two code solutions, explain their methodological differences, or synthesize a hybrid strategy from the comparison [38]. GEPA [62] provide closely related cases in which the prompt is designed to return evaluative feedback or ratings.

Meta-guidance prompts determine how the search should proceed next. Reflective prompts guide the LLM to output judgments about the quality and shortcomings of a solution or modification itself, whereas meta-guidance prompts guide the LLM to output guidance for future evolutionary directions. AdaEvolve is the clearest example because it explicitly prompts the model to generate breakthrough tactics conditioned on the evaluator, the current best program, and prior unsuccessful tactics [69]. AgentLTV also contains prompts that select an advice type or format a free-form idea into a structured method description, while cuPilot uses prompts to generate or translate optimization strategies for later kernel evolution [38,109].

The outputs of reflective and meta-guidance prompts are usually stored together with the corresponding candidate as reusable search information. When that candidate is retrieved later, the associated reflection and guidance can be retrieved together with it and integrated into subsequent prompts. One representative use appears in candidate-generation steps, where reflective feedback can be placed in the auxiliary context block, while directional guidance can be placed in the constraints and guidance block of the candidate-generation prompt structure shown in Figure 9.

6.3. Coordination-Oriented Prompting

Coordination-oriented prompts manage the overall search process by routing information across prompts, dispatching subtasks, maintaining persistent state, and organizing interactions among other components of the workflow. In multi-agent settings, these prompts are typically associated with coordination roles. Unlike candidate-generation and reflective prompts, however, current papers usually describe them more clearly in terms of workflow function than in terms of stable reusable section-level templates.

ASAP provides a representative Coordinator Agent that mediates between the user, the Analyzer Agent, and the Proposal Agent [90]. [66] similarly uses a controller to manage persistent state and coordinate interactions among specialized roles. OR-Agent further instantiates an OR Agent for global coordination [110]. In cuPilot, the SCE Manager plays a related coordination role over strategy initialization and crossover [109].

7. Foundation Models

After the prompt is prepared by the prompt builder, it is passed to an LLM to produce a response. Today, thousands of foundation models are available. Owing to differences in model architecture, training paradigm, and service form, these models vary substantially in both capability and cost. For example, GPT/o-series models are often used for strong coding, repair, and difficult-case reasoning, Gemini models are frequently used for high-throughput exploration or multimodal synthesis, and open families such as DeepSeek, Qwen, and Llama are often adopted in self-hosted or cost-sensitive settings. Table 4 summarizes the foundation-model families that recur most frequently in surveyed LLM-ES systems. Existing works can be categorized according to the number of models they use, namely single-model settings and multi-model settings. Figure 11 summarizes the common model-invocation patterns under these settings.

7.1. Single-Model Setting

The most straightforward setting is to employ the same base model throughout the entire optimization pipeline. This paradigm is simple to implement and introduces relatively few additional experimental variables. As a result, it has been widely adopted in many studies on LLM-based optimization and LLM-driven evolution, including OPRO [114], FunSearch [12], and Eureka [115]. Because the same foundation model can still exhibit nontrivial performance differences under different inference configurations, some systems use this property to increase usage diversity even in a single-model setting. For example, EvoCAD uses a lower temperature for evaluation tasks such as visual description and ranking, but a higher temperature for generative operations such as initialization, crossover, and mutation [116].

Methodologically, the main attraction of the single-model setting is control. It reduces confounding variance from heterogeneous model APIs and makes it easier to attribute gains to prompt design, population management, or evaluation design. Its main limitation is limited flexibility: the same model must handle all search stages, so the system cannot easily assign lower-cost models to simple subtasks and more capable models to more difficult ones.

7.2. Multi-Model Setting

Some LLM-ES systems introduce multiple foundation models in order to exploit their respective performance advantages. In such case, the system must decide how these models are allocated during search. We distinguish between static assignment and dynamic assignment.

7.2.1. Static Assignment

In static assignment, multiple models may appear in the same system, but their usage pattern remains fixed throughout the evolutionary process. Most such systems use role-based assignment, where models are bound to fixed generator, refinement, review, transfer, or team roles, as in ArchAgent [18] and PromptBridge [52]. A less common variant is fixed-probability assignment: Applied AlphaEvolve allocates model usage through a static mixture rather than through run-time reassignment [43]. The main advantage of static assignment is simplicity: the roles of different models are easy to specify and interpret, and the resulting system behavior is relatively stable.

7.2.2. Dynamic Assignment

Dynamic assignment addresses the main limitation of static assignment: a fixed allocation policy cannot react to stage-dependent search conditions. By changing model usage across stages, dynamic assignment can better match appropriate models to the current needs of the search process. The trade-off is a more elaborate control policy and additional system complexity.

The cleanest example is AdaptEvolve, where each refinement step starts from a small model and then uses token-level uncertainty features to decide whether the current candidate should be kept or escalated to a larger model; the routing policy itself is further updated online to adapt to the non-stationary evolutionary process [78]. At the generation level, MCCE alternates a frozen API model and a trainable local model as evolutionary operators across generations, so the active model changes with the outer co-evolutionary process [94]. ShinkaEvolve instead updates LLM sampling probabilities after each generation using a bandit-style rule based on relative improvement, reallocating future model usage according to observed search performance [67].

8. Candidate Evaluation

After a new candidate is generated by the LLM, its quality must be evaluated to determine whether it should be retained in the population or archive. In most LLM-ES systems, the problem designer provides an evaluator function, whose direct execution returns a scalar objective or a multi-objective vector. This default object evaluation is an implicit convention in the literature. A small number of systems instead use preference, ranking, or other comparative judgments as the evaluation signal, which is discussed first in this section. Beyond the primary signal itself, the discussion then focuses on two additional aspects that can arise under different evaluation interfaces: extra feedback returned together with the evaluation result, and evaluation procedures for time-consuming, expensive, noisy, or fragile evaluators.The evaluation output structure of LLM-ES systems is shown in Figure 12.

8.1. Preference-Based Evaluation

Some systems depart from the default scalar-score interface and instead treat preference or ranking judgments as the primary evaluation signal. In this regime, evaluation does not begin by assigning each candidate an absolute numeric score and then attaching auxiliary relational information. Rather, pairwise preferences, ranked lists, or other comparative judgments are the core output of the evaluator, and any later scalar quantity is derived only after aggregating these relational signals.

DUEL-EVOLVE is the clearest pairwise-preference example: it does not start from a conventional numeric evaluator, but first collects pairwise preference judgments and then aggregates them into latent utilities with uncertainty estimates [113]. EvoCAD and Lark are the closest ranking-based examples: both first obtain evaluator-provided ordinal rankings and then transform those rankings into fitness-like signals for evolution [95,116]. This design is suitable for settings where candidate quality is easier to compare than to quantify directly, such as open-ended generation tasks or problems with strong subjective or context-dependent criteria.

8.2. Additional Evaluation Feedback

This subsection focuses on additional evaluation feedback beyond the objective value itself. In these systems, evaluation does not end with returning one scalar score or one objective vector. Instead, it also produces extra feedback tied to the candidate, which can be preserved and reused in later search steps. Such feedback makes evaluation not only a selection signal, but also an information source for subsequent generation and revision.

8.2.1. Metadata

One common form of such additional feedback is metadata, namely auxiliary structured information returned together with the objective value during evaluation, such as correctness flags, exception types, profiler measurements, per-instance metrics, penalty codes, decomposed reward components, or other structured verification results. It does not replace the final score, but provides a more fine-grained description of how that score was obtained and what happened during execution, validation, or verification. Compared with a single summary number, such metadata can better support later diagnosis and targeted revision.

AlphaEvolve and KernelEvolve both retain richer evaluation outputs than one objective alone, including correctness-related status together with execution or profiling metadata [13,36]. ThetaEvolve and LtE both expose shaped reward components or derived credit signals that explain why a candidate or trajectory received its final optimization signal [14,117]. Strategic Search and Magellan preserve detailed timing or tuning information [35,79]. [64] returns validation diagnostics, soundness counterexamples, and unsoundness costs rather than only a final pass/fail outcome. EVOSYN preserves structured verification artifacts such as executable pass/fail outcomes, consistency checks, and strategy scores derived from testing behaviors [41].

8.2.2. Verbalized Evaluation Feedback

Structured metadata is useful for recording what happened during evaluation, but it is often less suitable for directly guiding the next generation step. In many cases, the useful signal lies not in one isolated field, but in how multiple evaluation outcomes should be interpreted together. Natural-language feedback is therefore useful for summarizing such information into a more compact form and passing revision-relevant signals to the LLM more directly.

GEPA is the clearest example because its feedback function returns not only a numeric score but also free-form text and evaluation traces [62]. Similar behavior appears in AlphaApollo [118], PACEvolve [89], and REvolution [39], where evaluator outputs are summarized into comments, judgments, or traces rather than being left as raw logs only.

8.3. Evaluation Procedures

In many domains, direct full evaluation is too slow, too noisy, or too failure-prone to be used uniformly for every candidate. As a result, recent frameworks redesign the evaluation loop in several ways. Some organize evaluation into stages, some replace full evaluation with approximate signals, some accelerate evaluation through parallel execution, and some improve robustness through repeated measurement. Table 5 summarizes these representative evaluation procedures.

8.3.1. Staged Evaluation

Staged evaluation begins with lower-cost screening stages and only then promotes surviving candidates to more expensive tests. This helps reduce evaluation cost by filtering out weak or invalid candidates early. Existing systems mainly differ in what they use as the intermediate gate. AlphaResearch [16], Applied AlphaEvolve [43], and FOREAGENT [119] use early performance-oriented screening such as reward-model filtering, minibatches, validation splits before broader validation. AgentLTV [38], ArchAgent [18], and ThetaEvolve [14] instead use execution, verification, or constraint checks to decide whether downstream evaluation should continue.

8.3.2. Approximate Evaluation

Approximate evaluation addresses the same full-evaluation bottleneck from another angle: instead of deciding which candidates should receive complete evaluation, it replaces exact full evaluation itself with approximate, proxy, or partial signals during search. Mathematical exploration and discovery at scale is a strong example: it explicitly uses multiple verifiers with different speed-accuracy tradeoffs and employs approximate geometric scoring procedures when exact evaluation would be too costly [105]. MadEvolve follows the same direction by using reduced-fidelity evaluators during search, such as lower-resolution settings or limited simulation setups, to avoid the cost of stronger full evaluation at every step [40].

8.3.3. Parallel Evaluation

Parallel evaluation addresses the same evaluation-speed bottleneck when the evaluation process itself can be parallelized. In such cases, candidate assessments are distributed across multiple workers, devices, or execution environments rather than being performed serially. CodeEvolve [75], DeltaEvolve [106], and ArchAgent [18] all employ parallel or distributed evaluation to keep the search loop tractable under expensive execution workloads. KernelEvolve follows the same direction with asynchronous remote dispatch to hardware pools [36].

8.3.4. Repeated Evaluation

Repeated evaluation addresses a different issue from the previous designs. Rather than reducing evaluation cost directly, it is used when evaluation outcomes are noisy, unstable, or workload-dependent, so that repeated runs can provide a more reliable estimate. cuPilot and EvolveSignal explicitly average over repeated timed runs or multiple scenarios to stabilize noisy performance measurements [107,109]. PromptBridge and Making Databases Faster with LLM Evolutionary Sampling use the same basic mechanism more generally, where repeated trials and aggregated statistics are built into evaluation itself rather than treated as an afterthought [52,120].

9. Exploration-Exploitation Control

As a metaheuristic search paradigm, LLM-guided evolutionary search faces the same exploration–exploitation challenge as classical evolutionary computation. Compared with classical EC, however, exploration and exploitation in LLM-ES depend simultaneously on multiple coupled factors, including parent selection, generation-operator selection, and foundation-model selection, which makes the design space both broader and more complex. At a high level, exploitation means continuing to generate better descendants along the search process associated with the currently strongest solutions, whereas exploration means shifting toward other search directions to escape local convergence. Some of these issues have already appeared in previous sections through archive and parent-selection design, generation mechanism selection, and model selection. This section therefore moves to a more global perspective and discusses how LLM-ES systems control the overall balance between exploration and exploitation. Table 6 summarizes the main explore–exploit control strategies discussed in this section.

9.1. Implicit Exploration-Exploitation Strategies

In many explicit explore–exploit designs, the two behaviors are realized through different contexts or control signals so that the LLM is guided to generate different kinds of responses. By contrast, some LLM-ES systems do not explicitly distinguish between exploratory and exploitative generation processes. Instead, they reuse one unified generation process and rely on the inherent stochasticity of LLM generation, together with differences in sampling, memory reuse, or archive exposure, to produce outcomes that behave differently in exploration and exploitation.

AlphaEvolve is the clearest example: it samples parents and inspirations from a persistent program database, proposes structured edits, evaluates offspring, and reinserts promising solutions [13]. Exploration arises from stochastic generation, archive diversity, and the resurfacing of multiple prior ideas, while exploitation arises from repeatedly refining strong stored programs. ThetaEvolve [14] and [66] follow the same broad logic, although with stronger archive boundaries than AlphaEvolve. In these systems, there is no dedicated switching variable that says “explore now” or “exploit now.” Instead, the balance is realized through ranked database sampling, multiple rollouts, archive truncation, or persistent state reuse. EvoSLD also fits this pattern: it samples high-scoring parent subroutine pairs from a database, exposes additional high-performing pairs as contextual references, and relies on LLM mutation to generate diverse descendants without introducing a separate exploration-exploitation controller [44].

9.2. State-Independent Exploration-Exploitation Control

When exploration and exploitation are explicitly realized through different generation processes, the system gains a clearer way to separate broad search from local refinement. In this setting, however, a new question immediately arises: when should the current evolutionary step emphasize exploration, and when should it emphasize exploitation? One broad answer is to decide this independently of the current search state. In such systems, the control rule is specified in advance rather than adjusted online from observed progress, uncertainty, or stagnation.

The simplest state-independent designs use fixed rules throughout the search process. MadEvolve alternates between full rewrites and differential patches under a preset allocation [40], while RankEvolve chooses among exploratory, exploitative, and intermediate parent-sampling modes under a predefined distribution [88]. Other systems use predefined stage schedules, where the search pressure changes over time according to a hand-designed progression across stages. [99] and [122] both place broader exploration earlier and more conservative exploitation later. AgentLTV [38] and [123] follow the same exploration-first, exploitation-later logic, but there the shift acts directly on the outer search mode itself.

The main advantage of such state-independent control is interpretability. A user can identify in advance how exploratory and exploitative behavior will be allocated. This simplicity makes these systems comparatively easy to reproduce and analyze, although the resulting search pressure may not match the realized trajectory of every run.

9.3. Adaptive Exploration-Exploitation Strategies

The limitation of state-independent control is that the explore–exploit balance is predetermined before the run begins. In practice, however, the search process can stagnate earlier than expected, continue benefiting from exploration longer than expected, or require stronger exploitation in only a subset of branches. This creates the need for adaptive strategies, which adjust the explore–exploit balance online according to the observed search state. The main benefit of such designs is that they can respond more flexibly to actual progress, uncertainty, or resource usage during evolution.

AdaEvolve adjusts each island’s exploration intensity from recent improvements, so stagnation increases exploratory sampling while strong progress increases exploitative refinement [69]. [79] uses a strategist conditioned on the current search context to choose whether to innovate, combine, or refine. AgentLTV [38], SEA-TS [70], and AdaExplore [121] instead adapt search pressure through tree statistics, using PUCT-, UCT-, or MCTS-style selection to trade off exploration against refinement during the run. TIDE [60], ShinkaEvolve [67], and SMCEvolve [124] apply the same general idea to prompt strategies, LLM choices, island-level resource allocation, or annealing-based search-pressure control. CausalEvolve gives a related factor-level variant: it uses a bandit-style controller to alternate between exploratory random interventions and exploitative best-action reuse [125]. Taken together, these systems treat explore–exploit balance as an online control problem that is continuously updated from observed feedback during search.

10. Applications and Open-Source Frameworks

By combining semantic generation with iterative feedback-driven search, LLM-ES has achieved applications and representative results across a wide range of domains. It is especially suitable for complex structured optimization problems whose solutions are difficult to hand-design but can still be evaluated through executable, simulatable, or verifiable feedback. In some cases, the discovered solutions even surpass the best human-designed results. Figure 13 summarizes the five core application domains of LLM-ES, presenting representative tasks and their corresponding state-of-the-art breakthroughs with quantitative performance improvements. These results collectively demonstrate the paradigm’s broad applicability and superior performance across diverse scientific and engineering fields.

10.1. Applications

10.1.1. Mathematical Sciences

Mathematical-science problems often have highly structured search spaces, strong symbolic constraints, and clear verification procedures, but they also tend to suffer from severe combinatorial explosion and heavy reliance on expert-designed heuristics. This makes them especially suitable for LLM-ES. Existing work has already demonstrated representative progress in several major directions.

10.1.1.1. Open-Problem Exploration

Open mathematical problems lie at the core of pure mathematics and typically lack clear solution pathways, making systematic breakthroughs challenging for traditional approaches.

AlphaEvolve provides the strongest early evidence that LLM-ES can make nontrivial progress on open mathematical problems [13]. Across open tasks spanning analysis, combinatorics, number theory, and geometry, it matches the best known constructions in 38 cases and surpasses them in 14 cases. Its most striking result is a new $4\times 4$ matrix multiplication algorithm, which constitutes the first improvement in this setting after 56 years of work. ThetaEvolve shows that such progress is not limited to large closed-source model ensembles [14]: using a small open-source model, it obtains new best-known bounds on open problems highlighted by AlphaEvolve. AlphaResearch further demonstrates that LLM-ES can be competitive with human researchers in open-ended mathematical algorithm discovery [16]. On its AlphaResearchComp benchmark of eight open-ended problems, it achieves a 2/8 win rate in head-to-head comparison against human researchers.

10.1.1.2. Heuristic Discovery

Heuristics denote manually designed algorithmic rules, operators, or decision policies used to construct or improve approximate solutions for computationally intractable optimization problems. Such heuristics are central to many hard discrete optimization tasks, but their manual design is often time-consuming and highly dependent on domain expertise.

TIDE demonstrates strong heuristic-discovery performance of LLM-ES across multiple NP-hard combinatorial optimization problems [60]. Across nine combinatorial optimization tasks and five algorithmic frameworks, it consistently achieves the best results among LLM-based automated heuristic design methods. For SAT solving, AutoModSAT reports more than 50% performance improvement over its baseline modular solver and average gains exceeding 30% over existing state-of-the-art solvers [37]. For multi-objective combinatorial optimization, MPaGE consistently outperforms prior LLM-based heuristic-design methods across multiple benchmarks [108]. Related mathematical applications in this direction include adversarial heuristic generation for combinatorial optimization [126], game-theoretic co-evolution for heuristic discovery [127], ranking-function evolution for canonical blow-up construction [128], evaluation of LLM-evolved 2D bin-packing heuristics [129], and reinforced generation of combinatorial structures for complexity-theoretic constructions [130].

10.1.1.3. Knowledge Discovery

Automated Knowledge discovery aims to enable intelligent systems to uncover mathematical knowledge across different levels of abstraction, ranging from data-driven equation identification to high-level theory formation. This direction serves as a paradigm bridging empirical observations and formal mathematical reasoning.

In symbolic regression, IdeaSearchFitter demonstrates that LLM-ES can recover mathematical expressions and physical laws directly from data with high accuracy and robustness [131]. On the FSReD benchmark, it outperforms several strong baselines in both noise-free and noisy settings, while also producing compact and interpretable expressions on real-world datasets. At a higher level of abstraction, EvoAbstract shows that LLM-ES can support automated mathematical theory formation rather than only equation fitting [132]. In the FERMAT environment for elementary number theory and finite fields, its evolved interestingness measures outperform manually designed baselines and rediscover core concepts such as powers, primality, and finite-field constructions.

10.1.2. Computer Science

LLM-ES systems have been successfully applied to automated optimization across the full stack of computer systems, spanning hardware design, system scheduling, compiler optimization, and kernel generation.

At the system level, AlphaEvolve has been applied to multiple components of Google’s computing infrastructure, including data center scheduling, large model training, hardware circuit design, and low-level kernel optimization, consistently improving system efficiency and reducing optimization time [13].

In computer architecture, ArchAgent automates the design of last-level cache replacement policies [18]. By leveraging cycle-accurate simulation, it generates optimized strategies for both standard benchmarks and real-world workloads, while supporting workload-aware runtime tuning to improve processor performance.

At the compiler and kernel level, this paradigm enables the automatic discovery of optimization strategies traditionally crafted by experts. Magellan synthesizes compiler heuristics for tasks such as function inlining, register allocation, and computation graph transformation, producing deployable optimization rules that improve performance across compiler frameworks [35]. KernelEvolve further extends this idea to heterogeneous AI systems, where it automatically generates and optimizes high-performance kernels for deep learning workloads across diverse hardware platforms [36]. The same paradigm has also been applied to Gaussian splatting kernels, showing that LLM-guided code evolution can optimize graphics-oriented low-level kernels beyond standard deep-learning operators [133].

10.1.3. Artificial Intelligence

Artificial intelligence presents a broad class of design problems in which the target object is related to neural networks, reward functions, agent pipelines, etc. These objects are typically difficult to optimize manually, while their quality can often be assessed through task performance or downstream system feedback.

At a more general machine-learning level, evolutionary methods have been used to discover scaling laws that characterize how model performance changes with training and model size [44]. The same paradigm also supports programmatic representation learning [134]. In neural rendering and representation design, EvoRender applies LLM-guided evolutionary search to neural texture compression decoder discovery and reports architectures that outperform hand-designed baselines [135].

For LLM agents and reasoning systems, evolutionary optimization has been used to refine prompts, tool usage, execution configurations, and reasoning trajectories. [54] and GEPA [62] show that such optimization can consistently improve reasoning and code-generation performance without parameter updates. [84] further strengthens deep reasoning through iterative refinement over candidate reasoning paths, while [81] improve the accuracy, stability, and efficiency of mathematical reasoning across models of different scales. In advanced text generation, WRitEer [136] combines multi-agent collaboration, evolutionary prompt refinement, and preference-based fine-tuning to improve human-like writing quality.

In reinforcement learning, [93] automatically evolves interpretable and verifiable environment dynamics for model-based reinforcement learning, GRACE [85] searches over executable reward functions for inverse reinforcement learning, and [137] search discovers multi-agent learning algorithms for imperfect-information games.

LLM-ES has also been applied to AI systems and infrastructure optimization. ASAP [90] uses a multi-agent framework to diagnose and improve distributed LLM training bottlenecks across computation, memory, and communication, while ContextEvolve [19] combines multi-agent context compression with evolutionary search to optimize system-level code under limited context budgets.

10.1.4. Natural Sciences

Natural-science problems focus on discovering governing laws, mechanistic models, or domain-specific computational procedures from observational data, simulations, and experiments.

In scientific equation discovery, SR-SCIENTIST searches for interpretable equations from data across physics, chemistry, biology, and materials science, outperforming baselines by absolute margins of 6%–35% [15]. In quantum simulation, evolutionary program synthesis optimizes executable circuit-generation code for molecular structure learning and many-body dynamics, reducing approximation error from 10.4% to 0.82% [138]. In cognitive and behavioral science, DataDIVER discovers interpretable computational models of human and animal learning directly from behavioral data and uses them to surface new mechanistic insights [139]. In computational biology, VCHarness applies autonomous program search to perturbation-response model construction for virtual cells, outperforming expert-designed baselines [140]. In ecological monitoring, the bioacoustic-association framework addresses the constrained problem of multi-channel whale-call association, discovering algorithms that generalize to unseen synthetic regimes and transfer effectively to real-world whale datasets [100]. In molecular and drug discovery, MCCE tackles five-objective molecule design and reports state-of-the-art Pareto-front quality [94].

10.1.5. Control and Engineering Systems

Control and engineering systems typically require executable policies or rules that operate under dynamics and uncertainty. These problems are well suited to LLM-ES because candidate solutions can be evaluated directly in simulators or operational environments, allowing iterative search over structured control logic rather than only parameter tuning.

In intelligent manufacturing, this paradigm automatically generates and refines dispatching rules for dynamic flexible job-shop scheduling under stochastic and multi-stage settings, and has also been extended to dynamic hybrid flow shop scheduling through personalized multi-island reflective evolution [141,142]. In power system scheduling, theory-driven modeling and LLM-guided evolution are used to discover warm-start scoring functions and hyperparameter configurations for large-scale unit commitment and economic dispatch problems [143]. In transportation and logistics, VRPAgent targets multiple vehicle-routing problems, and reports heuristic operators that outperform prior state-of-the-art VRP heuristics [76]. In traffic control, it evolves signal timing policies in simulators such as SUMO, yielding lightweight and effective strategies that outperform classical heuristics while remaining practical for real-world deployment [107]. Related work also studies robot path planning by combining it with reinforcement learning, treating path-planning control policies as executable objects that can be evaluated and improved in closed loop [144].

10.1.6. Emerging Domains

Beyond the major domains above, recent LLM-ES applications have also begun to target newer areas. In quantitative finance, EvoRisk autonomously discovers a regime-adaptive risk metric for asset selection and portfolio optimization under volatility shifts, jump risk, and persistent drawdowns [145]. In biomedical imaging, EvoAgents applies LLM-guided evolutionary search to automatically generate and refine convolutional architectures for cell nuclei detection from microscopy images [146]. In social simulation and AI evaluation, Persona Generators evolves reusable code that expands compact context descriptions into diverse synthetic populations for stress-testing human-facing AI systems across a wider range of possible user behaviors [147].

10.2. Open-Source Frameworks

As LLM-ES has expanded across application domains, a corresponding resource ecosystem has also emerged. Open-source implementations expose reusable search loops, evaluators, and engineering pipelines that support later reproduction and extension. Table 7 summarizes representative open-source frameworks.

11. Benchmarks

As LLM-ES has expanded across tasks and domains, a corresponding benchmark ecosystem has also emerged. Some of the benchmarks listed in Table 8, from ADRS [104] to MLEBench [149], were not originally introduced specifically for LLM-ES, but have been repeatedly adopted as public evaluation targets in later work. By contrast, more recent benchmarks such as FrontierCS [150] and FML-bench [151] were introduced with concerns that are more directly tied to this area. Their papers repeatedly argue that many existing evaluations are built around known answers, pass-or-fail grading, isolated code snippets, or end metrics that reveal little about iterative search and research behavior.

The motivations given in these newer benchmark papers are also fairly consistent. FrontierCS [150] emphasizes open-ended computer-science problems whose optima are unknown but whose solutions remain executable and deterministically scorable. HeuriGym [152] justifies combinatorial optimization as a setting with clear objectives and large solution spaces for iterative heuristic improvement. AIRS-Bench [153] argues for a standardized framework to compare AI research agents across full research-lifecycle tasks. FML-bench [151] emphasizes fundamental machine-learning research problems and metrics that capture iterative research behavior rather than only final performance and cost. CktEvo [154] highlights repository-level RTL evolution, where evaluation must account for cross-file dependencies and toolchain-in-the-loop feedback rather than isolated modules. Taken together, these benchmarks indicate that evaluation in this area is moving toward settings that are more open-ended, executable, and process-aware, while still remaining objectively checkable. Representative publicly available benchmarks are summarized in Table 8.

12. Conclusion

12.1. Summary of Key Findings

LLM-guided evolutionary search can be understood as an important form of LLM test-time scaling. Compared with repeated sampling or simply extending one chain of thought, LLM-ES improves performance more systematically by increasing generation attempts, using search state to steer later generations, and maintaining candidates whose evaluated quality keeps improving under the target objective. Because of this potential, the area has developed rapidly, but the relationships among existing systems have remained insufficiently organized. This survey attempts to classify existing works from the main layers of an LLM-ES pipeline, including search problem formulation, population design, parent selection, candidate generation mechanisms, prompt builder design, foundation-model use, candidate evaluation, exploration–exploitation control, and the surrounding application and resource ecosystem. The goal is to provide a quick guide for new researchers and a clearer systems-level perspective for more experienced audience.

12.2. Open Challenges and Future Directions

12.2.1. Aligning Foundation Models with Evolutionary Search

One major direction is to make the foundation model itself better aligned with evolutionary search. Most current LLM-ES systems keep the backbone largely fixed and focus mainly on designing the search loop above it. This has been effective, but it also means that the model is usually not optimized for iterative revision, long-horizon search, repeated evaluator-conditioned improvement, or coordinated multi-role interaction. A natural next step is therefore to adapt the model directly from search trajectories, successful revisions, and verifier feedback, as early systems with in-loop model updating already begin to suggest [78,94]. An initial attempt in this direction adapts the model from search-generated algorithm databases rather than leaving the backbone entirely unchanged [170]. More broadly, closer integration with multi-agent reinforcement-learning and reasoning-oriented training paradigms may help the model become not only a better generator of candidates, but also a better search participant that can revise, coordinate, and reason more effectively across many evolutionary iterations.

12.2.2. Moving Beyond Near-Zeroth-Order Optimization

Another challenge is to move beyond the current reliance on near-zeroth-order optimization [69]. Most existing methods still depend mainly on candidate generation, trial-and-error evaluation, and selection, while making limited use of higher-order information about how the search landscape is changing. This limitation matters because pure black-box iteration can be expensive and slow, especially in long-horizon problems with costly evaluation. A promising direction is to incorporate more structured update signals, surrogate local models, or optimization-inspired state that can accelerate search beyond simple sampling and filtering. Recent work such as TextBFGS points to this possibility by explicitly modeling a text-space analogue of BFGS-style updates [171], but much broader exploration is still needed.

12.2.3. Building Human-in-the-Loop Evolutionary Workflows

A further challenge is to build more effective human-in-the-loop evolutionary workflows. Current systems are dominated by fully automated loops, while human guidance often enters only through task formulation, benchmark choice, or occasional manual intervention outside the formal search process. In many realistic research and engineering settings, however, humans are important not only because they can provide preferences or corrections, but also because they can reformulate objectives, inject domain knowledge, and redirect search when automatic evaluation is incomplete. Recent systems already hint at this direction by mixing LLM search with explicit human simplification or review steps [126], but making such collaboration more systematic remains an open problem.

12.2.4. Symbolic Theorem Proving

Mathematical discovery and theorem proving form another important frontier. Symbolic regression and theory-formation systems already show that LLM-ES can contribute to mathematical pattern discovery, but stronger integration with formal proving, verifier-guided search, and theorem-oriented reasoning may substantially expand this line of work. Even though the technical route is different from typical LLM-ES pipelines, recent progress in Olympiad-level formal mathematical reasoning, such as AlphaProof, suggests the broader promise of combining search, verification, and learning for difficult mathematical problems [172].

12.2.5. Expanding Toward High-Value Real-World Applications

LLM-ES is likely to expand further toward real-world directions with clearer commercial or scientific value. Much of the current literature still concentrates on algorithm discovery, synthetic benchmarks, or well-scoped scientific tasks. Going forward, more attention may shift toward deployment-relevant settings such as auto bidding, safety-constrained industrial optimization, and high-impact scientific systems including controlled nuclear fusion. These domains place stricter demands on reliability, efficiency, and interpretability, but they are also where stronger LLM-ES systems may ultimately deliver the most practical value.