<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Trajectory - 标签 - lilfry's library</title><link>https://lilfry09.github.io/tags/trajectory/</link><description>Trajectory - 标签 - lilfry's library</description><generator>Hugo -- gohugo.io</generator><language>zh-CN</language><managingEditor>lilfry@sjtu.edu.cn (lilfry)</managingEditor><webMaster>lilfry@sjtu.edu.cn (lilfry)</webMaster><copyright>All rights reserved.</copyright><lastBuildDate>Mon, 20 Jul 2026 21:30:00 +0800</lastBuildDate><atom:link href="https://lilfry09.github.io/tags/trajectory/" rel="self" type="application/rss+xml"/><item><title>训练模型的长程软件工程能力：从 SWE-Marathon 到 FrontierSWE 与 SWE-Together</title><link>https://lilfry09.github.io/ai/long-horizon-swe-agent-training/</link><pubDate>Mon, 20 Jul 2026 21:30:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/long-horizon-swe-agent-training/</guid><description><![CDATA[<p>如果要训练模型做长程软件工程任务，最容易走错的一步，是把“长程能力”理解成“更长上下文 + 更多 token”。SWE-Marathon、FrontierSWE 和 SWE-Together 这三组工作放在一起看，会给出一个更锋利的答案：长程能力不是文本长度，而是 <strong>在一个可执行环境里，持续维护目标、状态、证据、风险和验证闭环</strong>。</p>
<p>SWE-bench 把真实 GitHub issue 变成了可评分 patch，这是很重要的一步。但它主要回答“模型能不能修一个相对局部的问题”。现在这三组新 benchmark 关心的是另一件事：模型能不能像一个还算可靠的工程师那样，连续几个小时推进一个项目，把中途实验、失败、回滚、测试、用户纠偏、最终提交都组织起来。</p>]]></description></item></channel></rss>