X thread analysis · 2026-05-15

SWE-ZERO-12M：用不执行测试的 agent trace 换取代码 Agent 数据规模

Kevin Li 这条帖子真正重要的地方，不只是发布了一个 112B token 的开放数据集，而是提出了一条非常明确的数据工程路线：牺牲执行验证，保留仓库导航、shell 操作、读写文件和多轮决策过程，从而绕开 Docker 环境瓶颈，把可用于 agentic mid-training 的真实 PR 轨迹放大一个数量级。

1. 我读了哪些来源

本报告把 X 帖当成入口，但判断主要基于可复核的一手材料：Hugging Face dataset card、Marin GitHub issue 中的实验记录、以及 SWE-ZERO/SWE-HERO 原论文背景。X 回复区里最有价值的信息是作者对“15 turn 是否够用”的回应，以及外部质疑 execution-free 质量的评论。

Kevin Li X thread OpenCLI 读取原帖与回复：发布 SWE-ZERO-12M-trajectories，解释规模、execution-free recipe、Marin/Qwen 实验和致谢。

Hugging Face dataset card: AlienKevin/SWE-ZERO-12M-trajectories 主来源：规模、动机、schema、采样设置、MinHash diversity、Marin-8B 训练验证、局限。

Marin issue #5611 Qwen3-1.7B-Base 的 10K/100K/1M SFT 实验、SWE-bench Verified 100-task slice 评估、关键修复和 8K 截断失败案例。

Marin issue #4898 Marin-8B 早期质量验证；GitHub 动态页抽取不完整，但 HF dataset card 引用了该 issue 的核心结果。

arXiv 2604.01496: From SWE-ZERO to SWE-HERO 背景来源：SWE-ZERO 是 execution-free 预训练/微调阶段，SWE-HERO 是后续 execution-backed refinement。

2. 一句话讲清楚这条帖子的主线

核心 thesis： 代码 Agent 训练缺的不是普通代码文本，而是“模型像开发者一样在仓库里查找、推理、修改、提交”的多轮轨迹；但如果每条轨迹都要求可执行 Docker 环境和测试验证，数据规模会被构建环境卡死。SWE-ZERO-12M 的策略是：先不要验证 patch 对不对，先大规模学习 agentic tool-use prior。

这里的 agentic trace 不是“一个问题和一个答案”。它更像一段开发过程日志：系统提示告诉模型如何操作 shell，用户给出 issue/PR 任务，assistant 每轮输出一个 bash 命令，环境返回命令结果，模型再根据结果决定下一步。训练这种数据的目标，是让 base model 学会“怎么在仓库里工作”，而不是立即保证它能最终修好 bug。

这和普通代码预训练差别很大。普通代码预训练主要学 token 分布、API 形态、函数结构；agentic trace 则让模型学会“什么时候 grep、什么时候打开文件、怎么根据报错定位、怎么编辑、什么时候提交”。如果未来代码模型越来越像一个长期运行的开发代理，这类 trajectory 数据会比单纯的代码文件更接近真实使用形态。

3. 它到底在解决什么问题

问题不是“没有 GitHub 代码”。GitHub 代码很多。真正稀缺的是高质量、可训练、可规模化的“代码 Agent 操作轨迹”。

瓶颈 A：数据可用性

真实 PR 很多，但不是每个仓库都能被现代容器顺利复现。老依赖、私有服务、系统包、数据库、GPU、网络、CI 脚本、平台差异，都会让“构建可执行环境”变成长尾工程问题。

如果一个数据 pipeline 必须先把仓库装起来、测起来，很多真实 PR 会被过滤掉。被过滤掉的往往不是“没价值”的 PR，而是环境复杂、历史久、工程味更重的真实问题。

瓶颈 B：rollout 成本

对每个 PR 生成多条 agent 轨迹，如果每条轨迹都要运行测试、维护 Docker image、处理依赖和 sandbox，这不只是算力问题，还是 infra orchestration 问题。

SWE-ZERO 的判断是：训练早期不一定需要每条轨迹都被测试验证。先学仓库导航和工具使用，再用更小但更高质量的执行反馈数据或 RL/SFT 做后处理。

关键取舍： 它不是说执行验证不重要，而是把“学会像 agent 一样行动”和“确保最终 patch 正确”拆成两个阶段。SWE-ZERO-12M 主要服务前者。

4. 它是怎么做的：从 PR 到训练轨迹

可以把 SWE-ZERO-12M 的数据生成理解成一个去掉执行验证的 mini-SWE-agent rollout factory。

取真实 PR snapshot

从 SWE-rebench-V2-PRs 中取真实 GitHub PR 任务，覆盖 3,222 个仓库。

构造 agent 任务

使用 mini-swe-agent v1 格式，把任务转成多轮 shell 交互。

采样 100 条 rollout

用 mini-coder-1.7b 以 temperature 1.0 对每个 PR 采样独立轨迹。

禁止 repo-specific execution

不跑 pytest、npm test、build script；只允许 grep、find、sed、cat、git 等通用 POSIX 命令。

保存 messages 轨迹

每条样本是 system/user/assistant/observation 的多轮列表，带 exit_status 与 duration。

什么叫 execution-free

execution-free 不是“模型不能执行任何命令”。它的意思是：不执行依赖仓库环境的命令。比如 grep、find、sed、cat、ls、git 这些命令不要求安装项目依赖，所以可以在几乎任意仓库快照上运行；但 pytest、npm test、cargo test、项目 build script 往往要求依赖、服务、环境变量和系统包，所以被排除。

这会让轨迹更像“静态仓库侦查 + 文本级编辑”，而不像完整开发闭环。好处是规模能上来；坏处是没有 runtime feedback，模型无法从测试失败中修正，也无法确认 patch 是否真的工作。

训练时学到的是什么

这类数据对模型最直接的训练信号是 next-token prediction：给定前面的系统提示、任务描述、命令输出和历史动作，预测下一轮 assistant 应该怎么思考、发什么命令、如何编辑文件。它不是强化学习奖励，也不是 verifier-guided RL；dataset card 里的验证实验也主要是标准 SFT / masked-loss recipe。

更准确的说法： SWE-ZERO-12M 更像“agentic behavior pretraining / mid-training corpus”，让模型学工具使用先验；后面仍需要高质量 SFT、执行验证数据、RL 或 evaluator 过滤，把行为先验转成稳定的 task completion 能力。

5. 数据规模、schema 和采样设置

项目	数值 / 格式	含义
总轨迹数	12,290,800 rollouts	每个 PR 约 100 条独立 rollout；规模比此前 SWE-ZERO 9B token 版本大约 10 倍。
总 token	约 112B tokens，表中写 111.06B	作者称比 open-thoughts/AgentTrove 的 19.41B token 大 5.7 倍。
PR / repo 覆盖	122,908 PRs，3,222 repos	数据来自真实软件工程任务，而不是纯合成 toy repo。
语言覆盖	16 programming languages	说明不是单一 Python 轨迹，但评估主要仍围绕 SWE-bench Verified。
每条样本字段	`instance_id`, `repo`, `messages`, `trajectory_format`, `exit_status`, `duration_sec`	`messages` 是核心，包含多轮 agent 与 shell 环境交互。
采样设置	15 max turns, temperature 1.0, 32,768 max tokens	为了控制 p99 生成成本，每条 rollout 最多 15 个模型 turn。

15 turn 的含义

回复区有人问：15 turn 对复杂 SWE task 是否太短。作者承认 15 turn 通常不够，Qwen3 Coder 30B A3B 在 SWE-smith tasks 上 median turn 约 30；SWE-ZERO 的 15 turn 截断导致 submission rate 只有 3.4%。但作者认为，即使如此，Qwen3-1.7B-Base 仍能通过这些短轨迹学到提交与解决部分任务的能力。

这里要区分两件事：作为“完整解题轨迹”，15 turn 很短；作为“mid-training 行为片段”，15 turn 仍可能有价值。模型可能学到的是仓库定位、命令格式、观察结果处理、patch 生成习惯，而不是完整任务闭环。

6. 它如何证明这些数据真的有用

这次 release 的验证不是“训练出一个顶级代码 Agent”，而是用小规模训练检查：execution-free、incomplete、unverified 的轨迹是否仍能给 base model 带来可测的 SWE-bench 提升。

6.1 Diversity check：轨迹是否只是重复

Dataset card 使用 MinHash-64 估算同一 PR 内 rollout 的 bash-command shingles 相似度，报告平均 Jaccard similarity 为 0.2730，低于 0.5 的 diversity threshold。直觉上，如果 100 条 rollout 都是同一串 grep/cat/edit 的复制品，训练价值会很低；0.2730 表示同一 PR 下采样出来的 agent 路径有相当差异。

这个指标只说明“命令序列不太重复”，不说明 patch 正确，也不说明思维质量高。它验证的是数据多样性，不是任务成功率。

6.2 Marin-8B 验证：从 0% 到 3.3-5.3%

训练数据	Rollouts	Tokens	SWE-bench Verified 100-task mean resolve
Marin-8B Base	n/a	n/a	0.0%
SWE-ZERO training	10,000	约 100M	3.3% ± 0.6
SWE-ZERO training	50,000	约 570M	4.0% ± 2.0
SWE-ZERO training	100,000	约 1.1B	5.3% ± 1.5

这个结果的意义很窄但重要：一个 base model 直接在 SWE-bench Verified 上是 0%，加入这些 unverified trajectories 后开始解决少量任务，并且数据量增加时指标上升。它不是强性能宣称，因为 5.3% 本身很低；但作为“数据有训练信号”的 smoke test 是成立的。

6.3 Qwen3-1.7B 验证：10K -> 100K -> 1M 单调提升

训练样本	训练 token	pass@1 / resolve	解读
10K rollouts	约 75M	7/100 = 7%	小样本已能从 0 附近获得可见行为增益。
100K rollouts	约 754M	9/100 = 9%	提升不大，但方向一致。
1M rollouts	约 7.5B	11/100 = 11%	单调上升，并且解决任务从 django/sympy 扩展到 pylint/pytest/scikit-learn/sphinx。

这个实验比 Marin-8B 更有意思，因为它显示 8K 截断后的数据仍能让 Qwen3-1.7B 在同一个 100-task SWE-bench Verified slice 上从 7% 提到 11%。作者把 100K 设成 10K 的 superset，1M 设成 100K 的 superset，因此更接近“同分布增加数据量”的 scaling check。

6.4 评估到底评的是什么

任务

SWE-bench Verified 的 100 个任务切片。模型需要作为代码 Agent 在仓库中定位问题、修改代码并提交 patch。

输入输出

输入是 issue/任务与仓库环境；输出不是一段自然语言答案，而是一系列 agent 动作和最终 patch/submit。

指标

pass@1 / resolve rate：一次尝试中最终 patch 是否通过验证。这里的 11/100 就是 100 个任务里解决 11 个。

不要误读： 这些结果不能证明 SWE-ZERO-12M 能单独训练出强代码 Agent。它只证明：即便轨迹不执行测试、很多不完整，作为 mid-training 数据仍能产生可测的工具使用与 SWE 任务迁移信号。

7. 最关键的局限与风险

没有 correctness guarantee

轨迹没有用 ground-truth test 验证，patch 可能不能编译、不能 apply、不能解决问题。训练时模型会同时吸收有效行为和错误行为。

submission rate 低

作者在回复中承认 15 turn 导致 SWE-ZERO dataset submission rate 只有 3.4%。如果只保留 clean submissions，会丢掉大部分数据。

短轨迹偏向早期探索

15 turn 往往覆盖定位和初步编辑，覆盖不到复杂调试、运行测试、反复修复、review feedback 等后半段工程能力。

评估切片小

Marin 和 Qwen 实验都使用 SWE-bench Verified 的 100-task slice。它适合快速 validation，但不能当作完整 leaderboard 级结论。

execution-free 和 production agent 有差距

真实开发中测试、lint、类型检查、复现报错是核心反馈。SWE-ZERO 先学无执行环境下的行为，不代表最终 agent 可以不执行。

格式/截断很敏感

Marin issue #5611 记录过 8K right truncation 导致模型输出全是感叹号的灾难性退化。后来需要 eos_token、max_tokens、RoPE、observation template 等多个修复才恢复 >0% resolve。

我的判断： 这类数据的最大风险不是“噪声多所以没用”，而是“噪声、截断和 prompt 格式会以很不直观的方式变成行为病灶”。比如模型不是稍微差一点，而是陷入固定 token attractor，完全失去 action parser 可用性。

8. 我的 insight：它真正改变的是数据路线，不是短期榜单

如果只看 5.3% 或 11% 的 SWE-bench Verified 数字，这个工作看起来并不惊艳。但这样看会错过重点。SWE-ZERO-12M 的价值不在于“直接训出了强 agent”，而在于证明了一种可规模化的数据层：真实 PR + 多轮工具使用 + 不依赖 Docker 的 execution-free rollout。

代码 Agent 训练未来大概率会分层：第一层用海量 execution-free trace 学仓库语义、命令习惯、局部编辑、工具循环；第二层用少量高质量 execution-backed trace 学测试驱动、错误恢复和任务完成；第三层再用 RL / verifier / human preference 优化最终策略。SWE-ZERO-12M 很适合第一层，不适合直接替代第二层和第三层。

这也解释了为什么作者强调 “mid-training corpus, not an SFT dataset”。如果把它当成最终 instruction-tuning 数据，很可能会嫌弃它 incomplete、unverified、submission rate 低；但如果把它当成 base model 的 agentic 行为预训练，它的噪声容忍度会更高，因为目标是学分布和动作先验，而不是逐条模仿成功 patch。

实践建议： 如果要用这个数据训练模型，不要只做简单 concat SFT。更稳的路线是：按轨迹长度、exit_status、命令类型、是否出现编辑/submit、仓库语言分布做 curriculum；保留大量 incomplete traces 用于行为预训练，再用 verified / execution-backed 小数据做最后对齐。尤其要对 chat template、EOS、截断方向、observation 格式做单元级验证，否则很容易训练出表面 loss 正常、实际 agent loop 崩掉的模型。

9. 本次获取与校验命令

我按仓库 OpenCLI 规范先确认能力，再读取 X thread 和网页来源。

opencli list | rg -i "twitter|x\.com"
opencli twitter --help
opencli twitter thread --help
opencli twitter thread "https://x.com/kevin_x_li/status/2054600962137100493" --limit 80 -f json --trace retain-on-failure

curl -Ls -o /dev/null -w '%{url_effective} %{http_code}\n' "https://t.co/aVqCc4J5tr"
opencli web read --url "https://huggingface.co/datasets/AlienKevin/SWE-ZERO-12M-trajectories" --stdout true --download-images false --wait 5 -f md --trace retain-on-failure
opencli web read --url "https://github.com/marin-community/marin/issues/5611#issuecomment-4440640008" --stdout true --download-images false --wait 5 -f md --trace retain-on-failure
curl -L --fail --silent "https://huggingface.co/datasets/AlienKevin/SWE-ZERO-12M-trajectories/raw/main/README.md"

GitHub REST API 在本机公网出口触发 unauthenticated rate limit，因此 #4898 的详细 comment 没有通过 API 读取；相关核心数值由 HF dataset card 引用，#5611 页面正文由 OpenCLI 成功读取。