前陣子出了一部影片講解 Stanford 的 AI 系統建構教學
影片中有提到像是 RAG, Prompt Engineering
模型微調還有 Agentic Workflow 這些重要的觀念
也有很多粉絲來信問我能不能拍一系列的影片
針對這些觀念進行比較詳細的教學
所以今天我想聊聊 agentic workflow
裡面很重要的觀念，task decomposition
現在前沿模型的能力絕對已經夠強了
能勝任絕大多數的任務
但還是有許多人會覺得模型表現不佳或者產出不靠譜
根據我過往的諮詢案例
其實大多數人只是不知道如何把一個大任務
拆成 agent 可以跑得動的小任務
這件事聽起來可能有點無聊，可能有點簡單
但相信我，如果你是技術人員
好的任務拆解能力可以幫你構建一個更穩定的系統
如果你是非技術人員
你更要知道怎麼把自己的日常執行專案拆小塊一點
然後委派給 AI
而不是一大包丟進去導致 agent 消化不良
那我們直接開始
首先我想要先把這部影片中會用到的三個名詞定義清楚
分別是 Human SOP， skill，還有 agentic workflow
三個東西很多人會搞混
但其實它們的層級跟功能完全不一樣
沒有先分清楚，後面你只會聽得一頭霧水
第一個是 Human SOP
就是傳統的流程檔案
這份檔案會告訴你第一步做什麼，第二步做什麼
遇到例外怎麼處理
旁邊還有一堆小提醒和經驗談
傳統的流程檔案可能是一份簡報，可能是一份 word 檔
但本質上都是寫給人看的 SOP
這型別的檔案給人類看完全沒問題
因為你的腦中會自動補進一堆 context
會自己判斷哪一步可以偷懶，哪一步一定要做
比方說在 SOP 檔案裡面寫到申請完之後送主管簽核
看到這句話之後，你可能會有能力判斷
如果是兩百塊以內的小金額
主管寧願你不要去煩他，直接跑完這個流程
但如果今天這筆金額超過五千塊
你可能就得照著規矩來
或者至少口頭知會主管一聲
這些判斷可以被寫進 SOP 檔案裡面
但需要花時間去把例外狀況給列出來
更何況很少人真的熱愛維護檔案
口頭提醒一下新同事永遠比維護檔案更方便
這種狀況在中小型企業更是經常發生
但這樣的 SOP 對 agent 來說
就是一坨非結構化的文字
理解成本高，執行時容易忘東忘西
只要你沒有 specify
AI 不會知道對你們團隊來說兩百塊跟五千塊有什麼差別
不會知道哪一步可以省略
不會知道遇到例外的時候要繼續做還是停下來問人
第二個是 skill
在我之前的影片有講過
skill 本質上就是把你做事的方法論，判斷標準，踩過的坑
打包成一個資料夾交給 agent
裡面通常有三個東西
第一個是 SKILL markdown
這個是人類寫給 agent 的 SOP 加心法
也是 skill 的核心檔案
第二個是 references
存放額外的參考資料
比方說範例輸出，術語表，過去踩坑的紀錄
有需要時 agent 可以自行取用
第三個是 scripts
是可以直接執行的指令碼
處理那些確定性的操作
比方說檔案 parsing，格式轉換
這種傳統軟體工程就能做到的事
一個 skill 對應的是單一任務，不是整條工作流
常用的命名方式像是 weekly-report-drafting
pdf-processing，還有 invoice-categorization
看名字就知道它做什麼，什麼時候該被 trigger
但在設計 skill 時
這個 skill 的防守範圍要拆多大是關鍵
防守範圍如果太大
容易讓人感覺樣樣通，但又都做得差強人意
防守範圍太小就變成每走一步都要去讀 skill
等於是把現在的模型當小孩子，什麼都要聽人類的
那具體怎麼拆我等等會再深入講解
第三個是 agentic workflow
也就是一整條由多個 agents， tools， skills
資料源組成的工作流
agentic workflow 不是一個單純的 prompt
更像是一條生產線
有人負責理解問題，有人查資料
有人執行動作，有人寫報告
中間呼叫各種工具， API，資料庫
還有你之前寫好的 skills
agentic workflow 更像一間工廠
只是裡面全都是 AI 夥伴在幫你做事
那我快速統整一下剛剛講到的三個名詞定義
Human SOP 是給人看的紙本流程
skill 是把流程跟方法論打包給 agent 的執行單位
agentic workflow 是把多個 skill 加上工具串起來
一條完整的生產線
這條生產線跑完，你的任務也就完成了
而這隻影片的重點
就是怎麼把原本寫給人看的 Human SOP
轉成一條 agentic workflow
讓 agent 可以理解，並且幫你穩定執行
不過講到這裡
很多人心中可能會有個疑問
反正現在模型能力越來越強
或者有一天達到 AGI 後
我也不用說那麼多了
反正就是指哪打哪，使命必達
但答案大機率是不行
我舉一個生活化的例子你們就懂了
假設你今天要出遠門，臨走前請了一位幫手
只交代他把家裡打掃乾淨
然後什麼都沒多說就出門了
等你回家，大機率會出事
因為你跟他對乾淨這個詞的定義可能完全不一樣
你心目中的乾淨
是地板不黏腳，桌面清爽沒一堆紙
廚房水槽沒有碗，垃圾都倒掉了
但幫手心目中的乾淨
可能是東西有歸位就好，看得順眼就算
反正角落裡，櫃子後面那些看不到的地方
不用特別去動它
結果就是表面上好像有掃
但你在意的那些地方一個都沒動到
所以問題從來不是幫手夠不夠聰明
或者模型表現好不好
就算他什麼都會，什麼都懂
你沒告訴他你在想什麼
只要沒有讀心術
他就永遠滿足不了你的需求
這也是為什麼
就算有一天 AGI 真的來了
有人做出了一個跟真人一模一樣的 AI 居家幫手
你還是得跟他磨合
所謂磨合，就是他得透過日常相處慢慢累積你的偏好
第一個月他知道你是極簡主義者
桌面只想要有必要的東西，不想要有任何雜物
第二個月他知道你很愛惜自己的不沾鍋
所以刷的時候要用菜瓜布黃色的那一面
這些事沒有寫在任何說明書上
但你就是很在意
而不知道這些事情的機器人
再聰明都會看起來像笨蛋
這個道理放到 agentic workflow 上也是一樣的
很多人第一次接觸 agent
直覺就是找一個最強的模型
把任務整包丟給它，讓它從頭跑到尾
這就是所謂的 mega agent
也就是前面說的那個幫手
你跟它說幫我最佳化整個開發流程
它一定會做點什麼出來
可能寫一份洋洋灑灑的最佳化建議
可能改一堆 config 檔
可能 refactor 一個你根本不該動的模組
但你完全不知道到底哪一段推理是對的
哪一段工具調錯了
哪一段是它幻想出來的
哪一段根本不該讓它自動跑
整坨丟進去，整坨吐出來
中間發生什麼你看不見
就算想 review 也找不到下手點
我看過太多新手卡在這個地方
他們第一個反應永遠是
再換一個更強的模型或者再寫一個更詳細的 prompt
但其實問題不在模型，也不在 prompt
而是任務本身太大，太模糊
所以每次執行都像是在買彩券
反過來，如果你把任務拆成一串小 task
每一個 task 都有明確的 input
明確的 output，明確的成功標準
那就完全不一樣了
比方說同樣是處理客戶 ticket
你可以拆成這四個 agent
一個只負責分類
一個只負責查資料庫找出相關歷史紀錄
一個只負責寫回覆草稿
再加一個 sub-agent 專門做 QC
確認回覆有沒有事實錯誤或政治不正確
每個 agent 或許都很笨
但每個 agent 都做一件很明確的事
出錯了你回去看 log
發現是分類的時候把客訴判定為諮詢需求
你就改分類的那一份 SOP 就好
不需要動到查資料的
不需要動到寫回覆的
不需要動到 QC 的
哪裡壞改哪裡，對症下藥
現在很多企業級的 agentic workflow 框架
在做的就是這件事
把複雜的流程拆成一串工作流
每一段由一個小 agent 或一段明確的 automation 處理
為什麼這些大公司不直接用 mega agent？
因為他們要上 production
他們需要的是穩定性，可觀測性，可修復性
一個你看不到內部的黑箱
永遠沒辦法 production-ready
因為你根本不敢讓它上線
所以 divide and conquer
也就是所謂的分而治之的老觀念
在 agent 時代反而更重要
你不是在訓練一個超人 agent
而是在設計一條生產線
一條真的能上線的生產線乍看之下非常無聊
但它可預測，有邊界，出錯可以修
而這些才是最關鍵的
知道為什麼要拆之後
接下來的重點就是怎麼拆
我們先用洗衣服這件事情當作例子
你今天教家裡的小孩子洗衣服
可能會跟他說
你就把衣服丟進去，加洗衣精，按開始
等洗完之後把衣服拿去曬
就這樣，沒了
這是一份典型的 Human SOP
為什麼人類看得懂？
因為你的腦中會自己補一些判斷
比方說白襯衫最好分開洗
不然會被牛仔褲染色
毛衣不能丟洗衣機，要手洗否則會縮水
天氣不好就不要用晾的了，直接用烘衣機
這些東西你可能都沒講
但你的小孩子會根據過去跟你生活的經驗
收斂出你的偏好
所以能夠避開這些坑，把這些東西給默默補起來
但你把這段話原封不動丟給 agent
跟它說幫我做一個洗衣服的 workflow
它會用教科書式的方法幫你處理好
但他可能不知道你們家從來不烘衣服
或者所有衣服都要放洗衣袋避免鬆掉
結果實際跑完一輪後衣服縮水或者出現荷葉邊
這就是 Human SOP 直接丟給 agent 的下場
所以我們需要一套方法論
把這份簡單扼要
但很吃個人腦補能力的 Human SOP
轉成 agent 可以直接吃的 agentic workflow
我把它整理成四步，我們一步一步來
首先是格式標準化
這一步要做的事情很簡單
就是把這份 Human SOP
改成 agent 能夠讀懂的版本
在做這件事情的時候，重點有三個
第一是引數化
你不要在 SOP 裡寫死一定要用 normal 模式
因為這樣 SOP 只能 cover 一種情境
你要改成用 mode， temperature 這種引數
讓 SOP 變成一個 template
呼叫的時候根據實際狀況帶不同的值進去
比方說 mode 可以是 quick， normal
還有 delicate 三選一
temperature 可以是 cold， warm
還有 hot 三選一
這樣一來，同一份 SOP 就可以 cover 各種洗衣服的場景
這件事很關鍵
SOP 一旦寫死，它就沒辦法重複使用
我看過太多人寫 skill
寫到最後變成一份只 cover 一種特殊情況的長文
那這份 skill 的容錯率就會非常低
當你分享給別人時
可能會少了環境引數或者其他的設定而直接報錯
第二個是 MUST， SHOULD， MAY
這個是 RFC 2119 的寫法
本來是用在網路協定的規格書上的
但我發現拿來寫 agent SOP 超好用
因為它強制你把每一條規則的強度給想清楚
MUST 是硬性規定
agent 必須做，絕對不能跳過
SHOULD 是建議作法
有強烈理由的話可以不做，但要明確說明原因
MAY 則是 optional 的專案，做不做都可以
舉例來說
agent 的 MUST 可能有
先檢查每一件衣服的洗標
把白色跟深色分開
啟動洗衣機後等待完成
agent 的 SHOULD 可能有
根據衣物材質選擇合適的洗衣模式
根據今天的天氣決定要不要用烘乾
agent 的 MAY 可能有
在濕度大於百分之七十的時候使用烘乾機
否則 MUST 改用晾乾的方式
你看，每一條規則的強度都很明確
agent 看到就知道哪些不能討價還價
哪些可以根據 context 自己判斷
第三個是結構化格式
用 Markdown 把區塊切清楚
把 Parameters， Steps， Error Handling
這每個區塊都分開
既讓人看得懂
也方便之後塞進 MCP 這類標準介面裡
當成 agent 的行為規格
新來的朋友們如果不知道 MCP 是什麼
我後面會再提到
這樣處理完之後
你手上的東西就不再是一篇給人看的散文
而是一份 agent 真的讀得懂的 SOP
但光是 SOP 寫得漂亮還不夠
這只是把 Human SOP 翻譯成 agent 能讀的格式而已
你還沒有真的拆解任務
所以我們進到第二步
也是 task decomposition 的核心
叫做任務拆解與連結
簡單講就是把它 decompose 成 pipeline steps
每一個 step 都是 pipeline 裡的一個獨立節點
洗衣服這件事拆開來就是這四節
分類衣物，檢查口袋汙漬，設定機器
決定要晾衣還是烘乾
每一個步驟都是 pipeline 的獨立節點
有自己的 input，有自己的 output
可以獨立執行，獨立 debug
甚至獨立替換成新的邏輯
我為什麼要這麼強調獨立這兩個字？
因為這會奠定後面的所有好處
舉個例子
如果分類衣物這個步驟有 bug
把白色 polo 衫誤判成深色衣物
你只要修這一段就好
後面的設定機器，決定晾或烘的邏輯完全不用動
但如果你寫的是 mega agent
全部塞在一個 prompt 裡
一旦出錯就只能整個重寫
因為你根本不知道是哪一段邏輯出了問題
除此之外，這樣做的好處是
每一節都可以變成一個小 skill
甚至一個小 agent
比方說我們可以做一個 agent 只負責分類
吃進去衣物列表，吐出來分類結果
另一個 agent 只負責根據分類結果
決定洗衣機的 mode 和 temperature
再下一個 agent 負責判斷天氣
然後決定走晾乾還是烘乾
三個 agent 各自做一件很笨，有點無聊
但超級明確的事
加起來就是一條完整的洗衣服 workflow
那這些 agent 之間靠什麼串接呢？
答案是 artifacts
也就是上一個 agent 的 output
變成下一個 agent 的 input
比方說分類 agent 的輸出是一份 JSON
會告訴你 whites 裡有哪幾件
darks 裡有哪幾件
delicates 裡有哪幾件
unknowns 裡有哪幾件
這份 JSON 就直接變成設定機器那個 agent 的 input
設定機器的 agent 看到 JSON
自己根據規則決定每一批應該怎麼洗
吐出來一份洗衣服的設定
再交給下一個 agent
一個節點連結另一個節點
靠的不是魔法
不是大型語言模型之間的心電感應
而是清楚定義的 input， output
和中間的 artifact 格式
第二步講完了，第三步是雙向開發
這一步很多人會忽略
但其實是整個四步裡最重要的
為什麼？
因為你的第一版 SOP 一定會有問題
無論你是多資深的工程師
多會設計流程的 PM
第一版 SOP 拿出來跑，一定會出包
為什麼我可以這麼篤定？
先介紹一個名詞叫做默會知識
英文是 Tacit Knowledge
又稱內隱知識
是指那些難以用文字，言語或圖表明確表達
存在於個人大腦與身體記憶中的知識
我協助過太多團隊做 SOP 自動化
而 SOP 的本質是
把腦中的默會知識轉成文字明示規則
而默會知識的特性就是
你自己不會發現它的存在，直到它出錯
你以為你寫完了
但其實腦子裡還有十幾條沒寫進去的判斷標準
要等 agent 真的跑出去，撞牆了，出錯了
你才會發現
啊，原來這條我沒寫到
那所謂的雙向開發其實就是為了持續迭代
實際執行時大概會長這樣子
你先用自然語言跟 agent 說
我平常洗衣服大概是這樣這樣這樣
請你幫我寫一份 SOP
然後 agent 就會幫你寫好第一版
接著你照這份 SOP 實際跑一次 workflow
跑完後發現它把所有 t-shirt 都丟進超高溫烘乾機
結果縮水到直接穿不下
這時候你就會意識到 SOP 哪裡寫得不夠清楚
於是你回頭把那份 SOP 補上一條規則
agent 不可以把含棉量超過 80% 的衣物用高溫烘乾
然後下一輪它就不會再犯這個錯了
不過當你再跑一次的時候
可能又發現另一個問題
比方說它沒有把衣服裝進洗衣袋
好，那你就再補一條 SOP
這個過程不斷重複
每一輪 agent 都會踩到一個你之前沒想過的坑
於是你就把那個坑補起來
幾輪下來之後
SOP 會穩定到能滿足大多數的使用情境
而剩下的 5% 是真正的 edge case
那就用 human-in-the-loop 的方式處理
這件事我們等下會講
不是你關在房間裡想像一份完美的 SOP
然後丟給 agent 跑
而是你跟 agent 一起跑
一起 debug，一起 iterate
根據真實的執行結果持續修復，迭代 SOP
之前有一位客戶花了兩個月
寫了一份所謂的完美 agent SOP
結果跑一次就垮了
因為他們 cover 的全是想像中的情境
現實中根本不會發生
後來我跟他們一起秉持 scrum 精神
改成用小步快跑的方式
兩天寫一個粗糙版本
然後一個禮拜內跑五十次 iteration
兩週內就上線
速度的關鍵不是寫得多完美
而是迭代得有多快
講完雙向開發
接著進到最後一步，整合與執行環境
這一步是決定你的 agent
到底是 demo 還是真的能在 production 跑的關鍵
再漂亮的 SOP
如果沒接到真實世界的工具
它就只是一份檔案，但永遠不會自己動起來
在洗衣服的例子裡
工具就是洗衣機，烘乾機，天氣 API 這些
你的 agent 要能真的去查今天會不會下雨
要能真的啟動洗衣機
光是腦袋裡知道應該這樣做是沒用的
要真的做出來才行
對 agentic workflow 來說
工具就是你的公司內部系統
資料庫， API，檔案系統
版本控制， ticketing system 這些
問題是這些東西每一家公司都長不一樣
你今天為 A 公司寫的 agent
搬到 B 公司可能完全動不了
這就是 MCP
也就是 Model Context Protocol 想解決的事
MCP 是一個開放協定
它的目的是讓 LLM， agent
可以透過同一套標準去呼叫外部的 tools
resources 還有 prompts
我自己最喜歡的比喻是
MCP 就像 AI 世界的 USB-C
以前你買新的筆電，新的手機，新的滑鼠
每個東西插頭都不一樣
每出一臺新裝置就要再買一堆轉接線
USB-C 出現之後全部統一了
一條線可以接所有東西
MCP 對 agent 來說就是這個角色
不管你用 ChatGPT，用 Claude，用 Cursor
還是用其他 agent host
只要它支援 MCP
就可以用同樣的方式去呼叫工具
今天你寫好一個 Slack MCP server
明天 ChatGPT 跟 Claude 都能用
不需要為了不同 host 各寫一套整合
接好工具之後
最後還要做一件事
那就是設計 human-in-the-loop 的 checkpoint
什麼是 human-in-the-loop？
簡單講就是在某些決策點
agent 必須停下來請人類確認
高風險的決策之前
agent 要先停下來等人確認
大規模變更之前
agent 要等人按 OK 才繼續
為什麼要這樣設計？
因為任何 agentic workflow
不管多成熟
總會有些 edge case 是 agent 沒辦法判斷的
這時候你要嘛讓 agent 亂猜，風險很高
要嘛讓它停下來問人類，風險可控
這樣整條 agentic workflow 才不是一個黑箱
不是一臺失控的機器
而是一個人類掌舵， agent 執行的系統
你還是最後拍板的人
但所有重複，機械，確定性的事
都不用自己做了
四步講完
我們直接套到一個真實的公司場景上
就是公司內部請求的分類系統
想像你在一間兩百人的公司上班
每天都會有人透過各種管道丟雜事進來
可能是表單， Slack， Teams， Email
或者你的私訊
內容大概長這樣
我要申請新系統的許可權
這張發票可不可以報帳
我下禮拜要 onboard 一個新同事
他需要哪些工具的存取
你處理這種事的 SOP 可能是
開啟內部 ticket 系統
掃一眼描述
判斷這是 IT 問題，許可權申請
HR 需求，財務報帳，還是其他類別
補上 priority 和 deadline
根據規則 assign 給對的 team 或對的人
如果他寫得很模糊，就回信問清楚
比方說你說電腦很慢
是開機慢，還是某個系統很卡？
這個流程不複雜
但很煩，很重複，而且每天都要做
最適合給 agent 處理
那我們就用四步把它變成一條 agentic workflow
Step 1 是標準化
我們把這個流程寫成一份 SOP
叫它 INTERNAL REQUEST TRIAGE
裡面的引數可能有
ticket 來源，原始文字，員工編號等
然後是 Steps
比方說 agent MUST 先根據員工編號
驗證這個人是不是在職員工
MUST 根據 ticket 內容
把請求分類成 IT， HR， Finance 這三類
SHOULD 根據 SLA 規則和關鍵字判斷 priority
是 High， Medium，還是 Low
MUST 產出一份結構化輸出
包含 category， priority 等欄位
如果是否需要澄清這個欄位是 true
agent 必須再產出兩到三個需要問使用者的釐清問題
你看，這份 SOP 已經有清楚的結構
有明確的 MUST 跟 SHOULD
有可以重複使用的 parameters
這就是 Step 1 做的事
Step 2 是拆解
把這個任務拆成兩個 skill
第一個叫 internal request triage
專門做分類，判斷 priority，推薦 assignee
它的 input 是 ticket 文字
output 是一份 JSON
category 是哪一類， priority 多高
推薦 assignee 是誰，要不要釐清
第二個 skill 叫 internal request reply drafting
它的 input 就是第一個 skill 的 JSON output
它要做的事是根據 triage 結果
產生給同事看的回覆草稿
告訴他這個問題會由誰處理
大概多久會回覆
兩個 skill 各做各的事
靠 JSON artifact 串起來
triage 失敗，不影響 reply-drafting 的邏輯
reply-drafting 改格式
不需要動到 triage 的分類邏輯
Step 3 是雙向開發
寫完第一版之後，跑一次
一定會發現問題
可能是某類請求一直被誤分類成 Other
可能是 priority 永遠都判 Medium
可能是 assignee 老是推薦給已經離職的人
沒關係，回頭改 SOP
補一條規則進去，再跑一次，再改
三五輪之後
整個 triage 的準確度就會趨於穩定
Step 4 是整合，也是最後一步
把這條 workflow 接到真實系統上
我們加一個小 script
把 triage 結果寫回公司內部的 tracking sheet
可能是 Notion，可能是 Jira
可能就是一個 Google Sheet
然後在高風險的請求之前加一個
human-in-the-loop checkpoint
比方說涉及財務超過五千塊
或者涉及 admin 許可權變更的請求
agent MUST 停下來等人按 OK
整條串起來就是
讀 ticket，自動分類，產生回覆草稿
寫回追蹤系統，必要時請人確認
一份原本只能給人跑的 SOP
就這樣變成一條每天自動跑
就算出錯也能第一時間知道怎麼修的 workflow 了
我把這部影片的內容做成了一組 prompt 工具包
總共五個 prompt
陪你一起拆解你最重複的 SOP
變成一條真的能用的 workflow
完整文章我會放在資訊欄
有需要的可以看看
順帶補充一下
今天這隻影片講的內容
不是工程師圈內的小眾興趣
前面提到的 MCP
目前已經被 ChatGPT， Claude， Cursor
各種 IDE 跟 agent 平臺採用
Anthropic 在2025年初
把這個協定整個捐給 Linux Foundation 底下的
Agentic AI Foundation
意思就是這個東西不再是某一家公司的私有規格
而是一個有基金會背書
會長期維護的開放標準
再拉大一點看
IBM， AWS 還有 ServiceNow 這些大公司
都在自己的產品線裡把 agentic workflow 跑起來了
ServiceNow 現在處理 IT ticket， HR 請求
各種內部服務流程
都已經是用 agentic workflow 在跑
而不是傳統的規則引擎
所以今天這套
Human SOP 轉 agentic workflow 的方法論
不是為了學一個新的 buzzword
不是為了寫一份報告給老闆看
而是每一位 AI 工作者在未來兩三年
都要具備的競爭力
最後回到個人身上
你不用一次把公司所有流程
都變成 agentic workflow
那會把你自己搞死
你只需要做一件小事
找一份你手上最無聊
但又一直在重複做的 Human SOP
可能是每週的週報
每次 release 前的 checklist
或者每次新人 onboard 的固定流程
挑你最不想做的那個
然後照著影片中提到的四步走一遍
不用一開始就做到完美
也不用一開始就完全自動化
先有一個跑得起來的
可以替你省 30% 時間的版本
再慢慢迭代
你不是在學怎麼用 AI
而是在學怎麼設計給 AI 用的工作流
前者半年就會過時
後者越來越值錢
在 MCP， agentic workflow
multi-agent 系統越來越普及的世界
能把流程拆好
設計成 agent 真的能執行的 workflow
這種能力的價值只會越來越高
那以上就是今天的內容
各位喜歡的話記得幫我按讚追蹤加分享
這是我持續創作下去的動力
我們下次見