Conductor 如何减少 Agent 工作流的重复 LLM 调用与 Token 成本【免费下载链接】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/conductorAgent 工作流跑一次要经过多次 LLM 调用一次崩溃或一次重试就可能让前面几十次调用全部重跑Token 费用被重复支付一遍。Conductor事件驱动的 Agent 工作流引擎通过持久化执行durable execution解决这个问题每次 LLM 调用完成后prompt、响应、token 用量和模型名都会写入持久化存储之后无论进程崩溃、部署重启还是任务重试已完成的 LLM 调用不会被重新执行输出直接从存储读取。适用前提是工作流跑在 Conductor 上持久化存储已配置Redis、PostgreSQL、MySQL 或 Cassandra。机制LLM 输出何时落盘Conductor 对 LLM 任务的持久化和普通任务一致见 docs/devguide/ai/token-efficiency.mdLLM_CHAT_COMPLETE任务被调度由 worker 或 server 本身执行收到 LLM 响应后prompt、completion、token usage、model 和 latency 全部记录任务进入COMPLETED其输出在下一个任务被调度之前写入持久化存储此后任何环节失败该 LLM 输出都已落盘不会被重新执行。AI 任务含LLM_CHAT_COMPLETE、LLM_TEXT_COMPLETE由ai模块注册需要conductor.integrations.ai.enabledtrue并配置好 LLM provider详见 AI Tasks 参考。四类省 Token 的场景以下四类场景的共同点上游已完成的 LLM 任务输出被复用只有未完成或失败的那一步重跑来源docs/devguide/ai/token-efficiency.md。1. 崩溃恢复Server、worker 或网络故障发生后已完成的 LLM 调用永不重跑输出从存储读取只有正在进行中的那一次调用被重试且仅此一次工作流从最后持久化的状态恢复。文档中的例子一个 20 步的 Agent 循环在第 18 步崩溃。没有持久化时第 1–17 步要整体重跑17 次 LLM 调用原样重算在 Conductor 上工作流从第 18 步恢复前 17 步的 LLM 输出、工具结果和状态都已在存储中。2. 从失败任务重试如果工作流在某一步失败例如 LLM 规划成功后工具调用报错可以对该工作流执行 retry之前所有已完成任务包括其中的 LLM 调用的输出全部复用只有失败任务及其之后的任务重跑。文档示例一个 5 任务的工作流在第 4 个任务失败前 3 个任务中的两次 LLM 调用共消耗 8,000 tokens从第 4 个任务重试后这部分 token 不需要再付。对应操作是 Workflow API 的 retry 端点见 Workflow APIcurl -X POST http://localhost:8080/api/workflow/3a5b8c2d.../retry{workflowId}替换为你要重试的执行 ID可选参数resumeSubworkflowTasks默认false控制是否同时恢复失败的子工作流任务。3. 修复后从指定任务重跑改了某个任务的定义、验证修复逻辑时用 rerun 从该任务开始重跑它之前的任务保留已持久化的输出上游 LLM 调用不会重算curl -X POST http://localhost:8080/api/workflow/3a5b8c2d.../rerun \ -H Content-Type: application/json \ -d { reRunFromWorkflowId: 3a5b8c2d..., workflowInput: {orderId: ORD-999}, reRunFromTaskId: task-uuid, taskInput: {override: true} }其中reRunFromTaskId指定从哪个任务 ID 开始重跑workflowInput是新的工作流入参taskInput用于覆盖该任务的输入——以上值均为文档示例按实际执行替换。注意 rerun 会创建一个新的执行新执行上带有reRunFromWorkflowId字段指回原执行而非原地修改原执行。4. DO_WHILE 循环的迭代检查点Agent 循环DO_WHILE每次迭代都会做检查点。若工作流在第 48 次迭代共 50 次时基础设施恢复第 1–47 次迭代及其全部 LLM 调用和工具结果已在存储中只有第 48 次迭代重跑。但有一个边界要分清重试一个失败的DO_WHILE任务时该循环的迭代历史会从第 1 次迭代重新开始。所以文档的建议是保持工具幂等、给循环设上限、并保留让这次重启保持安全的上下文。文档给出的成本对比token-efficiency 文档用典型 LLM 价格给出的一组示例数字这是文档示例不是固定预期值场景无持久化有 Conductor节省20 步 Agent第 18 步崩溃重跑全部 20 步~40K tokens从第 18 步恢复~4K tokens~36K tokens$0.04–$0.40RAG 管线在 PDF 生成失败重跑 embedding LLM~12K tokens只重试 PDF 步骤0 LLM tokens~12K tokens$0.01–$0.12100 次迭代循环第 95 次崩溃重跑全部 100 次~200K tokens从第 95 次恢复~10K tokens~190K tokens$0.19–$1.90含人工审批的 Agent审批人慢进程可能超时重启HUMAN 任务无限期持久上游 token 全部保留这些是单次执行的节省文档指出按每天数千次执行放大后差异会显著。除崩溃外持久化还覆盖两类不重算 token 的情况HUMAN 任务可暂停工作流数小时甚至数天期间进程超时或被杀不会导致上游 LLM 调用重跑部署与扩缩容时进行中的工作流存活正在消费的 LLM token 不丢失。验证确认 LLM 输出来自存储而非重跑用 Workflow API 检查执行与任务状态见 Workflow API# 查看执行整体状态与失败信息 curl http://localhost:8080/api/workflow/3a5b8c2d-1234-5678-9abc-def012345678 # 查看该执行的所有任务 curl http://localhost:8080/api/workflow/3a5b8c2d-1234-5678-9abc-def012345678/tasks?count10 # 只看失败任务 curl http://localhost:8080/api/workflow/3a5b8c2d-1234-5678-9abc-def012345678/tasks?statusFAILED判断依据来自 durable execution 文档每个任务执行的状态、输入、输出、时间戳和 retry count 都被持久化重启后执行从最后持久化状态恢复失败矩阵中worker 崩溃由 response timeout 触发重投递worker 报 FAILED 时按retryCount、retryDelaySeconds、retryLogic创建新的任务执行——重试只针对未完成任务调试失败 Agent 时可以检查每一次 LLM prompt 和响应而无需重跑文档明确说Nothing upstream. Only the failed LLM call retries. All previously completed tasks retain their outputs见 failure-semantics.md。LLM 调用自身的 token 用量promptTokens、completionTokens、totalTokens在 ai 模块执行时会记录并输出到日志可参考 LLMHelper.java。限制这不是永不重复调用的保证Conductor 是at-least-once 投递worker 在产生副作用后、上报完成前崩溃时任务会被重投递并再次执行因此 worker 必须对副作用保持幂等或用任务的updateTime检测重投递重试失败的DO_WHILE会重置该循环的迭代历史从第 1 次迭代重新开始因此要有意选择重试边界并保持工具幂等durable execution 文档。相关文档Durable Execution Semantics什么会被持久化、at-least-once 投递、失败矩阵、Restart/Rerun/Retry 三种恢复操作的区别Failure semantics for AI agentsLLM 调用失败、输出畸形、工具超时等场景下的精确行为LLM orchestrationLLM_CHAT_COMPLETE的 provider 支持与任务输入配置Token efficiency with durable execution本文省 Token 场景的完整原文。【免费下载链接】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），仅供参考 Conductor 如何减少 Agent 工作流的重复 LLM 调用与 Token 成本？
Conductor 如何减少 Agent 工作流的重复 LLM 调用与 Token 成本【免费下载链接】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/conductorAgent 工作流跑一次要经过多次 LLM 调用一次崩溃或一次重试就可能让前面几十次调用全部重跑Token 费用被重复支付一遍。Conductor事件驱动的 Agent 工作流引擎通过持久化执行durable execution解决这个问题每次 LLM 调用完成后prompt、响应、token 用量和模型名都会写入持久化存储之后无论进程崩溃、部署重启还是任务重试已完成的 LLM 调用不会被重新执行输出直接从存储读取。适用前提是工作流跑在 Conductor 上持久化存储已配置Redis、PostgreSQL、MySQL 或 Cassandra。机制LLM 输出何时落盘Conductor 对 LLM 任务的持久化和普通任务一致见 docs/devguide/ai/token-efficiency.mdLLM_CHAT_COMPLETE任务被调度由 worker 或 server 本身执行收到 LLM 响应后prompt、completion、token usage、model 和 latency 全部记录任务进入COMPLETED其输出在下一个任务被调度之前写入持久化存储此后任何环节失败该 LLM 输出都已落盘不会被重新执行。AI 任务含LLM_CHAT_COMPLETE、LLM_TEXT_COMPLETE由ai模块注册需要conductor.integrations.ai.enabledtrue并配置好 LLM provider详见 AI Tasks 参考。四类省 Token 的场景以下四类场景的共同点上游已完成的 LLM 任务输出被复用只有未完成或失败的那一步重跑来源docs/devguide/ai/token-efficiency.md。1. 崩溃恢复Server、worker 或网络故障发生后已完成的 LLM 调用永不重跑输出从存储读取只有正在进行中的那一次调用被重试且仅此一次工作流从最后持久化的状态恢复。文档中的例子一个 20 步的 Agent 循环在第 18 步崩溃。没有持久化时第 1–17 步要整体重跑17 次 LLM 调用原样重算在 Conductor 上工作流从第 18 步恢复前 17 步的 LLM 输出、工具结果和状态都已在存储中。2. 从失败任务重试如果工作流在某一步失败例如 LLM 规划成功后工具调用报错可以对该工作流执行 retry之前所有已完成任务包括其中的 LLM 调用的输出全部复用只有失败任务及其之后的任务重跑。文档示例一个 5 任务的工作流在第 4 个任务失败前 3 个任务中的两次 LLM 调用共消耗 8,000 tokens从第 4 个任务重试后这部分 token 不需要再付。对应操作是 Workflow API 的 retry 端点见 Workflow APIcurl -X POST http://localhost:8080/api/workflow/3a5b8c2d.../retry{workflowId}替换为你要重试的执行 ID可选参数resumeSubworkflowTasks默认false控制是否同时恢复失败的子工作流任务。3. 修复后从指定任务重跑改了某个任务的定义、验证修复逻辑时用 rerun 从该任务开始重跑它之前的任务保留已持久化的输出上游 LLM 调用不会重算curl -X POST http://localhost:8080/api/workflow/3a5b8c2d.../rerun \ -H Content-Type: application/json \ -d { reRunFromWorkflowId: 3a5b8c2d..., workflowInput: {orderId: ORD-999}, reRunFromTaskId: task-uuid, taskInput: {override: true} }其中reRunFromTaskId指定从哪个任务 ID 开始重跑workflowInput是新的工作流入参taskInput用于覆盖该任务的输入——以上值均为文档示例按实际执行替换。注意 rerun 会创建一个新的执行新执行上带有reRunFromWorkflowId字段指回原执行而非原地修改原执行。4. DO_WHILE 循环的迭代检查点Agent 循环DO_WHILE每次迭代都会做检查点。若工作流在第 48 次迭代共 50 次时基础设施恢复第 1–47 次迭代及其全部 LLM 调用和工具结果已在存储中只有第 48 次迭代重跑。但有一个边界要分清重试一个失败的DO_WHILE任务时该循环的迭代历史会从第 1 次迭代重新开始。所以文档的建议是保持工具幂等、给循环设上限、并保留让这次重启保持安全的上下文。文档给出的成本对比token-efficiency 文档用典型 LLM 价格给出的一组示例数字这是文档示例不是固定预期值场景无持久化有 Conductor节省20 步 Agent第 18 步崩溃重跑全部 20 步~40K tokens从第 18 步恢复~4K tokens~36K tokens$0.04–$0.40RAG 管线在 PDF 生成失败重跑 embedding LLM~12K tokens只重试 PDF 步骤0 LLM tokens~12K tokens$0.01–$0.12100 次迭代循环第 95 次崩溃重跑全部 100 次~200K tokens从第 95 次恢复~10K tokens~190K tokens$0.19–$1.90含人工审批的 Agent审批人慢进程可能超时重启HUMAN 任务无限期持久上游 token 全部保留这些是单次执行的节省文档指出按每天数千次执行放大后差异会显著。除崩溃外持久化还覆盖两类不重算 token 的情况HUMAN 任务可暂停工作流数小时甚至数天期间进程超时或被杀不会导致上游 LLM 调用重跑部署与扩缩容时进行中的工作流存活正在消费的 LLM token 不丢失。验证确认 LLM 输出来自存储而非重跑用 Workflow API 检查执行与任务状态见 Workflow API# 查看执行整体状态与失败信息 curl http://localhost:8080/api/workflow/3a5b8c2d-1234-5678-9abc-def012345678 # 查看该执行的所有任务 curl http://localhost:8080/api/workflow/3a5b8c2d-1234-5678-9abc-def012345678/tasks?count10 # 只看失败任务 curl http://localhost:8080/api/workflow/3a5b8c2d-1234-5678-9abc-def012345678/tasks?statusFAILED判断依据来自 durable execution 文档每个任务执行的状态、输入、输出、时间戳和 retry count 都被持久化重启后执行从最后持久化状态恢复失败矩阵中worker 崩溃由 response timeout 触发重投递worker 报 FAILED 时按retryCount、retryDelaySeconds、retryLogic创建新的任务执行——重试只针对未完成任务调试失败 Agent 时可以检查每一次 LLM prompt 和响应而无需重跑文档明确说Nothing upstream. Only the failed LLM call retries. All previously completed tasks retain their outputs见 failure-semantics.md。LLM 调用自身的 token 用量promptTokens、completionTokens、totalTokens在 ai 模块执行时会记录并输出到日志可参考 LLMHelper.java。限制这不是永不重复调用的保证Conductor 是at-least-once 投递worker 在产生副作用后、上报完成前崩溃时任务会被重投递并再次执行因此 worker 必须对副作用保持幂等或用任务的updateTime检测重投递重试失败的DO_WHILE会重置该循环的迭代历史从第 1 次迭代重新开始因此要有意选择重试边界并保持工具幂等durable execution 文档。相关文档Durable Execution Semantics什么会被持久化、at-least-once 投递、失败矩阵、Restart/Rerun/Retry 三种恢复操作的区别Failure semantics for AI agentsLLM 调用失败、输出畸形、工具超时等场景下的精确行为LLM orchestrationLLM_CHAT_COMPLETE的 provider 支持与任务输入配置Token efficiency with durable execution本文省 Token 场景的完整原文。【免费下载链接】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），仅供参考