把代码模型放进一个可交互环境里，它就不再只是生成一次性答案，而是可以通过行动、观察结果、获得奖励，再调整下一步策略。以“用代码绘制水彩画”为例，模型需要同时处理程序语法、视觉构图和连续迭代，这正适合用 TRL 负责训练流程、用 OpenEnv 描述环境交互。
需要说明的是，来源标题只明确了训练方向，并没有给出具体环境实现、奖励函数或模型配置。下面的代码是一个可以改造成真实项目的最小实践示例：它用一个假设的绘画环境展示交互协议和奖励设计，真实使用时需要替换为项目提供的 OpenEnv 适配器以及实际的 TRL Trainer 配置。
从“生成代码”变成“完成任务”
传统的代码生成通常是：输入提示词，模型输出一段程序，然后由用户判断结果是否满意。绘画任务的反馈更加直接：程序可以被执行，生成图片可以被渲染，渲染结果还能通过规则或视觉模型打分。
一次交互可以抽象成下面的循环：
- 环境提供任务描述和当前画布状态。
- 模型输出一段绘画代码或下一步编辑动作。
- OpenEnv 执行动作，生成新的画布状态。
- 环境计算奖励，例如代码是否运行、颜色是否接近目标、构图是否满足要求。
- TRL 使用轨迹和奖励更新模型。
水彩画比简单的像素匹配更难。水彩效果通常涉及透明度、颜色混合、边缘扩散和笔触层次，因此奖励不能只看“有没有输出图片”。一个更实用的奖励可以拆成：
总奖励 = 代码可执行性 + 构图相似度 + 色彩相似度 + 水彩风格分数 - 复杂度惩罚
代码可执行性适合用确定性检查；构图和色彩可以使用图像相似度模型；水彩风格则可以通过专门的视觉评分器或人工偏好数据建模。复杂度惩罚用于避免模型用过长、重复的绘制代码堆出一个难以维护的结果。
OpenEnv 的关键不是“画布”，而是边界
一个训练环境需要把模型能看到什么、能做什么、会得到什么反馈定义清楚。对于编程绘画任务，建议把接口拆成四类信息：
observation：任务要求、当前代码、画布缩略图或结构化绘画状态。action：模型提交的代码、补丁，或者一个有限的绘画操作。reward：本轮执行结果和各项评分。done：达到质量阈值、执行失败，或超过最大步数。
如果每一步都把完整高清图片和完整历史代码塞进上下文，训练成本会迅速升高。可以让环境返回缩略图、颜色直方图、图层摘要和最近一次错误信息；最终评估时再使用高清图像评分。这样能减少无关上下文，也让模型更容易定位“哪一步导致了退化”。
动作空间同样需要控制。允许模型执行任意 Python 代码会带来安全风险，也会让奖励变得不稳定。实际环境可以只开放一个沙箱，并限制：
- 文件系统只能访问临时目录。
- 禁止网络、子进程和动态导入。
- 单步执行有 CPU、内存和时间上限。
- 输出图片必须符合固定尺寸和颜色模式。
- 失败动作返回结构化错误，而不是让整个训练进程崩溃。
一个可运行的最小环境骨架
下面的示例不依赖 TRL 或 OpenEnv，目的是展示环境协议。它模拟一个“用代码逐步提高目标颜色相似度”的绘画环境。你可以先运行它验证奖励循环，再把 reset、step 和奖励计算替换成真实的渲染器与 OpenEnv 接口。
from dataclasses import dataclass
from typing import Dict, Tuple
@dataclass
class PaintState:
color: Tuple[int, int, int] = (255, 255, 255)
step: int = 0
class WatercolorEnv:
"""假设的水彩环境：真实项目中应替换为实际渲染和视觉评分。"""
def __init__(self, target=(210, 120, 80), max_steps=5):
self.target = target
self.max_steps = max_steps
self.state = PaintState()
def reset(self) -> Dict:
self.state = PaintState()
return self._observation()
def step(self, action: Dict) -> Tuple[Dict, float, bool, Dict]:
# 假设 action 是受控后的绘画参数，而不是任意可执行代码。
color = action.get("color", self.state.color)
if not self._valid_color(color):
return self._observation(), -1.0, True, {"error": "invalid color"}
self.state = PaintState(color=tuple(color), step=self.state.step + 1)
distance = sum((a - b) ** 2 for a, b in zip(self.state.color, self.target)) ** 0.5
similarity = max(0.0, 1.0 - distance / 442.0)
reward = similarity - 0.01 * self.state.step
done = similarity >= 0.98 or self.state.step >= self.max_steps
return self._observation(), reward, done, {"similarity": similarity}
def _observation(self) -> Dict:
return {
"task": "paint a warm watercolor wash",
"current_color": self.state.color,
"step": self.state.step,
"remaining_steps": self.max_steps - self.state.step,
}
@staticmethod
def _valid_color(color) -> bool:
return (
isinstance(color, (list, tuple))
and len(color) == 3
and all(isinstance(v, int) and 0 <= v <= 255 for v in color)
)
if __name__ == "__main__":
env = WatercolorEnv()
observation = env.reset()
print("reset:", observation)
actions = [
{"color": [240, 180, 150]},
{"color": [220, 135, 95]},
{"color": [210, 120, 80]},
]
for action in actions:
observation, reward, done, info = env.step(action)
print({"observation": observation, "reward": round(reward, 3), "info": info})
if done:
break
运行方式：
python watercolor_env.py
在真实版本中，action 可以改为模型生成的受限绘画 DSL，例如 wash(x, y, width, color, opacity)。环境负责解析 DSL、渲染 PNG、提取图像特征并返回奖励。这样既保留了代码模型的规划能力，又避免把整个操作系统暴露给模型生成的程序。
TRL 训练时要记录什么
无论采用哪种 TRL 训练器，训练数据的核心都不是单独的最终代码，而是完整轨迹：提示、模型动作、环境观察、奖励、终止原因。至少应记录以下字段：
{
"prompt": "Paint a warm watercolor wash with soft edges.",
"actions": [
{"code": "wash(40, 40, 120, '#e07a50', opacity=0.35)"},
{"code": "blend(radius=18, opacity=0.2)"}
],
"rewards": [0.31, 0.78],
"final_reward": 0.78,
"terminated_by": "quality_threshold"
}
可以这样组织训练阶段：
- 用监督微调让模型学会任务 DSL、画布坐标和环境返回格式。
- 用短轨迹进行环境交互，先让奖励信号稳定下来。
- 再增加多步规划、颜色混合和局部修复等困难任务。
- 将执行失败、超时和越权动作单独统计，不要只看平均奖励。
- 用固定提示集和人工抽检比较训练前后的视觉质量。
奖励设计尤其需要防止“投机行为”。例如，模型可能通过生成巨大文件、反复覆盖画布、使用极端颜色或调用评分器漏洞获得高分。解决办法包括限制动作预算、加入代码复杂度惩罚、对渲染输出做独立复核，并保留一套模型无法直接观察的测试提示。
落地检查清单
开始实验时，可以按下面的顺序推进：
- 固定画布尺寸、色彩空间、随机种子和最大交互步数。
- 先实现可复现的规则奖励，再接入视觉模型评分。
- 为每个动作设置超时、内存和文件访问边界。
- 记录每一步 observation、action、reward 和错误类型。
- 用少量任务验证奖励是否与人工判断一致。
- 训练时区分“代码正确”和“画面好看”，避免单一指标掩盖问题。
- 评估模型在新提示、不同画布尺寸和失败恢复场景下的表现。
TRL 与 OpenEnv 的组合价值在于把代码生成放进了一个可以反复试错的任务闭环。对于水彩绘画这样的任务，真正的难点并不是让模型输出更多代码，而是设计一个可靠、可观测、难以作弊的环境，让每次绘制动作都产生有意义的反馈。环境边界和奖励质量决定了训练上限，模型规模只是其中一个因素。