用經理人思維設計 AI 工作流：從確定性程式到模糊系統的四個轉變

同一段退費需求，第二版才真的把事情辦完

先看一個很多團隊都踩過的現象。

你接到一個需求：客戶在電商平台申請退費，系統要回覆他能不能退、怎麼退。第一個工程師用 RAG（Retrieval-Augmented Generation，檢索增強生成，意思是先去資料庫撈相關文件，再讓模型根據撈到的內容回答）做了一版。使用者問「我要退費」，系統撈出退費政策文件，把條文貼給模型，模型整理成一段話回覆。看起來很完整，政策講得清清楚楚。

第二個工程師交出來的東西長得不太一樣。同樣問「我要退費」，系統先讀政策，發現要判斷能不能退，得先知道是哪一筆訂單，於是反問使用者訂單編號；拿到編號後它去資料庫查這筆訂單的購買日期、商品狀態、是否已出貨，比對政策算出符不符合退費條件，最後不只回覆能不能退，還告訴使用者預計幾個工作天到帳。

兩版都用了同一個大語言模型，第一版卻只是一張會講話的政策海報，第二版才真的把事情辦完。差別在哪？這就是這篇文章要拆開的東西。RAG 只是一個工具，真正讓系統能把事情辦完的，是它外面那層結構。吳恩達（Andrew Ng）用 agentic workflow 這個詞，強調的就是這層結構：把 prompt、記憶、外部工具用一套設計編排起來，讓系統能規劃、能行動、能修正，而不只是生成一段文字（Andrew Ng, DeepLearning.AI, The Batch, 2024）。中文可以理解成有結構的 AI 工作流。

這篇要回答的問題是：當你要設計這層結構，你的腦袋要從工程師換成什麼？答案藏在四個從傳統軟體到 agentic workflow 的轉變裡，而其中最反直覺的一個，是你得學會像經理人一樣思考。

工作流設計，決定模糊判斷做得穩不穩

91APP CDMP 團隊每天都在處理一種介於兩者之間的活：把客戶的購買行為、會員資料、行銷成效拼成可以行動的判斷。這類工作有一半是規規矩矩的資料運算，另一半卻是模糊的判斷題，例如這個會員該不該被歸到沉睡族群、這檔活動的受眾要怎麼圈。

當 AI 開始接手後半段，我們很快發現一件事：能不能把這套東西做穩，跟用了多強的模型關係不大，跟你怎麼設計工作流關係很大。設計得好，AI 是個靠譜的同事；設計得不好，它是個會自信地給你錯答案的實習生。這也是為什麼，當每個品牌都用得到 AI 的時候，真正拉開差距的不是模型本身，而是底層的資料與設計。所以我們把這篇寫成一份設計者的筆記，講原理，不講產品。

Agentic workflow 在四件事上跟傳統軟體翻轉

要看懂 agentic workflow 跟傳統軟體哪裡不一樣，最乾淨的切法是看四件事在兩種系統裡長什麼樣。下面這張表先給你一個全貌，後面每一段再展開。

這四個轉變裡，前兩個是材料變了，第三個是設計哲學變了，第四個是驗收方式變了。最重要也最難適應的是第三個。一個習慣寫微服務的工程師，腦袋裡的預設是把每一步都規定死；但在 agentic workflow 裡，你規定得越死，AI 能發揮的價值越少，也越僵硬。

要補一句：這張表是為了把差異講清楚才二分，實務上多數可靠的系統是混合架構，確定性服務、LLM 編排、檢索、評估、人類複核同時並存，不是二選一。接下來的兩段，先把材料的變化講清楚，這是後面所有設計決策的地基。

確定性的活交給程式，模糊的判斷才交給模型

回到開頭那個退費例子，用它來感受 deterministic 與 probabilistic 的差別。

deterministic（確定性）的意思是：同樣的輸入，永遠得到同樣的輸出。傳統程式幾乎都是這樣。你寫一段 if 判斷，購買日期距今小於七天且商品未拆封，就回傳「可退」，否則「不可退」。這段邏輯跑一萬次結果都一樣，錯了你也找得到是哪一行錯。

probabilistic（機率性）的意思是：大語言模型在做的，是為下一個 token（模型處理文字的最小單位，中文約一到兩個字一個 token）估計一個機率分布，再從裡面挑字。如果採樣設定允許隨機性，你問同一句話兩次，回覆的措辭甚至判斷都可能有微妙差異。把 temperature（控制隨機程度的參數）調到零或固定 seed，輸出可以高度可重現；但就算可重現，模型的判斷仍不是傳統規則引擎那種可以形式化保證的對錯。這不是 bug，是這類模型的運作方式。

於是退費這件事其實藏著兩種性質不同的工作。判斷一筆訂單符不符合退費條件，購買日期、出貨狀態、金額，這些是結構化資料配上明確規則，是 deterministic 的活，應該交給傳統程式算，又快又穩又便宜。而理解使用者那句語意含糊的「我東西不想要了能不能處理一下」、把它對應到退費意圖、用人話回覆，這是 probabilistic 的活，交給模型。

這帶出 agentic workflow 的第一條落地原則：能用 deterministic 解的就用 deterministic 解，剩下真的需要彈性判斷的模糊部分，才交給機率性的模型。要講清楚的是，退費整件事既不是全部交給程式，也不是全部交給 AI。資格計算這種可形式化的部分由規則服務算出結果，agent 負責的是蒐集必要資訊、解釋結果、處理例外情境與該升級時找人。很多系統不穩，是因為把本來該寫死的規則丟給模型去猜，結果模型每次猜的不太一樣，整個系統就飄了。這也是為什麼當零售品牌要把行銷自動化從 CDP 升級到能承接 AI 的資料底座時，資料怎麼結構化、哪些該算哪些該判，會直接決定工作流穩不穩。

經理人思維，是把怎麼做的決策權交出去

現在進到最關鍵的轉變，也是技術含量的主場：架構從微服務的精確控制，換成經理人思維（Think like a manager）。

先講表象。微服務的世界裡，工程師是流程的編劇兼導演，每一個鏡頭怎麼拍都寫好了：先呼叫 A 服務，拿到結果傳給 B，B 算完丟給 C，任何一步的輸入輸出格式都是契約。這套東西的好處是可預測，壞處是不會應變，遇到劇本沒寫到的狀況就當機。

再看機制。Anthropic 在它那份被廣泛引用的工程指南裡，把這類系統分成兩種：workflow 是 LLM 與工具被預先寫好的程式路徑編排，agent 則是 LLM 自己動態決定要做什麼、用哪個工具、怎麼把任務完成。它同時強調一個務實的態度：從足夠簡單的架構開始，只有真的需要時才增加複雜度（Anthropic, Building Effective Agents, 2024）。經理人思維對應的就是後者那種把控制權部分交出去的設計。

底層原理是這樣。一個好的經理人不會告訴資深員工「第一步打開這個檔案，第二步複製這欄，第三步貼到那裡」，他會說「這季要把這個客群的回購率拉起來，預算這麼多，這幾條紅線不能碰，怎麼做你決定，做完跟我回報」。他給的是目標、資源、邊界，把怎麼完成的決策權交給有能力的人。

在 agentic workflow 裡，設計者就是那個經理人，AI 是那個資深員工。你不再寫死每一步，你寫的是：你的角色是什麼、目標是什麼、有哪些工具可以用、哪些事絕對不能做、什麼情況要回來問人。退費例子裡第二版之所以會主動要訂單編號、會自己去查資料庫，並不是因為工程師逐句寫死了每段對話。設計者沒有把回覆寫死，但仍然要定義必要欄位、工具的輸入格式、缺欄時的補問規則與停止條件。在這組約束下，模型推導出「要判斷退費得先有訂單編號」，於是去要、去查。

這套讓模型把推理與行動交錯進行的做法，學術上把它框架化講清楚的代表作之一，是 ReAct 這篇論文：讓模型一邊產生推理軌跡、一邊產生行動，推理幫它規劃和處理意外，行動讓它能去外部資料源拿真實資訊（Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, arXiv 2210.03629, 2022）。退費第二版那段「發現要判斷得先知道訂單，於是去要編號、去查庫」，就是推理與行動交錯的具體樣子。

經理人思維難就難在：它要求設計者放手，但放手不等於放任。一個只會說「你看著辦」的經理人會把團隊帶進溝裡，一個好經理人給的方向和邊界精準到讓員工有空間又不會出格。下一段就講，這個邊界具體要怎麼設計。

設計一個 agent，先調好三個核心旋鈕

當你決定用經理人思維設計，最核心、最常先動的旋鈕有三個。把這三個想清楚，一個 agent 的骨架就立起來了。

1. Prompt：賦予角色與權限。這是你寫給員工的職務說明。你在這裡定義 AI 扮演什麼角色（你是退費客服專員）、能做什麼（可以查訂單、可以告知處理時程）、不能做什麼（不可以承諾政策以外的補償、不可以未經確認就執行退款）。寫得越具體，行為越可控。模糊的 prompt 是飄移的源頭。
2. Context Management：在有限的視窗裡塞對的資訊。每個模型一次能讀的內容有上限，這個上限算的是 token 不是字數，叫 context window（上下文視窗，可以粗略想成模型的桌面，一次只攤得開這麼多紙）。桌面就這麼大，如果你塞進去的東西沒有經過篩選與排序，越雜就越可能稀釋掉重點。所以管理 context 的核心不是塞越多越好，是塞對的。這一點下一段單獨展開，因為它最常被做錯。
3. Tools：讓 AI 真的能做事。工具大致兩類，一類是做事型，例如執行退款、發送通知，會改變外部世界的狀態；一類是查資料型，例如查 CRM、查訂單、搜尋知識庫，只讀不改。這兩類的風險天差地遠，查錯了頂多答錯，做錯了可能真的退錯一筆錢出去。所以給工具時，這兩類要分開設計權限與護欄。

這三個旋鈕裡，Prompt 決定 AI 是誰，Tools 決定 AI 能碰什麼，Context Management 決定 AI 在當下這一步知道什麼。要提醒的是，三個調好只是骨架立起來，真正進到生產環境，還有模型選擇、執行迴圈、停止條件、評估與護欄這些系統層的設計不能省。

記憶分兩層，才不會在長對話裡失焦

Context Management 值得單獨講，因為它牽涉一個很多人沒意識到的設計：記憶要分層。

問題的根源是 context window 有限。一段對話如果一路累積，從第一句話到第五十句全部塞回去，桌面很快就滿了，而且大部分是無關的舊資訊，真正關鍵的當下資訊反而被埋掉。模型讀著一桌子雜訊，判斷自然會飄。

一個實用的切法是把記憶分成兩層，借用作業系統的概念。

第一層是工作記憶（working memory），放當下這一步真正要用的東西：使用者剛說的話、剛查到的訂單資料、現在要做的判斷。這層要小、要乾淨，只放現在用得到的。

第二層是歸檔記憶（archival memory），放需要長期保存但當下不一定要攤開的東西：完整的對話歷史、使用者過去的偏好、之前處理過的案件。這層可以很大，存在外部，需要的時候才去撈相關的那一小段拉進工作記憶。

這兩層的分工，跟人類做事的方式如出一轍。你處理一個案子時，桌上只攤開這個案子的卷宗（工作記憶），其他幾百份卷宗收在檔案櫃裡（歸檔記憶），要用到哪份再去抽。沒有人會把整個檔案櫃都倒在桌上。落到實作，桌面對應的是當下這次呼叫送進 context window 的內容，檔案櫃則常常是向量資料庫或外部儲存，需要時才檢索相關片段放上桌面。這個雙層切法是常見且好用的抽象，但不是唯一解，不同系統也可能拆成 session 狀態、摘要記憶、向量檢索或使用者偏好檔。共同的精神是：不是讓模型記得越多越好，是讓它在每一步都只看到當下該看的，其餘的收好、要用再撈。一個 agent 會不會在長對話裡漸漸失焦、開始答非所問，多半就看這層分工有沒有做好。

自主權三檔，看的是錯了還收不收得回來

設計到這裡，最後一個、也是最攸關風險的決策浮現了：你要放手放到什麼程度。這不是是非題，可以用三個實務檔位來理解。

1. Hardcoded steps（寫死步驟）：你把每一步都規定好，AI 只在你允許的格子裡填空。最安全也最僵硬，遇到劇本外的狀況就卡住。適合流程穩定、不容出錯、合規要求高的場景。
2. Hardcoded tools（寫死工具）：你不規定步驟，但你給定一組工具，讓 AI 自己決定怎麼組合使用。這是目前生產環境很常見的折衷設定，因為它在彈性與可控之間取得平衡：AI 有空間應變，但它能碰的東西被你框死在那組工具裡，不會跑去做你沒授權的事。
3. Fully autonomous（完全自主）：你給 AI 寫程式或自由搜尋的能力，讓它自己想辦法解題。能力最強，能處理你完全沒預料到的問題。風險也最高，如果沒有 sandbox（隔離執行的沙箱）與權限邊界，它能做的事就容易超出你的預期，所以越接近完全自主，越需要在環境層做隔離、白名單、花費上限這些圍欄。

選哪一檔，取決於這件事錯了會怎樣。退費客服這種會動到錢的場景，多數團隊會停在第二檔，把退款這個動作再加一道人類確認；而一個只負責整理內部報表草稿的 agent，給到第三檔也無妨，反正它產出後還有人看過才用。

吳恩達歸納的四種 agentic 設計模式也是同一個精神，反思、工具使用、規劃、多代理協作，每一種都是在不寫死步驟的前提下，靠結構讓模型自己把事情做得更好（Andrew Ng, DeepLearning.AI, The Batch, 2024）。自主權的本質是放手到哪裡還收得回來。

護欄按風險分級，而不是事事都要人簽

放手不等於不管。自主權越高，護欄越要設計得好，這就是 human-in-the-loop（人類在環中，意思是在 AI 的流程裡保留人類介入或核可的關卡）。

怎麼設才不會變成事事都要人簽、把自動化的好處全抵消掉？業界較成熟的做法是按風險分級設關卡。OpenAI 那份建構 agent 的實務指南建議：先幫每個工具評風險等級，看它是唯讀還是會寫入、操作可不可逆、要不要高權限、有沒有金錢影響；風險高的工具在執行前自動暫停、等人核可才放行，風險低的就讓它自己跑（OpenAI, A Practical Guide to Building Agents）。除了動作本身的風險，還有兩種情況也值得設成觸發人類介入的關卡：一是 AI 連續失敗或重試超過你設的門檻，二是它信心不足、缺少必要資訊還硬要往下走。

落到退費那個 agent，分級長這樣。查訂單、查政策是唯讀、可逆、零金錢風險，放它自己做。實際執行退款是會寫入、動到錢、不容易回收，這一步在執行前暫停，把它要退的這筆攤給人看，人點頭才執行。同一個 agent，不同動作給不同等級的把關，自動化的效率和高風險動作的安全才能兼顧。

這裡可以舉一個我們自己的場景。91APP CDMP 團隊在做受眾圈選時，撈名單、算分群這種唯讀的活可以讓工作流自己跑，但真要把一群會員推進某檔行銷活動、發出通知之前，會留一道人看過再放行的關卡。原因跟退費一模一樣：撈錯了重撈就好，發錯了訊息收不回來。設計護欄的判準從來不是這件事複不複雜，是這件事錯了能不能救得回來。

把這套整理成一份可執行的設計檢查清單：

1. 先分流確定性與機率性。把需求拆開，能用規則和資料庫算出來的歸 deterministic，需要理解語意或彈性判斷的才歸模型，別把該寫死的規則丟給模型猜。
2. 用經理人思維寫 prompt。給角色、給目標、給邊界、給回報條件，同時定義必要欄位與缺欄補問規則，不要寫死每一步操作。
3. 把工具分成做事型與查資料型。兩類分開設權限，做事型一律比查資料型多一層審視。
4. 記憶分兩層。工作記憶只放當下這一步要用的，其餘進歸檔記憶、要用再撈，別讓 context 被舊資訊塞爆。
5. 自主權從低往高給。先用寫死工具這一檔起步，跑穩了再評估要不要放更多，別一開始就給完全自主。
6. 護欄按風險分級。唯讀可逆的放手跑，會寫入、動錢、不可逆的加人類核可關卡，連續失敗或信心不足也設成介入點。
7. 測試要疊代。別期待跑一次就定案，agentic 系統要反覆觀察它在各種輸入下的行為，再回頭調 prompt、調工具、調護欄。

配發資源與設好檢核點，系統才長得出彈性

回到開頭那兩版退費系統。第二版之所以贏，不是因為它的模型更強，是因為它的設計者想清楚了：哪些交給確定性的程式、哪些交給機率性的模型、給 AI 哪些工具、放多大的自主權、在哪裡留人類的關卡。

agentic workflow 真正的門檻，從來不在你會不會接 API、會不會寫 RAG，而在你願不願意把腦袋從寫死每一步的工程師，換成給方向與邊界的經理人。捨棄逐行寫死的控制慾，學會劃定邊界、下放工具、設好檢核點，這個轉變一旦發生，你看待 AI 系統的方式會徹底不同：你不再問「這一步該怎麼寫程式」，你開始問「這個員工需要知道什麼、能碰什麼、什麼時候該回來問我」。

當你開始用經理人的方式配發資源、設定檢核點，你設計出來的就不會是一張會講話的政策海報，而是一個真的能把事情辦完、而且辦錯了還救得回來的系統。

常見問題

Q1：agentic workflow 和一般說的 AI agent 有什麼不同？ agentic workflow 是吳恩達常用的講法，重點放在把 prompt、記憶、外部工具組成有結構的工作流，讓系統能規劃、行動、修正，而不是糾結它算不算一個 agent。Anthropic 則把 workflow 定義為用預先寫好的程式路徑編排，agent 是 LLM 自己動態決定流程。實務上重點在那層編排結構，不在標籤。

Q2：用經理人思維設計，API 的 token 成本會不會暴增？ 做得好反而能省。把確定性的計算交給傳統程式而不是丟給模型,可以少掉大量無謂的推論呼叫;記憶分兩層、只把當下要用的放進 context window,也能避免每一步都把整段對話歷史重送一次。成本失控通常不是因為用了 agent,而是因為沒有分流計算、沒有管理 context、又把自主權開太大導致無謂的重試。

Q3：deterministic 和 probabilistic 的差別是什麼？ deterministic 確定性指同樣輸入永遠得到同樣輸出，傳統程式多半如此。probabilistic 機率性指模型為下一個 token 估計機率分布再挑字，採樣允許隨機時同樣輸入可能略有不同；把 temperature 調零雖可重現，模型判斷仍不像規則引擎那樣可形式化保證。設計原則是能用確定性程式算的就用程式算，只把需要彈性判斷的模糊部分交給模型。

Q4：agent 的記憶為什麼要分工作記憶和歸檔記憶？ 因為模型一次能讀的 token 有上限，也就是 context window。工作記憶只放當下這一步要用的乾淨資訊，歸檔記憶存完整歷史與長期偏好、需要時才撈相關片段進工作記憶，實作上常對應到向量資料庫或外部儲存。這樣模型每一步都只看到該看的，不會被舊資訊塞爆而失焦。

Q5：agent 自主權的三個檔位該怎麼選？ 三檔分別是寫死步驟（最安全最僵硬）、寫死工具（給一組工具讓 AI 自己組合，生產環境很常見的折衷）、完全自主（給寫程式或搜尋能力，最強但風險最高，需要 sandbox 與權限邊界）。選擇取決於這件事錯了的代價：高風險場景停在寫死工具並加人類確認，低風險場景才考慮放更多自主權。

Q6：human-in-the-loop 的人類關卡要設在哪裡？ 按風險分級設，而不是事事都要人簽。先評估每個工具是唯讀還是寫入、可不可逆、有沒有金錢影響，唯讀可逆的放手讓 AI 跑，會寫入、動錢、不可逆的動作在執行前暫停、等人核可。另外連續失敗超過門檻、或 AI 信心不足缺資訊時，也該設成介入點。判準是這件事錯了能不能救得回來。

Q7：這種帶機率的模糊系統，測試時怎麼知道這次成功不是運氣好？ 靠疊代式的觀察與評估，而不是跑一次就定案。準備一組涵蓋常見與邊界情況的測試輸入，反覆觀察 agent 在這些輸入下的行為是否穩定，記錄它的推理軌跡與工具呼叫，看它在劇本外的狀況怎麼反應。單次成功不算數，要在多次、多樣輸入下都能穩定通過，才算這版設計站得住。

工作流設計只是開始。要判斷系統到底做對沒有，接著看 你的 AI 到底做對沒有 的評估框架；要把單一 agent 擴成協作團隊，看 先拆解任務，再決定要不要 multi-agent 的架構取捨。源頭概念見 LLM 的四個限制與擴增地圖。

延伸閱讀

1. 選 CDP AI Agent 前先問 4 個問題：把本文的設計視角換成採購視角，看選型時該追問哪些工作流設計問題。
2. 如何挑選 CDP AI Agent：從設計者轉成使用者，怎麼判斷一個 AI agent 的自主權與護欄設計合不合用。
3. 破解 AI 神話：MCP 報表到 RAG 的陷阱、人機協作：延伸本文 human-in-the-loop 的精神，談 RAG 與人機協作的真實邊界。