9月14日，Temporal宣布完成5.5亿美元E轮融资，估值达到125.5亿美元。GeekWire援引公司披露称，其年度化收入运行率已超过2.5亿美元，同比增长超过200%，付费客户超过4300家，客户名单包括OpenAI、NVIDIA、Netflix和JPMorgan Chase。上述经营数据来自公司披露，仍应等待未来公开财务信息验证，但资本市场关注的方向已经很明确：Agent越进入长周期、跨系统的业务流程，可靠执行就越会成为独立基础设施市场。
Temporal提供的核心能力是durable execution——持久执行。一个任务运行几小时、几天甚至数周，中间遇到API失败、服务器重启、网络中断、限流、人工审批或业务系统维护后，系统仍需从正确的位置继续，避免从头执行、重复扣款或彻底丢失状态。
本文的核心判断是：企业Agent的竞争单位将从“单次调用成功率”转向“端到端任务最终完成率”，而持久执行会像数据库事务、消息队列和作业调度一样，成为AI应用的标准底座。
一、为什么长周期Agent会暴露传统脚本的极限
一次问答通常在几十秒内结束，失败后重新生成的成本有限。企业任务却由许多相互依赖的步骤组成。采购Agent要收集需求、向供应商询价、比较结果、等待预算审批、创建订单并同步财务系统；编程Agent要修改多个仓库、触发测试、处理失败、取得发布批准再部署；客服Agent可能先受理工单，数天后等待物流结果返回，再决定退款或补发。任务的业务价值只有在整条链路结束时才真正实现。
这些流程中的每一步都可能失败，而且失败含义不同。读取接口超时通常可以重试，创建订单超时却可能是“订单已经创建，但响应在返回途中丢失”；人工审批期间应暂停执行，持续占用计算资源没有意义；服务器更新后，系统还要知道此前完成了哪些动作、留下了哪些外部副作用。若开发团队用普通脚本、定时任务和一串回调临时拼接，状态保存、异常分支、重试和补偿逻辑很快会比业务逻辑本身更复杂。
Agent进一步放大了这个问题。传统工作流的大部分路径可以预先枚举，Agent却会根据工具返回、模型判断和外部事件动态调整计划。模型越自主，潜在路径越多；调用系统越多，故障组合也越多。于是，“模型这一步答对了”与“业务最终办成了”之间出现巨大距离。企业承担的风险包括重复付款、错发通知、错误部署、越权操作，以及任务在无人察觉的情况下永久停住；少生成一段文本反倒是较轻的后果。
因此，长周期Agent不能只被看作一连串模型调用。它更像一个持续存在的业务对象：有身份、有状态、有预算、有等待条件，也有明确的完成、暂停和失败边界。传统脚本擅长执行确定性命令，却缺少对这种长期生命周期的系统表达。
二、持久执行的价值，是把现实世界的不确定性纳入运行时
Temporal所代表的运行时层，会围绕工作流状态组织执行，把等待、恢复、重试和超时从应用代码里的零散补丁，提升为基础能力。模型负责判断下一步做什么，工具与连接器负责访问CRM、ERP、代码仓库、数据库和外部服务，持久执行层则负责记住已经发生了什么，以及中断后应该从哪里继续。
这种分层首先改变了故障的含义。进程故障只影响当前执行节点，已经持久化的任务仍可在节点重启后恢复。其次，等待成为一等能力：流程可以挂起，直至收到人工审批、物流回执、测试结果或维护窗口开放等事件，轮询脚本因此可以减少。再次，重试可以携带业务语义，系统能够区分可安全重复的查询与可能制造重复副作用的写操作。最后，长流程因此具备可观测性，管理者可以看到任务停在哪一步、重试了几次、正在等待谁、是否超出预算，以及何时需要人工介入。
这里需要区分“保存对话”与“保存执行状态”。对话历史只能说明模型说过什么，不能可靠证明订单是否建立、审批是否通过、测试是否完成。生产系统需要把订单号、审批结论、工具输出、错误类型和业务证据结构化保存。模型上下文可以被重新组织或压缩，业务状态却必须有稳定、可审计的记录。否则，即使恢复了对话，也不等于恢复了业务流程。
持久执行不会自动消灭异常，它为异常提供明确的处理路径。成熟系统需要为每项活动定义超时、重试范围、幂等键和补偿动作；对模型决策，还应保留所用模型版本、关键输入和工具结果，使团队能够解释任务为什么走到当前状态。恢复操作据此基于已发生事实继续推进，避免简单地“再跑一遍”。
三、Agent基础设施正在从“模型中心”转向分层协作
过去AI应用架构常被简化为“模型+向量数据库+业务接口”。当Agent真正进入生产，至少会形成四层。
最上层是模型和规划，负责理解目标、分解任务和选择动作。第二层是工具与连接器，负责访问企业系统和外部服务。第三层是持久执行运行时，负责状态、重试、等待、恢复和任务编排。第四层是治理与安全，负责身份权限、人工审批、预算、审计与紧急停止。四层缺一不可：只有模型，没有执行层，任务容易中断；只有执行层，没有治理，可靠地执行错误动作反而更加危险。
9月14日Copado发布Agentia Headless，提供了可供对照的产业信号。它把AI Agent带入Salesforce开发者的IDE和终端，让Agent能够操作流水线、触发测试、提交和推广变更、执行部署，同时继续沿用企业已有的审批、质量门禁和发布控制。企业部署这类Agent时，需要把它嵌入现有流程，使每项操作继续接受权限和门禁约束；绕过既有系统的“万能Agent”难以通过生产治理要求。
Temporal的资本热度说明，第三层正在被市场重新定价。可靠工作流早已存在，Agent则同步增加了长流程数量、路径不确定性和外部动作数量，“能否持续运行”因而成为产品成败的中心指标。模型可能随成本、能力和合规要求被替换，承载核心业务状态的执行层迁移难度更高，因为它连接任务历史、异常策略、企业系统和审计证据。持久执行平台一旦进入关键流程，可能形成较强的工程黏性。
不过，融资规模和客户名单不能证明某一种技术方案适合所有企业。Temporal是这一市场的重要代表，各企业仍需比较部署方式、语言生态、运维复杂度、可观测性、数据合规和团队能力，并判断现有工作流引擎、消息系统与作业平台能否满足当前需求。选型应先确认能力边界，再评估基础设施品牌。
四、可靠性绝不只是“自动重试”
Agent团队最容易犯的错误，是把可靠性理解成失败后多试几次。对于无副作用的查询，重试通常安全；对于支付、下单、发消息、删除资源和部署变更，盲目重试可能把一次技术故障扩大成多次业务事故。一个请求超时，并不能证明外部系统没有执行它。
因此，持久执行必须与幂等设计结合。每次外部写操作都应携带唯一业务键，让系统能够判断请求是首次执行还是重复到达。无法天然幂等的动作，需要定义补偿路径，例如取消订单、回滚部署，或生成待人工处理事项。补偿也不能被想象成完全对称的“撤销键”：一封邮件发出后无法真正收回，一次外部通知可能已经影响客户判断，所以高风险步骤仍应设置审批和明确权限边界。
模型调用同样需要预算和终止条件。如果Agent在错误状态下不断重新规划，持久执行可能只是让错误更持久。系统需要限制调用次数、累计成本和工具权限；当同类错误重复出现、关键证据冲突或外部环境改变时，应安全暂停并转交人工，防止无限循环。可靠性要求系统在无法安全继续时，以可解释、可接管的方式停止。
恢复还涉及代码版本变化。一个运行数周的工作流，在恢复时应用代码可能已经升级。如果新逻辑直接解释旧状态，行为可能发生变化。企业因此需要版本化工作流定义，为长期任务建立兼容策略，并明确旧任务继续走旧逻辑，还是经过受控迁移进入新逻辑。技术难点集中在状态、代码和外部世界的一致性；单纯把状态写入数据库解决不了这个问题。
五、企业应重做Agent的指标、治理和责任边界
如果仍用模型回答准确率或单次工具成功率评估长周期Agent，团队会得到误导性的乐观结果。更重要的指标是端到端任务最终完成率，并配套观察恢复次数、人工介入率、重复动作率、平均完成时间、单任务成本和异常停留时间。只有把业务结果与运行过程放在一起，才能判断Agent究竟提升了生产率，还是把失败隐藏到了更长的链路里。
治理需要覆盖整个执行过程，上线前的一次审批无法处理运行期间出现的变化。Copado所强调的测试、审批和质量门禁表明，Agent进入企业流水线需要“受治理地行动”。身份与权限应跟随具体任务和步骤，不能因为Agent代表某个团队，就默认拥有完整系统权限。高影响动作要有清晰的批准点，所有工具调用要能够追溯，紧急停止之后还要知道哪些动作已经完成、哪些仍待处理。
责任边界同样需要提前设计。模型负责提出计划，不意味着模型可以自行定义业务目标；运行时负责可靠推进，也不意味着它能判断所有动作是否合规；人工审批存在，也不意味着审批者应面对缺少上下文的“同意/拒绝”按钮。生产级系统必须把必要证据、当前状态、影响范围和建议动作同时交给审批者，降低人在长流程中接管时的信息损失。
六、企业行动建议：先用一个真实长流程验证
- 选择跨时间、跨系统并包含人工审批的试点。 采购、售后、合规审查和软件发布比一次性问答更能检验持久执行价值。试点范围不必大，但必须包含真实等待、真实故障和理想路径之外的异常分支。
- 绘制状态与副作用清单。 明确每一步读取什么、写入什么、由谁授权，标出付款、下单、发信、删除和部署等高影响动作，并为它们设计幂等键、审批点和补偿机制。
- 把模型状态与业务状态分开。 对话文本不能作为唯一状态源；订单号、审批结果、工具输出和证据应结构化保存，并能够在模型替换或上下文压缩后继续使用。
- 建立面向最终结果的指标。 除完成率外，同时记录恢复次数、人工介入率、重复动作率、平均完成时间、异常停留时间和单任务成本，避免只优化局部调用成功率。
- 设计人工接管与安全暂停。 当模型反复失败、预算超限、证据冲突或外部环境变化时，流程应停止自动推进，把已完成动作、当前状态和下一步选择完整交给人。
- 用故障演练验证架构。 主动测试API超时、网络中断、节点重启、审批延迟和重复回调，确认任务能否从正确位置恢复，以及外部写操作是否会被重复执行。常规演示无法覆盖这些风险。
- 先确认能力缺口，再决定平台选型。 企业应评估现有消息队列、工作流引擎和调度系统，找出状态持久化、长等待、版本兼容、审计或人工接管方面的实际缺口，再比较新平台的收益与迁移成本。
Temporal融资反映了AI应用评价标准的变化。企业要求Agent在复杂现实中持续推进任务，并在失败、等待、变更和人工干预之后仍能交付正确结果，一次漂亮演示无法证明这种能力。模型决定Agent能想到什么，工具决定它能接触什么，治理决定它被允许做什么，持久执行则决定这套系统能否把事情安全地做完。
Agent进入采购、客服、研发和发布流程后，企业需要可靠管理任务生命周期，长上下文和更多工具只能覆盖其中一部分。持久执行的市场关注度低于模型能力，但它可能成为企业Agent难以绕开的基础设施层，并构成生产系统与演示系统之间的关键边界。
参考资料
- GeekWire｜Temporal raises $550M, hits $12.55B valuation as agentic AI wave fuels massive growth｜2026-09-14｜核验融资、估值、客户及公司披露的经营数据。
https://www.geekwire.com/2026/temporal-raises-550m-hits-12-55b-valuation-as-agentic-ai-wave-fuels-massive-growth/ - Temporal｜Temporal平台资料｜2026-09访问｜用于理解durable execution与长周期工作流的产品定位。
https://temporal.io/ - Copado / PR Newswire｜Copado Brings Governed AgentOps Directly to Salesforce Developers with Agentia Headless｜2026-09-14｜背景资料，用于观察Agent进入审批、测试与发布流水线的趋势。
https://www.prnewswire.com/news-releases/copado-brings-governed-agentops-directly-to-salesforce-developers-with-agentia-headless-302877066.html