情境
正式應用中的工作流程自動化
應付帳款流程讀取帳單、比對採購單，請模型分類差異，再送審或建立異常工單。 流程狀態存於應用資料庫，不放在聊天紀錄裡。
模型只判斷不明確的分類。 解析、計算、重複偵測、寫入、重試與期限，維持確定性處理。 每次外部寫入都附冪等鍵。
正式環境場景
工作流程自動化用 LLM API
應付帳款流程讀取帳單、比對採購單，請模型分類差異，再送審或建立異常工單。 流程狀態存於應用資料庫，不放在聊天紀錄裡。
正式環境實作
API、主要模型與備援設定
| 正式環境選擇 | 建議 | 原因 |
|---|---|---|
| API | POST /v1/chat/completions | OpenAI 相容伺服器端請求 |
| 主要模型 | gpt-5.6-terra | Terra 處理範圍明確的判斷，保留政策與異常分類所需的推理能力。 |
| 備援模型 | gemini-2.5-flash | 範圍小且通過驗證的分類使用 Gemini 2.5 Flash。 新的異常情況交給 Sol 或人工，不擴大模型權限。 |
| 升級模型 | gpt-5.6-sol | 只在主要路徑未達品質或複雜度門檻時使用 |
| 輸出規則 | 通過驗證的 JSON | 回傳結構化分類、政策規則 ID、說明，以及需要時的送審理由。 |
架構
工作流程自動化流程如何運作
- 保存狀態與不可變的輸入參照。
- 執行確定性的解析與比對。
- 只在判斷不明確時呼叫模型。
- 依政策與信心規則驗證決策。
- 冪等地寫入下一狀態，或轉交審查。
API 請求
透過 LLMFly AI 呼叫 gpt-5.6-terra
從伺服器送出請求，將範例內容與預留工具格式換成應用的資料與工具。
curl https://app.llmfly.ai/v1/chat/completions \
-H "Authorization: Bearer $LLMFLY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-5.6-terra",
"messages": [
{"role": "system", "content": "Classify the invoice discrepancy using the supplied policy. Return MATCH, REVIEW, or REJECT with the exact policy rule. Do not perform any external action."},
{"role": "user", "content": "Classify this invoice and purchase-order discrepancy."}
],
"response_format": {"type": "json_object"}
}'模型選擇
為什麼以 gpt-5.6-terra 為主要模型
Terra 處理範圍明確的判斷，保留政策與異常分類所需的推理能力。
範圍小且通過驗證的分類使用 Gemini 2.5 Flash。 新的異常情況交給 Sol 或人工，不擴大模型權限。
驗收
工作流程自動化驗收檢查
| 指標 | 通過條件 |
|---|---|
| 端到端完成率 | 流程完成所有必要步驟，且成功狀態已記錄 |
| 重複寫入率 | 重播與重試不產生重複訊息、工單、付款或更新 |
| 人工介入率 | 只有預先定義的異常路徑需要人工恢復流程 |
| 每個流程的成本與時間 | 成功執行符合流程的時間與成本預算 |
失敗處理
部署前要處理的失敗
- 以聊天紀錄作為狀態儲存
- 重試非冪等寫入
- 授予不必要權限
- 沒有最終失敗處理路徑
輸出
回傳輸出與執行紀錄
回傳結構化分類、政策規則 ID、說明，以及需要時的送審理由。
每次正式執行記錄模型 ID、請求 ID、token 用量、重試、驗證結果與最終處理。
常見問題
流程狀態應存在哪裡？
存於應用資料庫或流程引擎，只傳相關狀態給模型。
哪些操作需要冪等性？
所有可能重試的外部寫入，包含訊息、工單、付款與更新。
何時應停止重試？
設定有上限的規則，最終失敗附復原資訊送入審查佇列。
用自己的輸入測試設定
以相同請求、工具與驗證規則比較主要和備援模型。