AI工作流中的缓存和重试有什么用
缓存让 AI 工作流减少重复计算、保留证据并支持失败后继续；重试要区分短暂故障和永久故障，并配合退避、抖动、限次和幂等 key。
很多团队第一次搭 AI 工作流时，关注点会放在模型、提示词、工具调用和最终输出上。只要一次演示能跑通，就觉得流程已经差不多了。
实际上线后，问题往往出在更朴素的地方：同一个文件被反复解析，搜索结果每次都重新拉取，模型请求偶尔超时，某个 API 返回 429，图片生成有时很慢，网络中断后任务只能重来，用户重复点击导致同一动作执行两次。
缓存和重试，就是用来处理这些“不够漂亮但经常发生”的问题。
缓存不是偷懒，而是把已经算过、查过、验证过的中间结果保存起来，避免重复消耗。重试也不是盲目多试几次，而是对短暂故障做有限、可控、可追踪的再次尝试。两者配合得好，AI 工作流会更省成本、更稳定，也更容易从失败处继续。
这篇文章面向工程团队，讲清楚 AI 工作流里缓存和重试分别解决什么问题、哪里容易出错，以及如何做一份可落地的实施清单。
为什么 AI 工作流更需要缓存
传统系统里，缓存常用于减少数据库查询、加快页面响应、降低后端压力。AI 工作流也需要这些，但还多了几个特殊原因。
第一，模型调用通常有成本。长上下文、工具结果、图片输入、多轮对话和复杂推理都会消耗 token 或计算额度。如果一个工作流每次都从头把相同系统提示词、规则、长文档和示例重新送进去，成本会被重复放大。
第二，AI 工作流经常依赖外部资料。比如网页搜索、代码仓库、PDF、视频转写、数据库查询、截图分析。外部资料获取慢、易失败、也可能变化。把“本轮任务使用过的来源、版本、抓取时间和解析结果”保存下来，可以让结果更可追溯。
第三，长任务需要可继续。一个研究报告、视频脚本、批量图片、邮件整理或多 Agent 协作任务，可能要跑十几分钟甚至更久。如果中途失败，没有缓存和中间产物，任务只能从头开始。对用户来说，这不是技术细节，而是体验崩掉。
第四，缓存能帮助复核。保存中间结果后，审稿人可以看到文章依据了哪些网页、哪一版文档、哪一次工具输出，而不是只看到最后一段流畅文字。
OpenAI 的 Prompt Caching 文档提到，模型提示词常包含重复内容，例如系统提示词和通用指令；对于相同前缀，Prompt Caching 可以降低延迟和输入成本。这个机制是平台层面的缓存。工程团队还需要在自己的应用层做缓存：保存搜索结果、解析结果、工具输出、结构化中间结果和生成产物。
缓存不只是一份结果
AI 工作流里的缓存可以分成四类。
第一类是输入缓存。比如文档解析后的纯文本、PDF 页码映射、音频转写、图片 OCR、网页抓取内容。它的价值是避免重复读同一个材料。
第二类是上下文缓存。比如固定系统指令、业务规则、术语表、示例、角色设定、工具 schema。这类内容变化慢，适合放在 prompt 前缀或应用缓存里。
第三类是工具输出缓存。比如搜索 API 返回、代码执行结果、数据库查询结果、向量检索结果、网页摘要。它的价值是把“外部世界的一次观察”固定下来，便于复核。
第四类是产物缓存。比如已经生成的文章段落、表格、图片、PPT 页面、音频片段、审核结论。它的价值是让任务可以分段交付，也能在失败后从最近的成功节点继续。
不同缓存的失效规则不一样。文档解析缓存可以跟文件 hash 绑定；网页抓取缓存要记录 URL、抓取时间和版本；模型输出缓存要记录模型、提示词版本、温度、工具版本和输入摘要；用户权限相关结果要按用户和权限范围隔离。
如果把所有缓存都当成“只要命中就用”，会埋下新问题。缓存过旧，会让文章引用过时资料；缓存粒度过粗，会把 A 用户结果暴露给 B 用户；缓存 key 设计不清，会把不同模型、不同提示词、不同工具版本的结果混在一起。
缓存的目标不是永远复用，而是知道什么时候可以复用、什么时候必须重新计算。
重试解决的是短暂故障
重试听起来简单：失败了，再来一次。但工程里的重试必须先分清错误类型。
短暂故障适合重试，比如网络抖动、临时超时、服务忙、429 限流、上游短暂不可用。永久故障不适合重试，比如参数错误、权限不足、文件不存在、输入格式不符合要求、业务规则拒绝。
AWS Well-Architected 的可靠性建议强调，重试应使用指数退避、加入 jitter，并限制最大重试次数。AWS Prescriptive Guidance 也提醒，频繁重试可能占用网络带宽并让服务降级；如果不是短暂错误，应更快停止并返回失败。
换到 AI 工作流，就是不要看到失败就一直重试。比如：
1. 模型服务返回 429，可以等待后重试。 2. 图片生成超时，可以按单图重试，而不是整篇重来。 3. 网页抓取失败，可以换备用源或稍后再试。 4. 用户没有权限访问某个文件，重试没有意义，应提示补权限。 5. 提示词让模型输出 JSON，但 schema 设计错误，重试只会浪费成本，应修正输入。
重试的价值，是把短暂故障从用户面前吸收掉；重试的风险，是把小故障放大成请求风暴。
重试必须配合幂等
只要一个步骤会产生副作用，就不能随便重试。副作用包括：发邮件、扣费、创建记录、写数据库、发布文章、上传文件、触发审批、调用外部自动化。
Stripe 的 idempotent requests 文档说明，幂等键可以让客户端在连接错误后重复请求，而不会意外创建第二个对象或执行第二次更新。Stripe 还说明，POST 请求可以使用 idempotency key，GET 和 DELETE 按定义具有幂等性。
AI 工作流同样需要幂等思想。比如自动发布系统中，“上传图片”可以用内容 hash 做 key；“创建文章”可以用 article_id 和 slug 做 key；“发送通知”可以用任务 ID 和通知类型做 key；“写入审核结果”可以用文章 ID、审核阶段和版本号做 key。
幂等不是只给支付系统用的。任何会改变外部状态的 AI 自动化步骤，都应该想清楚：如果网络断了，我不知道上一次是否成功，下一次请求会不会重复执行？
如果答案不清楚，就不要自动重试。先把步骤拆开：读取、生成、复核、提交、通知分别记录。让可重试的步骤留在安全区，让有副作用的步骤带上唯一 key 和审计记录。
缓存和重试要一起设计
缓存和重试不是两个孤立功能。一个可靠的 AI 工作流，通常会同时需要它们。
举个例子：用户要把 10 篇官方文档整理成一篇中文长文。
第一步，抓取网页。每个 URL 抓取后保存原文、时间、状态码和正文 hash。抓取失败时，短暂网络错误可以重试；404 或权限错误不要重试。
第二步，解析正文。解析结果按 URL、正文 hash、解析器版本缓存。文档没变，就不必重新解析。
第三步，生成大纲。大纲缓存要绑定模型、提示词版本、资料列表和目标读者。如果提示词改了，大纲要重新生成。
第四步，生成正文。每一节可以独立缓存，失败时只重试失败章节。这样不会因为一节出错而重做全部内容。
第五步，事实核验。核验结果要保存来源、结论、疑点和人工处理记录。它不能被长期盲用，因为来源会变化。
第六步，发布。发布是副作用步骤，必须带唯一 slug、版本号和 dry-run 记录。失败后重试时，要先查询是否已经创建，不要重复发布。
这个例子里，缓存降低了重复计算，重试吸收了短暂失败，幂等保护了副作用步骤，日志让人能复盘。
不要缓存这些东西
缓存有边界。
第一，不要缓存敏感凭据。token、cookie、SSH key、客户隐私、未脱敏文件路径、临时授权链接，都不应进入普通缓存。
第二，不要跨权限复用结果。A 用户能看的文件，B 用户未必能看。AI 工作流如果把 A 的检索结果缓存成全局结果，可能造成数据越权。
第三，不要缓存未标注来源的事实判断。比如“某 API 已废弃”“某产品支持某功能”这类事实，应记录来源和日期。没有来源的判断很难复核。
第四，不要把错误结果永久缓存。模型输出格式错了、工具返回半截数据、网页抓取被反爬页面替代，都要标成失败或低可信缓存。
第五，不要把随机生成的创意结果当成唯一答案长期复用。创意产物可以缓存为版本，但不应妨碍用户重新生成。
缓存是一种工程加速手段，不是事实权威。缓存条目应该带上状态、来源、时间、版本和失效策略。
失败恢复要有节点
Temporal 文档把 Workflow Execution 描述为 durable、reliable、scalable 的执行单元，并说明 Workflow Execution 的状态会持久化，失败后可以从最近状态继续。它的 Activity Execution 也支持自定义 timeouts 和 retry policies。
不管你是否使用 Temporal，这个思想都很适合 AI 工作流：长任务要拆成可记录的节点。
比如：
1. input_collected：输入已收集。 2. sources_fetched：来源已抓取。 3. sources_parsed：来源已解析。 4. outline_generated：大纲已生成。 5. draft_generated：初稿已生成。 6. review_completed：复核已完成。 7. assets_generated：图片或附件已生成。 8. dry_run_passed：预发布校验通过。 9. published：正式发布完成。
每个节点都要记录输入、输出、状态、耗时、错误和可重试策略。这样任务失败时，系统能知道应该从哪里继续，而不是把用户带回起点。
重试策略要写清楚
一份可维护的重试策略至少要包含七项。
第一，哪些错误可重试。比如 timeout、429、502、503、临时网络错误。
第二，哪些错误不可重试。比如权限不足、参数错误、文件不存在、schema 不兼容、人工拒绝。
第三，最大次数。不要无限重试。
第四，退避方式。优先指数退避，并加入随机抖动，避免多个任务同一时间再次冲击上游服务。
第五，总耗时上限。比如 5 分钟内最多重试 3 次，超过后进入待处理状态。
第六，幂等 key。任何会写外部状态的步骤，都要有唯一操作标识。
第七，人工接管条件。比如连续失败、成本超过阈值、来源冲突、权限错误、输出需要发布前复核。
这些内容最好写在配置里，而不是散落在代码里。这样团队可以调整策略，也能在故障复盘时看清楚系统为什么继续或停止。
缓存策略也要写清楚
缓存策略同样需要明确。
第一，缓存什么。输入、上下文、工具输出、产物分别列清楚。
第二，缓存 key 怎么生成。至少包含任务 ID、输入 hash、模型、提示词版本、工具版本、权限范围和来源版本。
第三，缓存多久。网页资料、模型输出、用户文件、公共文档的生命周期不一样。
第四，如何失效。文件变了、提示词变了、模型变了、来源更新了、权限变了，都要能触发重新计算。
第五，如何审计。缓存命中时，要记录命中哪个 key、用了哪个版本、是否跳过了外部请求。
第六，如何清理。临时缓存、长期证据、发布产物、失败样本要分层保存。
第七，如何保护隐私。敏感数据要脱敏、加密或不缓存。
缓存策略如果写清楚，团队就不会把缓存当成黑盒。用户也能理解为什么这次更快，为什么某一步要重新跑。
一张实施清单
工程团队可以从最小版本开始。
先给每个工作流加 task_id，并把步骤拆成可记录节点。然后为每个节点保存输入摘要、输出路径、状态、错误、耗时和重试次数。
再建立三层缓存：资料缓存、工具输出缓存、产物缓存。不要一上来做复杂分布式缓存；先把 key、版本和失效规则定清楚。
接着给外部调用加重试策略：限次、退避、抖动、超时、不可重试错误列表。模型调用、搜索、图片生成、文件上传、数据库写入要分开配置。
然后给副作用步骤加幂等 key。发布、发送、创建、写入、扣费、通知都属于副作用。没有幂等 key，就不要自动重试。
最后加一个人工接管队列。AI 工作流不应该把所有失败都藏起来。它应该告诉人：失败在哪一步，已经试了几次，缓存里有什么，下一步建议是什么。
结语：稳定性来自不起眼的工程细节
AI 工作流的亮点常常在模型输出，但长期体验来自工程细节。缓存让重复工作少一点，重试让短暂故障少打扰用户，幂等让副作用步骤更安全，节点记录让失败后可以继续。
好的缓存和重试设计，不会让系统变得复杂难懂。相反，它会让每一步更清楚：哪里可以复用，哪里必须重算，哪里可以再试，哪里应该停下等人处理。
当一个 AI 工作流开始处理真实资料、真实账号和真实发布动作时，缓存和重试就不是优化项，而是基础设施。它们决定了系统能不能从演示走向日常使用。