标题：Temporal 是什么？2.3 万星的开源持久执行平台，七个月估值翻倍到 125 亿美元（基础篇）
导语
前阵子我写 Prefect 那篇（2.4 万星的工作流引擎），评论区有人问：Agent 这东西跑几分钟挂了就前功尽弃，有没有更硬的底座？
有。而且它 2026 年 9 月刚融了 5.5 亿美元，估值 125.5 亿美元，七个月翻了一倍多——注意，这不是 AI 应用公司，是一家 2019 年成立、干了七年分布式工作流的老基建公司。
它叫 Temporal。
项目介绍：它不跟 Agent 抢活，只给 Agent 兜底
Temporal 的自我定位是 Durable Execution（持久执行）平台。它的核心承诺只有一句：程序一旦跑起来，就一直跑下去，进程死了、机器炸了、网络断了都能接着跑。
这跟 Agent 撞不撞？看它自己的分工就很清楚——框架负责 AI，Temporal 负责基建。
它的编程模型只有两个概念：
- Workflow（工作流）：放控制流，循环、分支、并行、超时这些无聊的逻辑。
- Activity（活动）：放不靠谱的活，调 LLM、请求外部 API、执行工具。
关键在于 Activity 会被记录进 Event History（事件历史）。Worker 崩了重启，Temporal 拿这份历史重放（replay）一遍，已经完成的 LLM 调用直接从历史里读结果，不会再烧一遍 token。
这个设计对 Agent 意味着三件很实际的事：
- LLM 撞限流不慌。429 之后自动重试，Workflow 挂着等，等额度恢复了自己往下走。
- 等审批不烧钱。人类可能一天后才点确认，这期间 Workflow 挂在 Temporal 服务端，零算力占用。等你 Go 项目里的
time.Sleep早就把机器占住了。 - 长跑任务是常态。官方说他们客户里有跑了好几个月的 Agent，continue-as-new 让它可以无限期跑下去还不爆内存。
血缘这块也挺硬：CTO Maxim Fateev 在亚马逊带过 SQS 的底层消息基建和 Simple Workflow Service，CEO Samar Abbas 在微软参与了 Durable Task Framework（Azure Durable Functions 就建在这上面），两人 2015 年在 Uber 一起做 Cadence，2017 年开源，三年内内部用了 100 多个场景，2019 年出来单干做 Temporal。
数据摆在这（2026 年 9 月官方公布）：
- GitHub
temporalio/temporal23462 星，MIT 协议，主力语言 Go - 最新版 v1.32.0（2026-09-11）
- 8 月单月处理 1.9 万亿次计费操作，同比增长 350%+
- 开源安装量 4300 万+，比 2025 年 12 月涨 134%
- 付费客户 4300+ 家，同比涨 139%，点名 OpenAI、Snap、NVIDIA
- Snap 每天在它上面跑 4.14 亿条 Stories，OpenAI 的使用量一年涨了 60 倍
- 团队一年翻倍到 570 人
上手：一条命令起本地环境
Temporal 的本地开发体验是这个项目做得最好的部分。
temporal server start-dev
这一条命令就起来了：本地 Temporal 服务 + 数据库 + 内置 Web UI（默认 8233 端口）。不用装 Docker，不用配 MySQL，不用申请任何 API Key。
然后装 SDK 起个 Worker：
pip install temporalio
Python 里 Workflow 是一个加了装饰器的类，Activity 是普通函数：
from temporalio import workflow, activity
@workflow.defn
class AgentWorkflow:
@workflow.run
async def run(self, question: str) -> str:
# 控制流放这里：循环、分支、并行
answer = await workflow.execute_activity(
call_llm, question,
start_to_close_timeout=timedelta(seconds=60),
)
return answer
@activity.defn
async def call_llm(question: str) -> str:
# API Key 只存在于 Worker 进程，不会进 Event History
...
上手 Agent 有个偷懒办法。Temporal 现在已经把持久执行接进主流 Agent 框架了，你的 Agent 主循环代码基本不用改：
| 框架 | 集成状态（2026-10） |
|---|---|
| OpenAI Agents SDK | 2026-03-23 转正（GA） |
| LangGraph | 2026-07 公开预览 |
| Google ADK | 已集成 |
| AWS Strands | 已集成 |
| Vercel AI SDK | 已集成 |
| Pydantic AI | 已集成 |
它还有自己的 Temporal Agent Harness（2026-08 放出，还在早期），套在你现有的 harness 外面加审批策略、工具回调和 AgentEvent 事件流。注意官方自己说这个项目「比公开预览还早」，API 会变。
自托管的坑提前说清楚：唯一必需的依赖是一个数据库。官方支持 Cassandra、PostgreSQL、MySQL，1.20 版本之后高级可见性（Advanced Visibility）在 SQL 库上也能用，不用非得配 Elasticsearch。SQLite 官方只建议开发和测试用，别上生产。
实话：这个层到底要不要上
说点难听的。
第一，官方自己承认它不能替代安全和治理。 持久执行解决的是「跑得完」，不是「跑得对」。它不管权限、不管合规、不管你 agent 会不会乱花钱。E 轮那篇博客里写得很明白，持久执行「不能替代安全、治理或合规；开发者必须单独整合这些层面」。指望接上 Temporal 就万事大吉的人会失望。
第二，学习曲线不低。 Workflow 的确定性约束（不能直接调时间、随机数、外部 API）、Activity 必须设超时、幂等性自己保证——这些概念对没用过分布式系统的人是新东西。而且它的集成大多还在 Public Preview 阶段，随时可能变。
第三，这不是个人和小团队项目。 4300 个付费客户里是 OpenAI、NVIDIA 这种量级。它的设计目标是跑几个月的生产 Agent，不是让你跑个 30 秒的脚本。对个人玩家，我上一篇文章讲的 Dify 或 n8n 加一层重试队列，成本和复杂度都更合理。
但它的判断我认为是对的。 CEO Samar 那句话我挺认同：「可靠性从来不是可选项，但 AI 迅速提高了跳过它的代价。」这话现在听着像套话，等你半夜被 LLM 限流吵醒、发现跑了四十分钟的任务全丢了的时候就懂了。
顺带一句，如果你还在纠结 Agent 平台选型，可以看看我之前写的这几篇：
- Prefect 是什么？2.4 万星的持久化工作流引擎（基础篇）
- Agent 平台怎么选？Zapier、Make、Dify、Langflow、CrewAI、MetaGPT 横向一张图讲清
- 谁说开源就能随便商用？Dify、n8n、CrewAI 的 LICENSE 里藏着最大的坑
- Flowise 归档横评：55K 星的平台死了，比它星数更高的 MetaGPT 也没活着
选型的一句话结论：Agent 跑几分钟就完 → Dify / n8n 够了；Agent 要跑几天、等人审批、要为可靠性付费 → 上 Temporal。这两层别混着比。
by 数码罗记 · godsun.pro
