史丹佛 AI 系統課程精髓：從 LLM 核心限制到 Agentic Workflow 與 Multi-Agent 系統設計
2026/8/29 11:58:36 · 来源
#mcp#agentic-workflow#step-by-step#llm#rag#ai-engineering
本文梳理史丹佛大學 BLLM 課程精華，深入探討基座模型的四大限制、RAG 與微調的抉擇、Agentic Workflow 架構設計及 3D 評估矩陣的實際應用。
史丹佛 AI 系統課程精髓：從 LLM 核心限制到 Agentic Workflow 與 Multi-Agent 系統設計
本文將這堂兩小時的課堂精華整理成系統化的技術指南，幫助你建立 AI 商業應用的完整認知圖譜。
一、 Base Model 的四大天生缺陷：為什麼單靠升級模型不夠？
在開發 AI 產品時，模型能力提升可分為兩個維度 [01:00]：
-
橫軸（Horizontal Scaling）：升級更強的 Base Model（例如 GPT-4 升級至 GPT-5）。這是 OpenAI 或 Anthropic 等巨頭的戰場。
-
縱軸（Vertical Augmentation）：在現有 Base Model 之上疊加工程架構（Augmenting LLMs）。這是廣大 AI 工程師施展拳腳的核心戰場。
史丹佛教授指出，單純依賴 Base Model 在商業落地時必定會撞牆，原因在於 Base Model 存在四大天然限制 [01:47]：
-
缺乏領域知識（Domain Knowledge）：模型未曾訓練過企業內部的私有數據、產品規格或特定行業資料集 [01:52]。
-
資訊落後（Information Lag）：模型無法即時更新，對最新的事件、名詞或流行用語一無所知 [02:09]。
-
輸出隨機性（Probabilistic Output）：相同 Prompt 執行兩次可能得到不同解答。在退費或合約等生產環境中，這種不可控性是致命的 [02:19]。
-
長上下文退化（Lost in the Middle）：即便 Context Window 擴充至百萬 Token，將微小細節塞在龐大上下文文本的中段時，模型仍可能無法精準檢索 [02:43]。
二、 強化單一 LLM 的三大武器：Prompt、Fine-Tuning 與 RAG
在進入複雜系統設計前，強化單一 LLM 輸出的工具主要有三種：
```
┌─────────────────────────┐
│ Base LLM Model │
└────────────┬────────────┘
│
┌─────────────────────────────────┼─────────────────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ Prompt │ │ Fine-Tuning │ │ RAG │ │ Engineering │ │ │ │ Retrieval │ └────────┬────────┘ └────────┬────────┘ └────────┬────────┘ │ │ │ • Low cost & fast • Domain specific • Real-time data • Centaur vs Cyborg • Expensive & fragile • High accuracy • Prompt Chaining • Risk of overfitting • Vector search
### 1\. 提示詞工程（Prompt Engineering）\[[03:33](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D213)\]
Prompt Engineering 不是一門獨立職業，而是每位工程師必備的基本功 \[[03:37](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D217)\]。BCG 的實驗研究揭示了使用 AI 的重要現象 \[[03:57](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D237)\]：
- **Jagged Technological Frontier**：AI 並非萬能，某些任務顯著加分，某些任務反而扯後腿 \[[04:11](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D251)\]。
- **Falling Asleep at the Wheel**：盲目信任 AI 產出，結果可能比不用 AI 還差 \[[04:25](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D265)\]。
- **Centaur（半人馬模式） vs. Cyborg（生化人模式）** \[[04:44](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D284)\]：
- **Centaur（分工委派）**：一次性給予完整指令，讓 AI 獨立完成重複性高、流程明確的工作。
- **Cyborg（高頻人機協同）**：來回對話校正，適合需要創意與即時判斷的複雜任務。
> **最核心的技巧：Prompt Chaining** \[[05:54](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D354)\]
>
>
>
> 避免將複雜任務塞入單一黑色盒子 Prompt。將大任務拆解成多個獨立 Prompt，前一步的 Output 做為下一步的 Input。這不僅提升模型的精準度，更帶來了系統的**可觀察性（Observability）** \[[06:43](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D403)\]。
>
>
### 2\. 微調（Fine-Tuning）的工程陷阱 \[[06:48](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D408)\]
史丹佛教授的立場非常明確：**能不做 Fine-Tuning 就不做** \[[06:53](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D413)\]。
- **數據成本高**：需要大量高質量且已標註的數據 \[[06:57](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D417)\]。
- **過擬合風險（Overfitting）**：特定任務變強，卻失去通用推理能力的廣度 \[[07:08](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D428)\]。
- **時效性差**：花數月微調的模型，可能下個月就被新一代 Base Model 擊敗 \[[07:20](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D440)\]。
- **移植性低**：Prompt 可以跨模型復用，微調模型則無法移植 \[[07:31](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D451)\]。
### 3\. RAG（檢索增強生成）\[[08:02](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D482)\]
RAG 是解決外掛知識庫、即時性與消除幻覺的最佳解法 \[[08:21](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D501)\]。
- **運作機制**：將文本透過 Embedding 模型轉為向量存入 Vector Database。查詢時透過語意距離（Semantic Distance）檢索最相關段落，組合成帶有約束條件的 Prompt Template 送入 LLM \[[08:32](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D512)\]。
- **切塊策略（Chunking）**：除了固定大小切塊外，進階做法是保留文件、章節與段落的多層次結構（Hierarchy Chunking），提高命中率 \[[09:50](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D590)\]。
- **Context Window 變大後 RAG 是否失效？** 教授認為不會。RAG 具備**檢索效率（Latency）**與**即時更新**的優勢，不可能每次提問都將整個雲端硬碟重讀一遍 \[[10:21](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D621)\]。
## 三、 Agentic Workflow：架構思維的根本翻轉
當系統需求超出單一 LLM 能力時，便需進入 **Agentic Workflow** \[[11:07](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D667)\]。這個概念由吳恩達（Andrew Ng）提倡，意指將提示詞、外部工具與多個元件組合進有結構的工作流中 \[[11:24](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D684)\]。
### 傳統軟體工程 vs. Agentic AI 系統 \[[12:37](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D757)\]
**維度**
**傳統軟體工程 (Traditional Software)**
**Agentic AI 系統 (Agentic Software)**
**資料形態 (Data)**
結構化數據（JSON, SQL），邊界明確 \[[12:46](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D766)\]
非結構化文本、圖像、語音 \[[12:51](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D771)\]
**執行邏輯 (Logic)**
確定性 (Deterministic)，輸入相同輸出必相同 \[[12:56](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D776)\]
模糊/概率性 (Fuzzy)，受 Context 與隨機性影響 \[[13:00](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D780)\]
**架構心態 (Mindset)**
精確控制每一步執行路徑（Microservices）\[[13:19](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D799)\]
**Think like a manager**：給予目標與邊界，讓 AI 決定路徑 \[[13:28](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D808)\]
**測試機制 (Testing)**
確定性單元測試，結果可窮舉 \[[13:35](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D815)\]
迭代探索式，需依賴 LLM Evaluation \[[13:39](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D819)\]
> **落地黃金原則**：能用 Deterministic（確定性代碼）解決的步驟就用代碼解決，剩下來的 Fuzzy（模糊判斷）部分才交給 LLM，並建立 **Human-in-the-Loop（人工申訴/接管）** 機制補底 \[[13:50](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D830)\]。
>
>
## 四、 Agent 三大要素與自主性三層架構
打造一個 Agent 需要三個核心元件 \[[15:02](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D902)\]：
1. **Prompt**：定義角色、職責與邊界 \[[15:06](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D906)\]。
2. **Context Management**：包含 Working Memory（高頻快速對話歷史）與 Archival Memory（低頻長期記憶/RAG）\[[15:17](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D917)\]。
3. **Tools**：包含操作類工具（Booking, Payment API）與查詢類工具（CRM, DB Query）\[[15:54](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D954)\]。
```
┌─────────────────────────────┐
│ Agent Core System │
└──────────────┬──────────────┘
│
┌──────────────────────────────────┼──────────────────────────────────┐
│ │ │
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Prompt │ │ Context & Memory │ │ Tools & APIs │
│ (Role & Boundary)│ │(Working/Archival)│ │ (Actions/Search)│
└──────────────────┘ └──────────────────┘ └─────────┬────────┘
│
▼
┌──────────────────┐
│ MCP Protocol │
│ (Unified Socket) │
└──────────────────┘
Agent 的自主性三層分級 [16:10]
MCP (Model Context Protocol) 的突破 [17:02]
傳統開發需為每個 API 手寫適配邏輯。MCP 在中間放一層標準化協議，讓 Agent 只需與 MCP Server 溝通即可呼叫各類工具，就像通用插頭一樣，這也是 Multi-Agent 通訊的核心基礎 [17:15]。
五、 互動可視化：Agentic 系統架構模擬器
調整下方的架構參數，觀察單 Agent 與 Multi-Agent 系統在不同任務複雜度下的處理路徑與評估機制：
六、 生產級系統的命脈：3D Evaluation 評估矩陣
怎麼知道 Agent 真的可用？史丹佛提出的 3D Eval 評估矩陣 是生產環境的靈魂 [17:52]：
```
End-to-End
│
│ Objective
│ ╱
│ ╱
│ ╱
Quantitative ──────────┼────────── Qualitative ╱│ ╱ │ ╱ │ Subjective │ │ Component-based
1. **End-to-End vs. Component-based** \[[18:00](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1080)\]：
- End-to-End 看最終用戶滿意度；Component-based 拆解看每一微步（如 Extract Info, Call API）的正確率。兩者缺一不可 \[[18:17](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1097)\]。
2. **Objective vs. Subjective** \[[18:22](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1102)\]：
- 客觀指標用代碼/Script 自動驗證（如 Order ID 是否寫入 DB）；主觀指標（如語氣、同理心）需依賴人工或 **LLM-as-a-Judge** \[[18:46](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1126)\]。
3. **Quantitative vs. Qualitative** \[[18:49](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1129)\]：
- 定量（成功率、Latency）；定質（人工分析在哪一步產生幻覺或混淆）\[[18:55](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1135)\]。
### LLM-as-a-Judge 的四種主流玩法 \[[19:12](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1152)\]
- **Pairwise Comparison**：給予 A/B 兩個回答，讓 Judge 選出較佳者 \[[19:16](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1156)\]。
- **Single Answer Grading**：依標準直接打 1 至 5 分 \[[19:20](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1160)\]。
- **Reference-guided Pairwise**：提供 Standard Answer 做為對比基準 \[[19:24](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1164)\]。
- **Rubric-based Grading**：自訂詳細評分細則（例如包含 3 個重點得 5 分，答非所問得 0 分）\[[19:29](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1169)\]。
## 七、 實戰 Case Study：5 步打造客服 AI Agent
以「客戶請求修改訂單地址」為例，工程落地的三步法為：**任務拆解 $\\rightarrow$ 工作流設計 $\\rightarrow$ 建立評估系統** \[[20:48](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1248)\]。
┌──────────────────────────────────────────────────────────────────────────┐ │ Customer Service Agent Workflow │ └────────────────────────────────────┬─────────────────────────────────────┘ │ ┌────────────────────────────────┼────────────────────────────────┐ │ 1. Task Decomposition │ 2. Tool Mapping │ 3. Eval Check ▼ ▼ ▼ Step 1: Extract Intent & Info ──► LLM One-shot API ──► Objective Exact Match Step 2: Query DB Customer Rec ──► Custom Tool / MCP ──► Latency & Error Rate Step 3: Check Shipping Policy ──► RAG (Policy Vector DB) ──► Citation Verification Step 4: Draft Email Response ──► LLM (Rubric Prompt) ──► LLM-as-a-Judge Tone Step 5: Send Confirmation Mail ──► Action Email Tool ──► Human-in-the-Loop Check
1. **Task Decomposition（任務拆解）** \[[21:25](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1285)\]：
- 抽取關鍵資訊（Intent, Order ID, New Address）\[[21:38](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1298)\]。
- 查詢客戶紀錄 \[[21:46](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1306)\]。
- 查驗公司政策（如是否已出貨）\[[21:48](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1308)\]。
- 起草回信 \[[21:53](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1313)\]。
- 送出 Email \[[21:55](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1315)\]。
2. **Tool Allocation（工具匹配）** \[[22:02](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1322)\]：
- 抽資訊用 **LLM One-shot**；查 DB 用 **Custom Tool/MCP**；查政策用 **RAG**；送信用 **Action Tool** \[[22:05](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1325)\]。
3. **Build Evils（建立評估）** \[[22:46](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1366)\]：
- 客觀指標自動對驗 Order ID；主觀指標以 LLM-as-a-Judge 審查郵件禮貌度 \[[23:00](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1380)\]。
## 八、 Multi-Agent 多智能體系統架構
當單一 Agent 遇到瓶頸時，Multi-Agent 能帶來兩個優勢：**平行處理（Parallel Processing）**與**組件復用（Reusability）** \[[23:34](https://www.google.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DeKW9ITaltWw%26t%3D1414)\]。
```
Hierarchical Architecture Flat Architecture
┌─────────────────┐ ┌───────────────┐
│ Orchestrator │ │ Agent A │
└────────┬────────┘ └───────┬───────┘
│ │ (MCP)
┌─────────────┼─────────────┐ ▼
▼ ▼ ▼ ┌───────────────┐
┌──────────┐ ┌──────────┐ ┌──────────┐ │ Agent B │
│ Flight │ │ Hotel │ │ Policy │ └───────────────┘
│ Agent │ │ Agent │ │ Agent │
└──────────┘ └──────────┘ └──────────┘
警告：工程設計應秉持簡潔原則。單一 Agent 能搞定的任務，硬套 Multi-Agent 只會增加不必要的複雜度與 Latency [24:16]。
九、 總結：AI Builder 的學習與實踐路線
從單一 LLM 增強到架構化系統設計，關鍵的 5 個層級路線為 [25:39]：
從實際工作或生活中的真實痛點出發，逐步拆解任務並套用相應工具，才是高效成長的最佳捷徑 [26:48]。
学习地图
Stage 1: 基礎與單一模型強化
- Prompt Engineering 與 Prompt Chaining: 學習如何將複雜任務拆解為多個串聯的提示詞，提升模型輸出精度與系統可觀察性。
- RAG 檢索增強生成: 理解向量資料庫與語意檢索原理，解決模型資訊落後與領域知識不足的問題。
- 避免不必要的 Fine-Tuning: 掌握微調的工程成本與過擬合風險，了解何時該選擇外掛知識庫而非重新訓練。
Stage 2: Agentic Workflow 與系統架構
- Agent 三大要素: 掌握 Prompt、Context Management（Working/Archival Memory）與 Tools 的協同運作。
- 自主性三層分級: 了解從硬編碼步驟到自主工具調用的區別，並選擇最適合生產環境的 Level 2 架構。
- 混合架構設計: 學習將確定性程式碼與模糊 LLM 邏輯結合，並加入 Human-in-the-Loop 機制。
Stage 3: 生產級評估與多智能體系統
- 3D Evaluation 評估矩陣: 掌握端對端與組件級、客觀與主觀、定量與定質的綜合評估方法。
- LLM-as-a-Judge: 學習使用大模型作為裁判進行評分與 A/B 測試。
- Multi-Agent 系統設計: 透過分層主控（Hierarchical）或點對點（Flat）模式，結合 MCP 協議打造模組化多智能體系統。
动手实践——分步指南
- 規劃一個簡單的客戶服務任務，並將其拆解為多個依序執行的子步驟（如意圖識別、資料庫查詢、回覆草擬）。
- 編寫第一個 Prompt Chain，將前一個步驟輸出的內容作為下一個步驟的輸入，並透過日誌記錄每一步的執行狀態。
- 為 Agent 綁定基礎工具與簡單的外部 API（例如查詢訂單或發送通知），並設定允許 Agent 自主決定工具呼叫順序的權限。
- 建立一組客觀驗證腳本與主觀的 LLM-as-a-Judge 評分規則，對 Agent 的最終輸出進行自動化測試與評估。
三大推荐资源
- 1
- 2
- 3
链接由 AI 推荐——使用前建议快速核实。