助理、工作流程與代理：為適當的自主層級而設計

Agent（代理）已經成為 AI 中最被濫用的術語之一。產品團隊拿它來形容各種東西——從帶有檢索功能的聊天介面，到可以自行規劃、呼叫工具和採取行動的長時間執行程式，通通都算。這種詞彙漂移會造成實際問題：真正的設計問題明明是架構性的，團隊卻在爭論標籤。

對工程師和技術決策者來說，真正該問的不是系統「是不是 agent」，而是：誰控制下一步？有些系統裡，下一步是寫死在程式碼中的。有些系統裡，模型可以在工具之間選擇、決定接下來要收集什麼資訊、決定何時停止或提報。這些是不同的控制模式，可靠性、成本和風險也截然不同。

這就是為什麼常見的「助理 vs. 代理」二分法太過膚淺——它把好幾個不同的設計決策壓縮成一個行銷術語。更好的做法是把助理、工作流程和代理區分為架構模式，再放到一個由權限、核准邊界（approval boundary）和停止條件定義的自主性光譜（autonomy spectrum）上。本文的重點是這些控制邊界，不是迴圈的執行時期機制——那些下一篇再談。

第四篇文章區分了四個資訊層：對話記憶（conversation memory）、任務狀態（task state）、工作記憶（working memory）和持久知識（durable knowledge）。這些詞彙在這裡很重要，因為自主性的設計直接取決於系統可以讀取、寫入和拿來當證據的資訊。一個把這些層次混為一談的系統，不管被貼上什麼標籤，自主性決策都不會好到哪去。

本文不是什麼

這不是一篇談執行時期迴圈機制、工具合約（tool contract）或故障恢復的文章。那些營運細節留到第六篇再談。也不是談治理或可稽核性的文章；核准閘門和可重播追蹤的完整生產標準會在第十篇介紹。本文專注於概念框架：自主性作為一個設計光譜意味著什麼，以及核准邊界（approval boundary）該設在哪裡。

為什麼代理術語令人困惑

困惑有一部分來自於產品語言和系統設計語言混著用。Assistant（助理）通常是一個面向使用者的比喻，暗示一個透過對話幫人完成任務的系統。但它能描述的架構範圍非常廣：單輪聊天應用程式、檢索支援的問答系統、包裝在聊天 UI 中的確定性工作流程，或在回應之前會規劃多個步驟的受限代理。

另一方面，Agent（代理）常被當成一個明確的技術類別。但其實不是。不同團隊用它來指：

• 任何可以呼叫工具的系統

• 任何可以完成多步驟任務的系統

• 任何主動行為的系統

• 任何模型幫助決定流程而非僅生成最終答案的系統

這些定義有重疊，但並不相同。一個系統可以呼叫工具，卻不一定具備實質的代理性。一個系統可以跑好幾步，卻不一定自己決定其中任何一步。一個主動的系統也可以被程式碼嚴格約束。術語一鬆散，設計審查也跟著鬆散。

解決的辦法是別再把 assistant 和 agent 當成互斥的產品類別，而是把它們看成圍繞更深層控制問題的簡稱：

• 執行路徑是預先確定的還是由模型引導的？

• 模型可以選擇下一個動作，還是只能填入一個步驟？

• 它可以使用什麼工具？

• 它可以讀取和寫入什麼狀態？

• 哪裡必須由人類核准、中斷或停止執行？

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

助理、工作流程和代理作為架構模式

區分這些概念最清楚的方式，是以控制邏輯來定義它們，而不是以個性。

助理（Assistant）

助理最好理解成一種互動模式，而非嚴格的系統類別。它是一個設計來透過自然語言幫使用者做事的系統。值得注意的是，助理可以用非常不同的自主層級來實作。

助理可能是：

• 草擬回覆的單一模型呼叫

• 引用內部文件的檢索支援介面

• 總是執行相同步驟序列的確定性編排

• 在要求核准前可以收集證據並提出下一步行動的受限代理

所以 assistant 告訴你一些關於產品體驗的資訊，但對內部架構其實說得不多。

工作流程（Workflow）

工作流程是預先定義好的流程。控制邏輯主要寫在程式碼裡，模型只在受限的步驟內被使用。模型可能負責分類、摘要、擷取、排序或草擬，但操作的順序基本上是預先固定的。

舉幾個例子：

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

• 分類請求、路由到三個已核准流程之一，然後生成回應

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

工作流程通常是正確的預設選擇，因為更容易測試、更容易推理、也更容易約束。弱點在於靈活性。如果任務不規則，或者正確的步驟順序很大程度取決於系統沿途發現的結果，僵化的工作流程可能變得脆弱，維護成本也會過高。

代理（Agent）

代理（agent）指的是模型對部分執行流程擁有實質控制權的系統。具體來說，模型可以在定義好的邊界內決定接下來做什麼、呼叫什麼工具、收集什麼資訊、要不要修改計畫，以及何時提報或停止。

這不需要開放式的自主性，不代表具備人類層級的判斷力，也不表示系統可以自由做任何想做的事。在正式環境中，有用的代理通常是受限系統：

• 它們在定義的任務範圍內運作

• 它們只能存取已核准的工具

• 它們在明確的策略下執行

• 它們在高影響動作前面對核准閘門（approval gate）

• 它們在固定的停止條件下終止

讓系統更具代理性的關鍵，不是它感覺更聰明，而是更多控制邏輯從確定性程式碼委派給了模型驅動的決策。

更有用的區分：固定流程 vs. 模型引導流程

這個框架有助於區分三種常被混淆的情況。

在固定工作流程中，程式碼決定下一步。模型可能執行子任務，但不引導流程。

在輔助式系統中，使用者可能仍是主要驅動者。系統協助檢索、草擬和分析，但使用者選擇每一個下一步動作。

在代理式系統中，模型可以引導至少部分流程。它可能決定檢索更多證據、呼叫解析器、比較衝突的結果、提出澄清問題，或因為信心太低或需要核准而停止。

為什麼這個區分很重要？因為當模型控制的是流程而不只是輸出時，可靠性的性質就不一樣了。一旦模型可以選擇行動，錯誤就可能跨步驟累積。一個錯誤的檢索選擇可能汙染後續的合成。一個不必要的工具呼叫可能增加延遲和成本。一個缺失的停止條件可能把有用的迴圈變成失控的迴圈。

架構上的轉變是真實的，但要精確描述。這不是一種不同類型的智慧，而是控制權的不同配置。

自主性是一個光譜

團隊常犯的另一個錯誤，是把自主性當成二元的——要麼系統「只是助理」，要麼它是「自主代理」。這種框架反而把真正重要的決策藏起來了。

自主性更好的理解方式是一個光譜（spectrum）。一個實用的版本如下：

1. 固定流程（Fixed Pipeline）

系統遵循硬編碼的路徑。它可能在內部使用模型，但模型不選擇接下來發生什麼。

典型使用場景：

• 文件匯入

• 結構化擷取

• 固定合規檢查

• 可重複的後台處理

2. 路由式工作流程（Routed Workflow）

系統仍然走預定義的流程，但由程式碼或分類器決定走哪一條。這增加了一些靈活性，又不會把太多執行控制權交給模型。

典型使用場景：

• 按意圖路由支援工單

• 在擷取範本之間選擇

• 在已核准的回答模式中選擇

3. 輔助式系統（Assistive System）

系統可以協助草擬、檢索和合成，但使用者仍然掌控序列。模型是有用的，但人類仍然控制流程。

典型使用場景：

• 研究 Copilot

• 建議變更但不會套用的程式助理

• 為人類審查者組裝證據的內部分析助理

4. 受限代理（Bounded Agent）

系統可以規劃或調整子任務、呼叫工具，並在受限範圍內選擇下一步做什麼。它能在有限監督下完成部分任務，但重要的行動仍然受到閘控。

典型使用場景：

• 調查工作流程

• 研究備忘錄準備

• 除錯或分析迴圈

• 在核准邊界（approval boundary）下的多步驟資料收集

5. 長時間執行的自主系統（Long-Running Autonomous System）

系統可以在較長的時間跨度內持續運作，直接監督有限，可能會監控狀態並採取重複動作。這是光譜中風險最高的一端，也是最難驗證的。

典型使用場景：

• 在高度受控領域中的狹窄營運自動化

• 具有廣泛監控和回滾機制的內部流程自動化

大多數團隊不需要跳到光譜的最遠端。事實上，許多團隊也不應該這樣做。提高自主性可以改善靈活性，但也會增加評估、可觀測性、權限設計和故障處理的負擔。

核准邊界比行銷標籤更重要

一旦你開始從自主層級的角度思考，接下來的設計問題就是核准邊界（approval boundary）該設在哪裡。這也是許多「代理」的討論真正變得具體的地方。

我們用 approval boundary（核准邊界）作為廣泛的設計術語：它標記系統可以準備輸出但不能自行推進的位置。approval gate（核准閘門）則是工作流程中執行該邊界的具體停止點。

對於任何具有模型引導行為的系統，你應該能清楚回答四個問題：

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

• 它可以呼叫什麼工具？

• 它可以讀取或修改什麼狀態？

• 什麼行動需要人類核准？

這些邊界不是文件裡的小細節——它們就是架構的核心。

看看以下兩個策略的差別：

• 模型可以草擬預訂建議

• 模型可以確認並支付預訂

第一個是有邊界的分析任務。第二個跨入了營運控制，系統出錯的後果嚴重得多。這個差異一點都不細微，不該藏在同一個 agent 標籤後面。

核准閘門（approval gate）在以下情況下尤其重要：

• 寫入持久紀錄

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

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

• 花錢

• 啟動實體流程

• 變更系統組態

在這些情況下，人類審查這一步通常不是暫時的妥協，而是正確的設計。

停止條件同樣重要。這裡先建立一個概念就好：一旦模型控制了部分流程，系統就必須知道何時該停止、提報或在核准邊界處等待。重試、停止和提報路徑的營運細節留到下一篇。

實作範例：具有核准閘門的 OptiVerse 旅遊 Copilot

回到本系列的 OptiVerse Travel 旅遊 Copilot。假設一位旅遊顧問提出以下需求：

為行程 JPN-2026-0417 準備京都飯店區段：在客戶預算內找到櫻花季期間的無障礙房間，並建議合約 KYO-H12 是否是最佳選項。

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

版本 1：輔助式

系統檢索合作夥伴飯店合約、無障礙規格表、季節性費率表，以及京都物件的過往客戶評價，然後呈現三間候選飯店的價格和無障礙詳細資訊。接下來由顧問自己決定要怎麼做：按價格縮小搜尋範圍、檢查特定飯店的無障礙紀錄，或請求建議。

這是輔助式的，因為系統提供了大量幫助，但人類控制流程中的每一步。

版本 2：工作流程

系統執行一個固定路徑：

1. 在請求日期期間搜尋京都合作夥伴飯店的無障礙房間

2. 按輪椅無障礙要求過濾結果

3. 從季節性費率表擷取價格並正規化為美元

4. 按預算契合度和無障礙評等排序選項

5. 呈現比較摘要供顧問審查

這是工作流程，因為順序是預先確定的。如果任務形態穩定，它可能既可靠又高效。但如果空房狀況已經改變，或飯店的無障礙宣稱跟實際設施對不上，系統可能沒有好的方式來適應——除非加入更多硬編碼的分支。

版本 3：受限代理

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

• 從合作夥伴合約、空房動態和無障礙紀錄中開始檢索

• 注意到一間飯店在合約中列出了無障礙淋浴間，但無障礙規格表描述的只是帶有扶手的浴缸

• 驗證計畫新幹線路段的 JR Pass 涵蓋範圍——Nozomi 不包含在基本通票中（2023 年 10 月起可另購補充票，但系統將此標記為費用和可用性細節，留給顧問確認）

• 對合約 KYO-H12 呼叫費率擷取工具以取得季節性定價附錄

• 把這些費率與兩間替代合作夥伴物件進行比較

• 識別飯店無障礙宣稱與實際房間規格之間的差異

• 在擴大搜尋範圍到非合作夥伴飯店之前請求顧問核准

• 產出一份明確標記無障礙衝突的建議

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

• 它可以跨合約和空房動態收集證據

• 它可以草擬建議

• 它可以建議預訂特定飯店

• 它不得確認任何預訂

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

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

這個區分同時建立了一個簡單的治理階梯——後面的文章還會再提到：系統可以「描述」、可以「建議」，或可以「行動」。這三者是不同的權責層級，不該混為一談。

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

何時不使用代理

最重要的設計決策之一，是認清什麼時候代理式行為根本沒必要。

當任務穩定到可以直接寫成程式碼時，別用代理。如果步驟是已知的、可重複的、容易驗證的，工作流程通常更好。

當出錯的影響很大、但靈活規劃的好處很小時，別用代理。在合規、金融、安全或正式環境營運相關的領域，有明確檢查點的確定性流程通常更勝一籌。

當可用工具太弱、規格不足或難以觀察時，別用代理。讓模型去控制糟糕的工具，不會產生有用的自主性，只會產生不透明的故障。

當團隊還無法評估多步驟行為時，別用代理。一旦模型引導流程，單輪提示評估就不夠了。你需要步驟級的追蹤、工具呼叫檢查，以及對終止和提報行為的測試。

別因為介面是對話式的就用代理。有聊天框不代表底層系統就該自主規劃或行動。許多優秀的產品在自然語言的表面之下，都應該維持大部分是確定性的。

實務上，團隊常常太早採用代理，因為這個標籤聽起來很先進。更好的路徑通常是反過來走：

1. 從工作流程開始

2. 找出僵化之處在哪裡損害了任務表現

3. 只在受限的模型引導決策點確實能抵消額外複雜性時，才加入它們

這種做法通常能產出更容易上線、也更容易信任的系統。

常見誤解

有幾個誤解反覆影響設計選擇。

任何有工具的系統就是代理。 不對。光有工具使用是不夠的。工作流程可以按固定順序呼叫工具，不需要給模型對流程的實質控制權。

代理意味著完全自主。 不對。許多有用的代理其實受到嚴格限制，最重要的行動仍需核准。

助理意味著簡單的聊天機器人。 不對。助理可以建立在從單一模型呼叫到複雜編排層的任何東西之上。

更多自主性意味著更多智慧。 不對。它意味著更多控制權交了出去。這樣是否改善結果，取決於任務結構、工具品質和控制設計。

如果模型能規劃，人類就應該退出迴圈。 在高後果的系統中，這往往恰恰是錯誤的結論。規劃能力不能消除對核准邊界（approval boundary）的需求。

真正的設計問題

當團隊說他們想要代理時，通常真正想要的是以下三件事之一：

• 處理不規則多步驟任務的能力

• 動態選擇工具或證據的能力

• 減少人類必須提供的流程控制的能力

這些都是合理的目標。但每一個都應該轉化為關於控制配置、權限和停止規則的架構決策。設計審查中最有用的問題，依然是那個最簡單的：

誰控制下一步？

如果答案始終是程式碼，你有一個工作流程。如果答案始終是使用者，你有一個輔助式互動模式。如果答案有時是模型——在明確的邊界內——你正在進入代理式設計。

這個框架比爭論一個產品配不配貼上 agent 標籤，有用得多。

通往實務中代理迴圈的橋樑

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

這就是下一篇文章的主題。我們會從術語轉向機制：推理-行動-觀察迴圈（reason-act-observe loop）、工具呼叫、規劃器-執行器模式、工具故障，以及讓受限代理保持有用而非不穩定所需的控制。目標不是讓系統看起來更自主，而是讓多步驟的工具使用變得可讀、可測試，安全到足以部署。

來源附註

本文參考以下主要與實務來源：

• Anthropic. "Building effective agents." 區分 workflow 與 agent、從簡單模式開始，以及有界自主性設計的實務參考。anthropic.com/engineering/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., Dessi, 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." 推理-行動-觀察迴圈的參考；本文主要作為下一篇的橋接。arxiv.org/abs/2210.03629

• National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." 隨自主性提高而需要的監督、護欄與風險框架參考。nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence