用 LangGraph interrupts 设计营销文案审阅交接

如何用 LangGraph interrupts 设计营销文案审阅交接？

一份 AI 活动文案交给下一个团队前，审阅者要能看到完整稿件，也要知道批准后允许进行什么操作。如果稿件还能在后台改变，界面上有一个“批准”按钮并不能解决版本问题。

LangGraph 提供按图组织的工作流执行机制。它的 interrupts 文档 说明，中断会暂停执行，等待外部输入，并通过 checkpointer 保存工作流状态。Checkpointer 是保存状态的组件，生产环境需要使用能持久保存状态的版本。这为流程等待人工决定提供了技术基础，但不是一套现成的营销审批系统。

设计交接时，应把审阅者看到的版本、提交的决定，以及交给指定下一步的版本连起来。下面的建议以这一机制为基础。

AI 营销文案审核流程，先把受审稿件保存下来

建议在进入专门的审阅节点前，保存原始草稿和拟议操作。节点是工作流执行的一个单位。中断可以向调用端暴露可序列化为 JSON 的数据；文档中的 review-and-edit 模式允许人在继续执行前检查并修改模型输出或工具调用。可序列化为 JSON，意味着信息能表示为结构化文字、对象或列表。

以活动社媒文案为例，审阅数据应带有版本标识，展示完整内容、目标市场、渠道和拟议下一步。附上来源链接，直接标出尚未确认的声明，避免审阅者还要去另一段对话里找。交接记录也应注明由谁负责审阅。

在稿件旁放一份短清单，检查具体内容：

• 事实： 产品信息、价格和活动条件是否有依据，是否仍然有效？
• 品牌： 措辞是否符合已确认的语气和定位？
• 来源与使用权： 证据能否重新打开，拟议用途是否获准？网页公开可见，不代表其中的文字或图片可以转载。
• 表达： 比较、最高级和含糊承诺是否有依据？
• 最终版本： 决定是否明确指向获批内容及下一步？

这些是本方案建议的检查项，不是 LangGraph 内置的营销功能。

批准、拒绝和修改，分别进入不同分支

建议要求明确的决定字段：approve、reject 或 revise，同时提交受审版本标识、需要时的修改内容及理由。记录决定由谁作出，再检查应用规则：审阅者是否有批准权限、版本是否仍然匹配，以及是否还有阻止通过的未确认声明。

批准应把确切的获批版本交给约定的下一步；拒绝应取消拟议操作，同时保留记录；修改应保存新版本，再交回审阅。不能因为有人改了文字，就把新稿自动视为已批准。

假设一份虚构的 v1 草稿写着：“每位顾客的最佳护肤选择。”如果没有证据支持比较和适用于所有人的承诺，审阅者可以删掉这句，把 v2 改为“探索我们的护肤系列”。这次提交的决定是 revise，并附上理由。V2 还要对照活动需求简报检查；删掉一项无依据声明，不等于批准了替换后的内容。

MIA 的 Cowork 人工审阅节点设计 描述可检查的交接，以及等待人审阅、修改或批准的步骤，可帮助团队思考在哪一步保留控制权。这是另一项产品的设计，不是与 LangGraph 已集成的证据；访问权限、保留期和部署控制仍须按具体部署确认。

有输入格式，还要有真正的决定校验

文档要求 langgraph>=1.2.12 才能使用中断响应结构描述。受支持的类型结构——Pydantic model、来自 typing_extensions 的 TypedDict 或 dataclass——会按 Pydantic 的验证和类型转换规则检查恢复输入。无效输入会触发 pydantic.ValidationError，可以修正后在同一个 thread 上重试。

直接传入 JSON Schema 字典，只会向调用端展示结构，不会让 LangGraph 据此验证恢复输入。省略 response_schema 也不会进行这项结构校验。

类型校验通过，不代表文案里的声明真实，也不代表审阅者批准的仍是当前版本。内容、审批权限和版本校验，需要另外写进应用规则。

恢复会从节点开头重跑，不是从暂停行接着走

恢复时使用 Command(resume=...)，并沿用中断时的 thread ID，也就是本次工作流的标识。提交的响应会成为中断调用的返回值。

恢复时，中断所在节点会从头执行，interrupt() 之前的代码会再次运行。不要把重新生成受审稿件或外部操作放在中断前，然后假设它只执行一次。建议让审阅节点只读取已保存的提案，不改动内容，并单独设计针对重复写入和后续操作的防护。暂停与恢复本身不保证操作严格只执行一次。

实施前，与工程团队明确审阅记录、三种决定各自的结果，以及哪些操作会受重跑影响。交接规格应能回答“谁审了哪个版本，这项决定允许下一步做什么”，而不是停留在界面上增加了一个批准按钮。