FIELD NOTES 首页 / AI Engineer
AI Engineer播出 2026.10.2921:3213 章约 13 分钟读完整理于 2026.11.01

我们信任那些每天都会出故障的 AI 智能体|Shy Ruparel,Temporal

Temporal 开发者倡导 Shy Ruparel 以一项针对 554 位工程师和工程负责人的调查为线索,指出 AI 智能体从日常使用走向生产部署仍有四个缺口:使用与部署、信任与可靠性、原型与企业落地、可观测与可恢复。演讲通过一个 2,500 美元付款流程演示持久执行:即使 worker 崩溃,工作流状态和进度仍保留,审批信号可在 worker 停机时记录,恢复后从上次成功处继续。LLM 活动只运行一次,资金和状态由确定性的工作流控制,AI 的职责受到限制。

01 0:01 77 字

开场

Shy Ruparel

大家好,我是 Shy,在 Temporal 做开发者倡导。我看不到台下的人,所以你们要是嘘我,或者想朝我扔西红柿,我都不会知道。好吧,翻页器真难用。好了。

02 0:35 387 字

金融依赖长流程

Shy Ruparel

看来今天我不用翻页器了。智能体到处都是,我猜在座各位不是正在构建智能体,就是准备把智能体上线,对吧?去年 KPMC 做了一项调查,发现 2025 年企业生产力收益达到 3 万亿美元,这是他们《Agentic AI》报告里的数据。在这 3 万亿美元中,金融服务业走在前面:94% 的金融科技公司表示,AI 已经是业务运营的核心。AI 不再只是边缘项目,而是业务的一部分,是我们现在的运营方式。

不过,62% 的团队仍因可靠性问题损失了可量化的时间或收入。决定要做 AI,和真正把它交付上线,显然是两回事。这里有个原因:金融依赖的是长流程,而不是单个模型。比如贷款发放、KYC 和 AML、欺诈审查、给人付款。每个流程都要跨好几天、好几个系统,通常还要经过好几个人。步骤很多,系统很多,牵涉的是真金白银,所以出错代价很高。现在再想想,如果把一个智能体放进这样的流程中间,会怎样?

03 2:06 343 字

《开发现状》调查

Shy Ruparel

Temporal 想了解实际情况,于是做了调查。这是我们连续第二年开展《开发现状》(State of Development)调查。我们访问了 554 位正在使用 AI 智能体的工程师和工程负责人。这套演示文稿里的每个数字都来自这份报告,或者我会在左下角标明数据来源。

先看看受访者情况:48.4% 的人有 11 年以上的行业经验,所以他们不是业余爱好者。其余受访者里也有不少人有 6 到 10 年经验;这些人都是每天在工作的专业人士。受访者包括软件工程师、AI 工程师、数据工程师、平台团队和 IT 负责人。三分之二来自美国,三分之一来自英国和欧洲、中东及非洲地区。我们发现了四个缺口。标题里说了这场演讲要谈缺口,数据也显示确实有四个主要缺口。我会逐一讲解,最后再用一个核心想法收尾。

04 3:16 325 字

缺口一:使用与生产部署

Shy Ruparel

先看第一个缺口:使用和生产部署之间的差距。2025 年那一版调查里,约 47.3% 的受访者每天使用智能体。将近一年后的今天,这个比例翻了一倍,达到 80.8%。

但使用智能体,不等于把智能体交付上线。再问这些团队在做什么,大约一半说他们已经在生产环境运行智能体,或者智能体已经成为他们交付方式的核心;另一半还在试验,或者只把智能体当辅助工具。具体来说,49.1% 的受访者在生产环境运行智能体,并称它们对交付至关重要。

差距很大:每天使用智能体的人占 80% 左右,真正把它们部署到生产环境的只有 49.1%,中间差了约 30 个百分点。实际用于生产的人远少于日常使用的人。通往生产环境的路上,似乎总有什么东西在出问题。接下来我们看看问题出在哪里。

05 4:33 763 字信息密度高

缺口二:信任与现实

Shy Ruparel

第二个缺口是信任与现实的落差。我们问受访者到底有多信任智能体的输出。信任度其实很高,这个数字让我挺惊讶:四分之一的人几乎完全信任智能体输出,大多数人有一定程度的信任,几乎没人明确表示不信任。我自己属于完全不信任或多少有点不信任的那一类,所以没被邀请参加这项调查。我确实很意外。85.5% 的受访者至少在某种程度上信任智能体输出。这个数字很重要,待会儿我们还会再提到。

我们还问了智能体出问题的频率。图里的粉色代表每天或更频繁地遇到问题。对于一个有 85% 人信任的系统来说,粉色实在太多了。41.1% 的受访者每天或更频繁地遇到智能体问题,也就是每十个人里有四个每天都碰上;16.4% 每小时都会遇到,也就是六个人里有一个。于是,85.5% 的信任度和 41.1% 的系统故障同时存在:我们信任输出和系统,但它每天仍会出问题。这两件事可以同时为真。

把智能体用得更熟,并不能消除这些问题;光靠提升技能走不出去。自称成功的团队,持续遇到问题的可能性反而高出 1.7 倍,也就是落在每小时或每天出问题的类别里。这不是因为他们运行的智能体更多;报告发现,智能体数量和问题频率之间没有相关性。我和 Temporal 团队猜测,这些团队可能只是查得更仔细,所以发现了更多问题。明年再做调查时,我们需要继续研究这一点。关键是,不管你多信任智能体,失败都不会消失。必须把失败算进去、提前做好准备。目标不是零故障,而是在生产环境使用智能体时,让故障不造成损失。

还有个很有意思的数据:40% 的团队说,安全问题才是真正阻碍他们使用自主智能体的因素。这本身就够讲一场了。Temporal 团队的 Mason 和 Keycard 团队的 Kim 昨天在工作坊那天专门讲过这个话题,我就不展开了,大家可以去看那场演讲的录像。下面我们进入第三个缺口。

06 7:19 481 字

缺口三:原型与企业级部署

Shy Ruparel

第三个缺口,是我们去年大概都在做的 AI 原型,与真正能让客户使用、达到生产标准的代码和系统之间的差距。大多数团队都希望把 AI 原型很快变成可投入生产的代码,但从数据看,实际速度并不快。只有 51.3% 的团队能在几小时内或更短时间里,把 AI 原型变成可用于生产的东西。这是创业公司的速度,对吧?

但如果你在大公司工作,情况就不一样了。员工超过 5,000 人的公司,往往要花几个月。按数据细分,最大型的公司里约五分之一的人说需要几个月;其他公司大约只有二十分之一这么说。换句话说,大公司上线速度差异很大,大家用的工具相同,交付速度却截然不同。一半的团队几小时内就能上线,而大型公司中有五分之一要花五个月。

大公司、受监管的业务——比如银行、保险公司、支付公司——需要很多关键保障:审批、审计记录,以及不会把付款弄丢的系统。我猜现场就有不少这类公司的朋友。我个人的理解是,那五个月主要花在确保可审计、让人信任这些系统上。调查没有进一步拆解这部分。但这不该只是为了官僚流程而官僚;至少我希望,这些流程是为了实现可靠性标准。说到这里,就来到最后一个可靠性缺口……

07 8:56 588 字

缺口四:看见问题与恢复运行

Shy Ruparel

最后一个缺口是“看见”与“恢复”。这也是标题里提到的。我们问,什么最限制团队的生产力?第一是跟踪状态,第二是调试,模型根本没排进前两名。35.7% 的人说,跨服务跟踪状态是他们最大的障碍;30.9% 说,定位和调试问题最难。调查中 22.2% 的人会因为崩溃和重启而丢失进度、重做工作,也就是五个人里有一个会丢掉已经做过的事。

去年另一项调查里,27% 的人说他们的状态管理很脆弱。今年的调查把它列为头号障碍。两次调查的问题不同,所以不能把它当成趋势线,但讲的是同一个故事:智能体越接近真实业务,状态管理就越重要。

我们收到一个特别离谱的回答:智能体出问题时,你会去哪里求助?第一名居然是 YouTube,这让我很意外。我平时不会靠 YouTube 写代码,这和我的做事方式很不一样。但如果系统没法告诉你发生了什么,调试就会变成去 YouTube 找一个能解释情况的人。

现在的可观测性通常只能告诉你智能体失败了。大多数团队都有追踪、日志和 LLM 可观测性工具。但可靠性意味着失败不会让你付出代价。只有 13% 的受访者非常有信心,认为自己能在规模化情况下观察和调试 AI 工作流;与此同时,22% 的人会因崩溃而丢失进度。所以,“看见”和“恢复”之间的差距,就是凌晨两点有人读着追踪记录,再手工修复状态。这不现实,不能指望有人凌晨两点起来修东西。接下来我想快速演示一下……

08 10:54 586 字信息密度高

演示:崩溃后仍能完成的付款

Shy Ruparel

我来快速演示一下实际效果。我要转一笔 2,500 美元。这是个合成客户,但工作流运行在真实的 Temporal 上,笔记本上也跑着真正的 LLM。我现在在这台电脑上运行的是 Qwen 36B……9B。(口误,型号听不清)接下来会演示付款流程:一共九个阶段,比真实生产流程短得多。资金会转出去,但这笔交易看起来有点异常,所以智能体会介入调查欺诈。它会查看交易,判断是否要升级给人工处理,还是可以直接放行。最后由人来做决定,审批或拒绝交易。

流程会先验证请求、预留资金、核对外汇报价,资金也会在另一个系统中真实预留。然后智能体会实际开展工作、调用工具;接着我会杀掉进程,也就是停止 worker,模拟 worker 崩溃。现实里可能是超时、部署出错或内存耗尽。我会故意把它杀掉,看看会丢失什么。

按传统做法,资金已经预留,却没有完成付款;调查简报也生成了,却没能送到审批人手上。通常还得重新花 LLM token,重新生成 AI 草稿或审核摘要。在传统架构里,这些状态都留在进程内存中,worker 一崩溃就全没了。资金仍在银行系统里预留着,只是我们的系统不知道这回事。传统做法需要自己写恢复代码、建状态表、写重试逻辑、创建对账任务。这些代码跟支付交易的核心业务逻辑毫无关系。30% 的受访者抱怨,他们不得不写一大堆与业务逻辑无关的代码。或者,你可以使用一个能记住进度的平台。

09 13:06 1,118 字信息密度高

持久执行的原理

Shy Ruparel

这就是持久执行(durable execution)的用武之地。这是 Temporal 的一个概念:即使进程停止,代码仍应能运行到完成。我们知道崩溃会发生,但用 Temporal,状态和进度都能保留下来。每一步都会记录在事件历史里,AI 的状态也会记录下来。等会儿会看到一条实时运行时间线,就是刚才付款演示的记录。

每个 AI 步骤——比如决定要调查什么、智能体循环要调用哪些工具、查询客户信息、起草简报——都各自作为一个活动执行,并记录结果。黄色的部分表示流程在等待人工审批。工作流代码负责决定接下来做什么,这部分是确定性的。任何非确定性操作或有副作用的操作,比如调用 LLM,都会放在 activity 里执行。工具调用或银行 API 调用也都是 activity。人批准或拒绝交易时,则会产生一个事件,我们称之为 signal。它会像其他事情一样记在 Temporal 的历史记录中。即使当时没有 worker 在运行,signal 也会被记录并处理。因此 worker 崩溃后,另一个 worker 可以从上一次成功的地方接着执行。

历史记录存在 Temporal 服务里,因此我们不会重复运行 LLM 工具调用、浪费 token;智能体已经做过的工作会保留下来,不必重做。如果 worker 在一次调用进行到一半时崩溃,那项 activity 会重试,但此前完成的所有内容都会保留。这很重要:有 80% 的人说成本限制了他们使用智能体。保留智能体的记忆很有帮助。每次遇到缓存问题就重跑智能体,会烧掉很多钱。

现在来看这个小演示。这是我的转账页面,我把金额设为 2,500 美元,收款人设为新收款人,并标记这笔金额对这个客户来说不寻常。为了确保 AI 把它标记为需要调查,我还在客户记录里设置了一个未解决的账户警报。然后启动任务,触发新的工作流。下方时间线上可以看到刚才说的九个步骤:预留资金、验证请求,AI 启动智能体循环,决定查看客户资料、查看付款记录,再起草一份给人工审核的简报。这里有批准或拒绝按钮。

不过在点击按钮前,我要故意杀掉 worker,直接按停止。现在没有 worker 在运行,我来批准这笔交易。你会看到这次批准被记成一个 signal。传统系统里,这个信号可能就丢了。稍后会超时,不过没关系,重试策略会自动处理。worker 一恢复运行,就会收到这个 signal,从上一个成功事件继续执行。我们启动一个 worker,这要等一会儿。现场演示时总会慢一些,平常是即时完成的。我刷新一下……其实这个情景我有一段视频,我们直接看视频吧——如果它能播放的话。让我跳到中间……哦,视频在另一个标签页,我在干什么?

10 17:06 383 字

持久执行的演示结果

Shy Ruparel

worker 停着的时候,我会先批准,然后重新启动 worker。它应该会接着处理:智能体进行调查、写简报;我批准后,还可以在等待银行批准交易或标记交易完成时再次杀掉 worker。signal 会被记录;等我重新启动 worker,它就会接着处理。事件历史记录展示的就是这一过程,我再把画面放大。

从上往下看,每个 AI activity 都只运行了一次,尝试一次、成功一次,没有再次执行。工作流没有重跑,token 也没有重新花;我们只运行了一次,只付了一次成本。没有 worker 运行时,审批 signal 仍然送达;银行提交也在没有 worker 时发生。这两件事都是由新启动的 worker 接手的。每次我们都停掉旧 worker,再由新 worker 恢复进度。worker 数量为零时,付款流程仍然等待着;审批信号到达之后,我们不必从头重跑任何内容。

11 18:13 626 字

演示解决了什么

Shy Ruparel

工程负责人说,究竟有哪些问题拖慢了他们?刚才的演示处理了他们列出的七个主要问题:状态调试、成本、重试、审批、长时间运行的工作,以及崩溃恢复。我们可以看看每一项在代码里是怎么实现的。

在 Temporal 里,状态管理原本是调查中排名第一的障碍——不,准确地说,是那份调查里排名第一的障碍。工作流的状态就是一些字段、普通变量,不需要我自己建数据库或缓存。崩溃后,重放会把状态原样重建。通常,LLM 调用如果跑多次就会多次收费;这次我们保留了智能体的状态,只运行了一次。工具运行结果也一直保留,所以不必再花新的 token。重试本身是策略,不是代码里的循环。我们在配置里声明一次重试策略,它就会应用于这笔交易的每一次调用。代码里根本没有循环。

这大概是这场演讲最重要的一页:智能体只提供建议,真正掌管资金和状态的是工作流。AI 只能在严格限定的范围内参与。如果模型失败,付款仍会继续,只是没有简报;模型服务中断也不会让其他环节降级。我们设置了人工审批,等待时间想设多长都行,代码无需改变。等一年再恢复 worker 也可以。我没有写任何崩溃恢复代码,这些都由 Temporal 提供。

在多数技术栈里,可观测性和恢复分别记录,久而久之会对不上,最后还得靠人把两边拼起来。这里我们在界面里用来调试的历史记录,和 worker 重放时读取的是同一份历史,这就弥合了第四个缺口。七个障碍,一个工作流就解决了。这不只是演示——现在已经有人在生产环境中使用这套东西。

12 20:12 291 字

谁在生产环境使用 Temporal

Shy Ruparel

现在确实有人把它用在生产环境。OpenAI 的 Codex 运行在 Temporal 上。你们一天里经常用到的那个编程智能体,就跑在 Temporal 上。Replit 也用 Temporal 运行他们的智能体。他们的工程团队说,智能体已经把任务做了很久、走得很远,最后却遇到灾难性错误,这会带来很糟糕的用户体验。我们刚才演示的,正是如何避免这种情况。

我得抓紧了,时间快不够了。对 AI 工程师来说,你写好提示词、运行它;如果输出不好,就把结果丢掉,让 Temporal 替你重试。糟糕的模型输出就是一次 activity 失败,也可以用类似的重试策略处理。回到刚才那四个缺口……

13 20:51 165 字

总结

Shy Ruparel

一份记录弥合了所有缺口。快速回顾一下这四个缺口——(笑)——可靠性和可观测性最终可以放在同一份记录里。我刚才提到的所有数字都来自 Temporal.io 的《开发现状》报告。我把报告留在屏幕上,大家可以拍照,之后去看看。Temporal 展台会有不少同事现场演示,有兴趣的话可以去看看,也可以来打个招呼。这就是我的演讲,谢谢大家。