用 LangGraph interrupts 設計行銷文案審閱交接

如何用 LangGraph interrupts 設計行銷文案審閱交接？

AI 寫好的活動文案要交給下一個團隊前，審閱者需要看到完整稿件，也要知道按下「批核」後允許進行哪一步。如果稿件還會在背後改動，只有一個批核按鈕並不足夠。

LangGraph 提供以圖組織的工作流程執行機制，當中的 interrupts 文件 說明：中斷會暫停執行，等待外部輸入，並透過 checkpointer 保存流程狀態。Checkpointer 是保存狀態的元件，正式運行環境需要使用可持久保存狀態的版本。這是讓流程停下來等人的技術基礎，不是一套現成的行銷批核系統。

審閱交接值得守住的原則，是把三件事連起來：審閱者看到的版本、他提交的決定，以及交給指定下一步的版本。以下是根據這項機制提出的設計建議。

AI 行銷文案審核流程，要先有可檢查的稿件

建議先保存原稿與擬議操作，再進入專門等待審閱的節點；節點就是流程執行的一個單位。中斷可以向呼叫端傳回可序列化為 JSON 的資料，文件也列出讓人檢查及修改模型輸出或工具呼叫的 review-and-edit 模式。這類資料可以用結構化文字、物件或清單表示。

以活動社媒文案為例，提交審閱的資料應標明版本，展示完整內容、目標市場、渠道及擬議下一步。附上來源連結，直接標出仍未確認的聲明，不要把它們藏在另一段對話中。交接紀錄也應列明負責審閱的人。

稿件旁可放一份簡短檢查清單：

• 事實： 產品資料、價格與活動條件是否有依據，是否仍然有效？
• 品牌： 措辭是否符合已確認的語氣與定位？
• 來源與使用權： 證據能否重新打開，擬議用途是否獲准？公開頁面不代表可以轉載其中的文字或圖片。
• 表達： 比較、最高級及含糊承諾是否有足夠依據？
• 最終版本： 決定是否清楚指定獲批的內容與下一步？

這些是本方案的審閱項目，不是 LangGraph 內建的行銷功能。

批核、拒絕與修訂，要有不同結果

建議用明確的決定欄位：approve、reject 或 revise，並附上受審版本識別碼、需要時的修改內容及理由。記錄由誰作出決定，再驗證應用規則：審閱者是否有權批核、版本是否仍然吻合，以及是否還有阻止通過的未確認聲明。

三種結果應分開處理。批核把指定的核准版本交給約定的下一步；拒絕取消擬議操作，但保留紀錄；修訂則保存新版本，再交回審閱。修改不能默默變成核准。

假設一份虛構的 v1 草稿寫着：「每位顧客的最佳護膚選擇。」沒有證據支持比較及適用所有人的承諾，審閱者刪去這句，將 v2 改為「探索我們的護膚系列」。這次決定是 revise，並附上修改理由。V2 仍要對照活動 brief 檢查，刪去一項無依據聲明不等於替新稿批核。

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() 前的程式碼會再次運行。不要把重新生成受審稿件或外部操作放在中斷前，然後假設它只會執行一次。建議讓審閱節點讀取已保存的提案而不改動內容，並另外設計重複寫入及後續操作的防護。暫停與恢復本身不保證嚴格只執行一次。

實作前，與工程團隊確認審閱紀錄、三種決定的結果，以及哪些操作會受重跑影響。大家能說清楚「誰審了哪個版本，這項決定允許下一步做甚麼」，才有足夠清楚的交接規格，而不只是畫面上多了一個批核按鈕。