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