设想一笔交期变更。销售在 CRM 里提交申请，Agent 查了库存和排产情况，主管批准把订单 

 的交期提前到周五。下午三点，ERP 提交成功。就在它准备返回回执时，执行这个步骤的 Worker 宕机了。

销售刷新页面，看到“处理中”。这时按下“重试”，会发生什么？可能只是取回原来的回执，也可能让 ERP 再跑一遍改期逻辑，给计划员多发一条通知。如果直接把流程标成失败，销售又会以为订单仍按原日期交付。

Temporal 是一个开源的持久化执行平台。它能让换了一台机器的程序接着办这笔业务。真正影响设计的是两件事：程序已经执行到哪里，ERP 究竟做了什么。 第一个问题可以靠执行历史回答，第二个要看 ERP 留下了什么证据。

一个正在等审批的 Agent，究竟运行在哪里？

把这次交期申请建成一个 Workflow。它写明业务顺序和分支，例如，交期可行才生成方案，批准后才提交 ERP，ERP 确认后才更新 CRM。在 Temporal 里，Activity 是一次可以单独调度并记录结果的工作。把查订单、调用模型、写 ERP、更新 CRM 各写成一个 Activity。

FastAPI 收到申请后，通过 Temporal Client 启动 Workflow。常驻的业务 Worker 从任务队列拉取工作。它执行一小段 Workflow 代码，走到“查订单”时向 Temporal 发出调度 Activity 的命令。具备 ERP 读权限的 Worker 执行实际查询。它把结果交给 Temporal 后，下一个 Workflow Task 才能利用这个结果推进流程。一个 Worker 可以处理多笔申请，一笔申请也可以由不同 Worker 接力。

等审批的几个小时里，这笔申请在逻辑上仍然运行，执行槽已经可以服务其他订单。Worker 可能暂时缓存它的状态，以便下次更快恢复。即使集群滚动升级、缓存全部丢失，主管次日发来的批准消息仍能让同一笔申请继续。为每个等待审批的 Agent 保留一个专属 Pod，会把原本只需保存历史的等待，变成实实在在的计算成本。

第一种是重放。 假设生成方案的 Activity 已完成，结果已经写入 Event History。新 Worker 接手时，SDK 重新运行 Workflow 代码。走到“生成方案”这一步，SDK 用历史里保存的结果满足这次调用。于是程序重新得到主管当时看到的 V3 方案，再沿原来的分支向前走。Worker 在两次执行之间可以更换，模型也不会因为这次重放被重新调用。

这要求 Workflow 对同一段历史产生相容的命令序列。如果在 Workflow 的 

 里直接问模型“现在该不该改期”，第二次回答可能变了。把模型调用放进 Activity，把结构化结论和方案版本作为返回值。若模型供应商已生成并计费，而 Activity 结果还没记入历史，后续尝试仍可能再次调用模型。昂贵推理要据此决定是否保存供应商请求号、结果引用，以及愿意承担多少次重复调用。

第二种是可靠地派发下一步。 如果自己写调度器，最直观的实现是先把数据库中的步骤改为“待写 ERP”，然后往队列发任务。进程若在两次写入之间退出，数据库会永远显示“待写”，却没有 Worker 能领到它。调换这两行的顺序，又会出现 Worker 已经领走任务、数据库状态还没提交的窗口。

Temporal 的服务端代码说明比架构图更有意思。History Service 用数据库事务一起提交 Mutable State（当前执行状态）和待处理的内部任务，并用状态中记录的历史位置确定哪些历史事件有效。后台随后根据 Transfer Task 把工作送到管理任务队列的 Matching Service。即使在派发前宕机，恢复后的服务仍能找回待办事项。这是事务性发件箱（Transactional Outbox）的一种应用。它解决的是 Temporal 服务端内部的交接；ERP 的那次数据库提交仍由 ERP 管理。

在发出请求前，为“把订单第 10 行的交期改到周五”分配一个稳定的 

。在平台的 PostgreSQL 动作台账中，它绑定租户、ERP 实例、订单行、预期版本、获批参数摘要和审批单。同一动作的网络重试沿用这个 ID；主管后来批准了另一份方案，才产生新的动作。

审批服务也有一个写入窗口。主管点了“批准”，PostgreSQL 已提交，服务却在向 Temporal 发 Signal 前退出。把审批决定和“待通知 Workflow”记录放在同一个业务库事务里。后台即使补发两次，Workflow 也能用同一个审批决定 ID 去重，再核对方案摘要和有效期。这样，界面上已经批准的单子有路可走，重复投递也不会派生第二个改单意图。

下表给出了为连接器实现的恢复规则。这里假设 ERP 能接受外部操作号，并能按这个号查回执。客户现场是否具备这两项能力，需要在接口联调时验证。

有些老 ERP 只能查询订单当前值。看到交期也是周五，就能认定本次动作成功吗？计划员完全可能同时做了同样的修改。如果这次操作还会通知供应商，仅核对日期也无法判断通知发过几次。要求可关联到本次动作的变更流水、回执或审计记录。查证能力不足的连接器，遇到结果未知就转人工，并暂缓同一订单行上相互冲突的写入。

这里还要决定谁有权重发。实现会让 Activity 每次尝试都先经过同一份台账和连接器规则，HTTP 客户端也按该动作的能力配置重试。否则，即使业务代码写了“先查证”，底层客户端也可能已经替它重发过一次。

两个公开案例，给出了不同的拆分理由

Grid Dynamics 的研究 Agent 遇到的是暂停与恢复。 他们为一家制造企业做深度研究，先查内部资料，必要时补充外部来源。团队在 Temporal 官方博客复盘，早期实现需要在步骤间读写 Redis，还要自行处理人工介入后的恢复。迁移时，一个实际成本是原先多个节点共用内存里的客户端和复杂对象，拆成 Activity 后，必须重新定义可序列化的输入输出。逐次初始化客户端又太慢，他们改用连接池和延迟初始化。对设计 Agent Skill 最有启发的是这条边界：连接池适合活在 Worker 进程里，决定能否接着跑的业务状态则要跨进程传递。

这篇案例里还有一处值得核对。它在后备分析 Activity 的示例中，把“省略重试策略”注释成只执行一次。官方 Retry Policy 文档给出的普通 Activity 默认行为是自动重试。若只允许一次尝试，Python 应显式设置 

。对只读分析，两者的差别可能体现为多一次模型费用；对写接口，则关系到是否会重复提交。即使只尝试一次，丢失回执后的查证仍然要做。

销售软件公司 Nooks 遇到的是两种节奏完全不同的工作。 一通电话结束后，要尽快完成校验、转写、补充信息和外部写入，他们将步骤拆成可独立重试的 Activity。另一条链路从 Salesforce 或 HubSpot 同步数据，既有历史回填，又有定期增量。客户案例称峰值数据集达 4,000 万条，因此同步按批分给子 Workflow。增量调度选择 

，让重叠触发的同步依次执行。

如果接入 CRM，是否沿用这个调度策略，取决于接口契约。若每轮对应不能遗漏的变更窗口，就需要保存游标，按顺序补齐，并监控最老窗口落后了多久。若每轮只是从上一次成功游标追到当前最新位置，十次积压触发可能只需要一次追赶。两种业务都叫“每五分钟同步”，对积压的正确处理完全不同。

首先，把编排、耗 CPU 的求解和受下游限流的写入分到不同任务队列。扩容前先看 Schedule-to-Start，即任务从排队到被 Worker 接走的时间，再对照执行槽、CPU 和下游返回码。队列变长且求解 Worker 的 CPU 已满，增加计算副本有意义；ERP 正在连续返回限流，如果再加写入副本，共享同一配额的客户只会互相挤占。自建时还要分别演练 Worker 全部重启和 Temporal 持久化数据库故障切换，这两类故障依赖不同的恢复机制。

其次，给每种 Activity 定义时间预算。例如，ERP 查询单次最多 8 秒，从入队到最终结束最多 30 秒，可分别用 

 表达。长时计算可以通过 Heartbeat 报告进度；若要从第 20 批接着算，就先持久化该批结果，再报告批号，并让重复处理同一批也安全。对于很大的文件或模型输出，Workflow 传对象存储中的不可变版本引用。长会话若持续积累历史，可通过 Continue-As-New 显式传递必要状态，保留 Workflow ID，并开启具有新 Run ID 的历史。

最后，在预生产环境做三个会改变上线决定的实验。下面是验收设计，结果需要在目标系统联调时取得。

版本测试尤其容易被漏掉。一个等审批三天的 Workflow，实际经历的是“昨天的输入、今天的代码”。Temporal Python SDK 提供历史重放测试和 Patching；测试样本应该覆盖已经进入审批、已经提交外部写入和正在查证的流程。只拿一条新请求跑通最新版，恰好绕开了最需要验证的部分。

如果只是一次短查询，失败后用户重查的成本很低，继续用普通请求处理。对于跨天审批、昂贵推理和多系统写入，引入 Temporal，因为这些流程的恢复成本已经落在销售、计划员和值班工程师身上。选型时，最想请 ERP 团队现场演示的，仍是开头那一幕：断开返回连接，只给你平台的动作号，你能否告诉我刚才那笔订单究竟改成功了没有？ 这个答案，决定了系统可以自动走多远。

设想一笔交期变更。销售在 CRM 里提交申请，Agent 查了库存和排产情况，主管批准把订单 SO-2088 的交期提前到周五。下午三点，ERP 提交成功。就在它准备返回回执时，执行这个步骤的 Worker 宕机了。

ERP 已经改了订单，Agent 为什么还在重试？读懂 Temporal 的持久化执行

架构设计

后端

数据库

交期变更场景下，Temporal持久化执行平台通过Workflow编排、事件历史重放和事务性发件箱，实现跨系统任务的可靠恢复。Activity机制配合稳定action_id和幂等设计，确保ERP改单、CRM同步等步骤在Worker宕机后仍能正确推进，避免重复提交或状态不一致。

对象存储

PostgreSQL

Python

Redis

Agent

腾讯云双十一大促

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

ERP 已经改了订单，Agent 为什么还在重试？读懂 Temporal 的持久化执行

ERP 已经改了订单，Agent 为什么还在重试？读懂 Temporal 的持久化执行

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐