如何選擇工作流程與代理

Agent（代理）已成為 AI 領域最被濫用的詞彙之一。從附帶檢索功能的聊天介面，到能自行規劃、呼叫工具並採取行動的長時間執行程式，產品團隊全用同一個詞來稱呼。一個詞涵蓋這麼多種設計，設計審查就會淪為名詞之爭，但真正需要討論的是架構。

對工程師與技術決策者來說，該問的不是系統「算不算 agent」，而是下一步由誰控制。有些系統把每一步轉換都寫死在程式碼裡；有些系統則讓模型在工具之間做選擇、決定接下來要蒐集哪些資訊，並判斷何時停止或轉交人工。這些控制模式的可靠度、延遲、成本與風險特性各不相同。

常見的「助理或代理」二分法，把好幾個獨立的設計決策壓進同一個行銷標籤。比較好的做法是把面向使用者的助理互動模式，和底層的工作流程或代理控制分開來看（兩者可以並存於同一個應用程式），再沿著幾個獨立維度評估控制主體與權限。本文只談這些邊界；執行期的迴圈機制、重試與工具錯誤復原，請先依閱讀路線完成先備課程，再到文章 06 閱讀。

選讀的記憶課程區分了對話記憶、任務狀態、工作記憶與持久知識。請用這套工作分類標明每項資訊的權威等級、生命週期與擁有者；若把四者混為一談，可能看不清執行期獲准讀取、寫入或引用哪些資料作為佐證，控制決策也會更難評估。

本文不涵蓋的內容

本文不談執行期迴圈機制、工具契約或故障復原，這些屬於文章 06 的範疇。本文也不是治理或可稽核性的專文；文章 10 會延伸架構範例，示範核准閘門與可檢視的追蹤紀錄。本文是教學設計，不是正式環境的認證標準，任務是建立概念框架：控制主體、權限、後果、可逆性與時間跨度如何形塑設計，以及核准邊界（approval boundary）該放在哪裡。

為什麼代理相關術語容易令人混淆

混淆有一部分來自把產品比喻和系統術語混在一起講。Assistant（助理）通常是面向使用者的比喻，指透過對話協助使用者完成任務的軟體。它可以描述差異很大的架構：單輪聊天應用程式、以檢索為基礎的問答系統、包在聊天介面裡的確定性工作流程，或在回應前先規劃多個步驟的受限代理。

相對地，許多人把 Agent（代理）當成定義嚴謹的技術分類，實務上各團隊卻拿它來指稱四種不盡相同的概念：

• 任何會呼叫工具的系統

• 任何橫跨多個步驟的系統

• 任何會主動觸發任務的系統

• 任何讓模型參與決定執行路徑，而非只負責產出最終文字的系統

這幾種定義彼此重疊，卻不等價：系統可以呼叫工具而不具備實質的代理性，可以跑很多步卻沒有一步是自己決定的，也可以主動觸發工作、同時仍受程式碼嚴格約束。術語一鬆散，設計審查也會跟著鬆散。

別再把 assistant 與 agent 視為互斥的產品分類，而是把它們當成五個更深層控制問題的簡稱：

• 執行路徑是由程式碼預先排定，還是由模型在執行期動態決定？

• 模型有權挑選下一個動作，還是只負責填滿某個固定步驟？

• 系統開放了哪些工具供模型呼叫？

• 模型可以讀取或修改哪些狀態儲存區？

• 哪些節點必須由人工核准、介入或強制中止？

這些問題比標籤穩定得多。

從架構模式區分助理、工作流程與代理

用控制邏輯、而不是對話個性來定義這三種模式，系統邊界就會清楚。

助理（Assistant）

助理最好理解成一種互動模式，而不是嚴格的系統類別：它協助使用者完成任務，通常透過自然語言互動，底層可以用差異很大的自主程度來實作。

同樣的介面背後，助理可能是：

• 負責起草回覆的單次模型呼叫

• 引用內部文件的檢索管線

• 執行固定階段圖的確定性工作流程

• 先收集各方證據、擬定下一步建議再送請人工核准的受限代理

因此，「做一個助理」只交代了產品互動體驗，並未說明底層採用哪種控制架構。

工作流程（Workflow）

工作流程按預先定義的階段順序執行。控制邏輯主要寫在應用程式的程式碼裡，模型只在邊界明確的步驟內負責分類、摘要、擷取、排序或起草，操作順序大致事先固定。

常見範例包括：

• 檢索文件、擷取相關表格、正規化單位，再綜合成摘要

• 先分類請求，導向三條已核准流程之一，再產生回應

• 匯入 PDF、執行版面擷取、驗證必填欄位，再寫入結構化輸出

工作流程通常是合適的預設選擇，因為固定路徑比較容易測試、理解與約束。它的弱點在於彈性：任務不規則，或正確的步驟順序高度取決於系統沿途發現的結果時，寫死的分支樹可能變得脆弱，維護成本也可能過高。

代理（Agent）

代理（agent）是指模型對部分執行流程握有實質控制權的系統。在預先劃定的邊界內，這通常表示模型可以自行決定下一步採取什麼行動、呼叫哪個工具、補查哪些資訊、是否修正原定計畫，以及何時停止或轉交人工。

交出這些決定權，不需要無邊際的自主性，也不代表模型具備人類等級的判斷力，更不等於放任系統為所欲為。在正式環境中，實用的代理通常是受限的系統：

• 只在明確定義的任務範圍內運作

• 只能呼叫白名單內已核准的工具

• 受應用程式端強制執行的明確政策約束

• 執行高影響動作前，必須停在核准閘門（approval gate）

• 觸及步數、時間或成本預算等固定停止條件就終止

系統之所以更具代理性，不是因為它看起來更聰明，而是因為有更多控制邏輯從確定性程式碼交給了模型決策。

更實用的切法：固定流程對照模型引導流程

追問「誰決定下一步」，就能拆開三種常被混為一談的運作模式。

在固定工作流程中，應用程式的程式碼決定每一次轉換，模型只負責完成邊界明確的子任務。

在輔助式系統中，使用者可能仍是主導流程的人：系統協助檢索、起草與分析，但每一步往哪走由使用者決定。

在代理式系統中，模型至少引導一部分流程：它可能補查更多證據、呼叫解析工具、比對互相衝突的紀錄、向使用者提問以釐清需求，或因為信心不足、需要核准而停下。

模型一旦能決定流程走向，而不只是產出內容，可靠度的性質就變了。錯誤可能跨步驟累積：挑錯檢索條件會汙染後續的綜合結論，多餘的工具呼叫會增加延遲與成本，漏設停止條件則可能讓原本有用的迴圈失控空轉。

這項架構轉變確實存在，但要精準描述：委派流程決策改變的是控制權的位置，並沒有創造出另一種智慧。

採用多維度決策矩陣

把自主性壓成單一階梯，也會製造盲點。連續跑一個月的票價監控程式，權限可能很有限；一步完成的不可退款購買，卻可能立即形成財務承諾。唯讀存取仍可能外洩機密資料，購買能否撤回也取決於實際條款。執行時間長短不是權限分數。

1. 控制主體

標明由程式碼、人類使用者還是模型決定下一步。路由式工作流程可以呼叫模型分類器，但所有允許的分支仍由程式碼列舉；受限代理則把部分流程選擇委派給模型。Anthropic 對工作流程與代理的區分是實用的共通詞彙，而不是正式的產業標準（Anthropic, 2024）。

2. 權限範圍

逐一列出系統獲准執行 read（讀取）、recommend（建議）、write（寫入）或 commit（對外提交承諾）的範圍。光有可用的工具並不夠：通過身分驗證的主體、委派與目標資源的政策，都必須授權這項確切的操作。

3. 錯誤後果

依系統出錯時的影響分類：資訊層面、內部營運、對外可見、財務、安全相關，或受法規管制。同一種控制模式放在不同領域，風險可能差很多。

4. 可逆性

區分操作屬於唯讀查詢、可輕易還原的修改、需付出成本才能補償的操作，還是實質上不可逆的承諾。更新有版本控管的內部草稿，和扣一筆不可退款的款項，不該共用同一套核准設計。

5. 時間跨度

標明任務屬於單次、多步驟、可中斷續跑、定期排程，還是長時間執行。時間跨度拉長會增加狀態維護、漂移與監控負擔，但持續時間本身不會賦予系統更大的權限。

先盤點完這五個維度，再選擇架構模式。這張矩陣是本教學的設計輔助工具，不是經過驗證的數值風險分數。目標不是把自主性開到最大，而是只委派任務需要的流程彈性，同時把權限與後果限制在邊界內。

核准邊界比產品標籤更重要

把控制主體與權限、後果拆開之後，下一個設計問題就是核准邊界該畫在哪裡。許多關於「代理」的討論，正是到了這一步才變得具體。

本文以 approval boundary（核准邊界）作為廣義的設計術語：它標出系統可以準備輸出、但不能自行推進的位置。approval gate（核准閘門）則是在工作流程中落實這道邊界的具體執行期檢查點。

任何包含模型引導行為的系統，都應該對以下四個問題有明確答案：

• 模型可以自行決定什麼？

• 模型可以呼叫哪些工具？

• 模型可以讀取或修改哪些狀態？

• 哪些動作在執行前必須取得明確的人工核准？

這些答案不是文件裡的補充細節，而是架構的核心。

授權（authorization）與核准（approval）是兩種不同的控制。授權判定通過身分驗證的主體能否對某項資源執行某個操作；核准則是在已授權的範圍內記錄人的決定，不能替使用者、工作負載身分或資源政策補上原本沒有的權限。NIST NCCoE 在 2026 年 2 月發布的概念文件，針對 AI 代理分別提出識別、身分驗證、授權、委派與稽核紀錄方面的問題，並探討如何把代理身分與人類身分綁定，以支援需要人類參與的授權（human-in-the-loop authorization）。這份文件仍是概念草案，不是最終標準（NIST NCCoE, 2026）。

對照以下兩條旅行 Copilot 政策：

• 模型可以草擬訂房建議

• 模型可以確認訂房並完成付款

前者是有邊界的分析任務；後者跨入營運控制，系統出錯時的後果嚴重得多。這個差異不該藏在同一個 agent 標籤後面。

當系統能執行以下操作時，核准閘門作為實作檢查點特別重要：

• 寫入持久紀錄

• 聯繫客戶或外部合作夥伴

• 在正式環境觸發程式碼變更

• 動用款項或鎖定庫存

• 啟動實體流程

• 變更系統或資安設定

依操作的後果、主體的權限、組織政策與錯誤成本決定審查要求。更新持久保存的內部草稿，不一定需要和付款相同的核准。人工審查只是其中一項控制，本身也可能出錯，因此它是授權與驗證的補充，不能取代兩者。

審查設計要避免造成核准疲勞。讓審查者看到計畫、佐證資料、將被變更的確切資源或欄位、預期後果、核准期限，以及還原或補償路徑。低風險且重複的讀取可以在常設授權下執行；不可逆或對外可見的操作，則應綁定到特定且仍有效的單次決定。Anthropic 把「將監督重心移到審查計畫，同時保留執行期間介入的能力」描述為一種實務模式（Anthropic, 2026）。

停止條件同樣重要，但這裡只需要先建立概念：一旦模型控制了部分流程，系統就必須知道何時該停止、提報，或在核准邊界等待。重試、停止與提報路徑的營運細節，會在文章 06 說明。

完整範例：設有核准閘門的 OptiVerse 旅行 Copilot

回到貫穿本系列的虛構 OptiVerse Travel 旅行 Copilot。以下的合約、飯店與比較都是教學用測試資料，不是對真實供應商的陳述。一位旅遊顧問提出以下需求：

為行程 JPN-2026-0417 準備京都住宿段落：在客戶預算內找出櫻花季期間的無障礙房型，並就合約 KYO-H12 是否為最佳選擇提出建議。

同一個需求可以有好幾種實作方式。

版本 1：輔助式互動

系統檢索京都合作飯店的合約、無障礙規格表、季節性費率表與過往客戶評價，再列出三間候選飯店的價格與無障礙細節。接下來每一步都由顧問決定：依價格縮小範圍、查看某間飯店的無障礙紀錄，或請系統提出建議。

這是輔助式設計：系統幫了很大的忙，但流程中的每一步仍由人類控制。

版本 2：固定工作流程

系統依序跑完五個預先寫定的階段：

1. 在指定日期內搜尋京都合作飯店的無障礙房間

2. 依輪椅無障礙必備條件過濾候選名單

3. 從季節性費率表擷取房價並統一換算為美元

4. 先依合適的證據強制檢查必備無障礙設施，再按明確表達的偏好與預算為合格選項排序；不能讓綜合評分抵銷缺少的必備設施

5. 產出結構化比較摘要供顧問審閱

這是工作流程，因為步驟順序是預先決定的。只要任務形態穩定，它可以既可靠又有效率。即使空房狀況已經改變，或飯店的無障礙宣稱和實際設施不符，工作流程仍能依明確設計的規則重新取得庫存、依衝突分支處理，或提報人工審查。單憑系統能因應變化，不足以證明必須改用模型引導的控制。

版本 3：受限代理

系統收到相同的目標，但現在可以自行決定部分流程。它可能：

• 先從合作合約、空房資料來源與無障礙紀錄開始檢索

• 發現某間飯店的合約列出無門檻淋浴間，但無障礙規格表只描述附扶手的浴缸

• 從目前的權威來源核實鐵路涵蓋範圍，該來源須標明生效日期、適用銷售通路與來源 ID

• 針對合約 KYO-H12 呼叫費率擷取工具，取出季節性計價附錄

• 將這些費率與另外兩間合作飯店比較

• 標記兩份紀錄的矛盾，再確認兩者是否涉及同一房型與同一生效期間；單憑任一份文件，都無法證明目前的實體設施狀況

• 在把搜尋範圍擴大到非合作飯店之前，先請顧問核准

• 產出附引用來源的建議，並清楚標示尚未解決的無障礙衝突

這就更具代理性，因為模型可以在受限任務內選擇下一步要做什麼。但邊界依然穩固：

• 可以從已授權的合約與空房資料來源收集證據

• 可以草擬比較與建議

• 可以建議預訂特定飯店

• 不得確認任何訂房

• 不得修改客戶的行程檔案或行程表

• 不得授權任何付款或訂金

「描述」、「建議」、「行動」這幾個動詞適合用來討論能力，但不構成完整的治理階梯。每項具體操作仍需要五維度評估，尤其建議本身也可能影響使用者做出後果重大的決定。

這就是受限自主性（bounded autonomy）在實務上的樣子：系統之所以有用，是因為它有一些裁量空間，而不是因為它有無限的權限。

實作練習

請針對以下五項操作完成這張矩陣：讀取合作合約、草擬行程、更新行程草稿、暫留飯店房間（hold），以及從付款方式扣款。

針對每一項操作，請將面向使用者的互動模式與底層的 workflow 或 bounded agent 控制分開填寫，接著標明應用程式端的授權檢查與任何核准邊界，並用全部五個維度說明每項設計的理由。

刻意破壞的案例

請對比以下兩套系統：

• 系統 A 是連續執行一個月的監控程式，讀取公開票價網頁並寫入內部警示。它無法訂位也無法付款，但因為會寫入警示，並非完全唯讀。

• 系統 B 用已儲存的付款方式，執行一筆由模型選定、不可退款的購買。

單一維度的自主性階梯，可能因為系統 A 執行得比較久，就把它排在系統 B「之上」。多維度矩陣呈現的營運疑慮卻正好相反：系統 B 的權限、後果與不可逆程度都更高。修補系統 B 的方式是：讓付款留在模型可選的動作集合之外、在應用程式程式碼中強制執行授權檢查，並要求一筆綁定確切金額與該筆購買、且仍然有效的人工核准。

何時不該使用代理

最重要的設計決策之一，是看出何時不需要代理式控制。

只要任務步驟已知、可重複，而且容易用程式碼驗證，確定性工作流程通常是更好的選擇。

當錯誤影響重大、彈性規劃又幫助不大時，在合規、金融、安全或正式環境維運等領域，具備明確檢查的確定性流程往往勝出。

當可用工具功能薄弱、規格不明確或難以觀測時，不要把控制權交給模型。讓模型掌控品質不佳的工具，不會帶來有用的自主性，只會造成不透明的失敗。

在團隊還無法評估多步驟行為之前，先別導入模型引導的控制。一旦模型主導流程，單輪提示評估就不夠了：你需要步驟層級的追蹤、工具呼叫檢查，以及針對終止與提報行為的測試。

也不要只因為介面是對話形式，就加入自主規劃。聊天介面並不代表底層系統應該自主規劃或行動；許多優秀的產品，在自然語言介面之下都應該維持以確定性流程為主。

實務上，團隊常因為「agent」這個標籤聽起來很先進而過早導入。比較好的演進順序通常正好相反：

1. 先從明確的固定工作流程做起

2. 量測固定分支在哪些地方妨礙了真實任務

3. 只在效益足以抵銷額外複雜度的地方，引入受限的模型引導決策點

照這個順序做出來的系統，往往更容易上線，也更容易讓人信任。

常見誤解

以下五種常見迷思，經常讓架構審查走偏。

只要有接工具的系統就是代理。 光是使用工具並不足夠。工作流程可以照固定順序呼叫工具，而不必把實質的流程控制權交給模型。

代理就代表完全自主。 許多實用的代理都受到工具白名單與步數預算的嚴格限制，最重要的行動也需要核准。

助理就只是陽春的聊天機器人。 助理底下接的可以是單次模型呼叫，也可以是複雜的編排層。

自主程度越高代表系統越聰明。 自主程度更高，代表交出更多控制權。結果會不會因此變好，取決於任務結構、工具品質與控制設計。

既然模型已經會規劃步驟，人類就該退出迴圈。 在後果重大的系統中，這往往正是錯誤的結論：規劃能力並不能免除核准邊界的需要。

真正的設計問題

想「打造 agent」的需求，通常可以歸結為以下三種具體需要之一：

• 處理步驟順序取決於中途發現、無法事先寫死的不規則多步驟任務

• 針對每個請求動態挑選工具或證據來源

• 減少人類操作員逐步手動引導的負擔

這些目標都合理，但每一項都應轉化為架構決策，明確界定控制權歸屬、權限與停止規則。設計審查中最有用的問題，仍然是最簡單的那一個：

下一步由誰控制？

請在每一個決策節點回答這個問題，而不是替整套產品只回答一次。使用者可以從助理互動啟動一條由程式碼定義的工作流程，而這條流程內部又可以包含一段受限的模型引導調查。在固定的路由集合中放一個模型分類器，本身並不會讓整套系統變成代理。請明確描述每一項委派出去的流程決策。

這樣的框架，比爭論產品配不配得上 agent 標籤更有用。

完成標準

你的矩陣必須滿足以下所有條件才算完成：

• 五項操作皆已沿著全部五個維度完成分類；

• 不以執行時間長短代替權限範圍或錯誤後果；

• 每項寫入或對外提交操作都列出了應用程式端的授權檢查機制；

• 核准不能補上原本缺少的權限；

• 高後果操作的審查畫面呈現執行計畫、佐證資料、確切異動內容、有效期限，以及復原路徑或不可逆影響；

• 只要固定工作流程足以勝任該任務，推薦的架構模式就必須比代理更精簡。

知識檢核

請不回頭翻閱文章，直接回答：

1. 為什麼自主性不能簡化為單一分數階梯？

2. 授權（authorization）與核准（approval）有何不同？

3. 哪些維度能區分「更新草稿」與「不可退款的付款」？

4. 為什麼長時間執行的監控程式，風險仍可能低於單一步驟的操作？

參考答案

1. 控制主體、權限、後果、可逆性與時間跨度，會隨不同操作各自獨立變化。

2. 授權決定某個主體是否獲准對某項資源執行某個操作；核准則是在既有的權限邊界內記錄人的決定。

3. 錯誤後果與可逆性，外加是否具備對外提交承諾（commit）的權限。

4. 在本測試案例中，監控程式只讀取公開票價並寫入內部警示，購買則會動用無法退還的款項。比較結果取決於這些權限與後果，而不是執行時間長短；不過監控程式仍可能誤導使用者，或產生過多警示。

以下是一組站得住腳的練習解法。其中的核准規則是選定的產品政策，不是普遍適用的要求：

受限代理可以在上述任何操作之前收集證據，但它的調查裁量權不會擴大執行器的權限。若核准有延遲，執行時要重新檢查授權與提案是否仍然有效。

通往實務代理迴圈的橋梁

一旦確定某項任務需要受限的模型引導控制，下一個問題就是營運層面的：這個迴圈實際上該怎麼執行？

在閱讀實務中的代理迴圈之前，請先完成它的先備課程代理身分、授權與提示注入防禦。那篇文章會從架構邊界進入執行期機制：推理、行動與觀察迴圈（reason-act-observe loop）、工具呼叫驗證、規劃器與執行器分工、工具故障復原，以及讓受限代理保持有用、不致失控的停止預算。目標不是讓系統看起來更自主，而是讓多步驟的工具使用清楚易讀、可測試，並且安全到足以部署。

來源與延伸閱讀

本文參考以下一手資料與實務來源：

• Anthropic. "Building effective agents." 區分工作流程與代理、從簡單模式起步，以及運用受限自主性的實務參考。anthropic.com/research/building-effective-agents

• BAIR. "The Shift from Models to Compound AI Systems." 比較控制邏輯留在程式碼中與委派給模型的參考資料。bair.berkeley.edu/blog/2024/02/18/compound-ai-systems

• Schick, T., Dwivedi-Yu, J., Dessì, R., et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." 說明模型引導工具選擇能力的參考論文。arxiv.org/abs/2302.04761

• Yao, S., Zhao, J., Yu, D., et al. "ReAct: Synergizing Reasoning and Acting in Language Models." 推理、行動與觀察迴圈的參考論文，本文用作文章 06 的背景。arxiv.org/abs/2210.03629

• National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." 關於監督、防護機制與生成式 AI 風險框架的參考資料。nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

• National Institute of Standards and Technology, National Cybersecurity Center of Excellence. "Accelerating the Adoption of Software and AI Agent Identity and Authorization." 2026 年 2 月概念草案，提出軟體與 AI 代理在識別、身分驗證、授權、委派、稽核紀錄，以及需要人類參與的授權（human-in-the-loop authorization）等方面的問題。nist.gov agent identity concept paper

• Anthropic. "Trustworthy agents in practice." 2026 年 4 月。探討實質人類控制、計畫審查、介入與提示注入風險的第一方討論。anthropic.com/research/trustworthy-agents