# 长跑agent最怕崩：三把断点续传新刀 ## 导语：你卷的是"快"，海外这周卷的是"崩了能不能续" 你让 AI agent 跑一个两小时的活——重构一个模块、批量处理几千条数据、把一个 feature 从一句话需求做成可上线的 PR。跑到第 90 分钟，网断了，或者进程 OOM 被杀，或者你的笔记本没电自动休眠。agent 进程一关，前面所有的上下文、所有中间产物，全部归零。重来的代价是：再烧一遍 token、再等一遍时间，还可能因为复现不出来而debug到天亮。 这是国内做 AI agent 的人最常踩、却最少有人正视的坑。我们一直在卷"哪个 agent 写代码更快""哪个模型更强",而海外这一周在卷一个更值钱的问题:**agent 跑崩了能不能续?同一个任务能不能复现?改的代码能不能在 CI 里审计?** 今天的情报就是围绕这个信息差展开的——三把近期刚开源的新刀,正在把"持久化执行(durable execution)"这个后端圈玩了十年的老概念,重新打磨成 AI agent 的标配基建。三把刀切入点完全不同,但解决的却是同一件事:**让长跑的 agent 不再怕崩。** ## 一、被低估的真相:agent 最大的坑不是"写得烂",是"不可恢复" 先说清楚一个认知差。绝大多数人评判一个 coding agent,看的是"它写的代码对不对、快不快"。但真正在生产里用 agent 的人,噩梦是另一回事: - **不可恢复**:一个跑了 90 分钟的 agent 任务,崩了就得从零重来。token 烧了就烧了。 - **不可复现**:同一个 prompt,今天跑和明天跑结果不一样。你没法把它接进 CI,因为 CI 要求确定性。 - **不可审计**:agent 一通操作改了几十个文件,除了聊天记录,没有任何结构化的执行轨迹。出事了说不清它到底干了什么。 这三个"不可",对应的是后端工程里一个成熟的概念叫 **durable execution(持久化执行)**。它的代表是 Temporal、DBOS、Restate 这类工作流引擎,核心思想就一句话:**把每一步的状态存进数据库,进程崩了,从最后一个检查点续跑,而且保证每个动作只执行一次(exactly-once)。** 这套东西,互联网大厂的后端团队用了好些年,但国内做 AI 应用的几乎没人碰——大家觉得那是"搞微服务的人才用的"。而最近这一两周,海外开源圈集体在干一件事:**把 durable execution 拽到 AI agent 的脚下。** 下面这三把刀,就是这一波的代表。 ## 二、三把断点续传新刀 ### 刀一:DBOSify —— 用你已有的 Postgres,把任何 Python 函数变成"崩了能续" - **仓库**:[github.com/dbos-inc/dbosify-py](https://github.com/dbos-inc/dbosify-py) - **文档**:[docs.dbos.dev/explanations/dbosify](https://docs.dbos.dev/explanations/dbosify) - **语言/协议**:Python / MIT - **价格**:**完全免费开源**,唯一依赖是一个 Postgres(绝大多数团队本来就有) - **热度**:GitHub 184⭐,2026 年 6 月 9 日创建,6 月 24 日还在更新 DBOSify 的定位极其精准:**它是 Temporal Python 的"平替"(drop-in replacement)。** Temporal 是 durable execution 领域的标杆,但它需要你单独部署一套 Temporal server、维护一套 gRPC 协议,门槛不低。DBOSify 的做法粗暴有效——你只需要一个 Postgres。 它的卖点在于迁移成本几乎为零: ```shell pip install dbosify ``` 然后把代码里的 `from temporalio import ...` 改成 `from dbosify import ...`,把客户端连到 Postgres,完事。原有的 workflow、activity、signal、retry、recovery 全部照常工作。 它怎么做到"崩了能续"?README 里讲得很清楚(DBOSify 的"How It Works"): > 用一个确定性解释器跑 workflow,所有非确定性动作(调用 activity、定时器、收发信号)在执行前,都先把检查点写进 Postgres。**Recovery 时,在一个新 worker 上重放(replay)同样的操作序列,从记录的检查点恢复,执行从断点处继续,且每个动作恰好执行一次。** 翻译成人话:你的 agent 任务跑了 90 步,第 91 步崩了。重启后,它不重跑前 90 步,而是直接从第 91 步接着干——因为前 90 步的"已完成动作"已经躺在 Postgres 里了。这个特性,作者专门写了 **kill-and-recover(杀掉再恢复)** 的测试来保证。 **为什么值得中国开发者关注**:它把"要不要上 Temporal"这个纠结了几年的决策,降级成了"反正我有 Postgres"。对你正在跑的 AI agent pipeline——批量调 LLM、多 agent 编排、长链路 RAG——加一层 DBOSify,立刻拿到崩溃恢复和 exactly-once,不用多部署任何中间件。 ### 刀二:Agentic Orchestrator(agentico)—— DoorDash 开源,一个 prompt 跑出可审核的 PR - **仓库**:[github.com/doordash-oss/agentic-orchestrator](https://github.com/doordash-oss/agentic-orchestrator) - **语言/协议**:Go / Apache-2.0 - **价格**:**免费开源**,自带 LLM key 即可 - **热度**:51⭐,2026 年 5 月 12 日创建,**今天(7 月 1 日)还在 push** - **本地命令**:`agentico` 这是外卖巨头 DoorDash 开源的工程化 agent 编排器,一句话 slogan 把它的野心说尽了: > **One-shot the moonshot — then do it ten times in parallel.**(一次性梭哈大目标——然后并行再跑十遍。) 它解决的是一个比"写代码"更难的问题:**怎么把一句模糊的 feature 需求,变成一个能 review 的 PR,中间不掉链子、不产出 AI slop(看着像样、实则经不起推敲的代码)。** 它的设计哲学是"上下文是构建出来的,不是碰运气碰出来的"。你描述一个 feature 后,它不是马上让模型改文件,而是先走一条**持久化的工程流水线**: 研究上下文 → 提澄清问题 → 设计方案 → 拆解 roadmap → 用 tracer-bullet 阶段打通路径 → TDD 填充实现 → 验证 → 代码审查 → 发 PR。 而且这条流水线是**分阶段、带检查点(checkpoint)的**:你不需要盯着每一个 prompt,只在那些"需要人判断"的关卡介入即可。多个 feature 还能从同一个终端并发跑。 **国内对比**:国内做 AI coding,大多数人还停在"在对话框里一问一答"或"用 Copilot/Cursor 补全"的阶段。Dify、Coze 这类平台能搭工作流,但没有 Temporal 级别的持久化和 checkpoint,跑到一半断了一样白干。agentico 把"feature → 可审核 PR"这条链路工程化、持久化了,这是国内工具的空白区。 ### 刀三:rigorix —— 把 agent 编译成 DAG,专治"同一个任务跑两次结果不一样" - **仓库**:[github.com/arman-jalili/rigorix-oss](https://github.com/arman-jalili/rigorix-oss) - **语言/协议**:Rust / Apache-2.0(crate 已上架 crates.io) - **价格**:**免费开源** - **热度**:9⭐,2026 年 6 月 13 日创建,6 月 30 日更新(早期项目,值得早期盯) 前两把刀解决"崩了能续",这把刀解决的是**"不可复现 + 不可审计"**。它的自我定位是: > **A deterministic coding-agent runtime for repeatable, auditable AI software engineering.**(一个确定性的 coding-agent 运行时,面向可复现、可审计的 AI 软件工程。) 它最核心的动作,是把自然语言任务**编译成一个有向无环图(DAG)**,然后再执行。README 原文说得直白: > Rigorix 把自然语言开发任务编译成可执行的 DAG。它不依赖开放式的 agent 循环,而是把**规划(planning)和执行(execution)分离**:先生成执行计划、校验它,然后在可配置的策略(policy)、权限(permission)、预算(budget)约束内执行。 这意味着什么?**LLM 负责生成代码,Rigorix 负责治理执行。**(原文:"The LLM generates code; Rigorix governs execution.") 它有三种用法,刚好覆盖三个场景: - **CLI(`rigorix`)**:本地开发的交互式 TUI + 脚本 - **GitHub Action(`rigorix-action`)**:在 CI/CD 里做 PR 治理和自动化代码生成 - **Engine**:驱动上面两者的核心库 它还构建在作者另一个叫 **Guardian Framework** 的"架构强制框架"之上——保证 agent 的每一次改动都能追溯到架构规范,由校验脚本验证,受冻结的模块契约约束。 **为什么这条信息差值钱**:国内把 AI coding agent 接进 CI/CD 的团队极少,绝大多数还停在"人盯着 agent 改代码"。rigorix 提供的 DAG + 策略/权限/预算约束 + 架构契约这套组合,是真正能让 AI 改代码"上得了 CI、过得了审计"的形态。对金融、通信、政企这类对合规审计敏感的场景,这正是缺的那块拼图。 ## 三、三把刀怎么配合:一张图看懂"持久化 agent"的全链路 ```mermaid flowchart TD A["一句话 feature 需求"] --> B["agentico 编排器
构建上下文 + 分阶段 roadmap"] B --> C{"需要可复现/审计?"} C --|否,只要崩溃恢复|--> D["DBOSify
每步检查点写进 Postgres"] D --> E{"进程崩了?"} E --|是|--> F["新 worker 重放
从断点续跑 exactly-once"] E --|否|--> G["正常完成"] F --> G C --|是,要进 CI|--> H["rigorix
编译成 DAG + 策略/权限/预算"] H --> I["GitHub Action 接入 PR"] I --> J["可复现 + 可审计的 PR"] G --> J style F fill:#fde68a,stroke:#b45309 style H fill:#bfdbfe,stroke:#1d4ed8 ``` 看懂这张图,你就看懂了海外这波"agent 基建"的底层逻辑:**不是让 agent 更聪明,而是给 agent 套上"崩溃兜底 + 复现审计"的两道保险。** ## 四、信息差总结:你知道的 vs 海外在卷的 | 维度 | 国内主流认知(你已知的) | 海外这周在卷的(信息差) | |------|----------------------|----------------------| | agent 评判标准 | 写代码快不快、准不准 | 崩了能不能续、能不能复现、能不能审计 | | 长任务保护 | 重试 + 日志,崩了重来 | durable execution,断点续传,exactly-once | | 工作流引擎 | 自研或不用,觉得 Temporal 太重 | DBOSify:一个 Postgres 就够,平替 Temporal | | feature→PR | 人在对话框里一步步带 | agentico:持久化流水线,人在检查点介入 | | AI 改代码进 CI | 极少有人做 | rigorix:DAG + 策略 + 预算,GitHub Action 治理 | | 成本 | 崩一次重跑一次,token 翻倍烧 | 崩了从断点续,只重跑尾部 | ## 五、行动指南:三步把这套信息差变成你的护城河 **第一步(最低成本,今天就能做)**:如果你有任何一个跑得比较长的 Python 任务——批量调 LLM、多步数据处理、agent pipeline——花半小时给它套上 [DBOSify](https://github.com/dbos-inc/dbosify-py)。你不需要装 Temporal,只要有个 Postgres。`pip install dbosify`,改个 import,先在本地试 kill-and-recover。这一步能立刻帮你省下"崩了重跑"的 token 和时间。 **第二步(团队级,下周做)**:装上 [agentico](https://github.com/doordash-oss/agentic-orchestrator),挑一个真实的小 feature,试一次"oneshot":让它走完"研究→设计→实现→验证→PR"的完整链路。重点不是看代码写得怎样,而是观察它的**检查点机制**——你在哪些关卡介入、它怎么并发。把这套"持久化 feature 流水线"的体感建立起来。 **第三步(组织级,本月规划)**:如果你的团队对"AI 改的代码怎么上 CI"有焦虑,把 [rigorix](https://github.com/arman-jalili/rigorix-oss) 的 GitHub Action 接到一个非核心仓库的 PR 流程里。给它配好预算上限、权限边界和架构契约,看它怎么把一个开放式的 agent 循环,收敛成可复现、可审计的 DAG 执行。这是你走向"AI 工程化合规"的第一块基石。 **一个省钱算账**:假设你的 agent 任务平均跑 90 分钟、烧 $5 的 token。没做持久化,崩一次=重跑 90 分钟、再烧 $5。加上 DBOSify 这类断点续传后,从崩点(假设在尾部)续跑,只需重跑约 5 分钟、约 $0.3——单次崩溃的浪费砍掉约 94%。一个月崩 20 次,就是省下近百美元和 30 小时机器时间。这还没算 DBOSify 替代 Temporal 省下的运维成本。 ## 六、给你的延伸思考 这三把刀背后是同一个判断:**AI agent 的竞争,正在从"模型层"下沉到"执行层"。** 模型谁都能调,但"谁能把 agent 跑得稳、跑得久、跑得可审计",才是接下来一年的真壁垒。国内从业者如果想拿到这块的信息差优势,与其追第十个新模型,不如先把"持久化执行"这套十年前的后端智慧,认认真真接到自己的 agent 栈上。 > 三把刀都是早期开源项目(star 数都不高),现在正是低位关注、低成本试水的窗口期。等它们涨到几千 star,国内一窝蜂跟进的时候,你已经用熟了。 ## 参考来源 - DBOSify 仓库与官方文档:[github.com/dbos-inc/dbosify-py](https://github.com/dbos-inc/dbosify-py) · [docs.dbos.dev/explanations/dbosify](https://docs.dbos.dev/explanations/dbosify) - Agentic Orchestrator(DoorDash 开源):[github.com/doordash-oss/agentic-orchestrator](https://github.com/doordash-oss/agentic-orchestrator) - rigorix 仓库:[github.com/arman-jalili/rigorix-oss](https://github.com/arman-jalili/rigorix-oss)(crate 见 [crates.io/crates/rigorix](https://crates.io/crates/rigorix)) - Hacker News Show HN 社区讨论:[news.ycombinator.com](https://news.ycombinator.com/show)(本情报工具发现来源) - durable execution 概念参考:Temporal([temporal.io](https://temporal.io))与 DBOS([dbos.dev](https://dbos.dev)) --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**(微信ID: gprshome201101)维护。 > 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!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 等场景全覆盖。