--- id: "mJ7q8CuVmbw" title: "我们信任那些每天都会出故障的 AI 智能体｜Shy Ruparel，Temporal" channel: "AI Engineer" host: [] guests: ["Shy Ruparel"] date: "2026-10-29" updated: "2026-11-01" duration: "21:32" duration_seconds: 1292 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=mJ7q8CuVmbw" canonical: "https://pod-exp.pages.dev/mJ7q8CuVmbw/" transcript_jsonl: "https://pod-exp.pages.dev/mJ7q8CuVmbw/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["AI 智能体","AI 基础设施","金融基础设施"] series: ["AI 基础设施"] --- # 我们信任那些每天都会出故障的 AI 智能体｜Shy Ruparel，Temporal > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** Temporal 开发者倡导 Shy Ruparel 以一项针对 554 位工程师和工程负责人的调查为线索，指出 AI 智能体从日常使用走向生产部署仍有四个缺口：使用与部署、信任与可靠性、原型与企业落地、可观测与可恢复。演讲通过一个 2,500 美元付款流程演示持久执行：即使 worker 崩溃，工作流状态和进度仍保留，审批信号可在 worker 停机时记录，恢复后从上次成功处继续。LLM 活动只运行一次，资金和状态由确定性的工作流控制，AI 的职责受到限制。 ## [0:01] 开场 · YouTube **Shy Ruparel：** 大家好，我是 Shy，在 Temporal 做开发者倡导。我看不到台下的人，所以你们要是嘘我，或者想朝我扔西红柿，我都不会知道。好吧，翻页器真难用。好了。 ## [0:35] 金融依赖长流程 · YouTube **Shy Ruparel：** 看来今天我不用翻页器了。智能体到处都是，我猜在座各位不是正在构建智能体，就是准备把智能体上线，对吧？去年 KPMC 做了一项调查，发现 2025 年企业生产力收益达到 3 万亿美元，这是他们《Agentic AI》报告里的数据。在这 3 万亿美元中，金融服务业走在前面：94% 的金融科技公司表示，AI 已经是业务运营的核心。AI 不再只是边缘项目，而是业务的一部分，是我们现在的运营方式。 **Shy Ruparel：** 不过，62% 的团队仍因可靠性问题损失了可量化的时间或收入。决定要做 AI，和真正把它交付上线，显然是两回事。这里有个原因：金融依赖的是长流程，而不是单个模型。比如贷款发放、KYC 和 AML、欺诈审查、给人付款。每个流程都要跨好几天、好几个系统，通常还要经过好几个人。步骤很多，系统很多，牵涉的是真金白银，所以出错代价很高。现在再想想，如果把一个智能体放进这样的流程中间，会怎样？ ## [2:06] 《开发现状》调查 · YouTube **Shy Ruparel：** Temporal 想了解实际情况，于是做了调查。这是我们连续第二年开展《开发现状》（State of Development）调查。我们访问了 554 位正在使用 AI 智能体的工程师和工程负责人。这套演示文稿里的每个数字都来自这份报告，或者我会在左下角标明数据来源。 **Shy Ruparel：** 先看看受访者情况：48.4% 的人有 11 年以上的行业经验，所以他们不是业余爱好者。其余受访者里也有不少人有 6 到 10 年经验；这些人都是每天在工作的专业人士。受访者包括软件工程师、AI 工程师、数据工程师、平台团队和 IT 负责人。三分之二来自美国，三分之一来自英国和欧洲、中东及非洲地区。我们发现了四个缺口。标题里说了这场演讲要谈缺口，数据也显示确实有四个主要缺口。我会逐一讲解，最后再用一个核心想法收尾。 ## [3:16] 缺口一：使用与生产部署 · YouTube **Shy Ruparel：** 先看第一个缺口：使用和生产部署之间的差距。2025 年那一版调查里，约 47.3% 的受访者每天使用智能体。将近一年后的今天，这个比例翻了一倍，达到 80.8%。 **Shy Ruparel：** 但使用智能体，不等于把智能体交付上线。再问这些团队在做什么，大约一半说他们已经在生产环境运行智能体，或者智能体已经成为他们交付方式的核心；另一半还在试验，或者只把智能体当辅助工具。具体来说，49.1% 的受访者在生产环境运行智能体，并称它们对交付至关重要。 **Shy Ruparel：** 差距很大：每天使用智能体的人占 80% 左右，真正把它们部署到生产环境的只有 49.1%，中间差了约 30 个百分点。实际用于生产的人远少于日常使用的人。通往生产环境的路上，似乎总有什么东西在出问题。接下来我们看看问题出在哪里。 ## [4:33] 缺口二：信任与现实 · YouTube **Shy Ruparel：** 第二个缺口是信任与现实的落差。我们问受访者到底有多信任智能体的输出。信任度其实很高，这个数字让我挺惊讶：四分之一的人几乎完全信任智能体输出，大多数人有一定程度的信任，几乎没人明确表示不信任。我自己属于完全不信任或多少有点不信任的那一类，所以没被邀请参加这项调查。我确实很意外。85.5% 的受访者至少在某种程度上信任智能体输出。这个数字很重要，待会儿我们还会再提到。 **Shy Ruparel：** 我们还问了智能体出问题的频率。图里的粉色代表每天或更频繁地遇到问题。对于一个有 85% 人信任的系统来说，粉色实在太多了。41.1% 的受访者每天或更频繁地遇到智能体问题，也就是每十个人里有四个每天都碰上；16.4% 每小时都会遇到，也就是六个人里有一个。于是，85.5% 的信任度和 41.1% 的系统故障同时存在：我们信任输出和系统，但它每天仍会出问题。这两件事可以同时为真。 **Shy Ruparel：** 把智能体用得更熟，并不能消除这些问题；光靠提升技能走不出去。自称成功的团队，持续遇到问题的可能性反而高出 1.7 倍，也就是落在每小时或每天出问题的类别里。这不是因为他们运行的智能体更多；报告发现，智能体数量和问题频率之间没有相关性。我和 Temporal 团队猜测，这些团队可能只是查得更仔细，所以发现了更多问题。明年再做调查时，我们需要继续研究这一点。关键是，不管你多信任智能体，失败都不会消失。必须把失败算进去、提前做好准备。目标不是零故障，而是在生产环境使用智能体时，让故障不造成损失。 **Shy Ruparel：** 还有个很有意思的数据：40% 的团队说，安全问题才是真正阻碍他们使用自主智能体的因素。这本身就够讲一场了。Temporal 团队的 Mason 和 Keycard 团队的 Kim 昨天在工作坊那天专门讲过这个话题，我就不展开了，大家可以去看那场演讲的录像。下面我们进入第三个缺口。 ## [7:19] 缺口三：原型与企业级部署 · YouTube **Shy Ruparel：** 第三个缺口，是我们去年大概都在做的 AI 原型，与真正能让客户使用、达到生产标准的代码和系统之间的差距。大多数团队都希望把 AI 原型很快变成可投入生产的代码，但从数据看，实际速度并不快。只有 51.3% 的团队能在几小时内或更短时间里，把 AI 原型变成可用于生产的东西。这是创业公司的速度，对吧？ **Shy Ruparel：** 但如果你在大公司工作，情况就不一样了。员工超过 5,000 人的公司，往往要花几个月。按数据细分，最大型的公司里约五分之一的人说需要几个月；其他公司大约只有二十分之一这么说。换句话说，大公司上线速度差异很大，大家用的工具相同，交付速度却截然不同。一半的团队几小时内就能上线，而大型公司中有五分之一要花五个月。 **Shy Ruparel：** 大公司、受监管的业务——比如银行、保险公司、支付公司——需要很多关键保障：审批、审计记录，以及不会把付款弄丢的系统。我猜现场就有不少这类公司的朋友。我个人的理解是，那五个月主要花在确保可审计、让人信任这些系统上。调查没有进一步拆解这部分。但这不该只是为了官僚流程而官僚；至少我希望，这些流程是为了实现可靠性标准。说到这里，就来到最后一个可靠性缺口…… ## [8:56] 缺口四：看见问题与恢复运行 · YouTube **Shy Ruparel：** 最后一个缺口是“看见”与“恢复”。这也是标题里提到的。我们问，什么最限制团队的生产力？第一是跟踪状态，第二是调试，模型根本没排进前两名。35.7% 的人说，跨服务跟踪状态是他们最大的障碍；30.9% 说，定位和调试问题最难。调查中 22.2% 的人会因为崩溃和重启而丢失进度、重做工作，也就是五个人里有一个会丢掉已经做过的事。 **Shy Ruparel：** 去年另一项调查里，27% 的人说他们的状态管理很脆弱。今年的调查把它列为头号障碍。两次调查的问题不同，所以不能把它当成趋势线，但讲的是同一个故事：智能体越接近真实业务，状态管理就越重要。 **Shy Ruparel：** 我们收到一个特别离谱的回答：智能体出问题时，你会去哪里求助？第一名居然是 YouTube，这让我很意外。我平时不会靠 YouTube 写代码，这和我的做事方式很不一样。但如果系统没法告诉你发生了什么，调试就会变成去 YouTube 找一个能解释情况的人。 **Shy Ruparel：** 现在的可观测性通常只能告诉你智能体失败了。大多数团队都有追踪、日志和 LLM 可观测性工具。但可靠性意味着失败不会让你付出代价。只有 13% 的受访者非常有信心，认为自己能在规模化情况下观察和调试 AI 工作流；与此同时，22% 的人会因崩溃而丢失进度。所以，“看见”和“恢复”之间的差距，就是凌晨两点有人读着追踪记录，再手工修复状态。这不现实，不能指望有人凌晨两点起来修东西。接下来我想快速演示一下…… ## [10:54] 演示：崩溃后仍能完成的付款 · YouTube **Shy Ruparel：** 我来快速演示一下实际效果。我要转一笔 2,500 美元。这是个合成客户，但工作流运行在真实的 Temporal 上，笔记本上也跑着真正的 LLM。我现在在这台电脑上运行的是 Qwen 36B……9B。（口误，型号听不清）接下来会演示付款流程：一共九个阶段，比真实生产流程短得多。资金会转出去，但这笔交易看起来有点异常，所以智能体会介入调查欺诈。它会查看交易，判断是否要升级给人工处理，还是可以直接放行。最后由人来做决定，审批或拒绝交易。 **Shy Ruparel：** 流程会先验证请求、预留资金、核对外汇报价，资金也会在另一个系统中真实预留。然后智能体会实际开展工作、调用工具；接着我会杀掉进程，也就是停止 worker，模拟 worker 崩溃。现实里可能是超时、部署出错或内存耗尽。我会故意把它杀掉，看看会丢失什么。 **Shy Ruparel：** 按传统做法，资金已经预留，却没有完成付款；调查简报也生成了，却没能送到审批人手上。通常还得重新花 LLM token，重新生成 AI 草稿或审核摘要。在传统架构里，这些状态都留在进程内存中，worker 一崩溃就全没了。资金仍在银行系统里预留着，只是我们的系统不知道这回事。传统做法需要自己写恢复代码、建状态表、写重试逻辑、创建对账任务。这些代码跟支付交易的核心业务逻辑毫无关系。30% 的受访者抱怨，他们不得不写一大堆与业务逻辑无关的代码。或者，你可以使用一个能记住进度的平台。 ## [13:06] 持久执行的原理 · YouTube **Shy Ruparel：** 这就是持久执行（durable execution）的用武之地。这是 Temporal 的一个概念：即使进程停止，代码仍应能运行到完成。我们知道崩溃会发生，但用 Temporal，状态和进度都能保留下来。每一步都会记录在事件历史里，AI 的状态也会记录下来。等会儿会看到一条实时运行时间线，就是刚才付款演示的记录。 **Shy Ruparel：** 每个 AI 步骤——比如决定要调查什么、智能体循环要调用哪些工具、查询客户信息、起草简报——都各自作为一个活动执行，并记录结果。黄色的部分表示流程在等待人工审批。工作流代码负责决定接下来做什么，这部分是确定性的。任何非确定性操作或有副作用的操作，比如调用 LLM，都会放在 activity 里执行。工具调用或银行 API 调用也都是 activity。人批准或拒绝交易时，则会产生一个事件，我们称之为 signal。它会像其他事情一样记在 Temporal 的历史记录中。即使当时没有 worker 在运行，signal 也会被记录并处理。因此 worker 崩溃后，另一个 worker 可以从上一次成功的地方接着执行。 **Shy Ruparel：** 历史记录存在 Temporal 服务里，因此我们不会重复运行 LLM 工具调用、浪费 token；智能体已经做过的工作会保留下来，不必重做。如果 worker 在一次调用进行到一半时崩溃，那项 activity 会重试，但此前完成的所有内容都会保留。这很重要：有 80% 的人说成本限制了他们使用智能体。保留智能体的记忆很有帮助。每次遇到缓存问题就重跑智能体，会烧掉很多钱。 **Shy Ruparel：** 现在来看这个小演示。这是我的转账页面，我把金额设为 2,500 美元，收款人设为新收款人，并标记这笔金额对这个客户来说不寻常。为了确保 AI 把它标记为需要调查，我还在客户记录里设置了一个未解决的账户警报。然后启动任务，触发新的工作流。下方时间线上可以看到刚才说的九个步骤：预留资金、验证请求，AI 启动智能体循环，决定查看客户资料、查看付款记录，再起草一份给人工审核的简报。这里有批准或拒绝按钮。 **Shy Ruparel：** 不过在点击按钮前，我要故意杀掉 worker，直接按停止。现在没有 worker 在运行，我来批准这笔交易。你会看到这次批准被记成一个 signal。传统系统里，这个信号可能就丢了。稍后会超时，不过没关系，重试策略会自动处理。worker 一恢复运行，就会收到这个 signal，从上一个成功事件继续执行。我们启动一个 worker，这要等一会儿。现场演示时总会慢一些，平常是即时完成的。我刷新一下……其实这个情景我有一段视频，我们直接看视频吧——如果它能播放的话。让我跳到中间……哦，视频在另一个标签页，我在干什么？ ## [17:06] 持久执行的演示结果 · YouTube **Shy Ruparel：** worker 停着的时候，我会先批准，然后重新启动 worker。它应该会接着处理：智能体进行调查、写简报；我批准后，还可以在等待银行批准交易或标记交易完成时再次杀掉 worker。signal 会被记录；等我重新启动 worker，它就会接着处理。事件历史记录展示的就是这一过程，我再把画面放大。 **Shy Ruparel：** 从上往下看，每个 AI activity 都只运行了一次，尝试一次、成功一次，没有再次执行。工作流没有重跑，token 也没有重新花；我们只运行了一次，只付了一次成本。没有 worker 运行时，审批 signal 仍然送达；银行提交也在没有 worker 时发生。这两件事都是由新启动的 worker 接手的。每次我们都停掉旧 worker，再由新 worker 恢复进度。worker 数量为零时，付款流程仍然等待着；审批信号到达之后，我们不必从头重跑任何内容。 ## [18:13] 演示解决了什么 · YouTube **Shy Ruparel：** 工程负责人说，究竟有哪些问题拖慢了他们？刚才的演示处理了他们列出的七个主要问题：状态调试、成本、重试、审批、长时间运行的工作，以及崩溃恢复。我们可以看看每一项在代码里是怎么实现的。 **Shy Ruparel：** 在 Temporal 里，状态管理原本是调查中排名第一的障碍——不，准确地说，是那份调查里排名第一的障碍。工作流的状态就是一些字段、普通变量，不需要我自己建数据库或缓存。崩溃后，重放会把状态原样重建。通常，LLM 调用如果跑多次就会多次收费；这次我们保留了智能体的状态，只运行了一次。工具运行结果也一直保留，所以不必再花新的 token。重试本身是策略，不是代码里的循环。我们在配置里声明一次重试策略，它就会应用于这笔交易的每一次调用。代码里根本没有循环。 **Shy Ruparel：** 这大概是这场演讲最重要的一页：智能体只提供建议，真正掌管资金和状态的是工作流。AI 只能在严格限定的范围内参与。如果模型失败，付款仍会继续，只是没有简报；模型服务中断也不会让其他环节降级。我们设置了人工审批，等待时间想设多长都行，代码无需改变。等一年再恢复 worker 也可以。我没有写任何崩溃恢复代码，这些都由 Temporal 提供。 **Shy Ruparel：** 在多数技术栈里，可观测性和恢复分别记录，久而久之会对不上，最后还得靠人把两边拼起来。这里我们在界面里用来调试的历史记录，和 worker 重放时读取的是同一份历史，这就弥合了第四个缺口。七个障碍，一个工作流就解决了。这不只是演示——现在已经有人在生产环境中使用这套东西。 ## [20:12] 谁在生产环境使用 Temporal · YouTube **Shy Ruparel：** 现在确实有人把它用在生产环境。OpenAI 的 Codex 运行在 Temporal 上。你们一天里经常用到的那个编程智能体，就跑在 Temporal 上。Replit 也用 Temporal 运行他们的智能体。他们的工程团队说，智能体已经把任务做了很久、走得很远，最后却遇到灾难性错误，这会带来很糟糕的用户体验。我们刚才演示的，正是如何避免这种情况。 **Shy Ruparel：** 我得抓紧了，时间快不够了。对 AI 工程师来说，你写好提示词、运行它；如果输出不好，就把结果丢掉，让 Temporal 替你重试。糟糕的模型输出就是一次 activity 失败，也可以用类似的重试策略处理。回到刚才那四个缺口…… ## [20:51] 总结 · YouTube **Shy Ruparel：** 一份记录弥合了所有缺口。快速回顾一下这四个缺口——（笑）——可靠性和可观测性最终可以放在同一份记录里。我刚才提到的所有数字都来自 Temporal.io 的《开发现状》报告。我把报告留在屏幕上，大家可以拍照，之后去看看。Temporal 展台会有不少同事现场演示，有兴趣的话可以去看看，也可以来打个招呼。这就是我的演讲，谢谢大家。