2026年5月22日,Google发布开源分布式Agent运行时Agent Executor(代号AX),将"持久执行"(Durable Execution)推上Agent基础设施的绝对C位。这不是概念炒作——当Agent从单次对话走向小时级甚至天级工作流,进程崩溃、API限流、人工审批等待每一个环节都可能让整条链路归零。持久执行通过检查点(Checkpoint)、事件回放(Replay)、Saga补偿和精确一次语义(Exactly-Once)解决了这个"最后一公里"问题。本文实测六大持久执行引擎:Google AX、Temporal、LangGraph、Inngest、Restate、Azure Durable Task,从检查点粒度、回放精度、等待语义、生态集成四个维度展开全链拆解。
| 维度 | Google AX (2026.05) | Temporal | LangGraph | Inngest | Restate | Azure Durable Task |
|---|---|---|---|---|---|---|
| 开源协议 | Apache 2.0 | MIT | MIT | BSL 1.1 | BSL 1.1 → MIT | MIT (SDK) |
| 语言栈 | Python, Go | Go, Python, TS | Python, JS | TypeScript | TypeScript, Go, Java | C#, Python, JS |
| 检查点粒度 | 步骤级(Step) | 工作流级(Workflow) | 节点级(Node) | 步骤级(Step) | 调用级(Invocation) | 函数级(Activity) |
| 回放机制 | 事件溯源 + 快照 | 事件历史重放 | 状态快照重载 | 事件溯源 | 日志不可变重放 | 事件历史重放 |
| 最长运行 | 无限(暂停/恢复) | 无限(Heartbeat) | 无限(Checkpoint) | 无限(Sleep/Wake) | 无限(Awakeable) | 无限(Timer/Event) |
| 等待语义 | Human-in-the-Loop, Timer, Event | Signal, Timer, Activity | Interrupt, Checkpoint | Sleep, WaitForEvent | Awakeable, Journal | Timer, ExternalEvent |
| 状态存储 | 可插拔(Redis/Spanner) | Cassandra/Postgres/MySQL | 可插拔(Postgres/SQLite) | PostgreSQL | 内置(KV) | Azure Storage |
| 学习曲线 | 中 | 高 | 低 | 中 | 低 | 中 |
| GitHub Stars | 3.2K(1周) | 14.8K | 15.2K | 8.6K | 2.9K | N/A(Azure集成) |
Google在5月22日开源Agent Executor,这不是又一个Agent框架,而是一个专注于执行可靠性的分布式运行时。AX的核心设计哲学是"代码即工作流"——开发者写普通Python/Go函数,AX自动将其转化为持久执行的分布式工作流。
架构核心:AX采用三层架构——调度层(Scheduler)负责步骤编排,持久层(Persistence)负责检查点存储,执行层(Executor)负责实际调用。每个Agent步骤完成后,调度层自动写入检查点。如果进程崩溃,调度层从最近检查点恢复,跳过已完成步骤直接执行未完成步骤。
关键特性:
- 步骤级原子检查点:每个executor.step()调用后自动持久化,粒度比工作流级更细
- 人机交接原生支持:executor.wait_for_approval()让Agent暂停等待人工确认,支持数天级别等待
- Saga补偿模式:内置compensate()注解,步骤失败时自动触发反向补偿
- 与ADK深度集成:Google Agent Development Kit原生支持AX作为执行后端
# Google AX 持久执行示例
from google.ax import AgentExecutor, step
executor = AgentExecutor("order-agent")
@step(checkpoint=True)
async def check_inventory(item_id: str):
result = await db.query("SELECT stock FROM items WHERE id = ?", item_id)
return result
@step(checkpoint=True, compensate="restore_inventory")
async def reserve_inventory(item_id: str, qty: int):
await db.execute("UPDATE items SET stock = stock - ? WHERE id = ?", qty, item_id)
@step(checkpoint=True)
async def process_payment(order_id: str):
payment = await payment_api.charge(order_id)
if payment.failed:
raise PaymentError(payment.reason) # 触发Saga补偿
return payment
async def restore_inventory(item_id: str, qty: int):
await db.execute("UPDATE items SET stock = stock + ? WHERE id = ?", qty, item_id)
# 持久执行:崩溃后自动恢复,跳过已完成步骤
@executor.workflow
async def order_workflow(order: Order):
await check_inventory(order.item_id)
await reserve_inventory(order.item_id, order.qty)
approval = await executor.wait_for_approval(
"confirm_order", timeout="7d"
)
if approval.approved:
await process_payment(order.id)
实测评价:AX的最大优势是与Google Cloud生态的无缝整合——Cloud Spanner作为状态后端、Cloud Run作为执行器、Pub/Sub作为事件总线。但对于非GCP用户,可插拔后端仍处于早期,社区驱动成熟度不足。 Saga补偿的实现优雅但调试困难——补偿链本身的失败处理需要额外设计。上手约2小时可完成第一个持久工作流,但生产级调优需要深入理解事件溯源模型。
Temporal在2026年Agent浪潮中的角色是"基础设施层"——它不提供Agent框架,而是提供Agent框架可以依赖的持久执行保证。LangChain、CrewAI、AutoGen等主流框架都已经或正在集成Temporal作为可选执行后端。
架构核心:Temporal的核心是事件溯源(Event Sourcing)——工作流的每一步都生成不可变事件,形成完整的事件历史(Event History)。当工作流需要恢复时,Temporal通过重放事件历史重建状态,而非从检查点快照恢复。这种设计使得Temporal能提供严格的确定性重放——相同的输入必然产生相同的输出。
关键特性: - 确定性重放:工作流代码必须是确定性的,Temporal通过确定性调度器保证这一点 - Heartbeat机制:长时间运行的Activity定期发送心跳,超时自动重试 - Signal/Query分离:Signal修改工作流状态,Query只读不修改,保证一致性 - 版本兼容:工作流代码升级时,旧版本的事件历史仍可正确重放
# Temporal 持久Agent工作流
from temporalio import workflow, activity
from datetime import timedelta
@activity.defn
async def analyze_document(doc_id: str) -> AnalysisResult:
"""活动:可被持久化、重试、超时控制"""
doc = await doc_store.get(doc_id)
return await llm.analyze(doc)
@activity.defn
async def human_review(analysis: AnalysisResult) -> ReviewDecision:
"""活动:等待人工审核,可持续数天"""
review = await review_queue.submit(analysis)
return await review.wait(timeout=timedelta(days=3))
@workflow.defn
class DocumentReviewWorkflow:
"""工作流:自动检查点,崩溃恢复,确定性重放"""
@workflow.run
async def run(self, doc_id: str) -> FinalResult:
# 步骤1:自动分析(失败自动重试)
analysis = await workflow.execute_activity(
analyze_document, doc_id,
start_to_close_timeout=timedelta(minutes=30),
retry_policy=RetryPolicy(maximum_attempts=3)
)
# 步骤2:人工审批(可持续数天)
review = await workflow.execute_activity(
human_review, analysis,
start_to_close_timeout=timedelta(days=3)
)
if review.approved:
return await workflow.execute_activity(
finalize_document, analysis,
start_to_close_timeout=timedelta(minutes=10)
)
实测评价:Temporal的确定性约束是双刃剑——它保证了严格的正确性,但要求工作流代码不能有随机数、当前时间、网络调用等非确定性操作。新手常在"工作流内不能做API调用"这个限制上反复踩坑。Temporal的运维复杂度是六大引擎中最高的——需要独立的Temporal Server集群、独立的数据库(Cassandra或PostgreSQL)。但在大规模生产环境中,Temporal的可靠性和可观测性无可匹敌。学习曲线约1周,适合有分布式系统经验的团队。
LangGraph在2025年底引入原生Durable Execution支持,将持久执行从外部基础设施下沉到框架层。开发者无需引入额外运行时,只需配置Checkpointer即可获得持久化保证。
架构核心:LangGraph的持久执行基于节点级快照——图中的每个节点执行完毕后,自动将整个图状态写入Checkpointer。与Temporal的事件溯源不同,LangGraph采用状态快照模式——恢复时直接加载快照,不需要重放。这种设计更简单直观,但牺牲了完整的审计追溯能力。
# LangGraph 持久执行
from langgraph.graph import StateGraph
from langgraph.checkpoint.postgres import PostgresSaver
# 配置持久化后端
checkpointer = PostgresSaver.from_conn_string("postgresql://...")
builder = StateGraph(AgentState)
builder.add_node("research", research_node)
builder.add_node("analyze", analyze_node)
builder.add_node("report", report_node)
builder.add_node("human_review", human_review_node)
builder.add_edge("research", "analyze")
builder.add_edge("analyze", "human_review")
builder.add_edge("human_review", "report")
graph = builder.compile(
checkpointer=checkpointer,
interrupt_before=["human_review"] # 执行到此节点前暂停
)
# 首次执行:到human_review前暂停
result = await graph.ainvoke(
{"topic": "AI Agent trends"},
config={"configurable": {"thread_id": "thread-123"}}
)
# 人工审核后恢复执行
result = await graph.ainvoke(
None, # 无需重新传入输入
config={"configurable": {"thread_id": "thread-123"}}
)
实测评价:LangGraph持久化的最大优势是零额外基础设施——不需要独立运行时,PostgreSQL作为Checkpointer即可。对于已有LangGraph项目的团队,引入持久化只需增加一行checkpointer=配置。但劣势同样明显:节点级快照在复杂分支场景下粒度不够——如果节点内部有多次工具调用,只有节点级别的检查点意味着中间调用结果在崩溃后丢失。此外,LangGraph的interrupt_before/after机制虽然支持人机交接,但不如AX和Temporal的等待语义灵活。上手只需30分钟,适合快速原型和中型项目。
Inngest定位为TypeScript原生的持久执行平台,2026年初发布Agent Kit,为TypeScript/Node.js生态的Agent开发者提供开箱即用的持久化。
架构核心:Inngest采用事件驱动模型——每个步骤(Step)是一个独立函数,步骤之间通过事件触发。Inngest Server自动管理步骤间的状态传递和检查点。与Temporal的工作流编排不同,Inngest的步骤是松耦合的——每个Step函数独立部署、独立扩展。
// Inngest Agent Kit 持久执行
import { agent, step } from "inngest/agent-kit";
export const researchAgent = agent({
name: "Research Agent",
model: "claude-sonnet-4-6",
steps: [
step("search", async ({ query }) => {
const results = await searchEngine.search(query);
return results;
}),
step("analyze", async ({ searchResults }) => {
const analysis = await llm.analyze(searchResults);
return analysis;
}),
step("wait-for-approval", async ({ analysis }) => {
// 可持久等待数天
const approval = await waitForHumanInput(analysis, {
timeout: "7d",
channel: "slack"
});
return approval;
}),
step("generate-report", async ({ analysis, approval }) => {
return await generateReport(analysis, approval.comments);
})
],
// 自动重试、检查点、并发控制
config: {
retries: 3,
checkpoint: true,
concurrency: { limit: 5, key: "user.id" }
}
});
实测评价:Inngest对TypeScript开发者而言是最佳选择——类型安全、零配置持久化、开箱即用的并发控制。Agent Kit的高层抽象让定义持久Agent变得直觉化。但BSL 1.1许可证限制了其在竞品产品中的使用(2026年后转为MIT)。对于需要与现有事件系统(如Kafka、RabbitMQ)集成的场景,Inngest的事件模型需要额外适配。上手约1-2小时,特别适合Next.js/Vercel生态的团队。
Restate在2026年以"轻量Temporal"的定位切入Agent持久执行市场。它的核心卖点是零外部依赖——不需要独立的状态数据库、不需要独立的服务集群,Restate自身就是持久化引擎。
架构核心:Restate采用日志不可变(Immutable Journal)模型——每次函数调用生成一条Journal Entry,包含输入、输出和副作用。恢复时,Restate通过重放Journal跳过已执行的调用。与Temporal类似但更轻量——Restate将运行时嵌入到应用进程中,而非独立部署。
// Restate 持久Agent
import { endpoint } from "@restatedev/restate-sdk";
const agentService = endpoint({
name: "OrderAgent",
handler: async (ctx: restate.Context, order: Order) => {
// 每个调用自动持久化到Journal
const inventory = await ctx.run("check-inventory", () =>
checkInventory(order.itemId)
);
if (!inventory.available) {
return { status: "out_of_stock" };
}
// 持久等待人工确认(可等待数天)
const approval = await ctx.run("request-approval", () =>
requestHumanApproval(order, { timeout: "3d" })
);
// Awakeable:外部事件唤醒
const paymentResult = await ctx.awakeable<PaymentResult>();
sendPaymentRequest(order, paymentResult.id);
return { status: "completed" };
}
});
实测评价:Restate的"零外部依赖"在Agent场景中极具吸引力——一个小型Restate进程即可支撑持久执行,不需要Temporal那样的运维团队。Awakeable机制是独特创新——允许外部系统主动唤醒暂停中的Agent,比轮询模型优雅得多。但Restate的生态成熟度仍不足——缺乏LangChain/CrewAI等框架的原生集成,文档和社区规模远小于Temporal和LangGraph。从BSL 1.1转为MIT后,商业化路径更清晰。上手约1小时,适合中小团队的快速落地。
微软在2026年5月发布Agent Framework的Durable Extensions,将Azure Durable Task的持久执行能力注入Agent开发。这不是独立产品,而是Microsoft Agent Framework + Azure Functions + Durable Task的整合方案。
架构核心:Durable Task采用Orchestrator/Activity模式——Orchestrator定义工作流逻辑,Activity是具体的执行单元。Orchestrator必须是确定性的(与Temporal相同),Activity可以有副作用。Azure Storage自动持久化Orchestrator的状态历史。
// Microsoft Agent Framework Durable Agent
[Agent(AgentName = "DocumentProcessor")]
public class DocumentAgent : DurableAgent
{
[AgentStep]
public async Task<AnalysisResult> Analyze(
[DurableActivity] IDurableActivityContext context)
{
var doc = context.GetInput<Document>();
return await _llm.AnalyzeAsync(doc);
}
[AgentStep]
public async Task<ReviewDecision> WaitForReview(
[DurableTimer] IDurableOrchestrationContext context,
AnalysisResult analysis)
{
// 持久定时器:等待外部事件或超时
var timeout = context.CurrentUtcDateTime.AddDays(3);
var reviewEvent = context.WaitForExternalEvent<ReviewDecision>("ReviewSubmitted");
var timeoutEvent = context.CreateTimer(timeout, CancellationToken.None);
var winner = await Task.WhenAny(reviewEvent, timeoutEvent);
return winner == reviewEvent
? reviewEvent.Result
: ReviewDecision.Timeout;
}
}
实测评价:Azure Durable Task是微软生态企业的自然选择——与Azure Functions、Azure Storage、Entra ID无缝集成。对于已在Azure上的团队,引入持久Agent几乎零额外成本。但Durable Task的确定性约束与Temporal一样严格,且对非微软生态的团队几乎没有吸引力——没有独立的本地开发模式,调试体验依赖Azure工具链。上手约2-3小时(假设已有Azure经验),学习曲线中等,但Azure Functions的冷启动延迟对实时Agent场景是硬伤。
graph TB
subgraph "Agent应用层"
A[Agent Loop] --> B[Tool Calls]
B --> C[LLM Inference]
end
subgraph "持久执行层(六大引擎)"
D[检查点管理器<br/>Checkpoint Manager]
E[事件日志<br/>Event Journal]
F[调度器<br/>Scheduler]
G[补偿管理器<br/>Compensation/Saga]
end
subgraph "等待语义层"
H[Human-in-the-Loop<br/>人工审批]
I[Timer<br/>定时器]
J[External Event<br/>外部事件]
K[Signal<br/>信号通知]
end
subgraph "状态存储层"
L[PostgreSQL]
M[Cassandra]
N[Redis]
O[Cloud Spanner]
P[Azure Storage]
end
C --> D
D --> E
E --> F
F --> G
G --> H
G --> I
G --> J
G --> K
H --> L
H --> M
H --> N
H --> O
H --> P
style D fill:#4A90D9,color:#fff
style E fill:#7B68EE,color:#fff
style F fill:#20B2AA,color:#fff
style G fill:#FF6B6B,color:#fff
检查点粒度是持久执行引擎最核心的设计选择。我们从实测数据看四种模型的表现差异:
场景:一个包含6步工具调用的Agent工作流,在第4步后进程崩溃
| 检查点模型 | 代表引擎 | 恢复后重执行步骤 | Token浪费 | 状态一致性 |
|---|---|---|---|---|
| 工作流级 | Temporal, Azure | 0(全事件重放) | 0 | 严格一致 |
| 节点级 | LangGraph | 1-2(当前节点重执行) | 低 | 最终一致 |
| 步骤级 | Google AX, Inngest | 0(精确步骤恢复) | 0 | 严格一致 |
| 调用级 | Restate | 0(Journal精确重放) | 0 | 严格一致 |
工作流级重放的代价是CPU时间——即使不需要重新调用API,仍需重放整个事件历史来重建状态。对于运行了数千步的长工作流,重放时间可能达到分钟级。步骤级和调用级检查点通过精确记录每步的输入输出来避免重放开销,但需要更多存储空间。
graph LR
subgraph "场景判断"
S1{需要持久执行?}
S2{运行时长?}
S3{技术栈?}
S4{基础设施?}
S5{团队规模?}
end
S1 -->|秒级完成| X[无需持久执行]
S1 -->|分钟到天级| S2
S2 -->|< 30分钟| S3
S2 -->|> 30分钟| S4
S3 -->|Python| LangGraph
S3 -->|TypeScript| Inngest
S4 -->|已有GCP| Google AX
S4 -->|已有Azure| Azure Durable Task
S4 -->|自建| S5
S5 -->|> 5人DevOps| Temporal
S5 -->|< 5人| Restate
场景一:Python生态 + 快速原型 → LangGraph
已有LangGraph项目,增加checkpointer=一行即可。不需要独立运行时。适合原型验证和中小规模生产。
场景二:TypeScript生态 + 事件驱动 → Inngest TypeScript/Next.js团队的自然选择。Agent Kit提供高层抽象,并发控制开箱即用。Vercel生态最佳。
场景三:大规模生产 + 严格正确性 → Temporal 需要严格持久保证、完整审计追踪、大规模并发。需要投入运维资源。回报是工业级可靠性。
场景四:GCP生态 + 长工作流 → Google AX 使用Google Cloud的团队首选。与ADK、Cloud Run、Spanner深度整合。2026年Q3生态预计快速成熟。
场景五:中小团队 + 零依赖 → Restate 不想维护独立运行时的团队。轻量部署、Awakeable机制优雅。适合从MVP到中等规模的过渡。
场景六:微软生态 + 企业合规 → Azure Durable Task 已在Azure上的企业团队。与Entra ID、Azure Monitor、合规认证无缝对接。非Azure生态不推荐。
陷阱一:确定性幻觉 Temporal和Azure Durable Task要求工作流代码是确定性的。但在Agent场景中,LLM调用本身是非确定性的。正确做法是将LLM调用放在Activity中,而非Orchestrator中。新手最常犯的错误是在Orchestrator内直接调用LLM,导致重放时产生不同结果。
陷阱二:检查点开销低估 步骤级检查点意味着每个工具调用后都写一次数据库。对于高频调用的Agent(如浏览器自动化,每秒多次操作),检查点写入可能成为瓶颈。解决方案是批量检查点——累积N步操作后统一写入。
陷阱三:补偿链的无限递归
Saga补偿模式在理论上是优雅的,但补偿操作本身也可能失败。当补偿失败时,是否需要补偿补偿操作?Google AX通过compensate_retries参数限制补偿深度,但没有银弹。生产系统中需要设计"最终一致"的兜底机制,而非追求完美回滚。
| 引擎 | 训练营可行性 | 产品化空间 | 市场需求度 |
|---|---|---|---|
| Google AX | 高(新热点) | 高(GCP咨询) | 快速上升 |
| Temporal | 中(门槛高) | 高(企业实施) | 稳定高位 |
| LangGraph | 高(易上手) | 中(框架绑定) | 最高 |
| Inngest | 中(TS限定) | 中(Vercel生态) | 上升中 |
| Restate | 高(轻量叙事) | 中(中小团队) | 新兴 |
| Azure Durable Task | 低(Azure限定) | 高(企业合规) | 稳定 |
最佳变现路径:以LangGraph作为入门教学(零门槛),以Temporal/Google AX作为高阶课程(高客单价)。"Agent持久执行"作为概念在2026年Q2-Q3将进入爆发期,目前是布局内容的窗口期。
[!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 等场景全覆盖。
