长周期智能体与持久执行
内容提要
长周期智能体可自动完成耗时数天至数周的复杂任务，但易遇进程崩溃、网络故障等中断。持久执行模式通过记录每步外部交互结果，使失败后重放时跳过已完成步骤并重建状态。文章以库存补货智能体为例，介绍用Temporal等实现持久化智能体循环，并讨论幂等性、信息过期、代码版本变更、历史增长及提示注入等挑战与应对策略。
延伸解读
持久执行：让智能体像分布式系统一样容错
文章将长周期智能体视为分布式系统，其失败模式（进程崩溃、网络故障、消息丢失）与常规分布式系统无异。持久执行运行时通过记录每个外部交互步骤的输入输出，在崩溃后重放时跳过已完成步骤并重建状态。这使智能体无需编写大量胶水代码处理重试、定时器和恢复逻辑，从而专注于领域逻辑。但文章也指出，智能体与普通分布式系统的关键区别在于模型能自主决定如何恢复，因此 harness 需为模型提供正确输入以决策下一步。
实体工作流与流程工作流：按业务实体组织智能体
文章以库存补货为例，区分了流程工作流（完成一次补货后结束）和实体工作流（代表一个 SKU 的终身状态）。实体工作流负责监控库存、触发补货，并作为该 SKU 的消息入口，将外部消息转发给当前运行的补货流程。这种模式可推广到订阅业务中的客户实体。实体工作流通过 continue_as_new 或快照避免日志无限增长，同时等待原语确保空闲时不占用进程和内存，使数千个智能体可低成本共存。
幂等性与信息过期：持久执行无法自动解决的两类风险
持久执行提供重试，但无法保证重试安全。若供应商已接单但响应丢失，运行时重试可能导致重复订单，因此 harness 必须使用幂等键（如采购单号）让接收方识别重复。此外，智能体决策与执行间隔数天，价格等事实可能过期。文章建议在工具中做确定性检查（如重新获取报价并与批准上限比较），超出范围则返回人工重新审批，而非依赖模型判断。这些策略需要领域知识来权衡。
代码版本变更与提示注入：部署和安全的额外考量
部署 harness 变更会影响挂起的智能体。文章建议将日志视为已发布接口，采用并行变更策略：先新增规则，再迁移新工作流，最后移除旧规则。不同运行时行为不同（Temporal 静默继续旧规则，Cloudflare 可能失败），需提前了解。提示注入方面，智能体无法区分文本与指令，但可通过限制模型只能选择允许的工具、验证审批来源等 harness 防御措施降低风险。这些威胁并非智能体独有，持久执行本身不提供防护。
Q&A
长周期智能体在运行中可能遇到哪些故障？持久执行如何帮助恢复？
长周期智能体可能遇到进程崩溃、网络故障、消息延迟或重复等中断。持久执行通过记录每个与外部交互步骤的结果，在失败后重放程序时跳过已完成步骤，并从记录中重建状态，从而让智能体继续向目标推进。
持久执行模式中的“步骤、日志、重放”分别指什么？
步骤是运行时代表程序对外部世界的调用（如LLM调用、ERP调用、发消息）；日志是运行时在步骤执行前将输入和输出持久化记录；重放是崩溃后程序从头运行，有记录的步骤直接返回日志中的结果而不重新执行，步骤之间的代码重新运行以重建状态。
在库存补货智能体中，实体工作流和流程工作流有什么区别？
流程工作流执行一项具体工作（如一次补货）后结束；实体工作流代表一个业务实体（如一个SKU）在其整个生命周期内持续存在，维护实体状态并启动流程工作流。实体工作流还作为该SKU的消息入口，将外部消息转发给当前运行的补货流程。
持久执行运行时如何高效处理智能体长时间的等待？
运行时提供等待原语（如workflow.wait_condition），在等待消息或超时期间挂起工作流，不占用进程或内存。等待的计时器和结束消息也会记入日志，因此等待能像步骤一样在崩溃后恢复。唤醒时通过重放日志重建状态，实测唤醒耗时通常低于三秒、CPU消耗仅数十毫秒。
为什么重试外部调用需要幂等性？如何实现？
持久执行运行时提供重试原语，但重试可能不安全：如果供应商已接单但响应丢失，运行时无法区分，会再次调用，导致重复下单。为实现“恰好一次”的效果，接收方需用幂等键识别重复请求，且harness必须在每次尝试和重放时保持同一幂等键。例如在place_order工具中，采购订单号作为幂等键。
长周期智能体如何应对决策依据的信息过期问题？
文章给出三种模式，其中一种是价格上限检查：经理批准价格及上浮5%的上限，place_order工具在下单前重新获取报价并检查是否在上限内；若超出上限则不订购，并让智能体回去请求重新批准。这种检查在工具中确定性执行，不受模型决策影响。
部署harness代码变更时，如何避免影响正在等待的智能体？
将日志视为已发布接口，采用并行变更（Parallel Change）策略：先添加新规则，再让新工作流按新规则启动、运行中的工作流按旧规则完成，最后移除旧规则。具体实现可在状态中记录规则版本（如state.rules_version），工具根据版本决定行为，使正在等待的智能体按原规则完成。
