虽然大家都期待未来的 Agent 能够真正端到端完成所有任务，并且在出错时也知道如何重新开始，但目前 AI 还没有达到这种能力。原因之一是现有的模型尚不具备持久记忆的能力，难以支撑持续数日、数周的任务；同时，任务执行的可靠性也并不稳定，往往需要多个 Agent 协作，或与企业内部数据库连接。在这种情况下，编排层能够协调不同的 agent，并提高任务执行的可靠性。
此外，成本控制同样是推动编排层发展的核心动力。编排层可以通过优化 prompt、压缩上下文，以及在不同场景下选择更高效的模型，有效降低计算消耗。同时，它能够在错误定位上发挥作用，避免出错后又从头执行任务，从而大幅节省 token 成本。
在这一背景下，提出 durable execution 的 Temporal 成为了最受关注的公司之一。本文编译了 CTO Maxim Fateev 的访谈，Maxim 认为 durable execution 的核心在于确保所有工作流都能够被可靠地执行，即使在程序崩溃、网络中断、外部 API 调用失败等情况下，工作流也能从出错的那一步继续执行，而不必从头再来。因此开发者可以完全聚焦于业务逻辑，而无需为失败场景编写额外代码。今年 3 月，Temporal 宣布完成 1.46 亿美元 C 轮融资，估值达到 17.2 亿美元，Nvidia、OpenAI 都是它的现有客户。
但我们认为，Temporal 也面临潜在挑战：一方面如果未来 AI agent 的自愈与容错能力显著提升，市场对持久化编排的依赖可能下降；另一方面，大型云厂商如 AWS、Google Cloud 也可能加码投入，在这一关键基础层形成直接竞争。此外，部分大客户如 OpenAI 也可能因成本与控制力考虑转向自建方案。
01.
Temporal 是什么？
Temporal 是一家成立于 2019 年的 AI infra 公司，核心概念是 Durable Execution，即确保所有工作流都能够被可靠地执行，即使在程序崩溃、网络中断、外部 API 调用失败等情况下，工作流也能从出错的那一步继续执行，而不必从头再来。
Temporal 最初主要用于相对小众的“长时间编排”场景。随着 AI agent 的兴起，市场对 agent 长期运行以及频繁调用外部 API 的需求迅速增加，Temporal 的能力被进一步放大，从传统的编排工具逐渐演变为 AI infra 的重要组成部分。如今 Temporal 已经成为分布式系统中的关键编排层，可以自动处理执行失败的任务，并支持重启，能够为复杂任务和长生命周期工作流提供可靠保障，开发者只需关注业务逻辑，而无需额外编写应对失败情况的代码。
Temporal 系统
根据公开新闻，目前 Temporal 已有超过 2500 家客户，包括 Nvidia、Airbnb、Bloomberg、OpenAI、Netflix、Datadog 等，NDR 高达 184%。
Temporal 客户
但 Temporal 也面临一定的风险。未来如果 AI agent 的容错能力显著提升，对持久化编排的依赖可能会减少，以及 OpenAI 等大型客户也可能因为成本原因选择自建，从而降低对 Temporal 的依赖。同时，AWS、Google Cloud 等巨头尽管目前在这一领域不及 Temporal，但未来可能加大投入，使 Temporal 的竞争压力变大。
产品架构
开发者只需将业务逻辑写在工作流函数中，Temporal 就能保证它被可靠、持久地执行。唯一的限制在于工作流函数必须保持确定性，即在相同的输入和历史记录下，每次重放都能得到相同的结果，因此不能在直接进行具有不确定性的操作，比如文件或网络 IO、访问数据库、调用外部 API、读取系统时间或生成随机数等。
这类交互需要封装在 Activity 中，由工作流通过调用 Activity 来完成，从而确保工作流逻辑在重放时始终一致。而工作流本身的状态则由 Temporal 通过 Event Sourcing 机制自动恢复，确保即使系统发生中断，执行也能从正确的位置继续。
在 Temporal 中，Activity 指的是工作流函数之外执行的具体任务，用来封装所有可能带来不确定性的操作，这些操作的执行结果会被记录下来，从而保证工作流本身的确定性。
Event Sourcing 是一种存储状态的方式，不直接保存最终结果，而是把系统里发生的所有事件按顺序记录下来，之后可以通过重放这些事件恢复出完整状态。
下面这个例子展示了客户如何通过 Temporal 启动工作流，并进行异步执行：
假设有一个 AI agent 应用，客户发起了查询订单的请求，系统会通过 SDK 调用 StartWorkflowExecution 来启动工作流。然后这个调用会发送到 Temporal，传入加密后的参数并指定一个唯一的工作流 ID，如订单号。Temporal 接收到请求后，会更新内部状态，并将这个任务放入队列（Task Queue） 。之后 Worker 会执行对应的工作流代码。
Worker 是用户编写并运行的程序进程，它会轮询 Temporal Server 来获取任务，然后执行其中工作流代码和 Activity 代码，相当于任务的执行者。
队列（Task Queue） 是工作流和任务的分发通道。工作流代码不会直接调用某个 Worker，而是把任务放入指定的队列；Worker 进程会主动从这个队列中轮询任务并执行。这样，多个 Worker 可以共享同一个队列，实现负载均衡和容错。
如果需要访问外部服务，比如调用 LLM，工作流代码会创建一个 Activity，交给 Temporal 处理。Temporal 会记录事件并将任务放入队列（Task Queue）。Worker 会从队列中取出任务，并执行调用 LLM 的任务，然后将结果返回给 Temporal。Temporal 更新并继续执行这个任务。如果接下来还需要调用其他工具，这个过程会重复进行。
Temporal 架构
这种架构的一个主要优势在于，所有调用都是通过队列（Task Queue）异步完成。系统通过事件驱动、异步回压、流量控制等措施来保证稳定性，Worker 只需不断轮询队列，无需暴露端口，从而简化了开发流程。开发者只需发起一次 RPC，就可以快速得到响应，即使后台出现拥堵或延迟，系统仍能平稳运行，确保任务按预期执行。工作流完成后，系统会返回最终结果，客户端可以选择同步等待或异步接收通知，直到结果就绪。
RPC（Remote Procedure Call，远程过程调用）是一种让程序可以像调用本地函数一样调用远程服务器上函数的技术。它隐藏了网络通信细节，使分布式系统的功能调用更加透明和方便。
更为重要的是，这种架构具有高度鲁棒性（Robustness），即任何组件的宕机都不会影响整体运行。每个任务都有超时机制，如果某个 Worker 崩溃，任务会被自动重新分配，这也意味着，即使 Temporal 在调用 LLM 或其他外部工具时发生错误，工作流本身也不会受影响。
即使宕机重启，Temporal 也能在没有人工干预的情况下，无缝继续执行原来的任务，比如 Activity 会按照设定的策略自动重启，也就是说可恢复的错误会被系统自动重启，不可恢复的错误则交回业务逻辑处理。而且 Temporal 不限制重启的时间跨度，开发者甚至可以重启一个月以前的策略。
此外，队列（Task Queue）还有个显著优势在于，它是完全动态的，没有数量上限，因此系统可灵活扩容或缩容，用户也可以为每个进程配置独立队列，比如用户可以把第一个任务分配到任意主机的同时，要求第二、第三、第五个任务必须分配到同一主机。
Use case
Temporal 早期主要应用于长生命周期的业务流程，典型场景包括电商和出行，比如 Uber 的打车流程、Airbnb 的订单流程，这些场景的共同点是代码执行可能会持续数分钟到数天，中间会经历多步 API 调用。
目前，作为一个通用平台，Temporal 可以提供“任务必然会被执行”的强保证。凡是需要确保执行可靠性的场景，都可以使用 Temporal，因此它的应用范围非常广泛。随着系统规模和复杂度的提升，这种保证让 Temporal 成为支撑容错、自愈与流程编排能力的关键 infra。
典型使用场景包括：
• Infra 运维编排：Uber 在数据中心部署新内核的时候，需要启动几十万台机器，这种大规模的操作协调是通过 Temporal 的工作流技术来实现的。
• 集群与 infra 管理：Kubernetes 用 Temporal 进行集群和底层 infra 的部署维护；HashiCorp 及部分云服务商基于 Temporal 来构建产品；Datadog 也用 Temporal 主动编排后端；许多公司在自建控制平台时，都把 Temporal 作为首选方案。
• 应用部署（CI/CD）：Netflix 曾基于 Temporal 重写过一版 Spinnaker，后来由于 Kubernetes 在扩展性上无法满足 Netflix 的需求，Netflix 甚至决定放弃 Kubernetes，转而以 Temporal 作为核心引擎来驱动 infra 的自动化。
• 数据管道与处理：传统的数据处理方案在文件操作方面表现出色，但在需要大量且不确定次数的 API 调用时，就无法满足需求了。以开发票为例，有的发票只需一次 API 调用即可完成，有的可能需要成千上万次，Uber 的经验是大客户生成一张发票可能要花一个小时，而小公司则只需几秒。对于这种高度复杂、调用次数差异巨大的任务，用户可以用 Temporal 进行编排。
• 支付与金融：在金融科技领域，跨境支付、汇款等涉及多方系统交互的流程对容错率等指标有非常高的要求，比如 Coinbase 为了确保跨区块链的数据传输的可靠性，每一笔交易都运行在 Temporal 上；印度 UPI（Unified Payments Interface，统一支付接口）、巴西的实时支付系统也在使用 Temportal。
• AI Agent：以往的 agent 框架更多关注“如何调用 API、如何处理数据”，但真正的难点在于如何在大规模场景下实现容错与自愈，而这正是 Temporal 的价值。Maxim 表示，许多团队已经将 agent 框架迁移到了 Temporal 上。
开源与商业化
Temporal 有开源版本（Self-hosted）和托管云服务（Temporal Cloud）两个版本的产品：
1. 开源版本：开发者可以在自己的环境中部署和管理 Temporal。
2. 托管云服务：由 Temporal 官方和维护的服务，用户不需要自行负担 infra 的管理。
Temporal Self-hosted 和 Temporal Cloud
这两个版本的服务器和 SDK 是兼容的，并且支持在线迁移，也就是说用户可以将正在运行的开源集群无缝切换到云端，这个过程无需停机，就可以实现在不同部署模式之间自由切换，比如 Netflix 就从 Temporal 的开源版本迁移到了云端版本。
• 开源版本
Temporal 一开始就是以开源形式发布产品的，使用了 MIT 协议，Maxim 认为 MIT 协议的宽松性让客户能够放心使用 Temporal，如果修改了协议，可能会导致客户流失。因此 Temporal 的开源版本始终完整可用，比如 DataDog、Salesforce 等大型企业就选择用 Temporal 的开源版本自建大规模集群。
在开源领域，infra 公司常常面临被 AWS 等云厂商“套壳”的风险，即 AWS 等云厂商在云上重新提供相同的服务。但 Maxim 认为这不值得担忧：
1. Amazon 近年来在开源上的态度更加开放，Temporal 与它保持着良好关系，并建立了长期合作，Temporal 也已在 AWS Marketplace 上架；
2. Temporal 的托管云服务与开源版的差异不止“托管”，而是在核心技术上也有差异，比如 Temporal 自研的 Cloud Data Store （CDS） 专为 Temporal API 深度优化，而开源版仅支持 MySQL、Postgres 和 Cassandra。因此即便只计算基础运行成本，云端的成本通常也不高于自建，算上运维成本后，云端往往更具优势。
在这种情况下，即便 Amazon 想要“套壳”Temporal，也必须付出巨大代价重写数据库，才能实现与 Temporal 同等效果的性能。而且如果 Amazon 真的这样做，反而会加速 Durable Execution 的普及。值得一提的是，AWS 曾经推出过 Simple Workflow Service，但如今已基本放弃了这个产品的推广。
Amazon Simple Workflow Service （SWF） 是 AWS 在 2012 年推出的一项工作流协调服务。它让开发者能够在云端构建、运行和扩展后台作业流程，核心概念与后来的 Durable Execution 有相似之处，可以被视为 Temporal 和 AWS Step Functions 等现代工作流引擎的“前身”。
• 托管云服务版本
在商业模式上，Temporal 的商业模式十分简单：它仅对托管的后端集群按使用量计费，客户随用随付，无需签署大合同，客户核心的库始终运行在客户自己的环境中，这种模式既符合客户利益，也符合公司的长期发展逻辑。
Temporal 的定价
Maxim 认为，历史上许多流行的开源项目（如 Docker）都遇到过一个困境：如果一家公司提供的只是一个开发库，那么即使这个库再受欢迎，也很难直接转化为收入来源。所以真正能够支撑商业化的，往往是运行在后端、不可或缺的核心组件，比如数据库、消息队列，或像 Temporal 这样可以同时承担调度与存储的系统，Temporal 也因此成为企业最核心的 infra。
总的来说，Temporal 为开发者提供了一种更高效的编程模型。开发者一旦上手并熟悉后，往往会将 Temporal 应用到核心业务中，以确保系统的高可用性、数据的持久化，从而提升整体开发效率。Maxim 认为，随着使用的深入，企业自然会意识到相比自己维护复杂的 infra，直接采用云服务更为省心可靠。
Temporal 如何提供多种语言的 SDK？
相比很多竞争对手只支持 1-2 种语言，Temporal 提供了多种语言的 SDK。实际上，开发一个 SDK 难度非常大，多语言支持的复杂度也非常高，因为接入不同语言需要面临不同的挑战，而且 Temporal 要求工作流代码必须具备确定性，因此 Temporal 在支持任何新语言时，都会先确保这个语言的执行过程是确定的：
• Python：支持流程相对简单，因为 Python 有一个具有完全确定性的调度器，可以保证每次执行顺序都一致。
• TypeScript：Temporal 基于 V8 isolates 构建了一个具有完全确定性的运行环境。比如：开发者在重启时调用 time ，会返回相同时间，调用 random 时，会返回相同随机数。
• Java 和 Go：这两种语言是最复杂的，因为它们支持多线程，而多线程天然带来不确定性。Temporal 希望保留多线程开发体验，因此 Temporal 通过框架内部调度器将它们改造为顺序执行的协作式多线程，比如在 Java 中，开发者不能直接用 new Thread来创建线程，必须通过 Temporal 提供的 API；在 Go 中，开发者不能直接写 go，而要用 workflow.Go。
此外，Temporal 在后端实现了一个非常复杂的状态机（State Machine），用于正确地跟踪、管理和恢复工作流在不同状态之间的执行过程，这些状态机的逻辑决定了何时发送命令、何时触发计时器、何时响应信号等。在处理跨语言一致性问题时，Temporal 将这些核心逻辑集中在一个由 Rust 编写的共享核心库（Core SDK）中，而不同语言的 SDK（如 Python、.NET、TypeScript、Ruby）都依赖于这个 Rust 核心库来复用逻辑、保证一致性且避免重复实现。
02.
Durable Execution 是什么？
核心价值在于 Runtime Visibility
Temportal 的核心概念是 Durable Execution，从概念上看，Durable Execution 是第一个真正能够让开发者摆脱分布式系统复杂性的技术，进程不再依赖于某台固定的机器，而是能够在不同节点间无缝迁移。
在传统开发模式中，程序可能随时崩溃。为了避免数据丢失，开发者通常需要把业务逻辑拆分得非常细碎，并在关键步骤频繁保存状态，再借助数据库或消息队列（Task Queue）来保证后续能够恢复。Durable Execution 的设想就是：如果程序在任意时刻都能将完整的执行状态持久化，会带来怎样的变化？
比如当开发者编写一个基于 LLM 的工作流时，通常的流程是先调用 LLM，然后再调用一系列工具。如果在调用工具的过程中进程崩溃，传统方式下所有进度都会丢失，只能从头重跑。而在 Temporal 中，状态会被持久化，即使进程三天后才恢复，也能从中断的那一行继续执行，所有变量和环境都会保持不变。换句话说，对开发者来说，崩溃就像从未发生过。代码可以长期运行，系统会自动持久化和恢复它，因此不再需要显式地用数据库保存状态。
再比如，一个 API 调用可能只需 50 毫秒，也可能要等 5 天，但在 Temporal 里没有区别。开发者甚至可以直接写下 sleep（30 days） 这样的逻辑（sleep 是编程中让程序暂停一段时间的函数），就能实现类似订阅计费的场景：每隔 30 天自动扣费并发送邮件。
Durable Execution 的核心价值就在于 runtime visibility。系统会完整记录每一次交互，包括活动调用、输入输出，以及错误发生的次数和位置。如果某个流程被阻塞，开发者只需打开 UI 就能快速定位问题；同时，开发者还可以下载完整的执行历史，在调试器中重放生产环境中的失败案例。
此外，Temporal 还支持与监控系统（如 Grafana）对接，并能通过 context 传递提供更丰富的可观测性。但即便只依赖内置的 UI 和历史记录，用户也能清楚了解系统的真实运行状态。
Durable Execution 是如何运行的
未来发展方向
Durable Execution 未来有几个演进方向：
首先是可以构建一个确定性的 runtime。Maxim 认为 WebAssembly 的潜力巨大，Temporal 最初也尝试过用它来构建工作流的 runtime。但在当时，除了 Rust、C++ 外，其他语言编译到 WebAssembly 都会带来额外的持续开销，难以支撑数十亿级的并发场景，因此并不适合大规模应用。不过，Maxim 表示一旦技术成熟，Temporal 一定会采用 WebAssembly，未来甚至可能出现专门为 WebAssembly 打造的高性能 runtime ，进一步甚至有可能发展为操作系统。
WebAssembly 是一种高性能、跨平台的二进制格式，可以让多种语言在统一、安全的沙盒环境中运行。它的确定性和可重放特性非常适合 Temporal 这样需要大规模并行并保持严格一致性的工作流引擎。
目前 Temporal 提供了一个跨服务器、跨数据中心的分布式运行环境。在这个环境中，开发者可以像在操作系统管理本地进程一样，管理有状态的分布式任务。Maxim 认为随着技术演进，它将不断靠近真正的操作系统形态，并逐步内置更多服务与功能。
另一个演进方向是面向 agentic 应用。几乎所有 agent 在长期发展中，只要需要关注状态并执行真实任务，就会以 Durable Execution 协调器的形式运行。如今，已经有不少公司在生产环境中使用 Temporal。未来，Temporal 所承载的 agent 任务量甚至可以超过头部 AI 公司，目前 OpenAI 在图像生成和 Codex 的底层技术中都已经采用了 Temporal。
此外，RPC（Remote Procedure Call，远程过程调用）也是一个关键的发展方向。Temporal 研发了 Nexus RPC 协议，它本质上是对 HTTP 的扩展，能够支持长时间运行的操作，之后 Temporal 计划将它与 MCP 结合，来进一步增强对长时工具调用的支持。这样不仅能保证调用的可靠性和可持续性，也与 Temporal 的特性高度契合。未来，Temporal 有机会成为工具调用生态中的核心环节，尤其在跨公司调用和可靠性保障方面发挥关键作用。
03.
Temporal 如何用 Durable Execution 解决传统痛点？
数据负载过大和流式响应
数据负载（Payload）指的是一次请求或消息中携带的实际数据内容，比如 API 返回的一段 JSON、一个文件或模型的输出结果。
流式响应（Streaming Response）指的是服务器不是一次性把完整结果返回给客户端，而是把结果拆成一小段一小段的数据流或分片来持续发送。
Maxim 将流式响应比作拨号上网时代看 JPEG 图片：有的从上往下逐行显现，有的交错显示。但随着模型生成速度的提升，tokens 几乎在瞬间就能被生成，因此流式的价值正逐渐减弱。对于后台的 agent 来说，它真正需要的是完整结果，以便进行后续决策，因此工作流本身并不依赖流式输出，流式更多是为了改善用户等待时的体验。
针对大规模数据负载或流式响应等场景，Temporal 设计了相应方案，主要分为两类：
1. 如果 payload 只是从一个 Activity 传递到另一个，中间无需额外处理，最优做法是将数据存放在外部存储（如 S3、Blob Store，甚至本地文件系统）中，在工作流中只传递数据指针即可。由于 Temporal 支持将任务路由到同一台主机，因此可以利用本地缓存来避免重复传输。
2. 如果必须在工作流代码中直接处理 payload，那就应该尽量缩短处理路径，要么缓存数据并尽快返回结果，要么只存储关键结果，而非完整文件。例如，如果用户只关心文件的字数，就没必要保存整个文件内容。
工作流版本变化
在工作流发生变化但已有流程仍在运行的情况下，或者在服务器崩溃后恢复时，模型版本却发生更新的情况下，往往会有版本管理的难题。传统的 ad-hoc system 通常缺乏版本控制，需要迁移数十个组件、数据库和服务，过程非常复杂。而 Temporal 借助 Durable Execution，通过两种机制来解决版本问题：
1. 对于短生命周期的工作流（几分钟到一天以内），可以将每个工作流绑定到特定版本的代码。例如，启动时使用 v1 版本，并将它分配给对应的一组 Worker，直到这些工作流全部完成，这种做法称为“彩虹部署”（rainbow deployment）。对于某些语言，可以在同一进程中同时加载多个代码版本，比如在 Python 中可以通过子进程来实现这个效果，Temporal 计划在未来继续强化这一能力。
2. 对于运行一个月甚至更久的长生命周期工作流，即使修复了 bug，也无法直接无缝切换版本。解决方法是在代码中同时保留新旧版本，并通过条件分支进行控制：已经执行过的逻辑继续使用旧代码，尚未执行的逻辑则使用新代码。这样既保证兼容性，又能实现逐步升级。
此外，Temporal 提供了回放测试（Replay Test）等工具，可以将历史执行记录存入仓库，每次测试时重放，从而确保新代码不会破坏已有流程。Temporal 还在开发自动回滚和预检回放等功能，来进一步提升部署和迁移的安全性。
代码无法持久化
在 Durable Execution 出现之前，人们通常依赖工作流引擎，但这些引擎有一个问题：开发者用 Java、Go、Python 或 TypeScript 编写的代码默认并不持久化。如果需要持久化，就必须将代码转换为某种中间形式，如 JSON 文档、UI 图表、DSL 描述或语法树等。
因此，市场上出现了 BPMN、AWS Step Functions 等方案，它们将高级语言抽象为语法树，再用 JSON 或 XML 描述。但这种方式对开发者并不友好，也违背了“非技术人员也能编排业务逻辑”的初衷。随着工作流复杂度增加，甚至连专业开发者也会感到困难，因为 JSON 或 XML 无法完整表达 Java、Go、TypeScript 等语言的特性。
Temporal 采用了完全不同的思路。借助 Durable Execution，开发者可以直接使用原生语言编写工作流逻辑，完整保留原生语言的特性，比如类、接口、同步代码，甚至反射机制。无论是 Java、Go 还是 TypeScript，使用体验都与平常开发一致，还能跨语言互调。同时，原有的单元测试框架（如 JUnit）、CI/CD 流水线都可以无缝复用，这一切都可以在代码库中完成，无需额外部署，只需连接 Temporal 后端集群。
值得注意的是，这个后端可以是 Temporal 的开源版本，也可以是 Temporal Cloud。Temporal Cloud 仅负责存储，因此 Temporal 能够满足对安全要求极高的企业的需求：
1. 代码在企业内部运行，云端无法访问或了解业务逻辑；
2. 数据在发送到云端前就完成加密，密钥和加密算法完全由企业掌握；
3. 客户端主动连接云端，但云端不会主动回连，企业无需在防火墙上额外开放端口；
4. 大多数企业甚至通过 Private Link 访问云端，从而进一步增强安全性。
04.
创业故事
Maxim Fateev 是 Temporal 的 CTO。他过往的职业经历主要集中在大型科技公司。他在 Amazon、Microsoft、Google、Uber 都担任过工程师职位，2019 年创办了 Temporal。Maxim 过往几乎没有管理团队的经验。在创立 Temporal 后，他在前四年左右时间担任 CEO，自 2024 年起转为 CTO。
在 Amazon 工作期间，Maxim 曾担任 Amazon Messaging Platform 的技术负责人。这个平台比 Kafka 出现的时间更早，最终成为 Amazon SQS 的后端。他还主导了 Amazon Simple Workflow Service（SWF） 的开发，SWF 的设计理念后来被 Uber 的开源项目 Cadence 借鉴。Temporal 正是 Maxim 在 Cadence 基础上创立的。
开源项目 Cadence 是 Uber 开发的一个分布式、可扩展、持久且高可用的工作流编排引擎。
Maxim Fateev 工作经历
Maxim 的创业动机非常直接：虽然现在几乎所有应用都是分布式的，但开发者能使用的仍然只是一些非常底层的抽象工具。他们需要自己组合各种 patterns 来构建解决方案。这就带来了两个问题：一是每次都得从零开始搭建；二是不同开发者的实现方式差异很大，缺乏统一的中间层，导致大家不断重复造轮子。
从业务逻辑的角度来看，很多应用开发需求其实很直观，比如开发者只需要按一定顺序调用十几个 API，并加入一些条件判断和动态逻辑。但一旦要把这些逻辑实现成可扩展、可恢复的分布式应用，它们就会被拆散到回调、服务、状态管理等各个模块中。结果原本几行代码就能清楚表达的业务逻辑，往往膨胀成上万行与业务无关的复杂代码。
因此 Maxim 创立了 Temporal，希望能让开发者专注于核心业务逻辑，而无需处理底层复杂技术，同时可以确保应用具有可扩展性、稳定性和高可靠性。
文章来自于微信公众号“海外独角兽”，作者是“lvy、Haozhen”。
