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

做 Coding Agent 相关的强化学习（RL）时，很多人第一周就卡住了。模型结构可以抄，训练框架可以用现成的，但真正到了准备数据、采集轨迹、定义奖励函数这三步，网上的资料要么只讲概念，要么直接甩一个论文地址，中间隔着大量工程细节。

这篇文章不打算从强化学习的数学原理开始推导，而是围绕大家问得最多的三个问题展开：训练数据从哪里来、模型执行轨迹怎么采、奖励函数到底怎么定。内容会覆盖 Coding Agent RL 的基础概念、数据与轨迹的工程化处理方式、以及一套可以照着写的简化训练示例。无论你是刚接触 RL 的算法工程师，还是想给编码助手接入强化学习训练的开发同学，都可以沿着这篇文章的思路落地。

1. 背景：Coding Agent 和 RL 为什么绑在一起

1.1 Coding Agent 和普通大模型的区别

普通的大语言模型，输入是一段文本，输出是一段文本，它只负责“生成”。而 Coding Agent 要解决的是更完整的任务：理解用户需求、读取仓库代码、制定修改计划、生成多个文件、运行测试、根据错误信息迭代修复。整个过程是一个带状态的多步决策过程。

举一个最简单的例子：

用户提问：帮我给项目里所有 Python 文件加上类型注解。

普通模型可能只生成一段说明或者一个补丁片段，但 Coding Agent 需要：

1. 扫描项目中的 Python 文件列表。
2. 理解每个文件的函数签名。
3. 规划哪些文件需要改动。
4. 逐个生成修改后的代码。
5. 运行静态检查或单元测试验证结果。
6. 根据报错继续修复。

这个流程天然具备“状态-动作-反馈”的闭环结构，正好是强化学习擅长处理的场景。模型每一步的“动作”会影响后续状态，最终结果可以通过测试是否通过来获得反馈。

这也是为什么近两年 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 训练中把“任务好坏的判断标准”翻译成数值信号的关键模块。

对于代码生成任务，最直接的奖励来自执行结果：

后面的章节会详细比较这几种奖励的适用场景。

3. 数据来源详解：Coding Agent RL 的数据从哪来

数据是 RL 训练的根基。没有高质量的问题和验证标准，模型再强的策略也是“对着空气优化”。下面按来源分类讲解。

3.1 公开代码数据集

最容易想到的数据来源是公开的代码数据集。GitHub 上有大量开源仓库，包含真实世界的代码问题和对应的解决方式。常见做法包括：

• 从开源仓库的 Issue 和 PR 中提取任务描述和代码变更，形成“问题-补丁”对。
• 使用代码竞赛平台的题目和评测用例。
• 使用专门为代码模型构建的训练集，例如包含自然语言指令和对应代码的数据。

这类数据的优点是规模大、成本低，缺点是噪声较高。很多 Repository 代码更新频繁，任务描述和实际代码可能不对应，直接拿来训练容易让模型学到错误映射。

使用公开数据时，建议做一次系统性的清洗：

1. 过滤掉包含敏感信息或私有密钥的仓库。 2. 过滤掉过于简单、无法形成有效训练的样本。 3. 过滤掉重复度高的代码片段。 4. 对测试用例进行人工抽查，确保验证方式有效。

3.2 合成数据与代码生成

当公开数据不够用，或者需要覆盖特定能力时，可以用合成数据。合成数据的生产方式很多，比较实用的有三种：

• 代码解释生成：选一段高质量代码，用大模型生成对应的任务描述，要求模型“根据这段代码写一个用户会提出的需求”。
• 任务反向生成：给定功能描述，让大模型补全测试用例和边界条件，形成带验证的数据。
• 数据增强：修改已有问题的表达方式、参数类型、输入规模，生成变体样本。

合成数据的意义在于“按需制造”训练样本。比如当前模型在多仓库修改场景上能力偏弱，就可以专门构造一批涉及多个文件改动的任务。

不过合成数据也有风险。很多情况下生成的任务描述和代码并不完全匹配，测试用例也不稳定，模型可能学到“看起来合理但实际无法执行”的路径。因此，所有合成数据必须经过执行验证，确认测试用例能通过参考实现后再进入训练。

3.3 用户真实场景数据

如果 Coding Agent 已经上线，用户真实请求是最宝贵的数据来源。真实数据天然贴近使用场景，包含真实代码库、真实需求和真实边界情况。

采集用户真实数据时，要注意三点：

1. 隐私与合规：涉及用户代码的任务必须脱敏，移除密钥、个人身份信息、内部路径。
2. 质量标准化：用户请求风格差异很大，需要统一成标准格式，并补充测试用例。
3. 偏好标注：如果用户对某个回答点了赞，可以作为偏好信号；如果用户关闭了会话，也要考虑是否作为负样本。

对于还没有用户量的团队，可以考虑用内部业务需求构造一批“内部真实数据”。这类数据虽然数量不大，但和线上场景最接近，往往比大规模公开数据更有价值。

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, timeout=30): 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", encoding="utf-8") as f: f.write(code) with open(test_path, "w", encoding="utf-8") as f: f.write(test_code) try: result = subprocess.run( ["python", test_path], capture_output=True, text=True, timeout=self.timeout, cwd=tmpdir, ) 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 Model：

pair (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, dtype=np.float32) mean = arr.mean() std = arr.std() + 1e-6 return (arr - mean) / std

这种组内归一化的方式，在 GRPO（Group Relative Policy Optimization）类算法中非常常见。它让模型关注“同一问题下哪些采样相对更好”，而不是比较不同难度任务的绝对分数。

5.6 奖励函数的常见误区

这里汇总几个我见到最多的错误：

6. 从零搭建一个简化版 Coding Agent RL 训练流程

下面用一个简化示例串联前面的概念。这里不追求训练出可用模型，而是演示数据、轨迹、奖励是如何组成闭环的。实际环境建议使用 Python 3.10+，PyTorch 版本按你的项目兼容情况调整。

6.1 项目结构

coding_agent_rl_demo/ data/ train.jsonl sandbox/ executor.py reward/ rule_reward.py train/ grpo_train.py utils/ logger.py

6.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_rounds=3): question = item["question"] executor = SandboxExecutor(timeout=10) rollout_data = { "question": question, "plan": "", "actions": [], "test_result": None, "reward": 0.0 } for round_idx in range(max_rounds): plan = model.generate(question, mode="plan") code = model.generate(question + "\n" + plan, mode="code") 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_size=4, clip_eps=0.2): optimizer = torch.optim.AdamW(model.parameters(), lr=1e-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, 1+clip_eps) * advantages).mean() # # 5. 反向传播 # optimizer.zero_grad() # loss.backward() # optimizer.step() pass

这个代码片段省略了真正的 token 和 logprob 计算，原因是这部分依赖具体框架和模型 API。但流程是通用的：采样、算奖励、归一化、算策略损失、更新参数。

6.6 运行与验证

训练过程中要关注几个关键指标：

- 平均奖励是否逐步提升 - 测试通过率是否上升 - 轨迹长度是否变得更短（说明模型学会了减少无效尝试） - 规整的比例是否稳定

建议每轮训练后，在固定评测集上跑一次完整评估，观察模型在未见任务上的表现，防止训练集过拟合。

7. 高频问题与排查思路

下面整理 Coding Agent RL 训练中常见的问题，以及对应的排查方向。

排查时，优先看两个东西：奖励日志和轨迹样本。如果奖励日志显示某个任务的测试通过率长期为零，先把这条数据拿出来人工检查，确认测试用例本身正确、模型具备解决它的基础能力。

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 做偏好对齐。你也可以把本文的简化示例扩展到真实模型中，从一个小规模评测集开始，验证训练流程是否稳定。

如果这篇文章对你有帮助，可以收藏备用。后续遇到具体问题，欢迎在评论区交流。