# 长程智能体三轴：分解·检查点·回滚实测 ## 概述 自主智能体在"单轮、单议题"任务上已接近人类，一旦任务跨小时、跨多文件、跨多个上下文窗口，塌方几乎是注定的。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 能力水位测量 | ## 深度分析 ### 一、长程塌方的两条曲线：25% 与 72.8% 之间发生了什么 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。模型有智力，但没有"跨窗口继续干活"的脊柱。 ### 二、轴一·子目标分解：初始化器 Agent 与那份 200 条特性清单 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： ```json { "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 法"**——本质都是把分解+交接工程化。 ### 四、轴二·检查点：从 58 分钟清零到三种触发器 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 丢状态）。 ### 五、轴二·语义稀疏：Crab 运行时把检查点流量砍掉 87% 应用层检查点解决"清零"，却解决不了一个更深的问题：**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%**。这是检查点从"无脑全量"走向"语义感知"的转折点。 ### 六、轴三·回滚：git revert 即记忆，干净状态即交接 分解防止"做太多"，检查点防止"全丢"，回滚防止"坏状态污染未来"。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 级语义分层"是同一个思想在不同尺度的投影：**检查点粒度必须匹配抽象层级，全量是浪费，缺失是灾难**。 ## 长程执行内核架构图 ```mermaid flowchart TD U[高层需求: '克隆 claude.ai'] --> INIT subgraph DECOMP[轴一·子目标分解] INIT[初始化器 Agent
仅首次运行] INIT --> FL[特性清单 JSON
200+ 条 passes:false] FL --> SCRIPT[init.sh + 首个 git commit
claude-progress.txt] end SCRIPT --> LOOP subgraph EXEC[编码器 Agent 每窗口循环] LOOP[1. pwd + 读 git log/progress] LOOP --> PICK[2. 选最高优先级未完成特性] PICK --> IMPL[3. 增量实现 单特性] IMPL --> TEST[4. 端到端测试
浏览器自动化 像人一样测] TEST --> CP{检查点决策} CP -->|语义稀疏判定
75% turn 无副作用| SKIP[跳过检查点] CP -->|有 OS 副作用| SNAP[落盘 Protobuf + GCS] TEST --> COMMIT[5. git commit 描述性信息] COMMIT --> PASS{测试通过?} PASS -->|是| FLIP[passes:true 回写 JSON] PASS -->|否| REVERT[轴三·git revert
回到已知良态] REVERT --> PICK end SNAP --> RESET[context reset
结构化交接对抗 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。 ## 推荐方案：按场景选栈 - **跨窗口应用构建 / C 端长任务产品**：轴一（初始化器+编码器）+ 轴三（git revert + context reset）。零额外基础设施，最高性价比。代表：Claude Agent SDK Harness、planner-generator-evaluator 三体。 - **金融/合规/法律文档长任务（企业）**：轴一 + 轴二应用层（Vertex AI Agent Engine + GCS/Firestore + Protobuf + 两阶段提交）。卖点是不丢工作、可审计恢复。 - **高密度沙盒 / RL 训练 / spot 实例**：轴二语义层（Crab / eBPF），用 turn 级分类把检查点开销压到 1.9%。 - **多 Agent 协作编排**：轴二分层检查点 + 两阶段提交，按编排/抽取/分析层级存各自粒度状态。 - **能力选型背书**：用 SWE-EVO（48 任务/均 21 文件/均 874 测试）+ Fix Rate 指标，替代被 SWE-Bench Verified 掩盖的长程盲区，避免在单议题分数上误判。 三轴不是三选一，而是一条脊柱：**分解让任务可继续，检查点让状态可恢复，回滚让坏状态不传染**。缺任何一轴，长程 Agent 都会在第 N 个上下文窗口准时塌方——25% 那条曲线就是缺脊柱的代价。 ## 参考来源 1. [Effective harnesses for long-running agents — Anthropic Engineering (2025-11-26)](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) — 初始化器+编码器双 Agent、特性清单 JSON、git 回滚、干净状态交接的官方工程原文。 2. [Harness design for long-running application development — Anthropic Engineering (2026-03-24)](https://www.anthropic.com/engineering/harness-design-long-running-apps) — planner/generator/evaluator 三体架构、context anxiety、context reset vs compaction、Ralph Wiggum 法。 3. [SWE-EVO: Benchmarking Coding Agents in Long-Horizon Software Evolution Scenarios — arXiv:2512.18470](https://arxiv.org/abs/2512.18470) — 长程软件演进基准，48 任务/均 21 文件/均 874 测试，GPT-5.4+OpenHands 25% vs SWE-Bench 72.80% 鸿沟，Fix Rate 指标。 4. [Crab: A Semantics-Aware Checkpoint/Restore Runtime for Agent Sandboxes — arXiv:2604.28138](https://arxiv.org/abs/2604.28138) — eBPF turn 级语义检查点，75% turn 无恢复状态，正确率 8%→100%、流量 -87%、开销 1.9%。 5. [Implementing Agent Checkpointing and Recovery Patterns for Long-Running AI Tasks in Production — Brandon Lincoln Hendricks (2026-04-09)](https://brandonlincolnhendricks.com/research/implementing-agent-checkpointing-recovery-patterns-long-running-ai-tasks) — 生产级 Protobuf 序列化、三触发器、两阶段提交、分层检查点、SHA-256 防腐与 write-verify 实战。 > [!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 等场景全覆盖。