2026-06-17 SWE-agent trajectory 关键词 备注

核心结论

在构建 Godot 4 编码模型时，仅使用少量 Q&A 数据集可能不足。当前思考的问题并非单纯的 instruction 数据集问题，而是更接近于一个 software engineering agent 的学习任务：需要读取仓库级别的长上下文，进行文件浏览、判断、修改、验证、生成补丁等全过程。

综上所述，当前方向的名称接近于以下内容。

Long-context repository-level software engineering agent training

或者更简短地说，可以视为以下关键字。

SWE-agent trajectory training

如果转向 Godot，目标不是单纯的 Godot 问答模型，而是更接近以下。

创建用于 Godot 的 SWE-agent 轨迹数据集

为什么仅靠小型问答仍然不足

原来的困惑如下。

"请制作地图"
-> 项目读取  
-> 查找相关文件  
-> 检查资源  
-> 判断 Godot 4 语法/API  
-> 修改代码  
-> 运行/测试/验证  
-> 生成补丁

这段流程并不是仅仅以 问题 -> 回答 一次结束。实际的编码代理需要遍历多个文件，进行中间判断，修改后再进行验证。因此，与其只保留最终答案代码的数据集，不如将代理在解决问题过程中留下的轨迹和补丁作为学习数据，这种方向可能更为合适。

查找的优先级

1. SWE-smith
2. nebius/SWE-agent-trajectories
3. CoderForge-Preview
4. ACC
5. aiXcoder CoLT
6. RepoBench / CrossCodeEval / RepoCoder
7. godot-dodo / wallstoneai dataset

案例 备注

SWE-agent 轨迹

SWE-agent-trajectories 是一个记录代理行为的数据集，内容包括查看 GitHub issue、浏览仓库文件、打开所需文件、进行修改、测试以及生成最终补丁的过程。

核心关键词：

• 代理轨迹
• GitHub issue 解决
• 文件探索
• 补丁生成
• 软件工程代理训练

Godot 方面的对应：

"请制作地图"
-> 探索 Godot 项目结构
-> 确认相关 scene/script/resource
-> 修改
-> 执行或截图验证
-> 生成补丁

SWE-smith

SWE-smith是将 GitHub 仓库转换为软件工程代理学习环境的工具包。它可以将任意 GitHub 仓库转换为 SWE-gym 形式，并能够进行文件定位、程序修复、SWE-bench 风格的任务。

Godot 方面的对应：

Godot repo  
-> 创建地图/场景/脚本修改任务  
-> 创建 Godot 代理轨迹  
-> 训练 Godot patch 模型

SWE-Gym

SWE-Gym是将代码库、可执行运行时环境、单元测试、自然语言任务捆绑在一起，用于训练SWE代理和验证器的案例。

Godot 方面的对应：

Godot 项目
+ 可运行的 Godot 版本
+ 场景/测试/截图 验证
+ 自然语言 任务
+ 修改 轨迹
+ 补丁

重要的是，不仅仅学习代码或仅仅学习自然语言问题，而是将执行环境和验证一起捆绑。

CoderForge-Preview

CoderForge-Preview 是基于 agent trajectory 构建 long-context SFT 数据的案例。使用了最长 128K token 的 long-context trajectory，这一点很重要。

该案例为以下疑问提供了依据。

在仓库级别的工作中，是否不需要大量的上下文？

实际编码代理学习方面也有使用长上下文轨迹的流程。

ACC

ACC: Compiling Agent Trajectories for Long-Context Training 是将 agent 轨迹编译为长上下文问答形式的方向。将跨多个回合的工具调用、观察、文件内容、搜索结果转换为长上下文学习数据是其核心。

此案例与以下疑问相连。

仅学习最终答案代码就足够吗？  
还是需要将文件浏览和判断过程也保留为学习数据？

RepoBench / CrossCodeEval / RepoCoder

此系列处理仓库级别的代码理解和完成问题。

核心问题意识：

• 仅使用 single-file 基准难以体现真实项目的复杂度。
• 有用的信息分散在多个文件中。
• 需要评估需要跨文件上下文的代码补全。
• 需要检索‑生成流水线。

Godot 方面的对应：

文件只有一个的话，地图修改会很困难。  
需要一起查看 scene、script、resource、project 设置以及 asset 路径。

aiXcoder CoLT

aiXcoder-7B-v2和 CoLT 处理即使提供长上下文，模型仍可能忽略有用信息的问题。

重要的疑问：

是否需要大量放入上下文？  
-> 不是。  
即使大量放入，也需要验证模型是否真的读取并利用它。

Godot 方面，即使在长上下文中包含了 Godot 4 的相关信息，模型仍可能使用 Python 风格的模式或 Godot 3 API 来回答。因此，可能需要对 long‑context 的使用进行专门训练，或设计更强力固定 Godot 4 语境的数据方案。

godot-dodo / wallstoneai 数据集

在 Godot 方面的直接案例有 godot-dodo 与 wallstoneai/godot-gdscript-dataset。

这两个数据集更接近 GDScript 原始代码或仓库文本数据集。它们对 Godot 专用学习的起点有意义，但与最终目标——agent 轨迹数据集——仍有距离。

与当前目标对比，可整理如下。

现有 Godot 数据集:
GDScript raw code / repo text

所需 Godot 数据集:
Godot repo context
+ user task
+ file exploration
+ patch
+ verification
+ long-context trajectory

当前的困惑与关联关键词

在6月14日的回顾中整理的疑问与之关联如下。

项目的整体上下文和检索到的官方文档片段，能一次性放入模型输入上下文吗？
-> long-context repo-level coding problem

# 探索与判断过程是否也需要以数据形式保留下来？
-> 轨迹训练问题

即使提供长上下文，模型也能正确使用 Godot 4 的语境吗？
-> long-context utilization / CoLT problem

参考链接

• nebius/SWE-agent-trajectories: https://huggingface.co/datasets/nebius/SWE-agent-trajectories
• SWE-smith: https://github.com/SWE-bench/SWE-smith
• SWE-smith dataset: https://huggingface.co/datasets/SWE-bench/SWE-smith
• SWE-Gym: https://arxiv.org/abs/2412.21139
• CoderForge-Preview: https://www.together.ai/blog/coderforge-preview
• ACC: https://arxiv.org/abs/2605.21850
• RepoBench: https://arxiv.org/abs/2306.03091
• CrossCodeEval: https://crosscodeeval.github.io/
• RepoCoder: https://arxiv.org/abs/2303.12570
• aiXcoder-7B-v2 / CoLT: https://arxiv.org/abs/2503.15301
• godot-dodo: https://github.com/minosvasilias/godot-dodo
• wallstoneai/godot-gdscript-dataset: https://huggingface.co/datasets/wallstoneai/godot-gdscript-dataset