Paper deep dive

MuEvo: LLM-Driven Evolution of Multi-Heuristic Ensemble

Haoze Lv, Ning Lu, Shengcai Liu, Shaofeng Zhang, Ke Tang

Year: 2026Venue: arXiv preprintArea: cs.NEType: PreprintEmbeddings: 137

Intelligence

Status: not_run | Model: - | Prompt: - | Confidence: 0%

Entities (0)

No extracted entities yet.

Relation Signals (0)

No relation signals yet.

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Large language model-based automated heuristic design (LLM-AHD) has shown strong potential in discovering effective heuristics for combinatorial optimization problems. However, existing methods primarily optimize a single heuristic, whereas practical optimization frameworks often rely on multiple interacting components. Directly extending single-heuristic methods is challenging because early component selection can overlook components with late potential, while independent evolution ignores inter-component dependencies. We propose MuEvo, an LLM-driven framework for evolving heuristic ensembles under ensemble-level feedback. MuEvo combines Dynamic Component Management, which uses short-budget probing and a reversible lifecycle to revise component priorities throughout the search, with LLM-Driven Co-Evolution, which coordinates component populations through Multi-Ensemble Evaluation, Cross-Component Information Sharing, Relation-Guided Pair Evolution, and Adaptive Budget Allocation. We evaluate MuEvo on selection hyper-heuristics and componentized ant colony optimization across four combinatorial optimization domains. Results show that MuEvo consistently improves human-designed frameworks and outperforms representative multi-component extensions of state-of-the-art LLM-AHD methods, demonstrating its effectiveness across both controller-mediated heuristic pools and functionally differentiated algorithmic components.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

135,353 characters extracted from source content.

Expand or collapse full text

MuEvo: LLM-Driven Evolution of Multi-Heuristic Ensemble Haoze Lv 1∗ , Ning Lu 1,2∗ , Shengcai Liu 1† Shaofeng Zhang 1 , Ke Tang 1 1 Guangdong Provincial Key Laboratory of Brain-Inspired Intelligent Computation, Department of Computer Science and Engineering, Southern University of Science and Technology, Shenzhen 518055, China 2 The Hong Kong University of Science and Technology liusc3@sustech.edu.cn Abstract Large language model-based automated heuristic design (LLM-AHD) has shown strong potential in discovering ef- fective heuristics for combinatorial optimization problems. However, existing methods primarily optimize a single heuris- tic, whereas practical optimization frameworks often rely on multiple interacting components. Directly extending single- heuristic methods is challenging because early component se- lection can overlook components with late potential, while independent evolution ignores inter-component dependen- cies. We propose MuEvo, an LLM-driven framework for evolving heuristic ensembles under ensemble-level feedback. MuEvo combines Dynamic Component Management, which uses short-budget probing and a reversible lifecycle to re- vise component priorities throughout the search, with LLM- Driven Co-Evolution, which coordinates component popula- tions through Multi-Ensemble Evaluation, Cross-Component Information Sharing, Relation-Guided Pair Evolution, and Adaptive Budget Allocation. We evaluate MuEvo on selection hyper-heuristics and componentized ant colony optimization across four combinatorial optimization domains. Results show that MuEvo consistently improves human-designed frame- works and outperforms representative multi-component ex- tensions of state-of-the-art LLM-AHD methods, demonstrat- ing its effectiveness across both controller-mediated heuristic pools and functionally differentiated algorithmic components. Introduction Given the wide applications of combinatorial optimization problems (COPs) in real world, designing effective heuris- tics has received significant attention (Matai, Singh, and Mit- tal 2010; Rajendran 1993). However, the traditional manual design process relies heavily on domain knowledge and in- volves costly trial-and-error loops (Desale et al. 2015). To address these issues, automated heuristic design (AHD) has been studied as a promising approach to simplify the design process (Burke et al. 2010). Traditional AHD approaches, such as genetic program- ming, automatically design heuristics by searching in a pre- defined space (Langdon and Poli 2013; Mei et al. 2022). ∗ These authors contributed equally. † Corresponding author. Copyright © 2027, Association for the Advancement of Artificial Intelligence (w.aaai.org). All rights reserved. </> </> Si ngle-Heuristi c Algori thm Fra mework Mul ti-Heuristi c Algori thm Fra mework </></> </></> LLM-AHD LLM-AHD </> Heu ri stic Performan ce (a) SingleBatchSplitMuEvo (Ours) 3.0 3.5 4.0 4.5 5.0 Optimality Gap (%) Human Design Fixed pre-search Flowshop Domain Performance 0.01% 0.16% 1.24% 0.43% (b) Figure 1: Existing LLM-AHD methods do not explicitly support dynamic coadaptation in multi-heuristic frame- works. (a) Existing methods primarily design a single heuris- tic, whereas practical optimization frameworks often rely on multiple interacting heuristics that jointly determine the search behavior. (b) Performance of ReEvo-based Single, Batch, and Split extensions under fixed pre-search, com- pared with Human Design and MuEvo on Flowshop Prob- lem. Lower values indicate better performance. However, the predefined search spaces and operator sets still rely on human knowledge (Liu et al. 2024). Recent stud- ies have shown that large language models (LLMs) offer new approaches for AHD, demonstrating superior perfor- mance with minimal reliance on expert knowledge (Romera- Paredes et al. 2024; Liu et al. 2024; Novikov et al. 2025). They maintain a population of heuristic code snippets and employ LLMs as crossover or mutation operators to generate new variants (Romera-Paredes et al. 2024). However, existing LLM-AHD methods primarily optimize a single heuristic (Romera-Paredes et al. 2024; Ye et al. 2024), whereas practical optimization frameworks often rely on multiple functionally distinct heuristics that jointly de- termine search behavior. For example, memetic algorithms may employ separate heuristics for initialization, crossover, and local search (Tang, Mei, and Yao 2009; de Carvalho, Özcan, and Sichman 2021). We refer to a collection of such jointly operating heuristics within an algorithmic framework as a heuristic ensemble. Recent work has begun to extend LLM-AHD to multiple components, for example through fixed pre-search that retains a subset for subsequent evolu- tion (Sun et al. 2025). This strategy faces two limitations: arXiv:2608.03636v1 [cs.NE] 4 Aug 2026 components evaluated only in the initial ensemble may be underestimated, and evolving the retained components with- out explicit coordination may overlook their dependencies. As illustrated in Figure 1, our controlled ReEvo-based Single, Batch, and Split extensions show inconsistent performance under fixed pre-search, whereas MuEvo achieves the lowest optimality gap. To address these challenges, we propose MuEvo, an LLM- driven method for evolving heuristic ensembles in multi- heuristic algorithm frameworks. MuEvo integrates Dynamic Component Management, which uses short-budget prob- ing and a feedback-driven lifecycle to allow initially un- derestimated components to re-enter the search, with LLM- Driven Co-Evolution, which maintains component-wise pop- ulations and coordinates their evolution through ensemble- aware evaluation, cross-component collaboration, and adap- tive budget allocation. Together, these mechanisms transform one-shot component selection and isolated optimization into a dynamic co-evolutionary process driven by ensemble-level feedback. We evaluate MuEvo on two multi-component frame- works with distinct interaction structures: selection hyper- heuristics (SHHs), where a high-level controller dynamically invokes low-level heuristics (LLHs) from a largely peer-level pool (de Santiago Junior, Özcan, and de Carvalho 2020; Qin et al. 2021), and componentized ant colony optimization (ACO), where components at different workflow stages ex- hibit structured dependencies (Dorigo, Maniezzo, and Col- orni 1996). Across four COP domains, MuEvo generates competitive heuristic ensembles under both interaction struc- tures, reducing the optimality gap of the strongest LLM-AHD baseline from 6.26% to 5.24% on TSP and from 3.51% to 3.24% on Flowshop. Our main contributions are summarized as follows: • We systematically propose the problem of multi-heuristic LLM-AHD, highlighting the importance and challenges of evolving multiple heuristics. • We propose MuEvo, which combines Dynamic Com- ponent Management with LLM-Driven Co-Evolution to revise component priorities using subsequent ensemble feedback and promote coadaptation across component populations. • We conduct comprehensive experiments across SHH and componentized ACO frameworks covering four combi- natorial optimization domains, demonstrating strong per- formance as well as generalization across high-level con- trollers and LLM backbones. Preliminaries and Related Work Problem Definition Let P be the COP of interest, and let D denote the dis- tribution over its instances. For each component position i, let C i represent the space of syntactically correct and ex- ecutable heuristic code compatible with that position. We define F as an algorithm framework (e.g., an SHH frame- work). When instantiated with an ordered heuristic ensemble E = (h 1 ,...,h N ) ∈ Q N i=1 C i , where each h i ∈ C i , the framework solves an instance I ∼ D to produce a feasible solution y. Multi-Heuristic AHD. The objective of Multi-Heuristic AHD is to identify an optimal heuristic ensemble E ∗ that minimizes the expected objective value over the distribution D: E ∗ = argmin E∈ Q N i=1 C i E I∼D [Q(F (E ),I)],(1) where Q(F (E ),I) quantifies the objective value of the so- lution generated by the framework instantiated with E on instance I, with lower values indicating better performance. Single-Heuristic AHD as a Special Case. Single- heuristic AHD corresponds to the special case N = 1. Let E = (h) with h∈ C 1 ; then Multi-Heuristic AHD reduces to h ∗ = arg min h∈C 1 E I∼D [Q(F ((h)),I)],(2) which is exactly the single-heuristic AHD objective. This formulation highlights that Multi-Heuristic AHD searches over the joint component space Q N i=1 C i , which reduces to C N when all components share the same code space. More importantly, the utility of each component depends on its collaborators, making the ensemble objective generally non- separable. LLM-AHD LLM-based AHD treats LLMs as search operators for gen- erating executable heuristics, with solver performance guid- ing iterative refinement. FunSearch and EoH established this paradigm, while ReEvo, MCTS-AHD, and PathWise ex- tended it with reflection, tree search, and model-based plan- ning, respectively (Romera-Paredes et al. 2024; Liu et al. 2024; Ye et al. 2024; Zheng et al. 2025; Gungordu, Xiong, and Fekri 2026; junhao qiu et al. 2026). It has since been applied to scheduling, MILP, and SAT (Li et al. 2025; Zhang et al. 2025; Chen and Li 2025). While most LLM-AHD meth- ods remain centered on a single heuristic, several recent stud- ies have begun to extend this paradigm to multiple heuristics or components, albeit with limited support for their coad- aptation. VRPAgent jointly designs two routing operators but does not maintain component-wise populations (Hottung et al. 2025). AutoModSAT uses fixed pre-search to select SAT-solver functions and restricts subsequent evolution to the retained subset, without explicitly modeling their coad- aptation (Sun et al. 2025). EoH-S constructs a portfolio of separate heuristic–framework pairs (Liu et al. 2026). CoEvo- AHD co-evolves two component-specific operator popula- tions for bi-component coupled optimization and evaluates their interaction under the full problem objective, but its formulation is designed for two-component problem struc- tures (Kuang et al. 2026). In contrast, MuEvo targets broader multi-component algorithm frameworks and co-evolves mul- tiple interdependent heuristics through component-specific populations. Multi-Heuristic Frameworks We study multi-heuristic LLM-AHD in two structurally distinct frameworks: selection hyper-heuristics (SHHs) and componentized ant colony optimization (ACO). In SHHs, (a ) Fi xed Pr e-search Late potential missed Unexplored Variants ℎ ℎ ℎ Fixed Top-k at Irr ev ersible ℎ ℎ ℎ ℎ ℎ (b) Spl it Evolution ℎ LLM Evolution LLM Evolution ℎ ℎ ℎ ℎ Ignore Relations In ter-r el ations ignored (c) Emergence of LLH's potentia l in evolved ensemble ℎ ℎ ℎ ... Ini t Ensembl e Candidate ℎ ℎ ... Evolved Ensembl e Candidate ℎ ℎ Ensembl e Evolve ∆= -0.0145 < 0∆= +0.0624 > 0 Reject Accept Figure 2: Limitations of fixed selection and independent evolution. Fixed pre-search may miss late potential, while independent evolution ignores component dependencies. In TSP-SHH, the sameh ′ 8 candidate degrades the initial ensem- ble but improves the evolved one. a high-level controller adaptively selects low-level heuristics (LLHs) from a predefined pool (Burke et al. 2013; Drake et al. 2020). Our SHH testbed follows the CHeSC 2011 HyFlex in- terface, with domain-specific LLH pools and multiple high- level controllers (Ochoa et al. 2012). In componentized ACO, the classical Ant System uses pheromone trails and problem- dependent heuristic information to guide stochastic solution construction, with all ants reinforcing their solutions (Dorigo, Maniezzo, and Colorni 1996). Nine replaceable components incorporate mechanisms from later ACO variants, includ- ing ACS-style candidate lists and local pheromone updates, rank-based and best-so-far reinforcement, stagnation control, and elite-solution memory (Dorigo and Gambardella 1997; Bullnheimer, Hartl, and Strauss 1999; Stützle and Hoos 2000; Guntsch and Middendorf 2002). Together, the two frame- works capture controller-mediated interactions among peer LLHs and structured dependencies across algorithmic stages. Complete definitions and implementation details for the SHH and ACO frameworks are provided in Appendices A and B, respectively. Methodology In this section, we present MuEvo to address two key chal- lenges in multi-heuristic design: the premature exclusion of promising components and overlooked inter-component dependencies. As illustrated in Figure 3, MuEvo addresses these challenges by combining Dynamic Component Man- agement with LLM-Driven Co-Evolution. We first motivate this design and then detail the two core mechanisms of MuEvo. Motivation and Method Overview Recent multi-component LLM-AHD work uses fixed pre- search to retain a subset of components for later optimiza- tion (Sun et al. 2025). A natural extension is then to evolve the retained components independently while freezing the rest, yielding the two-step pipeline shown in Figure 2(a–b). Despite its efficiency, this pipeline has two limitations. Late potential missed. Components are ranked only in the initial ensemble, although their utility may change as their col- laborators evolve; irreversible Top-k selection can therefore discard components whose potential emerges later. Inter- component dependencies ignored. Independent evolution neglects synergy, redundancy, and conflict among compo- nents, so individually improved components may still form a weak ensemble. Figure 2(c) provides a concrete observed case from TSP-SHH: the same h ′ 8 candidate increases the gap by 0.0145 percentage points in the initial ensemble, but reduces it by 0.0624 percentage points after the ensemble evolves. This sign reversal shows that a component update judged unpromising in the initial ensemble may exhibit po- tential later, while its utility varies with the state of the en- semble, providing direct evidence of inter-LLH dependencies and supporting the two motivations above. MuEvo addresses these limitations through Dynamic Component Management and LLM-Driven Co-Evolution. The former combines short-budget component probing with a reversible lifecycle to revise component priorities as new evidence emerges, while the latter coordinates compo- nent populations through Multi-Ensemble Evaluation, Cross- Component Information Sharing, Relation-Guided Pair Evo- lution, and Adaptive Budget Allocation. The following two subsections detail these mechanisms. Dynamic Component Management Fixed pre-search converts an early ranking from the initial en- semble into an irreversible Top-k decision, even though com- ponent utility may change as the ensemble evolves. MuEvo instead combines short-budget component probing with a feedback-driven lifecycle to preserve such late potential. As summarized in Algorithm 1, it probes all valid components, initializes them as Active or Inactive (lines 3-4), and up- dates their states and evolution priorities from subsequent co-evolution outcomes (line 19), allowing underestimated components to re-enter the search. Short-budget component probing. To estimate initial im- provement potential, MuEvo briefly evolves each component under the same probing budget while holding its collabora- tors fixed. Let f 0 i denote the ensemble fitness before probing h i and f ∗ i the best fitness observed during the probe. Since lower fitness is better, the probing score is defined as S probe i = f 0 i − f ∗ i .(3) A larger score indicates greater improvement potential under the fixed probing budget. Dynamic component lifecycle. Probe scores provide only initial evidence and therefore determine reversible priori- ties rather than permanent eligibility. MuEvo ranks all valid components by S probe i , initializes the top K A as Active and the remainder as Inactive, and reserves regular evolu- tion for Active components while retaining Inactive ones for later reactivation. State transitions are driven by ensemble- level feedback. An Active component with τ reject consecu- tive Multi-Ensemble Evaluation rejections is deactivated for ℎ ... ℎ 1. Ini tial Pool No li fecycle states 2. Short-Budget Component Probi ng Explore & evaluat e to initi al ize stat es ℎ ... 3. Ini tialized Ensembl e () ℎ ... 4. Co-evolution Loop 5. Final Ensemble ∗ ℎ ... Realloc ate budget and continue Se lect, R ef ine, Ev al uate, Update Zoom-in: one evolution step (→ ) (a) Target Selecti on ℎ ℎ ℎ ... (d ) Feedback Updates Adaptive Budget Alloca ti on （select one） ℎ ... reactivate deactivate ActiveInactive (b ) Cro s-Component In fo rmati on Shari ng and Refi nement Relation Context Constructi on Current co mponen t implemen tations Context-dep en den t improvemen t vec to r ∆ Accepted / r ej ected rep lacemen t his to ries Collaborator ver sio ns from relation memory Summarized re lation context Reflecti on-Guided Refinement Selected target component or pair ℎ ℎ re lation context Reflecti on-guided crossover and mutati on Refined candidate implementation ℎ (c) Multi-Ensemble Evalu ati on Best ( ) In iti al ( ) Secondary ( ) compute improvements ∆ ∆ ∆ ∆>0 >0 Accept or Reject ac ce pted ca ndid ate updates th e glo bal ensemble ℎ Current Ensembl e ActiveInactive Rel ati on-Guided Pair Selection （evidence-supported） Accepted onlyEvery outcome Global ensemble rep lacemen t Collaboration co ntext update Lif ecycle update (activate/deactivate) Relation memory update Alloca tion statistics update ℎ ℎ ℎ ＋ or ℎ ＋ / Figure 3: Overview of MuEvo. Dynamic Component Management retains all valid components in a reversible lifecycle, while LLM-Driven Co-Evolution combines Multi-Ensemble Evaluation, Cross-Component Information Sharing, Relation-Guided Pair Evolution, and Adaptive Budget Allocation. L cool rounds, provided that at least one other Active com- ponent remains, and cannot be selected or reactivated dur- ing cooldown. When global stagnation reaches τ stag and at least τ int rounds have elapsed since the previous activation, the highest-priority non-cooled Inactive component is pro- moted to Active and force-selected for one round. Activation priority favors fewer evaluation rejections, higher probing scores, larger historical replacement gains, and fewer prior activations. An accepted replacement clears the component’s rejection and cooldown records and resets global stagnation. LLM-Driven Co-Evolution LLHs in a multi-heuristic system are often interdependent, so optimizing one in isolation may weaken the resulting ensem- ble. Existing LLM-AHD methods provide limited support for such component-level coadaptation. Cooperative coevolu- tion offers a natural formulation by decomposing the system into subcomponents, maintaining a population for each, and coordinating their evolution to promote coadaptation (Yang, Tang, and Yao 2008). MuEvo instantiates this formulation by treating each LLH as a subcomponent and maintaining a ded- icated population for it. The within-population evolutionary process follows the reflective evolution design of ReEvo (Ye et al. 2024), employing reflection-guided crossover and muta- tion to refine heuristic code. As summarized in Algorithm 1, Adaptive Budget Allocation selects an Active LLH for evolu- tion, while Relation-Guided Pair Evolution periodically se- lects an evidence-supported pair (line 10). Cross-Component Information Sharing incorporates relation evidence into the evolutionary context (line 11), and Multi-Ensemble Evalu- ation determines whether the resulting candidate enters the global ensemble (line 13). An accepted replacement updates the global ensemble and collaboration contexts (line 16-17), while every evaluation outcome updates the component life- cycle and relation memory (line 19), forming a closed loop in which evidence from one population guides the subsequent evolution of others. The following subsections detail these mechanisms. Multi-Ensemble Evaluation. A candidate component must be evaluated within a complete ensemble, yet a sin- gle collaborator configuration may favor context-specific im- provements. MuEvo therefore evaluates each candidate in three representative collaboration contexts: the current Best ensemble, the fixed Initial ensemble, and a Secondary ensem- ble selected from the archive based on quality and diversity. To keep the evaluation cost fixed, the same per-candidate solver-run budget is shared across the three contexts, with the detailed allocation provided in Appendix C. After within- population evolution proposesh ′ i , its improvement in context k is defined as ∆ k i = f (E k )− f (E k [h i ← h ′ i ]),(4) and aggregated as R i = X k w k ∆ k i + λ min min k ∆ k i − λ var Std(∆ k i ). (5) The three terms capture weighted improvement, worst- context performance, and cross-context consistency, respec- tively. A candidate is accepted only if ∆ Best i > 0 andR i > 0. Jointly evolved pairs are evaluated analogously, with both replacements inserted into each context and accepted or re- jected together. The context-dependent improvement vector ∆ i = [∆ Best i , ∆ Initial i , ∆ Secondary i ] is retained as evidence for subsequent co-evolution. Cross-Component Information Sharing. Components may be synergistic, redundant, or conflicting, so evolving a target component requires information about the rest of the ensemble. Cross-Component Information Sharing con- structs this context from current implementations and multi- ensemble feedback. Before refining h i , MuEvo summarizes the functional roles and dependencies of the current compo- nents, while relation memory stores, for each pair, inferred dependencies, collaborator versions associated with accepted and rejected replacements, and historical context-dependent gains. Together with∆ i , these records form a target-specific relation context that distinguishes robust from collaborator- specific gains and conditions the LLM-based refinement of h i , allowing evidence from one component population to guide the evolution of others. Relation-Guided Pair Evolution. To further promote coadaptation among interacting components, Relation- Guided Pair Evolution jointly refines an evidence-supported pair as a cooperative unit. Every q evolution rounds, pro- vided sufficient evaluation budget remains, MuEvo ranks el- igible component pairs by combining structural dependency inferred from their current implementations with empirical interaction evidence stored in relation memory. The highest- ranked pair is jointly refined and evaluated as a single can- didate, with the detailed scoring and tie-breaking rules pro- vided in Appendix C. The resulting pair is evaluated as a single joint candidate through Multi-Ensemble Evaluation, so both components are accepted or rejected together. Adaptive Budget Allocation. Co-evolution must deter- mine which Active component should receive the next reg- ular evaluation. Adaptive Budget Allocation ranks eligible components outside cooldown according to their current improvement potential while discouraging persistent over- allocation. Except when a reactivation event force-selects a newly activated component, MuEvo assigns each eligible h i the score P i = w I I i +w V e V i +w S min z i H z , 1 +w R er i −w ρ ρ i . (6) Here, I i denotes the recent improvement rate derived from verified population fitness, e V i the normalized fitness vari- ance, and er i the normalized mean ensemble-replacement reward over the most recent H r selections; z i counts con- secutive selections since the last accepted replacement, H z controls saturation of the stagnation bonus, and ρ i is the fraction of regular evolution rounds allocated to h i . These terms jointly capture recent progress, population diversity, temporary stagnation, ensemble-level reward, and allocation frequency. MuEvo selects the component with the largest P i , refines it through reflection-guided crossover and mutation, and updates the score statistics, component lifecycle, rela- tion memory, and ensemble archive from the replacement outcome. Scheduled Relation-Guided Pair Evolution follows its own pair-selection rule and consumes the same evaluation budget. Experiments We evaluate MuEvo on SHH and componentized ACO across four combinatorial optimization domains, comparing it with human-designed defaults and representative multi- component LLM-AHD extensions, and assessing cross- controller transfer, mechanism ablations, and robustness across LLM backbones. Experimental Setup Frameworks and benchmarks. We evaluate MuEvo on SHH and componentized ACO frameworks. The SHH frame- Algorithm 1: MuEvo Overview 1: Input: FrameworkF, initial ensemble E 0 , probe budget B probe , evolution budget B evo 2: Output: Optimized ensemble E ∗ 3: P ← ProbeComponents(F,E 0 ,B probe ) 4: (A,I)← InitializeLifecycle(P) 5: E ∗ ← E 0 6: (M,C)← InitializeSearchState(E 0 ) 7: b← 0, t← 0 8: while b < B evo do 9: t← t + 1 10: J t ← SelectTargetOrPair(A,I,M,t) 11:Γ t ← BuildRelationContext(J t ,E ∗ ,M) 12: h ′ J t ← Evolve(h J t , Γ t ) 13: g t ← MultiEnsembleEvaluation(E ∗ ,J t ,h ′ J t ,C) 14: b← b + 1 15: if Accept(g t ) then 16: E ∗ ← Replace(E ∗ ,J t ,h ′ J t ) 17: C ← UpdateContexts(C,E ∗ ) 18: end if 19:UpdateLifecycleAndMemory(J t ,g t ,A,I,M) 20: end while 21: return E ∗ work uses a controller-mediated LLH pool and covers TSP, BPP, CVRP, and Flowshop, with 20/112, 25/88, 25/88, and 30/150 training/test instances from TSPLib, BPPLib, CVR- PLib, and the VRF benchmark, respectively (Reinelt 1991; Delorme, Iori, and Martello 2018; Uchoa et al. 2017; Vallada, Ruiz, and Framinan 2015). The componentized ACO frame- work comprises functionally dependent components across the optimization workflow and uses the same TSP and CVRP partitions. Framework and component details are provided in Appendices A and B, while complete instance lists are provided in Appendix G. Baselines. We compare MuEvo with the human-designed defaults, Default-SHH and Default ACO, and with rep- resentative learning-based methods where applicable: POMO (Kwon et al. 2020) for TSP and CVRP, and Deep- ACO (Ye et al. 2023) for componentized ACO. For multi- component LLM-AHD comparison, we further extend EoH, ReEvo, and MCTS-AHD. Each method performs fixed pre- search using its original search operators and feedback mech- anism, and then optimizes the selected components in three modes: Single evolves one component with the others fixed; Split evolves multiple components independently and com- bines them afterward; and Batch jointly represents and up- dates the selected components. Details of these LLM-AHD baselines and their multi-component adaptations are pro- vided in Appendix E. Training budget and MuEvo configuration. All LLM- based methods use DeepSeek-V4-Flash through its official API with temperature 0.8 and the same generation limit. Fol- lowing ReEvo’s evaluation protocol (Ye et al. 2024), each method receives 100 function evaluations (FEs) for the main evolutionary search. Before this search, MuEvo allocates 25 FEs to probe each valid component, while each LLM-AHD DomainTSPCVRP DatasetTSP-SSTSP-STSP-MTSP-LSet-ASet-BSet-PCMT MethodCost (Gap)↓Cost (Gap)↓Cost (Gap)↓Cost (Gap)↓Cost (Gap)↓Cost (Gap)↓Cost (Gap)↓Cost (Gap)↓ Default-SHH30211.7 (1.875%) 26504.9 (4.756%) 92521.4 (5.765%) 44680.6 (7.157%)1175.19 (12.26%) 1053.06 (8.871%) 645.892 (9.817%) 1051.51 (8.649%) POMO35100.4 (21.44%) 37924.0 (53.78%) 158371 (84.92%) 64956.8 (110.2%)1278.48 (24.70%) 1157.57 (20.03%) 791.792 (43.43%) 1136.62 (16.73%) EoH-Single30234.5 (2.032%) 26577.5 (4.964%) 93193.8 (7.194%) 40316.6 (17.73%)1177.4 (12.28%) 1050.93 (8.618%) 644.467 (9.116%) 1078.24 (10.86%) ReEvo-Single30000.4 (0.919%) 26136.6 (3.584%) 91530.6 (4.712%) 44542.0 (6.736%)1151.28 (9.950%) 1051.75 (8.633%) 638.179 (8.185%) 1061.09 (9.197%) MCTS-AHD-Single29957.7 (0.723%) 26033.2 (2.988%) 91524.4 (4.504%) 44462.6 (6.505%)1147.98 (9.124%) 1033.39 (6.583%) 629.938 (6.084%) 1083.44 (11.11%) EoH-Batch30131.9 (1.532%) 26456.9 (4.663%) 92488.1 (5.992%) 45195.9 (12.55%)1090.99 (4.136%) 1010.56 (4.610%) 616.367 (4.099%) 999.800 (2.730%) ReEvo-Batch30173.9 (1.700%) 26399.8 (4.390%) 92590.5 (5.675%) 44766.5 (7.865%)1148.23 (9.644%) 1046.10 (8.067%) 632.783 (7.277%) 1050.59 (7.962%) MCTS-AHD-Batch29925.8 (0.594%) 25987.6 (2.954%) 91083.4 (4.308%) 44041.8 (6.261%)1143.84 (8.714%) 1028.30 (5.998%) 630.763 (6.051%) 1084.24 (11.12%) EoH-Split30078.5 (1.316%) 26427.7 (4.381%) 92343.7 (6.044%) 40344.4 (18.21%)1143.05 (8.647%) 1025.14 (5.747%) 625.350 (5.834%) 1058.51 (8.522%) ReEvo-Split29999.5 (0.832%) 26902.8 (6.577%) 100873 (16.40%) 46035.1 (14.64%)1126.87 (7.627%) 1019.59 (5.590%) 622.092 (5.605%) 1027.11 (5.939%) MCTS-AHD-Split 30653.2 (3.182%) 26700.2 (5.798%) 90057.4 (15.63%) 41966.0 (16.45%)1087.38 (4.059%) 1000.03 (3.592%) 609.308 (3.968%) 1046.70 (7.332%) MuEvo29935.8 (0.651%)25815.0 (2.141%)90672.5 (3.657%)43909.0 (5.237%)1057.14 (1.387%)985.174 (2.135%)603.870 (2.300%)949.127 (4.213%) DomainBPPFlowshop DatasetFalkenauer-UFalkenauer-TScholl-3SchwerinVRF20VRF40VRF60VRF100 MethodBins (Gap)↓Bins (Gap)↓Bins (Gap)↓Bins (Gap)↓Makespan (Gap)↓ Makespan (Gap)↓ Makespan (Gap)↓ Makespan (Gap)↓ Default-SHH190.667 (0.754%) 82.9958 (6.484%) 58.1800 (3.530%) 20.3467 (2.166%)1724.40 (0.173%) 2759.63 (1.585%) 3796.15 (1.858%) 8200.53 (3.663%) EoH-Single190.367 (0.592%) 79.2250 (2.837%) 57.0400 (1.501%) 20.1133 (0.963%)1724.69 (0.199%) 2753.01 (1.358%) 3800.1 (1.955%) 8278.57 (4.633%) ReEvo-Single 189.688 (0.299%) 79.1542 (2.822%) 56.5100 (0.556%) 20.3967 (2.387%)1724.31 (0.170%) 2759.60 (1.584%) 3796.06 (1.856%) 8201.28 (3.676%) MCTS-AHD-Single189.996 (0.455%) 81.4208 (5.009%) 58.1700 (3.512%) 20.4500 (2.686%)1722.25 (0.058%) 2745.26 (1.087%) 3780.26 (1.452%) 8234.87 (4.095%) EoH-Batch189.867 (0.454%) 78.4833 (2.321%) 56.6200 (0.749%) 20.1933 (1.362%)1724.98 (0.211%) 2760.53 (1.610%) 3800.10 (1.960%) 8262.31 (4.449%) ReEvo-Batch189.146 (0.102%) 78.5000 (2.326%) 56.4500 (0.450%) 20.1667 (1.245%)1722.71 (0.080%) 2744.34 (1.051%) 3777.29 (1.377%) 8212.45 (3.822%) MCTS-AHD-Batch189.121 (0.072%) 78.6375 (2.408%) 57.7100 (2.692%) 20.1934 (1.382%)1721.98 (0.046%) 2742.04 (0.971%) 3777.56 (1.381%) 8187.62 (3.506%) EoH-Split189.158 (0.097%) 78.5000 (2.326%) 56.4700 (0.485%) 20.1133 (0.958%)1722.98 (0.099%) 2749.81 (1.240%) 3813.03 (2.272%) 8302.73 (5.004%) ReEvo-Split190.658 (0.771%) 83.5833 (7.073%) 58.3200 (3.779%) 20.3667 (2.267%)1723.85 (0.145%) 2748.69 (1.210%) 3776.13 (1.705%) 8174.62 (4.904%) MCTS-AHD-Split190.575 (0.706%) 82.3000 (5.757%) 57.9800 (3.175%) 20.4067 (2.482%)1722.64 (0.079%) 2748.21 (1.184%) 3783.91 (1.542%) 8290.35 (4.778%) MuEvo189.017 (0.051%)78.4667 (2.159%)56.4000 (0.360%)20.0067 (0.394%)1721.54 (0.022%)2740.78 (0.938%)3771.57 (1.235%)8169.21 (3.236%) Table 1: Performance comparison across four problem domains. Values report mean cost/bins/makespan and mean gap (%). Cost and Gap are averaged over 3 independent runs. For all metrics, lower is better. DomainTSPCVRP DatasetTSP-SSTSP-STSP-MTSP-LSet-ASet-BSet-PCMT MethodCost (Gap)↓Cost (Gap)↓Cost (Gap)↓Cost (Gap)↓Cost (Gap)↓Cost (Gap)↓Cost (Gap)↓Cost (Gap)↓ Default ACO31062.8 (4.830%) 37285.0 (65.96%) 239798 (173.6%) 126947 (199.8%)1224.73 (17.51%) 1054.83 (9.589%) 693.292 (16.36%) 1105.09 (14.83%) DeepACO33417.6 (14.58%) 36788.3 (43.72%) 176989 (105.1%) 88034.6 (205.2%)2066.86 (96.97%) 1796.38 (83.81%) 922.472 (45.65%) 1241.51 (26.81%) EoH-Single31679.7 (6.759%) 29360.2 (19.24%) 130805 (55.58%) 99687.8 (158.1%)1086.55 (3.834%) 991.212 (2.804%) 610.983 (3.561%) 1023.63 (5.024%) ReEvo-Single30851.1 (3.754%) 29273.9 (17.89%) 134035 (54.51%) 65091.3 (55.53%)1084.46 (3.689%) 988.339 (2.530%) 609.597 (3.342%) 1045.62 (6.768%) MCTS-AHD-Single30763.3 (3.754%) 30280.0 (26.23%) 208238 (138.4%) 113967 (174.0%)1110.81 (6.097%) 1001.54 (3.859%) 614.353 (4.161%) 1014.24 (4.697%) EoH-Batch30416.1 (1.893%) 28853.5 (16.08%) 120525 (39.89%) 58273.3 (39.65%)1109.85 (6.071%) 998.067 (3.628%) 623.633 (5.515%) 1027.81 (5.951%) ReEvo-Batch30467.9 (2.342%) 28236.2 (13.21%) 114530 (29.11%) 72177.4 (72.10%)1085.48 (3.901%) 988.136 (2.610%) 611.561 (3.582%) 998.419 (2.970%) MCTS-AHD-Batch30745.4 (3.701%) 29691.2 (21.91%) 190046 (120.4%) 99940.9 (137.5%)1142.85 (9.130%) 1022.69 (6.013%) 640.942 (8.311%) 1065.80 (10.03%) EoH-Split30856.0 (3.773%) 29301.7 (17.52%) 109201 (26.65%) 52918.3 (26.36%)1137.64 (8.474%) 1023.26 (5.979%) 631.497 (6.570%) 1061.05 (9.467%) ReEvo-Split32248.0 (9.190%) 30328.2 (21.80%) 128112 (49.73%) 66069.2 (56.99%)1157.77 (11.02%) 1028.40 (7.035%) 633.003 (7.203%) 1027.47 (6.414%) MCTS-AHD-Split32315.3 (9.706%) 31628.0 (38.50%) 197244 (125.1%) 99932.4 (137.5%)1157.54 (10.73%) 1023.82 (6.331%) 647.133 (9.274%) 1061.06 (9.827%) MuEvo30045.4 (0.825%)26131.0 (3.233%)93933.2 (6.956%)47117.5 (17.46%)1081.74 (3.399%)993.109 (2.969%)601.588 (2.100%)980.657 (1.052%) Table 2: Performance on the componentized ACO framework. Values report mean cost and mean gap (%). Cost and Gap are averaged over 3 independent runs. For all metrics, lower is better. baseline performs its method-specific fixed pre-search with the same per-component budget. Thus, a framework with N valid components uses 25N additional FEs in the prelimi- nary stage, excluded from the 100-FE evolution budget. One FE evaluates one candidate on the full training set under a fixed solver-run budget per instance. Single-context meth- ods spend this budget in one context, whereas MuEvo shares it across three collaboration contexts; hence, each regular or pair-evolution round consumes one FE. Lifecycle thresholds, context weights, pair scheduling, and adaptive-allocation pa- rameters are reported in Appendix C. Evaluation protocol. SHH candidates are evolved with ADAPHH as the controller. Each LLM-based method is run three times with different random seeds, and the results are averaged across these runs. For both SHH and ACO, each training instance is evaluated over 10 solver runs, while each test instance is evaluated over 10 independent runs with a 300-s time limit. We report mean solution cost, bin count, or makespan, together with the mean optimality gap to the best-known solution. Dataset-level results average instance gaps within each dataset, whereas aggregated analyses use instance-count-weighted means across datasets. Experiments are conducted on a server with two AMD EPYC 9754 pro- cessors and 1024 GB of RAM. Main Results Tables 1 and 2 compare MuEvo with the human-designed de- faults and three LLM-AHD baselines under SHH and com- ponentized ACO, respectively. We examine whether MuEvo remains effective across the two frameworks despite their different component structures. SHH Results As shown in Table 1, MuEvo improves the original human-designed LLH ensemble on all 16 datasets and obtains the lowest or tied-lowest mean gap on 14. It performs best on three of the four TSP datasets, all four BPP datasets, three of the four CVRP datasets, and all four Flowshop datasets. Among the direct LLM-AHD extensions, Batch provides the strongest baseline on 11 datasets, whereas Split is competitive on several BPP and CVRP datasets but degrades markedly on medium- and large-scale TSP for ReEvo and MCTS-AHD. This instability is consistent with independently evolved LLHs becoming mismatched when recombined. MuEvo is more robust across domains, reduc- ADAPHHHAHANAHHVNSTW 0 2 4 6 8 Instance-weighted gap (%) 4.26 4.16 5.63 7.04 2.49 3.47 3.93 3.44 OriginalMuEvo Figure 4: Cross-controller generalization on TSP. Instance-weighted mean gaps of the original and MuEvo- evolved LLH ensembles under four SHH controllers. Lower is better. ing the strongest baseline gap from 6.261% to 5.237% on TSP-L and from 3.506% to 3.236% on Flowshop VRF100. ACO Results Table 2 further evaluates MuEvo when the optimized components occupy different stages of the ACO workflow. MuEvo improves Default ACO on all eight datasets and achieves the lowest mean gap on seven, cov- ering all four TSP datasets and three of the four CVRP datasets. The relative performance of the direct extensions again depends on the domain: Batch is strongest on the two smaller TSP sets, Split performs best on TSP-M and TSP- L, and Single is strongest on three CVRP sets. No fixed evolutionary mode therefore remains consistently effective as the component context changes. MuEvo instead yields the most consistent performance, including reductions from 26.65% to 6.956% on TSP-M and from 26.36% to 17.46% on TSP-L over the strongest LLM-AHD baselines. These re- sults demonstrate that MuEvo remains effective across both controller-mediated LLH pools and functionally differenti- ated components with structured dependencies. Further Analysis Cross-Controller Generalization To examine whether the evolved LLH ensemble overfits the controller used dur- ing evolution, we train MuEvo with ADAPHH and trans- fer the resulting ensemble without modification to HAHA, NAHH, and VNSTW. These CHeSC 2011 controllers em- ploy different heuristic-selection mechanisms (Mısır et al. 2012; Lehrbaum and Musliu 2012; Mascia and Stützle 2012; Hsiao, Chiang, and Fu 2012); their implementation details are provided in Appendix F. As shown in Figure 4, the evolved ensemble reduces the instance-weighted TSP gap under all four controllers, with the largest improvement occurring un- der VNSTW, from 7.04% to 3.44%. Additional results on BPP, reported in Appendix C, show the same trend across all evaluated controllers. These results indicate that the ensem- bles evolved with ADAPHH transfer effectively to unseen controllers in both TSP and BPP without modification or retraining. Ablation Studies Table 3 evaluates five key mechanisms of MuEvo on BPP-SHH and TSP-ACO. Each variant re- moves one mechanism while keeping the probing results, Method BPP-SHHTSP-ACO Gap (%)↓Gap (%)↓ MuEvo (Full)0.7780 (+0.0000) 5.855 (+0.000) w/o Dynamic Component Management0.9516 (+0.1736) 13.86 (+8.005) w/o Multi-Ensemble Evaluation0.9268 (+0.1488) 12.83 (+6.975) w/o Cross-Component Information Sharing 1.1574 (+0.3794) 9.999 (+4.144) w/o Relation-Guided Pair Evolution1.1669 (+0.3889) 12.11 (+6.255) w/o Adaptive Budget Allocation 0.8598 (+0.0818) 10.75 (+4.895) Table 3: Ablation study reporting instance-weighted gaps and absolute increases over MuEvo (in parentheses). Lower is better. LLM BPP-SHHTSP-ACO Bins (Gap)↓Cost (Gap)↓ Ori-Heuristic88.1830 (3.113%) 103922 (93.28%) DeepSeek-V4-Flash86.1887 (0.778%) 49264.5 (5.855%) Kimi-K2.686.4614 (1.192%) 48506.6 (3.588%) Qwen3.7-Plus-2026-05-26 86.2648 (0.981%) 47087.0 (5.728%) Table 4: MuEvo with different LLM backbones. Values re- port instance-weighted cost and gap (%). Lower is better. evaluation protocol, and search budget unchanged. On TSP- ACO, removing Dynamic Component Management causes the largest degradation, increasing the weighted gap from 5.855% to 13.86%. Removing Multi-Ensemble Evaluation, Cross-Component Information Sharing, or Relation-Guided Pair Evolution also substantially worsens performance, yield- ing gaps of 12.83%, 9.999%, and 12.11%, respectively. The trend is consistent on BPP-SHH, where every ablation in- creases the gap over MuEvo. Cross-Component Information Sharing and Relation-Guided Pair Evolution have the largest effects, while replacing Adaptive Budget Allocation with ran- dom selection increases the gap from 0.7780% to 0.8598%. These results demonstrate that both Dynamic Component Management and the co-evolution mechanisms are impor- tant to MuEvo. MuEvo with Different LLMs To examine the sensitiv- ity of MuEvo to the underlying LLM, we evaluate three LLM backbones on BPP-SHH and TSP-ACO under the same search and evaluation settings. All models are ac- cessed through their official APIs. As shown in Table 4, all three backbones substantially improve over the original heuristics in both settings. The best-performing model varies by framework: DeepSeek-V4-Flash achieves the lowest BPP- SHH gap of 0.778%, whereas Kimi-K2.6 achieves the lowest TSP-ACO gap of 3.588%. These results indicate that MuEvo remains effective across different LLM backbones. Conclusion In this paper, we study multi-heuristic LLM-AHD, where fixed pre-search may miss components with late potential and independent evolution neglects their dependencies. We pro- pose MuEvo, which combines Dynamic Component Man- agement to revise component priorities with LLM-Driven Co-Evolution to coordinate component populations through ensemble feedback. Experiments on SHH and componen- tized ACO across four combinatorial optimization domains show that consistently outperforms strong baselines. Cross- controller transfer and ablation studies further support its generality and core mechanisms. References Augerat, P.; Naddef, D.; Belenguer, J.; Benavent, E.; Cor- beran, A.; and Rinaldi, G. 1995. Computational results with a branch and cut code for the capacitated vehicle routing problem. Bullnheimer, B.; Hartl, R.; and Strauss, C. 1999. A New Rank Based Version of the Ant System: A Computational Study. Central European Journal of Operations Research, 7(1): 25–38. Burke, E. K.; Gendreau, M.; Hyde, M.; Kendall, G.; Ochoa, G.; Özcan, E.; and Qu, R. 2013. Hyper-heuristics: A survey of the state of the art. Journal of the Operational Research Society, 64(12): 1695–1724. Burke, E. K.; Hyde, M.; Kendall, G.; Ochoa, G.; Özcan, E.; and Woodward, J. R. 2010. A classification of hyper- heuristic approaches. In Handbook of metaheuristics, 449– 468. Springer. Chen, M.; and Li, G. 2025. DaSAThco: Data-Aware SAT Heuristics Combinations Optimization via Large Language Models. arXiv preprint arXiv:2509.12602. Christofides, N. 1979. The vehicle routing problem. Combi- natorial optimization. de Carvalho, V. R.; Özcan, E.; and Sichman, J. S. 2021. Com- parative analysis of selection hyper-heuristics for real-world multi-objective optimization problems. Applied Sciences, 11(19): 9153. de Santiago Junior, V. A.; Özcan, E.; and de Carvalho, V. R. 2020. Hyper-heuristics based on reinforcement learning, balanced heuristic selection and group decision acceptance. Applied Soft Computing, 97: 106760. Delorme, M.; Iori, M.; and Martello, S. 2018. BPPLIB: a library for bin packing and cutting stock problems. Opti- mization Letters, 12(2): 235–250. Desale, S.; Rasool, A.; Andhale, S.; and Rane, P. 2015. Heuristic and meta-heuristic algorithms and their relevance to the real world: a survey. Int. J. Comput. Eng. Res. Trends, 351(5): 2349–7084. Dorigo, M.; and Gambardella, L. M. 1997. Ant Colony System: A Cooperative Learning Approach to the Travel- ing Salesman Problem. IEEE Transactions on Evolutionary Computation, 1(1): 53–66. Dorigo, M.; Maniezzo, V.; and Colorni, A. 1996. Ant sys- tem: Optimization by a colony of cooperating agents. IEEE Transactions on Systems, Man, and Cybernetics, Part B (Cy- bernetics), 26(1): 29–41. Drake, J. H.; Kheiri, A.; Özcan, E.; and Burke, E. K. 2020. Recent advances in selection hyper-heuristics. European Journal of Operational Research, 285(2): 405–428. Falkenauer, E. 1996. A hybrid grouping genetic algorithm for bin packing. Journal of heuristics, 2(1): 5–30. Gungordu, O.; Xiong, S.; and Fekri, F. 2026. PathWise: Plan- ning through World Model for Automated Heuristic Design via Self-Evolving LLMs. arXiv preprint arXiv:2601.20539. Guntsch, M.; and Middendorf, M. 2002. A Population Based Approach for ACO. In Applications of Evolutionary Com- puting, volume 2279 of Lecture Notes in Computer Science, 72–81. Springer. Hottung, A.; Berto, F.; Hua, C.; Zepeda, N. G.; Wetzel, D.; Römer, M.; Ye, H.; Zago, D.; Poli, M.; Massaroli, S.; et al. 2025. VRPAgent: LLM-Driven Discovery of Heuris- tic Operators for Vehicle Routing Problems. arXiv preprint arXiv:2510.07073. Hsiao, P.-C.; Chiang, T.-C.; and Fu, L.-C. 2012. A vns-based hyper-heuristic with adaptive computational budget of local search. In 2012 IEEE congress on evolutionary computation, 1–8. IEEE. junhao qiu; Chen, X.; Ge, L.; Lin, L.; Lu, Z.; and Zhang, Q. 2026. Evolving Interdependent Operators with Large Lan- guage Models for Multi-Objective Combinatorial Optimiza- tion. In Forty-third International Conference on Machine Learning. Kuang, M.; Deng, X.; Lin, X.; Fan, Y.; Sun, J.; and Shi, J. 2026. LLM-Driven Co-Evolutionary Automated Heuris- tic Design for Bi-Component Coupled Combinatorial Opti- mization. arXiv preprint arXiv:2606.00718. Kwon, Y.-D.; Choo, J.; Kim, B.; Yoon, I.; Gwon, Y.; and Min, S. 2020. POMO: Policy Optimization with Multiple Optima for Reinforcement Learning. In Advances in Neural Information Processing Systems, volume 33, 21188–21198. Curran Associates, Inc. Langdon, W. B.; and Poli, R. 2013. Foundations of genetic programming. Springer Science & Business Media. Lehrbaum, A.; and Musliu, N. 2012. A new hyperheuristic algorithm for cross-domain search problems. In Interna- tional Conference on Learning and Intelligent Optimization, 437–442. Springer. Li, R.; Wang, L.; Sang, H.; Yao, L.; and Pan, L. 2025. LLM- Assisted Automatic Memetic Algorithm for Lot-Streaming Hybrid Job Shop Scheduling With Variable Sublots. IEEE Transactions on Evolutionary Computation. Liu, F.; Liu, Y.; Zhang, Q.; Tong, X.; and Yuan, M. 2026. Eoh-s: Evolution of heuristic set using llms for automated heuristic design. In Proceedings of the AAAI Conference on Artificial Intelligence, volume 40, 37090–37098. Liu, F.; Xialiang, T.; Yuan, M.; Lin, X.; Luo, F.; Wang, Z.; Lu, Z.; and Zhang, Q. 2024. Evolution of Heuristics: Towards Efficient Automatic Algorithm Design Using Large Language Model. In Forty-first International Conference on Machine Learning. Mascia, F.; and Stützle, T. 2012. A non-adaptive stochastic local search algorithm for the chesc 2011 competition. In International Conference on Learning and Intelligent Opti- mization, 101–114. Springer. Matai, R.; Singh, S. P.; and Mittal, M. L. 2010. Traveling salesman problem: an overview of applications, formula- tions, and solution approaches. Traveling salesman problem, theory and applications, 1(1): 1–25. Mei, Y.; Chen, Q.; Lensen, A.; Xue, B.; and Zhang, M. 2022. Explainable artificial intelligence by genetic programming: A survey. IEEE Transactions on Evolutionary Computation, 27(3): 621–641. Mısır, M.; Verbeeck, K.; De Causmaecker, P.; and Van- den Berghe, G. 2012. An intelligent hyper-heuristic frame- work for chesc 2011. In International Conference on Learn- ing and Intelligent Optimization, 461–466. Springer. Novikov, A.; Vu, N.; Eisenberger, M.; Dupont, E.; Huang, P.; Wagner, A. Z.; Shirobokov, S.; Kozlovskii, B.; Ruiz, F. J. R.; Mehrabian, A.; Kumar, M. P.; See, A.; Chaudhuri, S.; Holland, G.; Davies, A.; Nowozin, S.; Kohli, P.; and Balog, M. 2025. AlphaEvolve: A coding agent for scientific and algorithmic discovery. CoRR, abs/2506.13131. Ochoa, G.; Hyde, M.; Curtois, T.; Vazquez-Rodriguez, J. A.; Walker, J.; Gendreau, M.; Kendall, G.; McCollum, B.; Parkes, A. J.; Petrovic, S.; et al. 2012. Hyflex: A benchmark framework for cross-domain heuristic search. In European conference on evolutionary computation in combinatorial optimization, 136–147. Springer. Qin, W.; Zhuang, Z.; Huang, Z.; and Huang, H. 2021. A novel reinforcement learning-based hyper-heuristic for het- erogeneous vehicle routing problem. Computers & Industrial Engineering, 156: 107252. Rajendran, C. 1993. Heuristic algorithm for scheduling in a flowshop to minimize total flowtime. International Journal of Production Economics, 29(1): 65–73. Reinelt, G. 1991. TSPLIB—A traveling salesman problem library. ORSA journal on computing, 3(4): 376–384. Romera-Paredes, B.; Barekatain, M.; Novikov, A.; Balog, M.; Kumar, M. P.; Dupont, E.; Ruiz, F. J.; Ellenberg, J. S.; Wang, P.; Fawzi, O.; et al. 2024. Mathematical discoveries from program search with large language models. Nature, 625(7995): 468–475. Scholl, A.; Klein, R.; and Jürgens, C. 1997. Bison: A fast hybrid procedure for exactly solving the one-dimensional bin packing problem. Computers & Operations Research, 24(7): 627–645. Schwerin, P.; and Wäscher, G. 1997. The bin-packing prob- lem: A problem generator and some numerical experiments with FFD packing and MTP. International transactions in operational research, 4(5-6): 377–389. Stützle, T.; and Hoos, H. H. 2000. MAX–MIN Ant System. Future Generation Computer Systems, 16(8): 889–914. Sun, Y.; Ye, F.; Chen, Z.; Wei, K.; and Cai, S. 2025. Automat- ically discovering heuristics in a complex SAT solver with large language models. arXiv preprint arXiv:2507.22876. Tang, K.; Mei, Y.; and Yao, X. 2009. Memetic algorithm with extended neighborhood search for capacitated arc routing problems. IEEE Transactions on Evolutionary Computation, 13(5): 1151–1166. Uchoa, E.; Pecin, D.; Pessoa, A.; Poggi, M.; Vidal, T.; and Subramanian, A. 2017. New benchmark instances for the capacitated vehicle routing problem. European Journal of Operational Research, 257(3): 845–858. Vallada, E.; Ruiz, R.; and Framinan, J. M. 2015. New hard benchmark for flowshop scheduling problems minimis- ing makespan. European Journal of Operational Research, 240(3): 666–677. Yang, Z.; Tang, K.; and Yao, X. 2008. Large scale evolution- ary optimization using cooperative coevolution. Information sciences, 178(15): 2985–2999. Ye, H.; Wang, J.; Cao, Z.; Berto, F.; Hua, C.; Kim, H.; Park, J.; and Song, G. 2024. Reevo: Large language models as hyper-heuristics with reflective evolution. Advances in neural information processing systems, 37: 43571–43608. Ye, H.; Wang, J.; Cao, Z.; Liang, H.; and Li, Y. 2023. Deep- ACO: Neural-Enhanced Ant Systems for Combinatorial Op- timization. In Advances in Neural Information Processing Systems, volume 36, 43706–43728. Curran Associates, Inc. Zhang, Z.; Li, S.; Li, C.; Liu, F.; Chen, M.; Li, K.; Zhong, T.; An, B.; and Liu, P. 2025. DHEvo: Data-Algorithm Based Heuristic Evolution for Generalizable MILP Solving. arXiv preprint arXiv:2507.15615. Zheng, Z.; Xie, Z.; Wang, Z.; and Hooi, B. 2025. Monte Carlo Tree Search for Comprehensive Exploration in LLM-Based Automatic Heuristic Design. In Forty-second International Conference on Machine Learning. A Selection Hyper-Heuristic Framework A.1 Introduction of SHH Selection Hyper-heuristics (SHH) represent a class of high- level search methodologies designed to automate the selec- tion and application of problem-specific heuristics for solv- ing complex combinatorial optimization problems. As es- tablished in a comprehensive survey (Drake et al. 2020), the fundamental architecture of an SHH framework is defined by the "Domain Barrier." This conceptual separation decou- ples the high-level selection logic from the domain-specific data structures and Low-Level Heuristics (LLHs), ensuring that the high-level strategy remains problem-agnostic and transferable across different domains. The SHH framework typically consists of two primary algorithmic components operating above the domain barrier: • Selection Mechanism: This component is responsible for choosing the most appropriate LLH from the avail- able pool at each decision point. Modern selection mech- anisms often utilize online learning, reinforcement learn- ing, or statistical indicators to adaptively prioritize heuris- tics that demonstrate superior performance on the current instance or search phase. • Move Acceptance: Once an LLH is applied and a new candidate solution is generated, the Move Accep- tance component determines whether to accept the move. This ranges from simple deterministic rules (e.g., Only Improving) to probabilistic criteria inspired by meta- heuristics (e.g., the Metropolis acceptance criterion used in simulated annealing) to allow escape from local op- tima. We select SHH as our research framework because its ar- chitectural design provides a natural environment for evaluat- ing and optimizing multiple heuristics simultaneously. In this framework, a high-level strategy functions as a controller that dynamically selects and applies operators from a pool of pre- defined Low-Level Heuristics (LLHs) based on the current problem state and feedback information (e.g., historical per- formance, objective value improvements) passed across the domain barrier. The existence of this LLH pool makes SHH naturally compatible with the objectives of Multi-Heuristic LLM-AHD, as it allows the LLM to focus on co-evolving a diverse ensemble of operators rather than a single isolated heuristic. Furthermore, the dynamic scheduling managed by the high-level strategy leads to complex, synergistic relation- ships among the LLHs, where the utility of a specific operator is often conditional on the previous search history. Algorithm 2 summarizes the generic execution procedure. At each decision point, the selection mechanism chooses an LLH using the current search state and historical feedback. The selected LLH produces a candidate solution, which is then evaluated by the move acceptance mechanism. The re- sulting performance information is retained to guide subse- quent selections. A.2 Design Principle We implement our framework based on the standard HyFlex interface established in the CHeSC 2011 (Ochoa et al. 2012). Algorithm 2: Generic Selection Hyper-Heuristic Framework 1: Input: Instance I and LLH poolH 2: Input: Selection mechanismS, move acceptanceA, and termination ruleT 3: x← Initialize(I); x ∗ ← x; historyB ←∅ 4: whileT is not satisfied do 5: z ← ObserveState(x,x ∗ ,B) 6: h←S(H,z,B) 7: x ′ ← ApplyLLH(h,x,I) 8: b←A(x,x ′ ,z,B) 9: if b then 10: x← x ′ 11: end if 12: if f (x) < f (x ∗ ) then 13: x ∗ ← x 14: end if 15: B ← UpdateFeedback(B,h,x ′ ,b,x,x ∗ ) 16: end while 17: return x ∗ While HyFlex provides a structural foundation, existing SHH frameworks typically exhibit complex architectural struc- tures, presenting significant challenges to the direct applica- tion of LLM-AHD. For example, these heuristics frequently manipulate domain-specific solution representations directly, lacking safe data manipulation interfaces. Crucially, while such structural inconsistencies are effectively masked when combined with traditional high-level search strategies, they become critical issues when employing LLM-AHD to di- rectly optimize LLHs. Consequently, LLM-generated code is highly prone to hallucinations, resulting in invocations of non-existent methods or invalid manipulations of struc- tured data. To systematically address these challenges and enable reliable LLM-driven heuristic optimization within SHH frameworks, we propose three main design principles that transform a traditional hyper-heuristic framework into an LLM-compatible framework. Principle 1: Unified LLH Invocation Interface. To facil- itate the simultaneous evolution of multiple heterogeneous heuristics, we establish a standardized interaction protocol. In standard implementations, distinct operator types (e.g., mutation versus local search) often require divergent func- tion signatures and variable naming conventions. This incon- sistency frequently induces hallucinations, where the LLM erroneously generates code with incorrect function signa- tures or mismatched parameter definitions. We address this by enforcing a homogenized invocation schema for all Low- Level Heuristics (LLHs). This unification ensures that the LLM interacts with a consistent API surface regardless of the specific operator type being evolved, thereby effectively preventing syntax errors derived from signature mismatches during the iterative co-evolutionary process. Principle 2: Error Prevention via Validated Operation Encapsulation. Complex combinatorial solvers often rely on complex problem-specific data structures that are error- prone when directly manipulated by LLM-generated code. Naive exposure of these internal representations can lead to a cascade of runtime failures—invalid state transitions, constraint violations, or inconsistent objective updates. We address this by encapsulating all low-level data manipula- tions into validated operation interfaces that enforce domain- specific boundary checks. By restricting the LLM’s interac- tion to this validated API surface, we significantly mitigate common error patterns (e.g., out-of-bounds access, solution corruption). Principle 3: Domain-Specific Algorithmic Library. In traditional automated heuristic design approaches, LLMs are often tasked with implementing fundamental operations from scratch, which distracts their attention from high-level strate- gic reasoning and consumes valuable context budget. To ad- dress this inefficiency, we curate and modularize domain- specific fundamental heuristics (e.g., greedy insert, nearest neighbor for TSP) into a structured algorithmic library. By providing these pre-validated building blocks, the framework liberates the LLM from the burden of reimplementing basic operators for every generated heuristic. This design shift en- ables the model to focus its generative capacity on novel heuristic designs. A.3 Implementation Interfaces The controller accesses every unary LLH through apply_heuristic(heuristic_id, from_index, to_index) and every crossover through apply_heuristic_with_parents(heuristic_id, parent1_index, parent2_index, to_index). These calls copy or combine solutions in managed memory, dispatch the selected original or evolved implementation, recompute the objective when required, validate feasibility, and return the objective value stored at to_index. The code generated for unary LLHs has the domain- level contract def method(self, solution: SolutionType) -> None. It modifies the provided solution in place and cannot directly manage controller memory. Crossover code receives two parent solutions and produces the destination solution through the validated domain adapter. Consequently, the LLM-facing implemen- tation contract remains domain-specific enough to expose useful features, while the controller-facing invocation contract is identical across TSP, BPP, Flowshop, and CVRP. A.4 Low-Level Heuristics We follow the HyFlex LLH taxonomy: Mutation, Ruin- Recreate, Local Search, and Crossover. A hyper-heuristic is a high-level controller that selects or sequences LLHs across these types, so it is not itself an LLH type. The details are shown in Table 5. Mutation. Mutation heuristics perturb or reorder parts of a single solution to generate a new search state. Their changes can range from small edits, such as swapping two elements, to stronger randomization of a subsequence or complete rep- resentation. They primarily provide diversification while pre- serving the domain’s feasibility requirements. Ruin-Recreate. Ruin-Recreate heuristics remove a se- lected portion of the current solution and reconstruct the missing structure using a domain-specific insertion or pack- ing rule. By combining a disruptive removal stage with a guided rebuilding stage, they can move the search beyond neighborhoods reachable through simple mutations. Local Search. Local Search heuristics repeatedly exam- ine a structured neighborhood and apply improving moves to refine the current solution. Different operators vary in neigh- borhood definition, move evaluation, and stopping policy, providing complementary forms of intensification at differ- ent computational costs. Crossover. Crossover heuristics construct a new solution from two parent solutions by preserving and recombining useful structural information from both. Domain-specific re- pair or representation-aware recombination ensures that the resulting offspring remains valid. These operators allow the framework to exploit information distributed across multiple search trajectories. B Componentized Ant Colony Optimization Framework B.1 Introduction of ACO Ant Colony Optimization (ACO) is a population-based meta- heuristic inspired by the collective foraging behavior of ant colonies (Dorigo, Maniezzo, and Colorni 1996). A set of arti- ficial ants incrementally constructs candidate solutions using pheromone information and problem-dependent heuristic in- formation. High-quality solutions reinforce useful decisions through pheromone updates, thereby biasing later ants toward promising regions while preserving stochastic exploration. A typical ACO iteration initializes the construction state of the ants, controls the search parameters, and repeatedly se- lects feasible actions until complete solutions are obtained. The constructed solutions may then be improved by lo- cal search. Finally, the framework assesses search progress, maintains high-quality solutions, and updates the global pheromone state for the next iteration. These stages provide the execution structure for the nine components described below. B.2 Design Principle Principle 1: Fixed Component Interfaces. Each ACO com- ponent has a fixed function signature, input state, output for- mat, and default implementation. Although the components operate at different stages and serve different purposes, the framework invokes each one at a predefined point in the search process. Consequently, an individual component can focus on its own algorithmic decision without reimplement- ing the complete ACO solver. Principle 2: Trusted Domain Kernel. Instance parsing, objective evaluation, feasible-action masking, constraint val- idation, and termination checks remain within a trusted do- main kernel. The components control the ACO search deci- sions but cannot bypass the fundamental feasibility require- ments of TSP or CVRP. This separation allows component implementations to concentrate on search strategy while the framework preserves valid solver execution. B.3 ACO Components The nine components are organized by their positions in the ACO workflow. H1–H3 initialize search information and Table 5: Detailed configuration of heuristic operators for TSP and BPP. Operator Name (ID)TypeDescription Traveling Salesman Problem (TSP) random_reinsertion (0)MutationRemoves one city and reinserts it at a random position to preserve feasibility. swap_two (1)MutationSwaps two randomly selected cities. shuffle (2)MutationRandomly shuffles the entire permutation. shuffle_subsequence (3)MutationShuffles a randomly chosen subset of positions. n_opt_move (4)MutationApplies a sequence of 2-opt flips to rewire edges. iterated_greedy (5)Ruin-RecreateRemoves a fraction of cities and reinserts them greedily. two_opt_local_search (6)Local Search2-opt edge swaps with first-improvement policy. best_imp_two_opt (7)Local Search2-opt edge swaps with best-improvement policy. three_opt_local_search (8)Local SearchUses 3-opt reconnections for complex route changes. order_crossover (9)CrossoverPreserves a subsequence from one parent and fills remaining cities in order. partially_mapped (10)CrossoverExchanges segments and maps duplicates (PMX). precedence_preservative (11)CrossoverMerges parent precedence constraints (PPC). one_point_crossover (12)CrossoverSplices two parents at one point and repairs duplicates. Bin Packing Problem (BPP) random_piece_move (0)MutationMoves random pieces between bins. swap_pieces (3)MutationSwaps pieces between two bins when feasible. random_bin_merge (5)MutationMerges contents of two bins if capacity allows. remove_repack_rnd (1)Ruin-RecreateRemoves random items and repacks using first-fit. empty_bins_repack (2)Ruin-RecreateEmpties selected bins and repacks their items. best_fit_improvement (4)Local SearchMoves items to better-fitting bins to reduce waste. bin_consolidation (6)Local SearchConsolidates bins by merging compatible ones. bin_crossover (7)CrossoverCombines bins from parents and packs remainder with first-fit. control parameters; H4 and H9 govern solution construc- tion; H5 improves completed solutions; and H6–H8 monitor search progress, maintain elite solutions, and perform global learning. Table 7 summarizes their individual responsibili- ties. Initialization and parameter control (H1–H3). H1 pro- duces the static heuristic information once before search, H2 controls the principal parameters from the current search state, and H3 initializes the ants at the beginning of each construction phase. Together, these components determine the search conditions under which an iteration begins. Solution construction (H4 and H9). H9 selects the next action from the feasible candidates scored by the trusted ker- nel. After the selected actions are applied, H4 modifies the local pheromone state. Both components are called repeat- edly while the ants incrementally construct complete solu- tions, providing decision making and immediate feedback within an iteration. Solution improvement (H5). H5 receives the completed candidate solutions and attempts to improve their objective values. The improved solutions are subsequently used in best- solution tracking and pheromone control, while problem- specific feasibility remains enforced by the domain kernel. Search monitoring and global learning (H6–H8). H6 determines whether the search is stagnating, H7 maintains an archive of high-quality solutions, and H8 updates the global pheromone state using the current solutions, best- so-far solution, archive, and stagnation information. These components carry search information across iterations and regulate longer-term search behavior. B.4 Implementation Provenance and Hook Interfaces The trusted numerical kernel was adapted from the Ant Sys- tem solver used in the public DeepACO implementation (Ye et al. 2023). We use neither DeepACO’s neural heuristic model nor its training procedure. The componentization it- self is our implementation: an initial six-hook refactoring was extended with explicit stagnation detection, elite-archive management, and action selection to obtain the nine-hook in- terface used in the experiments. The default hooks combine established ACO ideas with implementation-specific control rules. H1 and H9 retain the classical visibility and stochastic transition structure of Ant System (Dorigo, Maniezzo, and Colorni 1996); H4 uses an ACS-style local update (Dorigo and Gambardella 1997); H7 follows the population/archive perspective of P- ACO (Guntsch and Middendorf 2002); and H8 combines rank-based or best-so-far reinforcement and bounded restart- oriented control inspired by Rank-Based Ant System and MAX–MIN Ant System (Bullnheimer, Hartl, and Strauss 1999; Stützle and Hoos 2000). The adaptive schedules, multi- signal stagnation detector, archive bias, candidate-feature corrections, and the particular combinations of these mech- anisms are custom policies rather than claims of a standard Table 6: Detailed configuration of heuristic operators for Flowshop and CVRP (continued). Operator Name (ID)TypeDescription Flowshop Scheduling random_reinsertion (0)MutationRemoves one job and reinserts it at a random position. swap_two (1)MutationSwaps two randomly selected jobs. shuffle (2)MutationRandomly shuffles the entire job permutation. shuffle_subsequence (3)MutationShuffles a randomly chosen subset of job positions. use_neh (4)MutationApplies NEH heuristic using current permutation as initial. iterated_greedy (5)Ruin-RecreateRemoves jobs and reinserts using best-position insertion. deep_iterated_greedy (6)Ruin-RecreateApplies multiple rounds of iterated greedy. local_search (7)Local SearchJob reinsertion with best-improvement policy. first_imp_local_search (8)Local SearchJob reinsertion with first-improvement policy. random_local_search (9)Local SearchRandom job reinsertion based on search depth. rnd_first_imp_ls (10)Local SearchRandom job selection with first-improvement reinsertion. order_crossover (11)CrossoverPreserves subsequence and fills remainder in order. precedence_preservative (12)CrossoverMerges parent precedence constraints. partially_mapped (13)CrossoverExchanges segments and uses mapping to resolve duplicates. one_point_crossover (14)CrossoverSplices parents at one point and repairs sequence. Capacitated VRP (CVRP) two_opt (0)MutationReverses a segment within a single route. or_opt (1)MutationRelocates a sequence of 2 customers within the same route. shift_mutate (5)MutationMoves a customer to another route with random insertion. location_ruin_recreate (2)Ruin-RecreateSpatial ruin around a random location with best-fit repair. shift (3)Local SearchRelocates customers between routes based on distance penalty. two_opt_star (6)Local SearchExchanges route tails between two different routes. geni (7)Local SearchGeneralized insertion heuristic (GENI) for non-adjacent insertion. combine (4)CrossoverMerges high-quality routes from parents. nine-component ACO architecture. The exact callable interfaces are shown below. state and other dictionary arguments may contain optional infor- mation, but every generated hook must preserve the listed positional contract and return structure. Nine ACO Hook Interfaces H1 build_static_heuristic( context, candidate_info, state=None) -> ndarray,→ H2 control_parameters( iteration, best_history, pheromone_stats, stagnation_info, context, state=None) -> dict H3 initialize_ant_starts( n_ants, context, candidate_info, iteration, state=None) -> ndarray H4 local_pheromone_update( pheromone, edge, construction_state, params, context, global_state=None) -> ndarray H5 improve_solutions( solutions, costs, context, candidate_info, params,,→ iteration, archive, state=None) -> (solutions, costs),→ H6 detect_stagnation( iteration, best_history, pheromone, solutions, costs,,→ context, state=None) -> dict H7 manage_solution_archive( archive, new_solutions, new_costs, best_solution,,→ best_cost, stagnation_info, params, iteration,,→ context, state=None) -> list[(solution, cost)],→ H8 global_pheromone_control( pheromone, solutions, costs, best_solution, best_cost,,→ params, iteration, stagnation_info, archive, context,,→ state=None) -> (pheromone, state) H9 select_actions( scores, fallback_mask, construction_state, params,,→ Table 7: Components in the componentized ACO framework. IDComponentResponsibility H1 build_static_heuristicConstructs static heuristic information from problem features before the search begins. H2 control_parametersSets or adapts the principal ACO parameters according to the current search state. H3 initialize_ant_startsDetermines the starting positions and initial construction states of the ants. H4 local_pheromone_updateApplies local pheromone updates during incremental solution construction. H5 improve_solutionsApplies local improvement to completed candidate solutions. H6 detect_stagnationDetects search stagnation from the optimization history and current pheromone state. H7 manage_solution_archiveMaintains high-quality solutions and associated archive information. H8 global_pheromone_controlPerforms global pheromone updates and other iteration-level control operations. H9 select_actionsSelects the next action from the feasible candidates using the transition information. Algorithm 3: Componentized Ant Colony Optimization 1: Input: Instance I, ants M, and iteration limit T 2: η ← H 1 (I); initializeτ, best solutionx ∗ , archiveA, and historyB 3: for t = 1,...,T do 4: θ t ← H 2 (t,B); X ← H 3 (I,M,θ t ) 5: while some solution in X is incomplete do 6:(Q,F )← KernelScores(I,X,τ,η,θ t ) 7: a← H 9 (Q,F,X); X ← KernelApply(X,a) 8: τ ← H 4 (τ,X,a,θ t ) 9: end while 10: X ← H 5 (I,X,θ t ); c← KernelEvaluate(I,X) 11: x ∗ ← UpdateBest(x ∗ ,X,c) 12: s← H 6 (B,τ,c);A← H 7 (A,X,c) 13: τ ← H 8 (τ,X,c,x ∗ ,A,s,θ t ) 14: B ← UpdateHistory(B,c,x ∗ ,s) 15: end for 16: return x ∗ context, global_state=None) -> ndarray Algorithm 3 shows where the nine components are in- voked. Operations marked as kernel operations remain fixed, whereas H1–H9 correspond to the replaceable components listed in Table 7. C Implementation and Experimental Details C.1 Experimental Protocol and Search Budget Table 8 reports the configuration shared by the experiments in the main paper. A function evaluation (FE) denotes the complete evaluation of one proposed component or jointly proposed pair on the full training set. For MuEvo, this eval- uation covers the Best, Initial, and Secondary collaboration contexts under one shared per-candidate solver-run budget. Each regular evolution round or pair-evolution round there- fore consumes exactly one FE; the contexts are not charged as separate FEs. Reflection, code generation, static validation, and failed output parsing do not consume additional FEs. All methods use the same 25-FE-per-component prelim- inary budget. MuEvo and the Single and Batch adaptations then use 100 main-search FEs. The Split adaptation instead Table 8: Common experimental configuration. ParameterValue Primary LLMDeepSeek-V4-Flash Generator temperature0.8 Generator output limit6,144 tokens Independent AHD runs per method3 MuEvo, Single, and Batch main-search budget100 FEs Split main-search budget100 FEs per target; 300 FEs total Component-probing budget25 FEs per valid component Probe budget accountingExcluded from the main- search budget Within-component population size4 Mutation sampling fraction0.3 Training solver runs per instance and FE10 Test solver runs per instance10 Test time limit per solver run300 seconds Training controller for SHHADAPHH HardwareTwo AMD EPYC 9754 CPUs; 1,024 GB RAM runs three independent 100-FE searches over the same Top-3 components used by Batch, for 300 main-search FEs in total. This allocation is intentionally favorable to Split rather than a claim of equal total computation; the exact target selection and accounting are detailed in Appendix E. All final tables av- erage the three independent AHD runs; each resulting solver is evaluated with independent solver seeds. C.2 MuEvo Hyperparameters Table 9 lists the parameters corresponding to the mechanisms in Section 3 of the main paper. These values are fixed across the reported domains and are not tuned separately on the test sets. Dynamic Component Management The lifecycle con- tains exactly two component states: Active and Inactive. The top three probed components are initialized as Active, and every remaining valid component is initialized as Inactive. An Inactive component becomes eligible for activation when global stagnation reaches one round and at least two rounds have elapsed since the previous activation; the selected com- ponent is promoted to Active and force-selected for one round. An Active component is moved to Inactive after two consecutive rejected Multi-Ensemble Evaluations and cannot be reactivated during the following three-round cooldown. It can also be moved to Inactive after four selections without improvement, provided another Active component remains. Inactive activation candidates are ordered by fewer consec- utive gate rejections, higher uncertainty and probing scores, larger exponentially smoothed Best-context gains, fewer pre- vious activations, and component ID. The exponential mov- ing average uses coefficient 0.35. Components in cooldown are excluded from activation. The reported lifecycle does not introduce any additional component state. Multi-Ensemble Evaluation Best, Initial, and Secondary contexts receive weights 0.6, 0.2, and 0.2. The ten solver runs assigned to one candidate on each training instance are shared across the three contexts: four runs use the Best context, three use the Initial context, and three use the Secondary context. These ten runs together constitute one FE, rather than ten run-level FEs or three context-level FEs. The three resulting deltas are aggregated using Eq. (5) of the main paper with λ min = 0.2 and λ var = 0.1. Acceptance requires both ∆ Best i > 0 and R i > 0. The Secondary context is selected from an archive of at most eight ensembles, subject to a minimum diversity of 0.25 from the Best context. Relation Memory and Pair Evolution Relation mem- ory retains at most 200 accepted or rejected replacement events. For a selected target, the six most recent relevant events are combined with its interaction-graph neighbor- hood. The LLM-based interaction summary is updated every two rounds after at least two events are available and uses at most eight events. The SHH interaction graph starts without hand-coded relation priors and is learned from single- and pair-replacement outcomes; the componentized ACO graph may additionally be initialized with structural dependencies between hooks. Pair evolution is attempted every two regular rounds, be- ginning with the second round, while at least three FEs re- main. Eligible pairs are ranked by their structural or empiri- cally learned interaction score. For pair (i,j), the implemen- tation adds 0.20 for each previously accepted joint replace- ment, subtracts 0.30 for each failed attempt and an additional 0.15 per consecutive failure, and excludes a pair for three rounds after two consecutive failures. Ties are resolved by the graph score and then the lexicographic component IDs. A pair is accepted only as a joint replacement through the same Multi-Ensemble Evaluation rule used for single com- ponents, and the complete pair evaluation consumes one FE. The three-FE condition is a conservative scheduling guard that preserves budget for subsequent evolution; it is not the evaluation cost of the pair. Adaptive Budget Allocation The implementation uses the quantities in Eq. (6) of the main paper with w I = 0.40, w V = 0.30, w S = 0.05, H z = 5, w R = 0.25, and H r = 5. Under-exploration contributes 0.30(1− ρ i ) and the explicit over-selection term contributes −0.10ρ i ; because the addi- tive constant does not affect ranking, these are equivalent to an effective allocation penalty w ρ = 0.40. A supplemen- tary penalty of at most 0.20 is applied when the most recent three rewards are non-positive. Equal scores are broken by the smaller component ID. Lifecycle-forced activation takes precedence over this ranking for one round. C.3 Cross-Controller Generalization Details Table 10 reports the complete TSP and BPP results used in the cross-controller analysis. “Ori” denotes the original human-designed LLH ensemble, and “Evo” denotes the same controller using the LLH ensemble evolved with ADAPHH; no controller-specific retraining is performed. C.4 Sample Evolved Heuristic Code Below is an excerpt from an evolved heuristic (H5: Iterated Greedy) generated by MuEvo for TSP: Evolved Heuristic: Iterated Greedy (TSP) def _iterated_greedy(self, solution): """ Optimized Iterated Greedy algorithm combining advantages of two versions:,→ 1. Adaptive hybrid removal strategy (random + worst-edge + neighborhood),→ 2. Enhanced regret insertion strategy (k-regret value),→ 3. Incremental layered local search (fast 2-opt + intensive 2-opt,→ + conditional 3-opt) 4. Adaptive simulated annealing acceptance criterion,→ 5. Dynamic perturbation with elite pool management,→ 6. Computation optimization and caching strategy,→ """ import math # ==================== Nested Helper Functions ====================,→ def adaptive_params(n, intensity): """Compute adaptive parameters based on problem size and intensity""",→ base_ratio = 0.08 + 0.14 * intensity remove_count = max(2, min(n-1, int(base_ratio * n))),→ base_iterations = 15 + n // 12 iterations = min(base_iterations, 50) search_range = min(25, max(8, n // 8)) return 'remove_count': remove_count, 'iterations': iterations, 'search_range': search_range, 'perturb_after': 5 + int(3 * (1 - intensity)),,→ 'initial_temp': solution.cost * 0.025,,→ 'cooling_rate': 0.94, 'k_regret': 3 if n > 50 else 2 def efficient_hybrid_removal(tour, num_remove, intensity):,→ """Efficient hybrid removal strategy: random + worst-edge + neighborhood""",→ n, removed_indices, removed_cities = len(tour), set(), [],→ random_count = max(1, int(num_remove * (0.65 - 0.25 * intensity))),→ if random_count > 0: candidates = list(range(n)) self.rng.shuffle(candidates) for idx in candidates[:random_count]: removed_indices.add(idx); remove ⌋ d_cities.append(tour[idx]),→ # 2. Worst-edge and neighborhood fallback logic,→ if len(removed_indices) < num_remove: edge_scores = [] for i in range(n): if i in removed_indices: continue j = (i + 1) % n if j in removed_indices: continue edge_len = self.instance.get_dis ⌋ tance(tour[i], tour[j]),→ edge_scores.append((edge_len, i, j)),→ edge_scores.sort(reverse=True, key=lambda x: x[0]),→ for _, i, j in edge_scores[:num_remove - len(removed_indices)]: ,→ ,→ removed_indices.add(i); removed_ ⌋ cities.append(tour[i]),→ return removed_cities, sorted(removed_indices, reverse=True),→ Evolved Heuristic: Iterated Greedy (TSP) def enhanced_regret_insertion(partial_tour, cities_to_insert, k_regret):,→ """Enhanced regret insertion with incremental optimization""",→ current_tour, insert_order = partial_tour.copy(), cities_to_insert.copy() ,→ ,→ self.rng.shuffle(insert_order) for city in insert_order: m = len(current_tour) if m == 0: current_tour.append(city); continue,→ insertion_costs = [] for pos in range(m + 1): prev_c = current_tour[pos-1] if pos > 0 else current_tour[-1],→ next_c = current_tour[pos] if pos < m else current_tour[0],→ cost = self.instance.get_distanc ⌋ e(prev_c, city) + \,→ self.instance.get_distanc ⌋ e(city, next_c) - \,→ self.instance.get_distanc ⌋ e(prev_c, next_c),→ insertion_costs.append((cost, pos)),→ insertion_costs.sort(key=lambda x: x[0]),→ regret = sum( insertion_costs[i][0] - insertion_costs[0][0],→ for i in range(1, min(k_regret, len(insertion_costs))),→ ) threshold = insertion_costs[0][0] * 0.1,→ alt_idx = self.rng.randint(0, min(k_regret-1, len(insertion_costs)-1)) ,→ ,→ best_pos = ( insertion_costs[0][1] if regret > threshold else insertion_costs[alt_idx][1] ) current_tour.insert(best_pos, city) return current_tour # ==================== Main Algorithm Logic ====================,→ n = len(solution.permutation) if n <= 3: return intensity = self.get_intensity_of_mutation() params = adaptive_params(n, intensity) # Initialize best solution and elite pool best_tour = solution.permutation.copy() best_cost = solution.cost elite_pool = [(best_tour.copy(), best_cost)] for iteration in range(params['iterations']): # 1. Hybrid removal removed_cities, removed_indices = efficient_hybrid_removal(,→ best_tour, params['remove_count'], intensity,→ ) # 2. Remove cities from tour partial_tour = best_tour.copy() for idx in removed_indices: partial_tour.pop(idx) # 3. Regret insertion new_tour = enhanced_regret_insertion( partial_tour, removed_cities, params['k_regret'],→ ) # 4. Layered local search and acceptance new_tour = layered_local_search(new_tour, iteration, intensity),→ new_cost = self.algorithms.from_permutat ⌋ ion_compute_cost(new_tour),→ if adaptive_sa_acceptance(best_cost, new_cost, temperature, iteration,,→ params['iterati ⌋ ons'], no_improve): ,→ ,→ best_tour, best_cost = new_tour, new_cost,→ no_improve = 0 else: no_improve += 1 temperature * = cooling_rate # Update solution if best_cost < solution.cost - 1e-6: solution.permutation = best_tour solution.cost = self.algorithms.compute_ ⌋ cost(solution),→ D Prompt Templates for LLM Heuristic Design This section documents the prompt templates used by the current MuEvo implementation. The prompts fall into four categories: (1) reflective within-component evolution, (2) domain-specific generation constraints, (3) cross-component information sharing, and (4) relation-guided pair evolution. Component probing reuses the within-component evolution prompts under a smaller evaluation budget. Dynamic lifecy- cle transitions, Multi-Ensemble Evaluation, target and pair selection, and Adaptive Budget Allocation are implemented by numerical rules and therefore do not invoke additional LLM prompts. For readability, the Chinese-language SHH prompts are presented as faithful English translations with their place- holders preserved. Because the SHH and ACO implementa- tions share the same relation-evidence and joint-evaluation protocol, we summarize the SHH-specific relation and pair interfaces and show the ACO instantiations in full. D.1 Reflective Within-Component Evolution Each component maintains its own population. Following ReEvo, MuEvo uses short-term reflection, long-term reflec- tion, reflection-guided crossover, and mutation. The same templates are used during short-budget probing and regu- lar co-evolution; only the evaluation budget and the injected cross-component context differ. System Prompts Generator System Prompt. System Prompt (Generator) You are a professional algorithm engineer specializing in,→ designing and optimizing heuristic algorithms.,→ Please generate high-quality heuristic code based on the,→ given requirements and reflections. Important: If helper functions are needed, define them as,→ nested functions inside the requested main function. Do not,→ define helper functions at module level.,→ Reflector System Prompt. System Prompt (Reflector) You are a professional algorithm optimization expert,→ specializing in analyzing and improving heuristic algorithms.,→ Carefully compare the two given heuristic implementations,,→ identify the reasons for their performance difference, and,→ provide actionable improvement suggestions.,→ Short-Term Reflection Prompt Short-Term Reflection Prompt Analyze the following two implementations of the,→ func_name heuristic. Problem description: problem_desc Function description: func_desc Worse-performing implementation (fitness: fitness0):,→ ```python code0 ``` Better-performing implementation (fitness: fitness1):,→ ```python code1 ``` Analyze: 1. What are the key differences between the implementations?,→ 2. Why does one implementation perform better?,→ 3. What are the main weaknesses of the worse implementation?,→ 4. How can the heuristic be further improved?,→ Provide specific analysis and implementation suggestions.,→ Long-Term Reflection Prompt Long-Term Reflection Prompt Update the long-term reflection using the following information.,→ Problem description: problem_desc Accumulated short-term reflections: short_term_reflections Current long-term reflection: long_term_reflection Integrate the new observations and provide:,→ 1. A summary of the current trends 2. Successful optimization patterns 3. Strategies that should be avoided 4. Updated directions and concrete implementation suggestions,→ Crossover Prompt Reflection-Guided Crossover Prompt domain_generation_prompt algorithm_reference Using the following reflection, generate a new heuristic that,→ combines the useful properties of both parents.,→ Reflection: reflection Worse-performing parent: ```python func_signature0 worse_code ``` Better-performing parent: ```python func_signature1 better_code ``` Function name: func_name Return a complete Python implementation.,→ function_constraints Mutation Prompt The target-specific relation context de- scribed in Section D.3 is appended only during mutation. This prevents the same context from being repeated in both crossover and mutation within one evolution step. Relation-Aware Mutation Prompt domain_generation_prompt algorithm_reference Using the following long-term reflection and elite individual,,→ generate an improved heuristic variant.,→ Long-term reflection: reflection Elite individual: ```python elitist_code ``` Required signature: func_signature Function name: func_name Make a meaningful but contract-preserving improvement.,→ Return a complete Python implementation.,→ function_constraints ## Co-Evolution Context target_specific_relation_context D.2 Domain-Specific Generation Constraints MuEvo supports two implementation interfaces. SHH com- ponents manipulate solution objects through a domain API, whereas ACO components implement typed hooks inside the componentized solver. The corresponding constraints are generated separately. SHH API Reference Meta-Prompt For SHH domains, AlgorithmPromptGenerator introspects the avail- able algorithm utilities, read-only instance data, modifi- able solution fields, and blocked framework methods. The extracted information is inserted into the following meta- prompt, and the resulting API guide is included in the component-generation prompt. SHH API Reference Meta-Prompt You are generating a comprehensive API reference guide for the,→ DOMAIN_NAME problem domain. The guide will be used by an LLM,→ to generate executable heuristic code. domain_specific_notes # Algorithm methods formatted_algorithm_methods # Instance access Instance attributes and methods are READ-ONLY. formatted_instance_attributes formatted_instance_methods # Modifiable solution attributes formatted_solution_attributes # Forbidden framework methods Never call the following methods because doing so creates,→ nested framework calls or infinite recursion: blocked_methods_list # Random operations Use only the random-number generator exposed by the problem.,→ Generate a practical reference that: 1. Gives an exact signature and usage example for each method,→ 2. Distinguishes read-only instance data from modifiable solution data,→ 3. Explains when solution cost must be recomputed 4. Lists forbidden methods explicitly 5. Uses exact field and method names ACO Single-Hook Generation Prompt ACO domains do not use the SHH object API. The generator is instead given the exact hook signature, the default hook contract, and the runtime data that may be available to the component. ACO Hook System and User Prompt [System] You are an expert algorithm engineer optimizing one component,→ hook inside a componentized ACO solver. Return only valid Python code for the requested hook function.,→ Preserve the exact function name and argument contract.,→ [User] Please improve the`func_name` hook for `domain_name`.,→ This hook is executed inside a componentized Ant Colony,→ Optimization solver. It must preserve the exact signature and,→ return contract shown below. Strict requirements: - Function name:`func_name` - Exact signature:`func_signature` - Do not wrap the hook in`heuristic_function`. - Use only standard Python,`math`,`random`, and `numpy`/`np`.,→ - Preserve return types and array shapes. - Keep every numeric output finite. - Preserve feasibility masks and never select forbidden actions.,→ - Guard optional dictionaries with`.get(...)`. Useful runtime data: -`context`: domain, distances, coordinates, demands, capacity,,→ depot, number of nodes, and best-known value when available,→ -`candidate_info`: candidate masks, nearest-neighbor,,→ proximity, geometric, or archive-derived features,→ -`params`,`stagnation_info`,`archive`, and `state` may be,→ absent or partial Default behavior and contract: default_hook_docstring Return a complete Python function only. D.3 Cross-Component Information-Sharing Prompts MuEvo constructs target-specific context from two comple- mentary sources in both SHH and componentized ACO. Functional summaries describe the roles of the current com- ponents, while an interaction summarizer combines accepted and rejected single- and pair-replacement events, context- dependent fitness deltas, collaborator versions, and the cur- rent interaction graph whenever sufficient evidence is avail- able. The resulting context is used to guide mutation of the selected component and the joint refinement of selected pairs. Functional-Role Summaries for SHH The SHH con- text generator first extracts a concise design rationale for each component and then aggregates the rationales into a portfolio-level description. Per-Component Functional Analysis [System] You are an algorithm design analyst. Analyze the given,→ heuristic code and metadata to extract its design rationale,→ and strategic characteristic. Output in one or two sentences: - What is the heuristic trying to do? - What role does it fill in the portfolio?,→ [User] Heuristic: heuristic_name (Type: heuristic_type),→ Fitness: fitness Generation: generation_method (Iteration iteration),→ Complete code: ```python original_code ``` Provide a concise design rationale: Portfolio Functional Summary [System] You are a portfolio analysis expert. Synthesize the component,→ rationales into a cohesive portfolio-level summary.,→ Describe the overall strategic coverage, complementary roles,,→ possible redundancy, and missing functionality.,→ [User] Current portfolio (global-best cost: global_best_cost):,→ - Hid1 (name1, type1): rationale1,→ - Hid2 (name2, type2): rationale2,→ - ... Provide a concise portfolio summary: Interaction-Evidence Summarization For SHH, the in- teraction graph is initialized without hand-coded relation priors and is populated online from multi-ensemble replace- ment outcomes. Each accepted or rejected event links the evolved LLH to its collaborator context and records the cor- responding context-dependent deltas. Joint replacement out- comes additionally provide direct pair evidence. The LLM periodically summarizes these observations into evidence- supported hypotheses about synergy, conflict, or redundancy. The same high-level evidence schema is used for componen- tized ACO, where structural dependencies may additionally seed the graph. The ACO instantiation of the summarization prompt is shown below; the SHH version replaces the hook terminology with LLH roles and the domain API context. Interaction-Evidence Summarization Prompt [System] You summarize ACO component interaction evidence. Use only the supplied evidence and return strict JSON.,→ [User] Target: target_component_or_pair Below are raw facts from final replacement gates, group gates,,→ and the current interaction graph. Do not assume predefined,→ ACO component relations. Infer only what the evidence supports.,→ Return JSON with this schema: "summary": "...", "relations": [ "neighbor": "H6", "relation": "potential_conflict|potential_synergy| potential_redundancy|uncertain", "confidence": 0.0, "evidence": ["..."], "hypothesis": "...", "actionable_advice": ["..."] ], "recommended_mode": "single|pair|cooldown|explore",,→ "risk": "low|medium|high", "actionable_advice": ["..."] Evidence JSON: replacement_events_and_graph_edges Target-Specific Relation Context The generated sum- mary is combined with recent final-replacement records and the target’s graph neighborhood. The following assembled block is appended to the mutation prompt; fields with no available evidence are omitted. Relation Context Injected into Mutation ## Final Replacement Memory for Htarget_id,→ - iter t1: accepted_or_rejected, delta=best_delta; acceptance_reason,→ - iter t2: accepted_or_rejected, context deltas=best, initial, secondary; failure_mode,→ ## Learned Interaction Summary Summary: evidence_supported_summary Recommended mode: single_pair_cooldown_or_explore,→ Risk: risk Relations: - Htarget_id-Hneighbor_id: relation_type,,→ confidence=confidence; hypothesis,→ Advice: actionable_advice ## Interaction Graph Neighborhood - Htarget_id-Hneighbor_id: type=interaction_type,,→ positive=positive_score, conflict=conflict_score,,→ redundancy=redundancy_score, evidence=evidence_count,→ D.4 Relation-Guided Pair Evolution Prompt Pair selection is performed programmatically from the inter- action graph. ACO may combine structural priors with em- pirical evidence, whereas SHH begins without hand-coded pair priors and uses relations learned online from replace- ment outcomes. For SHH, the two selected LLHs are placed in one gen- eration request together with their current implementations, functional roles, exact HyFlex-compatible signatures, do- main API constraints, and the summarized pair relation. The LLM returns two named functions in one response. MuEvo extracts and validates each function against its own oper- ator contract, applies the same format-repair and preflight- repair stages used for joint generation, and inserts both LLHs into each evaluation context. The resulting pair is treated as one candidate and is accepted or rejected jointly by Multi- Ensemble Evaluation. This protocol also supports pairs con- taining different LLH operator types while preserving both original interfaces. The componentized-ACO instantiation follows the same joint protocol. Its current implementations, exact hook sig- natures, interaction evidence, recent failure mode, and joint design objective are provided in one request so that the two changes can be coordinated. Joint ACO Pair-Evolution Prompt [System] You jointly evolve two ACO component hooks. Return only valid,→ Python functions for the requested hook names. [User] You are jointly evolving two interacting componentized ACO,→ hooks for`domain_name`. Return exactly two Python functions, one for each required hook.,→ Keep the exact function names, signatures, return types, array,→ shapes, feasibility constraints, and finite numeric behavior.,→ Do not define classes, read or write files, or include,→ explanations outside the code. Required components: - Hleft_id`left_name` - Hright_id`right_name` Required exact signatures: - Hleft_id`left_signature` - Hright_id`right_signature` Observed interaction: pair_interaction_summary Failure mode: recent_pair_failure_context Design objective: joint_design_objective ACO contract reminders: - Return the same structural type as each original hook.,→ - Preserve finite arrays and valid shapes. - Preserve feasibility masks. - For TSP, preserve valid permutations after local improvement.,→ - If uncertain, make a small conservative change instead of,→ replacing the entire strategy. Current implementations: # Hleft_id: left_name ```python left_code ``` # Hright_id: right_name ```python right_code ``` Write the improved pair now. For both interfaces, if the returned pair cannot be parsed into the two required top-level functions, MuEvo issues at most one format-repair request at temperature 0.8. This re- quest changes only the output format: it supplies the parser error, required function names, and previous response, and instructs the LLM to return exactly the two raw Python func- tions. Once the pair is successfully parsed, interface-specific signature and static validation followed by a smoke test form a separate preflight stage. A pair that fails this stage may receive at most two correctness-repair requests, also at tem- perature 0.8, before it is discarded. Thus, the format-repair limit is one and the preflight-repair limit is two; they apply to different failure stages. E LLM-Based Automatic Heuristic Design Baselines We compare MuEvo with three representative LLM-based automatic heuristic design methods: ReEvo, EoH, and MCTS-AHD. This section summarizes their original search mechanisms and then describes how they are instantiated in the Single, Split, and Batch modes used in our experiments. E.1 ReEvo: Reflective Evolution Framework This section provides a detailed overview of the ReEvo framework (Ye et al. 2024), which pioneered the concept of Language Hyper-Heuristics (LHH) for automatic heuristic design. Our MuEvo framework builds upon ReEvo’s foun- dational ideas while extending them to the multi-heuristic co-evolution setting. Language Hyper-Heuristics ReEvo introduces the con- cept of Language Hyper-Heuristics (LHH), an emerging variant of traditional Hyper-Heuristics that leverages Large Language Models for heuristic generation. Unlike classic HHs that are limited by heuristic spaces predefined by hu- man experts, LHH features minimal human intervention and open-ended heuristic spaces. Formally, for a combinatorial optimization problem with solution spaceS and objective functionf :S → R, a Hyper- Heuristic searches for the optimal heuristic h ∗ in a heuristic spaceH such that a meta-objective function F : H → R is minimized: h ∗ = arg min h∈H F (h)(7) In LHH, heuristics inH are generated by LLMs rather than being predefined, enabling exploration of an open-ended heuristic space. ReEvo Methodology ReEvo couples evolutionary search with LLM self-reflections to efficiently explore heuristic spaces. The framework employs two LLM roles: a genera- tor LLM for generating heuristic candidates, and a reflector LLM for providing guidance through reflections. Individual Encoding. ReEvo performs evolutionary search over executable heuristic code. Each individual is a code snippet representing a heuristic function and is con- strained primarily by the required function signature rather than a predefined program encoding. Population Initialization. The heuristic population is ini- tialized by prompting the generator LLM with a task spec- ification containing: (1) COP descriptions (if available), (2) heuristic designation, and (3) heuristic functionality. Option- ally, seed heuristics can provide in-context examples to en- courage valid generation. Iterative Evolution. Each ReEvo iteration contains five sequential steps: 1. Selection: Parent pairs are selected from successfully exe- cuted heuristics at random, while avoiding pairing heuris- tics with identical meta-objective values. 2. Short-term Reflection: The reflector LLM analyzes the relative performance of each parent pair and provides hints for improved design. This is analogous to interpret- ing genetic cues and providing “verbal gradients” within the search space. 3. Crossover: The generator LLM produces an offspring heuristic given the parent pair, their relative performance, short-term reflections, and generation instructions. 4. Long-term Reflection: The reflector LLM summarizes accumulated short-term reflections into long-term in- sights, distilling expertise for improved heuristic design. 5. Elitist Mutation: Based on long-term reflections, the generator LLM samples multiple heuristics to improve the current best one. The dual-level reflection mechanism—short-term for pair- wise comparison and long-term for accumulated exper- tise—enables ReEvo to outperform prior state-of-the-art LHH methods with better sample efficiency. Relationship to MuEvo MuEvo retains ReEvo’s reflection-guided within-population evolution while ad- dressing the additional problem of coordinating multiple components in a complete solver. The key distinction is the shift from single-heuristic evolution to multi-component co-evolution: Algorithm 4: ReEvo Workflow 1: Input: Task Specification T , Optional Seed Heuristics H seed 2: Initialize: PopulationP ← LLM(T ,H seed ) 3: Long-term reflectionsR long ←∅ 4: while not converged do 5: Evaluate: Compute meta-objective F (h) for all h ∈ P 6: Selection: Select parent pairs (h 1 ,h 2 ) fromP 7: for each parent pair (h 1 ,h 2 ) do 8:Short-termReflection: r short ← Reflector(h 1 ,h 2 ,F (h 1 ),F (h 2 )) 9:Crossover: h new ← Generator(h 1 ,h 2 ,r short ) 10: end for 11: Long-termReflection: R long ← Reflector(R long ,r short ) 12: Elitist Mutation: h mutated ← Generator(h ∗ ,R long ) where h ∗ = arg minF 13: Update:P ← Select(P ∪h new ∪h mutated ) 14: end while 15: Return: Best Heuristic h ∗ ∈P • ReEvo focuses on evolving a single heuristic function for a specific component of the problem solver (e.g., a penalty heuristic for GLS, or a heuristic measure for ACO). • MuEvo maintains one population for each component and evaluates candidate replacements in the complete SHH or componentized ACO solver. This difference motivates two groups of extensions: 1. Dynamic Component Management uses short-budget probing and a reversible lifecycle so that an initially weak component is not permanently removed. 2. LLM-Driven Co-Evolution adds Multi-Ensemble Eval- uation, cross-component relation context, relation-guided pair evolution, and adaptive budget allocation. These mechanisms use ensemble-level replacement evidence rather than treating component populations as indepen- dent searches. The generator and reflector prompts remain ReEvo-style, but component eligibility, collaboration context, joint up- dates, and allocation are controlled by MuEvo. Their exact configuration is reported in Appendix C and their prompts in Appendix D. E.2 EoH: Evolution of Heuristics EoH combines Large Language Models with evolutionary computation for automatic heuristic design (Liu et al. 2024). Its central idea is to evolve both the high-level idea of a heuristic and its executable implementation. The former is represented by a natural-language description, referred to as a thought, while the latter is represented by code that follows a task-specific function signature. This joint representation allows the LLM to reason over algorithmic ideas while re- taining executable candidates that can be evaluated directly. Algorithm 5: EoH Workflow 1: Input: TaskT , population size N, evaluation budget B 2: O ←E1, E2, M1, M2;P ←∅ 3: while|P| < N and budget remains do 4:(d,c)← LLM(I1,T ) 5: if c is valid then 6: P ←P ∪(d,c, Evaluate(c)) 7: end if 8: end while 9: while budget remains do 10: for o∈O do 11: P o ← RankSelect(P,o) 12:(d,c)← LLM(o,T ,P o ) 13:if c is valid and budget remains then 14:h← (d,c, Evaluate(c)) 15: P ← Best N (P ∪h) 16:end if 17: end for 18: end while 19: return Best heuristic inP Heuristic Representation Each EoH individual is repre- sented by a tuple h i = (d i ,c i ,F i ), where d i is the natural- language description, c i is the executable code, and F i is the fitness obtained by running the heuristic on a set of train- ing instances. The description summarizes the main mecha- nism, whereas the code specifies implementation details and parameter settings. EoH maintains a fixed-size population P = h 1 ,...,h N and uses the evaluated fitness values to guide parent selection and survival. Evolution Operators The original EoH method proposes two exploration strategies and three modification strategies. E1 asks the LLM to generate a heuristic that is substantially different from selected parents. E2 first identifies a shared backbone among the parents and then develops a distinct heuristic motivated by that backbone. M1 modifies the mech- anism of one selected heuristic, M2 adjusts its parameters and decision rules, and M3 removes redundant components to simplify the heuristic. The implementation used in our experiments follows the released four-operator configuration O =E1, E2, M1, M2 and does not apply M3. Parents are sampled using rank-based probabilities, so bet- ter heuristics are selected more frequently without making selection deterministic. Every LLM response contains both a new description and code. Valid offspring are evaluated on the training instances and added to the candidate pool, after which population management retains the best N distinct individuals. Evolutionary Workflow Algorithm 5 summarizes the EoH workflow used by our baselines. Initialization operator I1 generates the first population from the task specification. The four evolution operators then alternate between broad exploration and targeted modification until the evaluation budget is exhausted. E.3 MCTS-AHD: Monte Carlo Tree Search for Heuristic Design The third baseline is MCTS-AHD (Zheng et al. 2025), a recent LLM-based Automatic Heuristic Design method that addresses the local optima problem of population-based ap- proaches through Monte Carlo Tree Search. Motivation and Key Insight Population-based LLM- AHD methods (such as ReEvo and EoH) maintain a fixed- size population of top-performing heuristics, discarding in- ferior ones in each generation. However, temporarily under- performing heuristics may still have potential for significant improvement after further LLM-based refinement. MCTS- AHD addresses this by preserving all generated heuristics in a tree structure, enabling “worse-before-better” evolutionary paths. MCTS-AHD Methodology Tree Structure. MCTS-AHD organizes all LLM- generated heuristics in a tree where: • The root node n r is a virtual node without representing any heuristic • Each non-root node represents an executable heuristic function h along with its linguistic description • Parent-child relationships encode evolutionary derivation (child generated from parent) LLM-Based Actions. MCTS-AHD defines six types of LLM-based actions for node expansion: • Initialization (i 1 ): Generate a heuristic function from scratch • Mutation (m 1 ): Introduce new mechanisms/formulas to existing function • Mutation (m 2 ): Modify parameter settings of existing function • Crossover (e 1 ): Generate divergent heuristic from multi- ple existing ones • Crossover (e 2 ): Improve parent heuristic by learning from reference function • Tree-path Reasoning (s 1 ): Analyze all heuristics on path from leaf to root and generate enhanced version UCT Selection with Exploration-Decay. Node selection uses the UCT formula with normalized quality values: UCT(c) = Q(c)− q min q max − q min + λ· s ln(N (n c ) + 1) N (c) (8) where Q(c) is the quality value (heuristic performance), N (c) is the visit count, andλ is the exploration factor. MCTS- AHD applies exploration-decay by linearly decreasing λ as iterations progress: λ = λ 0 · T − t T (9) This encourages exploration in early stages and exploitation in later stages. Algorithm 6: MCTS-AHD Workflow 1: Input: Task P, Framework, Max evaluations T 2: Initialize: Tree with root n r and N I initial nodes via action i 1 3: Elite set E ← Top-10 performing heuristics 4: while total evaluations < T do 5: Selection: Traverse from n r to leaf n l by max UCT 6: if Progressive widening condition met then 7:Expand n r with e 1 or other nodes with e 2 8: end if 9: Expansion: Generate2k + 2 children via m 1 ,m 2 ,e 2 ,s 1 10: Simulation: Evaluate each child heuristic h: Q(c)← g(h) 11: Backpropagation: Update Q,N on path to root 12: Update elite set E, q max , q min 13: end while 14: Return: Best heuristic h ∗ = arg max h g(h) Progressive Widening. To enable crossover between heuristics generated at different times, MCTS-AHD applies progressive widening, adding new child nodes when: ⌊N (n) α ⌋≥|Children(n)|(10) with α = 0.5, allowing re-exploration of non-leaf nodes as the elite set evolves. E.4 Multi-Heuristic Baseline Adaptations To evaluate MuEvo’s multi-heuristic co-evolution capability, we instantiate the baseline methods in three modes. All three modes use the same component ranking produced by their fixed pre-search. Single selects only the Top-1 component and evolves it while keeping the remaining ensemble fixed. Split and Batch both select the same Top-3 components. Split runs an independent single-component search for each selected target and combines their best outputs only after all three searches finish, whereas Batch treats the Top-3 set as a single optimization unit and prompts the LLM to generate or refine all three components simultaneously. For Single and Batch, the 100-FE budget applies to the complete main search, not separately to each selected com- ponent. In Batch, one FE evaluates one joint Top-3 candi- date. Split does not divide 100 FEs among its three targets: each independent component search receives the full 100 FEs, for 300 main search FEs in total. Consequently, no remainder-allocation rule is needed. This deliberately gen- erous allocation favors Split and tests whether additional independent search can compensate for the absence of ex- plicit co-evolution; its comparatively weak results therefore cannot be attributed to a smaller evaluation budget. Across the Batch adaptations, a response is valid only when all three required named functions can be extracted and pass the corresponding code checks. An incomplete or invalid multi-function response is discarded as one failed Batch proposal and is never partially merged with the current ensemble. Because it is not sent to the solver evaluator, it consumes no FE; the baseline proceeds to its next scheduled generation attempt. Algorithm 7: MCTS-AHD-Batch Workflow 1: Input: Target LLH IDsh 1 ,...,h n , Max evaluations T 2: Initialize: Tree with root n r representing the initial en- semble 3: while total evaluations < T do 4: Selection: Traverse from n r to a leaf node n l using the UCT criterion 5: Expansion: Prompt LLM to generate a new ensemble E new =h 1 ,...,h n in a single pass 6: Simulation: Evaluate E new in the hyper-heuristic framework to obtain fitness Q(E new ) 7: Backpropagation: Update Q and N values for all nodes on the path from n l to n r 8: end while 9: Return: Best ensembleE ∗ = arg max E Q(E ) MCTS-AHD-Batch MCTS-AHD-Batch extends the stan- dard MCTS-AHD framework to accommodate the simulta- neous evolution of a heuristic ensemble. Unlike the standard version that searches for a single optimal heuristic, MCTS- AHD-Batch treats the entire ensemble h 1 ,...,h n as a single optimization unit within the MCTS tree. Key Design. • Ensemble-Level Search Space: Each node in the MCTS tree represents a candidate ensemble. The expansion and simulation operations are modified to generate and eval- uate all heuristics in the ensemble simultaneously. • Joint Generation: During the expansion phase, the LLM is prompted to generate code for all target heuristics in the ensemble in a single pass, ensuring the LLM can consider the potential interactions between different operators. • Ensemble Evaluation: The reward signals (simulation results) are derived from the performance of the com- plete ensemble when integrated into the hyper-heuristic framework, allowing the search to optimize for synergistic effects. ReEvo-Batch ReEvo-Batch extends ReEvo to evolve an ensemble of multiple LLHs simultaneously within a single evolutionary process. Key Design. • Multi-LLH Individual: Unlike standard ReEvo where each individual is a single heuristic, ReEvo-Batch repre- sents each individual as an ensemble of multiple LLHs: Individual =h 1 ,h 2 ,...,h n . • Ensemble Evaluation: The fitness of each individual is evaluated by injecting all its LLHs into the hyper-heuristic framework and measuring ensemble-level performance. • Dual-Level Reflection: Maintains both short-term reflec- tion (before crossover) and long-term reflection (accumu- lated insights for mutation), applied to the entire ensem- ble. Algorithm 8: ReEvo-Batch Workflow 1: Input: Target LLH IDs h 1 ,...,h n , Population size M 2: Initialize:Population P← (h 1 ,...,h n ) 1 ,..., (h 1 ,...,h n ) M 3: Long-term reflectionR long ←∅ 4: while not converged do 5: Evaluate: Compute ensemble fitness for all individu- als (parallel) 6: Selection: Select parent pairs fromP 7: for each parent pair (P 1 ,P 2 ) do 8:Short-termReflection: r short ← Reflector(P 1 ,P 2 ) 9:Crossover: P new ← Generator(P 1 ,P 2 ,r short ) 10: end for 11: Long-termReflection: R long ← Reflector(R long ,r short ) 12: ElitistMutation:P mutated ← Generator(P ∗ ,R long ) 13: Update:P ← Select(P ∪P new ∪P mutated ) 14: end while 15: Return: Best ensemble P ∗ ∈P • Single-Pass Generation: During evolutionary operators (crossover and mutation), the LLM processes and gener- ates code for all heuristics in the ensemble within a single prompt-response cycle, rather than updating them one by one. • Parallel Evaluation: Uses ProcessPoolExecutor for effi- cient parallel fitness evaluation of ensemble individuals. EoH-Single, EoH-Split, and EoH-Batch EoH-Single fol- lows the standard EoH setting and evolves one target LLH with one population and one evaluator. EoH-Split launches an independent EoH-Single search for each selected LLH and combines the best resulting functions after all runs ter- minate; populations, prompts, and fitness feedback are not shared across targets. EoH-Batch is a portfolio-level exten- sion in which each individual contains all target LLHs, its natural-language description summarizes the complete port- folio, and its fitness is obtained by evaluating the complete ensemble in the target framework. EoH-Batch retains the E1, E2, M1, and M2 operator semantics, rank-based parent se- lection, and elitist population survival of EoH, but changes the individual representation from one function to a set of functions generated in a single LLM response. E.5 Comparison with MuEvo The batch baselines generate ensembles of LLHs in a single- pass manner, but differ fundamentally from MuEvo in how they handle the expanded search space: • Batch Baselines (EoH-Batch, MCTS-AHD-Batch, and ReEvo-Batch): These methods treat the ensemble as a single atomic unit. All target heuristics are generated or updated simultaneously in one LLM response. While this exposes the complete ensemble to the model, it requires Algorithm 9: ADAPHH Workflow 1: Initialize: Phase weights, Quality Index (QI), Tabu list T ←∅ 2: while not converged do 3: Learning Phase: Update QI for single heuristics 4: Subset Selection: Exclude heuristics with poor QI 5: Relay Hybridization: 6: Select heuristic h i based on performance memory 7: Select successor h j based on transition probability P (h j |h i ) 8: Apply sequence (h i ,h j ) to solution S 9: Acceptance: Accept if improving or via Simulated Annealing 10: Update performance metrics and transition probabili- ties 11: Tabu Mechanism: Move stagnating heuristics toT 12: end while each evolutionary step to search over the joint code space of all target heuristics. • MuEvo: Employs LLM-Driven Co-Evolution, maintain- ing separate component populations while coordinating them through Cross-Component Information Sharing, Relation-Guided Pair Evolution, Multi-Ensemble Eval- uation, and Adaptive Budget Allocation. F Details of Selection Hyper-Heuristics (SHH) This section details the four Selection Hyper-Heuristic (SHH) algorithms used in our cross-controller generaliza- tion experiments. These algorithms represent diverse search paradigms: adaptive dynamic heuristic sets (ADAPHH), on- line learning automata (HAHA), offline racing (NAHH), and variable neighborhood search (VNSTW). We use Python ports of the released CHeSC implementa- tions and retain their default controller constants. For every portfolio comparison, the original and evolved LLH ensem- bles use the same instance, solver seed, and time limit; only the LLH implementations are exchanged. The transfer ex- periments do not retrain or retune any controller. Algorithm- specific fixed schedules are shown below, including HAHA’s seven parallel offspring and NAHH’s phase fractions. F.1 ADAPHH (Adaptive Dynamic Heuristic Set) ADAPHH (Mısır et al. 2012) introduces an adaptive mech- anism to maintain a dynamic subset of high-performing heuristics. It employs Relay Hybridization to discover ef- fective heuristic pairs and learning automata for selection. F.2 HAHA (History-based Adaptive Heuristic Allocation) HAHA (Lehrbaum and Musliu 2012) is an online-learning selection hyper-heuristic that alternates between a serial search phase on a single working solution and a parallel search phase over several mutated candidate solutions. It maintains quality scores for local-search heuristics, applies Algorithm 10: HAHA Workflow (paper-faithful, simplified) 1: Init: Create ringbuffer b; initialise heuristic qualities q; sort local-search heuristics LS by decreasing q. 2: s work ← InitialiseLSQualities(), s best ← s work . 3: while time not expired do 4: b.add(s work ) 5: SerialSearch:s work ← SerialSearch(s work ,LS,q,b) 6: Generate Mutations: create m mutated offsprings s 1 ,...,s m from s work (paper uses m = 7) roulette-wheel over mutation qualities 7: Parallel Search: apply scheduled local search to each s i ; 8: if a global improvement (s i better than s best ) is found then 9: s best ← s i , s work ← s i ; abort parallel search and continue 10: end if 11: Working Solution Selection: if no global improve- ment, set s work ← SelectSolution(s 1 ,...,s m ) 12: end while 13: return s best them in decreasing-quality order, periodically updates these qualities, and uses a solution ringbuffer to avoid cycling. 3 F.3 NAHH (Non-Adaptive Hyper-Heuristic) NAHH (Mascia and Stützle 2012) leverages an offline config- uration or "racing" phase to select a static subset of heuristics or a fixed sequence that performs best on training instances, then applies it during the search. F.4 VNSTW (Variable Neighborhood Search with Time Windows) VNSTW (Hsiao, Chiang, and Fu 2012) adapts the classic VNS by dynamic management of neighborhood ordering and shaking intensities. G Benchmark Datasets This appendix details the dataset configurations utilized in our multi-heuristic experiments, covering TSP, Bin Packing, Flowshop, and CVRP domains. G.1 TSP We use TSPLib benchmark instances (Reinelt 1991) orga- nized into four test sets categorized by instance size. All instances use Euclidean distance and contain optimal or best- known solutions for performance evaluation. Test Sets We evaluate on four progressively larger test sets to assess scalability and generalization: TSP-S (directory FtsplibSS; Extra Small), TSP-S (directory FtsplibS; Small), TSP-M (directory FtsplibM; Medium), and TSP- L (directory FtsplibL; Large). Table 12 consolidates all 112 test instances. Algorithm 11: NAHH Workflow 1: Input: target instance I, low-level heuristics H, total time budget T 2: Offline (before deployment): prepare a small pool of fixed-parameter schemata S = s 1 ,...,s K tuned on sample domains 3: Phase 1 (LLH analysis,≤ 0.075T): 4: for each h∈H do 5: Run h on several random starts; record median run- time t h and median quality q h 6: end for 7: Compute non-dominated setH ′ ⊆ H using dominance on (t h ,q h ); keep at least the two best-quality heuristics 8: Obtain the best solution found so farS best from this phase 9: Phase 2 (Schema selection by online race, up to 0.25T): 10: Active setA←S; initialise all schemata from S best 11: while|A| > 1 and time used in Phase 2 < 0.25T do 12: for each schema s∈A (interleaved) do 13:Runs for a short slice of time (e.g., 0.025·(T−T 1 )) using heuristics inH ′ 14:Update its best-achieved quality 15: end for 16: Eliminate the worst-performing schema fromA 17: end while 18: Let s ⋆ be the remaining (or best-so-far) schema 19: Phase 3 (Run): 20: Execute s ⋆ for the remaining time budget usingH ′ 21: Return: best solution found G.2 Bin Packing We utilize a diverse collection of Bin Packing Problem (BPP) instances from well-known benchmarks, including datasets from Scholl (Scholl, Klein, and Jürgens 1997), Schw- erin (Schwerin and Wäscher 1997), and Falkenauer (Falke- nauer 1996). All instances are 1D Bin Packing problems where the goal is to minimize the number of bins used. Test Sets We evaluate on four distinct test sets covering varied problem characteristics: Scholl Set 3 (Hard), Schwerin Set 3, Falkenauer U (Uniform), and Falkenauer T (Triplets). Table 13 consolidates all instances. G.3 Flowshop We utilize standard Flowshop Scheduling benchmarks VRF (Vallada, Ruiz, and Framinan 2015). All instances aim to minimize the maximum completion time (Makespan). Test Sets We evaluate on four test sets categorized by job count (20, 40, 60, 100), encompassing various machine con- figurations. We report these sets as VRF20, VRF40, VRF60, and VRF100, while the underlying instance filenames use the VFR prefix. Table 14 summarizes the test instances. G.4 CVRP The Capacitated Vehicle Routing Problem (CVRP) experi- ments utilize classical benchmark instances from the liter- ature, including the sets by Augerat (Augerat et al. 1995) Algorithm 12: VNSTW Workflow 1: Initialize: Neighborhoods N 1 ,...,N k , Ordering π 2: Select random initial solution S 3: while not converged do 4: k ← 1 5: while k ≤ k max do 6:Shaking: Generate S ′ in neighborhood N π(k) (S) 7:Local Search: S ′ ← LocalSearch(S ′ ) 8:Move: 9:if f (S ′ ) < f (S) then 10:S ← S ′ 11:k ← 1 (Reset neighborhood) 12:else 13:k ← k + 1 (Next neighborhood) 14:end if 15:Adaptation: Update success counts for N π(k) 16:Periodically reorder π based on success rates 17: end while 18: end while and Christofides (Christofides 1979). These instances span a wide range of customer distributions, service node counts, and vehicle capacities. Test Sets Evaluation is performed on four standard bench- mark sets. In the instance naming convention (e.g., A-n32- k5), the number following “n” denotes the total number of nodes, including one depot, while “k” denotes the number of available vehicles. Thus, the number of service nodes is n− 1. These sets cover varied spatial distributions and de- mand/capacity ratios. Table 9: MuEvo hyperparameters used in the reported experiments. MechanismParameterValue Component probingActive components after probing, K A 3 Dynamic component lifecycleGlobal-stagnation threshold for activation, τ stag 1 round Minimum interval between activations, τ int 2 rounds Consecutive gate rejections before Active-to-Inactive transition, τ reject 2 Inactive reactivation cooldown, L cool 3 rounds Active-to-Inactive stagnation threshold4 selections Force-select a newly activated componentYes, for one round Multi-Ensemble EvaluationContext weights (Best, Initial, Secondary)(0.6, 0.2, 0.2) Solver-run allocation (Best, Initial, Secondary)(4, 3, 3) of 10 Worst-context coefficient, λ min 0.2 Cross-context variation coefficient, λ var 0.1 Acceptance threshold for R i 0 Require improvement in the Best contextYes Context evaluation orderBest, Initial, Secondary Ensemble archive size8 Minimum archive diversity for Secondary context0.25 Cross-Component Information Sharing Maximum stored replacement events200 Recent events included per target6 Minimum events before updating an LLM relation summary2 Relation-summary update interval / evidence window2 rounds / 8 events Maximum relation-context / summary lengths2,000 / 1,600 characters Relation-summary temperature / output limit0.8 / 900 tokens Relation-Guided Pair EvolutionPair-evolution interval, q2 regular rounds First eligible pair round / maximum pair events2 / 5 Conservative remaining-budget guard3 FEs Pair failure penalty / accepted-pair bonus0.30 / 0.20 Repeated failures before pair cooldown / cooldown length2 / 3 rounds Pair-generation temperature / output limit0.8 / 4,096 tokens Maximum format-repair requests1 Maximum preflight-repair requests2 Adaptive Budget AllocationImprovement-rate weight, w I 0.40 Fitness-variance weight, w V 0.30 Stagnation weight / saturation horizon, w S ,H z 0.05 / 5 selections Recent-reward weight / history window, w R ,H r 0.25 / 5 selections Effective allocation-frequency penalty, w ρ 0.40 Non-positive-reward streak penalty / saturation0.20 / 3 selections Table 10: Cross-controller generalization. Values report average cost or bins and optimality gap (%) for the original and MuEvo- evolved LLH ensembles. DomainTSPBin Packing DatasetTSP-SSTSP-STSP-MTSP-LFalkenauer_UFalkenauer_TScholl_3Schwerin MethodCost (Gap)↓Cost (Gap)↓Cost (Gap)↓Cost (Gap)↓Bins (Gap)↓Bins (Gap)↓Bins (Gap)↓Bins (Gap)↓ ADAPHH-Ori30211.7 (1.875%) 26504.9 (4.756%) 92521.4 (5.765%) 44680.6 (7.157%)190.667 (0.754%) 82.9958 (6.484%) 58.1800 (3.530%) 20.3467 (2.166%) ADAPHH-Evo29935.8 (0.651%) 25815.0 (2.141%) 90672.5 (3.657%) 43909.0 (5.237%)189.017 (0.051%) 78.4667 (2.159%) 56.4000 (0.360%) 20.0067 (0.394%) HAHA-Ori30081.4 (1.348%) 26327.7 (4.201%) 92501.6 (5.795%) 45148.7 (8.170%)190.104 (0.491%) 80.8667 (4.117%) 57.2700 (1.910%) 20.1400 (1.095%) HAHA-Evo29948.0 (0.648%) 25902.3 (2.402%) 91948.4 (5.251%) 44878.9 (8.067%)189.496 (0.227%) 78.5292 (2.343%) 56.4200 (0.668%) 19.9667 (0.159%) NAHH-Ori30038.2 (1.137%) 26751.0 (5.679%) 95271.6 (8.944%) 46179.8 (11.096%)190.054 (0.362%) 80.3167 (3.580%) 56.6300 (0.771%) 20.0300 (0.532%) NAHH-Evo29930.4 (0.581%) 26008.0 (2.747%) 92108.6 (5.337%) 45925.2 (10.307%)189.371 (0.160%) 78.6625 (2.423%) 56.4000 (0.361%) 20.0067 (0.402%) VNSTW-Ori30137.3 (1.470%) 26567.5 (4.905%) 93985.0 (9.134%) 49204.5 (18.149%)191.238 (0.674%) 80.1958 (3.488%) 56.6700 (0.844%) 20.1467 (1.126%) VNSTW-Evo29956.8 (0.701%) 26076.5 (3.253%) 92168.9 (5.591%) 44443.1 (6.741%)189.317 (0.154%) 78.5042 (2.328%) 56.4000 (0.361%) 20.1000 (0.897%) Table 11: Target selection and main-search budgets of the multi-heuristic baseline adaptations. The preliminary pre- search budget is reported separately in Appendix C. ModeTargetsSearchesTotal FEs SingleTop-1One 100-FE search100 BatchTop-3One joint 100-FE search100 SplitTop-3Three independent 100-FE searches 300 Table 12: The 112 test instances in TSP-S, TSP-S, TSP-M, and TSP-L. TSP-S (FtsplibSS; 47 instances; 100–500 cities) a280 (280)bcl380 (380)bier127 (127)ch130 (130)ch150 (150) d198 (198)d493 (493)eil101 (101)fl417 (417)gil262 (262) kroA100 (100)kroA150 (150)kroA200 (200)kroB100 (100)kroB150 (150) kroB200 (200)kroC100 (100)kroD100 (100)kroE100 (100)lin105 (105) lin318 (318)linhp318 (318)pbk411 (411)pbl395 (395)pbm436 (436) pbn423 (423)pcb442 (442)pka379 (379)pma343 (343)pr107 (107) pr124 (124)pr136 (136)pr144 (144)pr152 (152)pr226 (226) pr264 (264)pr299 (299)pr439 (439)qa194 (194)rat195 (195) rd100 (100)rd400 (400)ts225 (225)tsp225 (225)u159 (159) xqf131 (131)xqg237 (237) TSP-S (FtsplibS; 15 instances; 500–1000 cities) d657 (657)dkg813 (813)lim963 (963)lu980 (980)p654 (654) pbd984 (984)rat575 (575)rat783 (783)rbu737 (737)rbx711 (711) u574 (574)u724 (724)uy734 (734)xql662 (662)zi929 (929) TSP-M (FtsplibM; 29 instances; 1000–2000 cities) d1291 (1291)d1655 (1655)dca1389 (1389) dcc1911 (1911) dja1436 (1436) djc1785 (1785)dka1376 (1376) dkd1973 (1973) fl1400 (1400)fl1577 (1577) fnb1615 (1615) fra1488 (1488)icw1483 (1483) mu1979 (1979) nrw1379 (1379) pcb1173 (1173) pr1002 (1002)rbv1583 (1583) rby1599 (1599) rl1304 (1304) rl1323 (1323)rl1889 (1889)rw1621 (1621)u1060 (1060)u1432 (1432) u1817 (1817)vm1084 (1084) vm1748 (1748) xit1083 (1083) TSP-L (FtsplibL; 21 instances; 2000–5000 cities) bch2762 (2762) bck2217 (2217) beg3293 (3293) bva2144 (2144) d2103 (2103) dbj2924 (2924) dcb2086 (2086) dea2382 (2382) djb2036 (2036) irw2802 (2802) ley2323 (2323)lsm2854 (2854) mlt2597 (2597) pds2566 (2566) pr2392 (2392) rbw2481 (2481) u2152 (2152)u2319 (2319)xpr2308 (2308) xqc2175 (2175) xva2993 (2993) Table 13: Combined Bin Packing Test Instances (Scholl, Schwerin, Falkenauer U/T). Instance (Detail: C=Cap, N=Items, [Range])Instance (Detail: C=Cap, N=Items, [Range]) Scholl Set 3 (Hard) – 10 instances HARD0 (C=100000, N=200, [20114-34978])HARD1 (C=100000, N=200, [20008-34991]) HARD2 (C=100000, N=200, [20009-34953])HARD3 (C=100000, N=200, [20033-34746]) HARD4 (C=100000, N=200, [20139-35000])HARD5 (C=100000, N=200, [20000-34955]) HARD6 (C=100000, N=200, [20050-34973])HARD7 (C=100000, N=200, [20017-34808]) HARD8 (C=100000, N=200, [20091-34992])HARD9 (C=100000, N=200, [20081-34991]) Schwerin Set 3 – 30 instances Schwerin1_BPP1 (C=1000, N=100, [150-200])Schwerin1_BPP10 (C=1000, N=100, [150-200]) Schwerin1_BPP11 (C=1000, N=100, [150-200])Schwerin1_BPP12 (C=1000, N=100, [150-200]) Schwerin1_BPP13 (C=1000, N=100, [150-199])Schwerin1_BPP14 (C=1000, N=100, [150-200]) Schwerin1_BPP15 (C=1000, N=100, [150-199])Schwerin1_BPP2 (C=1000, N=100, [150-200]) Schwerin1_BPP3 (C=1000, N=100, [150-200])Schwerin1_BPP4 (C=1000, N=100, [150-200]) Schwerin1_BPP5 (C=1000, N=100, [150-200])Schwerin1_BPP6 (C=1000, N=100, [150-200]) Schwerin1_BPP7 (C=1000, N=100, [150-200])Schwerin1_BPP8 (C=1000, N=100, [150-200]) Schwerin1_BPP9 (C=1000, N=100, [150-200])Schwerin2_BPP1 (C=1000, N=120, [151-200]) Schwerin2_BPP10 (C=1000, N=120, [150-199])Schwerin2_BPP11 (C=1000, N=120, [150-200]) Schwerin2_BPP12 (C=1000, N=120, [150-200])Schwerin2_BPP13 (C=1000, N=120, [150-200]) Schwerin2_BPP14 (C=1000, N=120, [150-200])Schwerin2_BPP15 (C=1000, N=120, [151-200]) Schwerin2_BPP2 (C=1000, N=120, [150-200])Schwerin2_BPP3 (C=1000, N=120, [150-200]) Schwerin2_BPP4 (C=1000, N=120, [150-200])Schwerin2_BPP5 (C=1000, N=120, [150-200]) Schwerin2_BPP6 (C=1000, N=120, [150-200])Schwerin2_BPP7 (C=1000, N=120, [151-200]) Schwerin2_BPP8 (C=1000, N=120, [150-200])Schwerin2_BPP9 (C=1000, N=120, [150-200]) Falkenauer U (Uniform) – 24 instances Falkenauer_u1000_00 (C=150, N=1000, [20-100]) Falkenauer_u1000_01 (C=150, N=1000, [20-100]) Falkenauer_u1000_02 (C=150, N=1000, [20-100]) Falkenauer_u1000_03 (C=150, N=1000, [20-100]) Falkenauer_u1000_04 (C=150, N=1000, [20-100]) Falkenauer_u1000_05 (C=150, N=1000, [20-100]) Falkenauer_u120_00 (C=150, N=120, [20-98])Falkenauer_u120_01 (C=150, N=120, [20-100]) Falkenauer_u120_02 (C=150, N=120, [20-100])Falkenauer_u120_03 (C=150, N=120, [20-100]) Falkenauer_u120_04 (C=150, N=120, [20-99])Falkenauer_u120_05 (C=150, N=120, [20-100]) Falkenauer_u250_00 (C=150, N=250, [20-100])Falkenauer_u250_01 (C=150, N=250, [20-100]) Falkenauer_u250_02 (C=150, N=250, [20-100])Falkenauer_u250_03 (C=150, N=250, [20-100]) Falkenauer_u250_04 (C=150, N=250, [20-100])Falkenauer_u250_05 (C=150, N=250, [20-100]) Falkenauer_u500_00 (C=150, N=500, [20-100])Falkenauer_u500_01 (C=150, N=500, [20-100]) Falkenauer_u500_02 (C=150, N=500, [20-100])Falkenauer_u500_03 (C=150, N=500, [20-100]) Falkenauer_u500_04 (C=150, N=500, [21-100])Falkenauer_u500_05 (C=150, N=500, [20-100]) Falkenauer T (Triplets) – 24 instances Falkenauer_t120_00 (C=1000, N=120, [250-497]) Falkenauer_t120_01 (C=1000, N=120, [250-498]) Falkenauer_t120_02 (C=1000, N=120, [250-499]) Falkenauer_t120_03 (C=1000, N=120, [250-499]) Falkenauer_t120_04 (C=1000, N=120, [250-499]) Falkenauer_t120_05 (C=1000, N=120, [250-499]) Falkenauer_t249_00 (C=1000, N=249, [250-498]) Falkenauer_t249_01 (C=1000, N=249, [250-499]) Falkenauer_t249_02 (C=1000, N=249, [250-496]) Falkenauer_t249_03 (C=1000, N=249, [250-499]) Falkenauer_t249_04 (C=1000, N=249, [250-499]) Falkenauer_t249_05 (C=1000, N=249, [250-499]) Falkenauer_t501_00 (C=1000, N=501, [250-498]) Falkenauer_t501_01 (C=1000, N=501, [250-498]) Falkenauer_t501_02 (C=1000, N=501, [250-499]) Falkenauer_t501_03 (C=1000, N=501, [250-499]) Falkenauer_t501_04 (C=1000, N=501, [250-499]) Falkenauer_t501_05 (C=1000, N=501, [250-498]) Falkenauer_t60_00 (C=1000, N=60, [251-495])Falkenauer_t60_01 (C=1000, N=60, [251-475]) Falkenauer_t60_02 (C=1000, N=60, [250-498])Falkenauer_t60_03 (C=1000, N=60, [250-495]) Falkenauer_t60_04 (C=1000, N=60, [250-498])Falkenauer_t60_05 (C=1000, N=60, [250-496]) Table 14: Combined Flowshop test instances (VRF20, VRF40, VRF60, and VRF100). VRF20 (20 Jobs)VRF40 (40 Jobs) Instance GroupCount Instance GroupCount VFR20_5_1..1010VFR40_5_1..1010 VFR20_10_1..10 10VFR40_10_1..1010 VFR20_15_1..10 10VFR40_15_1..1010 VFR20_20_1..10 10VFR40_20_1..1010 VRF60 (60 Jobs)VRF100 (100 Jobs) Instance GroupCount Instance GroupCount VFR60_5_1..1010VFR100_20_1..10 10 VFR60_10_1..10 10VFR100_40_1..10 10 VFR60_15_1..10 10VFR100_60_1..10 10 VFR60_20_1..10 10 Table 15: CVRP Test Sets overview. SetSourceService Nodes Vehicle Capacity Set A Augerat et al. (1995)31–79100 Set B Augerat et al. (1995)30–77100 Set P Augerat et al. (1995)15–10040–350 CMT Christofides (1979)50–199140–200 Table 16: Complete list of the 88 CVRP test instances. A (27)B (23)P (24)CMT (14) A-n32-k5B-n31-k5P-n16-k8CMT1 A-n33-k5B-n34-k5P-n19-k2CMT2 A-n33-k6B-n35-k5P-n20-k2CMT3 A-n34-k5B-n38-k6P-n21-k2CMT4 A-n36-k5B-n39-k5P-n22-k2CMT5 A-n37-k5B-n41-k6P-n22-k8CMT6 A-n37-k6B-n43-k6P-n23-k8CMT7 A-n38-k5B-n44-k7P-n40-k5CMT8 A-n39-k5B-n45-k5P-n45-k5CMT9 A-n39-k6B-n45-k6P-n50-k7CMT10 A-n44-k6B-n50-k7P-n50-k8CMT11 A-n45-k6B-n50-k8P-n50-k10 CMT12 A-n45-k7B-n51-k7P-n51-k10 CMT13 A-n46-k7B-n52-k7P-n55-k7CMT14 A-n48-k7B-n56-k7P-n55-k8 A-n53-k7B-n57-k7P-n55-k10 A-n54-k7B-n57-k9P-n55-k15 A-n55-k9B-n63-k10 P-n60-k10 A-n60-k9B-n64-k9P-n60-k15 A-n61-k9B-n66-k9P-n65-k10 A-n62-k8B-n67-k10 P-n70-k10 A-n63-k9B-n68-k9P-n76-k4 A-n63-k10 B-n78-k10 P-n76-k5 A-n64-k9P-n101-k4 A-n65-k9 A-n69-k9 A-n80-k10

Instant research discovery