1. 从"单点炫技"到"系统进化"：具身智能正在经历什么
过去两年，具身智能领域的注意力大多集中在单点突破上——某个机械臂抓取成功率又提高了几个百分点，某款人形机器人学会了后空翻，某个视觉模型在标准数据集上刷新了纪录。这些成果当然重要，但如果你真正在实验室或工程一线待过，就会发现一个尴尬的现实：绝大多数演示都是"温室里的花朵"。换一个光照条件、换一批物体摆放、换一个地面摩擦系数，整套流程可能直接崩掉。
问题出在哪里？不是某个算法不够强，而是整个系统缺乏自主进化的能力。一个机器人要在真实环境中持续工作，它需要的不只是一个好用的策略网络，还需要一套能够自动发现问题、自动生成新任务、自动评估改进效果的闭环机制。这就是"具身智能开始卷系统"这句话背后的核心含义——竞争焦点正在从"谁的模型更强"转向"谁的系统更能自我迭代"。
RoboFoundry 这个方向之所以值得关注，是因为它试图解决的正是这个系统级问题。从标题来看，"让机器人自主进化"是它的核心主张。所谓自主进化，我理解至少包含三层意思：第一，系统能自动识别当前能力的短板；第二，系统能围绕短板生成有针对性的训练场景；第三，系统能把训练结果可靠地部署回真实机器人，并验证是否真的变强了。这三层缺一不可，少了任何一层，"进化"就只是实验室里的自娱自乐。
这篇文章适合谁看？如果你是从业者，正在搭建或维护具身智能的训练流水线，这里面的系统设计思路和踩坑经验应该对你有直接参考价值。如果你是研究者，关注机器人学习、仿真到现实迁移、自动化课程生成等方向，也能从中看到一些工程视角的取舍逻辑。如果你只是对这个领域好奇，我会尽量用生活化的类比把关键概念讲清楚，让你理解为什么"系统能力"比"单点算法"更难做，也更有价值。
需要提前说明的是，由于输入信息中没有提供 RoboFoundry 的具体技术文档，以下内容是基于具身智能领域常见的系统架构实践、公开的研究思路以及我个人在类似项目中的经验进行的合理推演和补充。我会明确标注哪些是通用实践，哪些是我的个人判断，方便你区分对待。
2. 自主进化的三个核心环节：诊断、生成、验证
2.1 能力诊断：怎么知道机器人"哪里不行"
自主进化的第一步不是训练，而是诊断。这个道理跟医生看病一样——你不可能给病人开一堆药让他全吃一遍，得先搞清楚病灶在哪里。机器人的能力短板可能出现在多个层面：感知层（视觉识别不准、深度估计偏差大）、规划层（路径规划陷入局部最优）、控制层（末端执行器抖动、力控不稳定）、任务层（长程任务中步骤遗漏或顺序错误）。
诊断的难点在于，很多失败并不是单一环节导致的。比如一个抓取任务失败了，可能是视觉没定位准，也可能是抓取姿态不对，还可能是夹爪力度控制有问题。如果系统不能把失败归因到具体环节，后续的针对性训练就无从谈起。
常见的做法是建立一套分层评估体系。在感知层，用标注数据定期测试识别准确率和定位误差；在控制层，用标准轨迹跟踪任务测试跟踪精度和响应延迟；在任务层，用一组固定难度的任务集测试成功率和完成时间。每个维度都有基线指标，当某个指标显著低于基线时，就触发对应的改进流程。
但这里有个容易被忽略的细节：基线本身也需要动态更新。如果机器人整体能力在提升，旧的基线可能已经不能反映真实短板了。我见过一些团队，基线设完之后半年没动过，结果系统一直在优化一个已经不再是瓶颈的环节，真正卡脖子的地方反而没人管。所以诊断模块需要定期重新校准基线，确保它始终指向当前最薄弱的环节。
另一个实操中的坑是：诊断场景和真实工作场景的分布差异。如果你只用实验室里那几个固定物体做诊断，得出的结论很可能跟真实环境中的表现对不上。比较稳妥的做法是维护一个"诊断场景池"，里面既有标准化的基准场景，也有从真实运行日志中采样出来的困难场景。前者保证可比性，后者保证相关性。
2.2 任务生成：从短板到训练场景的映射逻辑
诊断出短板之后，下一步是生成有针对性的训练任务。这一步是整个自主进化系统中最有技术含量的部分，也是最容易做砸的地方。
最朴素的做法是人工设计任务。比如发现抓取透明物体成功率低，就人工搭建一批透明物体的抓取场景。这种方式可控性强，但扩展性差，而且严重依赖人的经验。系统要真正"自主"，就必须能自动生成任务。
自动生成任务的核心思路是：在已知短板附近做参数扰动和场景组合。举个例子，如果诊断发现机器人在低光照条件下的识别能力下降明显，系统可以自动生成一系列光照参数逐渐降低的场景，同时保持物体类别、摆放位置等变量在一定范围内变化。这样既能针对性地训练低光照识别，又不会让任务过于单一导致过拟合。
更进阶的做法是引入课程学习（Curriculum Learning）的思想。系统不是一次性生成所有难度的任务，而是从当前能力刚好能应对的难度开始，随着能力提升逐步增加难度。这就像教小孩走路，先扶着走，再放手走，最后让他跑。如果一上来就给最难的场景，机器人可能完全学不到有效策略，因为失败信号太稀疏了。
这里有个关键参数需要仔细调：难度递增的步长。步长太小，训练效率低，系统长时间停留在简单任务上；步长太大，机器人可能直接卡住，学习曲线出现断崖。我的经验是，步长应该跟当前成功率挂钩——当某个难度级别的成功率稳定在70%到80%之间时，就可以考虑提升难度了。低于这个区间说明还没掌握，高于这个区间说明已经饱和，继续练收益不大。
还有一个容易被忽视的点：任务生成不仅要考虑难度，还要考虑多样性。如果系统总是生成同一类任务，机器人可能会过拟合到特定场景。所以在生成任务时，需要引入随机化机制，让物体形状、颜色、材质、摆放方式、背景纹理等变量都有一定的变化范围。这个范围也不能太大，否则任务之间差异过大，学习信号会被稀释。
2.3 效果验证：怎么确认机器人真的变强了
训练完成之后，怎么确认机器人真的变强了？这个问题听起来简单，实际上非常容易出错。
最常见的错误是：用训练时用过的场景做测试。这相当于考试前把答案告诉学生，考出来的分数没有意义。正确的做法是维护一个独立的测试集，这个测试集在训练过程中完全不可见，只在评估时使用。而且测试集的场景分布应该跟真实工作场景尽量接近，否则测出来的提升可能只是"在测试集上过拟合"。
另一个问题是：单次评估的随机性太大。机器人的表现受初始状态、传感器噪声、环境微小变化等因素影响，单次运行的结果可能波动很大。比较可靠的做法是每个条件跑多次（比如20到50次），取成功率和平均完成时间作为指标。如果条件允许，还应该做统计显著性检验，确认提升不是随机波动导致的。
验证环节还有一个隐藏的坑：仿真环境和真实环境的差异。很多系统在仿真里训练和验证，指标很好看，但部署到真机上效果大打折扣。这个差距可能来自物理引擎的近似误差、传感器模型的简化、执行器的响应延迟等多种因素。要缩小这个差距，一方面需要在仿真中引入更多的随机化和噪声建模，另一方面需要在真机上也做定期评估，用真实数据反过来校准仿真参数。
我个人的做法是：仿真评估用于快速迭代和筛选，真机评估用于最终确认。每次系统声称"变强了"，都必须通过真机验证才算数。仿真里的提升幅度再大，如果真机上没有体现，那就说明系统还有问题需要排查。
3. 仿真到现实的鸿沟：为什么"进化"不能只在虚拟世界里发生
3.1 物理引擎的近似误差到底有多大
做具身智能的人都知道"仿真到现实"（Sim-to-Real）是个老大难问题，但很多人对它的严重程度估计不足。我见过一些团队，在仿真里把抓取成功率刷到95%以上，结果真机上连50%都不到。这个差距不是靠调调参数就能解决的，它根植于物理引擎的近似本质。
举个例子，刚体碰撞检测在仿真中通常是基于凸包或简化网格做的，而真实物体的接触面可能是复杂的非凸形状。这导致仿真中的接触力和真实情况有系统性偏差。再比如，摩擦力的建模在仿真中通常用库仑摩擦模型，但真实世界的摩擦行为要复杂得多，受表面粗糙度、湿度、温度等因素影响。这些差异累积起来，就会让在仿真中"学会"的策略在真机上表现失常。
更麻烦的是，有些差异是难以建模的。比如线缆的形变、布料的褶皱、液体的流动，这些软体或流体的行为在仿真中要么被简化处理，要么计算成本高到无法实时运行。如果机器人的任务涉及这类物体，仿真和现实的差距会更大。
那怎么办？一个实用的思路是：不要追求仿真和现实完全一致，而是让仿真中的策略对差异具有鲁棒性。具体做法是在仿真训练时引入大量的域随机化（Domain Randomization）——随机改变物体的质量、摩擦系数、传感器的噪声水平、执行器的响应延迟等参数。这样训练出来的策略不会过度依赖某个特定的物理参数，在真实环境中更容易泛化。
但域随机化也有个度的问题。随机范围太小，策略在真机上还是容易崩；随机范围太大，策略可能变得过于保守，在真机上的表现反而不如针对性训练的策略。我的经验是，随机范围应该根据真机实测的偏差来设定——先测量真机和仿真在关键参数上的差异范围，然后在这个范围的基础上适当放大作为随机化区间。
3.2 传感器噪声与执行器延迟的真实影响
除了物理引擎的近似误差，传感器噪声和执行器延迟也是仿真到现实迁移中的两大杀手。
先说传感器噪声。仿真中的视觉传感器通常输出干净的图像，最多加一点高斯噪声。但真实相机的噪声模式要复杂得多：有读出噪声、有光子散粒噪声、有镜头畸变、有运动模糊、还有光照变化带来的影响。如果策略在仿真中习惯了干净图像，到了真机上就可能把噪声当成有效信号，做出错误决策。
处理这个问题的方法是在仿真中尽可能真实地模拟传感器噪声。对于视觉传感器，可以采集真实相机的噪声样本，然后在仿真图像上叠加这些噪声。对于深度传感器，可以模拟飞行时间相机的多路径干扰和反射率影响。对于力/力矩传感器，可以加入真实的漂移和温漂特性。这些工作很繁琐，但对缩小仿真到现实的差距非常关键。
再说执行器延迟。仿真中的执行器通常是理想化的——你给一个指令，它立刻执行。但真实执行器有响应延迟、有带宽限制、有死区、有饱和。如果策略在仿真中没有考虑这些，到了真机上就可能因为延迟导致振荡或失稳。
处理执行器延迟的常见做法是在仿真中显式建模延迟环节。比如在控制指令和实际执行之间插入一个延迟模块，延迟时间根据真机实测设定。同时，在训练策略时，可以让策略观测到延迟后的状态，这样它就能学会补偿延迟。这个技巧在控制领域是老生常谈，但在机器人学习社区里，我见过不少团队忽略了这一点，结果真机调试时被振荡问题折腾得够呛。
3.3 真机验证的不可替代性
说了这么多仿真到现实的差距，结论其实很明确：真机验证不可替代。不管仿真做得多逼真，最终都必须回到真机上确认效果。
但真机验证有个现实困难：成本高、速度慢。一台机器人跑一次实验可能需要几分钟到几十分钟，而且需要人工干预和监控。如果每次训练迭代都要做大量真机实验，整个研发周期会被拉得很长。
比较务实的做法是分层验证。第一层是仿真评估，快速筛选出有潜力的策略；第二层是小规模真机验证，用少量关键场景测试策略的基本可行性；第三层是大规模真机评估，用完整的测试集确认策略的最终效果。每一层都有明确的通过标准，只有通过上一层的策略才能进入下一层。这样既能保证最终效果，又能控制验证成本。
另外，真机验证的数据要好好利用。每次真机运行产生的数据——包括传感器读数、执行器指令、任务结果——都是宝贵的资产。这些数据可以用来校准仿真参数、发现新的失败模式、生成新的训练场景。我见过一些团队，真机跑完实验就把数据扔在一边，这是很大的浪费。正确的做法是建立数据回流机制，让真机数据自动进入诊断和任务生成流程，形成闭环。
4. 系统架构的工程取舍：模块化还是端到端
4.1 模块化流水线的优势与代价
搭建自主进化系统时，第一个架构决策就是：用模块化流水线还是端到端方案？
模块化流水线的思路是把系统拆成多个独立模块——感知模块、规划模块、控制模块、诊断模块、任务生成模块、评估模块——每个模块有明确的输入输出接口，可以独立开发和测试。这种架构的优势很明显：可解释性强，出了问题容易定位；模块可以独立替换和升级，不会牵一发而动全身；不同模块可以用不同的技术栈，灵活性高。
但模块化也有代价。最大的问题是模块之间的接口设计。如果接口设计得不好，模块之间的信息传递会丢失关键细节，导致整体性能下降。比如感知模块输出一个物体位置，规划模块根据这个位置生成路径，但如果感知模块没有输出位置的不确定性，规划模块就无法在不确定环境下做出鲁棒决策。这种信息丢失在模块化架构中很常见，而且往往在系统集成时才暴露出来。
另一个问题是误差累积。每个模块都有自己的误差，这些误差在流水线中会逐级放大。感知模块的定位误差可能导致规划模块生成错误的路径，规划模块的路径误差又可能导致控制模块执行失败。端到端方案理论上可以通过联合优化来减少这种误差累积，但模块化方案很难做到全局最优。
我的经验是：在系统早期阶段，模块化流水线更容易调试和迭代，因为你可以单独测试每个模块，快速定位问题。但当系统逐渐成熟，各模块的接口和误差特性都摸清楚之后，可以考虑在某些环节引入端到端优化，比如把感知和规划联合训练，或者把规划和控制联合优化。这种渐进式的架构演进比一开始就追求端到端更务实。
4.2 端到端方案在自主进化中的适用边界
端到端方案在具身智能领域一直很有吸引力——用一个大的神经网络直接从传感器输入映射到执行器输出，中间不需要人工设计的模块和接口。这种方案在理论上可以避免模块化架构的信息丢失和误差累积问题，而且随着数据量增加，性能还有持续提升的空间。
但在自主进化的场景下，端到端方案有几个需要仔细考虑的问题。
首先是可解释性。自主进化系统需要诊断能力短板，如果系统是一个黑盒，诊断就无从下手。你只能看到"任务失败了"，但不知道是感知问题、规划问题还是控制问题。虽然有一些可解释性技术可以分析神经网络的内部表示，但这些技术目前还不够可靠，尤其是在复杂的具身任务中。
其次是训练效率。端到端方案通常需要大量的训练数据，而具身智能的数据采集成本很高。如果每次进化迭代都需要重新采集大量数据，整个系统的迭代速度会很慢。模块化方案可以复用已有的模块和数据，只需要针对短板模块进行更新，效率更高。
第三是安全性。端到端方案的行为难以预测，在某些边界情况下可能产生危险动作。模块化方案可以在关键模块中加入安全约束，比如规划模块可以保证路径不碰撞，控制模块可以保证力矩不超限。这些约束在端到端方案中很难显式加入。
所以我的判断是：端到端方案适合作为系统中的一个组件，而不是整个系统的架构。比如可以用端到端方案做低层的感知-控制映射，但高层的任务规划、诊断、任务生成还是用模块化方案。这样既能利用端到端方案在特定环节的优势，又能保持系统的可解释性和可控性。
4.3 数据回流与持续学习的工程实现
自主进化的核心是持续学习——系统要能从每次运行中获取新数据，用这些数据改进自身，然后在下一次运行中表现更好。这个闭环的工程实现有很多细节需要注意。
首先是数据采集。每次机器人运行都要记录足够详细的数据，包括原始传感器读数、处理后的感知结果、规划轨迹、控制指令、执行器反馈、任务结果等。这些数据要带时间戳，方便后续做时间对齐和分析。数据量会很大，所以需要设计合理的存储和索引方案，确保能快速检索到需要的片段。
其次是数据标注。有些数据可以自动标注，比如任务成功与否、完成时间等。但有些数据需要人工标注，比如失败原因分类、关键帧的物体位置等。人工标注成本高，所以要设计好标注流程，尽量用主动学习的方法，只标注对改进最有价值的数据。
第三是数据回流。采集和标注好的数据要能自动进入训练流程。这需要一套数据管理机制，能追踪每条数据的来源、用途和处理状态。我见过一些团队，数据采集和训练是两套独立系统，数据要靠人工拷贝来传递，效率低而且容易出错。正确的做法是把数据流做成自动化的管道，从采集到标注到训练到评估，全程可追踪、可复现。
最后是模型更新。新数据进来后，怎么更新模型？全量重训还是增量更新？全量重训效果好但成本高，增量更新成本低但可能遗忘旧知识。比较稳妥的做法是：定期做全量重训，两次全量重训之间做增量更新。增量更新时要注意保留一部分旧数据做回放，防止灾难性遗忘。这个策略在持续学习领域有很多研究，工程上也有不少成熟的实现方案可以参考。
5. 实操中的坑与经验：来自一线的真实教训
5.1 任务生成中的奖励函数设计陷阱
在自主进化系统中，任务生成模块负责创建训练场景，但训练效果好不好，很大程度上取决于奖励函数怎么设计。我在这上面踩过不少坑，分享几个典型的。
第一个坑是奖励稀疏。如果只在任务成功时给奖励，失败时不给奖励，机器人很难学到有效策略，因为大部分尝试都是失败的，它不知道哪些动作是"接近成功"的。解决办法是设计稠密奖励，比如在抓取任务中，可以根据夹爪与物体的距离、物体的移动量、是否成功闭合等中间状态给奖励。但稠密奖励也有风险——如果设计不当，机器人可能学会"刷奖励"而不是真正完成任务。比如它可能学会把物体推来推去来获取距离奖励，而不是真正抓起来。
第二个坑是奖励尺度不平衡。如果任务有多个子目标，每个子目标的奖励尺度需要仔细调整。某个子目标奖励太大，机器人可能过度关注它而忽略其他子目标；奖励太小，机器人可能完全忽略它。我的经验是，先给每个子目标一个初始奖励值，然后根据训练中的表现逐步调整。如果某个子目标的完成率一直很低，说明奖励可能不够；如果某个子目标的完成率很高但整体任务成功率上不去，说明奖励可能过大，机器人过度关注这个子目标了。
第三个坑是奖励函数过拟合到特定场景。如果奖励函数的设计跟训练场景强相关，换一个场景可能就失效了。比如你根据物体的绝对位置设计奖励，换一个物体摆放位置后，奖励信号可能完全不对。解决办法是尽量用相对量而不是绝对量来设计奖励，比如用"距离变化量"而不是"距离绝对值"，用"相对于初始状态的改善"而不是"绝对性能"。
5.2 仿真参数校准的实操步骤
仿真参数校准是缩小仿真到现实差距的关键步骤，但很多团队做得不够细致。我分享一下我的实操流程。
第一步是收集真机数据。让机器人在真实环境中执行一组标准动作，比如直线运动、圆弧运动、抓取不同重量的物体、在不同表面上滑动等。记录执行器的指令和实际响应，以及传感器的读数。这些数据是校准的基础。
第二步是识别关键参数。不是所有仿真参数都需要校准，要找出对任务影响最大的那几个。通常包括：关节摩擦系数、电机响应延迟、传感器噪声水平、物体质量、表面摩擦系数、碰撞恢复系数等。可以通过敏感性分析来确定哪些参数对任务成功率影响最大。
第三步是参数拟合。用真机数据来拟合仿真参数。比如用直线运动的数据拟合关节摩擦和电机延迟，用抓取数据拟合物体质量和摩擦系数。拟合方法可以用简单的网格搜索，也可以用贝叶斯优化等更高效的方法。拟合的目标是让仿真中的动作响应和传感器读数尽可能接近真机数据。
第四步是验证。用一组独立的真机数据验证校准后的仿真。如果仿真和真机的差异在可接受范围内，校准就完成了。如果差异还是很大，可能需要回到第二步，检查是否遗漏了关键参数，或者仿真模型本身有结构性误差。
第五步是定期重新校准。机器人的硬件会磨损，环境会变化，所以仿真参数也需要定期更新。我的做法是每个月做一次快速校准，每季度做一次完整校准。快速校准只调几个关键参数，完整校准会重新走一遍全部流程。
5.3 评估指标选择的常见误区
评估指标选错了，整个自主进化系统可能朝着错误的方向优化。我见过不少团队在指标选择上栽跟头。
最常见的误区是只看成功率。成功率当然重要，但它不能反映全部。两个策略成功率都是80%，但一个策略失败时是轻轻放下物体，另一个策略失败时是把物体摔飞，这两个策略的实际价值完全不同。所以除了成功率，还要看失败模式——失败时是否安全、是否可恢复、是否损坏物体或环境。
另一个误区是忽略完成时间。有些策略成功率很高，但完成一个任务要花很长时间，在实际应用中可能不可接受。所以在评估时要把完成时间也纳入指标，可以用"单位时间成功率"或者"成功率-时间帕累托前沿"来综合评估。
还有一个误区是测试集代表性不足。如果测试集只包含简单场景，评估结果会过于乐观。如果测试集只包含困难场景，评估结果会过于悲观。测试集的难度分布应该跟真实应用场景匹配。我的做法是维护多个测试集——简单集、中等集、困难集、真实采样集——分别评估，综合判断。
最后，不要忽略定性评估。有些问题不是数字能反映的，比如机器人动作是否流畅、是否有多余的抖动、是否在某个阶段犹豫不决。这些定性观察往往能发现定量指标遗漏的问题。我习惯在每次评估时录视频，事后回放分析，经常能发现一些指标上看不出来的问题。
6. 自主进化系统的能力边界与未来演进方向
6.1 当前系统还做不到什么
说了这么多自主进化的能力和实现方法，也得清醒地认识到当前系统的局限。
首先，自主进化系统目前还很难处理全新的任务类型。如果任务的结构和之前见过的完全不同，系统可能无法生成有效的训练场景，也不知道该怎么评估。比如一个系统一直在做抓取和放置任务，突然让它做拧螺丝，它可能完全不知道从何下手。这种跨任务类型的泛化能力，目前还是人类工程师更擅长。
其次，系统对硬件变化的适应能力有限。如果机器人的某个关节坏了，换了一个不同型号的，系统的控制策略可能需要重新训练。虽然有一些自适应控制的方法可以处理一定程度的硬件变化，但如果变化太大，系统还是需要人工干预。
第三，系统在开放环境中的安全性还没有完全解决。在结构化环境中，系统可以枚举可能的情况并保证安全。但在开放环境中，可能出现系统从未见过的情况，这时候系统的行为难以预测。虽然可以加入安全约束和紧急停止机制，但这些机制本身也可能失效。
第四，系统的进化速度受限于数据采集和训练的效率。虽然自动化程度提高了，但每次进化迭代还是需要时间。如果任务很复杂，可能需要很多轮迭代才能看到明显提升。这个时间成本在实际项目中是需要考虑的。
6.2 从"自动"到"自主"还有多远
"自动"和"自主"是两个不同的概念。自动是指系统能按照预设的流程执行任务，不需要人工干预每一步。自主是指系统能自己决定做什么、怎么做、什么时候做。目前的自主进化系统，大部分还停留在"自动"层面——它们能自动执行诊断、生成、训练、评估的流程，但流程本身还是人工设计的。
从自动到自主，需要系统具备几个关键能力。第一是目标设定能力——系统要能自己决定优化什么目标，而不是等人来指定。第二是策略选择能力——系统要能自己决定用什么方法解决问题，而不是只能执行预设的方法。第三是资源管理能力——系统要能自己决定把计算资源、时间资源、数据资源分配到哪些任务上。第四是自我反思能力——系统要能评估自己的表现，发现自己的局限，并主动寻求改进。
这些能力目前都还在研究阶段，离实用还有距离。但我认为方向是明确的——随着基础模型能力的提升和工程实践的积累，系统会逐步从自动走向自主。这个过程可能比很多人预期的要慢，因为自主性带来的不确定性和安全风险需要仔细处理。但一旦突破，具身智能的应用范围会大大扩展。
6.3 对从业者的实际建议
如果你正在或准备做具身智能的自主进化系统，我有几条实际建议。
第一，从窄领域做起。不要一上来就追求通用系统，先在一个具体的任务领域（比如桌面抓取、仓库搬运、装配）把闭环跑通。窄领域的系统更容易调试，也更容易看到效果。等这个领域的闭环跑通了，再考虑扩展到其他领域。
第二，重视数据基础设施。自主进化的核心是数据闭环，如果数据采集、存储、标注、回流的管道不顺畅，整个系统就跑不起来。在项目早期就要把数据基础设施搭好，不要等到需要数据了才临时抱佛脚。
第三，仿真和真机并重。不要偏废任何一方。仿真用于快速迭代和筛选，真机用于最终验证和校准。两者之间的数据要双向流动——真机数据校准仿真，仿真结果指导真机实验。
第四，评估体系要独立。评估模块不能跟训练模块耦合太紧，否则容易产生"自己评估自己"的偏差。评估场景要独立维护，评估指标要全面，评估结果要定期人工复核。
第五，保持对失败的敏感。自主进化系统最容易陷入的陷阱是"指标很好看但实际没用"。要定期做真机验证，定期做人工评估，定期检查失败案例。如果发现指标和实际感受不一致，要停下来排查原因，不要盲目相信数字。
这个领域变化很快，今天有效的方法明天可能就过时了。保持学习，保持实践，保持对真实问题的敏感，比追逐任何具体技术都重要。
