OpenAI Baselines的A2C实现中SubprocVecEnv为何用env_fn而非直接传env

核心原因主要有以下几点：

• 环境实例序列化限制
  绝大多数强化学习环境都包含无法被序列化的对象，比如渲染用的图形上下文、打开的文件句柄、操作系统级的资源锁、内部的C/C++扩展对象等。即使使用cloudpickle也无法保证这类对象可以被正常序列化、跨进程传输，直接传递env实例大概率会在进程启动阶段触发序列化失败的报错。
• 保证环境实例的独立性
  如果需要启动N个并行环境，直接传递env实例的前提是需要先在主进程中初始化N个独立的环境对象，不仅主进程会承担不必要的资源开销，还可能出现部分环境的全局状态冲突问题。而使用env_fn的方案是让每个子进程在本地完成环境初始化，所有环境的生命周期、资源占用都归属对应的子进程，完全独立不会出现冲突，也不会占用主进程的额外资源。
• 适配子进程运行环境
  很多环境的初始化会依赖运行进程的本地配置，比如硬件资源绑定（GPU、NUMA节点）、本地数据路径、进程级的环境变量配置等。在子进程内部调用env_fn初始化环境，可以完美适配子进程的运行时配置，避免主进程初始化的环境和子进程运行环境不兼容的问题。

你提到的直接传递CloudpickleWrapper(env)的写法，仅在极少数完全无本地资源依赖、可被完整序列化的简单环境下可以运行，不具备通用性，因此官方实现采用了兼容性、稳定性更强的env_fn方案。

内容的提问来源于stack exchange，提问作者Qualia