训练模型的长程软件工程能力：从 SWE-Marathon 到 FrontierSWE 与 SWE-Together

如果要训练模型做长程软件工程任务，最容易走错的一步，是把“长程能力”理解成“更长上下文 + 更多 token”。SWE-Marathon、FrontierSWE 和 SWE-Together 这三组工作放在一起看，会给出一个更锋利的答案：长程能力不是文本长度，而是 在一个可执行环境里，持续维护目标、状态、证据、风险和验证闭环。

SWE-bench 把真实 GitHub issue 变成了可评分 patch，这是很重要的一步。但它主要回答“模型能不能修一个相对局部的问题”。现在这三组新 benchmark 关心的是另一件事：模型能不能像一个还算可靠的工程师那样，连续几个小时推进一个项目，把中途实验、失败、回滚、测试、用户纠偏、最终提交都组织起来。

如果只记住三句话

第一，SWE-Marathon 测的是“能不能把一个完整项目做完”：产品克隆、库重写、ML 训练、系统优化，全都放进 Harbor/Docker 环境，用 hidden verifier 判定最终是否 resolved。

第二，FrontierSWE 测的是“能不能在人类专家边界上做出真实进展”：PostgreSQL wire-compatible server、Pyright 性能优化、optimizer research 这类任务不再适合二值 resolved，需要 correctness gate、speedup、held-out metric 和 anti-cheat。

第三，SWE-Together 补上了过去 benchmark 缺的一块：真实用户不是一次性把需求说完，而会追问、纠偏、追加约束；因此 trajectory 不能只存最终 patch，还要存每一次用户意图更新、模型行动、工具结果和 verifier 反馈。

1. 三个 benchmark 分别在测什么

先把边界理清楚。它们名字都带 SWE，但关注点其实不同。

这里要特别小心版本漂移。SWE-Marathon 的论文数字、官网 leaderboard、GitHub main 和 Hugging Face 快照已经有差异；FrontierSWE 当前也没有论文，应该引用 Proximal blog 和仓库；SWE-Together 的可运行任务目录和 Hugging Face 表格互相映射，但真正能跑的是 tasks/<task_id>/ 里的 Dockerfile、verifier 和 prompt。

这不是吹毛求疵。做训练数据时，task_id 还不够，必须把 task_version_id、repo commit、Docker image digest、harness commit、verifier 版本一起存下来。否则两条轨迹看起来来自同一个任务，实际评分逻辑已经变了。

2. 作者动机：为什么 SWE-bench 不够了

SWE-Marathon 的问题意识最直接：现有 coding benchmark 多是短 horizon。SWE-bench 很好，因为它来自真实 issue/PR，但它依然偏向“定位一个 bug，改一个 patch，跑测试”。真正的软件工程任务经常不是这样。你要先读系统、补 scaffold、做实验、修一堆边角、反复验证，最后还要知道什么时候提交。

论文里一个很有意思的结果是，长程 rollout 的 token 绝大多数不是模型新生成的答案，而是系统提示、历史工具输出和上下文回放。换句话说，成本烧在“保持工作状态”上，而不是烧在“想出一句神奇代码”上。这解释了为什么最高 token 使用量并不必然带来最高通过率：长程任务的瓶颈不是单次推理长度，而是工作循环质量。

FrontierSWE 的动机更像 capability probe。Proximal 的官方博客把矛头指向现有 benchmark 的任务尺度和评分方式：当 agent 已经开始做大规模 refactor、性能工程、安全研究、甚至从零搭系统时，用短任务和二值 resolved 很难区分 frontier model 之间的差异。它的任务数量更少，但每题都很重：implementation、performance、ML research 三类任务都要求专家级背景。

SWE-Together 则从另一个角度补洞：真实用户会话不是一条 instruction 到底。用户会问“为什么这样改”、会说“不是改依赖，是在这个 repo 里修”、会提醒“别 mock 太多，测真实路径”、会追加一个性能分析问题。传统 benchmark 把这些互动压扁成一个最终 patch，训练出来的 agent 就容易只会“闭门造车”，不会根据用户反馈改变轨迹。

所以三者合起来的核心动机是：

SWE-bench:   真实 issue → 可验证 patch
SWE-Marathon: 完整项目 → 长程施工与最终验收
FrontierSWE: 专家挑战 → 连续指标与高成本实验
SWE-Together: 真实会话 → 用户意图随时间更新

3. 任务类型与真实例子

下面这些例子都来自任务文件、verifier 或 reference patch，而不是只读 abstract。

3.1 SWE-Marathon：完整项目级任务

slack-clone 是一个很典型的“长程产品 + 分布式系统 + UI”任务。任务要求在 /app 里实现一个 Slack-like team chat system：三个 HTTP 节点分别监听 127.0.0.1:8000/8001/8002，还有一个 IRC gateway 在 :6667，并提供浏览器 UI。功能面包括注册登录、workspace、public/private channel、DM、message、thread、reaction、pin、file、search、user group、slash command、mention、read state 和 settings。

难点不只是功能多。所有 HTTP 节点和 IRC gateway 必须共享 per-channel dense sequence；WebSocket reconnect 到另一个节点后要能 replay；杀掉一个 HTTP node 后其他节点继续读写和推送；杀掉 cross-node broadcast component 后，系统还要在 5 秒内通过 SQLite fallback 保持 fan-out 和 dense seq。前端还要过 Playwright 和 Computer-Use UI rubric。当前 task.toml 里专家估时是 60 小时，agent 时间约 3 小时。

这个任务训练的不是“写一个聊天页面”，而是：

• 如何先搭可启动 skeleton，而不是沉迷局部模型；
• 如何把 API、持久化、实时推送、IRC、UI 分层推进；
• 如何在 chaos test 下维护一致性；
• 如何避免只通过 visible browser test，却在 hidden API/cluster test 上崩掉。

biofabric-rust-rewrite 是另一种长程：把 Java BioFabric 和 Network Alignment plugin 重写成 Rust library + CLI。skeleton 会编译，但大量函数是 todo!()；public API 不能乱改；可见和隐藏 parity tests 会比较 BIF/NOA/EDA、layout、analysis、alignment 等输出，要求接近 byte-level parity。任务 metadata 里专家估时 80 小时。

这类任务对训练 trajectory 很有价值，因为它逼 agent 学会“参考实现迁移”的纪律：先找 Java 行为真相，锁定 public API，逐模块实现，跑小 parity，再跑大 parity。成功不是一次 patch，而是很多微小语义对齐的累积。

parameter-golf 则提醒我们，SWE-Marathon 不是只有传统代码工程。它要求在 WikiText BPE-8K 数据上训练一个语言模型，最终提交 /workspace/train_gpt.py 和不超过 32MB 的压缩 checkpoint，held-out val_bpb < 0.983 才算过。任务涉及模型结构、训练 schedule、量化压缩、H100 时间预算和反作弊检查。它训练的是长程 ML engineering：实验设计、资源预算、checkpoint 管理和 final artifact contract。

3.2 FrontierSWE：专家级系统、性能与研究挑战

FrontierSWE 的 postgres-sqlite-wire-adapter 要求写一个 Zig 程序，用 SQLite 做底层存储，却在 PostgreSQL 18.3 客户端看来像真实 PostgreSQL server。单个二进制需要根据 argv[0] 扮演 postgres、initdb、pg_ctl。隐藏 verifier 会把它接进 PostgreSQL 官方 regression suite 和 TAP tests，还包括 startup packet、auth、simple query、prepared statement、transaction、catalog/introspection、Unix socket、CLI behavior、cluster lifecycle 等兼容面。

当前 verifier 里可以看到一个很硬的评分形态：source scan、Zig project、dependency、build、binary、hidden harness 任一硬失败都置零；如果能跑起来，则按 regression、TAP、compatibility tests 的整体通过率给分。这个任务几乎是“用 SQLite 写一个 PostgreSQL 影子”。它训练的不是单个 SQL feature，而是如何优先实现 public compatibility surface，尽早让 psql select 1 和 pg_ctl start/stop 跑通，再逐步扩大 SQL/catalog 覆盖。

revideo-perf-opt 是性能工程任务。Revideo 是 TypeScript 视频生成框架，渲染链路包括 Puppeteer/Chrome、Vite、Canvas、WebSocket、FFmpeg。instruction 明确提示可能瓶颈：canvas.toBlob()、browser-node round trip、FFmpeg WebSocket bridge、视频 decode/encode 路径。agent 可以改任意 package、用 WebCodecs/WASM/muxer，但不能改变视觉输出、跳帧、降质或改 API。

verifier 先重建 candidate，再用 hidden scenes 跑 baseline 和 candidate，比较 SSIM/时长等 correctness，只有所有 hidden scenes 正确，才把几何平均 speedup 作为 reward。这个 scoring 特别关键：性能类 trajectory 不能只记录“快了”，必须记录 correctness gate 是否仍然全过。否则模型会学会危险的“快但错”。

pcqm4mv2-autoresearch 是 ML research 任务。agent 要在 closed-data、2D-only、no conformer、no external checkpoint 的约束下做 molecular graph regression，参数上限 50M，最终只允许 /app/submission/ 和 /app/checkpoint/ 里的内容参与 verifier-time inference。hidden test 与 visible dev 分离，要求 predict.py --count-params、--input-path、--output-path contract 都正确。

它训练的是“可执行研究”而非论文摘要：看数据 schema、设计 pipeline、跑实验、读 dev MAE、保留最好 checkpoint、控制参数量、保证最终提交最小且可加载。很多 agent 的失败不在模型结构，而在最后 artifact contract：checkpoint 放错、predict 依赖散落、hidden 输入假设错。

3.3 SWE-Together：真实多轮用户会话

SWE-Together 的一个短 bugfix 例子是 comfyui-triton-windows-amd-fix。初始用户消息是 Windows + AMD GPU 下 Triton 编译报错，指向 ComfyUI-WanVideoWrapper/ultravico/sageattn/attn_qk_int8_per_block.py。reference patch 很小：把循环里的 tl.load(K_scale_ptr) 改成基于稳定 base pointer 的 indexed load，并删除 K_scale_ptr += 1。但任务不是“猜这两行”。用户模拟器会在 agent 没解释编辑时问“Why is this modification needed?”，在 agent 偏去修 Triton C++ 后问“如何在这个 repo 里修，而不是改 Triton kernel？”

这说明 SWE-Together 的任务粒度不是 patch LOC，而是交互行为：agent 要懂用户在限制 scope、要求解释、纠正错误方向。canonical goals 里也把“不要改外部依赖、不要 silent edit、要解释原因”列为评分目标，而不仅是代码 shape。

另一个更长例子是 qwen3-moe-gguf-dequant。初始要求是修 dequantize_blocks_IQ3_XXS，并参考 llama.cpp 的 gguf-py/gguf/quants.py。后续任务实际上扩展到实现多种 IQ dequant：IQ3_S、IQ1_S、IQ2_S、IQ2_XXS、IQ1_M 等，要求用 PyTorch elemental operations 对齐 reference。用户模拟器的条件包括：如果 agent 过度折腾 PYTHONPATH，提醒“直接在当前目录跑 python test_gguf_dequant.py”；如果还用 F.embedding，要求换成 elemental torch ops；如果 IQ1_S 性能看起来慢，追问瓶颈是不是 dequant 代码。

这类 trajectory 对训练尤其有用，因为它展示了长程会话里的细粒度能力：测试协议服从、实现多个相似但不相同的 bit layout、解释性能现象、判断瓶颈在 test-side quantization 还是自己代码。

第三个例子 pi-mono-parallel-tool-stall 更接近 harness/debug 任务。初始要求是调查 parallel tool execution 和 interactive tools stall，不要实现，只产出 memo。但真实会话逐步推进到“先加 failing test”“不要 interactive metadata”“不要 throw，让它们 sequential”“测试要用真实代码路径，不要 mock/recreate 太多”“两个 submission 都要完成或至少尝试”。reference patch 最终是在 SDK 创建 session 时设置 toolExecution: "sequential"，并加了一个真实 session wiring 的 Vitest。

这个例子很漂亮地说明：长程软件工程任务的目标会在对话中变化。turn 0 说“不要实现”，但用户后面明确要求写 failing test 和修复；如果 harness 只保存初始 instruction，不保存用户纠偏，就会误判正确行为。

4. 任务是如何构造的

三个 benchmark 的构造方式可以抽象成同一套“可执行任务资产”：

instruction.md
task metadata: timeout / CPU / GPU / memory / network / image
environment: Dockerfile / pinned repo commit / mounted data
visible feedback: smoke tests / dev benchmark / public examples
hidden verifier: tests/test.sh / compute_reward.py / judge rubric
reference patch or oracle
anti-cheat: source scan / dependency scan / hash / hidden asset isolation
trajectory capture: agent logs / tool calls / verifier metrics / final workspace

SWE-Marathon 是人工 authored project tasks。贡献者需要给 objective、Docker、visible checks、hidden verifier、oracle、专家估时、资源需求和 reward-hack 风险。任务要通过 proposal review、CI、oracle run、NOP run、frontier-agent pilot、人工读日志、adversarial cheating agent 等环节。它的 CONTRIBUTING.md 把目录固定为 tasks/<slug>/instruction.md、task.toml、environment/Dockerfile、solution/solve.sh、tests/test.sh。

FrontierSWE 官方披露没有那么像论文 pipeline，但仓库结构能看出实际做法：每个任务有 instruction.md、task.toml、Docker image、hidden verifier、compute_reward.py、可选 solution/ 和 oracle.yaml。评分不是统一二值，而是按任务族定义：implementation 看测试通过率，performance 先过 correctness 再算 speedup，ML research 看 held-out metric。

SWE-Together 的构造则围绕真实 user-agent session。每行数据包含 instruction、repo、base commit、scoring targets、reference patch、user intents、docker image、task id。每个 tasks/<task_id>/ 目录里有 instruction、user simulation prompt、Dockerfile、tests/verifier、reference patch 和 frozen judge rubric。它的关键创新是 progressive reveal：agent 先得到 turn 0，之后 user simulator 根据原始会话里的触发条件发问、纠偏或保持沉默。

如果我们自己要实践，我会按这个顺序做：

1. 先选真实任务，不要先写 benchmark。来源可以是内部 backlog、性能瓶颈、迁移需求、真实用户 debug 会话、研究实验目标。
2. 固定 repo commit、数据版本、Docker digest、工具链版本和网络策略。
3. 写 outcome-oriented instruction，只告诉 agent 目标、约束、接口和 visible feedback，不泄漏 hidden verifier。
4. 做最小 visible smoke test，让 agent 能确认方向，但不要让 visible test 等于 final hidden set。
5. 先写 oracle/reference solution，再跑 NOP baseline。oracle 必须过，NOP 必须低分。
6. 设计 task-specific reward，而不是偷懒统一 pass/fail。性能任务要 correctness gate；ML 任务要 held-out；产品任务要 API + UI + resilience。
7. 加 anti-cheat：隐藏资产结束后才挂载；source/dependency scan；禁止读 /tests、/baseline；hash 检查；外网 allowlist。
8. 跑 3-5 个 frontier-agent pilot，人工读失败日志，区分“任务歧义”与“模型能力失败”。
9. 冻结 task version，把所有 rollout 都绑定 task_hash + verifier_hash + harness_hash。
10. 最后才大规模采 trajectory。

这里的一个原则是：先让任务成为可靠评测，再让它成为训练数据。如果 oracle 不能稳定通过，或者 NOP 也有高分，这个任务不适合训练。

5. Trajectory 到底应该保存什么

长程 trajectory 不是聊天记录。真正有训练价值的是状态转移：

{
  "task_id": "revideo-perf-opt",
  "task_version": "...",
  "harness": "claude-code",
  "state": {
    "changed_files": ["packages/core/src/exporter/..."],
    "best_score_so_far": 1.42,
    "known_failures": ["hidden correctness unknown"],
    "remaining_budget_sec": 18300
  },
  "model_action": {
    "kind": "run_benchmark",
    "command": "node benchmark.mjs"
  },
  "observation": {
    "correctness": "public_pass",
    "speedup": 1.18,
    "stderr_tail": "..."
  },
  "decision_label": {
    "outcome": "keep_experiment",
    "reason": "improved public speed without visible parity regression"
  }
}

最低限度要保存这些字段：

SWE-Marathon 的全量 raw logs README 说约 320GB，但目前需要向作者申请 S3 credentials；官网压缩 trajectory JSON 可以匿名看，不过 schema 更像展示用摘要，常见结构是 trial 加 rows[{step, call, kind, title, detail}]，不是完整可 replay 的 ATIF。FrontierSWE 当前公开仓库没有 raw trial dataset，但 Claude Code adapter 会把 sessions/**/*.jsonl 转成 /logs/agent/trajectory.json。SWE-Together 则把可运行任务、用户模拟 prompt、reference patch 和 frozen goals 公开得更完整。

一个重要判断：不要把“最终通过”直接当整条轨迹正样本。长程轨迹里有很多失败动作、误读、重复、reward hacking、自动重试、harness 托举。成功 trial 里也可能有很多不该学的片段；失败 trial 里也可能有非常好的局部诊断。蒸馏应该切 episode，而不是整条吞。

6. Trajectory 怎么蒸馏

我会把蒸馏拆成四种数据，而不是只做一种 SFT。

第一种是 action SFT。输入是 task + 当前 durable state + 最近 observation，目标是下一步高质量行动。例如：

状态：Pyright public diagnostics parity 全过，但 hidden 未知；ABBA timing 显示 union stress 慢。
好动作：保存当前 checkpoint，profile union narrowing path，做小范围缓存实验。
坏动作：直接提交，或重构整个 type evaluator。

第二种是 state compression。长程 agent 最容易死在上下文污染和记忆漂移。要训练模型把几小时轨迹压成结构化状态：

{
  "goal": "implement PostgreSQL wire-compatible adapter on SQLite",
  "working": ["initdb creates cluster dir", "TCP startup/auth works", "select 1 works"],
  "failing": ["prepared statement Describe returns wrong RowDescription"],
  "changed_files": ["src/main.zig", "src/protocol.zig"],
  "next": "add minimal Parse/Bind/Describe/Execute support and run psql prepared query smoke"
}

第三种是 verifier critic。很多训练样本应该不是“下一步代码”，而是“解释失败并选择验证”。例如 Revideo 任务里，speedup 提高但 SSIM fail，critic 要学会这是不可接受的，不是“部分成功”；Slack clone 里 WebSocket fan-out pass 但 Redis kill 后 seq gap，critic 要定位到 fallback path，而不是继续美化 UI。

第四种是 stop/continue policy。长程任务最贵的错误之一是过早提交或反复提交。SWE-Marathon 的失败模式里有 premature termination，官网失败轨迹也能看到连续 Submit 后又返工。训练时应该构造偏好：

完整 gate 通过 + hidden-like smoke 稳定 + best checkpoint 已恢复 > 自称完成但未跑完整验证
中途最佳 checkpoint > 最终冒险改坏版本
明确回滚 > 在失败实验上继续堆补丁

训练配方上可以这样分：

还有几个过滤原则：

• oracle/solve.sh 不能当普通 agent 解题数据；
• anti-cheat 失败、verifier tampering、环境异常要剔除或单独标注；
• is_copied_context、自动补跑、harness 自动恢复不能当模型功劳；
• tool definitions 和 harness 行为要随样本保存，否则模型学到的是某个框架习惯；
• 公开 benchmark 的 trajectory 不能训练后又回到同一 benchmark 报无污染结果。

7. 怎么 hack 进 Claude Code / harness

这里有两条路：不换模型，只增强 harness；或者把自训模型接进 Claude Code。

7.1 不换模型：把长程策略做成 harness 能力

这条最稳。你可以把蒸馏出的通用策略写进 CLAUDE.md、skill、MCP 或 wrapper：

• 每个任务创建 acceptance_ledger.md：目标、约束、visible tests、hidden-like risks；
• 每次重要编辑前保存 checkpoint；
• 每次实验写假设、命令、结果、是否保留；
• 自动维护 best-so-far，而不是默认提交 current workspace；
• 提交前强制跑 full gate 或 task-specific final checklist；
• 剩余时间低于阈值时停止大重构，恢复 best checkpoint；
• 对 repeated failures 触发“换诊断路径”，不是继续同一 patch。

这种方式训练的是 agent system，而不是裸模型。它的好处是马上可用；坏处是训练信号会被 harness 污染，所以采 trajectory 时必须标清“这一步是模型自己决定的，还是 wrapper 自动做的”。

7.2 换模型：让 Claude Code 调 Anthropic-compatible student

Claude Code 本身期待 Anthropic Messages / streaming / tool use 语义。FrontierSWE 和 SWE-Marathon 的 Harbor adapter 已经展示了可行路径：用 ANTHROPIC_BASE_URL、ANTHROPIC_MODEL、ANTHROPIC_DEFAULT_*_MODEL、CLAUDE_CODE_SUBAGENT_MODEL 把 Claude Code 指到 DeepSeek、GLM 或其他 Anthropic-compatible endpoint。

实践上大概是：

export ANTHROPIC_BASE_URL="https://your-anthropic-compatible-gateway"
export ANTHROPIC_API_KEY="..."
export ANTHROPIC_MODEL="your-long-horizon-student"
export ANTHROPIC_DEFAULT_OPUS_MODEL="your-long-horizon-student"
export ANTHROPIC_DEFAULT_SONNET_MODEL="your-long-horizon-student"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="your-long-horizon-student"
export CLAUDE_CODE_SUBAGENT_MODEL="your-long-horizon-student"

然后用 Claude Code/Harbor 正常跑任务，保留 --output-format=stream-json 和 session JSONL，再转成 ATIF trajectory。关键前提是你的 gateway 真正兼容 Claude Code 所需的 streaming、tool call、error、long-session 行为。只提供 OpenAI /chat/completions 的 vLLM endpoint 通常不够，需要一个 Anthropic translation layer。

如果目标是严肃训练自有模型，而不是借 Claude Code UI，那么更干净的方案是写自定义 Harbor agent：直接调用你的模型，暴露同样的 bash/edit/read/test 工具，输出 ATIF，顺便保存 token ids、mask ids、logprobs。这样才能做真正 on-policy RL。Claude Code 历史轨迹更适合 SFT/preference bootstrapping，不适合直接当 policy-gradient rollout。

7.3 Harness 接入时最该记录的事件

我会在 harness 里加一层语义事件，而不是只存原始 stdout：

{
  "event": "verification_failed",
  "scope": "correctness_gate",
  "command": "bash tests/test.sh",
  "component": "redis_fallback_seq_dense",
  "model_next_action": "inspect channel_events poller",
  "outcome": "recovered_after_two_edits"
}

特别要把以下事件标准化：

• checkpoint_saved
• best_checkpoint_updated
• experiment_regressed
• rollback_performed
• verification_skipped
• hidden_like_risk_identified
• user_correction_received
• scope_violation_detected
• harness_auto_retry
• final_submit

这些事件才是长程训练里的“骨架”。如果没有它们，trajectory 就只是一大坨 bash 和 diff。

8. 评测和反作弊：别把训练集做成答案库

长程 SWE 数据最危险的地方，是它天然包含答案、测试、hidden behavior 和模型探测 verifier 的痕迹。SWE-Marathon 的 HF 卡就提醒过 decontamination；SWE-Together 的 user simulator 也明确要求不能泄漏 fix 变量名、代码模式或行号。

一个可接受的训练/评测隔离应该至少包括：

1. 训练任务池和评测任务池按 repo、task family、verifier asset 严格分开；
2. 公开 benchmark 的 solution/trajectory 只能用于方法研究，不用于同 benchmark 提分后报告；
3. hidden tests 永不进入 prompt、SFT target 或 retrieval memory；
4. 任务文件里加 canary，并在训练语料里扫描；
5. 训练数据保留许可证和来源；
6. 任何用过 public trajectory 的模型，评测时标注 contamination risk；
7. agent 运行期禁用搜索答案、git checkout known solution、读取 /tests 或 /baseline；
8. verifier 记录 source scan、dependency scan、hash、network、file read traces。

尤其是 performance 和 ML research 任务，reward hacking 很自然：跳帧、降质、偷看 labels、缓存 hidden 输入、改 benchmark、伪造 loss。任务构造时要先设计作弊方案，再设计 anti-cheat，不要等 leaderboard 出现异常再补洞。

9. 结论：长程能力训练的真正对象

这三组 benchmark 共同说明了一件事：训练模型做长程软件工程，不是把 SWE-bench patch 变长，也不是把 context window 拉到几百万 token。真正要训练的是一组工程习惯：

• 读清 acceptance criteria；
• 建立可运行 baseline；
• 小步实现；
• 用测试和 benchmark 反馈更新状态；
• 保存 best checkpoint；
• 能解释失败；
• 能听用户纠偏；
• 知道何时回滚、何时继续、何时提交。

SWE-Marathon 给了完整项目施工的舞台；FrontierSWE 把舞台推到专家级系统和研究任务；SWE-Together 把真实用户重新放回 loop 里。它们的共同启发是：未来有价值的 Agent 数据，不会只是“prompt → patch”，而会是：

可执行任务 + 真实环境 + 分阶段反馈 + 用户纠偏 + 状态快照 + 验证指标 + 可归因轨迹

训练长程能力，归根到底是在训练模型成为一个可靠的工程过程参与者。模型当然要会写代码，但更要会维护一个还没结束的现实。

参考链接

• SWE-Marathon paper: arXiv 2606.07682
• SWE-Marathon GitHub
• SWE-Marathon website and trajectory viewer
• SWE-Marathon slack-clone task
• SWE-Marathon biofabric-rust-rewrite task
• SWE-Marathon parameter-golf task
• FrontierSWE website
• FrontierSWE official blog
• FrontierSWE GitHub
• FrontierSWE scoring notes
• SWE-Together paper: arXiv 2606.29957
• SWE-Together GitHub
• SWE-Together Hugging Face dataset
• Harbor trajectory format RFC