返回资讯中心
外部精选
软件工程
#开发者实时流

Dapr的Catalyst为AI Agent提供持久执行能力,崩溃后可从中断步骤恢复

来源标题:Durable Execution: The Missing Runtime Primitive for Agents

Dapr的Catalyst为AI Agent提供持久执行运行时能力,让崩溃的Agent从第47步继续而非重头开始。该能力需同时解决进程失败检测、状态恢复和断点重启三个问题,而多数Agent框架依赖的检查点机制无法做到,用try/except或重试装饰器也无法弥补。

Hacker News 最新mwfussell2026/11/5 · 今天30 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

回到博客ai-agentsdurable-executionagentic-ai 持久化执行:Agent 缺失的运行时原语 当 agent 在第 47 步崩溃时,它应该从那里恢复,而不是从头开始。为什么持久化执行应该属于运行时,框架自带的检查点机制在哪里不够用,以及 Dapr 上的 Catalyst 如何自动恢复崩溃的 agent 工作流。 本系列的第一篇文章列出了生产环境中 agent 失败的四种方式:持久性、安全性、成本和可观测性,并承诺这一篇会从持久性开始。上一篇文章以一个具体的承诺结束:一个在 50 步任务的第 47 步崩溃的 agent,应该从第 47 步恢复,而不是从第 1 步重新开始。这篇文章讲的是实现这一点的运行时属性——持久化执行,以及为什么大多数 agent 框架没有提供它。 持久化执行是一种运行时属性,不是你可以打开的一个设置开关。它必须同时解决三个难题:检测进程失败、恢复其状态、并从停止的地方重新启动。你不能在 agent 写完之后,用一个 try/except 块或一个重试装饰器把它补上,因为需要在崩溃中存活下来的不是代码,而是代码已经完成了什么的记录。例如,当一个 Kubernetes pod 在业务流程执行到一半时被驱逐,保存该执行记录的内存也随之消失。进程重新启动时完全不知道它的 50 个步骤中哪些已经运行过、它调用了哪些外部系统或工具、以及工具返回了什么。持久化执行是一种运行时能力,它把执行步骤的记录保存在进程不拥有的某个地方,这样重启就变成了恢复,而不是重做。 这和企业把应用从开发者的笔记本电脑迁移到生产环境时所经历的同一种转变是一样的。那些假设只有一个长期存活的进程的代码,必须围绕进程会被重新调度、扩缩容和杀死这一事实来重建。Kubernetes 解决了其中一部分。它在 pod 死亡时重启并重新调度它们,但它不会恢复进程正在做的事情,因此该 pod 中的进行中状态会丢失。持久化执行是缺失的另一半,这一层把状态带回来,让重启的进程继续而不是从头开始。Agent 是一种长时间运行、有状态、非确定性的应用类型,正是这种组合迫使问题必须被解决。当团队的服务是无状态且确定性的时候,他们可以不做持久化执行也过得去。一个跨 50 步进行推理的 agent 既不是无状态的也不是确定性的,因此进程丢失意味着工作丢失和花费丢失,而且你不能从头重新运行它并期望得到相同的路径。 持久化执行:一种执行模型,工作流的每个步骤在完成时都会被持久化,因此工作流可以在崩溃、重启或中断后从最后一个已完成的持久化步骤重建并恢复。 这种模型有一个谱系:循环如何变得持久化,梳理了通向它的七个执行阶段,最终以循环脱离进程结束。 把持久化执行与两个容易混淆的概念区分开来是有帮助的。重试只是在失败后再次调用同一步骤,对于崩溃前已经完成的步骤毫无帮助。检查点保存了状态,你以后可以重新加载,但仍然需要有东西注意到进程死了并决定重新加载它。两者单独都不够。持久化执行增加了真正困难的部分:首先检测失败,然后恢复已持久化的历史,并在停止的地方重新启动运行,无需任何人手动重建发生了什么。 其背后的机制是事件溯源。运行时不是把工作流状态保存在内存中并希望进程保持存活,而是把每个步骤的仅追加历史写入后端存储。Dapr——Diagrid Catalyst 中使用的开源 CNCF 运行时——称之为重放技术。当工作流恢复时,工作流通过重放已持久化的历史来重建其状态,已完成的活动返回其存储的结果,而不是再次运行。结果已被记录的 web 搜索不会被重复,响应已被持久化的 LLM 调用在重放期间不会再次计费。当重放到达被中断的步骤时,局部变量已恢复,工作流继续执行,就像从未停止过一样。 这种模型有两条规则,它们很容易混淆。编排逻辑必须是确定性的,这样相同的历史总是以相同的方式重放。活动必须是幂等的,这样在失败后重试的步骤不会使其副作用加倍。任何在运行之间变化的东西——时间戳、随机值、直接网络调用——都属于活动内部,而不是编排中,并且该活动必须可以安全地运行多次。持久化执行文档详细说明了幂等性规则。 持久化执行恢复已完成的、持久化的步骤。它本身并不能使非幂等的副作用变得安全。如果一个活动扣了卡、记了账或发送了邮件,而进程在提供方已执行操作之后、运行时记录结果之前死亡,运行时可能会在恢复时重试该活动。持久性为运行时提供了已完成工作的记忆。幂等键、事务 ID 或发件箱模式才是保护外部系统免受重复副作用影响的手段。两者你都需要,它们解决的是问题的不同部分。 看清差距所在的最清晰方式是在代码中。LangGraph 是一个广泛使用的 agent 框架,它自带持久化层,这使它成为检验框架原生状态保存是否足够的公平测试。

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →