SimpleEvol: An Agent-Loop Framework for LLM-Driven Automated Heuristic Design with Minimal Human Priors

Conference: NeurIPS2026
arXiv: 2609.37172
Code: https://github.com/HenryZhu1029/SimpleEvol-Master
Area: Optimization & Theory
Keywords: automated heuristic design, agent loop, trajectory memory, combinatorial optimization, intelligence conversion efficiency

TL;DR

SimpleEvol replaces elaborate population and evolutionary-operator orchestration with one “generate code—execute and evaluate—compress memory” search trajectory, obtaining the highest TSP/CVRP intelligence-conversion regression slopes across ten LLMs and lower test gaps at every evaluated size with GPT-5-mini, without establishing that fewer priors necessarily improve performance.

Background & Motivation

Automated heuristic design (AHD) does not ask an LLM to output routes directly for every customer instance. It asks the model to write a reusable decision function, then tests that function on optimization instances. FunSearch organizes search through program islands and candidate sampling, EoH prescribes crossover- and mutation-like operations, and ReEvo adds short- and long-term reflection. These mechanisms can control exploration, but they also confine the model to human-specified roles: even if it can diagnose a failure and propose a different algorithmic approach, the current operator's output contract may prevent it from expressing that approach.

Comparing only the final objective of one model–framework combination therefore cannot establish whether a framework makes effective use of stronger models. Better results may come from the model itself or from outer-loop search engineering. This paper instead compares ten backbone models: as an external composite proxy for knowledge, instruction following, mathematics, and coding improves, which frameworks show larger improvements in heuristic quality? The authors introduce AHI to describe orchestration structure and ICE to summarize the cross-model performance trend, then test this perspective with a framework that deliberately reduces external control.

The simplification removes explicit population management and predefined coordination among multiple operators, not all human knowledge. Task interfaces, evaluators, best-candidate retention, memory-compression intervals, and the underlying ACO/GLS solvers remain human-defined. Core Idea: let the same LLM choose its search strategy while retaining executable feedback, the best candidate, and compressed trajectories, so that it accumulates experience through successive experiments rather than being routed among fixed evolutionary operations by an external controller.

Method

Overall Architecture

Inputs include an optimization problem description, the required function interface, and training instances; the output is the best heuristic code found through training evaluation. SimpleEvol maintains one chronological trajectory of attempts. At each iteration, the same LLM proposes a candidate and a short algorithm description, and execution produces objective values, runtime, errors, and an experiment index that are fed back into context. By default, history is compressed every five iterations, retaining working notes and the best candidate before search continues.

Two loops must be distinguished: the outer LLM loop designs heuristics, while the inner loop executes candidate programs within fixed solvers. A TSP candidate chooses the next city; a CVRP candidate generates an edge-preference matrix for ACO; an FSSP candidate modifies the GLS search landscape and selects jobs for perturbation. At final deployment or testing, the selected code runs without requiring another LLM call for every decision.

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    A["Task interface and<br/>training instances"] --> B["Autonomous Candidate<br/>Generation"]
    B --> C["Executable Feedback"]
    C -->|Compress every five iterations| D["Trajectory Memory<br/>and Elite Retention"]
    C -->|Recent evaluations enter context| B
    D -->|Working notes and best code| B
    C -->|Select training best when budget ends| E["Final heuristic code"]
    X["New test instances"] --> F["Fixed-solver execution"]
    E --> F
    F --> G["Routes or job sequences"]

The feedback and memory edges belong only to search; the path from new test instances to the fixed solver belongs to final heuristic inference. Test results measure generalization rather than supervising the LLM during the main experimental search process.

Key Designs

1. Autonomous Candidate Generation: do not prescribe whether the next step must be crossover or mutation

Conventional frameworks often select parent candidates first and then ask the LLM to perform a specific local edit. SimpleEvol instead supplies the problem description, experimental progress, and accumulated context, allowing the model to choose its next algorithmic direction and return code with a design explanation. A candidate may repair existing logic or replace its central strategy; the population controller and operator menu no longer predetermine how exploration proceeds. This remains a serial trajectory generating one candidate at a time, not permission for the model to alter the actual evaluation budget or redefine the task.

Appendix B shows that this autonomy still has explicit prompting structure: the model is encouraged to record attempts, reflect on outcomes, compare strategies, and plan improvements. The post-compression generation prompt also includes a clue encouraging behavioral diversity. Thus, the absence of a separate reflection module does not mean the absence of reflection; reflection is integrated into the same model's reasoning and generation. “Minimal priors” likewise does not mean unconstrained prompts. A potential advantage is that the model can choose the granularity of its improvement based on the type of failure rather than recasting every problem as prescribed crossover or mutation.

2. Executable Feedback: constrain code and explanations with actual optimization outcomes

Without execution-based evaluation, a model can repeatedly propose ideas that sound plausible but fail to run or improve results. Each candidate executes on training instances, and the evaluator records objective values, runtime, errors, and the attempt index. These observations and the candidate's design explanation become context for the next iteration. Feedback communicates not only whether a candidate improves performance, but also whether it fails through poor optimization, timeout, or interface errors, avoiding the same blind edit for every failure type.

The LLM does not invent the evaluator on demand: function interfaces, feasibility checks, objectives, and execution limits are external constraints. The TSP decision function receives the current node, destination, unvisited set, and distance matrix and returns the next node. The CVRP function receives distances, coordinates, demands, and capacity and returns an edge-preference matrix; pheromones and ACO still construct the routes. The FSSP function receives the current job sequence and processing-time matrix and returns a modified matrix and jobs to perturb; GLS neighborhood search still advances the optimization. The simplification concerns how these functions are discovered, not discovery of the entire solver.

This also bounds the interpretation of performance. Each TSP/CVRP candidate has a 60-second evaluation limit, and FSSP has a 60-second limit per instance; code must satisfy these rules. Complex heuristics discovered by stronger models remain subject to runtime budgets, while the task interface already defines the searchable algorithm space. The evaluator and surrounding solvers are important structural priors, even when AHI does not count them separately.

3. Trajectory Memory and Elite Retention: compress experience without losing the best solution

Retaining all code, errors, and results as candidates accumulate lengthens context, raises input costs, and dilutes useful signals. By default, SimpleEvol asks the same LLM to compress history every five iterations, summarizing effective and ineffective structural patterns, recurring implementation errors, and experimental progress into working notes before removing older records. Memory accumulates experience about promising directions rather than functioning as an external planner that mandates the next operation.

Compression also preserves the best candidate and its meta-information, preventing the system from retaining only abstract lessons while losing its verified executable baseline. The best candidate anchors the whole search: a single trajectory does not mean that a worse new candidate overwrites the historical best. New attempts may fail, but the final output is still selected by training evaluation. Removing best-candidate retention causes the largest gap increase in the ablation study, showing that effectiveness depends on this deliberately imposed structural prior rather than unrestricted autonomy alone.

Compression and code generation are distinct LLM invocation types, so SimpleEvol makes more calls than it evaluates candidates. It removes explicit populations and multi-operator routing but does not guarantee the shortest runtime or lowest input-token usage. Serial progress also gives up the candidate parallelism available to population-based methods. This trade-off must be assessed against actual costs and model capabilities.

A Worked Example

For TSP trained on 50-node instances, the model first writes candidate code for the next-node selection interface. The evaluator runs it on 64 training instances and returns route lengths, runtime, or exceptions. Subsequent candidates can modify the strategy using previous design explanations and actual results. After the fifth iteration, the model summarizes that segment of the trajectory, recording useful patterns and errors in working notes while retaining the current best code. This describes the reported protocol, not an invented improvement at a particular iteration.

After the budget of 820 candidates is exhausted, the function selected by training performance runs on independent test sets of 64 instances each at sizes 50, 100, and 200. Each city-selection step now calls the generated Python function rather than the LLM. Two actual programs in Appendix F.1 illustrate the breadth of the search space: GPT-4.1-nano discovers a dynamically weighted nearest-neighbor rollout, while the GPT-5-mini example combines minimum-spanning-tree information, candidate prefiltering, normalized insertion regret, and limited lookahead. These are search outputs, not predefined SimpleEvol modules, and two code examples cannot establish a general causal relationship.

Loss & Training

There is no gradient training or update to LLM parameters; “training” means repeated program evaluation and selection. Each framework–model combination has three independent runs, with default temperature 1.0 and a common budget of 820 heuristics. CVRP's ACO uses 30 ants and 100 iterations, and FSSP's GLS uses 1000 iterations. CVRP has only 10 training instances with 50 nodes. FSSP uses 64 training instances, each with 50 jobs and a machine count sampled uniformly from 2 to 20.

The authors also introduce two analytical metrics. AHI describes only the outer orchestration covered by its counting rules: \(M\) counts stateful components that independently select or route candidates, \(K\) counts LLM invocation types with different search roles, and \(Q\) is the total number of calls averaged across models on a baseline task. Initialization is not a separate invocation type, and components that merely store or format context are not counted separately in \(M\).

\[ \mathrm{AHI}(\mathcal A)=M+K+\log_{10}(1+Q). \]

Under the authors' convention, SimpleEvol has one model component and two invocation types, generation and compression. Its mean TSP call count is 1001, giving AHI 6.001. AHI is an author-defined descriptive index, not an objective instrument measuring all priors. Solvers, interfaces, evaluation data, prompt requirements, and elite retention may affect outcomes without separately increasing the score under these rules.

The model-capability proxy aggregates MMLU-Pro, IFBench, AIME 2025, and LiveCodeBench. It uses the corresponding scores of the weakest model, GPT-4o-mini, as the baseline and takes the geometric mean of score ratios:

\[ I(m)=\left(\prod_{b\in\mathcal B}\frac{s_{m,b}}{s_{m',b}}\right)^{1/|\mathcal B|}. \]

This supports cross-model comparison rather than defining an absolute unit of actual intelligence. Performance first computes each instance's relative gap, \((J-J^*)/J^*\), then averages across runs and test sizes. TSP references come from an LK/LKH-family solver, CVRP references from DeepACO, and FSSP uses lower bounds for synthetic instances and optimal or best-known values for Taillard. Gaps across these tasks therefore cannot all be interpreted as strict optimality gaps.

\[ P(\mathcal A,m)=\frac{1}{\overline g(\mathcal A,m)+\epsilon},\qquad P(\mathcal A,m)\approx\alpha_{\mathcal A}I(m)+\beta_{\mathcal A},\qquad \mathrm{ICE}(\mathcal A)=\alpha_{\mathcal A}. \]

ICE is the regression slope above, not a computational-cost efficiency ratio, a causal effect, or a law of actual intelligence growth. Taking the reciprocal of gap amplifies changes in the low-gap regime. Capability benchmarks, reference solutions, the stabilizing constant, and the model set can all affect the slope. Comparisons should therefore use the same task and metric definition rather than directly ranking TSP and CVRP by their ICE magnitudes.

Key Experimental Results

Main Results

The following values come from main-text Tables 2 and 3 and Appendix F.3; higher ICE means a steeper fitted trend. MCTS-AHD is an additional appendix baseline rather than an original member of the main four-framework comparison.

Framework	AHI	TSP ICE	CVRP ICE
FunSearch	6.915	1.8174	5.4381
EoH	8.919	1.5082	3.6572
ReEvo	9.112	0.8230	2.0824
MCTS-AHD	10.215	0.7525	1.5376
SimpleEvol	6.001	2.1941	6.2128

With GPT-5-mini fixed, the next table reports gaps at each test size; lower is better. TSP and CVRP use different reference sources, so their task difficulty cannot be compared through these values. Every entry is averaged over three independent runs.

Task and size	FunSearch	EoH	ReEvo	SimpleEvol
TSP, 50	5.50%	6.76%	7.98%	4.77%
TSP, 100	7.33%	8.44%	10.06%	6.47%
TSP, 200	10.35%	10.56%	12.10%	9.49%
CVRP, 50	1.04%	0.71%	0.49%	0.34%
CVRP, 100	4.83%	6.70%	5.98%	4.31%
CVRP, 200	4.46%	4.28%	4.38%	4.26%

At CVRP size 200, 4.26% differs from EoH's 4.28% by only 0.02 percentage points; not every win should be described as a large margin. SimpleEvol's advantage includes both the cross-model trend and concrete results under this backbone, but does not imply victory under every backbone.

Ablation Study

The ablation uses GPT-4.1-nano at size 50. Parentheses report the standard deviation of objective values, not of gaps. The source's reported values are retained rather than replaced with the appendix's detailed main-experiment results.

Config	TSP50 gap (objective-value std.)	CVRP50 gap (objective-value std.)
Default SimpleEvol	10.00% (0.1020)	3.08% (0.1643)
Without summarization	13.24% (0.0711)	7.38% (0.2826)
Without meta-information	11.67% (0.0477)	6.01% (0.1243)
Without best-candidate retention	14.56% (0.0036)	11.49% (0.1345)
Compress every 10 iterations	12.88% (0.0942)	6.01% (0.2381)

Relative to the default configuration, removing best-candidate retention increases TSP/CVRP gaps by 4.56/8.41 percentage points; removing summarization increases them by 3.24/4.30 percentage points. The default five-iteration compression interval outperforms ten iterations, but this supports only the tested configuration, not universal optimality of five iterations across models and tasks.

Key Findings

• The advantage extends beyond the terminal budget, but is not universal early in search. At 200 evaluations, SimpleEvol's TSP/CVRP ICE is 1.403/3.281; at 400 it is 1.835/4.028; at 600 it is 2.436/6.137. At 50 evaluations, EoH's TSP ICE of 1.393 exceeds SimpleEvol's 0.936; at 100, FunSearch's CVRP ICE of 2.430 exceeds SimpleEvol's 2.215.
• Statistical evidence varies by comparison. Across 10000 Bayesian-bootstrap replicates, the probability that SimpleEvol's ICE difference against FunSearch is positive is 85.5% for TSP and 79.1% for CVRP; against ReEvo it is 97.6%/99.7%. Leading point estimates do not automatically provide equally strong statistical support for every comparison.
• Generalization does not obey a simple stronger-model-is-better rule. On 15 TSPLIB instances, the SimpleEvol heuristic found with GPT-4.1-nano achieves a mean gap of 10.26% and 8 first-place results. On FSSP's Taillard benchmark, it achieves the best performance score under 8/10 backbones, but all frameworks have negative cross-model fitted slopes, showing that improved adaptation to synthetic training data need not improve out-of-distribution transfer.
• The common budget concerns candidates, not resource consumption. Mean TSP call counts are 821 for FunSearch, 828 for EoH, 1293 for ReEvo, and 1001 for SimpleEvol. SimpleEvol uses 4.517M input tokens, more than the other three. Its TSP runtime is 10.55 hours versus 5.23/3.60 hours for EoH/ReEvo, so it is not uniformly fastest or cheapest.

Highlights & Insights

• Framework evaluation includes whether model upgrades help. A final score under one backbone can obscure framework–model interaction; cross-model curves make that interaction inspectable. Slope and average performance remain different dimensions, and both should be reported.
• Memory compression manages search state rather than merely saving tokens. Working notes preserve failure types and algorithmic structures, while elite code supplies an executable anchor. The transferable design is this combination, not periodic summarization without actual evaluation and the best implementation.
• A simple outer loop need not produce simple algorithms. A relatively unconstrained loop can generate complex programs using topology, insertion strategies, and lookahead. Complexity moves from fixed human orchestration into model-discovered candidates rather than disappearing.

Limitations & Future Work

• AHI has limited coverage. Only a few frameworks are compared, and the authors define component boundaries, invocation types, and weights. Testing 216 weight combinations strengthens robustness under that counting convention, but does not eliminate insufficiently measured priors in evaluators, prompts, and underlying solvers.
• ICE is observational regression. The ten models also differ in price, reasoning settings, speed, and training background, so a slope cannot be interpreted as the causal benefit of removing a component. Future experiments could manipulate individual orchestration variables under strict cost budgets and report uncertainty alongside mean gaps.
• Out-of-distribution results restrict extrapolation. Negative slopes on FSSP's Taillard benchmark directly warn that stronger models may exploit training-distribution features more effectively. Cross-size and cross-distribution training instances, plus tests with stochastic or surrogate evaluation feedback, would further examine robustness.
• The source contains reporting differences that should not be silently reconciled. The main text says TSP references are computed by LKH-3, whereas Appendix C.4 specifies elkai's LK implementation. Default ablation gaps are 10.00%/3.08% for TSP/CVRP, while the detailed main results for GPT-4.1-nano are 10.16%/3.19%, without an explanation of the difference. Some MMLU-Pro raw scores and normalized ratios in Table 5 are also inconsistent: the baseline is 64.8 and GPT-4.1-nano scores 65.7, yet its listed ratio is 1.04. This note cites the authors' ICE rather than recalculating and correcting it.
• Initialization and release descriptions also require verification. The appendix says SimpleEvol does not require seed heuristics, but also states that the FSSP seed is used for all AHD methods; seed-free operation across all three tasks cannot be asserted. The abstract provides a code link, while the checklist still promises release for the final paper. The paper's link is retained without claiming that the repository has been verified for reproducibility.

Related Work & Insights

• vs FunSearch: FunSearch manages multiple exploratory directions through islands, program clusters, and sampling; SimpleEvol accumulates search information through a single trajectory and compressed experience. The latter reduces external candidate routing, while the former retains explicit diversity mechanisms. The ICE comparison does not establish the same ordering for every program-search task.
• vs EoH / ReEvo: EoH prescribes evolutionary operations, and ReEvo additionally separates reflection calls; SimpleEvol delegates improvement decisions to the same model. Its ablation also shows that relaxing operator constraints must be paired with reliable feedback and elite retention, not reduced to removing all engineering.
• vs MCTS-AHD: Tree search provides explicit branch selection and path reasoning, with higher AHI and lower ICE in the appendix comparison. Further study could test whether explicit exploration structure becomes more useful with weaker models, smaller budgets, or noisier evaluation.
• vs neural combinatorial optimization: Neural combinatorial optimization typically trains a model to construct or improve solutions; this work searches for programs called by fixed solvers. Cross-distribution training may help reduce heuristic overfitting, but the training and inference costs of the two paradigms should not be conflated.

Rating

• Novelty: 4/5. The main contribution is the cross-model analytical perspective and minimal comparison framework, not a new combinatorial optimization operator.
• Experimental Thoroughness: 4/5. Ten backbones, three tasks, ablations, and robustness analyses are included, but sample size, cost fairness, and reporting differences constrain the conclusions.
• Writing Quality: 3/5. The central loop is clear, but “almost no priors” needs to be distinguished from the actual roles of elite retention and surrounding solvers.
• Value: 4/5. A useful lightweight AHD baseline for LLM upgrades and a starting point for studying memory, feedback, and orchestration constraints.