一次五分钟的 Agent 演示，通常可以默认进程不会崩溃、网络稳定、每个工具调用都能返回明确结果。但如果 Agent 工作流要运行五个小时，这些前提都不再成立。
长时间运行的 Agent 可能需要等待外部 API、处理大文件、反复调用模型、执行带副作用的操作，甚至中途停下来等待人工审批。在这个过程中，工作进程可能崩溃，容器可能被替换，请求可能在远端已经成功后才超时，工作流也可能在不同的提示词、模型或工具版本下恢复。此时，Agent 已经不再只是“一段提示词加几次工具调用”，而更像一个包含概率性步骤的分布式工作流。
从演示到生产：持久状态比进程记忆更重要
这篇来自 Dev.to AI 的文章提出了一套面向长时间运行 Agent 工作流的通用生产模式，核心思想是：要继续推进任务，所需的关键信息必须保存在执行进程之外。换言之，工作节点内存中的状态不能被当作持久状态。
文章列举了多个系统中的类似实践。Temporal 通过保存工作流事件历史，让 worker 在故障后重建状态；LangGraph 的持久化机制会以线程为单位保存图状态检查点；AWS Step Functions 的 redrive 能力则允许从失败步骤继续执行，同时保留已成功步骤的结果。这些机制实现方式不同，但都指向同一个架构原则：检查点、事件历史和任务身份必须独立于具体执行进程。
文章还建议区分三类数据：用于恢复的检查点、用于继续执行的工作流状态，以及大文件等产物。混在一起会增加恢复复杂度。例如，一个检查点不应该被迫序列化一个 2GB 的输出文件；长期记忆也不能被当作某个节点已经成功完成的证明。
失败不能只叫“失败”：需要区分可重试、需人工与结果未知
在长时间运行的 Agent 系统中，简单地把任务标记为“Failed”并不足够。不同类型的失败需要不同处理方式。
- 网络中断、限流、临时容量不足、服务重启等属于瞬时故障，可能通过重试恢复。文章建议为重试设置上限、指数退避、抖动以及总重试预算。
- 参数无效、权限缺失、Schema 不兼容、策略拒绝等属于永久性错误，重复发送相同请求通常不会改善结果，应转入修复路径、人工处理或终态。
- 最危险的是结果未知型故障：HTTP 请求超时了，但远端服务可能已经发送邮件、完成扣款、创建工单或修改数据库。
对于第三类情况，文章强调不能把它当作普通失败处理，而应引入一个专门的 NEEDS_RECONCILIATION 状态，在重试前先核对真实结果。AWS 关于幂等 API 的建议也被引用：客户端提供请求令牌，服务端保存令牌与原始请求的关联；如果同一个令牌携带不同参数再次到达，应视为错误，而不是新操作。
幂等键的稳定性同样是关键。文章指出，一种常见错误是把尝试次数加入幂等键，例如基于 workflow_id、node_id 和 attempt_number 生成 key。这样每次重试都会生成新的 key，下游系统会把重试识别为新的操作。更稳妥的做法是，根据 workflow_id、node_id 和逻辑操作 ID 生成稳定哈希，让同一个逻辑动作在多次尝试中保持一致身份。
恢复、预算与审计：长时间 Agent 需要明确边界
文章给出的实践架构并不追求复杂，但强调边界清晰。一个典型的系统包括触发接口、持久编排器、节点执行器、工具适配器、外部 API 与数据库、产物存储、副作用账本、人工审批收件箱，以及用于追踪、日志和评估的存储层。
其中，编排器负责状态转移，工作节点只执行有边界的步骤；大体积输出放入产物存储；可能改变外部世界的工作要记录到副作用账本，包括意图、幂等键和外部回执；等待人工审批的状态应被持久化，而不是靠一个长时间打开的 HTTP 连接维持。追踪存储则用于解释模型、工具、队列和服务之间究竟发生了什么。
在状态设计上，文章认为至少应保留具有运维含义的状态，例如 READY、RUNNING、SUCCEEDED、RETRY_SCHEDULED、WAITING_HUMAN、NEEDS_RECONCILIATION、FAILED_PERMANENT，以及涉及补偿逻辑的 COMPENSATING 和 COMPENSATED。
恢复过程中的版本问题也被单独提出。一个检查点可能比创建它的代码、提示词、模型路由、工具 Schema 或策略存在得更久。因此，恢复时应该基于固定版本执行，或者进行显式迁移。如果在恢复过程中静默升级组件，相当于把一次事故处理变成未经测试的部署。
此外，重试本身也可能放大系统压力。如果每一层都独立重试，流量可能迅速倍增。文章建议明确由哪一层负责重试，并配合退避、抖动和断路器。对于可能无限循环、长期等待审批或在结果已经失去价值后继续消耗 token 的 Agent，每次运行还需要总截止时间，并对模型调用、工具调用、成本、迭代次数和空闲时间设置上限。
并发和重复也是不可回避的问题。同一事件可能被投递两次，两个审批人可能同时批准，自动重试也可能与人工修复发生竞争。文章认为，稳定的工作流 ID、乐观锁和幂等恢复令牌，可以保护状态转移不被重复执行。
随着 Agent 从聊天助手走向更长链路的生产任务，可靠性设计正在成为基础能力。对于需要在数小时内持续执行、调用外部系统并产生真实副作用的 Agent 工作流，真正重要的不只是模型能力，还包括故障分类、检查点、幂等性、预算限制和可审计性。这些工程机制决定了 Agent 能否从“可演示”走向“可运行”。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/dang-ai-agent-lian-xu-yun-xing-shu-xiao-shi-gong-cheng-shi
