自主智能体在"单轮、单议题"任务上已接近人类，一旦任务跨小时、跨多文件、跨多个上下文窗口，塌方几乎是注定的。SWE-EVO 基准把这件事量化得格外刺眼：GPT-5.4 配 OpenHands 在长程软件演进上只拿到 25%，而同族模型在 SWE-Bench Verified 单议题上是 72.80%——近三倍的鸿沟。塌方不来自模型智力，而来自执行内核缺了三根梁：子目标分解（防止一次想做完）、检查点（防止中途崩盘清零）、回滚（防止坏状态污染下一个窗口）。本文沿这三轴，实测 Anthropic 长程 Harness、Vertex AI 生产级检查点、Crab 语义运行时三套实战方案，给出可复用的代码骨架与场景选型。
| 栈（代表实现） | 核心机制 | 关键数据 | 上手难度 | 变现潜力 | 适用场景 |
|---|---|---|---|---|---|
| 分解栈·初始化器+编码器（Claude Agent SDK Harness） | 特性清单 JSON + 单特性增量 + git 提交 | claude.ai 克隆拆出 200+ 特性 | 中（需写 prompt 与交接协议） | 高（训练营标准范式） | 跨多上下文窗口的应用构建 |
| 分解栈·三体架构（planner/generator/evaluator） | 生成-评估对抗 + 任务块拆分 + 结构化交接 | 多小时全栈应用无人值守 | 中高 | 高（产品级交付） | 主观质量+可验证正确性双约束 |
| 检查点栈·应用层（Vertex AI Agent Engine + GCS/Firestore） | Protobuf 序列化 + 三触发器 + 两阶段提交 | 58 分钟超时从清零→秒级恢复 | 中（分布式工程） | 中高（企业可靠性卖点） | 金融/合规文档长任务 |
| 检查点栈·语义层（Crab / eBPF） | turn 级 OS 效果分类 + 与 LLM 等待重叠 | 正确率 8%→100%，流量 -87%，开销 1.9% | 高（eBPF/OS） | 中（基础设施层） | 高密度沙盒、RL rollout 分支 |
| 回滚栈·git+context reset（Anthropic Harness） | 干净状态可合并 + 结构化交接对抗 context anxiety | 坏代码可 revert 到已知良态 | 低 | 高（通用） | 所有长程编码 Agent |
| 标尺·SWE-EVO | 多步骤演进基准 + Fix Rate 部分进度指标 | 48 任务/均 21 文件/均 874 测试 | 低（评测用） | 中（选型背书） | Agent 能力水位测量 |
SWE-EVO（arXiv:2512.18470，2025-12 提交、2026-05 修订）的杀伤力在于它把"真实软件工程"原样端上桌：48 个任务，平均每个要改 21 个文件，验证用的测试套件平均 874 条。现实里工程师解读高层需求、跨多文件协调、在多轮迭代里演进代码库还不破坏既有功能——这恰恰是单议题基准（修一个 bug、加一个小 feature）刻意回避的。结果就是那道鸿沟：GPT-5.4 + OpenHands 在 SWE-EVO 上仅 25%，而 GPT-5.2 在 SWE-Bench Verified 上是 72.80%。同一代模型，换一个考场，分数直接腰斩再腰斩。SWE-EVO 还顺带补了一个被忽视的指标——Fix Rate，用来度量长程任务上的"部分进度"，因为这类任务很少非黑即白，部分修复本身就是价值。这条曲线告诉我们：瓶颈不在模型，在 Harness。模型有智力，但没有"跨窗口继续干活"的脊柱。
Anthropic 在《Effective harnesses for long-running agents》（2025-11-26）里抓到了两个反复出现的失败模式。其一，一次想做完：Agent 试图一口气 one-shot 整个应用，结果上下文在中途耗尽，留下"半实现、无文档"的状态，下一个窗口的 Agent 只能猜，把大量时间花在"让基础应用重新能跑"上。其二，假完工：项目推进到中后期，新启动的 Agent 环顾四周，看到已有进度，直接宣布"搞定"。解法是把任务拆成两半——初始化器 Agent 只在首次运行出现，负责搭好脚手架（init.sh、claude-progress.txt 进度日志、首个 git commit）；编码器 Agent 在其后每个窗口只做增量推进，并留下干净交接物。关键动作是让初始化器把高层 prompt 扩写成一份详尽特性清单——克隆 claude.ai 时它写出了 200+ 条特性，每条结构化为 JSON 并标记 passes: false。后续 Agent 只能改 passes 字段、不能删改测试。仅一次做一个特性，是压制"一次做完"冲动的唯一解。
特性条目的真实结构（来自 Anthropic 官方示例）值得逐字抄进自己的 Harness：
{
"category": "functional",
"description": "New chat button creates a fresh conversation",
"steps": [
"Navigate to main interface",
"Click the 'New Chat' button",
"Verify a new conversation is created",
"Check that chat area shows welcome state",
"Verify conversation appears in sidebar"
],
"passes": false
}
这里有个被反复验证的细节：用 JSON 而非 Markdown。模型倾向于"顺手改写"Markdown，却较少篡改 JSON 文件。配套的硬约束 prompt 一字不能软："It is unacceptable to remove or edit tests because this could lead to missing or buggy functionality." 每个窗口的编码器执行同一套"归位"流程：pwd 确认目录 → 读 git log 与 progress 文件 → 从清单里挑最高优先级且未完成的特性 → 实现 → 端到端测试（用 Puppeteer 之类的浏览器自动化"像人一样测"）→ git commit 写描述性信息 → 回写 progress 文件。这套循环本身不值钱，值钱的是它把"长程任务"降维成了"可重复的短程任务 + 持久交接物"。在 2026-03 的《Harness design》里，这套思路被进一步抽象成 planner / generator / evaluator 三体架构（灵感来自 GAN 的生成-对抗），并把"用钩子或脚本让 Agent 持续迭代"的社区打法戏称为 "Ralph Wiggum 法"——本质都是把分解+交接工程化。
Brandon Hendricks 在 2026-04-09 的生产复盘里讲了一个血淋淋的案例：一个为金融服务客户做监管文件分析的 Agent，处理上千页文件，某次 Cloud Run 在第 58 分钟超时——没有检查点，全部从头再来。这把"检查点不是可选项"钉死在了墙上。生产级 Agent 面对的失败谱极广：Cloud Run 撞内存上限、外部 API 超时、Gemini 限流、硬件故障。他的检查点系统分三层。序列化层用 Protocol Buffers 打包对话记忆、任务队列、进度标记、中间计算、API 响应与运行时配置；高维 Gemini embedding 单独存进 Vector Search，主检查点只留引用。存储层是 Cloud Storage 桶（/checkpoints/agent-id/task-id/timestamp/ + /latest/）配 Firestore 元数据，便于不扫描全桶就找到"最近一个有效检查点"。触发层是三种触发器并行：时间触发（文档类每 5 分钟，实时对话类每 30 秒）、里程碑触发（500 页文档每处理完一章、数据转换每 1000 条批次）、资源触发（内存超 80% 强制落盘，防 OOM 丢状态）。
应用层检查点解决"清零"，却解决不了一个更深的问题：Agent-OS 语义鸿沟。Crab（arXiv:2604.28138，2026-04-30）一句话点破——Agent 框架只看到 tool call，看不到它在 OS 侧的副作用；OS 只看到状态变化，却没有 turn 级上下文判断哪些值得恢复。这个鸿沟藏着一个惊人的稀疏事实：超过 75% 的 Agent turn 根本不产生任何"与恢复相关的状态"，即绝大多数检查点是白做的。现有方案走两个极端：应用级恢复（只留聊天历史，丢了 OS 副作用）便宜但残缺；逐 turn 全量检查点正确但贵到无法高密度部署。Crab 的做法是用 eBPF 检查器在宿主侧透明分类每个 turn 的 OS 可见效果，按需决定检查点粒度；协调器把检查点对齐到 turn 边界，并与 LLM 等待时间重叠执行；宿主级引擎在共置的多个沙盒间调度检查点流量。实测在 shell 密集与代码修复负载上：恢复正确率从 8%（仅聊天）拉到 100%，检查点流量最多砍 87%，执行时间仅比无故障慢 1.9%。这是检查点从"无脑全量"走向"语义感知"的转折点。
分解防止"做太多"，检查点防止"全丢"，回滚防止"坏状态污染未来"。Anthropic 的回滚栈朴素到几乎免费：让 Agent 把进度 commit 到 git，写描述性信息，必要时 git revert 到已知良态。它的潜台词是——代码库本身就是最可靠的检查点，git 就是回滚引擎。配套要求是每个窗口结束时留下"干净状态"：无重大 bug、有序、文档齐全，可直接 merge 到 main。2026-03 的《Harness design》点破了一个比"上下文耗尽"更隐蔽的敌人——context anxiety（上下文焦虑）：模型在自以为接近上下文上限时，会提前收尾。解法不是 compaction（原地压缩、保留同一 Agent 继续，但焦虑仍在），而是 context reset：彻底清空上下文、重启一个新 Agent，靠结构化交接物把前一任的状态与下一步带过去。reset 同时治好了两件事——长任务上的连贯性丢失，与 context anxiety。回滚的另一面是检查点防腐：Hendricks 给出三层防护——SHA-256 校验、保留最近 5 个版本（最新版损坏就回退前版）、写完立即读回验证（write-verify，把腐败抓在写入时而非恢复时）。
当多个 Agent 协作时，检查点必须对齐，否则恢复时各 Agent 状态发散。Hendricks 的协调器走两阶段提交：先广播检查点请求，所有参与 Agent 在 staging 区预备，全员确认就绪后，协调器才原子地提交整组检查点，并把全局检查点标记记进 Firestore。复杂架构则用分层检查点：编排 Agent 只存文档队列与整体进度，抽取 Agent 存解析内容与实体，分析 Agent 存计算结果，摘要 Agent 存生成摘要与置信度——每一层只存自己粒度的状态，恢复时按层重建。这与轴一的"初始化器+编码器"分层、Crab 的"turn 级语义分层"是同一个思想在不同尺度的投影：检查点粒度必须匹配抽象层级，全量是浪费，缺失是灾难。
flowchart TD
U[高层需求: '克隆 claude.ai'] --> INIT
subgraph DECOMP[轴一·子目标分解]
INIT[初始化器 Agent<br/>仅首次运行]
INIT --> FL[特性清单 JSON<br/>200+ 条 passes:false]
FL --> SCRIPT[init.sh + 首个 git commit<br/>claude-progress.txt]
end
SCRIPT --> LOOP
subgraph EXEC[编码器 Agent 每窗口循环]
LOOP[1. pwd + 读 git log/progress]
LOOP --> PICK[2. 选最高优先级未完成特性]
PICK --> IMPL[3. 增量实现 单特性]
IMPL --> TEST[4. 端到端测试<br/>浏览器自动化 像人一样测]
TEST --> CP{检查点决策}
CP -->|语义稀疏判定<br/>75% turn 无副作用| SKIP[跳过检查点]
CP -->|有 OS 副作用| SNAP[落盘 Protobuf + GCS]
TEST --> COMMIT[5. git commit 描述性信息]
COMMIT --> PASS{测试通过?}
PASS -->|是| FLIP[passes:true 回写 JSON]
PASS -->|否| REVERT[轴三·git revert<br/>回到已知良态]
REVERT --> PICK
end
SNAP --> RESET[context reset<br/>结构化交接对抗 context anxiety]
FLIP --> RESET
RESET --> NEXT[下一个上下文窗口]
NEXT --> LOOP
style DECOMP fill:#e8f5e9
style EXEC fill:#fff3e0
style REVERT fill:#ffebee
训练营可直接变现的部分，是"轴一+轴三"这对组合：初始化器-编码器双 Agent 架构、特性清单 JSON、git 回滚、context reset 交接。它的上手门槛在 prompt 与交接协议设计，而非基础设施，适合做成"长程编码 Agent 实战营"的标准范式——学员用一个仓库就能复现"从一句 prompt 到小时级无人值守全栈应用"的体验，这是 2026 年最具传播力的演示形态。企业可靠性卖点集中在轴二：把"58 分钟清零→秒级恢复"做成合规与金融长任务的产品差异化，检查点即卖"不丢工作"的保险。
变现天花板在轴二的语义层（Crab 式 eBPF 运行时）：技术壁垒极高、依赖 OS/内核能力、客户群窄（高密度沙盒、RL rollout 分支、spot 实例场景），更适合做底层基础设施或被云厂商吸收，而非独立 SaaS。
三轴不是三选一，而是一条脊柱：分解让任务可继续，检查点让状态可恢复，回滚让坏状态不传染。缺任何一轴，长程 Agent 都会在第 N 个上下文窗口准时塌方——25% 那条曲线就是缺脊柱的代价。
[!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 等场景全覆盖。