AI Agent 工作流：授權、狀態與可靠執行

AI Agent 讓模型在限定的工具與資料範圍內，選擇下一步行動。要把它用於真實業務，必須把身份授權、執行狀態、人工批准、重試及結果確認設計成可驗證的系統規則。

本指南對應技術人學習路徑 B4，涵蓋營運報告、庫存預警、評論監察、客服輔助與多步協作。前置閱讀為資料管道及 RAG 知識庫。

1. 先選擇適合的控制方式

這些方式可以組合。是否需要模型判斷，應由真實任務決定；數據異常也可能由明確的統計或業務規則處理。

Anthropic 的架構經驗區分固定程式路徑與模型主導的工具使用，並建議先從簡單方案開始。本文沿用這個設計區分，具體工具接口則需按實際使用版本核對。

2. 把業務場景拆成讀取、建議與執行

不要讓資料來源中的文字自行授權操作。公開網頁、文件、評論及工具輸出應被當作資料處理，而非權限或批准。

3. 建立持久的工作記錄

每個工作需保存：租戶及擁有人、工作 ID、任務範圍、狀態與版本、計劃修訂、輸入來源、工具及參數、所需批准、執行回執、失敗原因與時間。憑據不應放在模型提示、對話記錄或客戶端。

服務端從已驗證身份取得租戶及角色，對每次讀取、批准、執行、重試與匯出重新授權。前端傳入的帳戶、租戶或角色名稱不能直接成為授權依據。

保存狀態後才回應成功。使用者離開、重新登入或換裝置時，應讀取同一份服務端記錄。LangGraph 的持久化文件區分 checkpoint 與其他儲存；其記憶體儲存範例不應被當作跨程序重新啟動後仍可保留資料的部署配置。

4. 明確處理狀態、批准及過期操作

一個受控流程可包括草稿、等待審閱、待執行、執行中、成功、失敗與待核對結果。若操作已送出但回應逾時，先進入核對程序，取得外部回執後再判定成功或失敗。

以下純函數示範合法狀態轉移、版本衝突和計劃批准的對應關係。它接受真實工作狀態，不生成業務結果。實際系統仍須在已授權的服務端，以資料庫事務保存變更並處理工作隊列及工具回執。

function advanceRun(run, event) {
  const transitions = {
    draft: {submit: "awaiting_review", cancel: "cancelled"},
    awaiting_review: {approve: "ready", request_changes: "needs_changes", reject: "rejected", cancel: "cancelled"},
    needs_changes: {revise: "draft", cancel: "cancelled"},
    ready: {dispatch: "running", cancel: "cancelled"},
    running: {succeed: "succeeded", known_failure: "failed", uncertain_result: "reconciling"},
    reconciling: {confirmed_success: "succeeded", confirmed_failure: "failed"},
    failed: {revise: "draft"},
    succeeded: {}, rejected: {}, cancelled: {}
  };
  if (!run || !event || !Object.hasOwn(transitions, run.state)) {
    throw new Error("Known run state and event required");
  }
  if (!Number.isSafeInteger(run.version) || run.version < 0 || run.version >= Number.MAX_SAFE_INTEGER ||
      !Number.isSafeInteger(run.planRevision) || run.planRevision < 1 || run.planRevision >= Number.MAX_SAFE_INTEGER) {
    throw new Error("Valid version counters required");
  }
  if (event.expectedVersion !== run.version) throw new Error("Stale run version");
  if (!Object.hasOwn(transitions[run.state], event.type)) throw new Error("Transition not allowed");
  if (event.type === "approve" && event.planRevision !== run.planRevision) {
    throw new Error("Approval does not match the current plan");
  }
  if (event.type === "dispatch" && run.approvedRevision !== run.planRevision) {
    throw new Error("Current plan approval required");
  }
  const revised = event.type === "revise";
  return {
    ...run, state: transitions[run.state][event.type], version: run.version + 1,
    planRevision: run.planRevision + (revised ? 1 : 0),
    approvedRevision: revised ? null : event.type === "approve" ? run.planRevision : run.approvedRevision
  };
}

每次改動計劃都必須增加修訂號並清除原批准。服務端保存時應核對工作 ID、租戶及預期版本；更新衝突要回傳明確訊息，重新載入後讓使用者決定下一步。函數檢查通過不等於資料庫已保存或外部操作已成功。

人工批准頁應展示操作、對象、參數、資料範圍、可能影響及批准有效期。按目前內容批准；內容、帳戶、租戶或批准期限改變後，需重新核對。LangGraph 的中斷與恢復文件可作框架實作參考，身份授權與業務批准仍由應用程式負責。

5. 工具契約、重試與結果確認

工具應驗證輸入、限制可存取的對象，並回傳可分類的結果。記錄來源、必要的決策摘要和操作回執；不應把模型的說法當作外部系統已完成工作的證據。

對價格、預算、付款、訊息發佈或刪除等操作，先定義限額、批准責任和可回復方式。跨系統的去重與重試保障，需要結合供應商的實際接口及回執機制驗證。

6. 持續執行、多 Agent 與記憶

設定每個工作的步數、時間、費用、工具及失敗上限。到達限制時保存進度及原因，向使用者提供可行的續辦方式。排程工作要有擁有人、有效期、失敗告警和取消入口。

多 Agent 分工可以分別處理檢索、分析及寫作；共同使用錯誤來源時，仍可能得到一致但錯誤的結果。審核需追溯到原始資料、工具回執或實際測試，並明確區分 AI 覆核與具名真人審校。

記憶及 checkpoint 也要按租戶和工作授權。恢復工作時重新驗證使用者及批准狀態，避免把舊會話的身份、快取或批准套用到另一個帳戶。

7. 安全、觀察與成本

OWASP 的提示注入說明涵蓋來自外部內容的間接注入。應以工具範圍、伺服器授權、受控資料傳輸及關鍵操作批准限制影響。

按實際記錄量度：任務完成率、工具失敗、錯誤執行、人工介入、待核對結果、延遲、費用及返工。成本要包含模型、檢索、工具、運算及人工；用量或單價缺失時保留未知，避免填入固定的節省比例或成本估計。

監控記錄應足以排查問題，同時限制私有內容及個人資料的保存。公開報告只使用獲准披露的實際數據。

8. 上線前的分支測試

• 正常完成、零資料、來源失效、工具不支援及參數無效。
• 未登入、權限撤回、跨租戶請求與另一帳戶的舊頁面。
• 等待批准時離開、批准後修改計劃、批准過期及不同人同時操作。
• 重複提交、網絡中斷、程序重新啟動、版本衝突及部分完成。
• 限流、費用上限、無限循環、提示注入及不符合工具契約的輸出。
• 寫入成功但回應遺失、外部回執無法取得及人工核對後的恢復。

先測讀取與草稿，再測有批准的實際操作。測試帳戶、沙盒及固定測試資料需與正式資料分開；真實收件、付款或公開發佈的驗收，需取得對應操作授權。

延伸閱讀

• RAG 知識庫設計與評估
• MCP 整合
• AI Agent 基礎
• 資料管道基礎