Coding Agent RL 这个方向听起来像是把两个大词堆在一起一边是能写代码的智能体Coding Agent一边是让策略不断试错的强化学习Reinforcement LearningRL。但真正落地时会发现问题远不只是“让模型自己生成代码再跑一下 test case”这么简单。数据从哪里来、智能体与环境交互的轨迹怎么采集、执行结果如何换算成奖励这三个环节直接决定了训练是向上收敛还是在原地空转。这篇文章从工程实践角度拆解这三件事。我会先说明 Coding Agent RL 训练闭环里数据、轨迹、奖励各自承担什么角色然后分别讨论公开数据集怎么选、轨迹如何采集与存储、奖励函数怎么设计最后给出一个最小实验闭环和环境搭建建议。适合正在做 Coding Agent RL 调研、准备搭建小规模训练实验或者已经跑通 SFTSupervised Fine-Tuning但想用 RL 进一步优化代码生成质量的开发者。1. 先理清 Coding Agent RL 的训练闭环数据、轨迹和奖励分别承担什么角色Coding Agent RL 还没有一个完全统一的官方定义但研究和工作里常见的路径是一致的把“完成编程任务”建模成智能体与代码执行环境交互的过程。模型通过生成代码、运行测试、读取报错、修改代码等动作与环境互动环境返回执行结果再按规则换算成奖励信号最终用强化学习算法更新模型参数。这个闭环里数据、轨迹、奖励是互相咬合的三块。脱离任何一块实验都很容易失控。1.1 从机器学习三要素看 RL 在代码生成中的位置经典机器学习三要素是数据、模型、算法。Coding Agent RL 里可以对应成数据编程任务描述、初始代码、测试用例、提交记录、issue 描述等。模型负责生成动作的策略模型通常是语言模型以自回归方式输出代码片段或工具调用。算法强化学习更新规则常见的有 PPO、GRPO、RLAIFAI Feedback 作为奖励等。但 Coding Agent RL 与普通监督学习最大的区别在于它多了一个“环境”。环境不是静态的答案对而是可以执行代码、返回结果、判断对错的系统。模型每次生成后环境会给出新状态代码是否通过测试、运行是否超时、编译是否有错、修改后是否修复了原问题。模型需要根据这些反馈决定下一步动作。这就是为什么 Coding Agent RL 常常被看作“代码生成 智能体 强化学习”的交叉任务。它不只是让模型输出更像人类代码而是让模型在真实可执行的环境中学会怎样做能通过任务约束。1.2 一条训练样本的完整生命周期代码任务 - 轨迹 - 奖励 - 策略更新理解训练样本生命周期是后面所有设计的前提。假设我们拿 MBPP 中的一个简单任务给模型任务描述编写一个函数输入两个整数返回它们的和。模型动作生成一段 Python 函数代码。环境反馈执行测试用例发现其中一个用例失败。模型再次动作修改函数。环境反馈全部测试通过。奖励计算通过率 1.0格式和长度惩罚很小最终奖励 0.95。策略更新用这条轨迹和奖励更新模型让类似任务上有更高概率生成通过测试的代码。注意这里“轨迹”不是只有最终答案。完整的轨迹应当包括每一步动作、观察结果、中间状态和终止原因。SFT 训练时我们只要求模型输出与人工答案相似RL 训练时我们要求模型在环境里真正完成任务。这意味着奖励函数要能区分“只是输出形式像”和“真正执行通过”这两种情况。注意Coding Agent RL 需要的不是“文本答案”数据集而是“可交互环境 可执行反馈”的数据集。没有测试用例和执行环境RL 就没有训练信号。2. 数据来源怎么选不是所有代码数据集都适合做 RL 基础数据是所有环节的起点。很多刚开始做 Coding Agent RL 的同学会直接拿开源代码语料库或者答题数据集开始训练结果发现奖励完全不涨。原因往往是数据集没有配套测试用例或者任务类型与目标场景不符。所以先要把数据来源按任务类型分清楚再做清洗和难度分层。2.1 按任务类型盘点公开代码数据集下面整理几个 Coding Agent RL 实验里常见的数据集按任务类型区分。这里的“规模”是公开资料中的大致情况实际使用时建议以当时拉取到的版本为准。数据集任务类型大致规模适合用途HumanEval函数级代码生成164 个 Python 问题基础生成能力、passk 评估MBPP函数级 Python 入门任务约 1000 个问题小规模 RL 实验、规则奖励调参APPS从入门到竞赛的编程题千级以上难度分层、竞赛代码生成CodeContests编程竞赛题 大量测试大规模竞赛样本复杂推理、多步调试TACO带算法标签的竞赛题数千题算法类型分析、难度分层SWE-bench真实 GitHub issue 修复数千个 issueAgent 多步骤修复、工具使用BigCodeBench注重真实库函数调用千级任务工具/库函数使用能力从 RL 角度最重要的一列是“是否自带可执行测试”。HumanEval 和 MBPP 自带简单测试适合先跑通最小闭环。SWE-bench 更接近真实工程场景但每一条任务都需要构造仓库环境轨迹采集成本高很多。2.2 数据清洗和难度分层先想清楚 RL 要解决什么缺陷拿到数据集后不能直接开工。有四个清洗动作是必须做的去重和溯源。如果训练集与评估集有重叠最后的 passk 会被高估。建议对代码做规范化后做 MinHash 或直接 ID 去重。补充测试用例。很多数据集只有少数测试用例容易出现“奖励被 hack”的情况。比如模型可以硬编码预期输出。最好保留一个隐藏测试集训练时用可见测试评估时用隐藏测试。过滤不可执行样本。先跑一遍全量样本把无法导入、总是崩溃、环境依赖重的样本剔除。难度分层。RL 初期建议从容易拿到中间奖励的任务开始。如果一开始全是竞赛题奖励几乎全是 0训练会非常慢。难度分层可以用题目长度、通过率、解题时间等作为代理指标。比如先按“单函数实现”和“多步骤修复”区分再按通过率排序。这样便于控制训练曲线。2.3 基础模型预训练数据 vs RL 训练数据的区别很多人会误以为“预训练数据那么多RL 也可以直接用”。实际差别很大数据类型目标反馈来源数据形态预训练数据学习语言模式和代码结构自回归语言模型损失海量文本/代码指令微调数据对齐指令学会输出格式下一个 token 预测指令 回答RL 训练数据在环境交互中最大化奖励执行结果、测试通过率、模型评判任务 环境 轨迹预训练数据没有“对错”概念模型不知道代码跑起来是否通过。RL 数据必须带有环境反馈而且反馈要可计算、可复现、可验证。这也是 Coding Agent RL 数据量通常远小于预训练数据但每条数据工程价值更高的原因。实际项目中如果原始材料没有给出明确版本落地前要先确认依赖版本和数据集许可。尤其是从 GitHub 抓取代码做训练时要遵守仓库的开源协议。3. 轨迹采集代码 Agent 与环境交互的数据怎么记录有了数据集下一步不是直接算奖励而是先设计好“轨迹采集”流程。轨迹是模型与环境交互的完整记录。没有轨迹策略更新就缺少训练样本轨迹不完整排错时就会无从下手。3.1 典型 Coding Agent 的观测、动作和执行环境一个代码 Agent 每一步会看到什么、能做什么取决于环境设计。观察Observation常见包括任务描述和初始代码。当前工作区文件列表。最近一次执行输出、编译错误、测试失败信息。执行超时、内存限制等资源信息。如果接入了工具还有代码搜索、文档检索结果。动作Action常见包括生成新代码片段。修改某个文件中的某一行。运行指定测试用例。执行 shell 命令。读取文件内容。执行环境Execution Environment必须可控。真实开发中不能直接在训练机上直接运行模型生成的任意代码。推荐的做法是用 Docker 容器、AWS Firecracker 微虚拟机或者至少是受限的 subprocess 加上 CPU/内存/网络隔离。注意轨迹采集系统要在第一步就考虑安全边界。生成代码可能包含系统调用、无限循环、恶意文件操作生产环境必须做沙箱隔离。3.2 用最小 Python 环境模拟一次轨迹采集为了讲清楚轨迹采集的机制下面用一个最小的 Python 示例说明。真实生产环境不会直接这样执行但逻辑是相同的。import subprocess import tempfile import json import uuid class MinimalCodingEnv: def __init__(self, task_prompt: str, test_code: str, timeout: int 5): self.task_prompt task_prompt self.test_code test_code self.timeout timeout self.step_count 0 self.done False self.last_output self.last_error def reset(self): self.step_count 0 self.done False self.last_output self.last_error return { observation: self.task_prompt, step: 0, done: False } def step(self, code: str): self.step_count 1 if self.done: raise RuntimeError(Episode already done) combined_code code \n\n self.test_code try: # 生产环境不要直接使用 subprocess shell这里仅做演示 result subprocess.run( [python, -c, combined_code], capture_outputTrue, textTrue, timeoutself.timeout ) self.last_output result.stdout self.last_error result.stderr if result.returncode ! 0: reward 0.0 info {error: result.stderr} else: # 简单判断测试是否全部通过 pass_count result.stdout.count(PASS) total max(result.stdout.count(TOTAL), 1) reward pass_count / total info {pass_count: pass_count, total: total} except subprocess.TimeoutExpired: self.last_error timeout reward 0.0 info {error: timeout} self.done self.step_count 3 or reward 1.0 observation { output: self.last_output, error: self.last_error, step: self.step_count, done: self.done } return observation, reward, self.done, info这个环境的关键点有三个每次step都接收一段代码执行它。执行结果同时包含输出、错误、超时等信息。奖励在环境内部按简单规则算出便于后续记录轨迹。要注意subprocess.run直接在训练机器上执行代码存在安全风险。真实项目需要把代码放入容器或虚拟环境中执行并限制网络和文件系统访问。3.3 轨迹结构设计状态、动作、奖励、终止标记轨迹不是日志流水账而是可以直接用于 RL 训练的结构化样本。推荐用 JSON Lines 或 Parquet 存储每条记录包含{ trajectory_id: traj_0001, task_id: mbpp_001, prompt: 编写一个函数 add(a, b)返回两数之和。, initial_code: , actions: [ { step: 0, action_type: generate, content: def add(a, b):\n return a b, observation: output: PASS\nTOTAL: 3, reward: 1.0 } ], final_code: def add(a, b):\n return a b, reward: 1.0, done: true, terminal_reason: all_tests_passed, metadata: { model_name: qwen2.5-coder-1.5b, temperature: 0.7, env_timeout: 5, execution_time_ms: 1234 } }字段设计中最重要的是actions数组。它要包含每一步动作内容、动作类型、观察结果和阶段性奖励。后续训练时可以从这个数组构造强化学习所需的state, action, reward, next_state四元组也可以直接用于离线 RL。如果只想输出最终答案而不记录中间步骤会丢失大量可学习信息。比如模型修复 bug 的过程、遇到报错后的调整动作都是很有价值的训练信号。3.4 采样策略和多样性控制温度、退火、重复惩罚RL 轨迹采集需要一定随机性。如果采样温度太低模型每次都输出同样的代码奖励方差小策略难以学习温度太高输出质量不稳定奖励噪声大。参数常见范围对轨迹多样性的影响对奖励稳定性的影响temperature0.2 - 1.0越高输出差异越大越高奖励波动越大top_p0.8 - 1.0越高候选词范围越大越低越稳定repetition_penalty1.0 - 1.2可减少重复输出过高会降低生成质量max_tokens根据任务调整过小容易截断过大浪费算力实际采集中可以先用温度 0.7 生成多个候选再用温度 0.2 做贪心验证。这样既保留了探索性又能衡量输出稳定性。4. 奖励函数设计从执行结果到可学习的信号奖励函数是 Coding Agent RL 里最容易被低估的部分。很多人以为“测试通过就给 1 分不通过给 0 分”就够了。结果训练到后面模型学会硬编码测试用例或者只输出空函数来规避报错。奖励设计需要同时考虑结果、过程和对抗性。4.1 结果奖励单元测试通过率、编译错误、输出对比结果奖励来自最终执行结果最常见的有信号计算方式优点缺点单元测试通过率通过用例数 / 总用例数直观、可复现容易被硬编码或过拟合编译是否通过通过为 1否则为 0简单区分度低输出对比与预期输出逐字符比较精确对浮点和格式敏感运行时间超时惩罚或耗时奖励鼓励高效代码噪音大受硬件影响在实现时建议把“测试通过率”作为主要奖励把“编译错误”作为额外惩罚。比如def compute_result_reward(pass_count, total, has_error, timeoutFalse): if timeout: return 0.0 if has_error: return -0.5 if total 0: return 0.0 return pass_count / total这里给编译错误一个负分是为了让模型不要通过输出不合法代码来逃避测试。4.2 过程奖励意图匹配、分步执行反馈、代码质量信号过程奖励关注的是模型“怎么走到最终结果”而不是只看终点。它的核心作用是解决稀疏奖励问题。比如一个复杂修复任务如果模型必须经过 5 步才能修好前 4 步都没有最终奖励策略梯度会很难更新。常见过程奖励设计步骤奖励每成功执行一次测试给一个小分每修复一个编译错误给一个小分。意图匹配比较生成代码中是否包含与任务相关的关键词、函数调用、变量名。代码质量信号代码长度、重复度、圈复杂度、是否包含注释。注意这类信号容易退化成“模型学会把代码写得短但功能缺失”。LLM-as-judge用另一个模型对中间步骤打分。比如评价“模型是否在朝正确方向修复 bug”。这种方式灵活但成本高且不稳定。一个朴素的实现是把过程奖励加进总奖励def compute_total_reward( pass_count, total, has_error, step_reward, code_length, max_code_length200 ): result_part compute_result_reward(pass_count, total, has_error) step_part min(step_reward, 0.2) length_penalty max(0.0, (code_length - max_code_length) / max_code_length) * 0.05 return result_part step_part - length_penalty这里每个分量都设有上限避免某一路信号淹没主信号。实际项目中所有权重都要在实验里反复调。4.3 用代码实现一个轻量规则奖励函数下面是一个稍微完整的奖励函数示例包含测试通过率、编译错误、长度惩罚和禁用词惩罚。FORBIDDEN_PATTERNS [ print(expected), assert True, return None ] def compute_rule_reward(pass_count, total, error_msg, code): reward 0.0 if error_msg: reward - 0.5 elif total 0: reward pass_count / total # 长度惩罚代码异常长时轻微扣分 length len(code.splitlines()) if length 80: reward - 0.01 * (length - 80) # 禁用模式惩罚防止模型绕过测试 for pattern in FORBIDDEN_PATTERNS: if pattern in code: reward - 1.0 break return max(reward, -2.0)这个函数的含义是首先保证“通过测试”是主要目标然后通过长度惩罚鼓励精简代码通过禁用模式惩罚防止硬编码。注意这些惩罚只适合作为辅助信号权重不能太大。4.4 常见奖励陷阱奖励作弊、稀疏奖励、信号噪声奖励设计里最容易踩的坑有四个奖励作弊Reward Hacking。模型学会了输出def add(a,b): print(3)之类的代码来骗过测试。缓解办法是使用隐藏测试集并在可见测试中随机抽样子集。稀疏奖励。规则奖励在复杂任务里几乎全是 0模型学不到东西。缓解办法是加入过程奖励、分步成功信号或使用课程学习。信号噪声。测试用例不稳定、浮点数比较失败、执行环境波动都会让奖励不准确。缓解办法是固定随机种子、使用容差比较、重复多次执行取中位数。过度优化单一指标。模型在训练集测试用例上通过率很高但换一个 hidden test 就崩。缓解办法是始终保留一个冻结评估集定期跑 passk。注意奖励函数是会被策略反向利用的。如果奖励规则里有明确漏洞模型会以你想不到的方式发现它。因此奖励函数上线前要做对抗性检查。5. 最小可复现实验在一道编程题上完成 Data - Trajectory - Reward - Update理解了数据、轨迹、奖励之后最好能亲手跑通一个最小闭环。这里以一个小规模 Python 实验为例演示“数据加载 - 采样轨迹 - 计算奖励 - 组织训练数据”的完整流程。完整 RL 更新需要显卡和框架这里重点是突出数据流设计而不是封装完整的 PPO/GRPO。5.1 实验目标和环境准备实验目标从 MBPP 风格数据集中取出一个任务让模型生成多个候选解在沙箱中执行计算奖励并把轨迹保存成 JSONL 文件。这样后续任何 RL 算法都可以直接读这条文件。需要准备的基础环境Python 3.9一个可用的代码生成模型本文示例使用 HuggingFace transformers 接口本地可执行 Python 的 subprocess 环境建议在容器里操作依赖版本在写代码前要确认。不同 transformers 版本的生成参数略有差异。5.2 实现数据加载、轨迹采样和奖励计算先构造一个最小数据集tasks [ { task_id: mbpp_demo_001, prompt: def add(a, b):\n \\\返回 a 和 b 的和。\\\\n, test_code: ( try:\n assert add(1, 2) 3\n print(PASS)\n except AssertionError:\n print(FAIL)\n finally:\n print(TOTAL: 1)\n ) } ]然后实现一个采样函数。这里用 transformers 的 pipeline 或 generate 接口from transformers import AutoModelForCausalLM, AutoTokenizer model_name Qwen/Qwen2.5-Coder-1.5B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) def generate_code(prompt, temperature0.7, max_new_tokens256): messages [{role: user, content: f请补齐以下 Python 函数。\n{prompt}}] text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue ) inputs tokenizer(text, return_tensorspt) outputs model.generate( **inputs, max_new_tokensmax_new_tokens, temperaturetemperature, do_sampleTrue, top_p0.9 ) return tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokensTrue)这里要注意不同模型生成的格式不同可能包含解释文字。真正实验时需要用正则或启发式规则提取代码块。示例中直接假设模型输出是纯代码实际并不可靠。然后组合出完整轨迹采集流程import json import time def run_one_task(task, num_samples5): trajectories [] for sample_idx in range(num_samples): traj_id f{task[task_id]}_sample_{sample_idx} start time.time() code generate_code(task[prompt]) env MinimalCodingEnv(task[prompt], task[test_code]) obs env.reset() reward 0.0 done False actions [] for step in range(3): obs, reward, done, info env.step(code) actions.append({ step: step, action_type: generate, content: code, observation: obs, reward: reward }) if done: break trajectories.append({ trajectory_id: traj_id, task_id: task[task_id], prompt: task[prompt], actions: actions, final_code: code, reward: reward, done: done, metadata: { sample_idx: sample_idx, execution_time_ms: int((time.time() - start) * 1000) } }) return trajectories这个流程中MinimalCodingEnv来自前文示例。每个样本最多执行 3 步记录每步观察和奖励最后保存为 JSON。5.3 用 GRPO/PPO 风格更新最小流程最小闭环最后一步是把轨迹转成 RL 可用的样本。这里用 GRPO 的简化思想同一 prompt 采样多个答案计算组内相对奖励再用 policy gradient 更新。def normalize_rewards(trajectories): rewards [t[reward] for t in trajectories] mean sum(rewards) / len(rewards) std (sum((r - mean) ** 2 for r in rewards) / len(rewards)) ** 0.5 eps 1e-6 for t in trajectories: t[advantage] (t[reward] - mean) / (std eps) return trajectories这里advantage表示某条样本在同一组样本中的相对好坏。GRPO 不再需要独立的价值网络而是用组内归一化替代。完整实现还要计算 log-prob 和 KL 惩罚但核心数据结构就是这样。5.4 运行验证日志指标和预期输出运行上述流程后建议输出以下信息task_id: mbpp_demo_001 generated: 5 traces reward list: [1.0, 0.0, 1.0, 1.0, 0.0] mean reward: 0.6 timeout count: 0 error count: 1如果看到 mean reward 长时间为 0优先检查测试代码本身是否能运行还要检查生成的代码是否包含多余文本。如果所有轨迹 reward 都是 1.0则要怀疑训练集过于简单或者模型见过测试答案出现了数据泄露。6. 从实验到生产数据管理、轨迹存储、奖励稳定性和评估体系最小实验跑通后下一步是考虑生产规模化。生产环境不是简单把 Python 脚本重复跑很多遍而是要解决数据版本、轨迹存储格式、奖励稳定性、评估回归等工程问题。6.1 RL 训练数据管线去重、Leak、难易度平衡生产级数据管线至少包含五个环节任务去重。使用代码规范化、AST hash 或 MinHash 去重。数据泄露检查。将所有基准评估集如 HumanEval作为黑名单避免进入训练集。测试用例质量检查。每个任务的可见测试和隐藏测试要分开隐藏测试不参与奖励计算。难度平衡。按通过率将任务分桶采样时保证每个桶有一定比例避免模型只学简单任务。数据版本化。每个训练数据集都应该有唯一版本号训练日志里记录dataset_version。如果暂时没有完整工具链可以先用一个 JSON 文件加一个 SHA256 checksum。发现训练结果变差时能回溯到具体数据版本。6.2 轨迹数据的存储与回放数据库、格式、版本轨迹数据是 RL 训练过程中的核心资产。建议使用 Parquet 或 JSONL 作为基础存储格式并使用列式存储便于过滤和分析。常见字段如下字段类型说明trajectory_idstring全局唯一 IDtask_idstring对应任务 IDpromptstring任务初始描述actionslist[dict]每一步动作与观察final_codestring最终生成的代码rewardfloat最终奖励metadatamap模型、温度、执行时间等在回放阶段可以把轨迹转换成 RL 训练所需格式。比如 PPO 需要state, action, log_prob, reward, done而 GRPO 需要同一 prompt 下多个样本的 advantage。建议在轨迹存储层就写入prompt_key字段方便按 task 聚合。生产环境还需要考虑数据保留策略。轨迹数据会非常大建议定期归档低质量轨迹只保留 reward 在某个阈值以上的样本用于后续微调。6.3 奖励函数生产化规则与模型评估的权衡规则奖励简单稳定但容易被 hack。LLM-as-judge 更灵活但 speed 和成本都不低。生产环境通常采用多信号加权执行结果为主信号权重占 0.6 - 0.8。代码质量信号为辅权重 0.1 - 0.2。LLM judge 作为监督信号权重 0.1 - 0.2。在训练过程中要持续记录奖励每个分量的分布而不是只看总奖励。如果总奖励上升但测试通过率下降说明其它信号权重过高正在发生 reward hacking。6.4 持续评估在 HumanEval、MBPP、SWE-bench 等基准上的回归测试RL 训练容易出现过拟合到训练环境的现象。因此必须设置冻结评估集。建议在训练过程中每隔固定步数跑一次 passk。评估集不参与任何训练所有测试用例都应该是模型没有见过的。评估指标上除了 pass1还可以看 pass10、pass100以及多步骤工具使用上的成功率。对于 Coding Agent常见指标还包括成功完成率完整解决任务的比例。平均步数任务完成所需的交互轮数。平均日志次数修复失败尝试次数。执行超时率代码执行超时的比例。这些指标能反映模型的稳定性和效率。7. 常见问题与排查路径样本为 0、奖励不涨、轨迹断链、奖励被 hack即使数据、轨迹、奖励都搭好了实际训练还是会出问题。这里列几个高频现象和排查路径。7.1 现象reward 一直不升反降可能原因测试代码本身有错所有样本 reward 都为 0。奖励信号噪声太大temperature 过高。训练数据过难模型一直没有中间奖励。检查方式先随机采样 20 条轨迹打印每条 reward 和 error。用温度 0.0 跑同一个任务确认环境是否稳定。观察每一步 reward 分布是否集中在少数值。解决方式先用简单任务跑通流程。加入过程奖励或步骤奖励。降低温度提高采样稳定性。7.2 现象模型只会输出空函数或重复代码可能原因惩罚函数里“长度过短”没有惩罚模型发现空函数能避免报错。生成时 max_tokens 太小输出被截断。模型本身微调不充分。检查方式打印生成代码长度分布。查看奖励是否在“空函数”上有非零分。解决方式在奖励函数中加入“语法错误”惩罚空函数如果没有通过测试应给负分。提高 max_tokens或对输出做是否包含 return 的规则检查。如果模型能力不足先做 SFT 再进入 RL。7.3 现象轨迹采集过程中 agent 卡死或超时可能原因执行环境没有限制最大运行时间。模型生成无限循环代码。单步执行时间设置过长。检查方式查看轨迹记录的execution_time_ms字段。统计 timeout 比例。解决方式所有执行都必须有子进程超时。在容器中设置 CPU 和内存限制。对超时样本直接给 0 奖励并保留原始错误信息到轨迹里。注意轨迹采集的超时必须作为一等字段记录不能只在日志里报错。否则后续训练时会发现一半轨迹缺失 terminal 状态。7.4 现象训练失真rollout 时和训练时不一致可能原因训练时奖励函数与 rollout 时不一致。轨迹采集中使用了不同的测试集。采样和训练之间模型版本不一致。检查方式确保 rollout 代码和训练代码使用同一个奖励函数包。在每条 sample 里写入reward_fn_version。定期用“回放目录”验证历史轨迹能否复现奖励。解决方式把奖励函数和数据集版本号写入每一条轨迹。训练前先跑一个回归脚本随机抽 100 条轨迹重新计算奖励并对比。禁止在训练中途修改奖励函数如需修改必须重新采集轨迹。8. 最佳实践与下一步建议Coding Agent RL 的工程链路并不轻松。数据、轨迹、奖励、训练和评估每一步都可能出问题。最后给出一份可以直接用的检查清单以及适合小团队推进的路线。8.1 RL 训练前应该完成的检查清单在启动一轮 Coding Agent RL 训练前建议逐项确认任务是否有可执行的测试用例且可见测试与隐藏测试已分离。数据集是否去重并已排除所有评估基准。执行环境是否沙箱化是否设置了超时、CPU、内存限制。轨迹格式是否包含动作数组、观察、奖励、终止原因和元信息。奖励函数是否有版本号是否在提交前运行过回归测试。是否记录了每次采样的模型版本、采样参数和 prompt 模板。是否设置了冻结评估集并确定评估指标pass1、pass10、平均步数等。是否在训练日志中记录奖励各分量分布而不是只记录总 reward。这份清单可以打印出来贴在实验记录里。任何一项没有确认都不建议直接启动大规模训练。8.2 小型团队可以优先尝试的路线如果团队刚起步不建议直接复现最复杂的 SWE-bench Agent RL 全流程。可以考虑分三步走第一步用一个单函数数据集比如 MBPP 子集配合规则奖励跑通采样、轨迹存储、GRPO/PPO 更新闭环。第二步加入多步骤 debug 环境。让模型先写代码看到报错再修改最多 3 步。奖励函数加入步骤成功信号。第三步再引入 LLM-as-judge 或代码质量信号同时接入 SWE-bench 这类真实工程任务。这样每步都能较快看到效果也便于定位问题。8.3 从 Coding Agent RL 延伸出去评估、安全、多步工具使用Coding Agent RL 并不只是“让模型通过更多测试”那么简单。真正的工程实践中还需要关注代码安全、恶意代码生成、隐私泄露以及 Agent 是否能在长链路工具调用中保持稳定。后续可以继续深入的方向包括RLAIF 如何与规则奖励结合、如何设计更稳定的过程奖励、如何用离线 RL 降低 rollout 成本、如何基于轨迹数据做更细粒度的策略评估。每一个方向都能单独形成完整实验。对于新手建议先把手上的最小闭环跑稳再去追求复杂的模型和算法。RL 在代码生成上的上限固然由模型决定但下限往往取决于你为它准备的数据、轨迹和奖励工程是否扎实。 Coding Agent RL工程实践：数据、轨迹与奖励函数设计
Coding Agent RL 这个方向听起来像是把两个大词堆在一起一边是能写代码的智能体Coding Agent一边是让策略不断试错的强化学习Reinforcement LearningRL。但真正落地时会发现问题远不只是“让模型自己生成代码再跑一下 test case”这么简单。数据从哪里来、智能体与环境交互的轨迹怎么采集、执行结果如何换算成奖励这三个环节直接决定了训练是向上收敛还是在原地空转。这篇文章从工程实践角度拆解这三件事。我会先说明 Coding Agent RL 训练闭环里数据、轨迹、奖励各自承担什么角色然后分别讨论公开数据集怎么选、轨迹如何采集与存储、奖励函数怎么设计最后给出一个最小实验闭环和环境搭建建议。适合正在做 Coding Agent RL 调研、准备搭建小规模训练实验或者已经跑通 SFTSupervised Fine-Tuning但想用 RL 进一步优化代码生成质量的开发者。1. 先理清 Coding Agent RL 的训练闭环数据、轨迹和奖励分别承担什么角色Coding Agent RL 还没有一个完全统一的官方定义但研究和工作里常见的路径是一致的把“完成编程任务”建模成智能体与代码执行环境交互的过程。模型通过生成代码、运行测试、读取报错、修改代码等动作与环境互动环境返回执行结果再按规则换算成奖励信号最终用强化学习算法更新模型参数。这个闭环里数据、轨迹、奖励是互相咬合的三块。脱离任何一块实验都很容易失控。1.1 从机器学习三要素看 RL 在代码生成中的位置经典机器学习三要素是数据、模型、算法。Coding Agent RL 里可以对应成数据编程任务描述、初始代码、测试用例、提交记录、issue 描述等。模型负责生成动作的策略模型通常是语言模型以自回归方式输出代码片段或工具调用。算法强化学习更新规则常见的有 PPO、GRPO、RLAIFAI Feedback 作为奖励等。但 Coding Agent RL 与普通监督学习最大的区别在于它多了一个“环境”。环境不是静态的答案对而是可以执行代码、返回结果、判断对错的系统。模型每次生成后环境会给出新状态代码是否通过测试、运行是否超时、编译是否有错、修改后是否修复了原问题。模型需要根据这些反馈决定下一步动作。这就是为什么 Coding Agent RL 常常被看作“代码生成 智能体 强化学习”的交叉任务。它不只是让模型输出更像人类代码而是让模型在真实可执行的环境中学会怎样做能通过任务约束。1.2 一条训练样本的完整生命周期代码任务 - 轨迹 - 奖励 - 策略更新理解训练样本生命周期是后面所有设计的前提。假设我们拿 MBPP 中的一个简单任务给模型任务描述编写一个函数输入两个整数返回它们的和。模型动作生成一段 Python 函数代码。环境反馈执行测试用例发现其中一个用例失败。模型再次动作修改函数。环境反馈全部测试通过。奖励计算通过率 1.0格式和长度惩罚很小最终奖励 0.95。策略更新用这条轨迹和奖励更新模型让类似任务上有更高概率生成通过测试的代码。注意这里“轨迹”不是只有最终答案。完整的轨迹应当包括每一步动作、观察结果、中间状态和终止原因。SFT 训练时我们只要求模型输出与人工答案相似RL 训练时我们要求模型在环境里真正完成任务。这意味着奖励函数要能区分“只是输出形式像”和“真正执行通过”这两种情况。注意Coding Agent RL 需要的不是“文本答案”数据集而是“可交互环境 可执行反馈”的数据集。没有测试用例和执行环境RL 就没有训练信号。2. 数据来源怎么选不是所有代码数据集都适合做 RL 基础数据是所有环节的起点。很多刚开始做 Coding Agent RL 的同学会直接拿开源代码语料库或者答题数据集开始训练结果发现奖励完全不涨。原因往往是数据集没有配套测试用例或者任务类型与目标场景不符。所以先要把数据来源按任务类型分清楚再做清洗和难度分层。2.1 按任务类型盘点公开代码数据集下面整理几个 Coding Agent RL 实验里常见的数据集按任务类型区分。这里的“规模”是公开资料中的大致情况实际使用时建议以当时拉取到的版本为准。数据集任务类型大致规模适合用途HumanEval函数级代码生成164 个 Python 问题基础生成能力、passk 评估MBPP函数级 Python 入门任务约 1000 个问题小规模 RL 实验、规则奖励调参APPS从入门到竞赛的编程题千级以上难度分层、竞赛代码生成CodeContests编程竞赛题 大量测试大规模竞赛样本复杂推理、多步调试TACO带算法标签的竞赛题数千题算法类型分析、难度分层SWE-bench真实 GitHub issue 修复数千个 issueAgent 多步骤修复、工具使用BigCodeBench注重真实库函数调用千级任务工具/库函数使用能力从 RL 角度最重要的一列是“是否自带可执行测试”。HumanEval 和 MBPP 自带简单测试适合先跑通最小闭环。SWE-bench 更接近真实工程场景但每一条任务都需要构造仓库环境轨迹采集成本高很多。2.2 数据清洗和难度分层先想清楚 RL 要解决什么缺陷拿到数据集后不能直接开工。有四个清洗动作是必须做的去重和溯源。如果训练集与评估集有重叠最后的 passk 会被高估。建议对代码做规范化后做 MinHash 或直接 ID 去重。补充测试用例。很多数据集只有少数测试用例容易出现“奖励被 hack”的情况。比如模型可以硬编码预期输出。最好保留一个隐藏测试集训练时用可见测试评估时用隐藏测试。过滤不可执行样本。先跑一遍全量样本把无法导入、总是崩溃、环境依赖重的样本剔除。难度分层。RL 初期建议从容易拿到中间奖励的任务开始。如果一开始全是竞赛题奖励几乎全是 0训练会非常慢。难度分层可以用题目长度、通过率、解题时间等作为代理指标。比如先按“单函数实现”和“多步骤修复”区分再按通过率排序。这样便于控制训练曲线。2.3 基础模型预训练数据 vs RL 训练数据的区别很多人会误以为“预训练数据那么多RL 也可以直接用”。实际差别很大数据类型目标反馈来源数据形态预训练数据学习语言模式和代码结构自回归语言模型损失海量文本/代码指令微调数据对齐指令学会输出格式下一个 token 预测指令 回答RL 训练数据在环境交互中最大化奖励执行结果、测试通过率、模型评判任务 环境 轨迹预训练数据没有“对错”概念模型不知道代码跑起来是否通过。RL 数据必须带有环境反馈而且反馈要可计算、可复现、可验证。这也是 Coding Agent RL 数据量通常远小于预训练数据但每条数据工程价值更高的原因。实际项目中如果原始材料没有给出明确版本落地前要先确认依赖版本和数据集许可。尤其是从 GitHub 抓取代码做训练时要遵守仓库的开源协议。3. 轨迹采集代码 Agent 与环境交互的数据怎么记录有了数据集下一步不是直接算奖励而是先设计好“轨迹采集”流程。轨迹是模型与环境交互的完整记录。没有轨迹策略更新就缺少训练样本轨迹不完整排错时就会无从下手。3.1 典型 Coding Agent 的观测、动作和执行环境一个代码 Agent 每一步会看到什么、能做什么取决于环境设计。观察Observation常见包括任务描述和初始代码。当前工作区文件列表。最近一次执行输出、编译错误、测试失败信息。执行超时、内存限制等资源信息。如果接入了工具还有代码搜索、文档检索结果。动作Action常见包括生成新代码片段。修改某个文件中的某一行。运行指定测试用例。执行 shell 命令。读取文件内容。执行环境Execution Environment必须可控。真实开发中不能直接在训练机上直接运行模型生成的任意代码。推荐的做法是用 Docker 容器、AWS Firecracker 微虚拟机或者至少是受限的 subprocess 加上 CPU/内存/网络隔离。注意轨迹采集系统要在第一步就考虑安全边界。生成代码可能包含系统调用、无限循环、恶意文件操作生产环境必须做沙箱隔离。3.2 用最小 Python 环境模拟一次轨迹采集为了讲清楚轨迹采集的机制下面用一个最小的 Python 示例说明。真实生产环境不会直接这样执行但逻辑是相同的。import subprocess import tempfile import json import uuid class MinimalCodingEnv: def __init__(self, task_prompt: str, test_code: str, timeout: int 5): self.task_prompt task_prompt self.test_code test_code self.timeout timeout self.step_count 0 self.done False self.last_output self.last_error def reset(self): self.step_count 0 self.done False self.last_output self.last_error return { observation: self.task_prompt, step: 0, done: False } def step(self, code: str): self.step_count 1 if self.done: raise RuntimeError(Episode already done) combined_code code \n\n self.test_code try: # 生产环境不要直接使用 subprocess shell这里仅做演示 result subprocess.run( [python, -c, combined_code], capture_outputTrue, textTrue, timeoutself.timeout ) self.last_output result.stdout self.last_error result.stderr if result.returncode ! 0: reward 0.0 info {error: result.stderr} else: # 简单判断测试是否全部通过 pass_count result.stdout.count(PASS) total max(result.stdout.count(TOTAL), 1) reward pass_count / total info {pass_count: pass_count, total: total} except subprocess.TimeoutExpired: self.last_error timeout reward 0.0 info {error: timeout} self.done self.step_count 3 or reward 1.0 observation { output: self.last_output, error: self.last_error, step: self.step_count, done: self.done } return observation, reward, self.done, info这个环境的关键点有三个每次step都接收一段代码执行它。执行结果同时包含输出、错误、超时等信息。奖励在环境内部按简单规则算出便于后续记录轨迹。要注意subprocess.run直接在训练机器上执行代码存在安全风险。真实项目需要把代码放入容器或虚拟环境中执行并限制网络和文件系统访问。3.3 轨迹结构设计状态、动作、奖励、终止标记轨迹不是日志流水账而是可以直接用于 RL 训练的结构化样本。推荐用 JSON Lines 或 Parquet 存储每条记录包含{ trajectory_id: traj_0001, task_id: mbpp_001, prompt: 编写一个函数 add(a, b)返回两数之和。, initial_code: , actions: [ { step: 0, action_type: generate, content: def add(a, b):\n return a b, observation: output: PASS\nTOTAL: 3, reward: 1.0 } ], final_code: def add(a, b):\n return a b, reward: 1.0, done: true, terminal_reason: all_tests_passed, metadata: { model_name: qwen2.5-coder-1.5b, temperature: 0.7, env_timeout: 5, execution_time_ms: 1234 } }字段设计中最重要的是actions数组。它要包含每一步动作内容、动作类型、观察结果和阶段性奖励。后续训练时可以从这个数组构造强化学习所需的state, action, reward, next_state四元组也可以直接用于离线 RL。如果只想输出最终答案而不记录中间步骤会丢失大量可学习信息。比如模型修复 bug 的过程、遇到报错后的调整动作都是很有价值的训练信号。3.4 采样策略和多样性控制温度、退火、重复惩罚RL 轨迹采集需要一定随机性。如果采样温度太低模型每次都输出同样的代码奖励方差小策略难以学习温度太高输出质量不稳定奖励噪声大。参数常见范围对轨迹多样性的影响对奖励稳定性的影响temperature0.2 - 1.0越高输出差异越大越高奖励波动越大top_p0.8 - 1.0越高候选词范围越大越低越稳定repetition_penalty1.0 - 1.2可减少重复输出过高会降低生成质量max_tokens根据任务调整过小容易截断过大浪费算力实际采集中可以先用温度 0.7 生成多个候选再用温度 0.2 做贪心验证。这样既保留了探索性又能衡量输出稳定性。4. 奖励函数设计从执行结果到可学习的信号奖励函数是 Coding Agent RL 里最容易被低估的部分。很多人以为“测试通过就给 1 分不通过给 0 分”就够了。结果训练到后面模型学会硬编码测试用例或者只输出空函数来规避报错。奖励设计需要同时考虑结果、过程和对抗性。4.1 结果奖励单元测试通过率、编译错误、输出对比结果奖励来自最终执行结果最常见的有信号计算方式优点缺点单元测试通过率通过用例数 / 总用例数直观、可复现容易被硬编码或过拟合编译是否通过通过为 1否则为 0简单区分度低输出对比与预期输出逐字符比较精确对浮点和格式敏感运行时间超时惩罚或耗时奖励鼓励高效代码噪音大受硬件影响在实现时建议把“测试通过率”作为主要奖励把“编译错误”作为额外惩罚。比如def compute_result_reward(pass_count, total, has_error, timeoutFalse): if timeout: return 0.0 if has_error: return -0.5 if total 0: return 0.0 return pass_count / total这里给编译错误一个负分是为了让模型不要通过输出不合法代码来逃避测试。4.2 过程奖励意图匹配、分步执行反馈、代码质量信号过程奖励关注的是模型“怎么走到最终结果”而不是只看终点。它的核心作用是解决稀疏奖励问题。比如一个复杂修复任务如果模型必须经过 5 步才能修好前 4 步都没有最终奖励策略梯度会很难更新。常见过程奖励设计步骤奖励每成功执行一次测试给一个小分每修复一个编译错误给一个小分。意图匹配比较生成代码中是否包含与任务相关的关键词、函数调用、变量名。代码质量信号代码长度、重复度、圈复杂度、是否包含注释。注意这类信号容易退化成“模型学会把代码写得短但功能缺失”。LLM-as-judge用另一个模型对中间步骤打分。比如评价“模型是否在朝正确方向修复 bug”。这种方式灵活但成本高且不稳定。一个朴素的实现是把过程奖励加进总奖励def compute_total_reward( pass_count, total, has_error, step_reward, code_length, max_code_length200 ): result_part compute_result_reward(pass_count, total, has_error) step_part min(step_reward, 0.2) length_penalty max(0.0, (code_length - max_code_length) / max_code_length) * 0.05 return result_part step_part - length_penalty这里每个分量都设有上限避免某一路信号淹没主信号。实际项目中所有权重都要在实验里反复调。4.3 用代码实现一个轻量规则奖励函数下面是一个稍微完整的奖励函数示例包含测试通过率、编译错误、长度惩罚和禁用词惩罚。FORBIDDEN_PATTERNS [ print(expected), assert True, return None ] def compute_rule_reward(pass_count, total, error_msg, code): reward 0.0 if error_msg: reward - 0.5 elif total 0: reward pass_count / total # 长度惩罚代码异常长时轻微扣分 length len(code.splitlines()) if length 80: reward - 0.01 * (length - 80) # 禁用模式惩罚防止模型绕过测试 for pattern in FORBIDDEN_PATTERNS: if pattern in code: reward - 1.0 break return max(reward, -2.0)这个函数的含义是首先保证“通过测试”是主要目标然后通过长度惩罚鼓励精简代码通过禁用模式惩罚防止硬编码。注意这些惩罚只适合作为辅助信号权重不能太大。4.4 常见奖励陷阱奖励作弊、稀疏奖励、信号噪声奖励设计里最容易踩的坑有四个奖励作弊Reward Hacking。模型学会了输出def add(a,b): print(3)之类的代码来骗过测试。缓解办法是使用隐藏测试集并在可见测试中随机抽样子集。稀疏奖励。规则奖励在复杂任务里几乎全是 0模型学不到东西。缓解办法是加入过程奖励、分步成功信号或使用课程学习。信号噪声。测试用例不稳定、浮点数比较失败、执行环境波动都会让奖励不准确。缓解办法是固定随机种子、使用容差比较、重复多次执行取中位数。过度优化单一指标。模型在训练集测试用例上通过率很高但换一个 hidden test 就崩。缓解办法是始终保留一个冻结评估集定期跑 passk。注意奖励函数是会被策略反向利用的。如果奖励规则里有明确漏洞模型会以你想不到的方式发现它。因此奖励函数上线前要做对抗性检查。5. 最小可复现实验在一道编程题上完成 Data - Trajectory - Reward - Update理解了数据、轨迹、奖励之后最好能亲手跑通一个最小闭环。这里以一个小规模 Python 实验为例演示“数据加载 - 采样轨迹 - 计算奖励 - 组织训练数据”的完整流程。完整 RL 更新需要显卡和框架这里重点是突出数据流设计而不是封装完整的 PPO/GRPO。5.1 实验目标和环境准备实验目标从 MBPP 风格数据集中取出一个任务让模型生成多个候选解在沙箱中执行计算奖励并把轨迹保存成 JSONL 文件。这样后续任何 RL 算法都可以直接读这条文件。需要准备的基础环境Python 3.9一个可用的代码生成模型本文示例使用 HuggingFace transformers 接口本地可执行 Python 的 subprocess 环境建议在容器里操作依赖版本在写代码前要确认。不同 transformers 版本的生成参数略有差异。5.2 实现数据加载、轨迹采样和奖励计算先构造一个最小数据集tasks [ { task_id: mbpp_demo_001, prompt: def add(a, b):\n \\\返回 a 和 b 的和。\\\\n, test_code: ( try:\n assert add(1, 2) 3\n print(PASS)\n except AssertionError:\n print(FAIL)\n finally:\n print(TOTAL: 1)\n ) } ]然后实现一个采样函数。这里用 transformers 的 pipeline 或 generate 接口from transformers import AutoModelForCausalLM, AutoTokenizer model_name Qwen/Qwen2.5-Coder-1.5B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) def generate_code(prompt, temperature0.7, max_new_tokens256): messages [{role: user, content: f请补齐以下 Python 函数。\n{prompt}}] text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue ) inputs tokenizer(text, return_tensorspt) outputs model.generate( **inputs, max_new_tokensmax_new_tokens, temperaturetemperature, do_sampleTrue, top_p0.9 ) return tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokensTrue)这里要注意不同模型生成的格式不同可能包含解释文字。真正实验时需要用正则或启发式规则提取代码块。示例中直接假设模型输出是纯代码实际并不可靠。然后组合出完整轨迹采集流程import json import time def run_one_task(task, num_samples5): trajectories [] for sample_idx in range(num_samples): traj_id f{task[task_id]}_sample_{sample_idx} start time.time() code generate_code(task[prompt]) env MinimalCodingEnv(task[prompt], task[test_code]) obs env.reset() reward 0.0 done False actions [] for step in range(3): obs, reward, done, info env.step(code) actions.append({ step: step, action_type: generate, content: code, observation: obs, reward: reward }) if done: break trajectories.append({ trajectory_id: traj_id, task_id: task[task_id], prompt: task[prompt], actions: actions, final_code: code, reward: reward, done: done, metadata: { sample_idx: sample_idx, execution_time_ms: int((time.time() - start) * 1000) } }) return trajectories这个流程中MinimalCodingEnv来自前文示例。每个样本最多执行 3 步记录每步观察和奖励最后保存为 JSON。5.3 用 GRPO/PPO 风格更新最小流程最小闭环最后一步是把轨迹转成 RL 可用的样本。这里用 GRPO 的简化思想同一 prompt 采样多个答案计算组内相对奖励再用 policy gradient 更新。def normalize_rewards(trajectories): rewards [t[reward] for t in trajectories] mean sum(rewards) / len(rewards) std (sum((r - mean) ** 2 for r in rewards) / len(rewards)) ** 0.5 eps 1e-6 for t in trajectories: t[advantage] (t[reward] - mean) / (std eps) return trajectories这里advantage表示某条样本在同一组样本中的相对好坏。GRPO 不再需要独立的价值网络而是用组内归一化替代。完整实现还要计算 log-prob 和 KL 惩罚但核心数据结构就是这样。5.4 运行验证日志指标和预期输出运行上述流程后建议输出以下信息task_id: mbpp_demo_001 generated: 5 traces reward list: [1.0, 0.0, 1.0, 1.0, 0.0] mean reward: 0.6 timeout count: 0 error count: 1如果看到 mean reward 长时间为 0优先检查测试代码本身是否能运行还要检查生成的代码是否包含多余文本。如果所有轨迹 reward 都是 1.0则要怀疑训练集过于简单或者模型见过测试答案出现了数据泄露。6. 从实验到生产数据管理、轨迹存储、奖励稳定性和评估体系最小实验跑通后下一步是考虑生产规模化。生产环境不是简单把 Python 脚本重复跑很多遍而是要解决数据版本、轨迹存储格式、奖励稳定性、评估回归等工程问题。6.1 RL 训练数据管线去重、Leak、难易度平衡生产级数据管线至少包含五个环节任务去重。使用代码规范化、AST hash 或 MinHash 去重。数据泄露检查。将所有基准评估集如 HumanEval作为黑名单避免进入训练集。测试用例质量检查。每个任务的可见测试和隐藏测试要分开隐藏测试不参与奖励计算。难度平衡。按通过率将任务分桶采样时保证每个桶有一定比例避免模型只学简单任务。数据版本化。每个训练数据集都应该有唯一版本号训练日志里记录dataset_version。如果暂时没有完整工具链可以先用一个 JSON 文件加一个 SHA256 checksum。发现训练结果变差时能回溯到具体数据版本。6.2 轨迹数据的存储与回放数据库、格式、版本轨迹数据是 RL 训练过程中的核心资产。建议使用 Parquet 或 JSONL 作为基础存储格式并使用列式存储便于过滤和分析。常见字段如下字段类型说明trajectory_idstring全局唯一 IDtask_idstring对应任务 IDpromptstring任务初始描述actionslist[dict]每一步动作与观察final_codestring最终生成的代码rewardfloat最终奖励metadatamap模型、温度、执行时间等在回放阶段可以把轨迹转换成 RL 训练所需格式。比如 PPO 需要state, action, log_prob, reward, done而 GRPO 需要同一 prompt 下多个样本的 advantage。建议在轨迹存储层就写入prompt_key字段方便按 task 聚合。生产环境还需要考虑数据保留策略。轨迹数据会非常大建议定期归档低质量轨迹只保留 reward 在某个阈值以上的样本用于后续微调。6.3 奖励函数生产化规则与模型评估的权衡规则奖励简单稳定但容易被 hack。LLM-as-judge 更灵活但 speed 和成本都不低。生产环境通常采用多信号加权执行结果为主信号权重占 0.6 - 0.8。代码质量信号为辅权重 0.1 - 0.2。LLM judge 作为监督信号权重 0.1 - 0.2。在训练过程中要持续记录奖励每个分量的分布而不是只看总奖励。如果总奖励上升但测试通过率下降说明其它信号权重过高正在发生 reward hacking。6.4 持续评估在 HumanEval、MBPP、SWE-bench 等基准上的回归测试RL 训练容易出现过拟合到训练环境的现象。因此必须设置冻结评估集。建议在训练过程中每隔固定步数跑一次 passk。评估集不参与任何训练所有测试用例都应该是模型没有见过的。评估指标上除了 pass1还可以看 pass10、pass100以及多步骤工具使用上的成功率。对于 Coding Agent常见指标还包括成功完成率完整解决任务的比例。平均步数任务完成所需的交互轮数。平均日志次数修复失败尝试次数。执行超时率代码执行超时的比例。这些指标能反映模型的稳定性和效率。7. 常见问题与排查路径样本为 0、奖励不涨、轨迹断链、奖励被 hack即使数据、轨迹、奖励都搭好了实际训练还是会出问题。这里列几个高频现象和排查路径。7.1 现象reward 一直不升反降可能原因测试代码本身有错所有样本 reward 都为 0。奖励信号噪声太大temperature 过高。训练数据过难模型一直没有中间奖励。检查方式先随机采样 20 条轨迹打印每条 reward 和 error。用温度 0.0 跑同一个任务确认环境是否稳定。观察每一步 reward 分布是否集中在少数值。解决方式先用简单任务跑通流程。加入过程奖励或步骤奖励。降低温度提高采样稳定性。7.2 现象模型只会输出空函数或重复代码可能原因惩罚函数里“长度过短”没有惩罚模型发现空函数能避免报错。生成时 max_tokens 太小输出被截断。模型本身微调不充分。检查方式打印生成代码长度分布。查看奖励是否在“空函数”上有非零分。解决方式在奖励函数中加入“语法错误”惩罚空函数如果没有通过测试应给负分。提高 max_tokens或对输出做是否包含 return 的规则检查。如果模型能力不足先做 SFT 再进入 RL。7.3 现象轨迹采集过程中 agent 卡死或超时可能原因执行环境没有限制最大运行时间。模型生成无限循环代码。单步执行时间设置过长。检查方式查看轨迹记录的execution_time_ms字段。统计 timeout 比例。解决方式所有执行都必须有子进程超时。在容器中设置 CPU 和内存限制。对超时样本直接给 0 奖励并保留原始错误信息到轨迹里。注意轨迹采集的超时必须作为一等字段记录不能只在日志里报错。否则后续训练时会发现一半轨迹缺失 terminal 状态。7.4 现象训练失真rollout 时和训练时不一致可能原因训练时奖励函数与 rollout 时不一致。轨迹采集中使用了不同的测试集。采样和训练之间模型版本不一致。检查方式确保 rollout 代码和训练代码使用同一个奖励函数包。在每条 sample 里写入reward_fn_version。定期用“回放目录”验证历史轨迹能否复现奖励。解决方式把奖励函数和数据集版本号写入每一条轨迹。训练前先跑一个回归脚本随机抽 100 条轨迹重新计算奖励并对比。禁止在训练中途修改奖励函数如需修改必须重新采集轨迹。8. 最佳实践与下一步建议Coding Agent RL 的工程链路并不轻松。数据、轨迹、奖励、训练和评估每一步都可能出问题。最后给出一份可以直接用的检查清单以及适合小团队推进的路线。8.1 RL 训练前应该完成的检查清单在启动一轮 Coding Agent RL 训练前建议逐项确认任务是否有可执行的测试用例且可见测试与隐藏测试已分离。数据集是否去重并已排除所有评估基准。执行环境是否沙箱化是否设置了超时、CPU、内存限制。轨迹格式是否包含动作数组、观察、奖励、终止原因和元信息。奖励函数是否有版本号是否在提交前运行过回归测试。是否记录了每次采样的模型版本、采样参数和 prompt 模板。是否设置了冻结评估集并确定评估指标pass1、pass10、平均步数等。是否在训练日志中记录奖励各分量分布而不是只记录总 reward。这份清单可以打印出来贴在实验记录里。任何一项没有确认都不建议直接启动大规模训练。8.2 小型团队可以优先尝试的路线如果团队刚起步不建议直接复现最复杂的 SWE-bench Agent RL 全流程。可以考虑分三步走第一步用一个单函数数据集比如 MBPP 子集配合规则奖励跑通采样、轨迹存储、GRPO/PPO 更新闭环。第二步加入多步骤 debug 环境。让模型先写代码看到报错再修改最多 3 步。奖励函数加入步骤成功信号。第三步再引入 LLM-as-judge 或代码质量信号同时接入 SWE-bench 这类真实工程任务。这样每步都能较快看到效果也便于定位问题。8.3 从 Coding Agent RL 延伸出去评估、安全、多步工具使用Coding Agent RL 并不只是“让模型通过更多测试”那么简单。真正的工程实践中还需要关注代码安全、恶意代码生成、隐私泄露以及 Agent 是否能在长链路工具调用中保持稳定。后续可以继续深入的方向包括RLAIF 如何与规则奖励结合、如何设计更稳定的过程奖励、如何用离线 RL 降低 rollout 成本、如何基于轨迹数据做更细粒度的策略评估。每一个方向都能单独形成完整实验。对于新手建议先把手上的最小闭环跑稳再去追求复杂的模型和算法。RL 在代码生成上的上限固然由模型决定但下限往往取决于你为它准备的数据、轨迹和奖励工程是否扎实。