Conductor 的 Token 效率可持久化执行如何让 Agent 崩溃恢复时不再重复付费【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor导读LLM 调用按 token 计费每一次非必要的重执行都会烧掉已经付过费的 token。Conductor 作为事件驱动的 Agent 工作流引擎通过在每个步骤持久化工作流与任务状态保证已完成的 LLM 调用永不重跑——本文基于官方文档 token-efficiency.md 并结合仓库源码系统讲解崩溃恢复、失败重试、指定任务重跑、循环断点四种场景下的 token 节省原理、真实成本量化以及背后的任务输出持久化机制帮助你为 Agent 应用构建零重复付费的执行底座。没有持久化时一次崩溃的真实成本假设一个自主 Agent 运行 20 步循环每轮迭代调用一次 LLM规划 一个工具执行。当执行到第 18 次迭代时进程崩溃没有持久化执行普通框架Agent 从第 1 次迭代重新开始。第 1~17 次迭代必须全部重跑——17 次 LLM 调用产生与之前完全相同的输出token 被再次烧掉工具调用也会重复执行可能产生重复副作用用户还要为已完成的工作继续等待。使用 ConductorAgent 从第 18 次迭代恢复。第 1~17 次迭代已被持久化——它们的 LLM 输出、工具结果和状态全部在持久化存储中。零 token 浪费、零重复工具调用Agent 精确地从上次中断的位置继续。这一对比正是 Conductor 的 持久化执行语义 的核心价值完成的工作永不丢失completed work is never lost。Token 节省发生在哪里四种核心场景1. 崩溃恢复Crash RecoveryConductor 工作流中的每次 LLM 调用在完成时都会被持久化。Prompt、响应、token 用量、模型全部被记录下来在任务输出中对应tokenUsed、promptTokens、completionTokens三个字段见 LLMResponse.java 中的常量定义。当服务器、Worker 或网络发生故障时已完成的 LLM 调用绝不重新执行其输出直接从存储中读取只有正在进行中的那一次调用会被重试——且仅重试这一单个调用工作流从最后持久化的状态继续执行。Token 节省量与崩溃前 Agent 的进度成正比。在第 20 步中的第 18 步崩溃的 Agent节省 17 次 LLM 调用的 token。2. 从失败任务重试Retry from Failed Task当工作流失败时例如 LLM 规划成功但工具调用返回错误你可以从失败任务处重试replay and recovery。Conductor 会复用所有先前已完成任务的输出。示例一个 5 任务组成的 Agent 工作流在第 4 个任务工具执行失败。任务 1~3 包含两次 LLM 调用共消耗 8,000 token。从任务 4 重试任务 1~3不重新执行它们的输出包括 LLM 响应从存储中直接复用只有任务 4及其后续任务重新执行每次重试节省 8,000 token。3. 从指定任务重跑Rerun from a Specific Task当你修复了某个任务定义中的 bug并从该任务重跑rerun时它之前的所有任务都保留各自的持久化输出。上游的 LLM 调用不会重新执行——这非常适合改一处、验证一处的调试循环。4. 循环断点与重试边界Loop Checkpointing and the Retry BoundaryAgent 循环DO_WHILE对每一次迭代都做断点checkpoint。如果基础设施在 Agent 运行到 50 次迭代中的第 48 次时恢复第 1~47 次迭代连同其全部 LLM 调用和工具结果都已持久化只有第 48 次迭代重新执行节省 47 次迭代的 LLM token。需要特别区分重试一个失败的DO_WHILE会从第 1 次迭代重新开始该循环的迭代历史。因此要保证工具幂等idempotent、为循环设定边界并保留重启动所需的上下文让重启是安全的。这正是 持久化执行语义 中at-least-once 投递所隐含的工程约束。真实世界的成本影响下面是基于典型 LLM 定价的具体估算原文表格完整引用场景无持久化使用 Conductor节省20 步 Agent第 18 步崩溃重跑全部 20 步约 40K token从第 18 步恢复约 4K token约 36K token$0.04-$0.40RAG 流水线在 PDF 生成步骤失败重跑 embedding LLM约 12K token只重试 PDF 步骤0 次 LLM 调用约 12K token$0.01-$0.12100 次迭代循环第 95 次崩溃重跑全部 100 次约 200K token从第 95 次恢复约 10K token约 190K token$0.19-$1.90带人工审批的 Agent审批人响应慢进程可能超时并重启HUMAN 任务无限期持久化全部上游 token 得以保留以上是单次执行级别的节省。乘以每天数千次执行成本差异就会非常显著。在规模化场景下——每天数千次 Agent 执行——即使只有 5% 的崩溃/重试率在没有持久化的情况下也会造成可观的 token 浪费而使用 Conductor 后这类浪费趋近于零。崩溃之外的 Token 节省持久化执行在以下场景中同样避免 token 浪费带人工介入human-in-the-loop的长期 Agent。一个 HUMAN 任务可以让工作流暂停数小时甚至数天。没有持久化时进程可能超时或被杀死导致整体重启并重跑所有上游 LLM 调用而 Conductor 的暂停是持久的——工作流从停止处精确恢复所有 LLM 输出都被保留。部署与扩缩容。当你部署新版本的 Worker 或缩容实例时进行中的工作流得以存活没有 LLM 调用丢失。没有持久化时扩缩容事件可能在执行中途杀死进程浪费迄今消耗的所有 token。调试与迭代。调试失败的 Agent 时你可以直接检查每一条 LLM prompt 和响应而无需重跑 Agent也可以从某个指定任务重跑来验证修复而不必重新执行并重新付费上游 LLM 调用。机械原理LLM 输出是如何被持久化的Conductor 持久化 LLM 任务输出的方式与持久化任何任务输出完全一致官方文档将其归纳为四步LLM_CHAT_COMPLETE任务被调度由 Worker或服务器自身执行收到 LLM 响应——prompt、补全内容、token 用量、模型、延迟全部被记录任务进入COMPLETED其输出在下一个任务被调度之前写入持久化存储此后若发生任何故障LLM 输出已经持久化绝不重新执行。仓库源码可以印证这一机制系统任务 Worker LLMWorkers.java 中WorkerTask(LLM_CHAT_COMPLETE)将ChatCompletion请求交给LLMs.chatComplete(...)处理在 LLMHelper.java 的chatComplete方法中响应被封装为LLMResponse其中completionTokens、promptTokens、tokenUsed三个字段来自ChatResponseMetadata.getUsage()——即 provider 返回的真实计费数据同一方法内还会构建一条TokenUsageLog包含taskId、api、integrationName、promptTokens、completionTokens、totalTokens通过tokenUsageLogger输出默认以 INFO 日志记录见 LLMs.java 中的默认实现方便你核算每次调用的成本这些 token 统计最终作为任务输出的一部分tokenUsed/promptTokens/completionTokens见 LLMResponse.java随任务一起写入持久化存储——这正是崩溃后读取输出、无需重跑的数据基础。这与 Conductor 对所有任务通用的持久化执行语义是同一套模型每个任务的状态机SCHEDULED → IN_PROGRESS → COMPLETED以及FAILED/TIMED_OUT后的重试回环中每一次状态迁移都会在采取后续动作之前被持久化。任务执行记录包含状态、输入、输出、时间戳、重试次数和 Worker ID工作流执行则持久化定义快照、工作流状态、任务队列状态全部写入配置的持久化存储Redis、PostgreSQL、MySQL 或 Cassandra服务器重启后从最后持久化状态恢复。持久化执行减少重复工作的边界已完成任务的输出在基础设施恢复、暂停和任务级重试期间始终可用因此当后续任务失败、Agent 等待审批、或操作员从指定任务重跑时上游 LLM 调用都不必重复。但这不是任何调用都永不重跑的保证。Conductor 采用 at-least-once 投递Worker 崩溃但副作用已发生时任务会被重新投递给其他 Worker 再次执行重试失败的DO_WHILE会重新开始该循环的迭代历史。因此请让工具幂等并有意识地选择重试边界。与此相关的超时与重试参数可在每个任务的任务定义中配置它们是持久化语义的调优旋钮参数控制内容timeoutSeconds任务到达终态的最大墙钟时间responseTimeoutSecondsWorker 状态更新前的最长等待时间超时则重新入队pollTimeoutSeconds已调度任务等待被 poll 的最长时间retryCount失败或超时时的重试次数retryLogicFIXED、EXPONENTIAL_BACKOFF或LINEAR_BACKOFFretryDelaySeconds重试之间的基础延迟timeoutPolicyRETRY、TIME_OUT_WF或ALERT_ONLY其中responseTimeoutSeconds直接决定了Worker 轮询到任务但未响应时任务多久回到SCHEDULED重新投递对应持久化执行语义中的 redelivery 机制。实践建议与下一步要让 token 节省真正落地建议在工程上做到三点一是 Worker 实现幂等容忍 at-least-once 投递下的重复执行二是依赖 Conductor 的重试、超时与重新入队机制不在业务代码里自建重试逻辑三是在设计DO_WHILE等循环时设置迭代边界并保留重启所需上下文。结合 LLM 编排 中 14 个原生 LLM Provider、向量数据库与内容生成任务以及LLM_CHAT_COMPLETE的webSearch、codeInterpreter、thinkingTokenLimit等能力配置字段定义见 ChatCompletion.java你可以构建既强大又省钱的持久化 Agent。继续深入阅读持久化执行语义Durable Execution Semantics —— 什么会被持久化、什么会被重试、恢复如何影响重复工作以及完整的失败矩阵、任务状态机与 Replay/Recovery 操作Restart / Rerun / Retry构建你的第一个 Agent 工作流图 —— 用 SDK 编写带内置持久化执行的 Agent持久化自适应图Durable Adaptive Graphs —— 构建有界扇出与显式恢复控制的受治理循环LLM 编排 —— 原生 LLM Provider、向量数据库与内容生成。【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考