2026-05-13-Stanford-AI系統課程

Properties2
tags來源/文章, 來源/youtube, 來源/逐字稿, 狀態/草稿, 領域/llm, 領域/ai系統設計
aliasesStanford AI 系統課程, Beyond LLM 中文整理, 從 LLM 到 Agentic Workflow, 一部影片看完 Stanford AI 系統課程

閱讀時間約 53 分鐘

一部影片看完 Stanford AI 系統課程，從 LLM 到 Agentic Workflow

後設資料

  • URL：https://www.youtube.com/watch?v=eKW9ITaltWw
  • 來源類型：YouTube 影片 / 課程整理逐字稿（使用者貼入全文；yt-dlp metadata 與字幕校準）
  • YouTube metadata：title 一部影片看完 Stanford AI 系統課程，從 LLM 到 Agentic Workflow；upload date 2026-05-04；duration 1644s；channel / uploader Gary Chen
  • 作者 / 講者：Gary Chen
  • 發表日：2026-05-04（yt-dlp metadata）
  • 語言：繁體中文口語逐字稿
  • 主題：LLM 應用設計、Prompt Engineering、Fine-Tuning、RAG、Agentic Workflow、MCP、Eval、Multi-Agent

一句話濃縮

這支影片把 Stanford Beyond LLM 課程整理成 AI Builder 的系統設計路線：不要只等待更強 base model，而要在既有 LLM 上用 Prompt-Engineering、RAG、Fine-Tuning、工具、記憶、Agentic-Workflow 與 LLM-Evaluation 疊出能在商業場景中穩定完成任務的系統。

提取要點

1. 從 base model 橫軸轉到 augmenting LLM 縱軸

  • 一般 builder 無法自己訓練下一代 base model；可施力的是在既有模型上疊工程技術，也就是 Augmented-LLM。
  • Base model 的限制包含：缺乏公司 / 產業 領域知識、資訊落後、輸出難控制、長 context 中仍可能 lost in the middle。
  • 對產品而言，換更強模型不是完整解法；要把 prompt、檢索、工具、記憶、流程與評估一起設計。

2. Prompt Engineering 是基本功，Prompt Chaining 提供可觀測性

  • 好 prompt 至少要交代「給誰看、輸出格式、重點是什麼」。
  • BCG 顧問實驗提供兩個實務提醒：AI 任務能力有鋸齒邊界；使用者若太信任 AI 會在不擅長任務上比不用 AI 更差。
  • Centaur / Cyborg 是兩種協作模式：重複、流程明確的任務可委派；需判斷、創意、校正的任務要高頻來回。
  • Prompt-Chaining 的價值不只是提升輸出，而是把黑盒任務拆成可獨立測試、debug、觀察的步驟。

3. Fine-tuning 不是預設解；RAG 是補知識的常用解

  • Fine-Tuning 需要大量高品質標註資料，容易 overfit，且會被新 base model 世代快速追上；多數商業應用應先嘗試 prompt / RAG / workflow。
  • Fine-tuning 仍適合少數需要重複高精度輸出的領域，或 base model 在特定 domain 明顯吃力的任務。
  • RAG 解的是 domain knowledge、時效性、幻覺與長 context 命中問題；基本流程是 embedding → vector database → retrieval → final prompt。
  • 超長 context 理論上能讀更多資料，但實務仍受 latency、成本、更新效率與檢索精度限制；索引式 retrieval 仍有價值。

4. Agentic Workflow 是把提示詞、上下文與工具組成可運作系統

  • Agentic-Workflow 用來避開「agent」一詞過度泛化：它指的是把 prompts、外部工具、context management、memory、RAG 與多步決策組合成有結構的工作流程。
  • RAG 是 agent 可用的工具之一；agent 還能主動問資訊、查訂單、呼叫 API、完成操作。
  • Agentic 系統與傳統軟體的差異：資料更非結構化、邏輯更 fuzzy、工程師要像 manager 管方向和邊界、測試也更迭代探索。
  • 落地原則：能 deterministic 解的就 deterministic 解；fuzzy 部分要加護欄，例如申訴 / 真人審查。

5. Agent 的三個元件與三層自主性

  • Agentic workflow 的三個核心元件：Prompts、Context Management、Tools。
  • Context Management 的任務是把對的資訊在對的時間提供給 agent；memory 可粗分 working memory 與 archival memory。
  • Tools 分成做事工具（搜尋航班、訂飯店、付款）與查資料工具（CRM、資料庫、訂單紀錄）。
  • 自主性可分三層：hardcoded steps、hardcoded tools + agent 自行決定步驟、fully autonomous。影片建議從 hardcoded tools 起步，因為可控又有彈性。

6. MCP 把工具接入標準化，也可延伸到 agent-to-agent

  • Model-Context-Protocol 可被理解為 agent 與外部工具 / API / 資料源之間的協議層，降低每個 API 都要單獨教模型使用的整合成本。
  • 影片把 MCP 也延伸到 agent-to-agent communication：把別人做好的 agent 當工具呼叫，作為 multi-agent 系統的基礎想像。
  • 在 vault 現有分工中，這點與 Agent2Agent 互補：MCP 解 model-to-tool，A2A 解 agent-to-agent。

7. Eval 是 production agentic system 的命脈

  • LLM-Evaluation 應同時看三個維度：End-to-End vs Component-based、Objective vs Subjective、Quantitative vs Qualitative。
  • End-to-end 看整體體驗；component-based 才能定位哪一步壞掉。
  • Objective 可用 script 驗證，例如 order ID 是否寫對；Subjective 需要人工或 LLM-as-Judge，例如語氣、同理心、禮貌度。
  • LLM-as-Judge 可用 pair-wise comparison、single-answer grading、reference-guided pair-wise、rubric-based 等方式，最好先人工 error analysis 再設計自動 eval。
  • A/B test 要一次只改一個變因：固定 prompt 換模型，或固定模型換 prompt，否則無法歸因。

8. 客服 agent case study：先看人怎麼做，再拆給系統

  • 建 agent 的第一步不是選框架，而是去觀察真人客服怎麼處理任務。
  • 改地址客服流程可拆成：抽 intent / order ID / 新地址 → 查客戶紀錄 → 查公司政策 → 起草回信 → 寄 email。
  • 每一步再決定用 LLM one-shot、database tool、RAG、email tool 或 deterministic 程式。
  • 完整工程流程可收斂為三步：task decomposition、workflow design、build evals。

9. Multi-Agent 的理由是平行處理與復用，不是炫技

  • Multi-agent 的主要理由是可平行處理互不依賴的子任務，例如找航班、找飯店、查天氣。
  • 次要理由是 reusability：專門 agent 可被不同團隊重複使用。
  • 若單一 agent 足以完成，硬上 multi-agent 只會增加複雜度。
  • 互動模式可分 hierarchical 與 flat；對使用者來說通常應由一個 orchestrator 對外，再由後台專門 agent 協作。

提取概念

連結到此來源衍生 / 更新的 wiki 頁：

  • Agentic-Workflow（新建：Andrew Ng 語境下的系統設計 umbrella）
  • LLM-Evaluation（新建：production agentic system 的 eval 框架）
  • Fine-Tuning（新建：模型微調與 RAG / prompt / harness 的取捨）
  • Augmented-LLM（補入「縱軸」：在既有 base model 上疊工程技術）
  • Prompt-Engineering（補入基本 prompt 三元素、Centaur / Cyborg 任務切換與 BCG 鋸齒邊界）
  • Prompt-Chaining（補入 observability / debug 價值與客服投訴拆步驟案例）
  • RAG（補入 embedding / vector database / chunking / long context trade-off）
  • Agent（補入 Stanford/Andrew Ng 式 hardcoded steps / tools / fully autonomous 三層自主性）
  • Context-Engineering（補入「對的資訊在對的時間提供給 agent」與 long context 仍需管理）
  • Model-Context-Protocol（補入 MCP 作為通用工具插頭，以及 agent-as-tool 的接口想像）
  • Agent2Agent（補入 agent-to-agent communication 與 agent-as-tool 心智模型）
  • Evaluator-Optimizer（補入與 LLM-as-Judge / eval system 的分工）
  • AI-幻覺（補入 RAG / eval 對抗 hallucination 的系統面）
  • MOC-LLM-應用設計（補入本來源作為 AI 系統設計整合來源）

觀察 / 待累積：

Ingest 筆記

2026-05-13

本來源是 broad course summary，且 vault 既有 MOC-LLM-應用設計 已有完整 agent / context / MCP / A2A / prompt cluster。因此處理策略不是逐章拆頁，而是：

  1. 新建三個高復用缺口頁：Agentic-Workflow 承接 Andrew Ng / Stanford 語境的「把 LLM 變成系統」；LLM-Evaluation 承接 production eval 框架；Fine-Tuning 承接模型微調與 RAG / prompt / harness 的 trade-off。
  2. 回寫既有頁：RAG、Prompt-Engineering、Prompt-Chaining、Agent、Model-Context-Protocol 等頁已存在，僅補入本來源帶來的 system design 角度。
  3. 不建立薄 entity：Gary Chen、Andrew Ng、Stanford、BCG 都不是本次主題對象；Stanford 課程與 BCG 顧問實驗列入觀察清單，等一手材料再處理。
  4. 二手來源標記：影片整理 Stanford 兩小時課程與 BCG 研究，但非課程原始講義；所有新概念頁都把本來源視為實務整理來源，而非唯一權威來源。

元命題：AI Builder 的工作不是迷信某個模型或框架，而是在每個任務上判斷哪些部分可 deterministic、哪些部分需 fuzzy，由 prompt、RAG、fine-tuning、tools、memory、workflow 與 eval 組成一個可觀測、可除錯、可逐步升級的系統。

原文（YouTube 字幕）

下文由 yt-dlp --write-subs --sub-langs zh-TW --sub-format vtt 取回 YouTube 字幕；使用者亦在本次訊息貼入完整逐字稿。保留時間戳以便回溯影片片段。

0:00 如果你有在關注 AI 0:01 這一兩年最炙手可熱的工作 0:03 一定是 AI Engineer，AI Builder 0:05 大型語言模型越強，這群人越吃香 0:07 他們有能力幫公司打造內部工具 0:10 優化運營流程 0:11 也已經有一堆人自己動手把想法做成產品 0:13 成立了自己的公司 0:15 而這種人，現在每間公司都在搶 0:17 想學 AI 的人很多 0:19 但大多數人都不知道從哪裡下手 0:21 市面上的資源不是太破碎，就是太過艱澀 0:24 看完還是不知道自己學到了什麼 0:26 或者下一步該往哪走 0:28 史丹佛大學有一堂課叫做 Beyond LLM 0:31 我認為這是目前最接近那個答案的東西 0:34 從大型語言模型的本質講起 0:36 一路帶到 Prompt Engineering 0:38 RAG，Fine-Tuning 0:39 Agentic Workflow 0:40 還有 Multi-Agent 的框架 0:42 這堂課時長兩小時 0:44 今天我就用一支影片的時間把核心整理給你 0:47 你看完之後 0:48 會對 AI 在商業領域上的應用有一套完整的認知框架 0:51 知道這些技術怎麼組合在一起 0:53 也能規劃自己接下來的學習路線 0:56 那我們廢話不多說，直接開始 0:58 首先我們要先知道大型語言模型的限制是什麼 1:02 LLM 要變強有兩條路 1:04 第一條是橫軸 1:05 就是換更強的 base model 1:07 比方說從 GPT-4 升級到 GPT-5 1:10 但橫軸是 OpenAI 跟 Anthropic 在做的 1:13 一般人沒有那個能力 1:14 也沒有那個金錢去訓練自己的大型語言模型 1:18 你能施力的地方是縱軸 1:20 也就是在現有的 LLM 上面疊各種工程技術 1:23 又叫做 Augmenting LLM 1:25 也就是想辦法提升這些 base model 的能力 1:28 而這整堂課，包括這支影片 1:30 講的都是縱軸的事情 1:32 如果你只會使用 base model 1:34 在商業場景上一定會撞牆 1:36 舉個例子，ChatGPT 剛出來的時候 1:39 沒有連網功能，沒辦法調用工具 1:41 充其量就是一個很聰明的問答機器人 1:44 沒辦法實際幫你做完一件事 1:46 Stanford 的教授整理了 base model 幾個常見的限制 1:49 第一是缺乏 domain knowledge 1:51 比方說有一組學生在做自動化農業設備 1:54 要用相機判斷作物有沒有生病 1:57 這種農業病害的 dataset 市面上根本找不到 1:59 換句話說你的公司資料，內部文件，產品規格 2:03 base model 都不知道 2:04 它也沒辦法根據這些資料幫你解決問題 2:07 第二是資訊落後 2:09 模型不可能每幾個月重訓一次 2:11 新詞，新事件，新公司它通通不認識 2:14 年輕人在用的網路流行用語 2:16 模型大多也聽不懂 2:18 第三個，控制很難 2:20 LLM 是機率性輸出 2:22 同樣的 prompt 兩次跑可能結果不一樣 2:24 在 ChatGPT 上聊天當然 OK 2:26 但你想想 production 環境 2:28 使用者問退費 2:29 AI 一下說可以一下說不行，公司就麻煩了 2:32 教授說，就連 OpenAI 跟 xAI 這種資金最多 2:36 人才最齊的團隊 2:37 都還沒辦法把 LLM 完全控制好 2:39 更何況一般公司 2:41 第四個，當 context 太長 2:43 模型的表現會顯著退步 2:45 現在主流模型的 context window 2:47 已經拉到 100 萬 token 2:48 差不多十幾本書的長度 2:50 但在這麼大的 context 裡 2:52 還是會出現 lost in the middle 的現象 2:54 簡單講 2:54 你把一個 Gary 午餐吃了一顆蘋果這樣的小細節 2:57 藏進公司過去一年的會議記錄裡 3:00 再問模型 Gary 午餐吃了什麼 3:02 雖然這個狀況現在已經顯著改善 3:05 但 LLM 有時候還是會答不出來 3:07 想做 AI 產品 3:08 光換更強的 base model 不夠 3:10 你需要在縱軸上施力 3:13 接下來這支影片的前半段會告訴你 3:15 強化單一 LLM 的三個工具和觀念 3:18 也就是 Prompt Engineering 3:19 Fine-Tuning，還有 RAG 3:21 影片後半段會進到系統設計 3:23 介紹 Agentic Workflow 跟 evaluation 評估方法 3:26 然後用一個客服 agent 的 case study 3:28 把這些東西串起來 3:29 最後也會帶到很多人感興趣的 Multi-Agent 3:32 那我們直接從 Prompt Engineering 開始講 3:34 Stanford 的教授說他不認為 prompt engineer 會是一個職業 3:38 因為提示詞工程應該是每個工程師都該會的基本技能 3:42 你不會靠 prompt engineering 當飯吃 3:44 但這個技能會讓你在職涯裡用一輩子 3:46 就像九九乘法表一樣是基本功 3:49 我之前有做過一部影片 3:50 專門在講 prompt engineering 3:52 有興趣的朋友可以去看看 3:53 關於 prompt engineering 3:55 有一個很有意思的研究我想分享給你 3:57 頂級管理顧問公司 BCG 做過一個實驗 4:00 他們把一群顧問分成三組 4:02 第一組沒有 AI 4:03 第二組可以使用 ChatGPT 4:05 第三組則是可以使用 ChatGPT 以外 4:07 還有接受撰寫提示詞的訓練 4:10 最後研究的結果發現三件事 4:12 第一個叫 The Jagged Frontier，鋸齒邊界 4:15 意思是 AI 不是在所有任務上都表現得好 4:19 有些任務搭配 AI 顯著加分 4:21 但有些任務 AI 反而扯後腿 4:24 第二個發現叫 Falling asleep at the wheel 4:26 翻成中文就是在方向盤前打瞌睡 4:29 當你不知道任務剛好是 AI 不擅長的 4:32 卻太信任它把產出直接送出 4:34 結果比沒用 AI 還慘 4:36 也就是說，你要知道 AI 的邊界在哪 4:39 才不會在它弱的地方踩雷 4:41 第三個現象最有趣 4:42 他們發現使用 AI 的方式分成兩種 4:45 分別是 Centaurs 跟 Cyborgs 4:47 Centaur 是半人馬，也就是分工委派型 4:50 丟一個長 prompt 給 AI 叫它做整份簡報 4:53 自己去做別的事 4:55 Cyborg 是生化人，是高頻來回型 4:57 跟模型一句一句對話協作 4:59 Stanford 的教授說 5:01 學生的使用習慣會比較像 cyborg 5:03 而企業在自動化 workflow 時比較像 centaur 5:06 那你應該用哪一種？關鍵是看任務性質 5:10 重複性高，流程清楚的任務 5:12 用 centaur 模式委派出去就好 5:14 需要判斷，需要創意，需要來回校正的任務 5:18 cyborg 模式才能逼出 AI 的最佳輸出 5:21 兩者沒有好壞之分，實務上兩種都會用 5:25 重點是要有意識地切換 5:26 接著進到實作 5:28 通常一個好 prompt 要有三個東西 5:30 給誰看，產出格式，重點是什麼 5:33 請幫我總結這篇文章是一個很爛的提示詞 5:36 因為什麼資訊都沒給 5:38 但如果你寫的是請將這份再生能源論文 5:41 整理成 5 個重點摘要 5:42 並且聚焦在其背後的政策意涵上 5:45 模型立刻知道對象是政策制定者 5:48 長度是 5 個點，重點放在政策意涵上 5:51 你的產出品質會立刻提升 5:53 但教授說，prompt engineering 裡最常用 5:56 最重要的一個技巧不是這些，是 Prompt Chaining 6:00 注意，chaining 跟 Chain of Thought 不一樣 6:03 Chain of Thought 是叫模型 step by step 思考 6:06 Chaining 則是把一個複雜的 prompt 拆成多個獨立的 prompt 6:09 前一個的 output 餵給下一個 6:11 有用過 n8n 的朋友應該知道我在說什麼 6:14 舉個例。你要做客戶投訴回信 6:17 單一 prompt 寫法是讀這封投訴信 6:20 寫一封專業的回應 6:22 這就是一個黑盒子 6:23 最後的產出如果有問題 6:25 你也不會知道該調整哪裡 6:27 但如果使用 prompt chaining 6:29 拆成三個 prompt 6:30 第一個抽出客戶在抱怨什麼 6:32 第二個用抽出來的問題起草大綱 6:34 第三個用大綱寫完整回信 6:37 每一步都可以獨立測試，獨立 debug 6:40 Chaining 不只讓模型表現更好 6:42 也讓你得到 observability 6:44 能觀察 LLM 在做什麼，哪個流程出了問題 6:47 講完 Prompt Engineering，下一個是 Fine-Tuning 6:50 Stanford 教授對 fine-tuning 的立場很簡單 6:53 能不做就不做，原因有四個 6:56 第一，要大量的優質數據 6:58 如果你想要自己 fine-tune 模型 7:00 就要有大量高品質的，標注好的資料 7:02 要做到這件事情的成本對一般人來說太高了 7:06 第二，容易 overfit 7:08 模型容易在你那個特定任務上變很強 7:11 但通用問題反而答不出來 7:13 就會失去 base model 原本的廣度 7:16 第三，時效性差，這應該是最傷的點 7:19 你花兩個月 fine-tune 完一個模型上線 7:21 下個月新一代 base model 就出來 7:23 直接打贏你 fine-tune 的版本 7:26 第四，通常用 prompt engineering 也可以達到一樣的效果 7:29 而且成本低很多 7:30 你想換新 base model 7:31 原本的 prompt 大多都是 portable 的 7:34 但 fine-tuning 的模型不行 7:36 當然，針對少數情境 7:38 fine-tune 還是值得做的 7:40 比方說法律，科學那種需要重複高精度輸出的領域 7:44 或者 base model 在某個 domain 上表現吃力 7:47 這些情況下，fine-tune 都會有幫助 7:49 但對大多數的人來說 7:50 其實不會有太大的效益 7:52 所以，如果你想要把特定的 domain knowledge 塞進模型 7:55 單純的提示詞工程可能塞不下 7:58 fine-tuning 的成本效益又對不起來 8:00 那實作端應該怎麼辦呢？ 8:02 Stanford 教授給出的答案是 RAG 8:04 RAG 是 AI 工程師面試最常考的題目之一 8:08 面試官常常會請你用 5 歲小孩聽得懂的方式解釋什麼是 RAG 8:13 你做 AI Builder 也好，做 AI 工程師也好 8:15 這個是你一定要知道的事情 8:17 RAG 解的痛點有幾個 8:19 context window 太小，長 context 抓不準 8:22 資訊有時效性，或者模型會產生幻覺 8:25 RAG 的做法很單純 8:27 我用藥物副作用這個需要高度準確的醫療場景來說明 8:31 通常 RAG 的做法是這樣的 8:33 先把所有的資料，文件用 embedding 模型 8:36 把這些資訊轉成向量，存進向量資料庫 8:38 英文叫做 vector database 8:41 所謂向量，就是把一段文字的語意轉換成一串數字 8:45 語意相近的文字 8:46 轉出來的數字陣列在數學空間裡距離也會比較近 8:50 所以當使用者問藥物 A 的副作用 8:53 我們不是在做關鍵字比對 8:55 而是在找語意最接近的文件片段 8:58 就算文件裡寫的是不良反應而不是副作用 9:01 一樣能找到 9:02 使用者的問題也用同個 embedding 模型轉成向量 9:05 再用距離 metric 從 vector database 裡 9:08 找出最相近的 documents 9:10 最後把這些 documents 加上 system prompt 9:12 加上 user query，組合成餵給 LLM 的最終 prompt 9:16 Prompt template 大概長這樣 9:18 根據以下 documents 回答使用者的問題 9:21 如果 documents 裡沒有答案，就說『我不知道』 9:23 這樣設計是為了把模型鎖在你提供的資料範圍內 9:27 避免它自由發揮，憑空捏造 9:29 當然，你還可以要求模型回答時附上這個答案來自第幾頁 9:34 第幾章，第幾行加超連結 9:36 這樣使用者可以自行回溯資料源進行驗證 9:39 但是單純這樣做有時候不夠 9:41 比方說一種藥的相關文件可能足足有 50 頁 9:45 整份直接轉成向量，那很多細節遺失其中 9:49 所以通常會搭配 chunking 9:51 最基本的 chunking 是把文件切成固定大小的片段 9:54 每段各自轉成向量 9:56 更進階的做法是多層次存儲 9:58 同時保留整篇，每章，每段的向量 10:01 retrieval 時可以先找到相關的章節 10:03 再往下鑽到精確的段落 10:05 這樣在大文件裡的命中率會更高 10:08 還有一個最近比較多人在討論的話題 10:10 有人說，像現在已經有模型支援超長的 context window 10:14 等這個技術成熟，算力夠便宜 10:17 base model 直接讀完整個資料庫 10:18 RAG 就沒用了 10:20 但 Stanford 的教授認為這樣的說法理論上對 10:23 實務上錯 10:25 因為實際上你還是會遇到很多問題 10:27 比方說 Latency，你想想看 10:29 每次問問題，模型都要把整個 Google Drive 重讀一次 10:33 沒人等得了 10:35 就像搜尋引擎也是靠預先建好的索引來快速定位資料 10:38 不可能每次 query 都把整個網路重新爬過一遍 10:41 所以 RAG 除了準確度以外 10:43 還有檢索效率，可即時更新這類的優勢 10:46 而這些優勢在可預見的未來都還是有其存在的價值 10:50 好，到這邊我們講完了影片的第一部分 10:53 從 base LLM 的限制出發 10:54 我們看了 Prompt Engineering 10:56 Fine-Tuning 還有 RAG 10:56 這三個工具本質上都是在強化單一個 LLM 的能力 11:00 但單一個 LLM 再強，還是有它做不到的事 11:03 所以接下來進入第二部分 AI 系統設計 11:06 我們會講 Agentic Workflow 11:08 Evaluation 還有 Multi-Agent 11:09 這些東西讓你能把 AI 從一個會回答問題的模型 11:13 變成一套真正可以運作，實際產出價值的系統 11:17 看到這邊，如果你覺得這支影片對你有幫助 11:20 想請你幫我按個讚，點個追蹤 11:21 這是我持續創作下去的動力 11:23 那我們直接進 Part 2 11:25 先講一下 agentic workflow 這個命名 11:27 這個詞來自吳恩達 11:29 如果你不認識他 11:30 吳恩達是 Coursera 的共同創辦人 11:32 Google Brain 的創始負責人 11:34 前百度首席科學家 11:35 是在 AI 領域講話有一定份量的男人 11:38 吳恩達用 agentic workflow 這個詞 11:40 是因為 AI Agent 已經被用到爛掉了 11:43 有人寫了一個很長的 prompt，叫 agent 11:46 有人做了複雜的 multi-agent 系統 11:48 也叫 agent 11:49 這個詞什麼都能套，反而什麼都說不清楚 11:52 所以他用 agentic workflow 來精確描述一件事 11:56 把一堆提示詞，外部工具，還有各種元件 11:59 組合進一個有結構的工作流程裡，成為一套系統 12:02 這就叫做 agentic workflow 12:05 還記得我們前面講的 RAG 嗎？ 12:07 RAG 主要做一件事 12:08 給 LLM 外部資料當參考 12:10 但 agent 把 RAG 當作工具之一 12:13 外加 tool calls，memory，多步驟決策 12:15 所以能做到 RAG 單獨做不到的事 12:18 舉個例子，使用者說我想退這筆訂單 12:21 RAG 只能丟政策文件給你 12:24 agent 則是用 RAG retrieve 政策 12:25 主動問訂單編號，用 tool 查訂單 12:28 確認退費 12:29 告訴你 3 到 5 個工作天會處理 12:31 RAG 是工具，Agent 是使用 RAG 這個工具的系統 12:35 要打造 agentic workflow 12:36 你的工程心態要先翻轉過來 12:39 因為傳統 software 跟 agentic AI software 12:42 在四個面向都很不一樣 12:44 首先是資料 12:45 傳統軟體吃結構化資料 12:47 JSON，資料庫，表單，格式固定，邊界清楚 12:50 Agentic 系統吃的是自由文本 12:53 圖片，音訊，沒有固定格式 12:56 第二個是邏輯 12:57 傳統 software 是 deterministic 12:59 同樣的 input，永遠給你同樣的 output 13:03 可預測，可重現 13:05 Agentic 系統是 fuzzy 的 13:07 意思是同樣的 input 13:08 不同時間跑可能給你不同的 output 13:11 因為 LLM 本身有隨機性 13:13 加上它會根據 context 做判斷 13:15 沒有一個固定答案 13:17 第三個是架構心態，這個最重要 13:20 傳統工程師的思維是寫 microservices 13:22 寫 monolith 13:23 你精確控制每一步執行路徑 13:26 Agentic 系統的思維是 think like a manager 13:28 你給 AI 一個目標和限制，讓它自己決定怎麼完成 13:32 你管的是方向和邊界，不是每一行程式碼 13:36 第四個是測試 13:37 傳統測試是確定性的，跑一百次結果一樣 13:40 Agentic 測試是迭代探索式的 13:42 因為系統本身是非確定性的 13:45 加上它對 context 非常敏感 13:46 你沒辦法窮舉所有情況 13:48 知道這四件事之後 13:49 第一個落地原則就跟著來了 13:51 能 deterministic 解的問題，就 deterministic 解 13:54 剩下 fuzzy 的部分，加上護欄 13:58 教授舉自己的例子 13:59 他們做 skills assessment 14:01 選擇題，配對題，拖拉題用 deterministic 算分 14:04 因為這些有標準答案，對就是對，錯就是錯 14:07 但語音題，語音加 coding 的混合題型 14:10 沒有標準答案，沒辦法 deterministic 評分 14:12 只能讓 LLM 去判斷 14:14 這就是 fuzzy scoring 14:15 也就是沒有標準答案的評分 14:17 你請 LLM 聽一段語音回答 14:20 它要判斷這個人有沒有真的理解這個概念 14:22 表達是否清晰，邏輯有沒有跑掉 14:24 這些不是對或錯，是一個程度的判斷 14:28 LLM 會給你一個分數 14:29 但這個分數是它覺得合理的答案，不是算出來的 14:34 Fuzzy 的問題是它一定會犯錯 14:36 LLM 可能誤判一個正確答案 14:38 或是對模稜兩可的回答給出偏低的分數 14:41 在考試評分這種高風險的場景，這不可接受 14:44 所以他們設計了一個 Appeal feature 14:46 受測者可以對 agent 的判分提出申訴 14:49 由真人介入審查並糾正 14:52 這就是護欄的具體形式 14:53 不是試圖讓 AI 零錯誤 14:55 而是在它出錯的時候有人接得住 14:58 好，原則講完了 15:00 要實際打造一個 agent，你需要哪些東西？ 15:02 教授用訂機票去巴黎當範例 15:05 整理出三個核心要素 15:07 第一個是 Prompts 15:08 前面講的提示詞工程，在 agent 裡就是這一塊 15:11 你怎麼告訴 AI 它的角色是什麼 15:14 它能做什麼，不能做什麼 15:15 第二個是 Context Management 15:17 也就是怎麼管理 agent 在每一個當下看得到的資訊 15:21 這包含幾件事 15:23 Memory，對話歷史 15:24 也可能有 RAG 撈回來的資料 15:26 通通都要塞進有限的 context window 裡 15:28 你要決定什麼重要，什麼可以丟，什麼要壓縮 15:32 Context Management 本質上只做一件事 15:34 那就是把對的資訊在對的時間提供給你的 agent 15:38 Memory 本身又分兩層 15:40 Working memory 是高頻，要快的 15:42 比方說使用者的名字，這次的目的地是巴黎 15:45 Archival memory 是低頻，可以慢一點的 15:49 比方說使用者過去五年的訂房紀錄 15:52 需要的時候再去撈 15:54 第三個是 Tools 15:55 也就是 agent 能呼叫的外部能力 15:58 通常分成兩種 15:59 一種是做事的 16:00 比方說 Flight Search，Hotel Booking，Payment 16:02 一種是查資料的 16:04 比方說去 CRM 撈客戶資料 16:05 去資料庫查訂單紀錄 16:07 另外，課堂上教授把 agent 的自主性分為三層 16:11 最低是 hardcoded steps 16:13 步驟全寫死，先識別用戶的意圖 16:16 再 lookup history，最後呼叫 API，照順序走 16:19 安全，可預測，但很僵硬 16:22 遇到預期外的情況就卡住 16:24 第二層是 hardcoded tools 16:25 但讓 agent 自己決定執行步驟 16:28 你給它一組工具，告訴它你是 travel agent 16:31 這些是你能用的工具，怎麼用你決定 16:34 掌控工具範圍，但給 agent 空間判斷怎麼組合 16:38 這是目前最常見的 production setup 16:40 也是教授推薦的起點 16:42 第三層是 fully autonomous 16:44 agent 自己決定步驟，甚至自己創工具 16:48 給它 code editor，給它 web search 16:50 叫它自己寫 code 解決問題 16:52 能力最強，但風險也最高 16:54 你沒辦法完全預測它會做什麼 16:57 如果 agent 判斷錯誤，自己訂了 100 張機票 16:59 你就完蛋了 17:01 還有一個關鍵概念是 MCP 17:03 Model Context Protocol 17:05 傳統做法是你要替每一個 API 單獨寫串接邏輯 17:08 教 LLM 這個 API 怎麼用 17:10 那個 API 要傳什麼參數 17:11 MCP 的做法是在中間放一個協議層 17:15 agent 不需要認識每一個 API 17:17 它只需要跟 MCP server 溝通 17:19 MCP 負責幫它跟後面的服務打交道 17:22 你可以把 MCP 想成一個通用插頭 17:24 以前每個國家的插座規格不一樣 17:26 你要帶一堆轉接頭 17:28 有了 MCP，插一個就全通了 17:31 Stanford 教授還有提到對 MCP 一個更大的想像 17:33 那就是 agent-to-agent communication 17:36 你可以把別人做好的 agent 當作一種工具 17:38 讓你自己的 agent 去呼叫它 17:40 就像現在 agent 呼叫 API 一樣 17:42 這是 multi-agent 系統的基礎 17:44 我們等一下會講到 17:46 不管是單一 agent 還是 multi-agent 17:47 上線之前都要先回答同一個問題 17:49 怎麼知道它真的有用？答案是 eval 17:52 也是 production agentic 系統的命脈 17:54 教授在課堂上給了一個完整的 eval 框架 17:56 是三個維度交叉 17:58 第一個維度是 End-to-End 還有 Component-based 18:02 End-to-end 是看整體 18:04 使用者用完給幾分，滿不滿意 18:07 Component-based 是拆開每一步看 18:09 比方說 18:10 這個 tool 老是忘記更新 email 18:11 送 email 那一步格式不對 18:13 光看整體你知道哪裡壞，但不知道為什麼壞 18:16 光看 component 你可能修了細節但整體體驗還是差 18:20 實務上兩個都要做 18:22 第二個維度是 Objective 還有 Subjective 18:25 也就是客觀和主觀的評價方式 18:28 Objective 是可以自動驗證的 18:30 使用者說 order ID 是 X 18:31 LLM 寫進 DB 變成 Y 18:33 這種東西你可以寫個 Python script 自動對齊 18:36 因為對就是對，錯就是錯 18:38 Subjective 是沒有標準答案的 18:40 語氣好不好，回答夠不夠有同理心 18:43 這種要靠人工評分 18:44 或是用另一個額外的 LLM 當作評審 18:47 這個等等我會細講 18:49 第三個維度是 Quantitative 還有 Qualitative 18:52 Quantitative 是數字 18:54 改地址成功率幾趴，每個環節的延遲多久 18:58 Qualitative 是感覺 18:59 在哪裡幻覺，語氣哪裡不對 19:02 使用者哪一步卡住 19:03 這個要人工一筆一筆看，沒有捷徑 19:06 剛剛提到的用 LLM 當作評審 19:08 又稱 LLM-as-Judge 19:10 這是做 subjective eval 常用的做法 19:13 設計上有四種主流玩法 19:15 第一種是 Pair-wise comparison 19:17 給 judge 兩個答案，問它哪個比較好 19:20 第二種是 Single-answer grading 19:22 直接打一到五分 19:23 第三種是 Reference-guided pair-wise 19:25 多給一個標準答案做對比，讓評分更有依據 19:29 第四種是 Rubric-based 19:30 你自己定義評分標準 19:32 比方說五分等於一百字以內，含三個重點 19:35 第一句是 overview 19:36 零分等於答非所問，冗長失焦 19:38 這四種可以混用 19:40 比方說 rubric-based 加上 few-shot examples 19:42 讓評審更知道你要什麼 19:45 怎麼實際跑一個 subjective eval？ 19:47 課堂上教授用 travel agent 的禮貌度評估當例子 19:50 共拆成四個步驟 19:52 第一步是 error analysis 19:54 從一千個使用者裡抽二十個對話，人工讀 19:58 你可能就會發現 LLM 講話超短 20:00 有點機車，沒同理心 20:02 這步不能省，你要先知道問題長什麼樣 20:04 才能設計出對的 eval 20:07 第二步是設計 eval 20:08 用 LLM-as-Judge 加上自己寫的禮貌度 rubric 20:11 把你在第一步發現的問題翻譯成評分標準 20:15 第三步是 A/B test 模型 20:17 固定 prompt，把底層模型從 GPT 換成 Opus 或者其他模型 20:21 然後跑同一批對話，judge 評分 20:23 看哪個模型禮貌度最高 20:26 第四步是 A-B test prompt 20:28 固定模型 20:29 把 act like a travel agent 改成 20:31 act like a helpful travel agent 20:33 看一個詞的差距影響有多大 20:36 核心原則只有一個 20:37 先人工掃出問題，再設計自動化 eval 20:41 而且模型跟 prompt 這兩個變因一次只動一個 20:43 不然不知道是哪個改動造成了差異 20:46 講完 eval，教授給了一個完整的 case study 20:48 把前面所有東西串起來 20:50 題目很簡單 20:51 我們要做一個客服 AI agent 20:53 使用者可能會說 20:54 『我要改 A127 訂單的地址，因為我搬家到建國南路了』 20:59 這樣的 AI 客服 agent 你會怎麼做？ 21:02 這題目有兩層 21:03 表面看是怎麼改地址 21:04 本質是怎麼做一個會自己處理客服請求的 agent 21:08 課堂上一個學生回答說 21:10 我會先去客服旁邊坐一到兩天 21:12 看他們實際怎麼處理這種請求 21:15 他們日常的工作流是什麼 21:17 教授很喜歡這個答案 21:18 因為你要先理解人怎麼做這件事 21:21 才知道怎麼讓 AI 做 21:22 而這就是做 agentic workflow 的第一步 21:24 叫做 task decomposition 21:26 也就是把大任務拆解成小任務 21:29 讓 LLM 可以逐個擊破 21:31 觀察之後，你會發現客服處理一個改地址請求 21:35 其實走了五步 21:36 第一步，抽出關鍵資訊 21:38 包含客戶的 intent 是什麼 21:41 order ID 是哪個，新地址是什麼 21:43 第二步，去資料庫查客戶紀錄 21:46 第三步，查公司政策 21:48 像是這筆訂單能不能改地址？是不是已經出貨了？ 21:52 第四步，根據前面收集到的資訊起草回信 21:55 第五步，送出 email 21:57 每一步都明確，這就是 task decomposition 22:00 有了拆解，下一步是決定每一步用什麼工具 22:03 第一步抽資訊 22:05 單純用 LLM 的一次 API 呼叫通常就能解決 22:08 第二步查和改 Database 22:10 要 custom tool 或 MCP server 22:12 第三步政策檢查，用 RAG 22:14 因為政策文件會更新，也需要有效率的檢索 22:17 不能讓客戶等太久 22:19 第四步是根據前幾步搜集到的資訊 22:21 開始撰寫 email 22:23 第五步送 email 22:24 用 agent 能夠使用的 email 寄送工具 22:28 做這些判斷的方式很簡單 22:30 先問自己哪些步驟是 fuzzy 22:32 哪些是 deterministic 22:33 再決定每一步是用 LLM one-shot 22:36 RAG，tool，還是其他工具 22:38 這就是 AI Builder 真實在做的工作 22:40 知道每個工具，每種技術的能力和限制 22:43 然後炒出一盤你需要的菜 22:45 最後是 build evals 22:47 把前面講的三個維度全部用上 22:49 End-to-end 看最終回覆正確性 22:52 語氣，使用者滿意度 22:54 Component-based 拆開看每一步 22:56 抽資訊的準度，API 錯誤率，政策遵守率 22:59 Objective 的部分可以自動驗證 23:01 抽出來的 order ID 是否正確 23:03 有沒有違反退費政策 23:05 Subjective 的部分要靠人工加 LLM-as-Judge 23:08 比方說回信是否有禮貌，有沒有同理心 23:11 Quantitative 看改地址成功率 23:14 latency，退費正確率 23:17 Qualitative 看哪裡有幻覺 23:18 哪裡語氣不一致 23:20 使用者在哪一步感到困惑 23:22 到這邊，一個完整的 AI 客服 agent 23:24 從零到上線的工程流程就出來了 23:26 其實總共就是三個步驟 23:28 先把大任務拆解成小任務 23:30 再設計工作流程 23:31 最後建立評估系統，確保產出穩定 23:34 這堂課的最後一個主題是 Multi-Agent 23:36 前面一個 agent 已經能拆步驟 23:38 call tool，做 RAG，寫信 23:40 看起來夠用了 23:42 但 multi-agent 還是有它存在的理由 23:44 主要原因是平行處理 23:46 有些事沒理由排隊跑 23:48 訂機票的時候，找航班，找飯店，查天氣 23:52 這三件事完全可以同時進行 23:54 如果只有一個 agent，就只能一件一件做 23:57 Multi-agent 就是把這幾件可以平行的事 23:59 拆給三個 specialized agent 同時跑 24:02 速度直接拉起來 24:04 次要原因是 reusability，也就是可復用性 24:07 公司裡的 design agent 可以給行銷團隊用 24:10 也可以給產品團隊用 24:12 不過，multi-agent 聽起來很厲害 24:15 但做產品的時候要先問自己真的有需要嗎？ 24:18 如果一個 agent 就能解決的任務 24:20 硬上 multi-agent 反而增加複雜度 24:23 所以還是老話一句，工程設計能簡單就簡單 24:26 不要 over design 24:27 教授用智慧家庭當 brainstorm 範例 24:30 一個完整的智慧家庭 multi-agent 系統可能有溫度控制 24:33 燈光，保全，娛樂，通知 24:36 還有能源管理這些 agent 24:37 加上一個 Orchestrator 統籌 24:39 互動模式有兩種 24:41 第一種是 Hierarchical 24:42 使用者只跟 orchestrator 講話 24:43 由它派工給下面的 agent，指揮鏈清楚 24:47 第二種是 Flat 24:48 agent 之間直接互通，沒有中間人 24:51 教授建議智慧家庭以 hierarchical 為主 24:54 因為從使用者的角度 24:55 你不想同時跟五個 agent 講話 24:57 你只想跟一個 assistant 說我要出門了 25:00 它就會自己去協調燈光，保全，溫控 25:03 但在後台，某些 agent 之間可以有彼此之間水平溝通的連線方式 25:09 比方說溫度控制的 agent 跟能源管理的 agent 直接互通 25:13 省掉每次都要過 orchestrator 的溝通成本 25:16 當你讓 agent 之間互相溝通 25:18 本質上就是 MCP protocol 25:20 你把 agent 當作 tool 25:21 就跟把 API 當作 tool 一樣 25:24 這個心態一旦想通，設計就清楚了 25:27 每個 agent 對外暴露一組 tool-like 介面 25:28 其他 agent 像呼叫工具一樣呼叫這個 agent 25:31 這樣子做結構乾淨，容易 debug 25:33 也支援平行處理 25:35 Multi-agent 聽起來複雜 25:36 但其實只是把你已經懂的東西，多疊一層 25:39 好，那我們最後整理一下這堂課的重點 25:42 這支影片我們從基礎模型的限制開始講起 25:45 並帶到能夠加強模型表現的技巧和技術 25:47 首先是 Prompt Engineering 25:49 強化 LLM 輸出，成本最低 25:51 重點放在 chaining 跟 testing 25:53 第二層是 Fine-Tuning 25:54 除非你在處理法律，科學那種需要重複高精度的 domain 25:58 或者興趣使然 25:59 否則別沒事找事去調模型 26:02 第三層是 RAG 26:03 幫模型補足知識的標準解法 26:06 做 AI 產品基本上一定會碰到 26:08 最後是 Agentic Workflow 26:10 從強化單一 LLM 進到系統設計 26:13 重點是思維上的心態轉變 26:15 從過往的 deterministic engineering 26:17 到現在的 fuzzy engineering 26:19 以及應對 fuzzy engineering 的 evaluation 系統 26:22 還有在實戰上要如何從拆解任務開始 26:25 打造自己的 agentic workflow 26:27 第五層是 Multi-Agent 26:28 把每個 agent 都當成工具 26:30 彼此協作來提升處理速度跟復用性 26:33 教授在兩個小時內跑完產業上常見的實作技巧 26:36 每個技術的存在理由跟適用情境都交代清楚 26:39 有了這樣的認知，你就不會盲目跟風 26:42 看到別人在做 multi-agent 就跟著做 26:44 看到別人講 fine-tuning 覺得很帥就去玩自己的模型 26:47 所以你的下一步是什麼？ 26:48 我給你的建議是，從實作中學習 26:51 看看你的生活上或者工作上有什麼痛點 26:54 從痛點出發去思考解決方法 26:56 在這個過程中你就會發現自己需要學會哪些技術 27:00 就能夠很有效率的去規劃自己的學習路線 27:03 我把這支影片整理成了一篇深度文章 27:05 附帶 4 組 prompts 27:06 幫你想清楚自己的 workflow 怎麼拆 27:08 現有架構有沒有 over-engineering 27:10 幫你建立 eval 系統 27:12 以及該不該上 multi-agent 27:13 有興趣的朋友可以在資訊欄找到連結 27:15 那今天這支影片差不多就講到這邊 27:17 如果你喜歡這樣的內容 27:19 想請你幫我點個讚 27:20 也在底下留言告訴我你們想看什麼樣的內容 27:22 那我們下次見

反向連結