自主编程智能体四范式控制流实测

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 的命令定义）：

# 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。

# 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 系统相当的命中率，而成本只有其零头。

# 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） 配合一个评估函数（估计当前状态离正确修复还有多远）来决定扩展哪条分支。当某条分支的评估值不升反降，搜索会回溯去试另一条。

# 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 的组合拳最能覆盖从入门到落地的变现链路。

四范式控制流架构对比

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 三层抽象都做成了可替换的接口，模型代际更迭时能最低成本地吃到红利。