演化对象指的是演化系统中真正被编码、变异、评价与选择的那一部分内容。经典演化算法默认这个对象只是一组数值参数；而在 GPU 与大模型共同构成的现代底座上，这条边界正在向外推开：从数值参数，到超参数与模型结构，再到算法机制与算子，最终到程序与持续存在的软件工程状态。
理解这条阶梯的关键，是同时抓住三件事：对象如何表示、受什么约束、用什么信号评价。对象每上升一层，这三件事都会同步改变。
- 数值参数层：对象是连续实向量 θ \in \mathbb{R}^d，例如学习率、权重或差分进化的变异因子。约束主要是取值范围，评价通常是一个标量目标 f(θ)。
- 超参数与模型结构层：对象含有离散选择，如层数、宽度、连接方式与数据增强策略。搜索空间变成混合型并迅速组合膨胀，评价必须额外关注泛化能力与过拟合。
- 算法机制与算子层：对象本身就是要执行的机制，例如差分进化的变异策略、粒子群中惯性系数的组合方式、损失函数的具体形式。候选必须满足语法与语义约束，评价从“谁的分数更高”转向鲁棒性、稳定性与多目标权衡。
- 程序与工程状态层：对象成为训练脚本、流水线配置、依赖关系与项目状态。候选只有通过编译、测试与验收才被视为有效，评价升级为系统级反馈：精度提升多少、资源开销是否可接受、结果能否复现。
为什么边界会向外扩展
两股力量共同推动。其一，算力规模打开了并行探索的可能：过去围绕单个候选编写的串行循环，被张量化与批量并行取代，整个种群可以一次生成、一次评价。其二，大模型能够理解自然语言、代码与领域上下文，使系统可以构造结构复杂的候选——过去必须人工设计的编码与变异方式，如今可以由模型参与生成。
当“产生候选的方法”本身也能被表达和被评价时，一个自然的问题就出现了：既然候选解可以被演化，那么产生候选解的方法是否也可以成为演化对象？这正是从“优化解”走向“优化算法本身”的那一级台阶。
评价信号必须随对象一起升级
在参数层，单一标量目标足以驱动搜索，例如 \min f(θ)。到了程序层，没有任何一个标量能概括“这段代码是否值得保留”：评价变成带约束的多目标权衡，需要同时考虑精度 f1、评估成本 f2 与稳定性 f3，并在约束 C(x) ≤ 0 下寻找一组互不支配的候选。工程上常用的判断清单包括：编译是否通过、测试是否覆盖、基准是否提升、资源开销是否可接受、结果能否复现。
常见误解：扩展不等于随意生成
把对象边界向外推，并不意味着可以任意生成代码。对象越自由，约束并不会消失，只是从“取值范围”转移到“语法、接口与可执行性”；验证责任也不是减轻，而是加重。放开脚本级演化的团队通常会先撞上两个现实问题：搜索空间急剧膨胀，以及大量“能跑通但无收益”的候选吃掉评估预算。
因此更稳妥的做法是分层放开：逐层扩大允许改变的范围，先用低成本筛选或代理模型排除明显无效的候选，再把高保真评估留给少数有希望的方案，并在精度与开销之间显式取舍。
演化对象从数值参数向复杂代码结构演进的层级图
觀察圖中的演化对象从数值参数向复杂代码结构演进的层级图，想一想它和「演化的对象从参数扩展到程序模型结构算法机制和软件工程状态」有什麼關係。
