门户首页
教学网站 · 专题模块 · 专题 02

从 SWE-agent 到 mini-swe-agent:以大模型能力跃迁为棱镜的架构演进调研报告

2024 年的 SWE-agent 用数千行代码证明「接口设计至关重要」,14 个月后同一团队的 mini-swe-agent 用约 100 行代码证明「大部分接口设计已不重要」——本页以这一对系统为棱镜,完整呈现调研报告十章内容:Agent 架构中哪些复杂度是模型能力的函数,哪些是任务本身的固有复杂度。

生成时间:2026-09-16 · 版本 v0.2 · 生成 Agent:TraeWork (LLM: Kimi-K3) · 载体:agentsoft-research-platform teaching-web-platform

概览

14
个月演进跨度(2024.05 → 2025.07)
2
个对照系统(SWE-agent / mini-swe-agent)
10
章正文(缘起 → 总结)
38
条来源(附录 B 全量收录于页脚)
本章导览
章标题这一章回答什么
一研究缘起与核心命题同一团队为何在 14 个月内给出两个看似矛盾的结论?它们指向什么深层命题?
二SWE-agent 的设计哲学2024 年的「驾驶舱」如何为弱模型量身定制?每个组件贡献多少性能(9 行消融表)?
三mini-swe-agent 的设计哲学约 100 行代码裁剪了什么、保留了什么?v1 → v2 为何重新拥抱 tool-calling?
四模型能力跃迁的时间线2024.05 → 2026.06 的能力轨迹如何分阶段?厂商自报与统一脚手架两种口径为何不可混用?
五架构对比四维度工具集 / 上下文管理 / 执行引擎 / 模板配置四个维度上,复杂度如何逐项迁移?
六机制归因模型变强后为什么可以「裸奔」?三条核心机制与能力迁移的非均匀性。
七性能-成本-复杂度三角解决率升至 76.8% 的同时成本为何降至 $0.07?三角关系如何动态平衡?
八后续演进与 2026 格局从 mini 出发的三条路线:运行时自我演化 / RL 训练底座 / 评测基础设施;Bash Only 子榜格局。
九前瞻研判复杂度下沉的极限在哪里?短期 / 中期 / 长期趋势与对可靠性研究的启示。
十总结核心规律:Agent 系统的架构复杂度,本质上是模型能力缺口的函数。

一、研究缘起与核心命题

一对张力十足的对照:数千行 vs 约 100 行,解决率却基本持平
2024 年论文证明「接口设计至关重要」,2025 年后续工作证明「大部分接口设计已经不重要」——两件事看似矛盾,实则指向同一个深层命题。
一 · 2024:SWE-agent 的鲜明主张

不动模型一个字节,只改接口,解决率相对提升约 64%

2024 年 5 月,普林斯顿大学与斯坦福大学的 SWE-bench 原班团队发表 arXiv:2405.15793《SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering》,后被 NeurIPS 2024 正式收录。 论文核心主张极其鲜明:同一个 GPT-4 Turbo,权重一字节不动,仅重新设计模型与代码仓库之间的交互接口,就能把 SWE-bench Lite 解决率从 11.00%(Shell-only 交互式基线)提升到 18.00%,相对提升约 64%。在完整的 SWE-bench Full 上取得 12.47%(286/2294)。

这意味着:在 Agent 系统的性能瓶颈中,Harness 层(包裹模型的外部运行时)的设计可能比模型本身更重要。论文为此提出 ACI(Agent-Computer Interface)专用工具集——窗口化文件查看器、带语法守卫的编辑器、结构化搜索工具、历史压缩链等一系列「保姆式」干预机制,目的只有一个:替模型做它做不好的事。

paper: arXiv:2405.15793(NeurIPS 2024) 数字:11.00% → 18.00%(Lite)/ 12.47%(Full)
一 · 2025:mini-swe-agent 的反转

约 100 行代码 + 裸 bash,解决率约 65%

仅仅 14 个月后,同一团队于 2025 年 7 月 25 日发布 mini-swe-agent。核心 Agent 类被压缩到约 100 行 Python 代码,只保留 bash 一个工具——没有专用文件查看器、没有编辑器、没有历史压缩、没有有状态 Shell 会话。它用 Claude Sonnet 4 在 SWE-bench Verified 上拿到约 65% 的解决率,与当时配置拉满的完整版 SWE-agent + Claude 4 Sonnet(66.60%,SWE-bench 官方榜单,2025-05-22)基本持平。

本报告的深层命题:2024 年用精密消融实验证明「接口设计至关重要」,2025 年用 100 行代码证明「大部分接口设计已经不重要」。两者共同指向——Agent 架构中哪些复杂度是模型能力的函数,哪些是任务本身的固有复杂度。本报告以这一对系统为棱镜,结合截至 2026 年 9 月的最新证据(mini v2 演进、官方 Bash Only 子榜、运行时自我演化脚手架登顶、Verified 退役与 Pro 审计反转),提炼前瞻性的架构演进规律。
对照:~100 行 vs 数千行,~65% vs 66.60% 发布:2025-07-25(Show HN / 官方文档)

二、SWE-agent 的设计哲学:为弱模型量身定制的「驾驶舱」

诊断 → 原则 → 组件 → 消融 → 假设
SWE-agent 的出发点是一个关键观察:Linux Shell 是给人用的,不是给 LLM 用的。本章拆解它如何用 ACI 四原则与四大组件替弱模型补短板。
二 · 问题诊断

通用 Shell 为何不适合 LLM:三重障碍

人类工程师使用 Shell 时,依赖视觉模式识别、空间记忆、跨窗口并行注意力、以及略读与选择性聚焦的能力;而 LLM 的认知架构根本不同——顺序 token 处理,对上下文顺序和格式高度敏感,工作记忆有限,且倾向于锚定在提示词中最突出的信息上。

障碍具体表现
命令粒度过细、选项过多sed、grep、awk 等命令选项繁多、文档冗长,模型难以正确调用
输出不可控一条 grep -r 可能返回上万行匹配结果,直接淹没上下文窗口,降低后续每一步的推理质量
无结构化反馈编辑文件后没有即时确认;命令无输出时,模型不知道该命令是否成功执行
诊断:认知架构差异 → 三重障碍
二 · ACI 四大设计原则

论文 §2 的四条设计原则

#原则含义
1动作应简单易懂每个命令仅 1–3 个参数,文档简洁,降低理解负担,减少对 demonstration 或微调的依赖
2动作应紧凑高效重要操作整合为尽可能少的动作,单步取得实质进展
3环境反馈应信息丰富但简洁反馈提供环境状态与动作效果的实质信息,避免不必要的细节
4防护机制缓解错误传播构建护栏(如语法检查器)阻止错误传播,帮助 agent 识别并快速纠正错误
出处:论文 §2(ACI 设计原则)
二 · 四大功能组件

工程实现:每个组件都针对一个具体失败模式

搜索与导航
  • find_file / search_file / search_dir 三个专用命令替代 ls + cd + grep 的多步组合
  • 关键在输出管理:每次搜索最多返回 50 条结果,超限则抑制输出并提示模型细化查询——把「上下文淹没」的失败模式转化为自然的精炼循环,迫使模型从模糊搜索走向精确查询
窗口化文件查看器
  • 有状态查看器,每次固定展示至多 100 行,附带文件路径、总行数与行号,配合 scroll_down / scroll_up / goto 导航
  • 网格搜索显示:100 行窗口(18.0%)优于 30 行窗口(14.3%,降 3.7 个百分点),更优于全文展示(12.7%,降 5.3 个百分点)——后者因 LLM 对长上下文中间部分的信息利用率呈 U 形曲线(「lost in the middle」效应),关键代码大概率被淹没
带 lint 守卫的文件编辑器
  • edit start:end 一步完成多行原子替换,编辑后查看器自动刷新到修改位置
  • 核心护栏:编辑先经 linter(如 flake8)检查,若引入语法错误则回滚编辑并把错误信息连同代码片段返回模型;无效编辑直接丢弃、要求重试——针对 LLM「反复编辑同一段代码」的典型失败模式
上下文管理器(History Processor 链)
  • 每轮发送给模型前对历史消息做过滤与压缩;核心处理器 LastNObservations 只保留最近 5 轮 observation 的完整内容,更早的观察折叠为单行占位
  • 另有标签系统(对编辑、测试等关键工具结果差异化保留)与正则清理器等处理器
组件:搜索 / 查看器 / 编辑器 / 历史压缩 出处:论文 §2–§3
二 · 消融实验(论文 Table 3)

量化每个组件的贡献:SWE-bench Lite,同一 GPT-4 Turbo

配置解决率相对基线变化
完整 SWE-agent18.0%—
去掉编辑守卫(edit w/o linting)15.0%↓ 3.0 个百分点
完全去掉编辑器(No edit)10.3%↓ 7.7 个百分点
全文展示(Full file,替代 100 行窗口)12.7%↓ 5.3 个百分点
窗口缩小到 30 行14.3%↓ 3.7 个百分点
迭代式搜索(Iterative search)12.0%↓ 6.0 个百分点
去掉搜索工具(No search)15.7%↓ 2.3 个百分点
全量历史(Full history,无压缩)15.0%↓ 3.0 个百分点
去掉演示轨迹(w/o demonstration)16.3%↓ 1.7 个百分点
这组数据的三条结论:其一,编辑器和文件查看器是性能贡献最大的两个组件;其二,「Full history ↓3.0」直接证明对 2024 年的模型不做上下文压缩要付出明确代价;其三,全文展示比窗口化差 5.3 个百分点,验证了「给模型更多信息不一定更好」的反直觉结论。
出处:论文 Table 3(SWE-bench Lite 消融) 最大贡献:编辑器 ↓7.7 / 迭代搜索 ↓6.0 / 窗口 ↓5.3
二 · 核心设计假设

一句话概括:为 2024 年初主流 LLM 的系统性缺陷做补偿

SWE-agent 的核心假设:2024 年初的主流 LLM(以 GPT-4 Turbo 为代表)在长上下文信息过滤、动作空间认知负荷、语法正确性与自我修正能力上存在系统性缺陷,因此需要 Harness 层在信息呈现、动作约束和错误拦截三个维度上做大量补偿。

这个假设有充分的实验支撑(论文 §5.2):搭载 GPT-4 Turbo 的 SWE-agent 在 2294 项任务中有 51.7%(1185 条)的交互轨迹存在至少 1 次失败的编辑;任意一次编辑操作最终成功的概率为 90.5%,但在一次编辑失败后,后续成功的概率会降至 57.2%——直接证明模型在代码编辑环节的脆弱性。

假设:三维度补偿(信息 / 动作 / 错误) 数据:51.7% 失败编辑 · 90.5% → 57.2%

三、mini-swe-agent 的设计哲学:把智能交还给模型

核心命题的反转:能力跨过阈值后,保姆式干预大多不再必要
mini-swe-agent 没有独立的 arXiv 论文,权威表述以官方文档与 NeurIPS 2024 论文的引用关系为准。它裁剪了什么、保留了什么,以及 v1 → v2 如何演进,是本章的三件事。
三 · v1 的五条核心原则

mini(v1)设计建立在五个核心原则之上

  • Bash-only 工具接口:没有任何 bash 以外的工具,甚至不使用模型的 tool-calling 接口(模型以特定格式输出 bash 命令,由 Harness 正则解析)
  • 线性历史透明性:每一步只是往消息列表后面追加,轨迹就是传给模型的消息历史本身
  • 无状态执行:每条命令通过 subprocess.run 独立执行,命令之间无隐式状态依赖
  • 极简沙箱化:把 subprocess.run 换成 docker exec 即完成隔离
  • 通用模型兼容:模型调用统一经 litellm 抽象层接入任意后端
五原则:bash-only · 线性历史 · 无状态 · 沙箱 · litellm
三 · 裁剪与保留

裁掉的是「补偿」,留下的是「骨架」

被裁剪的部分
  • 所有专用 ACI 工具(find_file、search_dir、窗口化查看器、edit + lint 守卫)→ 替换为裸 bash
  • History Processor 压缩链 → 替换为线性全量历史
  • 有状态 Shell 会话(SWE-ReX)→ 替换为 subprocess.run 独立子进程
  • Jinja2 模板族 + demonstrations → 替换为三个基础模板 + zero-shot
  • LangChain 依赖与复杂配置体系 → 替换为约 200 行可运行系统(官方口径:约 100 行核心 Agent + 约 100 行环境/模型/运行脚本合计),无重型依赖(模型层统一走 litellm,另有 pydantic、jinja2 等轻量依赖)
被保留的部分
  • 同构的 ReAct 主循环:「组装上下文 → 模型推理 → 解析动作 → 执行动作 → 观察回灌」的语义完全不变
  • 异常驱动的控制流:Submitted、LimitsExceeded、FormatError 等终止条件(v2 统一为 InterruptAgentFlow 异常体系)
  • 标准化的任务初始化与产出:隔离沙箱 + base commit checkout + patch 文件输出 + .traj 轨迹持久化
  • 提交机制:模型通过 echo COMPLETE_TASK_AND_SUBMIT_FINAL_OUTPUT 魔法字符串提交最终结果(v1 默认配置 mini.yaml 明确指示该命令)
裁剪:ACI 工具 / 压缩链 / 有状态 Shell / demos / LangChain 保留:ReAct 主循环 · 异常控制流 · 沙箱与轨迹
三 · 性能对标

同量级性能,数量级复杂度差

系统解决率(Verified)口径
SWE-agent + Claude 4 Sonnet(2025-05-22,配置拉满)66.60%SWE-bench 官方榜单
mini-swe-agent + Claude Sonnet 4(2025-07,极简架构)约 65%官方 README 与 Show HN

两者在解决率上基本持平,但 mini 的架构复杂度低了一个数量级。这个「同量级性能、数量级复杂度差」的事实,正是本报告核心命题的经验基础。

口径提醒:作为参照,Anthropic 发布 Claude 4 时用未公开的自研脚手架自报 Sonnet 4 为 72.7%——三方数字之间的差额本身就说明了脚手架口径对分数的影响,引用时必须注明口径。
结论:复杂度差一个数量级,性能持平
三 · v1 → v2 演进(2026-02-11)

mini 自己也在演进:「极简」不等于「拒绝现代接口」

  • 默认切换为原生 tool-calling:v2.0.0(官方称「自发布以来最大版本」)默认使用模型原生 tool-calling API(暴露一个 bash 工具),v1 的 regex 文本解析降级为可选配置(litellm_textbased 模型类 / swebench_backticks.yaml)
  • 架构重构:动作解析与 observation 格式化职责从 Agent 移到 Model,Agent 退化为简单协调器;配置从 dataclass 改为 Pydantic;异常体系统一为 InterruptAgentFlow
  • 体量增长:default.py 从 v1 的约 140 行增至 v2.x 的约 190 行(官网仍沿用 "The 100 line AI agent" 标语);当前最新版本 v2.4.6(2026-07-23)
这一演进对核心命题的微妙意义:v1 拒绝 tool-calling,是因为 2025 年中部分模型的格式遵循仍不可靠;v2 主动拥抱 tool-calling,是因为这个缺陷在新一代模型上已基本消失。Harness 的每一处设计都在随模型能力被重新定价——这正是「复杂度是模型能力缺口的函数」命题在 mini 自身演化上的二次验证。
v2.0.0:2026-02-11 · 最新 v2.4.6(2026-07-23) 演进:regex 解析 → 原生 tool-calling

四、模型能力跃迁的时间线:被 Harness 层追赶的移动靶

把架构变迁放回模型能力快速跃迁的时间线上考察
时间线严格区分厂商自报口径(各家用自己的脚手架跑分)与统一脚手架口径(SWE-bench 官方 Bash Only 子榜 / 榜单条目),两者不可混用。
四 · 能力跃迁关键里程碑

2024.05 → 2026.06:一条被两种口径标注的时间线

时间模型SWE-bench 成绩口径与来源
2024.05GPT-4 Turbo(128K 上下文)Full 12.47% / Lite 18.00%SWE-agent 论文,SWE-agent 脚手架
2024.10Claude 3.5 Sonnet 升级版(200K)Verified 49.0%(初版回溯补报 33.4%)Anthropic 官方,自研脚手架
2025.02Claude 3.7 Sonnet(首个混合推理模型)Verified 62.3%(高算力配置 70.3%)Anthropic model card,自研脚手架
2025.05Claude Sonnet 4(200K;8 月起 1M beta)Verified 72.7%Anthropic 官方,自研脚手架
2025.05Claude 4 SonnetVerified 66.60%官方榜单,SWE-agent 完整版
2025.07Claude Sonnet 4Verified ~65%mini-swe-agent v1
2025.09Claude Sonnet 4.5Verified 77.2%(高算力 82.0%)Anthropic 官方,自研脚手架
2026.02Claude Sonnet 4.6(2026-02-17)Verified 分数存疑(二手源 77.4%~79.6% 互相矛盾,未获官方一手确认)未确认
2026.04GPT-5.5(2026-04-23)Verified 82.6%(第三方复现)/ 85.1%(厂商自报)arXiv 2608.13675
2026.06Claude Sonnet 5(2026-06-30)Verified 分数存疑(二手源 85.2%~92.4% 互相矛盾,未获官方一手确认)未确认
口径警示:上表中 Anthropic 官方自报分数(49.0%、62.3%、72.7%、77.2%)均使用其自研 agent 脚手架(Claude Code 同系),不是 SWE-agent。SWE-agent 搭配 Claude 4 Sonnet 的官方榜单数字是 66.60%,与官方自报的 72.7% 相差 6.1 个百分点——这个差距本身就是脚手架价值的量化。
口径:厂商自报 ≠ 统一脚手架 警示:66.60% vs 72.7%(差 6.1 pt)
四 · 跃迁轨迹的阶段性特征

三个阶段:Harness 主导 → 模型爆发 → 复杂度被替代

  • 第一阶段(2024.04—2024.10):Harness 层主导性能差异。GPT-4 Turbo 在 Full 上只有 12.47%,即便有 ACI 加持也只能到这个水平。此阶段模型是瓶颈,接口设计能带来 64% 的相对提升,但绝对天花板很低。
  • 第二阶段(2024.10—2025.09):模型能力爆发式增长。Claude 3.5 Sonnet 升级版 49.0%(2024.10)→ Claude 3.7 Sonnet 62.3%(2025.02)→ Claude Sonnet 4 72.7%(2025.05)→ Sonnet 4.5 77.2%(2025.09),一年内绝对提升近 45 个百分点,远超 Harness 层的优化速度。
  • 第三阶段(2025.07 至今):Harness 层复杂度被模型能力替代,基准本身开始换代。mini-swe-agent 用极简架构 + Claude Sonnet 4 即达约 65%。此后两件大事改写格局(见下)。
大事一:Verified 退役(2026-02-23)

OpenAI 发布《Why SWE-bench Verified no longer measures frontier coding capabilities》,宣布停止报告 Verified 分数。两大理由:其一,对 o3 在 64 次运行中未能稳定解决的 138 道题(占全集 27.6%)的审计发现,其中 59.4% 存在实质缺陷(narrow tests 35.5% + wide tests 18.8% + 其他 5.1%)——注意这是对难钉子题子集的审计结论,并非「全数据集 59.4% 测试有缺陷」;其二,训练污染——GPT-5.2、Claude Opus 4.5、Gemini 3 Flash 均能复述 gold patch。

大事二:Pro 审计反转(2026-07-08)

OpenAI 发布对 SWE-bench Pro 的审计,估计约 30% 题目存在问题(pipeline 标记 27.4%、人工标注 34.1%),并撤回了此前对 Pro 的推荐。与此同时,Pro(1865 题、41 仓库)的厂商自报最高分在 8 个月内从首发的 23.3%(GPT-5)攀升至 81.2%(Claude Fable 5.1,2026-09-11 口径)——分数通胀与可信度危机并存。

事件:Verified 退役 2026-02 · Pro 审计 2026-07 污染:GPT-5.2 / Opus 4.5 / Gemini 3 Flash 复述 gold patch
四 · 关键观察

移动靶效应:不仅 Harness 设计是靶,基准本身也是靶

SWE-agent 的 ACI 设计是针对 2024 年初的 GPT-4 Turbo 这一特定能力快照做的优化。当模型能力快速迭代时,这些针对特定缺陷的补偿机制会逐渐变得冗余。mini-swe-agent 的出现,本质上是同一团队对自己前作的「时效性审计」——在 2025 年中的模型能力水平下,重新检验哪些干预仍然必要、哪些已经成为开销。

2026 年的新证据让这个效应更加立体:不仅 Harness 设计是移动靶,基准本身也是移动靶——Verified 因饱和与污染退役,Pro 在分数冲到 81% 的同时被审计出三成题目有问题。架构演进研究与基准生命周期管理,已成为同一枚硬币的两面。

观察:移动靶 × 2(模型能力 / 基准)

五、架构对比:逐项拆解复杂度迁移

四个维度:工具集 / 上下文管理 / 执行引擎 / 模板配置
每个维度的迁移都遵循同一逻辑:2024 年由 Harness 替模型做的决策,到 2025 年模型已能自己完成。
五 · 维度一:工具集

从多工具矩阵到单一 bash

SWE-agent 的工具集按职责分四组,每组对应模型的一个特定缺陷:

工具组对应模型缺陷补偿机制
搜索导航(find_file / search_dir)模型无法有效过滤搜索结果,容易被大量输出淹没50 条上限 + 超限抑制并提示细化查询
文件浏览(窗口化查看器)模型在长上下文中「lost in the middle」固定至多 100 行窗口 + 状态机
文件编辑(edit + lint)模型容易产出语法错误的代码编辑前 linter 检查 + 错误回滚
任务提交(submit)模型不知道何时 / 如何结束任务专用提交命令

mini-swe-agent 只有一件工具:bash。模型像人类工程师一样用 ls 探索、cat / nl / sed 查看编辑、grep 搜索、python 跑复现脚本,用 echo COMPLETE_TASK_AND_SUBMIT_FINAL_OUTPUT 提交。

迁移的本质:2024 年的模型需要 Harness 层替它做「信息过滤决策」(看多少行、搜多少条、编辑是否合法);2025 年的模型已能自己完成这些决策。专用工具的价值在于替弱模型做它做不好的事;当模型变强后,这些工具反而成为额外开销——模型需要学习工具文档、遵循工具调用格式、处理工具特有的反馈格式,这些都是认知负荷。
维度一:4 组工具 → 1 个 bash
五 · 维度二:上下文管理

从可插拔压缩链到线性全量历史

SWE-agent 的 History Processor 链在每轮发送前对历史做过滤与压缩:LastNObservations 只保留最近 5 轮 observation,过期内容折叠为单行占位;标签系统对关键工具结果差异化保留;正则清理器按规则清理冗余片段。消融实验证明这对 2024 年模型是净收益(Full history 配置下降 3.0 个百分点)。

mini-swe-agent 没有任何历史处理器:self.messages 是一个从 system 消息开始、每轮纯追加的线性列表。

迁移的本质:2024 年的模型在长上下文中性能衰减严重,必须通过压缩控制上下文长度;2025 年的模型(Claude Sonnet 4 支持 200K 上下文,2025 年 8 月起提供 1M token beta)能直接从完整历史中提取关键信息,不再需要外部压缩。mini 还带来一个额外优势:轨迹就是模型实际看到的内容——调试和微调时不需要从复杂的历史处理器里还原。这也是官方将 mini 定位为 FT/RL 训练底座的核心原因("doing FT or RL and don't want to overfit to a specific agent scaffold")。
维度二:压缩链 → 线性追加(轨迹 = 消息流)
五 · 维度三:执行引擎

从有状态长会话到无状态单步执行

SWE-agent 的 SWE-ReX 维护有状态的长 Shell 会话,支持 ipython、gdb 等交互式会话,工具间通过环境变量与文件系统共享状态。mini-swe-agent 每条命令通过 subprocess.run 独立执行,命令之间无隐式状态依赖。

迁移的本质:有状态 Shell 的价值在于支持需要保持进程生命周期的复杂工作流(如在 gdb 中设置断点、单步调试);但对大多数 SWE-bench 任务,模型只需执行独立的命令序列。无状态执行的额外好处:横向扩容只需多开进程,沙箱化只需一行替换,调试时不存在「模型实际看到了什么需要从历史处理器里还原」的问题。
维度三:SWE-ReX 长会话 → subprocess.run 独立子进程
五 · 维度四:模板与配置

从声明式实验平台到代码即配置

SWE-agent 的提示词由 Jinja2 模板族驱动,支持多套模板 + demonstrations + 多配置文件嵌套合并 + 命令行参数覆盖。mini-swe-agent(v1)只有 system_template、instance_template、observation_template 三个基础模板,走 zero-shot 路线,不挂载演示轨迹。

迁移的本质:演示轨迹的价值在于通过 in-context learning 教弱模型如何正确使用工具;当模型足够强、工具足够简单(只有一个 bash)时,zero-shot 就够了。SWE-agent 的消融显示去掉 demonstrations 只降 1.7 个百分点(18.0% → 16.3%),是所有组件中贡献最小的——这本身就预示了它最先被淘汰的命运。
维度四:Jinja2 模板族 + demos → 3 模板 zero-shot

六、机制归因:为什么模型变强后可以「裸奔」

把四个维度的迁移放在一起,归纳出三条核心机制
以及一条重要限定:能力提升并非在所有维度上均匀发生,因此各组件被「淘汰」的时间点也不同。
六 · 三条核心机制

长上下文 / 指令遵循 / 自我修正,三条能力线同时越过阈值

机制一:长上下文信息过滤能力的质变

2024 年初的 GPT-4 Turbo 在 128K 上下文窗口中,对中间位置的信息利用率呈 U 形曲线(「lost in the middle」),因此 SWE-agent 必须用 100 行窗口替模型做信息过滤。2025 年的模型(Claude Sonnet 4 的 200K 上下文、Sonnet 4.5 起的 1M token beta)在长上下文利用上有质的飞跃,能够直接从完整文件内容和完整历史中提取关键信息,不再需要外部窗口化。

机制二:指令遵循与工具使用精度的提升

2024 年的模型使用 sed、grep 等复杂命令行工具时错误率很高,SWE-agent 必须提供简化版专用命令来降低认知负荷。2025 年的模型已能准确使用原生 bash 命令完成搜索、浏览、编辑,甚至能自己组合 sed -i、python -c 等复杂命令。mini v2 默认切换原生 tool-calling(2026-02),是这一机制的最新注脚:连「文本协议解析」这层兜底都失去了必要性。

机制三:代码生成质量与自我修正能力的增强

SWE-agent 的 lint 守卫针对的是模型「编辑后引入语法错误」的问题——在 GPT-4 Turbo 上,51.7% 的任务轨迹存在至少 1 次失败编辑,失败后的续成功率从 90.5% 跌至 57.2%。2025 年的模型不仅产出语法正确代码的概率更高,遇到错误时还能更有效地自我修正(分析错误信息、调整策略、重新尝试),不再需要 Harness 层在编辑前拦截错误。

机制:长上下文 · 指令遵循 · 自我修正
六 · 能力迁移的非均匀性

不同组件对不同能力的依赖不同,「淘汰顺序」也不同

SWE-agent 的消融实验已经暗示了这一点:去掉编辑器降 7.7 个百分点,迭代搜索降 6.0,窗口化降 5.3,历史压缩降 3.0,lint 守卫降 3.0,去掉 demonstrations 只降 1.7——不同组件对不同模型能力的依赖程度不同,因此它们被「淘汰」的时间点也不同。

观察 mini 的取舍可以发现:demonstrations 与复杂模板最先被裁(认知负荷类补偿最先失效),信息过滤类补偿次之,而执行隔离、成本限额、轨迹持久化等工程基础设施被完整保留——这与第九章的「固有复杂度」判断互为印证。
淘汰顺序:认知负荷类 → 信息过滤类 →(工程基础设施保留)

七、性能-成本-复杂度三角关系

把解决率、成本、复杂度放在一个三角中观察
核心规律:模型能力较低时,Harness 复杂度投入带来显著边际收益;跨过阈值后,同样的投入边际收益急剧递减,甚至变为净开销。
七 · 解决率对比

六个系统-模型组合的解决率全景

系统模型SWE-bench 子集解决率时间
SWE-agentGPT-4 TurboFull12.47%2024.05
SWE-agentGPT-4 TurboLite18.00%2024.05
SWE-agent 完整版Claude 4 SonnetVerified66.60%2025.05
mini-swe-agent v1Claude Sonnet 4Verified~65%2025.07
mini-swe-agent v2.0.0Claude 4.5 Opus highVerified (Bash Only)76.80%2026
live-SWE-agent(mini 基座)Claude 4.5 Opus mediumVerified (Bash Only)79.20%2026
跨度:12.47% → 79.20%(2024.05 → 2026)
七 · 成本结构差异

成本下降与性能提升同步发生,而非此消彼长

SWE-agent 论文给出了精细的成本账(GPT-4 Turbo):

  • 成功任务:中位成本 $1.21,中位步数 12 步
  • 失败任务:平均成本 $2.52,平均步数 21 步
  • Full split 已解决实例的平均成本为 $1.59(注意口径:仅在成功解决的实例上平均,不是全体实例的整体平均)
  • 93.0% 的已解决实例在耗尽成本预算前主动提交(每实例预算上限为 $4.00)

mini-swe-agent 发布时没有官方成本数字,但 2026 年 SWE-bench 官方 Bash Only 子榜提供了真实数据(该榜独有 "Avg. $" 列,仅 mini 条目披露成本,其他脚手架均为 "-",因此跨脚手架成本对比无法直接从榜单进行):

Bash Only 子榜成本表(均为 mini-SWE-agent 脚手架)
配置% ResolvedAvg $/实例
Claude 4 Opus(v1.0.0)67.6%$1.13
Claude 4.5 Sonnet(v1.13.3)70.6%$0.56
Claude 4.5 Opus medium(v1.16.0)74.4%$0.72
Claude 4.5 Opus high(v2.0.0)76.8%$0.75
Gemini 3 Flash high(v2.0.0)75.8%$0.36
GPT-5 medium65.0%$0.28
Kimi K2.5 high70.8%$0.15
MiniMax M2.5 high(v2.0.0)75.8%$0.07

(v2 的 SWE-bench 默认配置:每实例成本上限 $3、步数上限 250。)

这组数据揭示了比定性推测更激进的图景:从 2024 年 5 月到 2026 年,统一脚手架口径下的解决率从 12.47% 升至 76.8%(约 6 倍),单实例成本反而从 $1.59 降至 $0.75(约腰斩);开源模型(MiniMax M2.5)更是以 $0.07 的成本达到 75.8%。mini 结构天然更省 token 的定性判断(无工具文档注入、无 demonstrations、线性历史对 prompt caching 友好)得到数据支持;「裸 bash 需要更多轮次」的反方向开销在总账上被模型单价下降与效率提升覆盖。
数据:SWE-bench 官方 Bash Only 子榜(2026) 极限:$0.07/实例 · 75.8%(MiniMax M2.5)
七 · 架构复杂度的量级差异

一张表看清两个系统的工程体量

维度SWE-agentmini-swe-agent
核心 Agent 代码数千行(模块化体系)~100 行(v1;v2 约 190 行)
可运行系统总量~10,000 行(含工具包、环境、配置)~200 行(官方口径:核心 + env/model/run 合计)
外部依赖LangChain + 多工具包 + SWE-ReX无重型依赖;litellm + pydantic/jinja2 等轻量依赖
配置文件多 YAML 嵌套合并 + 命令行覆盖单 YAML + 少量开关
量级:~10,000 行 vs ~200 行(约 1/50)
七 · 三角关系的动态平衡

三个时间点,三种平衡形态

  • 2024 年(SWE-agent + GPT-4 Turbo):低解决率(12.47%)、中等成本($1.59/成功实例)、高复杂度 → Harness 层投入大量工程复杂度,但受限于模型能力天花板,绝对性能仍然很低
  • 2025 年中(SWE-agent 完整版 + Claude 4 Sonnet):高解决率(66.60%)、高复杂度 → 模型能力突破天花板后,Harness 层的复杂度开始成为净开销
  • 2025–2026(mini + 各代模型):相近乃至更高的解决率(65% → 76.8%)、显著下降的成本($1.13 → $0.07 区间)、极低复杂度 → 同样乃至更弱的模型能力定价,用 1/50 的架构复杂度达到更好性能
核心规律:在模型能力较低的阶段,Harness 层的复杂度投入能带来显著的边际收益;但当模型能力跨过某个阈值后,同样的复杂度投入的边际收益急剧递减,甚至变为净开销。mini-swe-agent 的出现标志着这个阈值已经被跨过;而 2026 年 Bash Only 子榜的格局(第八章)则显示,跨过阈值之后出现了新的复杂度形态——运行时自我演化。
规律:复杂度投入的边际收益随模型能力递减

八、后续演进与 2026 年格局:从 mini 出发的三条路线

运行时自我演化 / RL 训练底座 / 评测基础设施
「重型 vs 极简」之争在 2026 年已演变为「极简静态 vs 极简自我演化」——传统重型 ACI 脚手架全面退出头部。
八 · 路线一:运行时自我演化

Live-SWE-agent:从 bash-only 出发、在运行时自主合成工具,已登顶

UIUC 张令明(Lingming Zhang)团队的 Live-SWE-agent(arXiv:2511.13646)从 mini-swe-agent 的 bash-only 脚手架出发,让 Agent 在运行时自主合成软件工程工具——论文定位是 "first live software agent that evolves its own scaffold on the fly, starting from nothing more than bash tools"。

性能数据的版本脉络需要精确引用:论文 v1 的头条数字是 75.4%(SWE-bench Verified,Claude Sonnet 4.5);v3 摘要已更新为 77.4%(Gemini 3 Pro,无 test-time scaling),并在 SWE-bench Pro 上达 45.8%。更重要的是:截至 2026-09-16,Live-SWE-agent 以 79.20%(Claude 4.5 Opus medium)与 Sonar Foundation Agent 并列 SWE-bench 官方 Bash Only 子榜榜首,超过了所有静态脚手架。这证明「模型自主决定何时需要专用工具」比「预先设计固定工具集」更有效——它已经从「前沿方向」变成了榜单冠军。

paper: arXiv:2511.13646(v1 75.4% → v3 77.4%) 榜单:79.20% 并列 Bash Only 榜首(2026-09-16)
八 · 路线二:极简 RL 训练环境

SWE-MiniSandbox 与 mini 的训练底座定位

北大团队的 SWE-MiniSandbox(arXiv:2602.11210,2026-02-11 提交)通过内核级隔离机制(namespace 类的独立工作区)替代每实例 Docker 容器,加轻量环境预缓存,磁盘占用降至约 5%,目标正是可扩展的 RL 训练——解决「每个 episode 都要拉起/销毁容器」的效率瓶颈。

这条路线的底座正是 mini 的设计哲学:官方文档明确将 mini 定位为 FT/RL 底座(不想过拟合到特定脚手架时使用),线性历史(轨迹 = 消息流)与无状态执行都是为了训练场景的沙箱化与横向扩展。

一个重要的反向案例:SWE-smith。SWE-bench 团队 2025 上半年的这个项目用完整版 SWE-agent 生成数万条训练轨迹,训出开源 SOTA SWE-agent-LM-32B——在训练数据生产场景,可控、可配、多工具的重型脚手架仍有残留价值,这是对「复杂度不可逆下沉」论断的重要限定(详见第九章)。
paper: arXiv:2602.11210(磁盘降至约 5%) 反向案例:SWE-smith 用完整版产训练数据
八 · 路线三:评测基础设施

关于 Bash Only 子榜的两处事实修正

mini-swe-agent 被 Meta、NVIDIA、IBM、Essential AI、Nebius、Anyscale、Princeton、Stanford 等机构采用。但关于其「评测基础设施」角色,有两处事实必须讲准:

  • 「为 Ramp 维护的 SWE-bench 官方榜单供能」是混淆表述。事实是:mini 驱动的是 Ramp 公司自己的榜单(labs.ramp.com/swebench,官方 News 原文 "mini-swe-agent now powers Ramp SWE-Bench");而 SWE-bench 官方站的做法是新增「Bash Only」子榜——Verified 标签页现在默认即 bash-only 视图,页面注明 "Defaults to bash-only setting (run with mini-SWE-agent)"。
  • 「官方榜单强制使用统一脚手架」不成立。官方 Verified 主榜不强制统一脚手架——OpenHands、SWE-agent、TRAE、Warp 等各用各家脚手架并存;只有 Bash Only 子榜统一用 mini 跑裸模型。
正确的论据结构:官方需要一个「零脚手架干扰」的控制变量视图来纯化模型能力对比,因此增设子榜而非改造主榜。当所有模型在同一个极简壳里跑分时,分数只反映模型能力——这一制度设计本身恰恰印证了本报告的核心命题:脚手架差异曾经(并仍然)能贡献分数,官方才需要一个排除脚手架变量的基准面。
修正:Ramp 自有榜单 ≠ 官方榜;主榜不强制统一脚手架
八 · 2026 年 Bash Only 子榜格局

重型脚手架已不占头部(2026-09-16 抓取)

排名模型 + 脚手架% ResolvedAvg $
1Claude 4.5 Opus + Sonar Foundation Agent79.20-
1Claude 4.5 Opus medium + live-SWE-agent79.20-
3Doubao-Seed-Code + TRAE78.80-
4Gemini 3 Pro Preview + live-SWE-agent77.40-
7Claude 4.5 Opus high + mini-SWE-agent v2.0.0(纯 mini 最高)76.80$0.75
9Gemini 3 Flash high + mini v2.0.075.80$0.36
10MiniMax M2.5 high + mini v2.0.075.80$0.07
12Claude 4.6 Opus + mini v2.0.075.60$0.55

对照重型/复杂脚手架的历史最佳:OpenHands + GPT-5 71.80%(2025-08)、OpenHands + Claude 4 Sonnet 70.40%、SWE-agent 完整版 + Claude 4 Sonnet 66.60%。同系模型直接对照:SWE-agent 完整版 + Claude 4 Sonnet = 66.6%,而 mini + Claude 4.5 Sonnet = 70.6%($0.56/实例)——极简脚手架反超同系重型脚手架。

与此同时,SWE-agent 完整版发布已停滞:最新 release 为 v1.1.0(2025-05-22),截至 2026-09 已约 16 个月无新版本;官方文档已把 mini-swe-agent 定位为「默认选择」,完整版只推荐给「要实验不同工具集/历史处理器」的研究场景。SWE-bench 团队的新动作则转向:Multimodal / Multilingual 子榜、SWE-smith 训练数据生成、免费云端评测 sb-cli、新基准 ProgramBench。工业界采用持续扩大:DataCurve 的 DeepSWE 长程任务基准用 mini 做评测 harness,官方称 "mini-swe-agent beats Claude Code and Codex on DeepSWE"。

格局判断:「重型 vs 极简」之争在 2026 年已演变为「极简静态 vs 极简自我演化」。榜首属于以 mini 为基座的运行时演化脚手架,传统重型 ACI 脚手架全面退出头部。
数据:SWE-bench 官方 Bash Only 子榜(2026-09-16 抓取) 判断:极简自我演化成为新的主要矛盾

九、前瞻研判:复杂度下沉的极限在哪里

短期 / 中期 / 长期三个时间尺度 + 对可靠性研究的启示
复杂度的生产者正从「人类预先设计」转移为「模型运行时自主生成」——下一阶段的真问题是演化的治理。
九 · 短期(2026—2027)

Harness 层继续瘦身,但「极简」的内涵在变化

随着模型在长上下文利用、指令遵循、代码生成质量上持续进步,静态脚手架剩余的模板和配置将进一步简化。但 mini v2 的演进提示了一个方向性修正:瘦身的终点不是「更少的代码行数」,而是「把协议适配层交给模型原生能力」(tool-calling 取代文本解析)。

同时,SWE-bench Pro(1865 题、41 仓库)曾是公认的新天花板,但 2026-07 的 OpenAI 审计(约 30% 题目有问题)使其权威性受损;SWE-rebench(Nebius 的月度刷新去污染基准,注意它不是 Princeton/SWE-bench 团队项目)、ProgramBench 等新基准正在承接「能力天花板」的角色。

短期:协议适配层交给模型原生能力
九 · 中期

自适应复杂度已被提前实现,下一站是「演化的治理」

曾有预言称「2027—2028 年将出现根据任务难度和模型能力动态调整 Harness 复杂度的自适应框架」。这一预言已被 Live-SWE-agent 提前实现(2025-11 论文、2026 年登顶官方子榜):复杂度的生产者从「人类预先设计」转移为「模型运行时自主生成」。

下一阶段的真问题随之变化——运行时生成的工具如何验证、审计、防退化?自我演化脚手架的可靠性工程(生成工具的测试、版本管理、跨任务迁移性)将成为新的研究焦点。

中期:从「自适应复杂度」到「演化的治理」
九 · 长期趋势

复杂度下沉的两个边界条件与一个修正

从 SWE-agent 到 mini-swe-agent 的演进,本质上是复杂度从 Harness 层不可逆地下沉到模型权重中的过程。这个趋势的边界条件:

  • 下限(固有复杂度):环境隔离、安全沙箱、成本预算控制、轨迹持久化等「工程基础设施」是任务本身的固有复杂度,不会因模型变强而消失——mini 完整保留了它们,SWE-MiniSandbox 更是在这条线上继续投入
  • 上限(骨架内化):当模型能力足够强时,连「循环 + 执行 + 线性历史」这个骨架都可能被模型内化
  • 修正(下沉的非全域性):下沉在推理侧成立,但在训练数据生产侧不成立——SWE-smith 用完整版 SWE-agent 生成训练数据(多工具、可控、可配恰恰是数据生产的优点)。「不可逆下沉」应精确表述为:推理时 Harness 复杂度不可逆下沉;离线数据生产与实验研究场景保留重型脚手架的生态位
边界:下限固有复杂度 · 上限骨架内化 · 修正非全域
九 · 对可靠性研究的启示

三组关键认知:可靠性来源、可观测性、基准生命周期

可靠性来源的迁移

2024 年的可靠性主要来自 Harness 层的外部约束(lint 守卫、窗口限制、搜索上限);2025 年越来越多地来自模型自身的内在能力;2026 年则出现了第三极——运行时生成的可靠性(模型自己造工具并自我约束)。可靠性研究的重点应从「如何设计更好的外部约束」转向「如何评估和增强模型的内在可靠性」,再延伸到「如何治理模型自主生成的脚手架」。

可复现性与可调试性的范式转换

mini 的线性历史设计证明了「透明性本身就是一种可靠性保障」——当你能直接看到模型实际看到的内容时,故障诊断和根因分析变得极其简单。这为 Agent 系统设计提供了一个重要原则:在满足功能需求的前提下,优先选择可观测性最高的架构。

基准生命周期管理成为一等公民

Verified 因饱和 + 污染 + 缺陷退役(2026-02),Pro 在分数冲到 81% 的同时被审计出约三成题目有问题(2026-07)。教训是双重的:其一,任何静态基准都有半衰期,去污染与持续刷新(SWE-rebench 模式)是必需机制;其二,审计基准缺陷与审计 Agent 行为是同构问题——对轨迹做过程分析的方法论(如本项目的 analysis 栈),同样适用于对基准题目做缺陷标注。对「评测 → 分析 → 构造 → 训练 → 评测」闭环而言,基准质量审计应成为闭环中的显式环节,而非外部假设。

启示:内在可靠性 · 透明性 · 基准审计入闭环

十、总结

大模型能力跃迁在软件工程 Agent 领域留下的最清晰的「化石记录」
一组可量化、可复现的对照实验,证明了一个深刻的规律。
十 · 核心规律

Agent 系统的架构复杂度,本质上是模型能力缺口的函数

当模型能力不足时,Harness 层必须承担大量补偿性工作——信息过滤、动作约束、错误拦截、上下文管理——这些工作的工程复杂度与模型能力的缺口成正比。当模型能力跨过临界阈值后,这些补偿性工作可以被逐步收回,复杂度从 Harness 层下沉到模型权重中。

2026 年的新证据为这个规律补上三块拼图
  • 下沉之后是演化:复杂度并未消失,而是转变了生产者——Live-SWE-agent 以 mini 为基座运行时合成工具并登顶官方 Bash Only 子榜(79.20%),标志着「极简静态 vs 极简自我演化」取代「重型 vs 极简」成为新的主要矛盾
  • 下沉不是全域的:推理侧复杂度下沉的同时,训练数据生产(SWE-smith 用完整版 SWE-agent)与工程基础设施(沙箱、成本、轨迹持久化)保留了重型/复杂度的生态位
  • 移动靶不止模型:基准本身也在移动——Verified 退役、Pro 审计反转,基准生命周期管理成为与架构设计同等重要的研究变量
一组递进的对照实验:SWE-agent 证明了「Harness 层能带来多大收益」,mini-swe-agent 证明了「模型能力能替代多少 Harness 复杂度」,Live-SWE-agent 证明了「模型可以自主生产多少 Harness 复杂度」。三者共同构成了 Code Agent 可靠性研究中一组递进的对照实验,也为自适应架构、运行时工具合成治理、极简评测基础设施、基准审计等前沿方向奠定了认知基础。
三系统:SWE-agent / mini-swe-agent / Live-SWE-agent 规律:复杂度 = f(模型能力缺口)