傳統 SaaS 會執行產品團隊預先定義的工作流程。AI 代理則為了達成目標，在執行期間自行選擇部分步驟。這項差異會改變權限、測試、介面、失敗處理與單位成本。
許多產品同時包含兩者。客服應用程式可以用一般程式碼驗證客戶並取得發票，再由代理調查語意不明的帳務問題。若把整個產品都稱為代理式產品，反而會掩蓋工程師真正需要控制的邊界。
工作流程從哪裡來
在 SaaS 中，產品把允許的路徑寫進程式碼。使用者選擇發票、點選退款、確認金額，再收到結果。請求開始前，介面和後端就知道所有可能狀態。
代理從目標出發，根據收到的上下文選擇工具。搜尋結果、工具錯誤或模型選擇不同，都可能讓兩次執行採取不同路徑。應用程式仍必須用硬性規則限制哪些路徑可以使用。
OpenAI 的代理建置實務指南建議在工作流程包含複雜決策、脆弱規則或大量非結構化資料時使用代理。如果一般程式碼就能表達決策，固定工作流程依然是更清楚的設計。
工程上的差異
| 關注事項 | 傳統 SaaS | AI 代理應用程式 |
|---|---|---|
| 工作流程 | 預先寫在程式碼中 | 執行期間在允許範圍內選擇 |
| 介面 | 針對已知狀態設計畫面和端點 | 目標、上下文、工具及產生的中間步驟 |
| 授權 | 使用者操作對應已知端點 | 每個選定工具和下游操作都要授權 |
| 測試 | 驗證已知輸入的預期輸出 | 驗證工作成果、工具選擇、禁止操作及多次執行的差異 |
| 失敗 | 通常是在已知步驟顯示明確錯誤 | 可能沿用錯誤步驟或來源，產生看似合理的答案 |
| 復原 | 重試請求或顯示錯誤 | 先核對已完成的效果，再從檢查點接續 |
| 成本 | 主要取決於請求和基礎設施 | 也取決於 token、工具呼叫、重試和執行時間 |
| 可觀測性 | 請求、服務與資料庫追蹤 | 再加上模型、工具、政策與評估紀錄 |
記憶、工具、狀態與持久執行中的應用程式架構，正是由這些差異推導而來。
權限設計會最先改變
SaaS 按鈕可以用範圍狹窄的操作呼叫單一端點。代理可能從二十個工具中選擇，並用產品團隊從未寫過的順序加以組合。後端必須根據目前的使用者、租戶和資源授權每一次呼叫。系統提示裡的一句話無法授予或移除存取權。
OWASP 的 Excessive Agency 指南把問題分成過多功能、權限和自主程度。這是一套實用的檢查方法：移除工作流程不需要的工具、縮小每個保留工具背後的憑證範圍，並在高影響操作前要求核准。
測試轉向行為驗證
單元測試可以證明退款函式會拒絕負數金額，卻無法證明代理永遠只在使用者要求退款時才選擇退款工具。因此，代理評估需要具代表性的工作、預期工具選擇、禁止操作，以及重複執行。
只看輸出並不夠。即使答案正確，只要它是在讀取另一個租戶的紀錄後產生，仍是嚴重失敗。AI 代理上線前評估指南會一起說明工作與追蹤斷言。
介面必須呈現不確定性
傳統 SaaS 通常呈現付款完成、失敗或等待中等已知狀態。代理可能只有不完整的證據，或遇到彼此衝突的來源。產品需要顯示代理使用了哪些內容、哪些地方不確定，以及下一步建議採取什麼操作。
核准內容應包含確切效果。「繼續」太模糊；「將發票 1842 退款 $42.00」才讓審核者知道自己核准的是什麼。
何時不該使用代理
如果規則穩定、輸入有結構，而且正確操作能直接寫成程式碼，就應維持確定性的工作流程。身分驗證、配額執行、付款結算、權限檢查和資料庫約束都屬於一般程式碼，即使呼叫它們的是代理也一樣。
當混亂上下文中的判斷會改變工作順序時，再使用代理。只給它一小組工具，並由後端執行絕不能變動的規則。
為一條工作流程畫出邊界
選擇一條工作流程，把每個步驟標記為確定性程式碼、模型判斷、人工核准或外部副作用。模型步驟若沒有必須變動的理由，就移回一般程式碼。外部效果若沒有明確身分和復原路徑，就先別進入正式環境。
下方提示會要求程式開發代理畫出這條邊界，同時禁止它在思考期間重構應用程式。