Temporal Replay 2026 深度解析：Serverless Workers、Workflow Streams 与 AI Agent 基础设施的范式革命

前言

2026年5月，Temporal 在 Replay 2026 大会上发布了公司历史上最重磅的产品更新。如果你还在把 Temporal 当作"分布式任务队列的替代品"，你需要更新认知了——Temporal 正在把自己定位成 AI Agent 的可靠执行基础设施，从 Workflow 编排到 Serverless 计算，从 LLM 流式输出到多云高可用，这一次的更新几乎覆盖了 AI 工程化的每一个关键环节。

作为一名在生产环境中使用 Temporal 构建订单系统和工作流引擎的后端工程师，我第一时间阅读了全部发布内容。这篇文章不堆砌营销话术，从工程师视角拆解每一个 feature 解决什么问题、背后是什么架构思路，以及在实际生产中应该如何落地。

一、Temporal 是什么，为什么它的定位变了

1.1 最初的故事：Durable Execution

Temporal 的核心技术叫 Durable Execution（持久化执行）。简单来说，它解决的是分布式系统中最令人头疼的一类问题：代码执行到一半，进程崩溃了怎么办？

传统的解决方案是：幂等设计 + 消息队列 + 手动补偿。开发者需要写大量防御性代码——每一步都要考虑"如果失败了要不要重试"、"重试会不会重复执行"、"重复了怎么兜底"。

Temporal 的思路完全不同：把代码执行状态自动持久化。 你的代码可以像普通程序一样写业务逻辑，Temporal 在底层自动捕获每一次状态变化。进程崩溃？没问题——Temporal 把状态恢复到崩溃前的最后一个持久化点，你的代码从那里继续往下跑，就像什么都没发生过一样。

这个能力来自于 Temporal Server ——它维护了 Workflow 执行的所有历史事件（Event History）。不管你的 Worker 重启了多少次、迁移到了哪台机器，Temporal 都可以根据 Event History 重放（replay）出完全一致的业务逻辑。

1.2 2026年的新故事：AI Agent 的可靠层

2025年到2026年，AI Agent 爆发式增长。但 AI Agent 有一个根本性挑战：LLM 调用不可靠——网络超时、模型限流、token 耗尽、内容安全拦截，每一步都可能失败。而且 AI Agent 通常是长时运行的：一个复杂的 Agent 任务可能持续几分钟到几小时，期间任何环节出错都需要从正确的位置恢复。

这正是 Temporal 的用武之地。Replay 2026 的核心主题就是：把 Durable Execution 变成 AI Agent 的可靠执行层。Temporal 不只是帮你管理 Workflow——它要成为 AI 应用的基础设施，让开发者专注于业务逻辑，而不用再写一堆"失败了怎么办"的防御代码。

二、核心新功能深度解析

2.1 Serverless Workers：从管理基础设施到只写业务代码

解决了什么问题：

传统的 Temporal Worker 需要部署在持久化的服务器上，你需要自己管理：

• 基础设施配置（EC2/K8s Pod）
• 自动扩缩容策略（什么时候扩容、扩多少、缩到多少）
• Worker 的生命周期管理（启动、健康检查、优雅关闭）

这对于已经有成熟基础设施的团队不是问题，但对于很多 AI 应用团队（特别是初创公司），光是搭这套基础设施就够喝一壶的。

技术原理：

Temporal 这次发布了 Serverless Workers，首批支持 AWS Lambda（预览版）。基本思路是：Temporal Cloud 直接管理 Worker 的调用生命周期，根据工作负载自动触发 Lambda 执行，执行完成后自动缩容到零。

从架构上看，这和传统 FaaS 没有本质区别——但关键是：你的 Workflow 状态是持久化的。Lambda 执行完后，如果同一个 Workflow 有新的任务，Temporal 会再次触发一个新的 Lambda 实例，从上次中断的地方继续执行。

代码示例（Python SDK）：

from temporalio.worker import Worker
from temporalio.workflow import workflow, workflow_method
from datetime import timedelta
import asyncio

@workflow.defn
class DataProcessingWorkflow:
    @workflow.run
    async def run(self, input_data: dict) -> dict:
        # Step 1: Fetch data from external API
        result = await workflow.execute_activity(
            fetch_data_activity,
            input_data,
            start_to_close_timeout=timedelta(seconds=30),
            retry_policy=temporalio.workflow.RetryPolicy(
                maximum_attempts=3,
                initial_interval=timedelta(seconds=1),
            )
        )
        
        # Step 2: Process and transform
        processed = await workflow.execute_activity(
            transform_data_activity,
            result,
            start_to_close_timeout=timedelta(minutes=5),
        )
        
        return processed

# 在传统模式下，你需要：
# worker = Worker(
#     client,
#     task_queue="data-processing",
#     workflows=[DataProcessingWorkflow],
#     activities=[fetch_data_activity, transform_data_activity],
# )
# await worker.run()

# 在 Serverless 模式下（Temporal Cloud 自动管理 Lambda）：
# 你只需要注册 Workflow 和 Activity，
# Temporal Cloud 会自动创建和管理 Lambda 函数

实际意义：

Serverless Workers 最大的价值是降低入门门槛。以前团队要上 Temporal，首先得搭一套 Worker 基础设施，这需要 DevOps 经验。现在 Temporal Cloud 直接帮你托管 Lambda，你只需要写业务代码，部署时间从天级别压缩到分钟级别。

对于 AI Agent 场景特别友好：AI 任务通常是突发性的——平时没什么流量，但当用户发起一个复杂查询时可能需要密集计算。Serverless 的弹性正好匹配这种流量模式，而且空闲时成本为零。

需要注意的坑：

• Lambda 有 15 分钟的最大执行时间限制。如果你的 Workflow 需要长时间运行（比如训练一个模型），Lambda 模式不适用，你需要传统的持久化 Worker。
• 冷启动延迟：Lambda 冷启动大约在 100-500ms 量级，对于延迟敏感的交互式 AI 应用需要注意。
• 预览版：当前是 Pre-release，生产环境使用需谨慎评估。

2.2 Workflow Streams：Durable Streaming 的工程突破

解决了什么问题：

AI Agent 的一个核心交互模式是流式输出：LLM 生成的内容一个字一个字地吐出来，前端需要实时渲染给用户看。但流式输出带来了新的可靠性挑战：

1. 流式中断怎么办？ LLM 生成到一半网络断了，用户看到的是一个不完整的响应，而且无法恢复。
2. 如何关联用户看到的 tokens 和后台的 Workflow 状态？ 流式输出的每一批 tokens 都需要和 durable execution 状态保持一致。
3. 实时监控和 guardrails（护栏）怎么做？ 需要在 LLM 输出的过程中实时检查内容，如果发现有害内容要能及时中断。

技术原理：

Temporal 发布的 Workflow Streams 是基于已有的 Signal 和 Update 机制构建的 durable streaming 能力。核心思想是：把流式 tokens 批次作为 Workflow 的 Signal 事件持久化存储，这样即使用户断开连接，Workflow 继续运行；重新连接后，可以从 Event History 中恢复所有已生成的 tokens，继续展示。

# Workflow Streams 代码示例（Python SDK）
from temporalio.workflow import workflow, workflow_method, signal, update
from typing import AsyncGenerator

@workflow.defn
class StreamingAgentWorkflow:
    @workflow.run
    async def run(self, prompt: str) -> str:
        full_response = ""
        
        # 使用 Workflow Streams 接收 LLM 流式输出
        # 每一批 tokens 都会被持久化
        async for token_batch in self._stream_llm_response(prompt):
            full_response += token_batch
            
            # 检查内容安全 - guardrails 逻辑
            if self._contains_blocked_content(token_batch):
                await self._trigger_safety_alert(token_batch)
                break
            
            # 更新 Workflow 状态（持久化）
            await workflow.update(self, "partial_response", full_response)
        
        return full_response
    
    async def _stream_llm_response(self, prompt: str) -> AsyncGenerator[str, None]:
        # 这里可以是 OpenAI/Anthropic 的流式 API
        async for chunk in llm_stream(prompt):
            yield chunk

# 用户端接收流式输出
async def consume_stream():
    async for token in workflow.get_stream_updates("workflow-id"):
        print(token, end="", flush=True)
        # 即使网络断开，用户重新连接后可以从头看到完整的 token 序列

和普通 WebSocket 流的本质区别：

普通的 Server-Sent Events（SSE）或 WebSocket 流是内存状态——服务端崩溃了，生成的 tokens 就丢了。Workflow Streams 的 tokens 存在 Temporal 的 Event History 里，Workflow 迁移到另一台机器后，新机器可以从 Event History 重建完整的流状态。

性能与适用场景：

Workflow Streams 目前是 Public Preview，延迟大约在 100-500ms 量级（取决于 Temporal Server 和网络延迟）。对于需要实时交互的 AI 应用，这个延迟已经足够好。对于不需要实时流的批处理场景，用传统的非流式 Workflow 效率更高。

2.3 Standalone Activities：Activity 不再只是 Workflow 的配角

解决了什么问题：

在 Temporal 的经典模型中，Activity 是Workflow 内部的步骤——你不能单独运行一个 Activity，它必须被 Workflow 调用。这对于很多简单场景来说过于复杂了：

• 只想运行一个带重试的 HTTP 请求？必须先创建一个 Workflow。
• 写一个定时任务，需要 Retry 和持久化？以前得包装成 Workflow。

技术原理：

Standalone Activities 允许 Activity 独立运行，不依赖 Workflow。Activity 本身就具备：

• 自动重试（Retry Policy）
• 持久化执行状态
• 超时控制
• 结果存储

你可以直接提交一个 Activity 执行，Temporal 负责调度和持久化。Activity 失败会按策略重试，成功后结果会被持久化。下次查询时可以直接拿到结果，就像一个托管的任务队列。

# Standalone Activity 示例（Python SDK）
from temporalio.client import Client
from temporalio.worker import ActivityOptions
from temporalio.common import RetryPolicy
from datetime import timedelta

# 独立的 Activity 函数
@activity.defn
async def send_notification_activity(notification: dict) -> dict:
    # 发送通知，可以是邮件、短信、推送等
    result = await http_client.post(
        "https://notification-service/send",
        json=notification
    )
    return {"status": "sent", "message_id": result["id"]}

async def main():
    client = await Client.connect("localhost:7233")
    
    # 直接提交 Standalone Activity，不需要 Workflow
    handle = await client.start_activity(
        send_notification_activity,
        arg={"user_id": "12345", "type": "email", "content": "Your order shipped!"},
        task_queue="notifications",
        retry_policy=RetryPolicy(
            maximum_attempts=5,
            initial_interval=timedelta(seconds=1),
            backoff_coefficient=2.0,
        ),
        start_to_close_timeout=timedelta(seconds=30),
    )
    
    # 等待结果（也可以不等待，直接获取 handle 后续查询）
    result = await handle.result()
    print(f"Notification sent: {result}")

# 如果 Activity 失败，Temporal 会自动按策略重试
# 如果需要从外部查询状态：
status = await client.get_activity_status(handle.id)

使用场景：

Standalone Activities 特别适合以下场景：

• 异步任务处理：发邮件、发短信、推送通知
• 定时任务：每天凌晨跑数据导出
• 外部集成：调用第三方支付 API、地图 API
• 批处理：对一批数据进行转换处理

当你的任务复杂度增长、需要多个 Activity 协调执行时，可以无缝地把相同的 Activity 纳入 Workflow 中，不需要重写。

当前状态： Public Preview for Go, Python, .NET；Pre-release for Java, TypeScript。

2.4 External Payload Storage：解决 AI 应用的大文件困境

解决了什么问题：

LLM 应用经常需要处理大文件——上传的 PDF 文档、图片、音频，以及 LLM 生成的完整上下文。Temporal 默认把 payload 存在数据库里，文件太大会导致：

• 数据库存储成本急剧上升
• 大文件传输拖慢 Workflow 性能
• 数据库连接超时

技术原理：

External Payload Storage 允许你把 Workflow payload 存到外部存储（首批支持 Amazon S3）。Temporal 仍然管理 metadata 和索引，但实际的文件内容存在 S3 上。这对于 AI 应用来说特别自然——文档、向量、模型输出本来就应该存在对象存储里。

# Temporal Server 配置示例（external-storage）
persistence:
  defaultStore: es-default
  visibilityStore: es-visibility
  externalPayloadStores:
    s3:
      type: s3
      config:
        bucket: my-temporal-payloads
        region: us-east-1
        # 可选：自定义 prefix、加密设置等
        prefix: "temporal-payloads/"
        sse: AES256

# Workflow 中使用 External Storage（Python SDK）
from temporalio.workflow import workflow, workflow_method

@workflow.defn
class DocumentAnalysisWorkflow:
    @workflow.run
    async def run(self, document_url: str) -> dict:
        # 下载大文件（存到 S3，由 Temporal 管理引用）
        doc_ref = await workflow.execute_activity(
            download_and_store_document,
            document_url,
            start_to_close_timeout=timedelta(minutes=10),
            # 指定使用 external storage
            payload_storage=ActivityPayloadStorage.EXTERNAL,
        )
        
        # 将文档发给 LLM 分析
        analysis = await workflow.execute_activity(
            analyze_document_with_llm,
            doc_ref,
            start_to_close_timeout=timedelta(minutes=5),
            payload_storage=ActivityPayloadStorage.EXTERNAL,
        )
        
        return analysis

性能收益： 对于 10MB+ 的 payload，External Storage 相比纯数据库存储，Workflow 吞吐量可以提升 5-10 倍。

2.5 AI 生态集成：Google ADK 和 OpenAI Agents SDK

Google ADK 集成：

Google Agent Development Kit（ADK）让开发者可以快速构建 AI Agent。Temporal 和 Google ADK 的集成把 ADK Agent 的每一步 LLM 调用和工具执行都封装成 Temporal Activity：

# Temporal + Google ADK 集成示例
from google.adk.agents import Agent
from temporalio.workflow import workflow, workflow_method, activity

# 普通的 Google ADK Agent
adk_agent = Agent(
    model="gemini-2.0-flash",
    name="research_agent",
    instruction="You are a research assistant...",
    tools=[web_search_tool, document_tool],
)

@workflow.defn
class ResearchWorkflow:
    @workflow.run
    async def run(self, query: str) -> str:
        # ADK Agent 的每次 LLM 调用和工具执行
        # 都会作为 Temporal Activity 自动获得：
        # 1. 自动重试（网络错误、API 限流自动重试）
        # 2. 持久化状态（Agent crash 后无缝恢复）
        # 3. 可观测性（每一步的执行时间和结果都可查）
        
        result = await adk_agent.run(query)
        return result

# 关键优势：
# - 之前：ADK Agent 网络中断？重新开始，之前的工作全部丢失。
# - 现在：Temporal 帮你自动重试和恢复，开发者不需要写任何防御代码。

OpenAI Agents SDK 沙箱集成：

OpenAI Agents SDK 的沙箱功能允许 Agent 在隔离环境中执行代码。Temporal 的集成让沙箱环境获得了持久化能力——沙箱崩溃或超时后，Workflow 可以从最后一个稳定状态重新启动沙箱，而不需要从头开始。

2.6 Task Queue Priority & Fairness：从"能跑"到"跑得公平"

解决了什么问题：

在大规模多租户环境中，不同团队或不同类型的 Workflow 共享同一个 Temporal Cluster。如果某个团队的 Workflow 占据了所有 Worker，其他团队的 Workflow 就会饿死。

技术原理：

Task Queue Priority & Fairness 现在 GA（正式发布），允许你在 Task Queue 上设置：

• Priority（优先级）：高优先级 Workflow 的任务会被 Worker 优先处理
• Fairness（公平性）：Worker 的执行时间会在不同租户/团队间均匀分配，防止单一来源垄断资源

# Temporal task queue 配置
taskQueues:
  - name: "order-processing"
    priorityRules:
      - match:
          workflowType: "PaymentWorkflow"
        priority: 10  # 支付相关最高优先级
      - match:
          workflowType: "NotificationWorkflow"
        priority: 3
    fairness:
      enabled: true
      weightBy: "namespace"  # 按 namespace 分配权重
      weights:
        premium-tenant: 4    # 付费租户权重 4
        standard-tenant: 2   # 标准租户权重 2

这对于平台型产品（比如帮不同客户跑 AI 任务的 SaaS 平台）特别重要——你需要保证每个客户的任务都能在合理时间内完成，而不是被某个大客户的密集任务全部卡死。

2.7 Worker Versioning：部署不再心惊胆战

解决了什么问题：

传统的 Worker 部署有一个经典困境：正在运行的 Workflow 用的是旧版代码，新版代码已经部署了，要不要停？ 停的话影响正在执行的任务，不停的话 Workflow 和新代码的行为可能不一致（特别是在动态语言中）。

技术原理：

Worker Versioning（正式 GA）通过版本亲和性解决这个矛盾：

• Worker 声明自己的版本（如 build-2026-07-23-a）
• Workflow 在启动时被"钉"到启动它的 Worker 版本
• 新版 Worker 部署后，新 Workflow 使用新版本，老 Workflow 继续用老版本直到完成
• 旧 Worker 逐渐被新 Worker 替代，零停机、零破坏性

# Worker Versioning 示例（Python SDK）
from temporalio.worker import Worker, WorkerVersioning

async def main():
    # 旧版 Worker
    async with Worker(
        client,
        task_queue="my-task-queue",
        workflow_runner=WorkerVersioning.running_version("build-2026-07-20"),
        workflows=[MyWorkflow],
        activities=[my_activity],
    ):
        await asyncio.get_running_loop().create_future()  # Run forever
    
    # 新版 Worker 同时运行
    # Temporal 自动管理版本亲和性：
    # - 已启动的 Workflow 继续用旧版
    # - 新启动的 Workflow 使用新版

这对于持续交付流程是革命性的改进——以前你需要在部署前检查是否有长时运行的 Workflow，现在完全不需要担心了。

2.8 Rust SDK：系统级开发者的春天

Temporal 终于发布了 Rust SDK（Public Preview）。对于做性能敏感型系统的团队来说，这是一个重要的里程碑：

use temporal_sdk::{Client, Worker, WorkflowOptions};
use std::time::Duration;

#[derive(Debug, serde::Serialize, serde::Deserialize)]
struct OrderPayload {
    order_id: String,
    amount: f64,
}

#[workflow_fn]
async fn process_order(ctx: WorkflowContext, order: OrderPayload) -> Result<bool, WorkflowError> {
    // Rust SDK 的并发模型使用 tokio
    // Workflow 函数必须是 async 的
    
    // 执行 Activity（带自动重试）
    let payment_result = ctx
        .activity(ProcessPayment {
            order_id: order.order_id.clone(),
            amount: order.amount,
        })
        .start_to_close_timeout(Duration::from_secs(30))
        .retry_policy(RetryPolicy {
            maximum_attempts: 3,
            backoff_coefficient: 2.0,
            ..Default::default()
        })
        .await?;
    
    Ok(payment_result.success)
}

#[activity]
async fn process_payment(ctx: ActivityContext, input: ProcessPayment) -> PaymentResult {
    // Activity 里可以跑任何 tokio 异步代码
    let client = reqwest::Client::new();
    let response = client
        .post("https://payment-gateway.example.com/charge")
        .json(&input)
        .send()
        .await?;
    
    Ok(PaymentResult { success: true })
}

Rust SDK 的价值不只是语言偏好——在需要极致性能和内存安全的场景（高频交易、游戏后端、物联网数据处理），Rust SDK 让 Temporal 可以直接嵌入这些系统，不需要额外的进程间通信开销。

2.9 高可用：多区域与多云Replication

解决了什么问题：

Temporal Cloud 的多区域复制（Multi-region Replication）和多云复制（Multi-cloud Replication）正式 GA，提供：

• 自动故障转移（Automatic Failover）：Region 或云服务商故障时，自动切换到备用节点
• 自动故障恢复（Automatic Failback）：主节点恢复后，自动切回
• RTO（Recovery Time Objective）≤ 20 分钟

# Temporal Cloud Namespace 配置示例
namespace_config:
  name: "production-ai-workflows"
  region: "us-east-1"
  failover_regions:
    - "us-west-2"        # 同云不同区域
    - "gcp-us-central1"  # 跨云
  failover_config:
    RTO: 20m
    # Temporal 自动管理 DNS 切换和 Worker 重路由

对于金融级 AI 应用（交易决策、风险控制）和合规要求（数据主权、灾备要求），多云复制是刚需。20 分钟的 RTO 对于大多数场景足够好——比很多传统数据库的 HA 方案都要强。

三、架构全景：从 Temporal 到 AI Agent 基础设施

3.1 Temporal 在 AI 应用中的位置

把 Temporal Replay 2026 的所有新功能放在一起看，会发现 Temporal 正在构建一套完整的 AI Agent 可靠执行平台：

┌─────────────────────────────────────────────────────────────┐
│                     AI Agent Application                      │
├─────────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐ │
│  │ LLM (GPT/   │  │ Tool System │  │ Memory / Context    │ │
│  │ Claude/Gemini)│  │ (MCP/WebSearch)│  │ (Vector DB/RAG)    │ │
│  └──────┬──────┘  └──────┬──────┘  └──────────┬──────────┘ │
│         │                │                     │            │
│         └────────────────┴─────────────────────┘            │
│                          │                                  │
│                          ▼                                  │
│  ┌──────────────────────────────────────────────────────┐  │
│  │           Temporal Durable Execution Layer            │  │
│  │  ┌────────────────────────────────────────────────┐ │  │
│  │  │ Workflow Engine   │  Activity Executor          │ │  │
│  │  │ - Workflow Streams (streaming tokens)           │ │  │
│  │  │ - Standalone Activities (independent tasks)     │ │  │
│  │  │ - External Payload Storage (S3 for large data)  │ │  │
│  │  ├────────────────────────────────────────────────┤ │  │
│  │  │ Reliability Primitives                          │ │  │
│  │  │ - Automatic retries      - State persistence    │ │  │
│  │  │ - Serverless Workers     - Worker Versioning     │ │  │
│  │  │ - Task Queue Priority                            │ │  │
│  │  ├────────────────────────────────────────────────┤ │  │
│  │  │ Observability                                   │ │  │
│  │  │ - OpenMetrics/Prometheus - Worker Status UI     │ │  │
│  │  │ - Temporal Web UI       - Event History          │ │  │
│  │  └────────────────────────────────────────────────┘ │  │
│  └──────────────────────────────────────────────────────┘  │
│                          │                                  │
│                          ▼                                  │
│  ┌──────────────────────────────────────────────────────┐  │
│  │          Temporal Cloud / Self-Hosted Server          │  │
│  │  - Multi-region replication  - 99.9999% uptime SLA   │  │
│  │  - SCIM / SSO               - Billing API             │  │
│  └──────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

3.2 和现有方案对比

四、生产落地指南

4.1 迁移路径建议

对于已有 Temporal 部署的团队：

优先级从高到低：

1. Worker Versioning（GA）—— 立即启用，解决部署噩梦
2. Task Queue Priority & Fairness（GA）—— 如果是多租户场景
3. External Payload Storage（Public Preview）—— 如果你在处理大文件
4. Standalone Activities（Public Preview）—— 评估现有代码中是否有可以简化的场景
5. Workflow Streams（Public Preview）—— 如果你在做 AI 流式应用
6. Rust SDK（Public Preview）—— 新项目可以考虑

对于从零开始的 AI 应用团队：

Temporal Cloud + Serverless Workers 是最低成本的入场方案：

• 不需要运维 Temporal Server
• 不需要管理 Worker 基础设施
• 按实际使用量计费（Workflow 执行次数 + Activity 执行时间）
• 从第一天就获得所有 Durable Execution 的能力

4.2 监控与可观测性

Replay 2026 发布了几个重要的可观测性能力：

# Temporal Cloud OpenMetrics 配置
# Prometheus 格式，可以直接对接 Grafana
metrics:
  endpoint: "https://<namespace>.tmprl.cloud:7233/metrics"
  headers:
    Authorization: "Bearer <token>"
  # 可用的 metrics:
  # - temporal_workflow_started_total
  # - temporal_workflow_completed_total
  # - temporal_activity_execution_duration_seconds
  # - temporal_cloud_v1_billable_action_count  # 计费指标

Worker Status UI（Public Preview）是另一个亮点——它让你可以在 Web UI 中直接看到每个 Worker 的状态、可用 slot、CPU 使用率，而不需要 SSH 到服务器上查日志。

4.3 成本考量

Temporal Cloud 的计费基于 Actions（Workflow 执行次数 + Activity 执行次数）和执行时间。对于高频 AI 工作负载，成本可能比自建 Kafka/Redis 方案高一些，但考虑到你不需要再写那些防御性代码、生产环境可靠性有保障，很多团队的 TCO（总拥有成本）是更低的。

新发布的 Billing API 和 Billable Action Metrics 让你可以把 Temporal 的使用量集成到自己的成本监控系统中，实现按团队/按客户的精细化计费。

五、总结与展望

5.1 核心价值总结

Replay 2026 的所有发布，可以归纳为一个主题：让 AI 应用的可靠性不再是工程师的手工活。

以前，AI 应用的可靠性靠工程师写大量防御性代码来实现——幂等设计、重试逻辑、状态恢复、补偿事务。这些代码枯燥、容易出错、而且跟业务逻辑完全无关。

Temporal 的思路是：把这些可靠性基础设施抽象成平台能力，让工程师只写业务代码。 Serverless Workers 让你不需要管基础设施，Workflow Streams 让你不需要管流式状态，Standalone Activities 让你不需要管任务队列，Worker Versioning 让你不需要管部署兼容性。

5.2 值得关注的方向

1. 组件模型（Component Model）仍未完成：这是 Wasm 生态的重要方向，PostgreSQL 19 Beta 2 的发布说明中未提及，可能还需要时间。
2. Rust SDK 成熟度：Rust 生态的 AI 应用在快速增长，Rust SDK 的 GA 时间表值得关注。
3. Temporal 的 AI Agent 市场：Replay 2026 推出了 AI Partner Ecosystem，未来可能会有更多 AI 框架（LangChain、LlamaIndex 等）的原生集成。
4. 定价策略调整：随着 Serverless Workers 的推出，Temporal Cloud 的计费模型可能会进一步演进，需要持续关注。

5.3 给工程师的建议

如果你正在构建 AI 应用或平台，建议把 Temporal 纳入技术选型的核心考量。它不是银弹——对于简单的微服务间调用，gRPC 和消息队列更轻量；但对于需要长时运行、带状态、可恢复、AI 交互的工作流，Temporal 的 Durable Execution 是目前最成熟的解决方案。

Replay 2026 的发布让 Temporal 从"Workflow 引擎"进化成了"AI Agent 的可靠执行层"。这个定位的转变，意味着 Temporal 未来会成为 AI 应用架构中不可或缺的基础设施组件——就像数据库和消息队列一样，是每个 AI 应用团队迟早要掌握的技术。

参考资料

• Temporal Replay 2026 产品发布公告
• Temporal 官方文档
• Temporal Serverless Workers 文档
• Workflow Streams 文档
• Standalone Activities 文档
• External Storage 文档
• Temporal Rust SDK 文档
• Temporal Google ADK 集成
• Temporal GitHub