首页 › ai-agents › 长跑即迷：自主体漂移四栈实测

概述

把自主体从"30步内跑完"的演示，推向"30小时不崩"的长时域（long-horizon）实战，是2026年Agent落地的真正分水岭。本期横向实测四套主流自主体运行栈——LangGraph、OpenHands、AutoGen、Mini-SWE-Agent（最小自研Loop）——在同一个长跑任务下的目标漂移、上下文腐烂（context rot）与中断恢复表现。核心发现：超过六成（65%）的实战失败并非模型能力不足，而是长跑过程中自主体"忘了自己在干嘛"；而能把任务从崩溃点接续完成的，全部依赖一个被低估的原语——可重放的检查点。100行代码的Mini-SWE-Agent能在SWE-bench Verified拿到74%，恰恰证明长跑自主体缺的不是花架子，是工程纪律。

对比表格：四栈长时域表现横评

维度 LangGraph OpenHands AutoGen Mini-SWE-Agent（自研Loop）
长时域核心策略 节点级Checkpoint 事件流Event Stream重放 对话状态内联 全量历史回放，无状态外置
漂移对抗 状态Schema强约束 + 显式状态 事件裁剪 + 上下文压缩 弱（状态混入消息） 靠prompt + 短期窗口
中断恢复粒度 任意节点可断点续跑 事件回放重建完整内存态 需自建快照 重跑或自管快照
生产Checkpoint采用率 ~92%生产部署启用 内建，默认开 需自建 无
SWE-bench Verified通过率 框架不参与打榜 72% 框架不参与打榜 74%（100行代码）
上手成本 中（概念多） 中低（一个loop） 中（多Agent） 极低（100行）
变现/训练营可包装度 ★★★★ 企业级首选 ★★★★ 开源标杆 ★★★ 多Agent叙事 ★★★ 极简哲学卖点

深度分析

一、漂移病灶：六成长跑失败率从哪来

长时域自主体的头号杀手不是模型蠢，是模型"走神"。多份2026年实战复盘指出，约65%的企业级Agent失败可归因于上下文漂移（context drift），而非原始模型能力。漂移的机理很朴素：自主体每执行一步，上下文就膨胀一截——工具返回、中间推理、试错记录全部堆进历史。当历史超过某个阈值，模型的注意力被"稀释"，原本清晰的目标被噪声淹没，于是出现三类典型症状：重复调用已完成的工具、忘掉最初的验收标准、在错误的子问题上死磕。Chroma的"Context Rot"研究测试了18个模型，证实输入越长、准确率越低，即便模型声称支持百万token窗口——这是"窗口大"与"窗口内全能"的本质区别。所以长跑自主体拼的不是谁的上下文长，而是谁在长跑中保持目标清晰。判断一个栈能不能打长跑，第一个问题就该问：它的漂移对抗机制是什么。

二、LangGraph：检查点优先的存活术

LangGraph把"状态"从模糊的对话流里抽出来，做成一等公民：每个节点有一个强类型State Schema，每次转移都生成一个Checkpoint存进Checkpointer（内存/Redis/Postgres皆可）。这套设计让它在生产环境被广泛采用——有数据指出约92%的生产LangGraph部署启用了某种形式的检查点以维持对话连续性。漂移对抗上，强Schema本身就是约束：你无法在状态里偷偷塞进无关字段，自主体"走神"的物理通道被收窄。中断恢复是它的强项：崩溃后graph.invoke(None, config)传一个thread_id，从最近的Checkpoint继续，不需要从头跑。

# LangGraph 断点续跑的核心：thread_id 绑定一条可恢复的执行轨迹
from langgraph.checkpoint.postgres import PostgresSaver
graph = builder.compile(checkpointer=PostgresSaver.from_conn_string(DB))
config = {"configurable": {"thread_id": "job-7713"}}
# 崩溃前跑了一半，重连后自动从最近 checkpoint 接续
result = graph.invoke({"task": "修复登录bug"}, config)

缺点是概念税重（Channels、Reducers、Threads、Checkpointer），新人容易在"为什么要Reducer"上卡壳。训练营包装价值高：企业级、可审计、可恢复，是甲方最爱听的三个词。

三、OpenHands：事件流重放的"录像机"

OpenHands（前身OpenDevin，AllHands维护）走的是另一条路——不存"状态摘要"，存"事件流"。自主体执行的每一步（思考、动作、观察）都作为不可变事件追加到一个EventStream里，状态是事件流在任意时刻的"投影"。这意味着两件事：第一，崩溃恢复本质是重放事件流重建内存态，类似数据库的WAL；第二，上下文压缩可以无信息损失地做——原始事件永远在，压缩只是当前视图。这让它能在SWE-bench Verified拿到约72%，且GitHub星标超70K、累计融资1880万美元。它跑的是完整自主循环（含浏览、终端、文件编辑），长跑能力内建而非外挂。

# OpenHands 哲学伪代码：状态 = reduce(events)，恢复 = 从头重放
state = initial_state
for event in event_stream[start:]:      # 崩溃点之后的事件
    state = reducer(state, event)        # 重建到当前
agent = Agent(state)                     # 从重建态继续

优点是可重放、可审计、压缩无损；缺点是事件流会无限增长，磁盘与重放开销随任务时长线性上升，超长任务需要配合事件归档策略。

四、AutoGen：状态混进对话的代价

AutoGen擅长多角色对话（用户Agent、助手Agent、评论者Agent），但它的"状态"长期是隐式地塞在消息历史里的——谁说了什么、决策到哪一步，全靠你从一长串消息中"读"出来。这对短任务无伤大雅，对长跑是慢性中毒：随着消息堆积，关键决策被埋在数百轮对话深处，模型每次都要"翻完聊天记录"才能确认自己在哪一步，漂移由此加剧。AutoGen没有内建的可恢复Checkpoint，断点续跑需要开发者自己把对话快照序列化到外部存储，恢复时再灌回去——而这个"灌回去"往往无法保证语义等价（消息顺序、缓存策略、tool call id都对齐很难）。结论：AutoGen在长跑任务上是四栈里最吃力的，它适合短而密的协作对话，不适合"30小时无人值守"。如果一定要用它跑长任务，必须在外层套一层自管的Checkpoint+压缩，等于把别的栈的活自己重写一遍。

五、Mini-SWE-Agent：100行复刻74%的启示

SWE-agent团队的反讽之作：Mini-SWE-Agent用约100行代码，在SWE-bench Verified上拿下约74%，比复杂的OpenHands脚手架还高两个点。它在GitHub的Tagline直接发问——"我们在2014年建了SWE-bench和SWE-agent，引爆了coding agent革命；现在我们想问，当初那套复杂里有多少是必要的？"。这条数据对长跑自主体的选型是当头一棒：漂移和崩溃，常常是过度工程自己造出来的。越多的中间层、越复杂的状态机、越花哨的"记忆模块"，反而制造了越多让自主体走神的噪声表面。Mini-SWE-Agent的纪律很朴素：一个清晰的Agent Loop、一个干净的工具集、一个明确的停止条件。它没有花哨Checkpoint，但因为没有冗余状态，重跑成本极低。给我们的启示是：长跑自主体的第一步不是加功能，是减熵——先把Loop写干净，再决定要不要上Checkpoint和压缩。

# Mini-SWE-Agent 的极简 Loop 骨架（示意）
while not done and steps < MAX_STEPS:
    obs = view()                      # 看当前文件/错误
    action = llm(PROMPT, obs, history) # 决定下一步
    result = run(action)              # 执行
    history += [(action, result)]     # 只记必要轨迹
    done = check_goal(result)         # 明确停止条件

六、压缩即续命：上下文compaction三式

长跑绕不开上下文体积，而体积一涨，rot就来。当前主流的compaction有三种范式：摘要式压缩（让模型把旧历史总结成几句话塞回去，实现简单但有损，可能丢关键细节）、检索式剔除（把历史转存向量库，只保留最近窗口+按需召回，无信息损失但召回质量决定成败）、结构化外置（把可重算的中间结果——工具输出、检索片段——用引用占位符替代，需要时重算/重取，OpenHands和Codex系倾向于这条）。值得注意的是，OpenAI于2026年2月5日发布的GPT-5.3-Codex在compaction上做了关键扩展，被视为让长跑coding agent真正可用的一步。对长跑自主体而言，compaction不是优化项，是生存项——一个不做压缩的自主体，长跑时上下文必然触顶，触顶那一刻就是漂移的拐点。选型时该问的不是"支不支持压缩"，而是"压缩有没有信息损失、损失的部分能不能从外部源恢复"。

七、中断恢复：从崩溃点继续 vs 从头再来

把六和前面合起来看，长跑自主体的成败最终压在一个判断上：任务中途崩了，能不能从崩溃点接着干。四种栈给出四种答案。LangGraph：能，任意节点Checkpoint，传thread_id续跑。OpenHands：能，事件流重放重建态。AutoGen：勉强，需自建快照且语义等价难保证。Mini-SWE-Agent：默认不能，但因为干净，重跑代价低。这里藏着一个被忽视的成本账：很多团队上了Checkpoint却从不演练恢复，等到真崩溃才发现Checkpoint写坏了、版本对不上、状态缺字段——恢复比重跑还贵。长跑自主体的可靠性 = Checkpoint质量 × 恢复演练频率，二者缺一不可。这也是为什么"最小可恢复单元"比"最大上下文窗口"更该成为长跑设计的第一指标：先保证能停下来、能接上去，再谈跑多远。

Mermaid架构图：长跑自主体存活循环

flowchart TD
    A[长跑任务启动] --> B[Agent Loop: 思考-行动-观察]
    B --> C{上下文体积超阈值?}
    C -->|否| D[继续执行]
    C -->|是| E[Compaction 压缩<br/>摘要/剔除/外置]
    E --> D
    D --> F{目标漂移检测<br/>重复调用/标准遗忘?}
    F -->|检测到漂移| G[重注入目标 + 回滚最近步]
    G --> B
    F -->|正常| H[写 Checkpoint/事件]
    H --> I{崩溃/超时?}
    I -->|否| J{达到验收标准?}
    J -->|否| B
    J -->|是| K[任务完成]
    I -->|是| L[从最近 Checkpoint 恢复]
    L --> M{Checkpoint 完好?}
    M -->|是| B
    M -->|否| N[降级: 重跑或人工介入]
    style C fill:#fff3cd
    style F fill:#fff3cd
    style I fill:#f8d7da
    style H fill:#d4edda

推荐方案

企业级长跑（合规可审计）：首选 LangGraph。强Schema + 92%生产Checkpoint采用率 + thread_id断点续跑，满足甲方对"可中断、可恢复、可追溯"的全部要求。务必把Compaction做在节点转换处，并定期演练恢复。

开源自主coding/工程长跑：首选 OpenHands。事件流重放是四栈里唯一无信息损失的恢复范式，72% SWE-bench Verified证明其自主循环的成熟度。适合需要浏览/终端/文件编辑的开放式长任务，注意配事件归档策略。

学习/极简起步：从 Mini-SWE-Agent 的100行Loop开始。先用它跑通一个长任务，感受漂移和触顶，再决定要不要加Checkpoint——"先减熵再加固"，避免一上来就被框架概念税淹没。

明确避开：用AutoGen跑"30小时无人值守"。它的状态隐式内联在对话里、无内建可恢复Checkpoint，是四栈里长跑最吃力的。短而密的多角色协作才是它的主场。

通用长跑纪律（与栈无关）：①明确停止条件，否则自主体永不收敛；②Compaction做在状态转换处而非上下文将爆时；③Checkpoint必须演练恢复，写得出≠接得上；④把"最小可恢复单元"看得比"最大上下文窗口"更重。

参考来源

  1. Agent Context Engineering 2026: Sliding Windows, Hierarchical Memory — "65%企业级Agent失败源于上下文漂移而非模型能力"的核心数据出处
  2. Long-Running Autonomous Agents: Drift, Checkpointing, Recovery — 长跑自主体漂移、检查点、恢复机制的实战复盘
  3. OpenHands vs SWE-agent (2026): SWE-bench Scores Compared — OpenHands 72% / Mini-SWE-Agent 74% 的对比数据
  4. GitHub: SWE-agent/mini-swe-agent — "100行AI Agent"项目原文，对复杂度必要性的反问
  5. Context Rot: How Increasing Input Tokens Impacts LLM Performance (Chroma Research) — 18模型测试，输入越长准确率越低的"context rot"研究
  6. LangGraph Checkpointing and Persistence Guide — "92%生产部署启用检查点"及Checkpoint/Thread机制说明

[!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学通信知识星球海报-扫码加入

📎 本分类最新文章