Temporal 的持久化执行：让 AI 智能体不掉线的 Human-in-the-Loop 架构

当「人类是一个异步 API」

在 AI Engineer 大会的这场演讲中，来自 Temporal 的演讲者抛出了一个值得玩味的观点：人类对于 AI 智能体来说，本质上是一个异步 API。

当下几乎所有人都在讨论 agentic loop——推理（reason）、行动（act）、观察（observe）这个闭环。无论你把它写成 for 循环还是 while 循环，智能体的核心都是这样一个持续运转的循环。而当我们希望智能体尽可能自主运行时，一个绕不开的问题浮现出来：人类的响应速度太慢了。

模型可以在 200 毫秒内返回结果，但人类审批一个决策可能需要几分钟、几天甚至几周。如果你把「等待人类输入」直接写成一个普通的函数调用，它会变成一个阻塞调用（blocking call）。更糟糕的是，一旦服务宕机，这个等待状态就会丢失，整个系统可能彻底不知道自己之前进行到了哪一步。

冰淇淋配送 Demo：多智能体协同的真实场景

演讲者用一个「Ziggy 冰淇淋配送」的演示来说明问题。这个场景中有多个智能体在协同工作：

• Fleet Agent（车队智能体）：使用 Google Maps 等工具研究司机和路线
• Customer Agent（客户智能体）：使用 Google Search 等工具研究订单信息
• Dispatch Agent（调度智能体）：接收前两者的输入并做出决策

整套 Demo 把 Google 的 ADK（Agent Development Kit，用于编排多智能体的方案）与 Temporal 做了集成。ADK 负责协调智能体之间的活动，而 Temporal 则被嵌入其中，负责跟踪和管理系统状态，并提供一个可视化 UI 来展示整个工作流的事件历史（event history）。

关键的演示点在于：当一位客户临时修改订单时，系统会暂停正在等待该更新的「司机 A」，但系统的其余部分照常运转——新订单继续进来、继续被履约。只有涉及这笔变更的那一个具体环节在等待另一位人类的审批。当审批者点击「approve」后，这笔更新被处理，订单继续前往下一个目的地（Oracle Park）完成配送。

这就是 Temporal 所说的「durable execution（持久化执行）」。

Temporal 的三个核心原语

Temporal 的定位是帮你标准化分布式系统中的失败处理与状态管理，尤其是带有智能体的系统。它既是软件也是服务：软件本身提供一系列开箱即用的原语（primitives），可直接应用到你的代码中，支持 Python、TypeScript、Rust 等多种语言。

它最常被提及的三个核心原语是：

Worker（工作者）

真正运行代码的执行单元。

Workflow（工作流）

负责跟踪系统中的步骤。由于智能体本身就是一个循环，一个 ADK 框架或一个智能体就可以运行在一个 workflow 内部。

Activity（活动）

所有与外部交互的操作。在循环中，任何模型调用或工具调用都应被设置为 activity。

换句话说，你用这些原语来组织代码结构，从而让系统变得「有状态（stateful）」。Temporal 本身是免费开源的（可在 GitHub 自托管），只有当你让它托管你的状态服务时才需要付费。

「持久化执行（durable execution）」是 Temporal 的核心设计哲学，理解它有助于把握这三个原语的协作方式。传统分布式系统中，程序状态存在于内存，一旦进程崩溃，正在执行的任务就会丢失，恢复通常依赖手动重试或外部消息队列。Temporal 的做法是将 Workflow 的执行历史持久化为一条不可变的事件日志（event log）。每当 Workflow 从崩溃中恢复，运行时并不重新执行所有副作用，而是「重放（replay）」这条日志——跳过已完成的 Activity，直接恢复到中断点，就像把磁带快进到断点处。这意味着开发者可以用近乎普通顺序代码的方式编写具有持久状态的长时任务，而无需自己维护断点续传、幂等性补偿等复杂逻辑。Activity 被设计为系统与外界交互的唯一边界，正是为了让 Temporal 知道哪些操作有副作用、哪些结果需要被记录进日志。

Wait Condition 与 Signal：驯服「异步的人类」

回到 human-in-the-loop 这个核心命题。既然人类不是工具，但对智能体来说又像一个工具，那该如何优雅地处理这种慢速、可能长时间阻塞的交互？

答案是两个关键原语的组合：wait condition（等待条件） 和 signal（信号）。

做法是：隔离出一个事件，为它施加一个 wait condition，并把这个状态存储在 workflow 的持久化层中。这样一来：

• 系统不会被一个对人类的调用阻塞，其余部分继续运行
• 如果系统崩溃，重启后它能从上次中断的地方恢复，知道自己进行到了哪一步
• 你可以在任意时刻发送一个 signal 让流程继续
• 它不占用线程，能够在崩溃中存活
• 内置超时（timeout）等机制——如果等待人类响应，可以设定只等待一定时长

演讲者强调，哪怕有数百万个 workflow 处于「停泊」状态等待输入，系统依然能持续运转。

在第二个演示中，调度智能体判断某笔特殊订单需要人类介入，于是进入 pause 状态等待审批。此时演讲者故意把 worker 服务「kill 掉」下线，并在离线状态下点了 approve。由于这个事件的状态存储在独立的数据存储中，审批动作被排队保存。当服务重新上线后，事件日志（event log）会被「replay（重放）」而非「redo（重做）」——它重放到上次中断的位置，识别出人类已经批准，于是订单被分配并完成配送。这正是持久化带来的灾难恢复能力。

「signal」的概念借鉴自操作系统和 actor 模型中的消息传递机制。在 Temporal 中，一个 Workflow 实例在运行时拥有唯一 ID，外部系统可以通过这个 ID 向它发送 signal——本质上是一条带有数据载荷的异步消息。Workflow 内部用 wait condition 声明「当某个条件为真时才继续」，而 signal handler 负责更新该条件。这套机制与事件驱动架构（event-driven architecture）的思想一脉相承，但关键差异在于状态的归属：事件驱动系统通常把状态外置到数据库或消息队列，开发者要自己保证幂等和顺序；而 Temporal 把等待状态内化到 Workflow 本身，持久化由框架托管，开发者只需声明「等什么」和「收到后做什么」。这也是为什么数百万个处于 pause 状态的 Workflow 不会占用线程——它们只是日志中的一条悬挂记录，被唤醒时才会调度执行。

什么时候才该让人类进入循环？

这是演讲者认为最难回答的问题。他给出的判断标准朴素而实用：

核心是评估「出错的代价」。当出错的代价很高——尤其是在安全相关的场景——就更应该引入人工审批。这是一个 case-by-case 的权衡。

但天平的另一端是「告警疲劳（alert fatigue）」。很多人都有体会：当系统不停地问你「要不要同意」时，你会开始机械地一路 yes、yes、yes。模型是概率性的、难以做到完全可靠，所以我们一方面要靠人类兜底，另一方面又不能让人类被淹没在无意义的确认请求里。行业努力让模型变得更可信，正是为了缓解这种疲劳。

无论是人类主动发起还是计算机发起，无论你是把流程完全下线还是重新上线，底层机制始终是那两个原语：用 wait condition 暂停 workflow，用 signal 让它继续并带回结果。而这套机制可以跨多个框架复用。

「告警疲劳（alert fatigue）」最早作为医学概念被提出，描述重症监护室中护士因监护设备频繁误报而对真实警报产生钝感的现象，后被广泛引入信息安全和 DevOps 领域。在 AI 智能体的语境下，它指的是当系统过度请求人类确认时，审批者会失去辨别力，将高风险操作与低风险操作同等对待地一路放行，实质上消解了人工审批本应提供的安全保障。这一问题在安全运营（SOC）场景已有深入研究，研究表明过高的误报率不仅不能降低风险，反而会系统性地降低人类对真正威胁的响应质量。因此，human-in-the-loop 的设计不只是技术问题，更是一个人因工程（human factors engineering）问题：需要通过合理的触发阈值、分级审批和上下文展示，让人类的注意力真正花在值得花的地方。

写在最后

这场演讲虽然带有明显的产品宣传色彩，但它点出的工程问题是真实而普遍的：当智能体系统越来越复杂、越来越依赖人机协同时，如何保证状态不丢失、系统不掉线，会成为把 agent 推向生产环境的关键一环。Temporal 给出的答案——把人类当作一个可以等待、可被信号唤醒的异步 API——提供了一种清晰的架构思路，值得构建 agentic 系统的开发者参考。