Coding Agent强化学习实战：数据、轨迹与奖励函数设计指南

做 Coding Agent 相关的强化学习RL时很多人第一周就卡住了。模型结构可以抄训练框架可以用现成的但真正到了准备数据、采集轨迹、定义奖励函数这三步网上的资料要么只讲概念要么直接甩一个论文地址中间隔着大量工程细节。这篇文章不打算从强化学习的数学原理开始推导而是围绕大家问得最多的三个问题展开训练数据从哪里来、模型执行轨迹怎么采、奖励函数到底怎么定。内容会覆盖 Coding Agent RL 的基础概念、数据与轨迹的工程化处理方式、以及一套可以照着写的简化训练示例。无论你是刚接触 RL 的算法工程师还是想给编码助手接入强化学习训练的开发同学都可以沿着这篇文章的思路落地。1. 背景Coding Agent 和 RL 为什么绑在一起1.1 Coding Agent 和普通大模型的区别普通的大语言模型输入是一段文本输出是一段文本它只负责“生成”。而 Coding Agent 要解决的是更完整的任务理解用户需求、读取仓库代码、制定修改计划、生成多个文件、运行测试、根据错误信息迭代修复。整个过程是一个带状态的多步决策过程。举一个最简单的例子用户提问帮我给项目里所有 Python 文件加上类型注解。普通模型可能只生成一段说明或者一个补丁片段但 Coding Agent 需要扫描项目中的 Python 文件列表。理解每个文件的函数签名。规划哪些文件需要改动。逐个生成修改后的代码。运行静态检查或单元测试验证结果。根据报错继续修复。这个流程天然具备“状态-动作-反馈”的闭环结构正好是强化学习擅长处理的场景。模型每一步的“动作”会影响后续状态最终结果可以通过测试是否通过来获得反馈。这也是为什么近两年 Coding Agent 的进展开始和 RL 深度绑定普通指令微调SFT只能让模型学会“模仿正确结果”但很难让模型学会“在执行环境中试错并自我修正”。RL 提供了一个直接的优化信号让模型在真实执行结果中学习策略。1.2 RL 在 Coding Agent 中的位置RL 在 Coding Agent 训练中主要解决两个问题让模型学会“对自己生成的代码负责”通过执行结果反馈模型知道哪一步写错了、哪一步浪费时间了。让模型学会“长程规划”在多文件修改、长链路任务中模型需要平衡探索和利用不能每一步只盯着当前 token 的概率。从训练流程来看Coding Agent RL 通常不是从零训一个模型而是先有基础模型Base Model再经过 SFT 让模型学会工具调用和代码生成格式最后用 RL 提升策略。一个常见的训练流程是基础大模型 - 代码语料继续预训练 - SFT学会调用工具和生成代码- RL通过执行反馈优化策略有个容易混淆的点需要说明Coding Agent RL 中的“奖励”不一定是标量分数。它可以是一个规则判断结果比如编译是否通过、单元测试通过率也可以是一个模型给出的质量分比如代码风格分、逻辑正确性分。奖励函数设计得是否合理直接决定训练效果。1.3 当前的技术进展和趋势现在市面上的 Coding Agent 已经不是一个“生成式问答工具”而是能独立完成仓库级任务的智能体。这类系统对模型的“规划能力”和“反思能力”要求很高而这两种能力都很难通过简单的指令微调获得RL 成了当前提升这些能力的主要路径。从技术细节看很多 Coding Agent 采用了 Plan-then-Code 的策略模型先生成一份计划plan再基于计划编写代码。RL 训练时计划和代码作为同一策略的连续决策步骤被采样奖励在代码执行完成后统一给出。这样模型在训练中能学到“计划要做详细一点代码才能写得顺手”这种隐式关联。如果你在搜索引擎里看到“plan agent”“coding plan”这些说法本质上都是在描述这种把任务拆成“规划-执行”两个阶段的架构。后面的轨迹采集部分我会专门演示 Plan 和 Code 阶段的数据怎么组织。2. Coding Agent RL 的三个基本要素数据、轨迹、奖励在动手写代码之前先把框架立起来。一个完整的 Coding Agent RL 训练闭环包含下面三个核心部分数据来源训练问题从哪来 - 轨迹采集模型如何与环境交互产生中间过程 - 奖励函数如何给每一步或最终结果打分 - 策略优化GRPO / PPO / DPO 等算法更新模型 - 新的轨迹采集进入下一轮迭代很多团队 RL 效果不好并不是算法不行而是前面三个环节没有闭环。下面逐个拆解。2.1 数据来源RL 训练的问题从哪里来RL 训练中的“数据”本质上是一批带验证标准的问题。对于 Coding Agent 来说每条数据至少包含任务描述用户希望实现的功能、修复的问题或改造的需求。验证方式单元测试、集成测试、静态检查或者一段可以自动评估结果的脚本。可选上下文仓库结构、相关文件内容、已有代码。数据来源通常有几类公开代码数据集、合成数据、用户真实场景数据、专家构造数据。不同来源各有优劣后面的章节会展开。2.2 轨迹采集模型如何在环境中执行有了问题和验证方式接下来要让模型去“做一遍这道题”这就是轨迹采集。轨迹trajectory指的是模型从接收任务到产生最终结果之间的一系列中间状态和动作。对于 Coding Agent一条完整轨迹通常包括用户消息 - 模型思考过程 - 生成的计划文本 - 一次代码修改动作 - 命令执行结果 - 根据报错再次修改 - 最终提交结果这些中间过程非常重要。RL 不仅关心最终结果对不对还需要知道模型是怎么一步步走到那里的。如果模型生成的代码能通过测试那中间的计划很可能包含合理步骤如果模型绕了很大弯才通过我们可以通过轨迹分析发现问题。2.3 奖励函数给“好行为”打分奖励函数是 RL 训练中把“任务好坏的判断标准”翻译成数值信号的关键模块。对于代码生成任务最直接的奖励来自执行结果奖励信号说明优缺点编译是否通过代码能否被编译器/解释器接受简单直接但粒度太粗单元测试通过率多少测试用例通过与任务目标强相关是核心信号代码风格检查分是否符合 PEP8 等规范能提升可读性但不能替代功能正确性运行耗时代码执行是否高效适合算法优化类任务模型质量分由 Reward Model 或大模型打分灵活但可能引入偏好偏差后面的章节会详细比较这几种奖励的适用场景。3. 数据来源详解Coding Agent RL 的数据从哪来数据是 RL 训练的根基。没有高质量的问题和验证标准模型再强的策略也是“对着空气优化”。下面按来源分类讲解。3.1 公开代码数据集最容易想到的数据来源是公开的代码数据集。GitHub 上有大量开源仓库包含真实世界的代码问题和对应的解决方式。常见做法包括从开源仓库的 Issue 和 PR 中提取任务描述和代码变更形成“问题-补丁”对。使用代码竞赛平台的题目和评测用例。使用专门为代码模型构建的训练集例如包含自然语言指令和对应代码的数据。这类数据的优点是规模大、成本低缺点是噪声较高。很多 Repository 代码更新频繁任务描述和实际代码可能不对应直接拿来训练容易让模型学到错误映射。使用公开数据时建议做一次系统性的清洗1. 过滤掉包含敏感信息或私有密钥的仓库。 2. 过滤掉过于简单、无法形成有效训练的样本。 3. 过滤掉重复度高的代码片段。 4. 对测试用例进行人工抽查确保验证方式有效。3.2 合成数据与代码生成当公开数据不够用或者需要覆盖特定能力时可以用合成数据。合成数据的生产方式很多比较实用的有三种代码解释生成选一段高质量代码用大模型生成对应的任务描述要求模型“根据这段代码写一个用户会提出的需求”。任务反向生成给定功能描述让大模型补全测试用例和边界条件形成带验证的数据。数据增强修改已有问题的表达方式、参数类型、输入规模生成变体样本。合成数据的意义在于“按需制造”训练样本。比如当前模型在多仓库修改场景上能力偏弱就可以专门构造一批涉及多个文件改动的任务。不过合成数据也有风险。很多情况下生成的任务描述和代码并不完全匹配测试用例也不稳定模型可能学到“看起来合理但实际无法执行”的路径。因此所有合成数据必须经过执行验证确认测试用例能通过参考实现后再进入训练。3.3 用户真实场景数据如果 Coding Agent 已经上线用户真实请求是最宝贵的数据来源。真实数据天然贴近使用场景包含真实代码库、真实需求和真实边界情况。采集用户真实数据时要注意三点隐私与合规涉及用户代码的任务必须脱敏移除密钥、个人身份信息、内部路径。质量标准化用户请求风格差异很大需要统一成标准格式并补充测试用例。偏好标注如果用户对某个回答点了赞可以作为偏好信号如果用户关闭了会话也要考虑是否作为负样本。对于还没有用户量的团队可以考虑用内部业务需求构造一批“内部真实数据”。这类数据虽然数量不大但和线上场景最接近往往比大规模公开数据更有价值。3.4 评测集与种子问题RL 训练还需要一个稳定的评测集Evaluation Set用于衡量模型每一轮训练后表现是否提升。评测集可以从上述数据来源中预留一部分也可以专门构造。种子问题Seed Problems指的是构造覆盖不同能力的少量问题例如- 单文件函数实现 - 多文件重构 - 依赖升级后的 API 迁移 - 性能优化 - Bug 定位与修复每个种子问题都应该有明确的验证脚本。评测集不参与训练只用于评估避免模型在“背题”状态下虚高。3.5 数据规模怎么定很多同学会问“RL 的训练数据要多少条才够”这个问题没有标准答案取决于任务的复杂度和模型已有的能力。如果模型已经具备较强的代码能力只是需要学会“执行-反馈-修复”的机制那较小规模的优质数据例如几千条到几万条也能取得明显效果。反过来如果任务非常复杂例如多文件、多轮交互的仓库级任务则可能需要十几万条以上。我的建议是在开始训练前先把数据质量做扎实。宁可五千条高质量数据也不要五万条低质量、验证标准不统一的数据后者会让奖励信号混乱训练反而难收敛。4. 轨迹采集让模型在真实环境里“跑一遍”轨迹采集是整个 RL 训练中工程量最大的部分。Coding Agent 不像文本生成任务那样只需要输入输出它需要与代码执行环境交互。4.1 什么是轨迹Rollout从强化学习角度一条轨迹可以写作τ {s₀, a₀, r₀, s₁, a₁, r₁, ..., s_T, a_T, r_T}但在这个场景里我们更关心的是模型的“动作序列”。一条 Coding Agent 轨迹通常包含{ question: 用户需求, plan: 模型生成的修改计划, actions: [ {type: edit, file: src/util.py, code: ...}, {type: run, command: pytest tests/test_util.py, output: ...} ], final_result: 最终的代码提交或修改, test_result: {passed: 5, total: 6} }采集轨迹时不仅要保存最终代码还要保存中间步骤、工具调用输出、错误信息。这些数据后续可以用来分析模型行为也可以当成 SFT 的补充语料。4.2 沙箱执行环境的设计模型生成的代码必须在受控环境中执行这就是沙箱。沙箱设计的核心目标是隔离代码不能访问宿主机的敏感文件、网络、密钥。可复现依赖版本固定测试环境一致。可并行大量轨迹同时采集时沙箱能横向扩展。实践中常用的方案是容器化执行。每个任务在独立的容器里运行超时后强制清理。下面是一个简化版的沙箱执行示例# file: sandbox_executor.py import subprocess import tempfile import os class SandboxExecutor: def __init__(self, timeout30): self.timeout timeout def execute(self, code: str, test_code: str) - dict: with tempfile.TemporaryDirectory() as tmpdir: solution_path os.path.join(tmpdir, solution.py) test_path os.path.join(tmpdir, test_solution.py) with open(solution_path, w, encodingutf-8) as f: f.write(code) with open(test_path, w, encodingutf-8) as f: f.write(test_code) try: result subprocess.run( [python, test_path], capture_outputTrue, textTrue, timeoutself.timeout, cwdtmpdir, ) return { returncode: result.returncode, stdout: result.stdout[:2000], stderr: result.stderr[:2000], } except subprocess.TimeoutExpired: return {returncode: -1, stdout: , stderr: timeout}这只是一个最小示例生产环境还需要补充资源限制、网络隔离、依赖安装等功能。沙箱的稳定性直接影响训练效率——如果沙箱本身经常崩溃RL 训练会浪费大量时间在无效采样上。4.3 Plan 与 Code 分离的采样方式很多 Coding Agent 都采用“先规划、再编码”的策略。在 RL 训练中这种策略意味着每一条轨迹包含两个阶段阶段一模型根据任务描述生成 plan 阶段二模型根据 plan 生成具体代码两个阶段可以视为同一个策略在不同上下文条件下的采样也可以作为两个独立的动作空间来优化。从轨迹组织的角度可以这样记录{ question_id: task-001, messages: [ {role: user, content: 实现一个函数返回列表中所有偶数的和。} ], plan: 1. 遍历列表\n2. 判断元素是否为偶数\n3. 累加满足条件的元素, code: def sum_even(nums):\n return sum(x for x in nums if x % 2 0), exec_result: {returncode: 0, stdout: PASSED, stderr: } }这样做有一个好处当我们观察到模型反复在代码上出错时可以把错误归因到“计划不清晰”还是“代码实现有误”从而针对性地调整轨迹采样策略。4.4 多轮修复轨迹真实 Coding Agent 不是一次生成就完事它常常需要根据测试结果反复修改。这个过程会产生多轮轨迹初始生成 - 测试失败 - 读取报错 - 修改代码 - 再次测试 - 通过在 RL 训练中我们可以让模型执行多轮迭代直到达到最大轮数或测试通过。轨迹长度因此可能很长这会抬高训练成本。控制成本的办法有两个限制最大迭代轮数例如最多 3 轮超时没通过就直接结束。提前终止当测试已经严重偏离正确方向时立即结束本轮并记录奖励。多轮轨迹中的每一次“试错”都有学习价值。即使最终没有通过测试中间的错误信息也能帮助模型学会识别常见问题。但要注意过多的失败轨迹会拉低整体训练质量因此要控制采样时数据集中困难任务的比例。4.5 轨迹数据的存储与管理轨迹数据量会非常大。一条仓库级任务可能产生几十 KB 到几 MB 的中间输出一天的采样量很容易超过几十 GB。建议按下面的格式组织存储trajectories/ task_id/ rollout_001.json rollout_002.json每个 rollout 文件包含完整轨迹、执行结果和奖励。同时建立索引表记录任务 ID、模型版本、采样时间、是否通过测试等信息方便后续分析。不要小看数据管理这一步。RL 训练中经常要做“数据回放”——把之前的失败轨迹拿出来让模型重新学习或者分析哪些任务当前策略一直过不了。没有规范的管理这些工作会变得非常痛苦。5. 奖励函数的设计从规则到模型的打分体系奖励函数是整个 RL 训练中“最像艺术”的部分。它决定了模型优化方向如果设计不当模型会学会钻空子。5.1 规则奖励最可靠的底层信号规则奖励指根据确定的规则计算出的奖励例如编译是否通过、测试用例是否通过、代码执行时间是否在限制内。一个常见的组合是reward w1 * compile_ok w2 * test_pass_rate w3 * style_score其中test_pass_rate是最核心的信号。测试用例越全面奖励越能反映真实质量。规则奖励的优点是客观、稳定、可复现。缺点是粒度粗无法覆盖代码可读性、可维护性、设计优雅度等软性指标。5.2 模型奖励用大模型或 Reward Model 打分当任务没有明确的测试用例时可以引入模型奖励。常见做法是让一个强大的大模型作为裁判根据代码质量和任务匹配度打分或者训练一个独立的 Reward Model 来打分。一个简单的模型打分实现# file: model_reward.py def judge_by_llm(question: str, plan: str, code: str) - float: prompt f请根据任务描述评估下面的代码质量。 任务{question} 计划{plan} 代码 {code} 请从正确性、可读性、效率三个维度打分0-10 分 并给出一个综合分数。只输出综合分数。 response llm_completion(prompt) try: return float(response.strip()) except ValueError: return 0.0模型奖励灵活但不可靠存在几个问题大模型自身的偏好会引入偏差比如偏爱冗长答案。打分不稳定同一段代码反复打分可能结果不同。如果裁判模型太弱会被“看起来正确但实际上不行”的代码骗过。因此建议把模型奖励作为互补信号而不是唯一信号。5.3 偏好奖励从比较中学到的信号偏好奖励Preference Reward来自“哪个输出更好”的比较信号。比如用户对多个候选答案进行排序或者直接将用户的点赞、采纳行为转化为偏好。偏好信号可以直接用于 DPO 这类算法也可以训练一个 Reward Modelpair (output_a, output_b, preference) - 训练模型学会判断哪个输出更符合偏好 - 在 RL 中用这个模型作为奖励来源真实产品中最容易获取的就是用户点击、复制、采纳等隐式反馈。这类信号成本低、规模大但噪声也大。举个例子用户复制了一段代码不代表它正确可能只是恰好能跑起来。5.4 结果奖励 vs 过程奖励结果奖励只看最终代码是否通过测试通过给正奖励不通过给零分。过程奖励对中间步骤分别打分例如计划是否合理、每一步工具调用是否正确、是否避免了无效重试。结果奖励简单可靠但在长轨迹任务中会面临“奖励稀疏”问题——模型走完二十步才发现自己全错了中间每一步都得不到有用的反馈。过程奖励可以缓解这个问题但设计难度高因为很难给“中间步骤”设计出公正的自动化评分规则。一个折中方案是“混合奖励”最终结果用规则奖励中间步骤用轻量规则判断。比如计划阶段如果模型输出了清晰的步骤列表就给予少量奖励如果代码编译失败则根据错误类型降低奖励。5.5 奖励裁剪与归一化RL 训练中奖励尺度不一致会导致策略跳动剧烈。一个常见技巧是对奖励做裁剪和归一化。def normalize_reward(group_rewards): # group_rewards: 同一问题多个采样的奖励列表 import numpy as np arr np.array(group_rewards, dtypenp.float32) mean arr.mean() std arr.std() 1e-6 return (arr - mean) / std这种组内归一化的方式在 GRPOGroup Relative Policy Optimization类算法中非常常见。它让模型关注“同一问题下哪些采样相对更好”而不是比较不同难度任务的绝对分数。5.6 奖励函数的常见误区这里汇总几个我见到最多的错误误区说明测试用例太弱所有采样都能通过奖励失去区分度奖励全用模型打分模型偏好不稳定训练过程波动大忽略编译错误分类相同错误反复出现模型学不到根因奖励尺度跨任务不统一简单任务奖励高困难任务奖励低优化目标混乱没有写奖励日志训完一轮才发现奖励函数有 bug6. 从零搭建一个简化版 Coding Agent RL 训练流程下面用一个简化示例串联前面的概念。这里不追求训练出可用模型而是演示数据、轨迹、奖励是如何组成闭环的。实际环境建议使用 Python 3.10PyTorch 版本按你的项目兼容情况调整。6.1 项目结构coding_agent_rl_demo/ data/ train.jsonl sandbox/ executor.py reward/ rule_reward.py train/ grpo_train.py utils/ logger.py6.2 准备训练数据训练数据使用 JSONL 格式每条包含任务描述和测试用例{ question: 实现一个函数 sum_even(nums)返回列表中所有偶数的和。, test_cases: [ {input: [1, 2, 3, 4], expected: 6}, {input: [2, 4, 6], expected: 12}, {input: [], expected: 0} ] }注意真实的 Agent 任务还需要包含仓库上下文这里为了演示只保留单文件场景。6.3 轨迹采样脚本核心逻辑模型生成计划再生成代码代码在沙箱中执行记录结果。# file: train/rollout.py from sandbox.executor import SandboxExecutor from reward.rule_reward import compute_reward def sample_trajectory(model, tokenizer, item, max_rounds3): question item[question] executor SandboxExecutor(timeout10) rollout_data { question: question, plan: , actions: [], test_result: None, reward: 0.0 } for round_idx in range(max_rounds): plan model.generate(question, modeplan) code model.generate(question \n plan, modecode) test_code build_test_script(code, item[test_cases]) exec_result executor.execute(code, test_code) rollout_data[actions].append({ round: round_idx, plan: plan, code: code, exec_result: exec_result }) if exec_result[returncode] 0: break rollout_data[plan] rollout_data[actions][0][plan] rollout_data[test_result] exec_result rollout_data[reward] compute_reward(exec_result, len(item[test_cases])) return rollout_data这里的build_test_script负责把测试用例转换成 pytest 脚本model.generate是模型推理接口的简化写法。实操中建议把模型推理和沙箱执行拆成独立服务方便并发扩展。6.4 奖励计算继续实现规则奖励# file: reward/rule_reward.py def compute_reward(exec_result: dict, total_tests: int) - float: if exec_result[returncode] ! 0: return 0.0 stdout exec_result.get(stdout, ) # 解析 pytest 结果示例输出3 passed, 0 failed try: passed int(stdout.split( passed)[0].strip().split()[-1]) except (ValueError, IndexError): passed 0 passed min(passed, total_tests) return passed / total_tests这个实现比较粗糙但它满足了核心原则规则奖励必须能区分不同采样结果。真实项目里测试用例输出格式可能不同需要根据实际测试框架调整解析逻辑。6.5 策略优化GRPO 简化示意图当前 Coding Agent RL 训练中GRPO组相对策略优化是常用的方法。它不需要单独训练 Critic 模型而是用同一问题下的多个采样结果归一化后计算优势。下面是一个高度简化的训练循环示意图# file: train/grpo_train.py import torch def grpo_train_step(model, ref_model, batch, tokenizer, group_size4, clip_eps0.2): optimizer torch.optim.AdamW(model.parameters(), lr1e-6) for item in batch: # 1. 为同一个问题采样多个轨迹 trajectories [sample_trajectory(model, tokenizer, item) for _ in range(group_size)] rewards torch.tensor([t[reward] for t in trajectories]) # 2. 组内归一化计算优势 advantages rewards - rewards.mean() advantages advantages / (rewards.std() 1e-6) # 3. 计算当前策略和参考策略的 logprob 比例 # 这里需要将轨迹 token 化并重新计算 logprob伪代码如下 # logp_new model.logprob(trajectory_tokens) # logp_old ref_model.logprob(trajectory_tokens).detach() # ratio torch.exp(logp_new - logp_old) # # 4. 计算 PPO/GRPO 的 policy loss # loss -torch.min(ratio * advantages, # torch.clamp(ratio, 1-clip_eps, 1clip_eps) * advantages).mean() # # 5. 反向传播 # optimizer.zero_grad() # loss.backward() # optimizer.step() pass这个代码片段省略了真正的 token 和 logprob 计算原因是这部分依赖具体框架和模型 API。但流程是通用的采样、算奖励、归一化、算策略损失、更新参数。6.6 运行与验证训练过程中要关注几个关键指标- 平均奖励是否逐步提升 - 测试通过率是否上升 - 轨迹长度是否变得更短说明模型学会了减少无效尝试 - 规整的比例是否稳定建议每轮训练后在固定评测集上跑一次完整评估观察模型在未见任务上的表现防止训练集过拟合。7. 高频问题与排查思路下面整理 Coding Agent RL 训练中常见的问题以及对应的排查方向。问题现象常见原因解决思路训练初期奖励就很高但评测集效果差训练数据和评测集分布不一致或者测试用例太弱检查训练集种子任务增加测试用例强度使用更贴近真实场景的数据奖励一直不高模型不进步数据质量差任务太难或轨迹采样成本太低降低任务难度增加参考实现数据检查沙箱是否能稳定执行模型学会“刷奖励”奖励函数存在漏洞例如只检测输出格式不检测逻辑检查测试用例是否能区分随机猜测和正确答案增加规则约束轨迹太长训练成本爆炸最大迭代轮数设置过大或任务本身过难限制最大轮数给步骤数加惩罚项增加提前终止逻辑同一问题多次采样结果差异大采样温度过高或模型本身在该任务上能力不足降低采样温度对问题做难度筛选损失值波动大不收敛奖励未归一化或学习率过大使用组内归一化降低学习率减少 batch 内任务难度差异GRPO 中参考模型被更新反传时没有正确 stop-gradient检查参考模型参数是否冻结对比时使用 detach()排查时优先看两个东西奖励日志和轨迹样本。如果奖励日志显示某个任务的测试通过率长期为零先把这条数据拿出来人工检查确认测试用例本身正确、模型具备解决它的基础能力。8. 最佳实践与工程建议8.1 数据层面每条训练数据必须有稳定的自动验证方式不能只有“人工判断”。数据去重非常重要重复样本会导致模型过度拟合特定模式。定期从轨迹库中抽取困难样本补充进 SFT 数据形成良性循环。评测集和训练集的数据来源要隔离避免评估失真。8.2 轨迹采集层面沙箱环境要有资源限制包括 CPU、内存、磁盘、网络、超时时间。并发采样时需要设计好容错机制。单条轨迹失败不应该中断整个训练任务。轨迹数据要保留原始输出不要只存奖励值否则后续分析没有依据。建议为模型版本、采样参数温度、top-p、token 消耗打标签方便问题回溯。8.3 奖励函数层面优先用规则奖励测试用例通过率是最可靠的信号。如果任务没有测试用例谨慎使用模型奖励并定期人工抽查。奖励函数代码要写单元测试尤其是解析测试输出、计算奖励的部分。将奖励计算做成独立服务与训练采样解耦便于单独优化。8.4 训练稳定层面使用较低的初始学习率例如 1e-6 到 5e-6 区间。使用梯度裁剪防止单个困难样本导致梯度爆炸。每个 step 都记录奖励分布、优势分布、轨迹长度方便快速定位异常。定期保存 checkpoint并且记录每个 checkpoint 在评测集上的指标。9. 总结与下一步这篇文章从三个关键问题展开数据来源、轨迹采集、奖励函数。数据来源决定了 RL 训练的“上限”质量比数量重要。轨迹采集是工程量最大的部分需要稳定的沙箱和规范的存储。奖励函数是优化方向的引导器规则奖励是基础模型奖励是补充。最后用 GRPO 的简化示例把三者串联形成完整的训练闭环。如果你刚入门 Coding Agent RL建议从单文件、有明确测试用例的任务开始练手先把轨迹采集和规则奖励跑通再逐步过渡到多文件、仓库级任务。等整个闭环稳定运行之后再尝试引入模型奖励和过程奖励。下一步可以继续学习的方向包括PPO 和 GRPO 的数学推导、Reward Model 的训练细节、以及如何用 DPO 做偏好对齐。你也可以把本文的简化示例扩展到真实模型中从一个小规模评测集开始验证训练流程是否稳定。如果这篇文章对你有帮助可以收藏备用。后续遇到具体问题欢迎在评论区交流。