30 秒看懂
Temporal 开发者布道师 Shy Ruparel 介绍一项针对 554 名 AI 智能体使用者的工程师及负责人调查，随后用模拟付款流程演示持久执行。演讲区分了信任、生产环境采用和可观测性，与故障发生后实际恢复状态的能力。
- 1使用不等于部署受调查群体中，80.8% 的人每天使用智能体，49.1% 的人报告在生产环境或核心交付中使用。
- 2信任与故障并存大多数受访者至少在一定程度上信任输出，同时 41.1% 的人表示每天或更频繁地遇到问题。
- 3状态和调试阻碍团队跨服务追踪状态和定位问题是受访者提到最多的生产力障碍。
- 4从记录的历史中恢复Temporal 示例记录进度和审批信号，让重新启动的工作进程能够在已完成工作的基础上继续。
要点建议
- 每天使用智能体与在生产环境部署智能体是不同的采用阶段。
- 对智能体输出的信任与频繁报告的问题可以同时存在。
- 跨服务状态追踪和调试是受访群体提到的主要障碍。
- 记录的工作流历史可以支持恢复，避免重复已完成的活动；中途进行的工作可能需要重试。
- 在演示中，是否批准付款仍由人决定。
按章节阅读整理后的全文
长时间运行的工作流中的智能体
Ruparel 介绍金融工作流，以及 Temporal 对已经使用智能体的工程师开展的调查。
我是 Temporal 的开发者布道师 Shy Ruparel。智能体越来越多地进入业务运营，但决定使用它们，与在生产环境运行可靠系统并不是一回事。我想讨论调查中发现的四个差距，并演示一种恢复方式。
金融业务依赖长期运行的工作流，而不是孤立的模型调用。贷款发放、身份和反洗钱检查、欺诈审核及付款会跨越多个系统、数天和多个人员。把智能体放进这些流程，也意味着它要面对所有依赖环节带来的后果。
Temporal 的 2026 年开发现状调查由 Qualtrics 执行，包含 554 名已经使用 AI 智能体的工程师和工程负责人。这是针对特定受访群体的调查，并非所有工程师的普查。幻灯片将本次调查结果与其他报告的数据区分开来。
使用、信任与生产环境
调查比较了日常使用与部署情况，并同时报告了信任程度和频繁出现的问题。
第一个差距是使用与生产部署。在受访群体中，每天使用智能体的比例从上一轮调查的 47.3% 升至本轮的 80.8%。但 49.1% 的人表示智能体已在生产环境运行，或成为交付工作的核心。每天使用助手与在生产环境运营智能体，是不同程度的投入。
第二个差距是信任与实际体验。85.5% 的受访者至少在一定程度上信任智能体输出，其中 24.7% 表示完全信任。我本人比这个结果更谨慎，而报告中的故障频率让这种对比尤其值得关注。
在同一调查中，41.1% 的人表示每天或更频繁地遇到智能体问题，其中 16.4% 表示持续或每小时遇到问题。信任与频繁问题可以并存；单凭这些百分比，我们无法判断哪些受访者同时属于两组。
自认为成功的团队报告持续或频繁问题的可能性高出 1.7 倍。我们推测他们可能检查得更仔细，因而发现了更多问题，但这一解释还需要进一步研究。我得出的教训是，应该为故障做准备，而不是以为经验能够消除故障。
安全也是一个限制因素：约 40% 的受访团队将其列为自主智能体的阻碍。这个话题值得单独讨论。在这里，我重点关注流程失败后系统如何恢复。
企业部署与恢复差距
Ruparel 讨论投产时间、状态管理，以及发现故障与从故障中恢复的区别。
第三个差距是从原型到可投产代码。调查中，51.3% 的受访者表示这一过程只需数小时或更短。但在员工超过 5000 人的组织中，约五分之一的人报告需要数月，而其他组织约为二十分之一。
我猜测，大型受监管组织需要审批、审计记录和可靠性保障，这解释了部分时间差异，但调查并没有证明原因。银行或支付公司必须确保流程可以审计，交易不会丢失。
第四个差距是发现故障与从故障中恢复。受访者将跨服务追踪状态列为主要生产力障碍，比例为 35.7%；定位和调试问题为 30.9%。另有 22.2% 的人表示，崩溃和重启导致进度丢失，需要重新工作。
去年的另一项调查询问了脆弱的状态管理，但问题不同，所以我不会将这些结果称为趋势线。我认为一致的主题是：当智能体进入更长、后果更重大的工作流时，状态管理变得更加重要。
日志和追踪可以显示智能体失败，但恢复仍可能依赖某个人阅读追踪并手动修复状态。只有 13% 的受访者表示，非常有信心大规模观察和调试 AI 工作流。看见故障不等于能够安全恢复。
模拟付款与持久执行
付款演示使用本地模型和人工审批。Ruparel 解释事件历史、工作进程崩溃和重放。
为了说明这一点，我使用一笔 2500 美元的模拟付款、真实的 Temporal 工作流和本地语言模型。这个九阶段示例预留资金，让智能体调查可疑交易并准备简报，然后等待人工批准或拒绝。
我故意停止工作进程，模拟崩溃。如果没有保存工作流状态，外部银行可能仍然预留了资金，而应用已经丢失继续处理所需的信息。团队就需要编写恢复、重试和对账逻辑来处理这种不一致。
Temporal 的持久执行方案把工作流进度记录在事件历史中。工作流负责确定性的决策；模型调用和银行调用等非确定性或有副作用的工作作为活动执行。人工审批作为信号进入系统，即使没有工作进程运行也可以被记录。
工作进程恢复后，可以重放记录的历史并从已完成的工作继续。进程死亡时仍在进行的调用可能需要重试；已完成的活动则不必重复。这一区别关系到外部操作的影响，也关系到重新调用模型的成本。
在现场示例中，我输入模拟付款信息、触发调查，并在批准前停止工作进程。审批信号在进程停止时仍被记录。现场重启比预期更慢，因此我切换到录制好的演示，展示预期的继续过程。
录制的事件历史显示了已完成的 AI 活动、审批信号和后续银行提交步骤。我解释说，新的工作进程可以接手工作流，不必重复已经完成的模型工作。这个例子展示的是特定工作流，并不保证所有集成都自动安全。
工作流解决了哪些问题
演讲者将示例与状态、重试、成本和调试联系起来，并阐述可恢复工作流的价值。
我把演示与调查中提到的问题联系起来：状态、调试、成本、重试、人工审批、长期工作和崩溃恢复。在示例里，重放恢复工作流变量，配置的重试策略处理符合条件的失败。活动重试时，外部操作仍需要适当处理。
智能体的职责受到限制：它提供建议，工作流掌管交易，人负责审批。在演示设计中，如果模型无法生成简报，付款工作流可以继续，并提供供人工审核的备用信息。这个示例将 AI 组件与资金转移流程分开。
同一份历史可以同时支持调试和重放，缩小工程师检查的记录与用于恢复工作的状态之间的差距。我还提到 OpenAI Codex 和 Replit 的智能体在生产环境使用 Temporal；这是演讲中列举的例子。
不合格的模型响应可以作为活动失败处理，并依据策略重试。我的结论是，智能体可靠性既需要可观测性，也需要保存进度和恢复工作的能力。调查详情可以在 Temporal 的开发现状报告中查看。
同频道的其他文章
14:50EN → 简体中文
AI Engineer· 2026年10月29日Cole Gannaway：代码审查、跨仓库风险与 AI 软件工厂Cole Gannaway · Qodo一行重命名代码可能通过本地检查，却影响远端客户端。Qodo 的 Cole Gannaway 解释如何借助审查上下文、共享规则和独立智能体发现这些风险。
11:47EN → 简体中文AI Engineer· 2026年10月29日Revolut 的 David Abitbol：大规模自托管 AI 编程模型David Abitbol · RevolutAbitbol 分享工程交付趋势、GPU 服务成本和延迟调优经验，并介绍受监管银行运行这些工具时采用的控制措施。
21:47EN → 简体中文AI Engineer· 2026年10月28日Patrick Smyth：AI 时代的开源供应链安全Patrick Smyth · ChainguardChainguard 的 Patrick Smyth 讨论漏洞利用加速、依赖中的恶意软件、零日漏洞，以及开发者工作流不断扩大的攻击面。
14:09EN → 简体中文AI Engineer· 2026年10月28日Taylor Luttrell-Williams：用 SonarQube Hunter Agent 发现逻辑漏洞Taylor Luttrell-Williams · SonarSonar 的 Taylor Luttrell-Williams 介绍安全智能体如何梳理代码库、调查逻辑漏洞，并将验证过的发现与常规扫描结果一起呈现。
16:29EN → 简体中文AI Engineer· 2026年10月28日Chris Vela：用 Runpod BenchPod 对 vLLM 配置做基准测试Chris Vela · RunpodRunpod 的 Chris Vela 演示如何通过仪表盘比较大语言模型服务配置，依据具体工作负载的数据选择性能设置。
18:52EN → 简体中文AI Engineer· 2026年10月28日Manish Kapur 与 Addy Osmani：如何验证 AI 软件工厂Manish Kapur, Addy Osmani · SonarSonar 的 Manish Kapur 与 Anthropic 的 Addy Osmani 讨论编码智能体加快软件变更后，如何进行代码审查、收集证据并实施分层检查。