最近在翻一些模型技术报告时我注意到一句话“The big improvement is on coding and especially long-horizon tasks. Explicitly trained on it actually...”这句话虽然是从英文报告里摘出来的但恰好点中了当前大模型落地最核心的痛点代码生成容易长时程任务处理难。很多读者可能在 GitHub 上见过某些 Agent 项目“翻车”现场简单 Issue 能修稍微给一个跨多文件、多轮验证的需求模型就开始“拆东墙补西墙”改了一个文件忘了另一个文件最后测试直接崩盘。这是模型能力不行吗不完全是更多是训练目标和推理范式没有为 long-horizon tasks 做好准备。本文我想从“长时程任务训练”的角度把这个问题拆开讲清楚。内容会覆盖什么是 long-horizon coding tasks它和普通代码补全有什么区别为什么“显式训练”对这类任务至关重要训练数据、奖励模型、评估体系应该怎么设计当前工具链vibe coding、coding plan、Agent SDK里哪些做法在解决这个问题落地时常见的坑和工程建议。这篇文章适合正在做大模型应用开发、Agent 框架设计、AI 编码工具评估的开发者也适合想理解“为什么 AI 写简单代码很强、做复杂重构就变笨”的读者。1. 背景与核心概念1.1 什么是 long-horizon coding tasksLong-horizon tasks 翻译过来是“长时程任务”或“长视界任务”。在编码场景下它指的是需要跨越多个文件、多个步骤、多次验证才能完成的任务。举个例子简单任务写一个add(a, b)函数。中等任务给项目添加一个/api/user接口。Long-horizon 任务重构整个用户模块把原来的 Session 鉴权改为 JWT同时兼容旧接口更新数据库迁移脚本、前端调用、单元测试、CI 配置还要保证重构过程中其他模块不受影响。第三种任务有几个显著特征上下文跨度大。模型需要同时理解十几个文件的关联关系。步骤依赖强。第 5 步的决策往往取决于第 2 步的输出一步错步步错。验证延迟高。模型写完代码后需要跑测试、看报错、修改还要回归验证整个反馈周期比“写完一个函数立刻见输出”长得多。探索空间巨大。从一个 Bug 到根因之间有上千条路径模型需要学会放弃无效路径。这就引出了一个关键结论long-horizon coding tasks 的本质不是“生成代码”而是“在复杂状态空间里做决策”。1.2 Long-horizon 与代码补全、代码生成的边界传统代码补全如 Copilot 早期版本解决的是“下一个 token 是什么”的问题。技术上可以理解为输入上文代码 输出下一个最可能的 token / 一段代码而 long-horizon coding 解决的是“下一步动作是什么”的问题输入仓库状态 任务描述 已执行步骤 观察结果 输出下一个动作读取文件 / 修改文件 / 运行测试 / 查询日志 / 提交代码两者之间的差别不亚于“打字”和“写文章”的差别。前者是局部建模后者是全局规划加执行。很多开源 Agent 项目表现不稳根源就在这里底层模型可能本身具备代码生成能力但它没有经过 long-horizon 任务的数据训练一到“多步骤执行 结果反思 状态更新”的循环里就成了短板。1.3 为什么“显式训练”是关键词回到标题那句英文我理解它强调的点是“专门在长时程任务上显式训练过”是很关键的改进来源。所谓“显式训练”不是指在混合语料里多塞一些代码文件而是指在训练阶段直接构造“多步骤任务轨迹trajectory”数据让模型看到的不只是“代码上下文 - 代码输出”而是任务描述 (User Request) - 第一步推理 动作 (Thought Action) - 执行结果 (Observation) - 第二步推理 动作 - ... - 最终答案用这种轨迹数据训练出来的模型才能学会两件事任务分解把大任务拆成可执行的小步骤。从错误中恢复执行结果和预期不符时能调整策略。思维链Chain-of-Thought本质上也属于一种显式训练通过让模型输出中间推理步骤提升复杂问题的正确率。只不过 long-horizon coding 的中间步骤不止是“想想”还包括“调用工具、观察结果、修改状态”。1.4 当前业界对 Long-horizon Coding 的重视如果你关注过 AI 编码领域的动态会发现最近很多工具都在强调“plan”这个概念。比如搜索热词里出现的 coding plan、GLM coding plan、vibe coding 等本质上都是围绕“先规划、后执行”的思路在演进。Vibe coding强调开发者用自然语言描述意图由 AI 完成大部分编码工作。它降低了 coding 门槛但也因为缺少长期规划会在复杂项目里放大错误。Coding plan强调在动手写代码之前先让模型生成一份实施计划涉及哪些文件、依赖关系、变更顺序再按照计划逐步执行。Spec-driven developmentSDD把开发流程往前再推一步要求先写清晰的需求规格再基于规格生成计划和代码最后逐条验证。这些热词背后其实都在解决同一个问题不要让大模型在整棵代码库里“裸奔”要给它一个结构化的执行框架。而 long-horizon tasks 的训练目标正好为这种结构化执行提供了模型能力底座。2. 为什么 Long-horizon 是当前 AI Coding 的核心瓶颈2.1 模型“只见树木不见森林”的原因大模型在做长任务时拉胯很多人会归咎于“上下文窗口不够”。确实上下文长度是一个物理限制。但即使上下文窗口扩展到 1M token模型依然可能做不好长任务。原因在于长任务的难点不只是“记不住”而是“不会组织”。普通代码生成可以类比为“回答一道填空题”模型只需要根据上下文生成符合语法和逻辑的文本long-horizon 任务则是“完成一个包含 20 个子任务的工程项目”模型需要学会设定优先级判断哪些信息值得保留在上下文里哪些可以丢弃在多个选择路径中做取舍根据测试反馈修正此前决策。这些能力无法只靠“上下文更长”获得必须靠训练阶段的目标设计和数据设计来获得。2.2 传统训练目标与 long-horizon 的冲突传统监督微调SFT的训练目标通常是最小化交叉熵损失即让模型生成的 token 序列逼近“标准答案”。但对于 long-horizon coding tasks我们很难得到一个唯一“标准答案”因为工程实现方式有很多种中间步骤并没有唯一正确的动作序列有些动作需要探索和试错一条固定的“标准轨迹”反而无法教会模型如何应对失败。因此业界逐渐引入强化学习 / RL如 PPO、GRPO来优化这类任务。它的逻辑是不强制模型走某一条路而是告诉模型“最终结果对了就有奖励”让模型自己学会如何探索、如何规划、如何纠错。2.3 验证成本是训练和推理的隐藏难题在 long-horizon coding 任务中奖励信号非常稀疏。你可能需要让模型先产生一整段动作序列最后跑一次测试才能知道这段序列是否正确。问题在于如果测试不通过到底错在第几步需要逐段定位。如果只有“对/错”二值奖励模型很难学到中间步骤的正确技能。如果每次试错都要真实地在沙箱环境里运行代码训练成本会迅速上升。这就催生了奖励模型、过程奖励Process Reward ModelPRM、代码执行沙箱等配套技术。对普通开发者来说了解这些概念不是为了复现训练而是为了在选择模型、设计 Agent 时知道什么方案靠谱、什么方案只是在“表面优化”。3. 长时程编码任务训练的技术拆解理解了问题背景下面我们来拆解“如何在训练和微调中提升 long-horizon coding 能力”。这一节对做模型训练的同学比较技术向应用开发者也建议读完因为你可以借此判断底层模型是否适合做 Agent 底座。3.1 数据层构造多步骤任务轨迹显式训练的第一步是准备 long-horizon 数据。所谓轨迹数据在代码任务里通常长这样{ task: 重构用户模块的鉴权方式从 Session 改为 JWT并保持旧接口 /api/user/info 兼容, repo: example-user-service, steps: [ { thought: 先了解现有鉴权过滤器在哪查找 javax 相关文件。, action: grep -r \HttpSession\ src/main/java, observation: src/main/java/com/example/AuthFilter.java:42 ... }, { thought: 创建 JWT 工具类并在 AuthFilter 中替换 Session 读取逻辑。, action: edit src/main/java/com/example/AuthFilter.java, observation: file updated }, { thought: 更新测试用例新增 JWT 场景。, action: edit src/test/java/com/example/AuthFilterTest.java, observation: file updated }, { thought: 运行测试确认没有破坏旧逻辑。, action: mvn test -DtestAuthFilterTest, observation: Tests run: 15, Failures: 0, Errors: 0 } ], final_answer: ... }这类数据有几种常见获取方式从真实 GitHub Issue PR 关联数据中爬取Issue 是任务PR 是代码变更测试结果是验证信号在沙箱环境里运行模型/Agent 生成轨迹再人工或自动筛选正确轨迹用规则或小模型启发式生成多步操作序列再用任务成功率筛选。在构建数据时需要重点覆盖两类“课程难度”单文件多函数修改训练模型跨函数、跨类协调多文件横向改动训练模型理解文件间依赖关系。3.2 训练策略SFT RL 两阶段这里给一个常见的训练流程适用于在已有的基础代码模型上继续增强 long-horizon 能力。阶段一SFT on Trajectories在这个阶段直接用构造好的轨迹数据做监督微调。输入 [用户任务描述] [仓库检索结果 / 相关文件内容] [已执行的动作及观测结果] [历史步骤摘要] 输出 下一个动作 或 最终答案训练时需要注意的点不要只训练“最终答案”要让模型见过大量中间步骤否则运行时它会跳过必要动作直接改代码导致测试失败。要均衡“成功轨迹”和“失败轨迹”。如果全是成功轨迹模型遇到意外情况时缺少恢复能力。建议混入大约 20%-30% 的失败轨迹并把“失败后如何修正”也作为监督信号。上下文长度要足够容纳“任务描述 仓库信息 已执行步骤”。建议训练时动态截断和摘要提高模型对长上下文的耐受力。SFT 阶段的代码实现通常基于 transformers 库下面是一个伪代码示例展示数据预处理逻辑# 文件路径train_sft.py from transformers import AutoTokenizer, AutoModelForCausalLM from datasets import load_dataset model_name your-base-code-model tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) dataset load_dataset(json, data_filestrajectory_data.jsonl) def format_input(example): # 将任务、上下文、历史步骤拼接成对话格式 messages [{role: system, content: You are an AI coding agent.}] messages.append({role: user, content: example[task_prompt]}) for step in example[steps]: messages.append({role: assistant, content: step[thought] \n step[action]}) messages.append({role: user, content: Observation:\n step[observation]}) messages.append({role: assistant, content: example[final_answer]}) # 这里省略 tokenizer.apply_chat_template 细节按具体模型模板处理 return tokenizer.apply_chat_template(messages, tokenizeFalse) tokenized_dataset dataset.map(lambda x: {text: format_input(x)}) # 之后交给 Trainer 做标准 SFT 即可阶段二RLHF / RLVR 强化结果验证如果说 SFT 让模型“见过”长任务怎么走那 RL 阶段就是让模型“练会”长任务怎么做。在编码场景中最实用的强化训练方式叫RLVRReinforcement Learning from Verifiable Rewards基于可验证奖励的强化学习。它的思路很简单跑测试通过了就给正奖励不通过给负奖励。伪代码如下# 文件路径rlvr_train.py def reward_fn(prediction, test_suite, repo_path): 在沙箱环境运行测试根据结果返回奖励。 apply_patch(repo_path, prediction[patch]) result run_test_suite(repo_path, test_suite) if result.failed 0: return 1.0 elif result.errored 0 and result.failed 5: return 0.3 else: return -1.0这里有几个实战经验奖励函数要分层。全对给满分部分测试通过给部分分完全跑不起来给负分。稀疏的二值奖励会让训练极其不稳定。使用过程奖励Process Reward Model。如果训练资源允许可以训练一个 PRM对每个中间步骤打分帮助模型定位“从哪一步开始跑偏”。上下文压缩策略很重要。长任务轨跡非常长训练时要用摘要机制动态压缩旧步骤否则 GPU 显存扛不住。3.3 评估层建立长时程基准训练完之后不能只靠“读代码像不像”来判断模型好坏。推荐从三个维度评估 long-horizon coding 能力评估维度考察内容例子任务完成率最终是否通过测试、满足需求修复一个跨文件 Bug要求所有单测通过过程效率是否用了最少步骤完成应当只修改 2 个文件模型却改了 6 个错误恢复能力中间步骤失败后能否纠正第一步 grep 结果不对模型能否换一种检索方式目前开源社区已经有类似 SWE-bench 的基准它收集真实 GitHub Issue 和对应 PR用测试用例自动验证模型生成的 patch。如果你在做模型对比强烈建议用这种“Issue - Patch - Test”的闭环基准而不是只给一个函数让模型补全。4. 实战在现有模型上增强 Long-horizon Coding 能力很多团队没有从零预训练模型的条件但可以在开源模型基础上做微调或直接构建 Agent 应用。本节梳理两条路径模型微调路径和应用工程路径。4.1 路径 A基于开源模型的 SFT RL 微调适合有 GPU 资源、希望打造垂直领域模型的团队。核心步骤4.1.1 准备轨迹数据数据格式可以保持 3.1 中的 JSONL 结构。建议字段{ repo: 项目名, task_id: issue-123, task_description: 问题描述, related_files: [src/A.java, src/B.java], trajectory: [ {type: action, content: read src/A.java}, {type: observation, content: ...}, {type: action, content: edit src/B.java} ], final_patch: diff 内容, test_result: passed }4.1.2 数据清洗真正工程质量在于数据清洗。注意点过滤掉测试服务不稳定的样本避免噪声标签根据 final_patch 是否通过测试筛选成功轨迹对失败轨迹打上“失败原因”标签如“缺少依赖文件”“修改了错误模块”去重同一个 Issue 的轨迹不要保留 100 条近似内容容易导致过拟合。4.1.3 微调资源配置参考这里不写死具体框架版本因为变化很快。只给方案方向基座模型建议 7B 到 32B 规模之间兼顾效果和显存使用 DeepSpeed ZeRO-3 或 FSDP 解决多卡显存LoRA/QLoRA 可以先跑通流程最终训练追求上限就做全参数微调训练分为“短轨迹”和“长轨迹”两个阶段先训短任务再逐步加长类似课程学习。4.2 路径 B不训练模型通过 Agent 框架补足 Long-horizon 能力如果团队没有微调预算仍然可以显著提升模型在长任务上的表现。核心思路是在 Agent 框架里做“显式规划、显式记忆、显式验证”。4.2.1 显式计划Plan-then-Execute不要让模型直接输出 patch而是先输出结构化计划。# 文件路径agent/planner.py SYSTEM_PROMPT 你是一名资深工程师。在修改代码之前必须先输出一份修改计划。 输出格式为 JSON { goal: 本次任务的最终目标, steps: [ {order: 1, action: locate, target: 鉴权过滤器所在文件}, {order: 2, action: read, target: src/main/java/AuthFilter.java}, {order: 3, action: modify, target: AuthFilter.java, detail: 把 Session 读取改为 JWT 解析} ], risks: [旧接口可能受影响需要回归测试] } 计划本身就是在要求模型显式利用训练时学到的任务分解能力同时给执行者一个稳定的锚点避免走着走着忘掉全局目标。4.2.2 状态跟踪与摘要Long-horizon 任务执行过程中上下文会越来越长。一个工程技巧是维护“任务状态摘要”每执行若干步就更新一次摘要而不要把原始日志全部塞进上下文。# 文件路径agent/state.py class TaskState: def __init__(self, goal): self.goal goal self.completed_steps [] self.current_file_refs [] self.known_issues [] def summarize(self, max_len1200): summary f目标{self.goal}\n summary 已完成步骤\n- \n- .join(self.completed_steps[-10:]) summary \n当前相关文件\n- \n- .join(self.current_file_refs) summary \n已知问题\n- \n- .join(self.known_issues[-5:]) # 超出 max_len 时需要截断或调用摘要模型 return summary[-max_len:]这种摘要机制能显著延长 Agent 的有效工作步数也是 long-horizon 任务工程落地的关键。4.2.3 验证回路Test-in-the-LoopAgent 做完一步修改后不要急着做下一步。先运行相关测试根据测试反馈决定继续还是回溯。# 文件路径agent/verifier.py from subprocess import run, PIPE def verify(project_dir, test_command): result run(test_command, shellTrue, cwdproject_dir, capture_outputTrue, textTrue) if result.returncode 0: return {passed: True, output: result.stdout[-1000:]} else: return { passed: False, output: result.stdout[-1000:], error: result.stderr[-1000:] }在 Agent 主循环中只有passedTrue时才前进到下一步否则触发“错误分析动作”。4.3 完整 Demo一个最小 Long-horizon Agent下面给出一个极简原型演示“计划 - 执行 - 验证”的循环。这个示例不依赖特定 API核心是说明结构。# 文件路径simple_long_horizon_agent.py import os from agent.planner import generate_plan from agent.state import TaskState from agent.verifier import verify class SimpleCodingAgent: def __init__(self, repo_path, llm_generate_func): self.repo_path repo_path self.llm_generate_func llm_generate_func self.state None def run(self, issue_description): # 1. 规划 plan self.llm_generate_func( 请为以下问题生成分步修改计划。\n f问题{issue_description}\n f仓库路径{self.repo_path} ) print( 计划 ) print(plan) # 2. 初始化状态 self.state TaskState(goalissue_description) # 3. 执行循环 tasks extract_steps_from_plan(plan) for step in tasks: thought self.llm_generate_func( 当前步骤 step \n 状态摘要 self.state.summarize() \n 请输出下一步具体 shell 命令或代码修改内容。 ) print( 动作 ) print(thought) if thought.strip().startswith(run:): cmd thought.split(run:, 1)[1].strip() result run_command(cmd, self.repo_path) print( 观察 ) print(result) self.state.completed_steps.append(cmd) elif thought.strip().startswith(edit:): # 简化处理直接把修改内容写入文件 file_path, content parse_edit_command(thought) apply_file_change(file_path, content) print(f已修改 {file_path}) self.state.completed_steps.append(fedit:{file_path}) # 4. 验证每三步验证一次测试 if len(self.state.completed_steps) % 3 0: test_result verify(self.repo_path, python -m pytest tests -x) if test_result[passed]: print(测试通过继续执行。) else: print(测试失败进入错误分析模式。) analysis self.llm_generate_func( 测试失败错误信息\n f{test_result[error]}\n 请分析原因并给出修复建议。 ) print(analysis) print( 最终状态 ) print(self.state.summarize()) def run_command(cmd, cwd): import subprocess result subprocess.run(cmd, shellTrue, cwdcwd, capture_outputTrue, textTrue) return result.stdout result.stderr def extract_steps_from_plan(plan): # 简化解析假设 plan 中的每一行是一个步骤 return [line for line in plan.splitlines() if line.strip()] def parse_edit_command(thought_line): # 简化解析从 edit: 文件路径\n内容 中解析 raw thought_line.split(edit:, 1)[1].strip() file_path, content raw.split(\n, 1) return file_path, content def apply_file_change(file_path, content): with open(file_path, w, encodingutf-8) as f: f.write(content) # 使用示例 if __name__ __main__: def fake_llm(prompt): # 这里接入真实模型 API return run: git status agent SimpleCodingAgent(repo_path./my_project, llm_generate_funcfake_llm) agent.run(修复登录模块无法返回用户信息的问题)实际接入时把fake_llm替换成 OpenAI、Anthropic、GLM 或其他模型的调用即可。这个例子虽然简单但已经包含 long-horizon 的三个核心模块计划生成状态摘要与记忆测试验证回路。5. 当前工具链与热词盘点最近看到了很多高频词汇比如 vibe coding、coding plan、spec-driven development。这些热词容易让人混淆这里做一个简单辨析。5.1 Vibe CodingVibe Coding 的核心思想是“跟着感觉走”用自然语言描述需求让 AI 实时生成代码。它适合快速原型验证、前端页面调试、胶水代码生成。但它不要求任务有多长、多复杂所以并不天然解决 long-horizon 的问题。在大型项目里直接 vibe coding 很容易陷入“代码到处能跑、但没人知道哪段代码为什么存在”的混乱。5.2 Coding PlanCoding Plan 是在编码前让模型生成一个行动计划。它可以是修改哪些文件依赖什么接口实施顺序如何验证。这个做法本质上就是把 long-horizon task 转化为“一串短任务”降低每一步的复杂度让模型逐步执行、逐步反馈。5.3 GLM Coding PlanGLM Coding Plan 是智谱生态里推出的 Coding Plan 产品/体验方案从搜索词里能看到“GLM coding plan·7天体验卡”这类信息。它的价值在于把“大模型生成计划”做成了产品化流程。虽然不同产品的细节差异很大但在解决 long-horizon 任务这一目标上思路和社区里其他 plan 类工具是一致的先规划再动手避免模型在复杂任务中迷失方向。5.4 Spec-driven DevelopmentSDDSDD 比 coding plan 更进一步先把需求完整地写成规格例如用 markdown 写清楚用户故事、验收标准、设计方案然后再让 AI 基于规格生成实现计划、代码和测试。在这种模式下long-horizon 任务的“验证信号”来自于规格中的验收标准Agent 能更准确地判断“做完了没有”。5.5 从 Vibe Coding 到 Harness × SDD现在圈子里有句流行话叫“从 vibe coding 到 harness × SDD 全栈开发实战”。这里的 harness 可以理解为一套“约束和支架”类似于测试框架、类型检查、CI 流程、监控系统。SDD 则补充了“需求到代码的可追踪链路”。两者结合本质上就是给生成式编程套上一层“工程安全网”。如果你打算做 AI 编码工具或 Agent 平台这个方向值得关注。因为单靠模型自由度很难稳定交付复杂项目必须是“模型 工程脚手架”的组合。6. 常见问题与排查思路6.1 为什么 Agent 总在一个文件里反复修改问题现象常见原因解决思路Agent 反复修改同一文件无法跳出局部方案上下文里丢失了全局目标在每次循环开始时注入任务目标摘要明明有更简单的方案Agent 却选择了复杂改动模型缺乏全局仓库结构感知在规划阶段一次性检索仓库文件树、模块说明修改后测试失败Agent 无法定位根因观察信息过载关键报错被淹没截断日志输出提炼最近几条错误信息给模型建议在 long-horizon 任务里把“目标”和“已完成的改动清单”放在 prompt 的显眼位置不要依赖模型记住。6.2 训练长任务轨迹时显存溢出怎么办这个问题在做 SFT 时最常见。策略按优先级排列缩短单条轨迹长度把长轨迹切成多个短会话每个会话内部自带摘要使用 LoRA/QLoRA 降低显存占用对历史步骤做摘要压缩上下文里只保留最近的 N 步完整内容采用序列打包sequence packing提高 batch 的训练效率。6.3 RL 训练时奖励一直不涨排查顺序检查环境沙箱是否稳定、测试是否无歧义。检查奖励密度是不是 99% 的样本都是负奖励模型根本没有有效梯度信号。检查初始策略如果基座模型本身完成率极低可以先做一轮 SFT再开始 RL。检查优势估计尝试候选采样数量 K 设大一点比如 8 或 16让模型有更多比较对象。6.4 模型计划写得很好执行就崩这就是典型的“规划能力”和“执行能力”分离问题。解决办法执行过程中允许模型每步结束后返回计划修正引入“计划变更申请”让模型明确说明为什么要偏离原计划在验证回路里增加“最小改动原则”约束禁止与任务无关的文件修改。7. 最佳实践与工程建议7.1 训练层面的最佳实践课程学习先训练 2-3 步的短任务再逐步扩展到 10 步以上的长任务。一步到位训练超长任务容易不收敛。混入失败样本建议最多 30%太少模型不会纠错太多模型过度保守。使用可验证奖励能用测试用例给出二进制成功信号的就不要让模型给自己打分。过程奖励优先于结果奖励结果奖励太稀疏最好结合 PRM。7.2 应用层面的最佳实践保持计划可见性无论用哪家模型的 Coding Plan都要把计划展示给用户让用户可以在计划阶段纠偏。限制动作类型不要给 Agent 完整的 shell 权限。最好提供read、edit、run_test、search四个原子动作减少不可控行为。记录决策日志为了让用户理解 Agent 为什么改某一行代码需要把“读到的信息”和“决策依据”记录下来。沙箱隔离运行 Agent 的代码执行环境必须隔离应用层不能允许 Agent 直接访问生产库。7.3 生产环境的注意事项在代码仓库上操作之前先确认是否具有维护者授权对生产环境变更建议先走 MR 评审。执行 Agent 修改前优先在临时分支操作不要直接推到主干。对数据库字段的改动必须同时附上迁移脚本并做回滚演练。涉及删除文件或重写大段逻辑时强制增加人工 review 门槛。日志要保留原始 prompt、Agent 的思考过程、执行命令、测试输出方便事后复盘。8. 总结与学习路线如果你想在 long-horizon coding 方向上继续深入我建议按下面的顺序学习。掌握基础理解 GPT/LLM 的生成原理熟悉 function calling 和 tool use 的接口设计。跑通 Agent 框架用现成框架搭一个最小 Agent先让它完成“读取仓库 - 修改代码 - 跑测试”的闭环。研究轨迹数据找一批真实 Issue手动构造轨迹数据理解“好数据”长什么样。动手微调用 LoRA 在开源模型上做 SFT数据规模可以先从 5000 条开始观察模型行为变化。接触强化学习跑通 RLVR 流程重点理解奖励函数对训练稳定性的影响。参与评估基准使用 SWE-bench 这类基准持续跟踪模型在 long-horizon 任务上的真实表现。在实践过程中最容易忽略的一个风险是把模型在短任务上的表现误判为它在长任务上的能力。短任务正确率提升很快但长任务一旦进入第 10 步错误累积往往是指数级的。不要把评测集只做成“短问题集”一定要覆盖多步骤、多文件、带验证回路的任务。最后想说的是long-horizon coding 的训练和应用本质上都在做同一件事把“生成代码”这件事改造成“逐步完成任务”这件事。任何方案无论是 coding plan、SDD、RLVR 还是 Agent 状态机都在朝这个方向努力。如果你正在做相关应用可以先把计划、记忆、验证这三个模块搭起来再逐步通过数据或提示词优化细节。 长时程编码任务：从显式训练到工程落地的完整指南
最近在翻一些模型技术报告时我注意到一句话“The big improvement is on coding and especially long-horizon tasks. Explicitly trained on it actually...”这句话虽然是从英文报告里摘出来的但恰好点中了当前大模型落地最核心的痛点代码生成容易长时程任务处理难。很多读者可能在 GitHub 上见过某些 Agent 项目“翻车”现场简单 Issue 能修稍微给一个跨多文件、多轮验证的需求模型就开始“拆东墙补西墙”改了一个文件忘了另一个文件最后测试直接崩盘。这是模型能力不行吗不完全是更多是训练目标和推理范式没有为 long-horizon tasks 做好准备。本文我想从“长时程任务训练”的角度把这个问题拆开讲清楚。内容会覆盖什么是 long-horizon coding tasks它和普通代码补全有什么区别为什么“显式训练”对这类任务至关重要训练数据、奖励模型、评估体系应该怎么设计当前工具链vibe coding、coding plan、Agent SDK里哪些做法在解决这个问题落地时常见的坑和工程建议。这篇文章适合正在做大模型应用开发、Agent 框架设计、AI 编码工具评估的开发者也适合想理解“为什么 AI 写简单代码很强、做复杂重构就变笨”的读者。1. 背景与核心概念1.1 什么是 long-horizon coding tasksLong-horizon tasks 翻译过来是“长时程任务”或“长视界任务”。在编码场景下它指的是需要跨越多个文件、多个步骤、多次验证才能完成的任务。举个例子简单任务写一个add(a, b)函数。中等任务给项目添加一个/api/user接口。Long-horizon 任务重构整个用户模块把原来的 Session 鉴权改为 JWT同时兼容旧接口更新数据库迁移脚本、前端调用、单元测试、CI 配置还要保证重构过程中其他模块不受影响。第三种任务有几个显著特征上下文跨度大。模型需要同时理解十几个文件的关联关系。步骤依赖强。第 5 步的决策往往取决于第 2 步的输出一步错步步错。验证延迟高。模型写完代码后需要跑测试、看报错、修改还要回归验证整个反馈周期比“写完一个函数立刻见输出”长得多。探索空间巨大。从一个 Bug 到根因之间有上千条路径模型需要学会放弃无效路径。这就引出了一个关键结论long-horizon coding tasks 的本质不是“生成代码”而是“在复杂状态空间里做决策”。1.2 Long-horizon 与代码补全、代码生成的边界传统代码补全如 Copilot 早期版本解决的是“下一个 token 是什么”的问题。技术上可以理解为输入上文代码 输出下一个最可能的 token / 一段代码而 long-horizon coding 解决的是“下一步动作是什么”的问题输入仓库状态 任务描述 已执行步骤 观察结果 输出下一个动作读取文件 / 修改文件 / 运行测试 / 查询日志 / 提交代码两者之间的差别不亚于“打字”和“写文章”的差别。前者是局部建模后者是全局规划加执行。很多开源 Agent 项目表现不稳根源就在这里底层模型可能本身具备代码生成能力但它没有经过 long-horizon 任务的数据训练一到“多步骤执行 结果反思 状态更新”的循环里就成了短板。1.3 为什么“显式训练”是关键词回到标题那句英文我理解它强调的点是“专门在长时程任务上显式训练过”是很关键的改进来源。所谓“显式训练”不是指在混合语料里多塞一些代码文件而是指在训练阶段直接构造“多步骤任务轨迹trajectory”数据让模型看到的不只是“代码上下文 - 代码输出”而是任务描述 (User Request) - 第一步推理 动作 (Thought Action) - 执行结果 (Observation) - 第二步推理 动作 - ... - 最终答案用这种轨迹数据训练出来的模型才能学会两件事任务分解把大任务拆成可执行的小步骤。从错误中恢复执行结果和预期不符时能调整策略。思维链Chain-of-Thought本质上也属于一种显式训练通过让模型输出中间推理步骤提升复杂问题的正确率。只不过 long-horizon coding 的中间步骤不止是“想想”还包括“调用工具、观察结果、修改状态”。1.4 当前业界对 Long-horizon Coding 的重视如果你关注过 AI 编码领域的动态会发现最近很多工具都在强调“plan”这个概念。比如搜索热词里出现的 coding plan、GLM coding plan、vibe coding 等本质上都是围绕“先规划、后执行”的思路在演进。Vibe coding强调开发者用自然语言描述意图由 AI 完成大部分编码工作。它降低了 coding 门槛但也因为缺少长期规划会在复杂项目里放大错误。Coding plan强调在动手写代码之前先让模型生成一份实施计划涉及哪些文件、依赖关系、变更顺序再按照计划逐步执行。Spec-driven developmentSDD把开发流程往前再推一步要求先写清晰的需求规格再基于规格生成计划和代码最后逐条验证。这些热词背后其实都在解决同一个问题不要让大模型在整棵代码库里“裸奔”要给它一个结构化的执行框架。而 long-horizon tasks 的训练目标正好为这种结构化执行提供了模型能力底座。2. 为什么 Long-horizon 是当前 AI Coding 的核心瓶颈2.1 模型“只见树木不见森林”的原因大模型在做长任务时拉胯很多人会归咎于“上下文窗口不够”。确实上下文长度是一个物理限制。但即使上下文窗口扩展到 1M token模型依然可能做不好长任务。原因在于长任务的难点不只是“记不住”而是“不会组织”。普通代码生成可以类比为“回答一道填空题”模型只需要根据上下文生成符合语法和逻辑的文本long-horizon 任务则是“完成一个包含 20 个子任务的工程项目”模型需要学会设定优先级判断哪些信息值得保留在上下文里哪些可以丢弃在多个选择路径中做取舍根据测试反馈修正此前决策。这些能力无法只靠“上下文更长”获得必须靠训练阶段的目标设计和数据设计来获得。2.2 传统训练目标与 long-horizon 的冲突传统监督微调SFT的训练目标通常是最小化交叉熵损失即让模型生成的 token 序列逼近“标准答案”。但对于 long-horizon coding tasks我们很难得到一个唯一“标准答案”因为工程实现方式有很多种中间步骤并没有唯一正确的动作序列有些动作需要探索和试错一条固定的“标准轨迹”反而无法教会模型如何应对失败。因此业界逐渐引入强化学习 / RL如 PPO、GRPO来优化这类任务。它的逻辑是不强制模型走某一条路而是告诉模型“最终结果对了就有奖励”让模型自己学会如何探索、如何规划、如何纠错。2.3 验证成本是训练和推理的隐藏难题在 long-horizon coding 任务中奖励信号非常稀疏。你可能需要让模型先产生一整段动作序列最后跑一次测试才能知道这段序列是否正确。问题在于如果测试不通过到底错在第几步需要逐段定位。如果只有“对/错”二值奖励模型很难学到中间步骤的正确技能。如果每次试错都要真实地在沙箱环境里运行代码训练成本会迅速上升。这就催生了奖励模型、过程奖励Process Reward ModelPRM、代码执行沙箱等配套技术。对普通开发者来说了解这些概念不是为了复现训练而是为了在选择模型、设计 Agent 时知道什么方案靠谱、什么方案只是在“表面优化”。3. 长时程编码任务训练的技术拆解理解了问题背景下面我们来拆解“如何在训练和微调中提升 long-horizon coding 能力”。这一节对做模型训练的同学比较技术向应用开发者也建议读完因为你可以借此判断底层模型是否适合做 Agent 底座。3.1 数据层构造多步骤任务轨迹显式训练的第一步是准备 long-horizon 数据。所谓轨迹数据在代码任务里通常长这样{ task: 重构用户模块的鉴权方式从 Session 改为 JWT并保持旧接口 /api/user/info 兼容, repo: example-user-service, steps: [ { thought: 先了解现有鉴权过滤器在哪查找 javax 相关文件。, action: grep -r \HttpSession\ src/main/java, observation: src/main/java/com/example/AuthFilter.java:42 ... }, { thought: 创建 JWT 工具类并在 AuthFilter 中替换 Session 读取逻辑。, action: edit src/main/java/com/example/AuthFilter.java, observation: file updated }, { thought: 更新测试用例新增 JWT 场景。, action: edit src/test/java/com/example/AuthFilterTest.java, observation: file updated }, { thought: 运行测试确认没有破坏旧逻辑。, action: mvn test -DtestAuthFilterTest, observation: Tests run: 15, Failures: 0, Errors: 0 } ], final_answer: ... }这类数据有几种常见获取方式从真实 GitHub Issue PR 关联数据中爬取Issue 是任务PR 是代码变更测试结果是验证信号在沙箱环境里运行模型/Agent 生成轨迹再人工或自动筛选正确轨迹用规则或小模型启发式生成多步操作序列再用任务成功率筛选。在构建数据时需要重点覆盖两类“课程难度”单文件多函数修改训练模型跨函数、跨类协调多文件横向改动训练模型理解文件间依赖关系。3.2 训练策略SFT RL 两阶段这里给一个常见的训练流程适用于在已有的基础代码模型上继续增强 long-horizon 能力。阶段一SFT on Trajectories在这个阶段直接用构造好的轨迹数据做监督微调。输入 [用户任务描述] [仓库检索结果 / 相关文件内容] [已执行的动作及观测结果] [历史步骤摘要] 输出 下一个动作 或 最终答案训练时需要注意的点不要只训练“最终答案”要让模型见过大量中间步骤否则运行时它会跳过必要动作直接改代码导致测试失败。要均衡“成功轨迹”和“失败轨迹”。如果全是成功轨迹模型遇到意外情况时缺少恢复能力。建议混入大约 20%-30% 的失败轨迹并把“失败后如何修正”也作为监督信号。上下文长度要足够容纳“任务描述 仓库信息 已执行步骤”。建议训练时动态截断和摘要提高模型对长上下文的耐受力。SFT 阶段的代码实现通常基于 transformers 库下面是一个伪代码示例展示数据预处理逻辑# 文件路径train_sft.py from transformers import AutoTokenizer, AutoModelForCausalLM from datasets import load_dataset model_name your-base-code-model tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) dataset load_dataset(json, data_filestrajectory_data.jsonl) def format_input(example): # 将任务、上下文、历史步骤拼接成对话格式 messages [{role: system, content: You are an AI coding agent.}] messages.append({role: user, content: example[task_prompt]}) for step in example[steps]: messages.append({role: assistant, content: step[thought] \n step[action]}) messages.append({role: user, content: Observation:\n step[observation]}) messages.append({role: assistant, content: example[final_answer]}) # 这里省略 tokenizer.apply_chat_template 细节按具体模型模板处理 return tokenizer.apply_chat_template(messages, tokenizeFalse) tokenized_dataset dataset.map(lambda x: {text: format_input(x)}) # 之后交给 Trainer 做标准 SFT 即可阶段二RLHF / RLVR 强化结果验证如果说 SFT 让模型“见过”长任务怎么走那 RL 阶段就是让模型“练会”长任务怎么做。在编码场景中最实用的强化训练方式叫RLVRReinforcement Learning from Verifiable Rewards基于可验证奖励的强化学习。它的思路很简单跑测试通过了就给正奖励不通过给负奖励。伪代码如下# 文件路径rlvr_train.py def reward_fn(prediction, test_suite, repo_path): 在沙箱环境运行测试根据结果返回奖励。 apply_patch(repo_path, prediction[patch]) result run_test_suite(repo_path, test_suite) if result.failed 0: return 1.0 elif result.errored 0 and result.failed 5: return 0.3 else: return -1.0这里有几个实战经验奖励函数要分层。全对给满分部分测试通过给部分分完全跑不起来给负分。稀疏的二值奖励会让训练极其不稳定。使用过程奖励Process Reward Model。如果训练资源允许可以训练一个 PRM对每个中间步骤打分帮助模型定位“从哪一步开始跑偏”。上下文压缩策略很重要。长任务轨跡非常长训练时要用摘要机制动态压缩旧步骤否则 GPU 显存扛不住。3.3 评估层建立长时程基准训练完之后不能只靠“读代码像不像”来判断模型好坏。推荐从三个维度评估 long-horizon coding 能力评估维度考察内容例子任务完成率最终是否通过测试、满足需求修复一个跨文件 Bug要求所有单测通过过程效率是否用了最少步骤完成应当只修改 2 个文件模型却改了 6 个错误恢复能力中间步骤失败后能否纠正第一步 grep 结果不对模型能否换一种检索方式目前开源社区已经有类似 SWE-bench 的基准它收集真实 GitHub Issue 和对应 PR用测试用例自动验证模型生成的 patch。如果你在做模型对比强烈建议用这种“Issue - Patch - Test”的闭环基准而不是只给一个函数让模型补全。4. 实战在现有模型上增强 Long-horizon Coding 能力很多团队没有从零预训练模型的条件但可以在开源模型基础上做微调或直接构建 Agent 应用。本节梳理两条路径模型微调路径和应用工程路径。4.1 路径 A基于开源模型的 SFT RL 微调适合有 GPU 资源、希望打造垂直领域模型的团队。核心步骤4.1.1 准备轨迹数据数据格式可以保持 3.1 中的 JSONL 结构。建议字段{ repo: 项目名, task_id: issue-123, task_description: 问题描述, related_files: [src/A.java, src/B.java], trajectory: [ {type: action, content: read src/A.java}, {type: observation, content: ...}, {type: action, content: edit src/B.java} ], final_patch: diff 内容, test_result: passed }4.1.2 数据清洗真正工程质量在于数据清洗。注意点过滤掉测试服务不稳定的样本避免噪声标签根据 final_patch 是否通过测试筛选成功轨迹对失败轨迹打上“失败原因”标签如“缺少依赖文件”“修改了错误模块”去重同一个 Issue 的轨迹不要保留 100 条近似内容容易导致过拟合。4.1.3 微调资源配置参考这里不写死具体框架版本因为变化很快。只给方案方向基座模型建议 7B 到 32B 规模之间兼顾效果和显存使用 DeepSpeed ZeRO-3 或 FSDP 解决多卡显存LoRA/QLoRA 可以先跑通流程最终训练追求上限就做全参数微调训练分为“短轨迹”和“长轨迹”两个阶段先训短任务再逐步加长类似课程学习。4.2 路径 B不训练模型通过 Agent 框架补足 Long-horizon 能力如果团队没有微调预算仍然可以显著提升模型在长任务上的表现。核心思路是在 Agent 框架里做“显式规划、显式记忆、显式验证”。4.2.1 显式计划Plan-then-Execute不要让模型直接输出 patch而是先输出结构化计划。# 文件路径agent/planner.py SYSTEM_PROMPT 你是一名资深工程师。在修改代码之前必须先输出一份修改计划。 输出格式为 JSON { goal: 本次任务的最终目标, steps: [ {order: 1, action: locate, target: 鉴权过滤器所在文件}, {order: 2, action: read, target: src/main/java/AuthFilter.java}, {order: 3, action: modify, target: AuthFilter.java, detail: 把 Session 读取改为 JWT 解析} ], risks: [旧接口可能受影响需要回归测试] } 计划本身就是在要求模型显式利用训练时学到的任务分解能力同时给执行者一个稳定的锚点避免走着走着忘掉全局目标。4.2.2 状态跟踪与摘要Long-horizon 任务执行过程中上下文会越来越长。一个工程技巧是维护“任务状态摘要”每执行若干步就更新一次摘要而不要把原始日志全部塞进上下文。# 文件路径agent/state.py class TaskState: def __init__(self, goal): self.goal goal self.completed_steps [] self.current_file_refs [] self.known_issues [] def summarize(self, max_len1200): summary f目标{self.goal}\n summary 已完成步骤\n- \n- .join(self.completed_steps[-10:]) summary \n当前相关文件\n- \n- .join(self.current_file_refs) summary \n已知问题\n- \n- .join(self.known_issues[-5:]) # 超出 max_len 时需要截断或调用摘要模型 return summary[-max_len:]这种摘要机制能显著延长 Agent 的有效工作步数也是 long-horizon 任务工程落地的关键。4.2.3 验证回路Test-in-the-LoopAgent 做完一步修改后不要急着做下一步。先运行相关测试根据测试反馈决定继续还是回溯。# 文件路径agent/verifier.py from subprocess import run, PIPE def verify(project_dir, test_command): result run(test_command, shellTrue, cwdproject_dir, capture_outputTrue, textTrue) if result.returncode 0: return {passed: True, output: result.stdout[-1000:]} else: return { passed: False, output: result.stdout[-1000:], error: result.stderr[-1000:] }在 Agent 主循环中只有passedTrue时才前进到下一步否则触发“错误分析动作”。4.3 完整 Demo一个最小 Long-horizon Agent下面给出一个极简原型演示“计划 - 执行 - 验证”的循环。这个示例不依赖特定 API核心是说明结构。# 文件路径simple_long_horizon_agent.py import os from agent.planner import generate_plan from agent.state import TaskState from agent.verifier import verify class SimpleCodingAgent: def __init__(self, repo_path, llm_generate_func): self.repo_path repo_path self.llm_generate_func llm_generate_func self.state None def run(self, issue_description): # 1. 规划 plan self.llm_generate_func( 请为以下问题生成分步修改计划。\n f问题{issue_description}\n f仓库路径{self.repo_path} ) print( 计划 ) print(plan) # 2. 初始化状态 self.state TaskState(goalissue_description) # 3. 执行循环 tasks extract_steps_from_plan(plan) for step in tasks: thought self.llm_generate_func( 当前步骤 step \n 状态摘要 self.state.summarize() \n 请输出下一步具体 shell 命令或代码修改内容。 ) print( 动作 ) print(thought) if thought.strip().startswith(run:): cmd thought.split(run:, 1)[1].strip() result run_command(cmd, self.repo_path) print( 观察 ) print(result) self.state.completed_steps.append(cmd) elif thought.strip().startswith(edit:): # 简化处理直接把修改内容写入文件 file_path, content parse_edit_command(thought) apply_file_change(file_path, content) print(f已修改 {file_path}) self.state.completed_steps.append(fedit:{file_path}) # 4. 验证每三步验证一次测试 if len(self.state.completed_steps) % 3 0: test_result verify(self.repo_path, python -m pytest tests -x) if test_result[passed]: print(测试通过继续执行。) else: print(测试失败进入错误分析模式。) analysis self.llm_generate_func( 测试失败错误信息\n f{test_result[error]}\n 请分析原因并给出修复建议。 ) print(analysis) print( 最终状态 ) print(self.state.summarize()) def run_command(cmd, cwd): import subprocess result subprocess.run(cmd, shellTrue, cwdcwd, capture_outputTrue, textTrue) return result.stdout result.stderr def extract_steps_from_plan(plan): # 简化解析假设 plan 中的每一行是一个步骤 return [line for line in plan.splitlines() if line.strip()] def parse_edit_command(thought_line): # 简化解析从 edit: 文件路径\n内容 中解析 raw thought_line.split(edit:, 1)[1].strip() file_path, content raw.split(\n, 1) return file_path, content def apply_file_change(file_path, content): with open(file_path, w, encodingutf-8) as f: f.write(content) # 使用示例 if __name__ __main__: def fake_llm(prompt): # 这里接入真实模型 API return run: git status agent SimpleCodingAgent(repo_path./my_project, llm_generate_funcfake_llm) agent.run(修复登录模块无法返回用户信息的问题)实际接入时把fake_llm替换成 OpenAI、Anthropic、GLM 或其他模型的调用即可。这个例子虽然简单但已经包含 long-horizon 的三个核心模块计划生成状态摘要与记忆测试验证回路。5. 当前工具链与热词盘点最近看到了很多高频词汇比如 vibe coding、coding plan、spec-driven development。这些热词容易让人混淆这里做一个简单辨析。5.1 Vibe CodingVibe Coding 的核心思想是“跟着感觉走”用自然语言描述需求让 AI 实时生成代码。它适合快速原型验证、前端页面调试、胶水代码生成。但它不要求任务有多长、多复杂所以并不天然解决 long-horizon 的问题。在大型项目里直接 vibe coding 很容易陷入“代码到处能跑、但没人知道哪段代码为什么存在”的混乱。5.2 Coding PlanCoding Plan 是在编码前让模型生成一个行动计划。它可以是修改哪些文件依赖什么接口实施顺序如何验证。这个做法本质上就是把 long-horizon task 转化为“一串短任务”降低每一步的复杂度让模型逐步执行、逐步反馈。5.3 GLM Coding PlanGLM Coding Plan 是智谱生态里推出的 Coding Plan 产品/体验方案从搜索词里能看到“GLM coding plan·7天体验卡”这类信息。它的价值在于把“大模型生成计划”做成了产品化流程。虽然不同产品的细节差异很大但在解决 long-horizon 任务这一目标上思路和社区里其他 plan 类工具是一致的先规划再动手避免模型在复杂任务中迷失方向。5.4 Spec-driven DevelopmentSDDSDD 比 coding plan 更进一步先把需求完整地写成规格例如用 markdown 写清楚用户故事、验收标准、设计方案然后再让 AI 基于规格生成实现计划、代码和测试。在这种模式下long-horizon 任务的“验证信号”来自于规格中的验收标准Agent 能更准确地判断“做完了没有”。5.5 从 Vibe Coding 到 Harness × SDD现在圈子里有句流行话叫“从 vibe coding 到 harness × SDD 全栈开发实战”。这里的 harness 可以理解为一套“约束和支架”类似于测试框架、类型检查、CI 流程、监控系统。SDD 则补充了“需求到代码的可追踪链路”。两者结合本质上就是给生成式编程套上一层“工程安全网”。如果你打算做 AI 编码工具或 Agent 平台这个方向值得关注。因为单靠模型自由度很难稳定交付复杂项目必须是“模型 工程脚手架”的组合。6. 常见问题与排查思路6.1 为什么 Agent 总在一个文件里反复修改问题现象常见原因解决思路Agent 反复修改同一文件无法跳出局部方案上下文里丢失了全局目标在每次循环开始时注入任务目标摘要明明有更简单的方案Agent 却选择了复杂改动模型缺乏全局仓库结构感知在规划阶段一次性检索仓库文件树、模块说明修改后测试失败Agent 无法定位根因观察信息过载关键报错被淹没截断日志输出提炼最近几条错误信息给模型建议在 long-horizon 任务里把“目标”和“已完成的改动清单”放在 prompt 的显眼位置不要依赖模型记住。6.2 训练长任务轨迹时显存溢出怎么办这个问题在做 SFT 时最常见。策略按优先级排列缩短单条轨迹长度把长轨迹切成多个短会话每个会话内部自带摘要使用 LoRA/QLoRA 降低显存占用对历史步骤做摘要压缩上下文里只保留最近的 N 步完整内容采用序列打包sequence packing提高 batch 的训练效率。6.3 RL 训练时奖励一直不涨排查顺序检查环境沙箱是否稳定、测试是否无歧义。检查奖励密度是不是 99% 的样本都是负奖励模型根本没有有效梯度信号。检查初始策略如果基座模型本身完成率极低可以先做一轮 SFT再开始 RL。检查优势估计尝试候选采样数量 K 设大一点比如 8 或 16让模型有更多比较对象。6.4 模型计划写得很好执行就崩这就是典型的“规划能力”和“执行能力”分离问题。解决办法执行过程中允许模型每步结束后返回计划修正引入“计划变更申请”让模型明确说明为什么要偏离原计划在验证回路里增加“最小改动原则”约束禁止与任务无关的文件修改。7. 最佳实践与工程建议7.1 训练层面的最佳实践课程学习先训练 2-3 步的短任务再逐步扩展到 10 步以上的长任务。一步到位训练超长任务容易不收敛。混入失败样本建议最多 30%太少模型不会纠错太多模型过度保守。使用可验证奖励能用测试用例给出二进制成功信号的就不要让模型给自己打分。过程奖励优先于结果奖励结果奖励太稀疏最好结合 PRM。7.2 应用层面的最佳实践保持计划可见性无论用哪家模型的 Coding Plan都要把计划展示给用户让用户可以在计划阶段纠偏。限制动作类型不要给 Agent 完整的 shell 权限。最好提供read、edit、run_test、search四个原子动作减少不可控行为。记录决策日志为了让用户理解 Agent 为什么改某一行代码需要把“读到的信息”和“决策依据”记录下来。沙箱隔离运行 Agent 的代码执行环境必须隔离应用层不能允许 Agent 直接访问生产库。7.3 生产环境的注意事项在代码仓库上操作之前先确认是否具有维护者授权对生产环境变更建议先走 MR 评审。执行 Agent 修改前优先在临时分支操作不要直接推到主干。对数据库字段的改动必须同时附上迁移脚本并做回滚演练。涉及删除文件或重写大段逻辑时强制增加人工 review 门槛。日志要保留原始 prompt、Agent 的思考过程、执行命令、测试输出方便事后复盘。8. 总结与学习路线如果你想在 long-horizon coding 方向上继续深入我建议按下面的顺序学习。掌握基础理解 GPT/LLM 的生成原理熟悉 function calling 和 tool use 的接口设计。跑通 Agent 框架用现成框架搭一个最小 Agent先让它完成“读取仓库 - 修改代码 - 跑测试”的闭环。研究轨迹数据找一批真实 Issue手动构造轨迹数据理解“好数据”长什么样。动手微调用 LoRA 在开源模型上做 SFT数据规模可以先从 5000 条开始观察模型行为变化。接触强化学习跑通 RLVR 流程重点理解奖励函数对训练稳定性的影响。参与评估基准使用 SWE-bench 这类基准持续跟踪模型在 long-horizon 任务上的真实表现。在实践过程中最容易忽略的一个风险是把模型在短任务上的表现误判为它在长任务上的能力。短任务正确率提升很快但长任务一旦进入第 10 步错误累积往往是指数级的。不要把评测集只做成“短问题集”一定要覆盖多步骤、多文件、带验证回路的任务。最后想说的是long-horizon coding 的训练和应用本质上都在做同一件事把“生成代码”这件事改造成“逐步完成任务”这件事。任何方案无论是 coding plan、SDD、RLVR 还是 Agent 状态机都在朝这个方向努力。如果你正在做相关应用可以先把计划、记忆、验证这三个模块搭起来再逐步通过数据或提示词优化细节。