WEBVTT
Kind: captions
Language: zh-TW

00:00:00.000 --> 00:00:03.220
前陣子出了一部影片講解 Stanford 的 AI 系統建構教學

00:00:03.240 --> 00:00:05.699
影片中有提到像是 RAG, Prompt Engineering

00:00:05.960 --> 00:00:08.739
模型微調還有 Agentic Workflow 這些重要的觀念

00:00:08.739 --> 00:00:11.279
也有很多粉絲來信問我能不能拍一系列的影片

00:00:11.279 --> 00:00:13.920
針對這些觀念進行比較詳細的教學

00:00:13.920 --> 00:00:16.020
所以今天我想聊聊 agentic workflow

00:00:16.020 --> 00:00:18.180
裡面很重要的觀念，task decomposition

00:00:18.180 --> 00:00:20.219
現在前沿模型的能力絕對已經夠強了

00:00:20.219 --> 00:00:21.520
能勝任絕大多數的任務

00:00:21.559 --> 00:00:24.399
但還是有許多人會覺得模型表現不佳或者產出不靠譜

00:00:24.459 --> 00:00:26.340
根據我過往的諮詢案例

00:00:26.340 --> 00:00:28.540
其實大多數人只是不知道如何把一個大任務

00:00:28.540 --> 00:00:30.059
拆成 agent 可以跑得動的小任務

00:00:30.680 --> 00:00:33.099
這件事聽起來可能有點無聊，可能有點簡單

00:00:33.119 --> 00:00:34.959
但相信我，如果你是技術人員

00:00:35.040 --> 00:00:37.599
好的任務拆解能力可以幫你構建一個更穩定的系統

00:00:37.740 --> 00:00:39.139
如果你是非技術人員

00:00:39.139 --> 00:00:42.580
你更要知道怎麼把自己的日常執行專案拆小塊一點

00:00:42.720 --> 00:00:43.799
然後委派給 AI

00:00:43.919 --> 00:00:46.779
而不是一大包丟進去導致 agent 消化不良

00:00:46.919 --> 00:00:47.919
那我們直接開始

00:00:48.200 --> 00:00:51.299
首先我想要先把這部影片中會用到的三個名詞定義清楚

00:00:51.299 --> 00:00:54.459
分別是 Human SOP， skill，還有 agentic workflow

00:00:54.779 --> 00:00:56.459
三個東西很多人會搞混

00:00:56.459 --> 00:00:58.639
但其實它們的層級跟功能完全不一樣

00:00:58.799 --> 00:01:01.340
沒有先分清楚，後面你只會聽得一頭霧水

00:01:01.880 --> 00:01:03.479
第一個是 Human SOP

00:01:03.540 --> 00:01:04.819
就是傳統的流程檔案

00:01:04.819 --> 00:01:07.620
這份檔案會告訴你第一步做什麼，第二步做什麼

00:01:07.620 --> 00:01:08.779
遇到例外怎麼處理

00:01:08.779 --> 00:01:11.040
旁邊還有一堆小提醒和經驗談

00:01:11.220 --> 00:01:15.164
傳統的流程檔案可能是一份簡報，可能是一份 word 檔

00:01:15.379 --> 00:01:17.239
但本質上都是寫給人看的 SOP

00:01:17.860 --> 00:01:20.239
這型別的檔案給人類看完全沒問題

00:01:20.279 --> 00:01:22.519
因為你的腦中會自動補進一堆 context

00:01:22.580 --> 00:01:25.559
會自己判斷哪一步可以偷懶，哪一步一定要做

00:01:25.559 --> 00:01:29.760
比方說在 SOP 檔案裡面寫到申請完之後送主管簽核

00:01:29.959 --> 00:01:32.279
看到這句話之後，你可能會有能力判斷

00:01:32.459 --> 00:01:33.959
如果是兩百塊以內的小金額

00:01:34.000 --> 00:01:36.739
主管寧願你不要去煩他，直接跑完這個流程

00:01:36.739 --> 00:01:38.599
但如果今天這筆金額超過五千塊

00:01:38.599 --> 00:01:40.180
你可能就得照著規矩來

00:01:40.180 --> 00:01:42.120
或者至少口頭知會主管一聲

00:01:42.120 --> 00:01:44.080
這些判斷可以被寫進 SOP 檔案裡面

00:01:44.099 --> 00:01:46.400
但需要花時間去把例外狀況給列出來

00:01:46.419 --> 00:01:48.260
更何況很少人真的熱愛維護檔案

00:01:48.300 --> 00:01:51.260
口頭提醒一下新同事永遠比維護檔案更方便

00:01:51.260 --> 00:01:53.980
這種狀況在中小型企業更是經常發生

00:01:54.440 --> 00:01:56.180
但這樣的 SOP 對 agent 來說

00:01:56.180 --> 00:01:57.879
就是一坨非結構化的文字

00:01:57.879 --> 00:02:00.540
理解成本高，執行時容易忘東忘西

00:02:00.540 --> 00:02:01.459
只要你沒有 specify

00:02:01.459 --> 00:02:04.639
AI 不會知道對你們團隊來說兩百塊跟五千塊有什麼差別

00:02:04.639 --> 00:02:05.900
不會知道哪一步可以省略

00:02:05.980 --> 00:02:09.279
不會知道遇到例外的時候要繼續做還是停下來問人

00:02:09.279 --> 00:02:10.559
第二個是 skill

00:02:10.559 --> 00:02:12.100
在我之前的影片有講過

00:02:12.166 --> 00:02:15.520
skill 本質上就是把你做事的方法論，判斷標準，踩過的坑

00:02:15.639 --> 00:02:17.860
打包成一個資料夾交給 agent

00:02:17.860 --> 00:02:18.940
裡面通常有三個東西

00:02:19.000 --> 00:02:20.300
第一個是 SKILL markdown

00:02:20.539 --> 00:02:23.039
這個是人類寫給 agent 的 SOP 加心法

00:02:23.039 --> 00:02:24.320
也是 skill 的核心檔案

00:02:24.460 --> 00:02:25.559
第二個是 references

00:02:25.600 --> 00:02:27.300
存放額外的參考資料

00:02:27.300 --> 00:02:30.380
比方說範例輸出，術語表，過去踩坑的紀錄

00:02:30.380 --> 00:02:32.119
有需要時 agent 可以自行取用

00:02:32.259 --> 00:02:33.419
第三個是 scripts

00:02:33.419 --> 00:02:34.600
是可以直接執行的指令碼

00:02:34.699 --> 00:02:36.279
處理那些確定性的操作

00:02:36.279 --> 00:02:38.240
比方說檔案 parsing，格式轉換

00:02:38.240 --> 00:02:40.800
這種傳統軟體工程就能做到的事

00:02:41.000 --> 00:02:44.479
一個 skill 對應的是單一任務，不是整條工作流

00:02:44.699 --> 00:02:47.440
常用的命名方式像是 weekly-report-drafting

00:02:47.839 --> 00:02:49.899
pdf-processing，還有 invoice-categorization

00:02:49.960 --> 00:02:52.179
看名字就知道它做什麼，什麼時候該被 trigger

00:02:52.820 --> 00:02:54.080
但在設計 skill 時

00:02:54.119 --> 00:02:56.080
這個 skill 的防守範圍要拆多大是關鍵

00:02:56.139 --> 00:02:57.279
防守範圍如果太大

00:02:57.279 --> 00:02:59.539
容易讓人感覺樣樣通，但又都做得差強人意

00:02:59.600 --> 00:03:02.440
防守範圍太小就變成每走一步都要去讀 skill

00:03:02.440 --> 00:03:05.979
等於是把現在的模型當小孩子，什麼都要聽人類的

00:03:05.979 --> 00:03:08.699
那具體怎麼拆我等等會再深入講解

00:03:08.699 --> 00:03:10.639
第三個是 agentic workflow

00:03:10.639 --> 00:03:13.639
也就是一整條由多個 agents， tools， skills

00:03:14.059 --> 00:03:15.179
資料源組成的工作流

00:03:15.793 --> 00:03:17.460
agentic workflow 不是一個單純的 prompt

00:03:17.580 --> 00:03:19.000
更像是一條生產線

00:03:19.199 --> 00:03:21.460
有人負責理解問題，有人查資料

00:03:21.460 --> 00:03:23.639
有人執行動作，有人寫報告

00:03:23.699 --> 00:03:26.479
中間呼叫各種工具， API，資料庫

00:03:26.619 --> 00:03:28.500
還有你之前寫好的 skills

00:03:28.770 --> 00:03:30.559
agentic workflow 更像一間工廠

00:03:30.619 --> 00:03:33.020
只是裡面全都是 AI 夥伴在幫你做事

00:03:33.139 --> 00:03:35.720
那我快速統整一下剛剛講到的三個名詞定義

00:03:35.720 --> 00:03:37.860
Human SOP 是給人看的紙本流程

00:03:38.180 --> 00:03:40.740
skill 是把流程跟方法論打包給 agent 的執行單位

00:03:41.139 --> 00:03:43.520
agentic workflow 是把多個 skill 加上工具串起來

00:03:43.720 --> 00:03:45.119
一條完整的生產線

00:03:45.199 --> 00:03:48.639
這條生產線跑完，你的任務也就完成了

00:03:48.639 --> 00:03:49.860
而這隻影片的重點

00:03:49.860 --> 00:03:52.199
就是怎麼把原本寫給人看的 Human SOP

00:03:52.320 --> 00:03:53.899
轉成一條 agentic workflow

00:03:54.059 --> 00:03:56.720
讓 agent 可以理解，並且幫你穩定執行

00:03:57.199 --> 00:03:58.119
不過講到這裡

00:03:58.460 --> 00:04:00.339
很多人心中可能會有個疑問

00:04:00.559 --> 00:04:02.419
反正現在模型能力越來越強

00:04:02.720 --> 00:04:04.320
或者有一天達到 AGI 後

00:04:04.440 --> 00:04:06.139
我也不用說那麼多了

00:04:06.139 --> 00:04:08.559
反正就是指哪打哪，使命必達

00:04:08.759 --> 00:04:10.119
但答案大機率是不行

00:04:10.119 --> 00:04:13.080
我舉一個生活化的例子你們就懂了

00:04:13.080 --> 00:04:15.740
假設你今天要出遠門，臨走前請了一位幫手

00:04:16.119 --> 00:04:17.859
只交代他把家裡打掃乾淨

00:04:17.859 --> 00:04:19.279
然後什麼都沒多說就出門了

00:04:19.279 --> 00:04:21.440
等你回家，大機率會出事

00:04:21.600 --> 00:04:24.339
因為你跟他對乾淨這個詞的定義可能完全不一樣

00:04:24.959 --> 00:04:25.959
你心目中的乾淨

00:04:26.200 --> 00:04:28.920
是地板不黏腳，桌面清爽沒一堆紙

00:04:28.920 --> 00:04:31.880
廚房水槽沒有碗，垃圾都倒掉了

00:04:31.880 --> 00:04:33.019
但幫手心目中的乾淨

00:04:33.019 --> 00:04:35.399
可能是東西有歸位就好，看得順眼就算

00:04:35.519 --> 00:04:38.179
反正角落裡，櫃子後面那些看不到的地方

00:04:38.299 --> 00:04:39.760
不用特別去動它

00:04:39.760 --> 00:04:41.179
結果就是表面上好像有掃

00:04:41.279 --> 00:04:43.260
但你在意的那些地方一個都沒動到

00:04:43.500 --> 00:04:45.440
所以問題從來不是幫手夠不夠聰明

00:04:45.559 --> 00:04:46.600
或者模型表現好不好

00:04:47.019 --> 00:04:48.880
就算他什麼都會，什麼都懂

00:04:48.880 --> 00:04:50.559
你沒告訴他你在想什麼

00:04:50.559 --> 00:04:51.380
只要沒有讀心術

00:04:51.380 --> 00:04:53.079
他就永遠滿足不了你的需求

00:04:53.500 --> 00:04:54.339
這也是為什麼

00:04:54.420 --> 00:04:56.220
就算有一天 AGI 真的來了

00:04:56.440 --> 00:04:59.299
有人做出了一個跟真人一模一樣的 AI 居家幫手

00:04:59.359 --> 00:05:00.679
你還是得跟他磨合

00:05:00.880 --> 00:05:04.160
所謂磨合，就是他得透過日常相處慢慢累積你的偏好

00:05:04.200 --> 00:05:06.160
第一個月他知道你是極簡主義者

00:05:06.160 --> 00:05:08.619
桌面只想要有必要的東西，不想要有任何雜物

00:05:08.880 --> 00:05:11.059
第二個月他知道你很愛惜自己的不沾鍋

00:05:11.320 --> 00:05:13.600
所以刷的時候要用菜瓜布黃色的那一面

00:05:13.720 --> 00:05:15.559
這些事沒有寫在任何說明書上

00:05:15.559 --> 00:05:16.480
但你就是很在意

00:05:16.480 --> 00:05:18.059
而不知道這些事情的機器人

00:05:18.059 --> 00:05:19.459
再聰明都會看起來像笨蛋

00:05:19.799 --> 00:05:22.679
這個道理放到 agentic workflow 上也是一樣的

00:05:22.679 --> 00:05:23.600
很多人第一次接觸 agent

00:05:23.739 --> 00:05:25.459
直覺就是找一個最強的模型

00:05:25.459 --> 00:05:27.700
把任務整包丟給它，讓它從頭跑到尾

00:05:27.799 --> 00:05:29.019
這就是所謂的 mega agent

00:05:29.119 --> 00:05:30.559
也就是前面說的那個幫手

00:05:30.920 --> 00:05:33.100
你跟它說幫我最佳化整個開發流程

00:05:33.440 --> 00:05:34.799
它一定會做點什麼出來

00:05:35.019 --> 00:05:36.859
可能寫一份洋洋灑灑的最佳化建議

00:05:37.079 --> 00:05:38.559
可能改一堆 config 檔

00:05:38.559 --> 00:05:40.700
可能 refactor 一個你根本不該動的模組

00:05:40.980 --> 00:05:43.600
但你完全不知道到底哪一段推理是對的

00:05:43.600 --> 00:05:44.959
哪一段工具調錯了

00:05:44.959 --> 00:05:46.700
哪一段是它幻想出來的

00:05:46.700 --> 00:05:48.040
哪一段根本不該讓它自動跑

00:05:48.480 --> 00:05:50.420
整坨丟進去，整坨吐出來

00:05:50.600 --> 00:05:52.200
中間發生什麼你看不見

00:05:52.200 --> 00:05:54.079
就算想 review 也找不到下手點

00:05:54.559 --> 00:05:56.239
我看過太多新手卡在這個地方

00:05:56.380 --> 00:05:57.679
他們第一個反應永遠是

00:05:57.679 --> 00:06:00.140
再換一個更強的模型或者再寫一個更詳細的 prompt

00:06:00.239 --> 00:06:02.440
但其實問題不在模型，也不在 prompt

00:06:02.440 --> 00:06:04.160
而是任務本身太大，太模糊

00:06:04.260 --> 00:06:06.260
所以每次執行都像是在買彩券

00:06:06.440 --> 00:06:08.799
反過來，如果你把任務拆成一串小 task

00:06:08.940 --> 00:06:10.619
每一個 task 都有明確的 input

00:06:10.619 --> 00:06:12.420
明確的 output，明確的成功標準

00:06:12.459 --> 00:06:13.940
那就完全不一樣了

00:06:13.940 --> 00:06:15.322
比方說同樣是處理客戶 ticket

00:06:15.380 --> 00:06:16.899
你可以拆成這四個 agent

00:06:16.980 --> 00:06:18.000
一個只負責分類

00:06:18.160 --> 00:06:20.880
一個只負責查資料庫找出相關歷史紀錄

00:06:20.959 --> 00:06:22.760
一個只負責寫回覆草稿

00:06:22.760 --> 00:06:24.660
再加一個 sub-agent 專門做 QC

00:06:24.660 --> 00:06:28.200
確認回覆有沒有事實錯誤或政治不正確

00:06:28.200 --> 00:06:29.399
每個 agent 或許都很笨

00:06:29.420 --> 00:06:31.760
但每個 agent 都做一件很明確的事

00:06:31.760 --> 00:06:32.859
出錯了你回去看 log

00:06:33.179 --> 00:06:35.799
發現是分類的時候把客訴判定為諮詢需求

00:06:35.920 --> 00:06:37.839
你就改分類的那一份 SOP 就好

00:06:37.839 --> 00:06:39.239
不需要動到查資料的

00:06:39.239 --> 00:06:40.380
不需要動到寫回覆的

00:06:40.380 --> 00:06:41.859
不需要動到 QC 的

00:06:41.859 --> 00:06:43.600
哪裡壞改哪裡，對症下藥

00:06:44.339 --> 00:06:46.760
現在很多企業級的 agentic workflow 框架

00:06:47.000 --> 00:06:48.279
在做的就是這件事

00:06:48.500 --> 00:06:50.540
把複雜的流程拆成一串工作流

00:06:50.540 --> 00:06:53.359
每一段由一個小 agent 或一段明確的 automation 處理

00:06:53.739 --> 00:06:55.459
為什麼這些大公司不直接用 mega agent？

00:06:55.640 --> 00:06:56.820
因為他們要上 production

00:06:56.820 --> 00:06:59.820
他們需要的是穩定性，可觀測性，可修復性

00:07:00.260 --> 00:07:02.179
一個你看不到內部的黑箱

00:07:02.179 --> 00:07:03.380
永遠沒辦法 production-ready

00:07:03.380 --> 00:07:04.720
因為你根本不敢讓它上線

00:07:05.480 --> 00:07:06.500
所以 divide and conquer

00:07:06.579 --> 00:07:08.519
也就是所謂的分而治之的老觀念

00:07:08.720 --> 00:07:10.059
在 agent 時代反而更重要

00:07:10.200 --> 00:07:11.799
你不是在訓練一個超人 agent

00:07:11.799 --> 00:07:13.200
而是在設計一條生產線

00:07:13.399 --> 00:07:16.019
一條真的能上線的生產線乍看之下非常無聊

00:07:16.160 --> 00:07:18.700
但它可預測，有邊界，出錯可以修

00:07:18.739 --> 00:07:20.619
而這些才是最關鍵的

00:07:20.619 --> 00:07:21.619
知道為什麼要拆之後

00:07:21.760 --> 00:07:23.619
接下來的重點就是怎麼拆

00:07:23.899 --> 00:07:26.339
我們先用洗衣服這件事情當作例子

00:07:26.339 --> 00:07:27.899
你今天教家裡的小孩子洗衣服

00:07:27.899 --> 00:07:28.679
可能會跟他說

00:07:28.779 --> 00:07:31.720
你就把衣服丟進去，加洗衣精，按開始

00:07:31.739 --> 00:07:33.339
等洗完之後把衣服拿去曬

00:07:33.839 --> 00:07:35.220
就這樣，沒了

00:07:35.500 --> 00:07:37.100
這是一份典型的 Human SOP

00:07:37.559 --> 00:07:38.720
為什麼人類看得懂？

00:07:38.720 --> 00:07:40.220
因為你的腦中會自己補一些判斷

00:07:40.220 --> 00:07:41.880
比方說白襯衫最好分開洗

00:07:41.940 --> 00:07:43.500
不然會被牛仔褲染色

00:07:43.500 --> 00:07:46.040
毛衣不能丟洗衣機，要手洗否則會縮水

00:07:46.119 --> 00:07:48.559
天氣不好就不要用晾的了，直接用烘衣機

00:07:48.920 --> 00:07:50.260
這些東西你可能都沒講

00:07:50.299 --> 00:07:53.260
但你的小孩子會根據過去跟你生活的經驗

00:07:53.440 --> 00:07:54.559
收斂出你的偏好

00:07:54.559 --> 00:07:57.940
所以能夠避開這些坑，把這些東西給默默補起來

00:07:58.160 --> 00:08:00.260
但你把這段話原封不動丟給 agent

00:08:00.339 --> 00:08:02.700
跟它說幫我做一個洗衣服的 workflow

00:08:03.153 --> 00:08:05.359
它會用教科書式的方法幫你處理好

00:08:05.359 --> 00:08:07.600
但他可能不知道你們家從來不烘衣服

00:08:07.600 --> 00:08:09.839
或者所有衣服都要放洗衣袋避免鬆掉

00:08:09.839 --> 00:08:12.799
結果實際跑完一輪後衣服縮水或者出現荷葉邊

00:08:12.799 --> 00:08:15.019
這就是 Human SOP 直接丟給 agent 的下場

00:08:15.559 --> 00:08:17.160
所以我們需要一套方法論

00:08:17.160 --> 00:08:18.880
把這份簡單扼要

00:08:18.940 --> 00:08:21.799
但很吃個人腦補能力的 Human SOP

00:08:21.799 --> 00:08:24.100
轉成 agent 可以直接吃的 agentic workflow

00:08:24.359 --> 00:08:27.320
我把它整理成四步，我們一步一步來

00:08:27.320 --> 00:08:28.880
首先是格式標準化

00:08:29.239 --> 00:08:30.640
這一步要做的事情很簡單

00:08:30.799 --> 00:08:32.280
就是把這份 Human SOP

00:08:32.280 --> 00:08:34.380
改成 agent 能夠讀懂的版本

00:08:34.500 --> 00:08:36.940
在做這件事情的時候，重點有三個

00:08:37.500 --> 00:08:38.520
第一是引數化

00:08:38.520 --> 00:08:41.619
你不要在 SOP 裡寫死一定要用 normal 模式

00:08:41.619 --> 00:08:43.700
因為這樣 SOP 只能 cover 一種情境

00:08:44.020 --> 00:08:46.539
你要改成用 mode， temperature 這種引數

00:08:46.640 --> 00:08:48.539
讓 SOP 變成一個 template

00:08:48.539 --> 00:08:51.340
呼叫的時候根據實際狀況帶不同的值進去

00:08:51.340 --> 00:08:53.539
比方說 mode 可以是 quick， normal

00:08:53.739 --> 00:08:55.099
還有 delicate 三選一

00:08:55.426 --> 00:08:57.239
temperature 可以是 cold， warm

00:08:57.306 --> 00:08:58.979
還有 hot 三選一

00:08:58.979 --> 00:09:02.539
這樣一來，同一份 SOP 就可以 cover 各種洗衣服的場景

00:09:03.039 --> 00:09:04.179
這件事很關鍵

00:09:04.340 --> 00:09:07.239
SOP 一旦寫死，它就沒辦法重複使用

00:09:07.239 --> 00:09:08.840
我看過太多人寫 skill

00:09:08.840 --> 00:09:11.539
寫到最後變成一份只 cover 一種特殊情況的長文

00:09:11.700 --> 00:09:13.679
那這份 skill 的容錯率就會非常低

00:09:13.679 --> 00:09:15.239
當你分享給別人時

00:09:15.239 --> 00:09:18.106
可能會少了環境引數或者其他的設定而直接報錯

00:09:19.179 --> 00:09:20.919
第二個是 MUST， SHOULD， MAY

00:09:21.359 --> 00:09:23.400
這個是 RFC 2119 的寫法

00:09:23.400 --> 00:09:25.940
本來是用在網路協定的規格書上的

00:09:25.940 --> 00:09:28.099
但我發現拿來寫 agent SOP 超好用

00:09:28.099 --> 00:09:31.000
因為它強制你把每一條規則的強度給想清楚

00:09:31.679 --> 00:09:33.080
MUST 是硬性規定

00:09:33.359 --> 00:09:35.200
agent 必須做，絕對不能跳過

00:09:35.200 --> 00:09:36.440
SHOULD 是建議作法

00:09:36.440 --> 00:09:39.440
有強烈理由的話可以不做，但要明確說明原因

00:09:39.440 --> 00:09:42.099
MAY 則是 optional 的專案，做不做都可以

00:09:42.440 --> 00:09:43.340
舉例來說

00:09:43.433 --> 00:09:44.479
agent 的 MUST 可能有

00:09:44.479 --> 00:09:45.700
先檢查每一件衣服的洗標

00:09:45.840 --> 00:09:47.359
把白色跟深色分開

00:09:47.400 --> 00:09:49.000
啟動洗衣機後等待完成

00:09:49.359 --> 00:09:50.239
agent 的 SHOULD 可能有

00:09:50.239 --> 00:09:52.280
根據衣物材質選擇合適的洗衣模式

00:09:52.320 --> 00:09:54.719
根據今天的天氣決定要不要用烘乾

00:09:55.260 --> 00:09:56.059
agent 的 MAY 可能有

00:09:56.059 --> 00:09:58.700
在濕度大於百分之七十的時候使用烘乾機

00:09:58.700 --> 00:10:00.419
否則 MUST 改用晾乾的方式

00:10:01.179 --> 00:10:03.539
你看，每一條規則的強度都很明確

00:10:03.880 --> 00:10:05.799
agent 看到就知道哪些不能討價還價

00:10:05.799 --> 00:10:08.239
哪些可以根據 context 自己判斷

00:10:08.299 --> 00:10:09.979
第三個是結構化格式

00:10:10.000 --> 00:10:11.739
用 Markdown 把區塊切清楚

00:10:11.739 --> 00:10:14.020
把 Parameters， Steps， Error Handling

00:10:14.020 --> 00:10:15.320
這每個區塊都分開

00:10:15.320 --> 00:10:16.159
既讓人看得懂

00:10:16.179 --> 00:10:18.979
也方便之後塞進 MCP 這類標準介面裡

00:10:18.979 --> 00:10:20.359
當成 agent 的行為規格

00:10:20.539 --> 00:10:22.500
新來的朋友們如果不知道 MCP 是什麼

00:10:22.500 --> 00:10:24.119
我後面會再提到

00:10:24.119 --> 00:10:25.039
這樣處理完之後

00:10:25.119 --> 00:10:27.900
你手上的東西就不再是一篇給人看的散文

00:10:27.900 --> 00:10:29.840
而是一份 agent 真的讀得懂的 SOP

00:10:30.599 --> 00:10:32.859
但光是 SOP 寫得漂亮還不夠

00:10:32.859 --> 00:10:35.960
這只是把 Human SOP 翻譯成 agent 能讀的格式而已

00:10:35.960 --> 00:10:37.200
你還沒有真的拆解任務

00:10:37.799 --> 00:10:38.840
所以我們進到第二步

00:10:39.020 --> 00:10:40.799
也是 task decomposition 的核心

00:10:40.820 --> 00:10:42.820
叫做任務拆解與連結

00:10:42.820 --> 00:10:45.359
簡單講就是把它 decompose 成 pipeline steps

00:10:45.359 --> 00:10:47.460
每一個 step 都是 pipeline 裡的一個獨立節點

00:10:47.780 --> 00:10:49.700
洗衣服這件事拆開來就是這四節

00:10:49.700 --> 00:10:52.479
分類衣物，檢查口袋汙漬，設定機器

00:10:52.479 --> 00:10:53.760
決定要晾衣還是烘乾

00:10:54.099 --> 00:10:56.260
每一個步驟都是 pipeline 的獨立節點

00:10:56.260 --> 00:10:57.780
有自己的 input，有自己的 output

00:10:57.979 --> 00:10:59.440
可以獨立執行，獨立 debug

00:10:59.440 --> 00:11:01.039
甚至獨立替換成新的邏輯

00:11:01.599 --> 00:11:03.619
我為什麼要這麼強調獨立這兩個字？

00:11:03.619 --> 00:11:05.179
因為這會奠定後面的所有好處

00:11:05.640 --> 00:11:06.539
舉個例子

00:11:06.559 --> 00:11:08.299
如果分類衣物這個步驟有 bug

00:11:08.340 --> 00:11:10.520
把白色 polo 衫誤判成深色衣物

00:11:10.580 --> 00:11:12.099
你只要修這一段就好

00:11:12.099 --> 00:11:15.599
後面的設定機器，決定晾或烘的邏輯完全不用動

00:11:15.739 --> 00:11:17.299
但如果你寫的是 mega agent

00:11:17.320 --> 00:11:18.533
全部塞在一個 prompt 裡

00:11:18.599 --> 00:11:20.320
一旦出錯就只能整個重寫

00:11:20.320 --> 00:11:22.260
因為你根本不知道是哪一段邏輯出了問題

00:11:22.739 --> 00:11:24.280
除此之外，這樣做的好處是

00:11:24.280 --> 00:11:25.739
每一節都可以變成一個小 skill

00:11:25.739 --> 00:11:27.020
甚至一個小 agent

00:11:27.020 --> 00:11:29.340
比方說我們可以做一個 agent 只負責分類

00:11:29.570 --> 00:11:31.799
吃進去衣物列表，吐出來分類結果

00:11:32.039 --> 00:11:34.119
另一個 agent 只負責根據分類結果

00:11:34.119 --> 00:11:36.059
決定洗衣機的 mode 和 temperature

00:11:36.059 --> 00:11:37.640
再下一個 agent 負責判斷天氣

00:11:37.700 --> 00:11:39.320
然後決定走晾乾還是烘乾

00:11:39.859 --> 00:11:42.059
三個 agent 各自做一件很笨，有點無聊

00:11:42.080 --> 00:11:43.100
但超級明確的事

00:11:43.280 --> 00:11:45.559
加起來就是一條完整的洗衣服 workflow

00:11:45.719 --> 00:11:47.880
那這些 agent 之間靠什麼串接呢？

00:11:47.880 --> 00:11:49.219
答案是 artifacts

00:11:49.219 --> 00:11:51.159
也就是上一個 agent 的 output

00:11:51.159 --> 00:11:52.419
變成下一個 agent 的 input

00:11:53.099 --> 00:11:56.119
比方說分類 agent 的輸出是一份 JSON

00:11:56.260 --> 00:11:57.719
會告訴你 whites 裡有哪幾件

00:11:58.033 --> 00:11:58.820
darks 裡有哪幾件

00:11:59.006 --> 00:12:00.000
delicates 裡有哪幾件

00:12:00.200 --> 00:12:01.559
unknowns 裡有哪幾件

00:12:01.559 --> 00:12:04.900
這份 JSON 就直接變成設定機器那個 agent 的 input

00:12:04.900 --> 00:12:06.539
設定機器的 agent 看到 JSON

00:12:06.599 --> 00:12:08.679
自己根據規則決定每一批應該怎麼洗

00:12:08.700 --> 00:12:10.299
吐出來一份洗衣服的設定

00:12:10.619 --> 00:12:11.640
再交給下一個 agent

00:12:12.320 --> 00:12:13.940
一個節點連結另一個節點

00:12:13.940 --> 00:12:14.820
靠的不是魔法

00:12:14.820 --> 00:12:17.039
不是大型語言模型之間的心電感應

00:12:17.039 --> 00:12:18.900
而是清楚定義的 input， output

00:12:18.900 --> 00:12:20.359
和中間的 artifact 格式

00:12:21.000 --> 00:12:23.340
第二步講完了，第三步是雙向開發

00:12:24.020 --> 00:12:25.320
這一步很多人會忽略

00:12:25.460 --> 00:12:27.619
但其實是整個四步裡最重要的

00:12:27.979 --> 00:12:28.299
為什麼？

00:12:28.799 --> 00:12:30.880
因為你的第一版 SOP 一定會有問題

00:12:31.159 --> 00:12:33.059
無論你是多資深的工程師

00:12:33.059 --> 00:12:34.400
多會設計流程的 PM

00:12:34.760 --> 00:12:36.739
第一版 SOP 拿出來跑，一定會出包

00:12:37.419 --> 00:12:38.299
為什麼我可以這麼篤定？

00:12:38.659 --> 00:12:40.179
先介紹一個名詞叫做默會知識

00:12:40.359 --> 00:12:41.500
英文是 Tacit Knowledge

00:12:41.520 --> 00:12:42.599
又稱內隱知識

00:12:42.700 --> 00:12:45.739
是指那些難以用文字，言語或圖表明確表達

00:12:45.739 --> 00:12:48.460
存在於個人大腦與身體記憶中的知識

00:12:48.460 --> 00:12:50.659
我協助過太多團隊做 SOP 自動化

00:12:50.659 --> 00:12:51.719
而 SOP 的本質是

00:12:51.719 --> 00:12:54.299
把腦中的默會知識轉成文字明示規則

00:12:54.539 --> 00:12:55.919
而默會知識的特性就是

00:12:55.919 --> 00:12:58.719
你自己不會發現它的存在，直到它出錯

00:12:58.799 --> 00:12:59.760
你以為你寫完了

00:12:59.780 --> 00:13:02.479
但其實腦子裡還有十幾條沒寫進去的判斷標準

00:13:02.580 --> 00:13:05.320
要等 agent 真的跑出去，撞牆了，出錯了

00:13:05.320 --> 00:13:06.039
你才會發現

00:13:06.219 --> 00:13:08.000
啊，原來這條我沒寫到

00:13:08.000 --> 00:13:10.059
那所謂的雙向開發其實就是為了持續迭代

00:13:10.140 --> 00:13:11.979
實際執行時大概會長這樣子

00:13:11.979 --> 00:13:13.520
你先用自然語言跟 agent 說

00:13:13.520 --> 00:13:15.086
我平常洗衣服大概是這樣這樣這樣

00:13:15.140 --> 00:13:16.500
請你幫我寫一份 SOP

00:13:17.000 --> 00:13:18.340
然後 agent 就會幫你寫好第一版

00:13:19.000 --> 00:13:21.419
接著你照這份 SOP 實際跑一次 workflow

00:13:21.599 --> 00:13:24.619
跑完後發現它把所有 t-shirt 都丟進超高溫烘乾機

00:13:24.619 --> 00:13:26.719
結果縮水到直接穿不下

00:13:26.719 --> 00:13:29.039
這時候你就會意識到 SOP 哪裡寫得不夠清楚

00:13:29.479 --> 00:13:31.840
於是你回頭把那份 SOP 補上一條規則

00:13:32.040 --> 00:13:35.500
agent 不可以把含棉量超過 80% 的衣物用高溫烘乾

00:13:35.539 --> 00:13:37.619
然後下一輪它就不會再犯這個錯了

00:13:37.619 --> 00:13:38.659
不過當你再跑一次的時候

00:13:38.659 --> 00:13:39.859
可能又發現另一個問題

00:13:39.859 --> 00:13:41.619
比方說它沒有把衣服裝進洗衣袋

00:13:41.840 --> 00:13:43.979
好，那你就再補一條 SOP

00:13:43.979 --> 00:13:45.340
這個過程不斷重複

00:13:45.340 --> 00:13:48.200
每一輪 agent 都會踩到一個你之前沒想過的坑

00:13:48.239 --> 00:13:49.960
於是你就把那個坑補起來

00:13:50.159 --> 00:13:51.099
幾輪下來之後

00:13:51.099 --> 00:13:53.559
SOP 會穩定到能滿足大多數的使用情境

00:13:53.559 --> 00:13:55.739
而剩下的 5% 是真正的 edge case

00:13:55.880 --> 00:13:57.479
那就用 human-in-the-loop 的方式處理

00:13:57.479 --> 00:13:59.280
這件事我們等下會講

00:13:59.280 --> 00:14:01.419
不是你關在房間裡想像一份完美的 SOP

00:14:01.419 --> 00:14:02.359
然後丟給 agent 跑

00:14:02.380 --> 00:14:03.559
而是你跟 agent 一起跑

00:14:03.559 --> 00:14:04.739
一起 debug，一起 iterate

00:14:04.820 --> 00:14:07.520
根據真實的執行結果持續修復，迭代 SOP

00:14:08.419 --> 00:14:10.000
之前有一位客戶花了兩個月

00:14:10.000 --> 00:14:11.559
寫了一份所謂的完美 agent SOP

00:14:11.739 --> 00:14:13.000
結果跑一次就垮了

00:14:13.000 --> 00:14:14.739
因為他們 cover 的全是想像中的情境

00:14:14.880 --> 00:14:16.580
現實中根本不會發生

00:14:16.580 --> 00:14:18.460
後來我跟他們一起秉持 scrum 精神

00:14:18.460 --> 00:14:20.340
改成用小步快跑的方式

00:14:20.340 --> 00:14:21.799
兩天寫一個粗糙版本

00:14:21.799 --> 00:14:23.700
然後一個禮拜內跑五十次 iteration

00:14:23.739 --> 00:14:24.840
兩週內就上線

00:14:25.080 --> 00:14:26.900
速度的關鍵不是寫得多完美

00:14:26.900 --> 00:14:28.280
而是迭代得有多快

00:14:28.539 --> 00:14:29.820
講完雙向開發

00:14:29.820 --> 00:14:32.299
接著進到最後一步，整合與執行環境

00:14:33.020 --> 00:14:34.239
這一步是決定你的 agent

00:14:34.239 --> 00:14:37.359
到底是 demo 還是真的能在 production 跑的關鍵

00:14:37.359 --> 00:14:38.299
再漂亮的 SOP

00:14:38.619 --> 00:14:40.479
如果沒接到真實世界的工具

00:14:40.479 --> 00:14:43.099
它就只是一份檔案，但永遠不會自己動起來

00:14:43.760 --> 00:14:45.200
在洗衣服的例子裡

00:14:45.200 --> 00:14:48.460
工具就是洗衣機，烘乾機，天氣 API 這些

00:14:48.880 --> 00:14:51.020
你的 agent 要能真的去查今天會不會下雨

00:14:51.020 --> 00:14:52.400
要能真的啟動洗衣機

00:14:52.400 --> 00:14:54.760
光是腦袋裡知道應該這樣做是沒用的

00:14:54.760 --> 00:14:56.679
要真的做出來才行

00:14:56.679 --> 00:14:58.260
對 agentic workflow 來說

00:14:58.260 --> 00:15:00.400
工具就是你的公司內部系統

00:15:00.400 --> 00:15:02.520
資料庫， API，檔案系統

00:15:02.520 --> 00:15:04.599
版本控制， ticketing system 這些

00:15:04.679 --> 00:15:07.099
問題是這些東西每一家公司都長不一樣

00:15:07.099 --> 00:15:08.260
你今天為 A 公司寫的 agent

00:15:08.260 --> 00:15:09.840
搬到 B 公司可能完全動不了

00:15:10.239 --> 00:15:11.340
這就是 MCP

00:15:11.400 --> 00:15:14.159
也就是 Model Context Protocol 想解決的事

00:15:14.479 --> 00:15:15.799
MCP 是一個開放協定

00:15:15.940 --> 00:15:17.940
它的目的是讓 LLM， agent

00:15:17.940 --> 00:15:20.400
可以透過同一套標準去呼叫外部的 tools

00:15:20.955 --> 00:15:21.780
resources 還有 prompts

00:15:22.280 --> 00:15:24.419
我自己最喜歡的比喻是

00:15:24.419 --> 00:15:26.780
MCP 就像 AI 世界的 USB-C

00:15:26.780 --> 00:15:29.280
以前你買新的筆電，新的手機，新的滑鼠

00:15:29.280 --> 00:15:30.700
每個東西插頭都不一樣

00:15:30.760 --> 00:15:33.000
每出一臺新裝置就要再買一堆轉接線

00:15:33.340 --> 00:15:35.320
USB-C 出現之後全部統一了

00:15:35.320 --> 00:15:36.679
一條線可以接所有東西

00:15:37.119 --> 00:15:38.940
MCP 對 agent 來說就是這個角色

00:15:39.239 --> 00:15:41.440
不管你用 ChatGPT，用 Claude，用 Cursor

00:15:41.580 --> 00:15:42.580
還是用其他 agent host

00:15:42.659 --> 00:15:43.739
只要它支援 MCP

00:15:43.799 --> 00:15:46.840
就可以用同樣的方式去呼叫工具

00:15:46.840 --> 00:15:49.280
今天你寫好一個 Slack MCP server

00:15:49.380 --> 00:15:51.320
明天 ChatGPT 跟 Claude 都能用

00:15:51.419 --> 00:15:53.880
不需要為了不同 host 各寫一套整合

00:15:54.380 --> 00:15:55.159
接好工具之後

00:15:55.159 --> 00:15:56.159
最後還要做一件事

00:15:56.159 --> 00:15:58.359
那就是設計 human-in-the-loop 的 checkpoint

00:15:58.700 --> 00:16:00.020
什麼是 human-in-the-loop？

00:16:00.219 --> 00:16:02.080
簡單講就是在某些決策點

00:16:02.320 --> 00:16:04.640
agent 必須停下來請人類確認

00:16:04.640 --> 00:16:05.840
高風險的決策之前

00:16:06.106 --> 00:16:07.520
agent 要先停下來等人確認

00:16:07.599 --> 00:16:08.719
大規模變更之前

00:16:08.933 --> 00:16:10.320
agent 要等人按 OK 才繼續

00:16:10.940 --> 00:16:11.960
為什麼要這樣設計？

00:16:12.080 --> 00:16:13.599
因為任何 agentic workflow

00:16:13.599 --> 00:16:14.539
不管多成熟

00:16:14.539 --> 00:16:16.700
總會有些 edge case 是 agent 沒辦法判斷的

00:16:17.200 --> 00:16:19.799
這時候你要嘛讓 agent 亂猜，風險很高

00:16:19.799 --> 00:16:22.479
要嘛讓它停下來問人類，風險可控

00:16:22.919 --> 00:16:25.159
這樣整條 agentic workflow 才不是一個黑箱

00:16:25.159 --> 00:16:26.599
不是一臺失控的機器

00:16:26.599 --> 00:16:28.919
而是一個人類掌舵， agent 執行的系統

00:16:29.179 --> 00:16:30.760
你還是最後拍板的人

00:16:30.760 --> 00:16:33.320
但所有重複，機械，確定性的事

00:16:33.320 --> 00:16:34.979
都不用自己做了

00:16:34.979 --> 00:16:35.599
四步講完

00:16:35.840 --> 00:16:38.200
我們直接套到一個真實的公司場景上

00:16:38.200 --> 00:16:40.179
就是公司內部請求的分類系統

00:16:40.700 --> 00:16:42.599
想像你在一間兩百人的公司上班

00:16:42.599 --> 00:16:45.320
每天都會有人透過各種管道丟雜事進來

00:16:45.320 --> 00:16:47.299
可能是表單， Slack， Teams， Email

00:16:47.520 --> 00:16:48.340
或者你的私訊

00:16:48.500 --> 00:16:49.599
內容大概長這樣

00:16:50.219 --> 00:16:51.960
我要申請新系統的許可權

00:16:52.159 --> 00:16:53.599
這張發票可不可以報帳

00:16:53.960 --> 00:16:55.919
我下禮拜要 onboard 一個新同事

00:16:56.140 --> 00:16:58.119
他需要哪些工具的存取

00:16:58.599 --> 00:17:00.359
你處理這種事的 SOP 可能是

00:17:00.359 --> 00:17:01.440
開啟內部 ticket 系統

00:17:01.580 --> 00:17:02.479
掃一眼描述

00:17:02.479 --> 00:17:04.660
判斷這是 IT 問題，許可權申請

00:17:04.819 --> 00:17:07.459
HR 需求，財務報帳，還是其他類別

00:17:07.459 --> 00:17:09.260
補上 priority 和 deadline

00:17:09.260 --> 00:17:11.560
根據規則 assign 給對的 team 或對的人

00:17:11.560 --> 00:17:14.020
如果他寫得很模糊，就回信問清楚

00:17:14.079 --> 00:17:15.719
比方說你說電腦很慢

00:17:15.760 --> 00:17:17.680
是開機慢，還是某個系統很卡？

00:17:18.140 --> 00:17:19.180
這個流程不複雜

00:17:19.359 --> 00:17:21.900
但很煩，很重複，而且每天都要做

00:17:22.280 --> 00:17:23.599
最適合給 agent 處理

00:17:24.199 --> 00:17:26.520
那我們就用四步把它變成一條 agentic workflow

00:17:26.900 --> 00:17:28.540
Step 1 是標準化

00:17:28.660 --> 00:17:30.680
我們把這個流程寫成一份 SOP

00:17:30.819 --> 00:17:32.367
叫它 INTERNAL REQUEST TRIAGE

00:17:33.060 --> 00:17:34.239
裡面的引數可能有

00:17:34.289 --> 00:17:36.839
ticket 來源，原始文字，員工編號等

00:17:37.020 --> 00:17:38.339
然後是 Steps

00:17:38.339 --> 00:17:41.280
比方說 agent MUST 先根據員工編號

00:17:41.280 --> 00:17:43.400
驗證這個人是不是在職員工

00:17:43.400 --> 00:17:44.859
MUST 根據 ticket 內容

00:17:44.859 --> 00:17:47.859
把請求分類成 IT， HR， Finance 這三類

00:17:47.859 --> 00:17:50.400
SHOULD 根據 SLA 規則和關鍵字判斷 priority

00:17:50.400 --> 00:17:52.119
是 High， Medium，還是 Low

00:17:52.119 --> 00:17:53.660
MUST 產出一份結構化輸出

00:17:53.660 --> 00:17:55.219
包含 category， priority 等欄位

00:17:55.420 --> 00:17:57.380
如果是否需要澄清這個欄位是 true

00:17:57.690 --> 00:18:00.859
agent 必須再產出兩到三個需要問使用者的釐清問題

00:18:01.739 --> 00:18:03.900
你看，這份 SOP 已經有清楚的結構

00:18:04.380 --> 00:18:06.160
有明確的 MUST 跟 SHOULD

00:18:06.479 --> 00:18:08.359
有可以重複使用的 parameters

00:18:08.359 --> 00:18:10.140
這就是 Step 1 做的事

00:18:10.500 --> 00:18:11.560
Step 2 是拆解

00:18:11.560 --> 00:18:12.739
把這個任務拆成兩個 skill

00:18:13.140 --> 00:18:14.579
第一個叫 internal request triage

00:18:14.839 --> 00:18:17.300
專門做分類，判斷 priority，推薦 assignee

00:18:17.619 --> 00:18:18.939
它的 input 是 ticket 文字

00:18:19.206 --> 00:18:20.160
output 是一份 JSON

00:18:20.519 --> 00:18:22.540
category 是哪一類， priority 多高

00:18:22.540 --> 00:18:25.040
推薦 assignee 是誰，要不要釐清

00:18:25.500 --> 00:18:28.300
第二個 skill 叫 internal request reply drafting

00:18:28.300 --> 00:18:30.660
它的 input 就是第一個 skill 的 JSON output

00:18:30.900 --> 00:18:32.760
它要做的事是根據 triage 結果

00:18:32.859 --> 00:18:34.540
產生給同事看的回覆草稿

00:18:34.619 --> 00:18:36.959
告訴他這個問題會由誰處理

00:18:36.959 --> 00:18:38.459
大概多久會回覆

00:18:38.560 --> 00:18:40.160
兩個 skill 各做各的事

00:18:40.800 --> 00:18:42.719
靠 JSON artifact 串起來

00:18:42.979 --> 00:18:45.319
triage 失敗，不影響 reply-drafting 的邏輯

00:18:45.780 --> 00:18:46.800
reply-drafting 改格式

00:18:46.939 --> 00:18:49.739
不需要動到 triage 的分類邏輯

00:18:49.979 --> 00:18:51.619
Step 3 是雙向開發

00:18:51.880 --> 00:18:54.040
寫完第一版之後，跑一次

00:18:54.339 --> 00:18:55.380
一定會發現問題

00:18:55.619 --> 00:18:58.060
可能是某類請求一直被誤分類成 Other

00:18:58.300 --> 00:19:00.159
可能是 priority 永遠都判 Medium

00:19:00.380 --> 00:19:02.739
可能是 assignee 老是推薦給已經離職的人

00:19:03.260 --> 00:19:05.079
沒關係，回頭改 SOP

00:19:05.079 --> 00:19:07.680
補一條規則進去，再跑一次，再改

00:19:07.900 --> 00:19:08.880
三五輪之後

00:19:08.880 --> 00:19:11.199
整個 triage 的準確度就會趨於穩定

00:19:11.680 --> 00:19:13.719
Step 4 是整合，也是最後一步

00:19:13.719 --> 00:19:16.119
把這條 workflow 接到真實系統上

00:19:16.160 --> 00:19:17.219
我們加一個小 script

00:19:17.420 --> 00:19:20.939
把 triage 結果寫回公司內部的 tracking sheet

00:19:20.939 --> 00:19:22.439
可能是 Notion，可能是 Jira

00:19:22.439 --> 00:19:23.900
可能就是一個 Google Sheet

00:19:23.900 --> 00:19:25.880
然後在高風險的請求之前加一個

00:19:25.919 --> 00:19:26.939
human-in-the-loop checkpoint

00:19:26.939 --> 00:19:28.859
比方說涉及財務超過五千塊

00:19:28.920 --> 00:19:30.959
或者涉及 admin 許可權變更的請求

00:19:31.226 --> 00:19:32.920
agent MUST 停下來等人按 OK

00:19:33.560 --> 00:19:35.040
整條串起來就是

00:19:35.040 --> 00:19:37.599
讀 ticket，自動分類，產生回覆草稿

00:19:37.699 --> 00:19:40.219
寫回追蹤系統，必要時請人確認

00:19:40.599 --> 00:19:42.260
一份原本只能給人跑的 SOP

00:19:42.260 --> 00:19:43.880
就這樣變成一條每天自動跑

00:19:43.920 --> 00:19:47.180
就算出錯也能第一時間知道怎麼修的 workflow 了

00:19:47.180 --> 00:19:49.500
我把這部影片的內容做成了一組 prompt 工具包

00:19:49.500 --> 00:19:50.500
總共五個 prompt

00:19:50.500 --> 00:19:52.280
陪你一起拆解你最重複的 SOP

00:19:52.400 --> 00:19:53.959
變成一條真的能用的 workflow

00:19:54.199 --> 00:19:56.060
完整文章我會放在資訊欄

00:19:56.060 --> 00:19:57.260
有需要的可以看看

00:19:57.260 --> 00:19:58.180
順帶補充一下

00:19:58.180 --> 00:19:59.319
今天這隻影片講的內容

00:19:59.439 --> 00:20:01.260
不是工程師圈內的小眾興趣

00:20:01.260 --> 00:20:02.619
前面提到的 MCP

00:20:02.660 --> 00:20:04.739
目前已經被 ChatGPT， Claude， Cursor

00:20:04.739 --> 00:20:06.380
各種 IDE 跟 agent 平臺採用

00:20:06.900 --> 00:20:08.680
Anthropic 在2025年初

00:20:08.680 --> 00:20:11.619
把這個協定整個捐給 Linux Foundation 底下的

00:20:11.619 --> 00:20:12.479
Agentic AI Foundation

00:20:12.479 --> 00:20:15.119
意思就是這個東西不再是某一家公司的私有規格

00:20:15.119 --> 00:20:17.020
而是一個有基金會背書

00:20:17.160 --> 00:20:19.040
會長期維護的開放標準

00:20:19.300 --> 00:20:20.579
再拉大一點看

00:20:20.579 --> 00:20:23.739
IBM， AWS 還有 ServiceNow 這些大公司

00:20:23.739 --> 00:20:27.420
都在自己的產品線裡把 agentic workflow 跑起來了

00:20:27.420 --> 00:20:29.760
ServiceNow 現在處理 IT ticket， HR 請求

00:20:29.760 --> 00:20:31.040
各種內部服務流程

00:20:31.040 --> 00:20:33.180
都已經是用 agentic workflow 在跑

00:20:33.180 --> 00:20:34.780
而不是傳統的規則引擎

00:20:35.380 --> 00:20:36.579
所以今天這套

00:20:36.579 --> 00:20:38.739
Human SOP 轉 agentic workflow 的方法論

00:20:38.920 --> 00:20:40.560
不是為了學一個新的 buzzword

00:20:40.660 --> 00:20:42.739
不是為了寫一份報告給老闆看

00:20:42.739 --> 00:20:45.479
而是每一位 AI 工作者在未來兩三年

00:20:45.479 --> 00:20:47.160
都要具備的競爭力

00:20:47.160 --> 00:20:48.719
最後回到個人身上

00:20:48.719 --> 00:20:50.780
你不用一次把公司所有流程

00:20:50.780 --> 00:20:51.939
都變成 agentic workflow

00:20:52.160 --> 00:20:53.400
那會把你自己搞死

00:20:53.619 --> 00:20:55.160
你只需要做一件小事

00:20:55.160 --> 00:20:56.319
找一份你手上最無聊

00:20:56.319 --> 00:20:58.160
但又一直在重複做的 Human SOP

00:20:58.160 --> 00:20:59.660
可能是每週的週報

00:20:59.660 --> 00:21:00.920
每次 release 前的 checklist

00:21:00.920 --> 00:21:02.739
或者每次新人 onboard 的固定流程

00:21:02.979 --> 00:21:04.560
挑你最不想做的那個

00:21:04.599 --> 00:21:06.699
然後照著影片中提到的四步走一遍

00:21:07.060 --> 00:21:08.400
不用一開始就做到完美

00:21:08.439 --> 00:21:10.219
也不用一開始就完全自動化

00:21:10.400 --> 00:21:12.180
先有一個跑得起來的

00:21:12.180 --> 00:21:14.040
可以替你省 30% 時間的版本

00:21:14.040 --> 00:21:14.920
再慢慢迭代

00:21:15.439 --> 00:21:16.839
你不是在學怎麼用 AI

00:21:16.839 --> 00:21:19.579
而是在學怎麼設計給 AI 用的工作流

00:21:19.800 --> 00:21:21.140
前者半年就會過時

00:21:21.140 --> 00:21:22.540
後者越來越值錢

00:21:22.800 --> 00:21:24.660
在 MCP， agentic workflow

00:21:24.840 --> 00:21:26.439
multi-agent 系統越來越普及的世界

00:21:26.459 --> 00:21:27.579
能把流程拆好

00:21:27.579 --> 00:21:29.339
設計成 agent 真的能執行的 workflow

00:21:29.359 --> 00:21:31.579
這種能力的價值只會越來越高

00:21:31.859 --> 00:21:33.920
那以上就是今天的內容

00:21:33.920 --> 00:21:36.560
各位喜歡的話記得幫我按讚追蹤加分享

00:21:36.660 --> 00:21:38.680
這是我持續創作下去的動力

00:21:38.800 --> 00:21:39.599
我們下次見