mini-SWE-agent：100 行代码如何击败了大多数 Agent 框架

Princeton & Stanford 出品

26k+ Stars

74% SWE-bench 修复率

~100 行核心代码

核心洞察

SWE-agent 团队在 2024 年发布了 SWE-bench（软件工程 Agent 基准测试），开启了 AI 编程 Agent 的浪潮。2026 年，他们问了自己一个反直觉的问题：

如果 Agent 框架简化 100 倍，效果还能保持吗？

答案是：不仅能，还更好。

mini-SWE-agent 只有约 100 行 Python 代码，却达到了 74% 的 SWE-bench verified 修复率。大多数商业 Agent 框架都做不到这个成绩。

这个项目不是炫技，而是一个深刻的灵魂拷问：我们给 Agent 堆的那些复杂度，真的都需要吗？

一、背景：SWE-agent 的起源和演进

SWE-agent 的诞生

SWE-agent 由 Princeton 和 Stanford 的研究团队开发，核心思想是：让语言模型自主使用工具来修复 GitHub Issues。

2024 年，它的架构是：

• 精心设计的 Agent-Computer Interface（ACI）
• 专门为 LLM 优化的工具调用格式
• SWE-bench 上的 SOTA 结果

2026 年的新问题

一年后，LLM 的能力大幅提升。团队开始思考：

“既然模型变强了，我们去掉那些专门为模型设计的接口，还能不能 work？”

答案是令人惊讶的：完全可以，而且效果更好。

二、mini-SWE-agent 的设计哲学

原则 1：没有工具，只有 bash

mini-SWE-agent 没有自己的工具调用接口。它只有一个工具：subprocess.run。

# mini-SWE-agent 的全部"工具"：
result = subprocess.run(command, shell=True, capture_output=True, ...)

没有 bash() 工具，没有 file_editor 工具，没有任何为 LLM 优化的接口。模型看到的就是真实终端。

原则 2：完全线性历史

传统 Agent（树状/图状历史）：
  message_1
    ├── tool_call_1
    │     └── tool_result_1
    └── tool_call_2
          └── tool_result_2

mini-SWE-agent（线性历史）：
  message_1
  message_2 (with tool_result_1 appended)
  message_3 (with tool_result_2 appended)

每一步只是把工具执行结果追加到消息历史里。没有中间状态，没有分支，没有复杂的轨迹管理。

原则 3：每个动作完全独立

传统 Agent 维护一个状态ful 的 shell session。mini-SWE-agent 每次执行都是一个独立的 subprocess.run。

# 传统 Agent：维持 shell 状态
shell_session.write("cd src")
shell_session.write("ls")  # 能看到 cd 的结果

# mini-SWE-agent：每次完全独立
subprocess.run("cd src && ls", ...)  # 每条命令都是完整的

这意味着：

• 调试极度简单：轨迹就是消息历史，可以直接给另一个模型重现
• 沙箱极度简单：换掉 subprocess.run 就能换执行环境
• 扩展极度简单：不需要理解复杂的内部状态机

三、74% 修复率背后的秘密

为什么这么强？

不是框架强，是模型变强了。

当 Claude 3.7 Sonnet 能理解 bash 命令、能在上下文窗口内维护多文件状态时，专门设计的”Agent友好”接口反而成了噪声。

mini-SWE-agent 团队的原话：

“When LLMs have become more capable, a lot of this is not needed at all to build a useful agent!”

benchmark 数据

Gemini 3 Pro 达到了 74%，超过了所有开源 Agent 框架。

token 效率

mini-SWE-agent 的另一个优势是轨迹极短：

• 没有专门设计的 tool_call schema
• 没有中间状态序列化
• 消息历史 = 完整轨迹

结果：用更少的 token 达到更好的效果。

四、与 SWE-agent 1.0 的对比

五、技术实现：100 行代码里有什么

核心代码结构

# 约 100 行核心代码

class MiniSWEAgent:
    def __init__(self, model, environment):
        self.model = model          # LiteLLM / OpenAI / Anthropic
        self.env = environment      # Docker / Local / Singularity

    def run(self, issue: str, repo_path: str):
        # 1. 构造初始 prompt（包含 issue 描述）
        messages = [SystemMessage(...), UserMessage(issue)]

        # 2. 主循环
        while not self.finished:
            # 3. LLM 生成 bash 命令
            response = self.model.generate(messages)

            # 4. 执行命令（完全独立）
            result = self.env.execute(response.commands)

            # 5. 追加结果到历史（线性）
            messages.append(UserMessage(result))

        return self.result

环境支持

# 支持多种执行环境
env = LocalEnvironment()           # 本地直接执行
env = DockerEnvironment("python:3.11")  # Docker 容器
env = SingularityEnvironment("image.sif")  # Singularity
env = ContreeEnvironment()         # 沙箱隔离

六、为什么这对 AI 编程工具的开发者很重要

1. 模型能力已经超过框架复杂度

mini-SWE-agent 证明了：当前最强的模型已经能在”原始”的 bash 环境下 work。专门设计的”Agent友好”接口，在某些场景下反而限制了模型的能力。

2. 调试和可重现性是关键

完全线性历史 + 独立 subprocess = 完美的可重现性。

你想复现一个 Agent 的执行？只需要把消息历史传给另一个模型。

3. 极简主义不等于简单

mini-SWE-agent 简单，但解决的是真实问题：LLM 能理解 bash，能读代码，能写测试，能判断修复是否成功。

当问题本身就很直接时，过度工程化反而是负担。

七、mini-SWE-agent 的使用场景

✅ 完美适合

• 代码修复自动化：修复 GitHub Issues（它的本职）
• 大规模代码迁移：批量重命名、重构
• 研究基准测试：干净、可控、可重现
• CI/CD 集成：作为流水线的一环

❌ 不适合

• 复杂多步骤的协作任务：没有状态管理
• 需要严格权限控制的环境：纯 bash 无隔离
• 需要细致人类反馈的流程：无 HITL 设计

八、快速开始

pip install mini-swe-agent

from minisweagent import MiniSWEAgent
from minisweagent.models import LiteLLMModel

model = LiteLLMModel(
    model_id="claude-3-7-sonnet-20260211",
    api_key=os.environ["ANTHROPIC_API_KEY"]
)

agent = MiniSWEAgent(model=model)

result = agent.run(
    repo_path="./repo",
    issue="Fix the login bug when username contains special characters"
)

print(result.passed)  # True/False
print(result.patch)   # 生成的 patch

九、Gemini 3 Pro 的 74% 意味着什么

这是目前最强的代码修复结果。背后的关键：

1. 长上下文：Gemini 3 Pro 能一次性读入整个代码库
2. 原生代码能力：在代码任务上经过专门优化
3. 工具调用原生化：不需要特殊 prompt 工程

这意味着：

• 模型 > 框架：选对模型比优化框架更重要
• 上下文 > 工具：给模型足够的信息比设计复杂的工具接口更有效

十、SWE-bench 给我们的启示

SWE-bench 的设计

SWE-bench 从真实 GitHub Issues 中采样，评估 Agent 能否：

1. 理解 Issue 描述
2. 找到相关代码
3. 编写修复
4. 通过测试

这个基准测试之所以重要，是因为它测的是真实软件工程问题，而不是玩具题目。

Agent 的能力边界

资源

• GitHub: https://github.com/SWE-agent/mini-swe-agent
• 文档: https://mini-swe-agent.com/
• 论文: https://arxiv.org/abs/2405.15793
• 社区: https://swe-agent.com/

本文基于 2026-03-22 的最新版本