使用 Amazon Quick Automate 構建智能體自動化流程的最佳實踐

Agentic automation 正在改變企業運行業務流程的方式。Amazon Quick Automate 是 Amazon Quick 中的多智能體自動化能力，可以協調不同部門的多個智能體，打通內部系統、UI/API 和第三方應用，幫助組織大規模構建、部署和維護自動化。相較於傳統自動化，智能體需要在非結構化輸入、跨系統數據和頻繁變化的業務規則中做判斷，也因此帶來了可靠性、可觀測性和運維上的新挑戰。如果不在職責邊界、人工監督、確定性防禦措施和評估機制上做刻意設計，很容易獲得脆弱且難以信任的工作流。

第一步是挑對流程。適合智能體的流程通常需要協調多個記錄系統，輸入常是郵件、掃描件等非結構化或半結構化內容，決策不能靠簡單 if-then 完成，而且會頻繁出現傳統腳本難以處理的異常。供應商發來 PDF 發票需要匹配採購訂單並走審批，或者新員工入職需要 HR、IT、後勤等多個系統協同，都是典型場景。選好流程後，先定義可衡量的成功目標，比如週期縮短、錯誤率下降、吞吐量提升或單筆成本下降，再用這些指標衡量後續每一步是否值得加入，避免範圍蔓延。

最容易被跳過的是“目標流程”設計。從手工流程搬到一個由智能體驅動的流程，不是把舊步驟原樣複製後掛上一個智能體，而是重新思考當智能體承擔大部分工作時，工作應當怎樣流動。很多舊步驟只是用來彌合系統鴻溝的：從 PDF 重新錄入數據、把文檔在多個收件箱間傳遞、從 A 工具下載再上傳到 B 工具。這些步驟應當直接刪除。人工交接時間可以從一天縮短到幾秒；工作也不會長時間滯留在隊列裏等人發現。經驗法則是：儘量刪除一切能刪的步驟；如果沒有偶爾被逼着加回幾個，説明刪得還不夠深。完成這一步後，再繪製現狀流程，主要用於識別差距。

智能體本身的設計原則是單一職責。一個什麼都要做的智能體難以構建、難以調試，也更貴，因為職責過寬意味着需要更多指令、工具和推理步驟。在發票處理流程中，可以讓一個智能體專門讀取並結構化發票，另一個負責與採購訂單/合同比對並標識差異，第三個按金額和類別決定審批路徑。每個智能體足夠小，可獨立測試和優化。Quick Automate 能幫助限制每個智能體的工具和動作範圍，Automation Assistant 會根據流程描述完成一部分工具裁剪；Structured Output 則要求智能體返回固定結構的數據，例如規範的供應商名、發票號、行項目與總額，從而讓步驟間交接可靠。

並非每個工作流步驟都需要智能體。若能用代碼精確表達邏輯、或只要按結構化字段判斷分流的場景，應使用 Quick Automate 的確定性步驟；它們運行快、行為可預測且成本更低。而且 Quick Automate 按智能體執行時長計費，而不是按 token 計費，因此減少不必要的智能體推理能明顯降低成本。較好的做法是把需要判斷的步驟交給智能體，例如理解非模板化的供應商郵件、從掃描合同中提取付款條件、判斷一張發票與兩個採購訂單都部分匹配時如何處理；而凡是能完整寫出規則的部分，交給代碼或確定性分支即可。多個智能體也可以用確定順序鏈接，模擬真實運營團隊的固定交接。

人機協作要落在真正高風險和異常場景。Quick Automate 支持兩種模式。阻塞式 HITL 會在智能體需要幫助時暫停工作流，等審批人確認後再繼續，適合無法匹配任何採購訂單的發票、大額付款、發送合同等場景。非阻塞式 HITL 則只是通知人工並繼續處理下一個事務，適合需要監督但不想拖慢整體進度的場景，也適合允許異步響應的異常。閾值調節可以從兩個錯誤看：送審過多會造成評審員“橡皮圖章”，送審過少會漏掉本應升級的高風險錯誤。建議先設置偏保守的閾值，統計分析評審員實際修改智能體建議的比例，再逐步放寬自動處理範圍。每個審閲節點應儘量附帶原始 PDF、圖片和智能體的摘要，併為超時未響應定義升級路徑。

最後，智能體每次執行的行為並不完全相同，因此持續評測比傳統自動化更重要。最好的評測數據來自歷史流程：過去人工處理過的真實案例既是輸入也是參考答案。可先構建測試集，覆蓋正常與異常情形，在發佈前以及每次改動後運行評測，觀察成功率和失敗模式。可觀測性應當作為基本要求內建在自動化和人工介入點中，記錄智能體的輸出、採取的步驟、審批結果和異常中斷，當流程漂移或出錯時才能快速定位並恢復信任。