可恢复智能体架构：OpenAI Agents SDK 与 Temporal 实战
为什么恢复能力比演示效果重要
Bringing Resilience to Agents: OpenAI Agents SDK + Temporal 这个主题最值得提炼的不是视频里的每一个操作，而是它背后的使用场景：什么时候应该引入 可恢复智能体，什么时候只需要一个普通提示词或脚本。本文会把它改写成一篇可以直接执行的教程，重点放在判断标准、落地步骤和检查方法上。
如果你只记住一个原则，那就是先让流程可验证，再追求自动化程度。不可验证的 AI 输出越长，后期返工成本越高；可验证的中间产物即使很朴素，也能慢慢演化成稳定系统。
Temporal 和 Agents SDK 的分工
这个主题适合用在三类任务里。第一类是输入材料明确、输出格式稳定的任务，比如整理文档、生成代码改动、分类客户反馈。第二类是需要工具参与的任务，比如读取文件、查询网页、写入 CMS 或运行测试。第三类是需要人机协作的任务，比如先让 AI 生成草稿，再由人确认后发布。
不建议一开始就处理高风险动作。删除数据、发送正式消息、修改权限、创建订单、执行付款，都应该保留人工确认。把边界写在任务说明里，是降低风险的第一步。
把不稳定动作移出 workflow
- 把 workflow 当作状态机，只负责顺序和恢复
- 把模型调用、数据库写入、截图上传等不稳定动作放进 activity
- 为每个外部写入设计幂等键
- 把人工确认做成 signal，而不是内存里的等待
- 用事件历史定位失败发生在哪一步
这些步骤不要求一次做完。真正稳定的做法，是先拿一个小任务跑通，再把成功流程保存下来。下次遇到类似任务时，复用的是流程结构，而不是某一句固定提示词。
幂等、重试和人工确认
以 Bringing Resilience to Agents: OpenAI Agents SDK + Temporal 为例，可以把任务拆成一个很小的闭环：先定义目标，再准备输入，再限制工具，最后设计验收。比如你想把一个开发需求交给 AI，不要说“帮我实现这个功能”，而是写成“读取这几个文件，解释当前行为，只修改目标组件，完成后运行类型检查，并列出无法自动验证的风险”。
这个闭环里，每一步都有可观察结果。解释当前行为可以暴露上下文是否读对；文件计划可以暴露范围是否过大；类型检查可以暴露语法和类型问题；风险列表可以提醒你哪些地方还需要人工判断。
内容发布智能体的架构样例
常见问题主要有三类：
- 在 workflow 里直接访问网络，破坏可重放性
- 重试没有幂等设计，造成重复发布或重复扣费
- 只关注成功路径，没有取消、超时和人工介入策略
修正这些问题的办法也很直接：缩小任务范围、减少工具权限、增加中间检查点。不要用“换一个更强模型”掩盖流程设计问题。模型能力越强，越需要清楚边界，否则它会更自信地走向错误方向。
生产检查项
你可以做一个 30 分钟练习：选一个真实但低风险的任务，先写任务卡片，再执行，再复盘。任务卡片至少包含五项：目标、输入、允许工具、禁止动作、验收标准。执行过程中保存计划、工具结果、最终产物和失败记录。
复盘时问自己三个问题：哪一步最容易被 AI 误解？哪一步最难验证？哪一步最值得沉淀成模板？这三个答案会告诉你下一次应该优化提示词、工具说明还是验收规则。
生产检查项的验收清单
- 这篇教程对应的任务是否能被一句话说明？
- 输入材料是否足够，缺失信息是否被列出？
- 工具权限是否保持最小化？
- 每一步是否有可检查的中间产物？
- 失败时是否知道回到哪一步？
- 最终输出是否能被人类快速审查？
Temporal 和 Agents SDK 的分工之后读什么
本文根据 Temporal 的视频主题整理并扩展，来源链接：https://www.youtube.com/watch?v=rSQ6WjPjoFo
后续可以继续阅读同标签下的文章，把 可恢复智能体 和相邻主题串起来看：概念文章帮助你判断边界，工具文章帮助你提高效率，架构文章帮助你把流程放到生产环境。
幂等、重试和人工确认的落地细节
可恢复架构的关键是区分“决策”和“副作用”。模型可以参与决策，但外部副作用必须被包进可重试、可记录、可幂等的 activity。这样即使模型调用超时、上传失败或人工审批延迟，系统也知道自己停在哪一步。
真正上线时，还要准备观察面板：当前 workflow 状态、最近失败 activity、重试次数、等待的 signal、外部写入 ID。没有这些信息，长任务一旦失败，就会回到人工猜测；有了这些信息，恢复路径会清楚很多。
内容发布智能体的架构样例：如何复盘
复盘时不要只问“结果能不能用”，还要记录输入是否充分、工具是否必要、失败是否可恢复、人工审查花了多久。把这些记录保留下来，下一次同类任务就有了改进依据。
如果某个错误重复出现两次，就不要继续靠人脑记忆修补，而是把它写进任务模板、工具说明或验证脚本。长期看，这比临时换模型更稳定。
可恢复执行的操作剧本
可以把「内容发布智能体」写成一张操作剧本，而不是临时聊天。第一行写目标：这次要交付什么具体结果。第二行写输入：需要哪些文件、字段、链接或上下文。第三行写工具：允许读取什么、允许写入什么、哪些动作必须停下来确认。第四行写验收：完成后用什么事实判断结果可用。
剧本写好后，再让 AI 执行。执行过程中不要急着追求最终答案，先看它是否理解了输入，是否按边界使用工具，是否能解释每一步为什么这么做。只要某一步无法解释，就回到剧本修改，而不是继续让模型补更多文字。
这类架构任务最重要的是把长流程拆成可恢复步骤。每个 activity 都要能独立失败、独立重试、独立记录结果；workflow 只保存顺序和状态。只要这个边界清楚，智能体就能从脚本演示走向生产系统。
Temporal 分工的决策表
建议把关键判断写成一个三列表：条件、动作、验证方式。例如条件是“资料不足”，动作就不是继续生成，而是列出缺失字段；条件是“需要改生产数据”，动作就是请求人工确认；条件是“测试失败”，动作是保留错误输出并回到上一轮修改。
这张表能把隐性的经验变成显性的规则。对个人来说，它能减少每次重新思考的成本；对团队来说，它能让不同成员用同一套边界审查 AI 输出。表格不需要复杂，关键是能在任务开始前约束行为，在任务结束后检查结果。
内容发布智能体的复用方式
第一次跑通之后，不要只保存最终结果。请同时保存原始输入、任务剧本、关键中间产物、验证结果和失败记录。下一次类似任务开始时，先复制这套材料，再替换输入。这样复用的是经过验证的流程，而不是某个容易失效的固定话术。
如果你要把它放进团队流程，可以增加两个字段：负责人和风险等级。负责人说明谁来确认高风险动作，风险等级说明哪些任务只能半自动执行。这样 AI 工作流会更像工程资产，而不是一次性技巧。
用内容发布智能体做小样本验证
正式采用这套方法前，请至少准备三个样本：一个正常样本、一个信息缺失样本、一个边界样本。正常样本用来确认主流程是否顺畅；信息缺失样本用来确认 AI 会不会编造；边界样本用来确认系统是否会停下来等待确认。三个样本都通过后，再逐步扩大到更多输入。
这个验证动作很小，但能有效区分“演示可用”和“长期可用”。如果某个样本失败，不要只改正文或提示词，而要判断失败属于输入、工具、流程还是验收问题。分类之后再修，质量会稳定很多。
把验证结果写回模板，是让下一篇文章、下一次开发任务、下一轮自动化都变得更好的关键。