论文

Socratic-SWE: 通过轨迹导出的代理技能实现自我进化的编码代理

Socratic-SWE: 通过轨迹导出的代理技能实现自我进化的编码代理

LLM驱动的软件工程代理已成为评估语言模型真实能力的关键测试平台,但其训练受限于高质量SWE任务的可用性。现有合成数据方法通常通过固定突变或缺陷注入流程生成任务,导致任务分布与代理自身的弱点和训练进度无关。 我们提出Socratic-SWE,一个闭环自我进化框架,将代理的历史解决轨迹重新用作训练信号源。Socratic-SWE不仅将轨迹视为奖励计算的证据,还将其提炼为结构化的代理技能,总结重复出现的失败和有效修复模式。这些技能指导在真实仓库中生成有针对性的修复任务。候选任务通过基于执行的验证进行检查,并依据求解器梯度对齐奖励评分,确保保留的任务既可验证又有助于改进求解器。 更新后的求解器产生新轨迹,使得任务课程能够随着迭代轮次自适应调整。在SWE-bench Verified、SWE-bench Lite、SWE-bench Pro和Terminal-Bench 2.0上,Socratic-SWE在相同计算预算下持续优于自我进化基线,经过三次迭代后在SWE-bench Verified上达到50.40%。结果表明,解决轨迹可以作为自我进化SWE代理的可扩展基础。

论文精读

TL;DR Socratic-SWE 闭环自演进框架:从智能体求解轨迹中提炼结构化技能,指导生成针对性修复任务,让代码智能体在迭代中自我提升,在 SWE-bench Verified 上达到 50.40%。

问题

问题背景

当前,LLM 驱动的软件工程智能体 (SWE agent) 已成为评估语言模型现实世界编程能力的核心测试平台。这类智能体需要在真实代码仓库中理解 issue、定位错误并生成修复补丁,但其训练高度依赖高质量的任务数据,而真实世界 bug 修复数据的规模与多样性远远不足。

现有方法局限

主流合成数据方法通过固定变异 (如代码行交换、变量重命名) 或预定义 bug 模板注入错误来生成训练任务。这些策略存在两个根本性缺陷:

  • 与智能体弱点脱节:生成的任务分布独立于智能体自身的失败模式,无法针对其频繁出错的环节提供强化训练。
  • 缺乏课程适应性:在整个训练周期内,任务难度与类型保持不变,无法跟随智能体能力提升而动态演进,导致低效的“盲训”。 换言之,传统方法无法形成“从错误中学习”的闭环,智能体可能反复陷入同类陷阱,而合成数据却无法提供针对性纠正信号。

为什么这个问题难且重要

核心技术挑战在于:如何从智能体多轮求解轨迹 (traces) 中自动提炼出结构化的技能描述 (如常见错误模式与有效修复策略),并利用这些技能逆向指导生成新的、可执行且上下文兼容的修复任务。这不仅要求轨迹提炼过程足够泛化,更要求生成的任务能通过执行验证且其训练梯度与智能体性能提升方向一致。业界高度关注这一方向,因为 SWE-bench Verified 等基准已成为衡量 LLM 智能体工程能力的黄金标准,具备自我进化能力的智能体将大幅降低对人类标注 bug 修复数据的依赖,是迈向自主 AI 软件工程师的关键一步。

行业类比

这一思路类似自动驾驶中的场景库迭代闭环:通过采集车辆在实际路测中暴露的失败场景,自动生成针对性仿真任务,定向提升感知模型在长尾案例上的鲁棒性,而非依赖随机路况生成。

核心洞察

  • 将智能体的历史求解轨迹提炼为结构化的“代理技能”(agent skills),这不同于以往仅用轨迹作为奖励信号的方法,而是直接提取可复用的失败模式与修复模式,指导针对性任务生成,形成与智能体弱点紧密耦合的训练数据分布。
  • 闭环自进化框架通过执行验证和 solver-gradient 对齐奖励,确保生成的任务既能被验证又能直接提升求解器性能,避免合成数据与智能体当前能力脱节,从而实现随着迭代不断调整难度的课程学习。
  • 整个流程在真实仓库中生成修复任务,并利用重构过程中的测试来保证可验证性,使得自进化训练的数据都来自实际工程上下文,提升了 agent 在 SWE-bench 等真实基准上的泛化能力。

方法

核心流程:轨迹驱动的闭环自进化

Socratic-SWE 将智能体历次解决问题的轨迹(含成功修复与失败尝试)作为训练信号,形成“求解→提炼→生成→验证→更新”的闭环。

输入

  • 真实代码仓库及历史 issue/pull request 描述;
  • 当前 SolverSWE-bench 等基准上的求解轨迹(包括执行日志、生成补丁与最终是否通过验证的信息)。

关键模块

  1. 技能蒸馏(Skill Distillation)
    从轨迹中抽取两类结构化技能:

    • 失败模式:归纳反复出现的错误类型(如缺失 import、错误修复范围);
    • 修复范式:提炼成功案例中的通用修复策略(如添加空指针检查、调整函数参数)。 这些技能以自然语言形式保存,不依赖固定模板。
  2. 任务生成(Task Generation)
    利用上述技能,指导一个生成器在真实仓库中构造新的修复任务。例如,针对“错误范围识别不准”的技能,生成器会选取合适文件裁剪出需要返回中间结果但当前代码不返回的场景,形成可执行验证的 task 描述。

  3. 验证与筛选(Execution-Based Validation & Solver-Gradient Alignment Reward)
    候选任务先在隔离环境中运行验证其可检查性(即存在客观通过/失败条件),再通过 Solver-Gradient Alignment Reward 评分:该奖励度量任务对 Solver 参数更新的潜在帮助程度,保留能最大程度降低后续 Solver 损失的任务。

  4. Solver 更新
    将筛选后的任务混入训练集,对 Solver 做一轮微调(或强化学习)。更新后的 Solver 在新的基准实例上产生新轨迹,返回步骤 1,实现任务课程的自适应演化。

输出:迭代提升的 Solver 代理。经过三轮迭代,在 SWE-bench Verified 上达到 50.40% 正确率,显著超越同等算力下固定任务生成的自进化基线。

差异点:与传统固定变异或错误注入的合成方法不同,Socratic-SWE 直接从智能体自身弱点的轨迹中动态构建任务课程,使生成数据与 solver 当前状态强对齐,实现真正的数据闭环自进化。

实验

实验设计

Socratic-SWE 采用闭环自进化框架,基于历史解决轨迹生成有针对性的修复任务。实验选取 SWE-bench VerifiedSWE-bench LiteSWE-bench ProTerminal-Bench 2.0 四个基准,所有对比均在同等计算预算下进行。每轮迭代包含四个阶段:

  1. 技能提取:从 Solver 的历史轨迹中蒸馏出结构化的 agent skills,捕捉重复失败模式与有效修复策略。
  2. 任务生成:利用提取的技能在真实仓库中诱导生成修复任务。
  3. 验证与筛选:通过执行验证和 solver-gradient alignment reward 评估任务质量与对 Solver 改进的潜在贡献。
  4. 再训练:用筛选后的任务更新 Solver,产生新轨迹,驱动课程自适应。

实验设计的关键在于任务分布随 Solver 能力动态调整,避免固定变异或缺陷注入导致的数据分布与 agent 弱点脱节。

关键发现

  • 三轮迭代后,Socratic-SWE 在 SWE-bench Verified 上达到 50.40% 的解析率,显著优于仅使用相同计算资源的自进化基线。
  • 轨迹衍生技能能够有效概括可复用的修复模式,例如处理类型错误、依赖缺失或多文件协同修改,这些模式在常规合成数据中难以显式编码。
  • 引入 solver-gradient alignment 奖励后,筛选出的任务不仅执行正确,而且对 Solver 能力提升更有帮助,避免浪费训练预算在过于简单或噪声过大的任务上。
  • 在四个基准上的稳定提升表明,该方法对任务难度和仓库类型具有较好泛化性,尤其在长程编辑和多步推理场景优势更明显。

与基线对比的深度解读

相比基于固定变异或 bug 注入的合成数据方法,Socratic-SWE 的核心差异在于数据生成与 agent 当前能力直接挂钩,形成类似课程学习的自适应过程。基线方法生成的任务往往与 agent 的薄弱环节无关,导致训练效率低下。而 Socratic-SWE 通过重用求解轨迹,将 agent 的失败经验转化为针对性的训练信号,每一轮迭代都能有效修补能力短板。同时,execution-based 验证保证了任务的可解性,solver-gradient alignment 奖励则使课程朝着对模型改进最有利的方向演进。在同等算力下,这种闭环设计实现了更高效的数据利用和更快的性能爬升,为构建自我进化的软件工程 agent 提供了可扩展的范式。

行业影响

落地场景

Socratic-SWE 的核心能力是从历史求解轨迹中提炼技能,并生成有针对性的代码修复任务,适用于所有需要自动化软件工程的业务线。典型场景包括:

  • 持续集成/持续部署(CI/CD)流水线:自动处理 issuebug report,生成经过执行验证的补丁,减少人工介入。
  • 代码托管平台(如 GitHub、GitLab):作为机器人服务,对开源或私有仓库的提交进行自动修复建议,提升代码合并效率。
  • 企业级开发者工具:集成到 IDE 或代码助手(如 Copilot)中,利用历史修复模式预测并修复类似错误。

商业价值

  • 降本:大幅缩短 Bug 修复周期,减少高级开发者的调试时间;对于频繁发版的产品,可降低紧急修复带来的机会成本。
  • 增收:通过加速软件交付,直接提升产品迭代速度和市场响应能力,尤其对电商大促活动、金融服务高频交易系统等稳定性要求高的场景,可避免因代码缺陷导致的收入损失。
  • 体验提升:开发者体验(DX)优化——自动生成可验证的修复方案,让工程师聚焦复杂设计,同时提升代码库的长期可维护性。

与现有产品 / 工作流的接口

Socratic-SWE 以求解器-技能生成器双组件形式嵌入,对外暴露轻量 API:

  1. 与代码仓库集成:通过 webhook 监听新的 issue 或失败 CI 事件,触发求解器生成修复候选,验证后自动创建 pull request
  2. 与现有评测/测试框架集成:复用执行环境(如 Docker)和测试套件,技能生成器从日志和 diff 中提取结构化技能,反馈到任务生成器。
  3. 与工作流编排工具(如 Airflow、Temporal)结合,形成迭代自进化闭环。

具体落地 Use Case

  • 电商后端服务修复:某电商平台在促销期间接口响应超时,Socratic-SWE 可从历史 timeout 相关的 trace 中提取“增加重试逻辑”或“异步化”技能,生成并验证修复任务,将平均修复时间从小时级降至分钟级。
  • 金融交易系统可靠性增强:对高频交易系统的历史故障 trace 进行自进化训练,持续生成针对边界条件和并发冲突的验证补丁,避免人工排查在多线程环境下的隐蔽缺陷,保障交易链路 99.99% 可用性。

局限

  • **对初始轨迹质量的强依赖**。Socratic-SWE 的核心是从历史求解轨迹中提炼 **agent skills**,若初始 Solver 能力较弱,生成的轨迹会包含大量错误模式或低质量修复,导致提炼出的技能偏差、生成的任务噪声较大,闭环可能陷入局部最优或进化缓慢。论文未深入探讨冷启动策略,当可用的高质量轨迹不足时,框架的有效性可能骤降。这一局限在现实部署中尤为关键,因为初始模型往往离专家水平较远,需要额外的数据或启发式规则来保证早期轨迹的可靠性。
  • **合成任务的覆盖范围受限**。任务生成依赖从已有仓库错误修复中总结的模式,可能偏向高频、可复现的故障类型,难以覆盖长尾、跨模块或需要深层语义理解的错误。执行验证只保证任务的可解性,但无法评估任务的**真实度**和**多样性**,长期进化可能导致 Solver 过拟合于特定缺陷类型,对外部真实世界的故障泛化能力下降。跟直接使用真实世界代码更改记录的方法相比,合成数据固有的分布偏移风险仍然存在,论文未提供对生成任务多样性的定量分析。
论文Chuan Xiao2026-06-05原文

相关内容