<!-- title: 自主编程智能体四范式控制流实测 -->

## 自主编程智能体四范式控制流实测：从 issue 到补丁的对决

2026 年 6 月，SWE-bench Verified 这道由 500 道真实 GitHub issue 人类核验过的尺子，SOTA 已经稳定在 75%–80% 区间。当分数逼近天花板，真正值得复盘的不再是"谁能更高"，而是"谁用什么控制流跑到这里"。把开源自主编程智能体解剖开，会发现它们对同一件事——把一段 issue 文本变成一个能通过隐藏测试的补丁——给出了四套截然不同的工程答案：Princeton 的 **SWE-agent** 给出了 ACI 定制接口，All-Hands-AI 的 **OpenHands** 用事件流加 CodeAct，UIUC 的 **Agentless** 干脆去掉 agent 循环走三段流水线，而 **Moatless Tools / SWE-Search** 把代码定位建模成蒙特卡洛树搜索。本期把这四套控制流放在同一张解剖台上，逐范式拆解它们的循环内核、上下文税与变现形态。

### 衡量四范式的一张表

| 维度 | SWE-agent (ACI) | OpenHands (CodeAct) | Agentless (无 agent) | Moatless / SWE-Search |
|------|----------------|--------------------|--------------------|-----------------------|
| 控制流内核 | 定制 REPL + 受限工具集，LM 驱动循环 | 事件流（event stream）+ 代码即动作 | localize→repair→validate 固定流水线 | 搜索节点 + MCTS 回溯 |
| 设计哲学 | 接口即上下文预算 | 事件溯源，动作可重放 | 去 agent 化，回归传统 SE 流程 | 定位是搜索问题，非阅读问题 |
| 代表分数 | SWE-bench Verified 早期基线 ~12%，新版随模型爬升 | CodeAct 2.1 达 53%（Claude 3.5，2024.11），后续迭代逼近 SOTA | 低成本打平同期 agent，成本仅其零头 | SWE-Search 用 MCTS 显著提升定位命中率 |
| 上手难度 | 单命令起容器，需理解 ACI 命令 | Docker runtime + SDK，组件最多 | 一条流水线脚本，最简单 | 概念门槛高（树搜索、评估函数） |
| 变现潜力 | 教学友好，ACI 是好选题 | 平台化最强，可做云 IDE/训练营 | 成本故事最硬，适合 ToB 降本 | 偏研究，难直接产品化 |
| 适用场景 | 通用 SWE 自动修复 | 端到端云编码平台 | 高并发、低成本的批量修复 | 大仓定位、难例攻克 |

### 一、先把"自主"这把尺子说清楚

SWE-bench Verified 的规则冷峻而公平：智能体拿到一个 Python 仓库的检出状态、一份 issue 文本，必须产出一个补丁，让仓库自带的隐藏测试通过。它逼出了自主智能体的全部硬骨头——**定位**（改哪几个文件）、**理解**（这坨代码的语义）、**编辑**（不破坏既有结构）、**验证**（自己的改动是否真能跑通）。值得注意的是，这四步里没有任何一步能靠单次 LLM 调用完成，所以"控制流"成了分水岭：谁来决定下一步做什么、循环何时终止、失败如何回退。四种范式给出的不是参数差异，而是对这个循环结构的四种哲学回答。理解了这一点，就理解了为什么 2026 年榜单前列分数趋同、架构却依然分道扬镳。

### 二、范式一：ACI 定制接口——把工具集当上下文预算

SWE-agent 的核心贡献是 **Agent-Computer Interface（ACI）** 这一概念。它的洞见是：人类用的 bash、vim 对 LM 来说是灾难——输出冗长、错误信息含糊、状态不可观测。于是 SWE-agent 为 LM 专门造了一套受限命令：`find_file`、`search_dir`、`search_file`、`open`、`edit`、`scroll_down`，每个命令的输出都经过精剪，文件默认只展示一个窗口（约 100 行）。这本质上是在**用接口设计购买上下文预算**：每次工具调用的 token 都被压到最低，让 LM 在有限的上下文窗口里能支撑更多轮推理。代价是这套 ACI 是"为弱模型时代"设计的强约束，当模型变强、上下文窗口变大，部分约束反而成了负担，社区也一直在争论 ACI 还需不需要这么"保姆"。代码形态如下（节选自 SWE-agent 的命令定义）：

```python
# SWE-agent ACI 命令的典型形态：输入输出都为 LM 做了精剪
commands = {
    "find_file": {
        "class_name": "FindFile",
        "description": "search for files by name, return at most 10 results",
    },
    "search_dir": {
        "class_name": "SearchDir",
        "description": "search for <search_string> in <dir>, show top matches",
    },
    "edit": {  # 编辑命令要求给出完整的替换前后块，强制精确
        "class_name": "Edit",
        "description": "replaces lines <start> through <end> with <replacement>",
    },
}
```

它的优点是**可控、可解释、可复现**，每个动作都是一个明确定义的命令，调试时能逐命令回放。缺点是表达能力被接口上限锁死，遇到需要复杂管道的任务，LM 必须把多步操作拆成一系列 ACI 命令，步骤数膨胀带来 token 与延迟税。

### 三、范式二：事件流 + CodeAct——把动作本身写成代码

OpenHands（前身 OpenDevin）选择了完全相反的哲学：与其给 LM 一堆受限命令，不如**让 LM 直接写 Python/Jupyter 代码来驱动一切**，这就是 CodeAct。它的内核是**事件流（event stream）** 架构——所有动作（Action）与观察（Observation）都是不可变事件，追加到一条流上，AgentController 订阅这条流、驱动循环，Runtime 订阅这条流、在 Docker 沙箱里执行动作并把结果作为新事件发回来。事件溯源带来三个红利：**可重放**（任何会话都能从事件流精确重建）、**可审计**（每一步都是结构化记录）、**可扩展**（新能力就是新的 Action 类型）。2024 年 11 月，CodeAct 2.1 配合 Claude 3.5 Sonnet 在 SWE-bench Verified 上拿下 53%，是当时开源 SOTA。

```python
# OpenHands 事件流的伪代码：动作即事件，执行即回写观察
from openhands.events.action import FileWriteAction, CmdRunAction
from openhands.events.observation import CmdOutputObservation

controller.step(CmdRunAction("grep -rn 'TODO' src/"))     # 发出动作事件
obs: CmdOutputObservation = runtime.run(action)           # 沙箱执行
controller.history.add(obs)                               # 观察回写流
controller.step(FileWriteAction(path="src/fix.py", content=...))
```

优点是**表达能力天花板极高**——LM 能写任意复杂逻辑，循环、条件、异常处理都在代码里自然完成。代价是 CodeAct 把控制权下放给了 LM 写出的代码，一旦代码有副作用（rm、网络请求），爆炸半径远大于 ACI；这也是为什么 OpenHands 在 runtime 层做了重度沙箱与权限治理。从训练营角度，OpenHands 是最值得讲的"平台型"案例：事件流、Runtime、AgentSkill 三层抽象本身就是一堂软件架构课。

### 四、范式三：无 agent 三段流水线——回归传统 SE 流程

Agentless（UIUC，arXiv 2407.01489）抛出了一个尖锐的反问：你们这些 agent 循环，到底是必需的，还是 LLM 包装出来的复杂感？它的回答是后者。Agentless 完全不用 agent 循环，而是回到软件工程最朴素的三段式：**定位（localize）→ 修复（repair）→ 验证（validate）**。定位阶段用一套渐进式检索（先仓库级文件筛选，再类/函数级精筛，最终落到具体代码块），修复阶段对候选位置逐个尝试生成补丁，验证阶段跑回归测试并做格式与语法校验。论文里最硬的结论是：在不使用 agent 循环的前提下，Agentless 在 SWE-bench 上达到了与同期 agent 系统相当的命中率，而**成本只有其零头**。

```python
# Agentless 三段流水线骨架：无循环，纯流水线
def agentless_resolve(repo, issue):
    suspects = localize(repo, issue)          # 1. 定位：文件→类/函数→代码块
    patches = []
    for loc in suspects:                      # 2. 修复：对每个候选位置生成补丁
        patch = repair(repo, loc, issue)
        if patch: patches.append(patch)
    best = validate(repo, patches)            # 3. 验证：回归测试 + 语法校验
    return best
```

它的优点是**成本极低、过程可预测、无循环失控风险**——每一段都是确定性管道，便于并行与压测。缺点是**表达力被流水线形状锁死**：它假设"定位能一次定准、修复能一次改对"，遇到需要反复在仓库里试探、根据报错动态调整的难例，流水线的刚性反而拖累命中率。这是一个重要的工程启示——**去掉循环是降本的捷径，但天花板也由流水线形状决定**。变现上，Agentless 的成本故事最适合 ToB：批量处理积压 issue、CI 自动修复，按调用量计费的故事讲得通。

### 五、范式四：搜索节点 + MCTS——把定位当成搜索问题

Moatless Tools（aorwall）和基于它构建的 SWE-Search（arXiv 2410.20285）走出了第四条路：它们观察到，在大型仓库里**定位本身就是一个搜索问题**，而非阅读问题。LM 不可能把整个仓库读进上下文，于是 Moatless 把"探索仓库"建模成一棵搜索树——每个节点是一个搜索动作（如"在目录树里下钻""按符号名检索""打开文件看上下文"），从一个状态出发有多个候选动作，用 **蒙特卡洛树搜索（MCTS）** 配合一个评估函数（估计当前状态离正确修复还有多远）来决定扩展哪条分支。当某条分支的评估值不升反降，搜索会回溯去试另一条。

```python
# SWE-Search 的 MCTS 定位骨架（简化）
root = SearchNode(state=repo_root_context)
for _ in range(budget):
    leaf = select(root)                  # UCB 选最有潜力的叶节点
    child = expand(leaf)                 # 试一个搜索动作（检索/打开/下钻）
    value = evaluate(child, issue)       # 评估函数：离修复还有多远
    backprop(child, value)               # 回传价值，更新路径
best_context = root.best_trajectory()    # 取价值最高的轨迹作为修复输入
```

优点是**在大仓定位的难例上命中率显著提升**——SWE-Search 论文报告 MCTS 让定位准确率明显超过线性阅读。缺点是**概念门槛与计算门槛双高**：评估函数的设计本身就是一门艺术，树搜索的 token 与延迟开销是线性 agent 的数倍。这是一个典型的"用算力换命中率"的范式，适合攻关头部难例，不适合日常批处理。

### 六、控制流之外的隐形税：成本、上下文与误改

把四范式摆在一起，真正决定落地取舍的是三笔隐形账。**第一是成本账**：Agentless 凭"无循环"拿下最低单题成本，而 MCTS 范式的单题成本可以是前者的数倍——在批处理千级 issue 的场景，这个差距直接决定 ROI。**第二是上下文塌方账**：ACI 与 Moatless 都在精打细算每一 token 的上下文预算，OpenHands 的 CodeAct 则依赖模型自身的长上下文能力，二者在不同模型代际上的相对优劣会翻转。**第三是误改账**：自主智能体最危险的失败不是"没改对"，而是"改对了 A 却顺手改坏了 B"——这要求验证阶段不仅跑目标测试，还要跑回归套件。值得注意的是，2026 年榜单的"分数趋同"某种程度上掩盖了这三笔账的巨大差异：同样 75% 的命中率，背后可能差出一个数量级的成本和完全不同的误改风险敞口。

### 七、变现与训练营评估

从训练营产品化角度，四种范式的"可教性"差异巨大。**OpenHands 最值钱**：事件流 + Runtime + AgentSkill 是一套完整的、可拆解讲授的架构，能撑起"从零造一个云编码智能体"的中高级训练营，且平台属性强，能对接真实企业仓库做案例。**SWE-agent 次之**：ACI 概念清晰、单命令可起，适合做"工具接口设计"的入门课，把"为什么 LM 专用接口比 bash 好"讲透就是一个硬核章节。**Agentless 适合做 ToB 降本课**：三段流水线故事线干净，"去掉 agent 循环反而更省"是极具传播力的反常识钩子，能包装成"企业 issue 自动修复 ROI"主题。**Moatless / SWE-Search 适合做研究型高阶课**：MCTS 在 agent 中的应用是前沿选题，但受众窄、复现门槛高，更适合做付费论文精读或小班。整体看，OpenHands + Agentless 的组合拳最能覆盖从入门到落地的变现链路。

### 四范式控制流架构对比

```mermaid
flowchart LR
    Issue([GitHub Issue]) --> A{控制流范式}

    A -->|范式一 ACI| B1[SWE-agent]
    B1 --> B1a[受限命令集 find/search/edit]
    B1 --> B1b[REPL 循环 LM驱动]
    B1b --> B1c[窗口化输出 精剪token]

    A -->|范式二 事件流+CodeAct| C1[OpenHands]
    C1 --> C1a[事件流 Action/Observation]
    C1 --> C1b[CodeAct 代码即动作]
    C1b --> C1c[Docker Runtime 沙箱执行]
    C1c --> C1a

    A -->|范式三 无agent流水线| D1[Agentless]
    D1 --> D1a[Localize 定位]
    D1a --> D1b[Repair 修复]
    D1b --> D1c[Validate 验证]

    A -->|范式四 MCTS搜索| E1[Moatless/SWE-Search]
    E1 --> E1a[搜索节点 select/expand]
    E1a --> E1b[评估函数 估距离]
    E1b --> E1c[回溯 backprop]
    E1c --> E1a

    B1c --> Patch([补丁])
    C1a --> Patch
    D1c --> Patch
    E1c --> Patch
    Patch --> Test{隐藏测试}
    Test -->|通过| OK([✅ 解决])
    Test -->|失败| Retry([❌ 失败/误改])

    style B1 fill:#e8f0fe
    style C1 fill:#e6f4ea
    style D1 fill:#fef7e0
    style E1 fill:#fce8e6
```

### 八、针对不同场景的推荐

把四范式映射到真实诉求，选型逻辑其实很清晰。**通用 SWE 自动修复 / 开发者日常助手**：选 OpenHands，CodeAct 的表达力天花板和事件流的可审计性最匹配生产环境，配合重度沙箱治理副作用。**教学、演示、概念入门**：选 SWE-agent，ACI 是讲清"工具接口设计"的最佳教材，单命令起容器，调试友好。**高并发批处理、CI 自动修复、ToB 降本**：选 Agentless，无循环的成本优势在千级任务上是碾压性的，过程可预测便于压测。**大仓难例攻关、研究型探索**：选 Moatless / SWE-Search，MCTS 把定位当搜索问题，是攻克"线性阅读读不准"的硬骨头。若只能押注一条长期主线，OpenHands 的平台化能力最具复利价值——它把事件流、Runtime、Skill 三层抽象都做成了可替换的接口，模型代际更迭时能最低成本地吃到红利。

## 参考来源
1. [Agentless: Demystifying LLM-based Software Engineering Agents (arXiv 2407.01489)](https://arxiv.org/abs/2407.01489) — UIUC 团队提出无 agent 三段流水线（localize→repair→validate）的原始论文，成本对比数据来源
2. [SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering (arXiv 2405.15793, NeurIPS 2024)](https://arxiv.org/abs/2405.15793) — Princeton 团队提出 ACI（Agent-Computer Interface）概念与工具设计原则的奠基论文
3. [OpenHands CodeAct 2.1: An Open, State-of-the-Art Software Development Agent](https://www.openhands.dev/blog/openhands-codeact-21-an-open-state-of-the-art-software-development-agent) — All-Hands-AI 官方博客，CodeAct 2.1 在 SWE-bench Verified 达 53% 的开源 SOTA 记录
4. [SWE-Search: Enhancing Software Agents with Monte Carlo Tree Search and Contrastive Reflection (arXiv 2410.20285)](https://arxiv.org/html/2410.20285v2) — 基于 Moatless Tools 框架用 MCTS 重构代码定位阶段的论文
5. [SWE-bench Verified Leaderboard 2026: Latest Coding Agent Scores (Steel.dev)](https://leaderboard.steel.dev/leaderboards/swe-bench-verified/) — 2026 年 4 月核验的 SWE-bench Verified 榜单，SOTA 稳定在 75%–80% 区间的分数来源

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
