从并行进化到分布式进化计算读 A Survey on Distributed Evolutionary Computation

我们究竟在谈什么：从并行进化到分布式进化计算

——读 A Survey on Distributed Evolutionary Computation

最近在梳理并行与分布式进化算法的文献时，我反复遇到一个看似只是命名、实际上涉及研究边界的问题：一个算法同时运行多个种群，能否称为分布式进化算法？如果这些种群采用不同的搜索策略，并且周期性交换最优解，它究竟属于异构并行进化、协同并行进化，还是分布式协同进化？

这并非无关紧要的文字游戏。一个方法叫什么，隐含了作者对研究问题、算法结构和实验责任的判断。称其为“并行”，就应当说明并发执行方式及其效率收益；称其为“分布式”，就需要交代计算节点、通信拓扑和信息交换；称其为“协同进化”，则要说明不同种群究竟在协同什么，以及局部搜索如何形成全局解。术语不是论文标题上的装饰，而是方法机制的压缩表达。

也正因为如此，Feng-Feng Wei、Wei-Neng Chen、Tian-Fang Zhao、Kay Chen Tan 和 Jun Zhang 于 2025 年发表在 IEEE Computational Intelligence Magazine 上的综述 A Survey on Distributed Evolutionary Computation 值得认真阅读[1]。在我看来，这篇文章真正重要的地方并不是又汇总了一批 GPU、集群、岛模型和多智能体算法，而是试图澄清“distributed”长期以来被混用的两层含义：计算过程的分布与问题信息的分布。

理解这一区分，几乎是理解整个分布式进化计算领域的钥匙。

一、同一个“分布式”，其实对应两类完全不同的问题

经典的并行进化计算大多面对一个完整而集中的优化问题。决策变量是什么、目标函数如何计算、约束条件有哪些，所有计算节点原则上都能够访问。之所以使用多核、GPU 或计算集群，只是因为适应度评价太昂贵、搜索空间太大，或者希望多个子种群同时探索不同区域。

在这种情况下，问题本身没有被分散，被分散的是计算任务。不同处理器可以并行评价不同个体，也可以分别维护多个子种群，但它们看到的是同一个问题，追求的也是同一个全局目标。分布式计算在这里是一种提高效率和扩展性的手段。

另一类问题则不同。随着物联网、边缘计算、智能电网和多智能体系统的发展，数据、变量和目标评价往往天然属于不同主体。不同节点可能出于带宽、隐私、所有权或物理部署的原因，无法把局部信息上传到一个中心。任何一个节点都看不到完整问题，却又必须与其他节点合作，才能获得对整个系统有意义的解。

此时，分布式不再只是实现方式，而是问题本身的结构属性。算法面对的核心困难也不再只是“如何更快”，而变成“如何让掌握局部信息的主体形成全局智能”。

综述据此概括了分布式进化计算的两种主要目的：

对集中式优化问题，利用并行和分布式计算提高搜索效率；对分布式优化问题，协调只拥有部分信息的个体、子种群或智能体，实现全局优化。

这两条路线都可以被纳入广义的 Distributed Evolutionary Computation，但它们不能在论文表述中不加区分。前者首先是并行计算问题，后者首先是信息不完备条件下的协同优化问题。

这里有一个很容易被忽略、却十分关键的判断：集中式优化并不等于单机优化，分布式优化也不等于多机运行。一个问题即使运行在数十台服务器上，只要所有节点共享完整数据、变量和目标，它仍然是集中式优化；相反，一个只有十几个边缘节点的小系统，只要节点之间不能共享完整信息，也可能是真正的分布式优化。

因此，判断一个方法是否属于分布式优化，不应先问“用了几台机器”，而应先问：全局信息究竟掌握在谁手中？

二、与其先看硬件，不如先看信息在哪里

综述用一个一般优化模型来说明这一点：

[
\min_{X\in\Omega} F(X;D), \qquad \text{s.t. } G(X;D)\le 0,
]

其中，(X) 是决策变量，(D) 是环境或样本数据，(F) 是目标函数，(G) 表示约束。如果这些信息均可被所有节点访问，问题就是集中式的；如果某类关键信息只能被局部主体访问，则可以根据被分散的信息，区分数据分布式、维度分布式和目标分布式优化。

数据分布式：不能集中的是数据

数据分布式优化是目前最容易理解的一类。医院、企业、传感器或边缘设备分别持有本地数据，但这些数据不能直接汇总。每个节点只能利用自己的数据建立局部模型，再通过参数、代理模型或知识的交换来改进全局搜索。

联邦数据驱动进化优化正是这一思路的代表。局部节点基于本地数据训练代理模型，中心节点聚合这些模型，并将形成的全局知识反馈给各节点，以辅助后续进化[8][9]。原始数据不离开本地，并不意味着问题已经解决。现实数据通常并非独立同分布，不同节点的数据规模、噪声、类别比例和缺失属性也可能完全不同。一个在本地预测准确的模型，未必能够代表全局搜索景观。

更进一步，即使不传输原始数据，模型参数、适应度信息和候选解也可能泄露隐私。因此，联邦只是降低数据集中化风险的一种组织方式，并不自动构成严格的隐私保护。安全聚合、差分隐私、加密计算和恶意节点识别，仍然需要与进化搜索共同设计。

维度分布式：不能集中的是决策权

维度分布式优化中，不同智能体只控制完整决策向量的一部分。例如，智能电网中的不同节点只能调整本地设备状态，无人系统中的不同个体只能决定自己的动作。每个节点都能作出局部决策，但这些决策共同决定全局目标。

这类问题表面上很像合作协同进化，因为二者都把完整变量向量分成若干部分。然而二者的出发点不同。合作协同进化通常是算法主动分解一个集中式大规模问题，以降低搜索难度；维度分布式优化中的变量归属则往往由设备所有权、控制权限或物理结构预先决定，算法不能为了方便而任意重新分组。

如果不同节点控制的变量互不重叠，局部解可以相对直接地组合；一旦存在共享变量，问题就会复杂得多。一个节点对共享变量的改进，可能损害另一个节点的局部目标。此时，算法需要的不只是合作，还包括冲突检测、信用分配和共识机制。

目标分布式：不能集中的是评价能力

目标分布式优化中，不同节点分别掌握不同目标或约束的评价能力。汽车结构优化就是一个典型例子：振动、噪声和碰撞安全性可能依赖不同仿真软件，由不同计算平台完成。任何单一节点都不能立即获得完整目标向量，多个评价主体必须协同，才能形成对候选设计的整体判断。

这里需要特别谨慎地区分“多目标”与“目标分布式”。如果所有目标都能在同一节点计算，那么它只是普通多目标优化；只有目标信息或评价能力确实分散时，才构成目标分布式问题。

此外，目标之间还可能存在两种不同关系。一种是协作关系：不同节点提供完整评价的不同部分，共同寻找 Pareto 前沿；另一种是冲突关系：每个节点都有自己的局部目标，局部改进并不保证全局改进。后一种情形更接近多智能体共识优化，其理论难度也明显更高。

现实问题往往同时分散多类信息。例如，不同微电网既持有本地数据，又控制局部变量，还具有各自的成本函数。这类混合信息分布问题，才是未来分布式进化计算真正困难、也更有应用价值的部分。

三、问题、环境、通信与算法结构，不应被放在同一层面理解

原综述从问题类型、实现环境、通信模型和算法结构四个维度构建分类框架。这一框架很有启发性，但在阅读时，我更愿意把它理解为一个有先后顺序的判断过程，而不是四组平行标签。

首先确定问题信息是否集中，这是问题层。其次选择算法部署在多处理器、GPU、集群、云端还是边缘节点，这是环境层。然后确定节点怎样连接、由谁协调、何时交换信息，这是通信层。最后才是算法层：究竟并行评价个体，还是让多个种群演化完整问题、不同子问题或不同目标。

这个顺序不能颠倒。因为同一种硬件环境可以承载完全不同的问题，同一种通信模型也可以服务于不同算法结构。

云计算就是最典型的例子。如果云中的多个实例访问同一个数据库，它只是集中式问题的云端并行实现；如果不同服务器分别保留本地数据，只交换模型或统计量，它才属于数据分布式优化。不能因为论文中出现了 cloud、edge 或 multi-agent，就直接把方法归入分布式优化。

同样，主从模型既可以把单个适应度评价分派给工作节点，也可以让每个工作节点维护完整子种群；岛模型通常是粗粒度多种群并行，但岛屿是否运行在同一台机器、不同 GPU 或不同网络节点上，又属于实现层的问题。

一篇论文如果只写“we propose a distributed evolutionary algorithm”，却没有说明信息所有权、并行任务、通信拓扑和节点角色，那么“distributed”实际上没有提供足够的学术信息。

四、多个子种群并行，并不意味着它们在做同一类协同

这篇综述中，我认为对当前大规模优化研究最有用的部分，是它区分了面向整体进化的子种群并行、面向子问题的协同进化，以及面向目标的协同进化。很多论文都使用多个种群，却没有充分说明这些种群为何存在、各自在搜索什么。

第一类：多个子种群都搜索完整问题

在面向整体进化的子种群并行中，总体被划分为多个子种群，但每个子种群仍然在完整搜索空间中演化。它们可能采用不同初始化、参数、邻域结构或搜索算子，并通过迁移共享个体。

岛模型属于这一类最典型的实现。它的价值并不只是把种群放到不同处理器上，而是让不同岛屿在一段时间内保持相对独立，从而延缓全局同质化。迁移过于频繁，所有岛屿很快会围绕同一批精英解收缩，多种群就失去了意义；迁移过少，有价值的信息又难以及时传播。

因此，这类方法的核心矛盾是：既要允许不同种群形成各自的搜索经验，又要在适当时机共享真正有价值的信息。

如果不同子种群采用明显不同的进化算法、局部搜索或邻域偏好，那么“异构”是一个有意义的修饰词。但异构不能只意味着更换几个参数或随机种子。只有当不同分支在探索能力、开发能力、约束处理或问题结构利用上承担可辨识的不同角色时，异构协同才构成方法贡献。

第二类：不同子种群只优化完整问题的一部分

面向子问题的协同进化采用的是另一套逻辑。原问题首先被分解为多个子问题，不同子种群只负责部分变量。局部候选解本身并不完整，必须与其他子种群的代表个体组合后，才能获得全局适应度。

合作协同进化的困难从来不只是“分而治之”，而是怎样正确地分，以及分开之后怎样重新建立联系。

对于可分问题，随机分组可能已经足够；对于变量之间存在强耦合的问题，错误分组会切断关键依赖，使任何局部优化都难以转化为全局改进。差分分组及其后续变体之所以受到广泛关注，正是因为它们试图从函数响应中识别变量交互[7]。

分解之后还存在协同适应问题。评价一个局部个体时，究竟与其他子问题的最优个体、随机个体还是精英池成员组合，会产生不同的搜索偏差。最优协作者有利于快速收敛，却容易形成路径依赖；随机协作者能够增加多样性，但会给适应度评价带来较大噪声。所谓协同进化，真正困难的部分往往就在这些看似细小的代表选择机制中。

因此，多个种群同时运行并不自动等于 cooperative coevolution。只有当各子种群优化的是相互依赖的子问题，并通过协同评价形成完整解时，使用这一术语才准确。

第三类：不同子种群分别承担不同目标

面向目标的协同进化更少见，也更难处理。不同种群分别关注不同目标或约束，但没有任何一个种群持续拥有完整目标视角。如何让局部目标上的进步共同推动全局 Pareto 前沿，是其核心问题。

当不同目标的评价时间差异较大时，异步计算还会引入评价时间偏差：容易快速完成的目标可能更频繁地影响选择，昂贵目标则长期缺席。因而，面向目标的并行不仅需要计算调度，还需要重新思考档案更新、选择压力和延迟补偿。

这三类结构的区别可以用一句话概括：

整体并行中的每个种群都在求解完整问题；子问题协同中的每个种群只产生部分解；目标协同中的每个种群只掌握部分评价。

如果论文能够把这句话说清楚，其方法归类通常就不会出现大的偏差。

五、通信并不是算法之外的“工程细节”

在不少进化算法论文中，通信只用一句“periodically exchange elite solutions”带过。这远远不够。对于分布式进化计算，通信本身就是进化机制的一部分，因为它直接改变信息传播速度、种群多样性和选择压力。

主从模型由中心节点分派任务、收集结果，控制清晰，却可能形成瓶颈；池模型允许工作节点异步读取和写回解池，减少统一等待；岛模型通过种群迁移保持多样性；元胞模型让个体只与局部邻域交互，使优良信息逐步扩散；分层模型则在不同硬件层级组合这些结构[2][3]。近年来，自适应通信进一步把“是否交换”和“何时交换”纳入搜索状态判断，而不再把迁移周期固定为外部参数[6]。

无论采用哪一种模型，都应回答四个问题：与谁通信、何时通信、传递什么，以及收到信息后如何使用。仅仅说明“存在信息交换”，并不能刻画一个分布式算法。

同步与异步的比较尤其需要克制。同步机制便于定义代际边界和复现实验，但快节点必须等待慢节点；异步机制能够减少空闲时间，更适合异构硬件和不等时评价。综述引用的部分研究发现，异步迁移在计算时间上优于同步迁移。然而，把这一结果概括为“异步优于同步”仍然过于武断。

异步算法使用的可能是过期信息，不同评价耗时还会造成繁殖机会不平等。某些解并非质量更高，只是评价得更快，于是更早、更频繁地进入种群。异步减少了等待成本，却可能增加统计偏差和收敛分析难度。严谨的研究需要同时测量时间收益、信息陈旧程度以及最终解质量，而不是只报告墙钟时间。

六、回到一个实际问题：我们的算法究竟应该叫什么？

分类框架的价值，不在于把已有论文重新放进若干格子，而在于帮助我们拒绝不准确的命名。

以大规模车辆路径问题为例。假设多个种群同时求解同一个完整 VRPTW 实例，都能访问全部客户、时间窗、容量约束和优化目标，只是采用不同的邻域或搜索策略，并周期性交换当前最优方案。从问题属性看，它仍然是集中式优化；从算法结构看，它更接近面向整体进化的子种群并行；从实现方式看，如果多个分支确实并发运行，它属于并行进化计算。

在这种情况下，Cooperative Parallel Evolutionary Framework 是一个准确而稳妥的名称。它清楚地表达了三个事实：存在多个并行搜索单元，这些单元并非彼此隔绝，而且它们通过信息交换共同改进全局解。

如果不同分支采用不同的算法、邻域或约束处理机制，并且这种差异经过消融实验验证具有互补性，那么可以进一步使用 Heterogeneous Cooperative Parallel Evolutionary Algorithm。这里的“heterogeneous”说明搜索角色不同，“cooperative”说明存在功能性协作，“parallel”说明它们真实并发。

相较之下，Distributed Cooperative Evolutionary Algorithm 是一个更强的表述。它通常会使读者期待看到相对独立的计算节点、明确的通信拓扑、迁移或消息传递机制、同步或异步协议，以及通信成本和并行扩展性。如果方法只是在单一程序中顺序调用多个搜索模块，或者虽然使用多张设备却始终依赖全局共享状态，那么“distributed”很可能夸大了方法性质。

同样，如果各子种群都构造完整路径方案，就不宜仅因为它们相互合作而称为 cooperative coevolution。只有当客户、路线或决策变量被明确分解成子问题，各子种群产生部分解，并通过协同评价合成为完整方案时，这一名称才真正成立。

我们此前考虑用“Parallel Evolutionary Algorithms—Cooperative Parallel Evolutionary Algorithms—Distributed Cooperative Evolutionary Algorithms”来组织相关工作。这条线索可以作为文献发展的叙事顺序：从并行执行，到多种群功能协作，再到独立节点上的受限通信。但必须说明，它们不是三个边界清晰、彼此排斥的大类。后两者往往是前者的特殊形式，而“distributed”又可能同时描述实现环境和问题信息。若不提前给出判别标准，这种三级分类反而会造成新的混淆。

我的看法是：与其追求一个听起来更“高级”的名称，不如让术语准确对应可验证的机制。名称越强，论文需要承担的证据责任也越大。

如果使用 parallel，应报告真实并发、硬件配置、墙钟时间、加速比和并行效率；如果使用 distributed，应进一步报告节点拓扑、通信量、同步策略和可扩展性；如果使用 cooperative，应通过独立搜索、无通信或同质化版本的消融实验，证明协作确实产生了额外价值。

七、评价 DEC，不能只看最终目标值

传统优化论文习惯比较最终目标值和运行时间，但这不足以评价一个并行或分布式进化算法。

对于集中式问题的并行求解，经典加速比为

[
R_s=\frac{T_1}{T_p},
]

其中 (T_1) 是串行运行时间，(T_p) 是使用 (p) 个处理器时的并行时间。并行效率为

[
E=\frac{R_s}{p}.
]

这些指标虽然基础，却经常被不恰当地使用。串行基线与并行版本是否采用相同评价预算？通信、数据复制和结果聚合是否计入时间？并行算法是否因为使用更多计算节点而实际执行了更多适应度评价？如果这些问题没有交代，加速比就很难解释。

对于信息本身分布的优化问题，评价维度还应进一步扩展。除了全局解质量，至少还需要考察通信频率和通信量、局部节点之间的共识误差、节点掉线和延迟下的鲁棒性、隐私泄露风险，以及节点规模增长时的可扩展性。边缘系统还需要考虑能源和存储约束。

这也是分布式进化计算与普通多种群优化真正拉开距离的地方：算法不再只对“找到多好的解”负责，还必须对“为形成这个解交换了多少信息、依赖了多少全局知识、付出了多少系统成本”负责。

八、这篇综述解决了什么，又留下了什么？

这篇论文最值得肯定的贡献，是把经典并行进化计算与新兴分布式优化放在了同一张知识地图上。早期研究主要关心怎样利用多处理器、GPU 和集群提高进化效率[2][3]；后来的合作协同进化关注大规模问题分解和计算资源分配[4][5][7]；近年来，联邦优化、边缘—云协同和多智能体共识又把隐私、信息所有权和局部自治带入进化计算[8]–[11]。这篇综述让这些看似分散的方向有了共同的讨论语言。

它提出的“按信息所有者区分集中式与分布式优化”，也是全文最有解释力的思想。很多术语争议，一旦回到信息由谁掌握、能否全局访问，便会清楚许多。

不过，这篇综述也不是这个领域的最后答案。

首先，问题、环境、通信和算法结构之间并非完全正交。同一个主从模型可以执行单个评价任务，也可以协调完整子种群；同一个云环境既能求解集中式问题，也能求解分布式问题。因此，论文中的分类更适合被理解为分析视角，而不是严格的互斥集合。

其次，文章虽然使用了“systematic review”的表述，但正文没有给出系统综述通常要求的检索数据库、检索式、纳入排除标准和文献筛选流程。它是一篇覆盖面很广、概念组织能力很强的叙述性综述，却不能据此判断不同技术路线的相对优劣。

再次，文中引用了不少并行加速和异步通信结果，但不同研究使用的硬件、评价预算、问题规模和停止条件差异很大。某篇论文中的几十倍加速不能被脱离实验条件转化为一般结论。

最后，真正面向分布式优化的进化计算仍然缺乏统一理论。通信频率如何影响收敛？局部改进何时能够保证全局改进？重叠变量和冲突目标如何达到共识？隐私保护会给最优性带来多大损失？这些问题远没有因为一套分类框架而得到解决。

因此，我更愿意把这篇综述看作一张“研究地图”，而不是一本“方法排名册”。地图的价值在于告诉我们有哪些道路、边界在哪里，以及哪些区域仍然空白；它并不替我们决定哪条道路一定更好。

九、分布式进化计算下一步真正值得研究什么？

从现有研究看，DEC 至少还有四个值得长期投入的方向。

第一是通信与收敛的统一理论。现有研究往往把通信频率、迁移规模和拓扑结构当作经验参数，而它们实际上决定了信息传播、选择压力和种群多样性。未来需要建立通信成本与优化收益之间更可解释的关系。

第二是面向异构和动态环境的算法。真实节点不会拥有完全相同的算力、数据质量和在线状态。算法需要容忍延迟、掉线、陈旧信息和 non-IID 数据，而不是只在理想同步环境中运行。

第三是隐私、安全与鲁棒性的共同设计。只保护原始数据并不足够，代理模型、目标评价、共享变量和候选解同样可能泄露信息。恶意节点还可能通过伪造局部模型或适应度操纵全局进化方向。

第四是能够经得起系统评价的真实应用。智能电网、分布式制造、无人系统和大规模组合优化都提供了重要场景，但研究不能止步于把现有算法“搬到多台机器上”。只有当算法同时处理局部自治、有限通信、实时响应和资源约束时，分布式设计才真正具有不可替代性。

结语

“分布式进化计算”之所以容易引起混淆，是因为它同时处在三个学科传统的交界处：进化计算关心搜索行为，并行计算关心资源与效率，分布式优化关心局部信息与全局一致。三者使用相似的种群、节点和通信语言，却在回答不同的问题。

读完这篇综述，我认为最应当保留的不是某张分类图，而是一种判断方法：先看问题信息是否分散，再看计算怎样部署；先问不同种群各自搜索什么，再讨论它们如何通信；最后让方法名称与实验依据保持一致。

一个好的并行进化算法，可以在更短时间内完成更大规模的搜索；一个真正的分布式进化算法，则应当在没有任何单一节点拥有完整视角的情况下，仍然让局部搜索形成可靠的全局行为。

后者更困难，也更接近分布式智能的本质：

不是让更多机器重复同一件事，而是让彼此不完整的局部认知，经过有限而有效的协作，最终产生超越任何单一节点的全局解。

---

参考文献

[1] F.-F. Wei, W.-N. Chen, T.-F. Zhao, K. C. Tan, and J. Zhang, “A Survey on Distributed Evolutionary Computation,” IEEE Computational Intelligence Magazine, vol. 20, no. 3, pp. 41–62, Aug. 2025. DOI: 10.1109/MCI.2025.3563425.

[2] E. Alba and M. Tomassini, “Parallelism and Evolutionary Algorithms,” IEEE Transactions on Evolutionary Computation, vol. 6, no. 5, pp. 443–462, 2002.

[3] Y.-J. Gong et al., “Distributed Evolutionary Algorithms and Their Models: A Survey of the State-of-the-Art,” Applied Soft Computing, vol. 34, pp. 286–300, 2015.

[4] K. C. Tan, Y. Yang, and C. K. Goh, “A Distributed Cooperative Coevolutionary Algorithm for Multiobjective Optimization,” IEEE Transactions on Evolutionary Computation, vol. 10, no. 5, pp. 527–549, 2006.

[5] Y.-H. Jia et al., “Distributed Cooperative Co-evolution with Adaptive Computing Resource Allocation for Large Scale Optimization,” IEEE Transactions on Evolutionary Computation, vol. 23, no. 2, pp. 188–202, 2019.

[6] Q. Yang et al., “A Distributed Swarm Optimizer with Adaptive Communication for Large-Scale Optimization,” IEEE Transactions on Cybernetics, vol. 50, no. 7, pp. 3393–3408, 2020.

[7] M. N. Omidvar, X. Li, Y. Mei, and X. Yao, “Cooperative Co-evolution with Differential Grouping for Large Scale Optimization,” IEEE Transactions on Evolutionary Computation, vol. 18, no. 3, pp. 378–393, 2014.

[8] X.-Q. Guo et al., “Edge–Cloud Co-evolutionary Algorithms for Distributed Data-Driven Optimization Problems,” IEEE Transactions on Cybernetics, vol. 53, no. 10, pp. 6598–6611, 2023.

[9] J. Xu, Y. Jin, W. Du, and S. Gu, “A Federated Data-Driven Evolutionary Algorithm,” Knowledge-Based Systems, vol. 233, Art. no. 107532, 2021.

[10] B. Zhao et al., “PriMPSO: A Privacy-Preserving Multiagent Particle Swarm Optimization Algorithm,” IEEE Transactions on Cybernetics, vol. 53, no. 11, pp. 7136–7149, 2023.

[11] F.-F. Wei et al., “Distributed and Expensive Evolutionary Constrained Optimization with On-Demand Evaluation,” IEEE Transactions on Evolutionary Computation, vol. 27, no. 3, pp. 671–685, 2023.

---

排版说明：原论文图表受 IEEE 版权保护。公开发布时建议依据本文内容重新绘制概念图，并注明“根据 Wei et al. (2025) 的分类框架整理”，不直接使用论文截图。