你让 AI agent 跑一个两小时的活——重构一个模块、批量处理几千条数据、把一个 feature 从一句话需求做成可上线的 PR。跑到第 90 分钟，网断了，或者进程 OOM 被杀，或者你的笔记本没电自动休眠。agent 进程一关，前面所有的上下文、所有中间产物，全部归零。重来的代价是：再烧一遍 token、再等一遍时间，还可能因为复现不出来而debug到天亮。
这是国内做 AI agent 的人最常踩、却最少有人正视的坑。我们一直在卷"哪个 agent 写代码更快""哪个模型更强",而海外这一周在卷一个更值钱的问题:agent 跑崩了能不能续?同一个任务能不能复现?改的代码能不能在 CI 里审计?
今天的情报就是围绕这个信息差展开的——三把近期刚开源的新刀,正在把"持久化执行(durable execution)"这个后端圈玩了十年的老概念,重新打磨成 AI agent 的标配基建。三把刀切入点完全不同,但解决的却是同一件事:让长跑的 agent 不再怕崩。
先说清楚一个认知差。绝大多数人评判一个 coding agent,看的是"它写的代码对不对、快不快"。但真正在生产里用 agent 的人,噩梦是另一回事:
这三个"不可",对应的是后端工程里一个成熟的概念叫 durable execution(持久化执行)。它的代表是 Temporal、DBOS、Restate 这类工作流引擎,核心思想就一句话:把每一步的状态存进数据库,进程崩了,从最后一个检查点续跑,而且保证每个动作只执行一次(exactly-once)。
这套东西,互联网大厂的后端团队用了好些年,但国内做 AI 应用的几乎没人碰——大家觉得那是"搞微服务的人才用的"。而最近这一两周,海外开源圈集体在干一件事:把 durable execution 拽到 AI agent 的脚下。 下面这三把刀,就是这一波的代表。
DBOSify 的定位极其精准:它是 Temporal Python 的"平替"(drop-in replacement)。 Temporal 是 durable execution 领域的标杆,但它需要你单独部署一套 Temporal server、维护一套 gRPC 协议,门槛不低。DBOSify 的做法粗暴有效——你只需要一个 Postgres。
它的卖点在于迁移成本几乎为零:
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,不用多部署任何中间件。
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"这条链路工程化、持久化了,这是国内工具的空白区。
前两把刀解决"崩了能续",这把刀解决的是"不可复现 + 不可审计"。它的自我定位是:
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、过得了审计"的形态。对金融、通信、政企这类对合规审计敏感的场景,这正是缺的那块拼图。
flowchart TD
A["一句话 feature 需求"] --> B["agentico 编排器<br/>构建上下文 + 分阶段 roadmap"]
B --> C{"需要可复现/审计?"}
C --|否,只要崩溃恢复|--> D["DBOSify<br/>每步检查点写进 Postgres"]
D --> E{"进程崩了?"}
E --|是|--> F["新 worker 重放<br/>从断点续跑 exactly-once"]
E --|否|--> G["正常完成"]
F --> G
C --|是,要进 CI|--> H["rigorix<br/>编译成 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 套上"崩溃兜底 + 复现审计"的两道保险。
| 维度 | 国内主流认知(你已知的) | 海外这周在卷的(信息差) |
|---|---|---|
| agent 评判标准 | 写代码快不快、准不准 | 崩了能不能续、能不能复现、能不能审计 |
| 长任务保护 | 重试 + 日志,崩了重来 | durable execution,断点续传,exactly-once |
| 工作流引擎 | 自研或不用,觉得 Temporal 太重 | DBOSify:一个 Postgres 就够,平替 Temporal |
| feature→PR | 人在对话框里一步步带 | agentico:持久化流水线,人在检查点介入 |
| AI 改代码进 CI | 极少有人做 | rigorix:DAG + 策略 + 预算,GitHub Action 治理 |
| 成本 | 崩一次重跑一次,token 翻倍烧 | 崩了从断点续,只重跑尾部 |
第一步(最低成本,今天就能做):如果你有任何一个跑得比较长的 Python 任务——批量调 LLM、多步数据处理、agent pipeline——花半小时给它套上 DBOSify。你不需要装 Temporal,只要有个 Postgres。pip install dbosify,改个 import,先在本地试 kill-and-recover。这一步能立刻帮你省下"崩了重跑"的 token 和时间。
第二步(团队级,下周做):装上 agentico,挑一个真实的小 feature,试一次"oneshot":让它走完"研究→设计→实现→验证→PR"的完整链路。重点不是看代码写得怎样,而是观察它的检查点机制——你在哪些关卡介入、它怎么并发。把这套"持久化 feature 流水线"的体感建立起来。
第三步(组织级,本月规划):如果你的团队对"AI 改的代码怎么上 CI"有焦虑,把 rigorix 的 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,国内一窝蜂跟进的时候,你已经用熟了。
本文由「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 等场景全覆盖。