// LLM Core Concepts · 培訓教學指南 · 2026-05-27

10 大 LLM
核心概念完全指南

從 Token 到 Agent、從 Prompt 到 RAG——系統化理解大型語言模型的基礎架構與應用技術。整合培訓簡報 × Claude × Gemini × GPT 三模型分析，以 Anthropic / OpenAI / Google 官方文件為基準，2026/05 版本。

LLM · Token Context · Prompt Tool · MCP Agent · Skill RAG · Cache
最後更新 2026-05-29
↗ NotebookLM
① 點 PDF 匯出檔案，或 Copy Link 複製網址　② 開 NotebookLM →「新增來源 → 網站」貼上，加入你的筆記本
// 目錄
  1. 10 大概念一眼看懂
  2. 模組 1–2：LLM 與 Token
  3. 模組 3–4：Context Window 與 Prompt
  4. 模組 5–6：Tool / Function Calling 與 MCP
  5. 模組 7–8：Agent 與 Skill
  6. 模組 9–10：RAG 與 Cache
  7. 跨概念比較矩陣
  8. 常見誤解與校正
  9. 端到端系統架構
  10. 工程決策樹
  11. 動手實作路徑
  12. 品管檢核表
  13. 參考資料
// 01

10 大概念一眼看懂

學習路徑由基礎到應用。先理解模型本質（LLM / Token），再掌握溝通介面（Context / Prompt），最後建構完整應用系統（Tool / MCP / Agent / Skill / RAG / Cache）。

🧠

① LLM
② Token

模型本質與最小計算單位

💬

③ Context
④ Prompt

工作記憶與溝通介面

🔧

⑤ Tool
⑥ MCP

能力擴充與標準化協定

🤖

⑦ Agent
⑧ Skill

自主推理迴圈與可重用模組

📚

⑨ RAG
⑩ Cache

外部知識接地與效能優化

Anthropic Docs OpenAI Developers Google AI for Developers modelcontextprotocol.io 學術論文
// 02

模組 1–2：LLM 與 Token

LLM 是基於 Token 序列的條件生成系統，不是資料庫，也不是穩定記憶體。

🧠

① LLM — 大型語言模型

TRANSFORMER · ATTENTION · RLHF
核心定義
以 Transformer 架構為基底，透過 Attention Mechanism（注意力機制）處理 Token 序列；訓練目標是預測下一個 Token（Next-Token Prediction）。Google Research Transformer 論文奠定此架構基礎[1]
能力來源
參數量 × 訓練資料品質 × RLHF（人類回饋強化學習）共同決定能力上限；規模帶來湧現能力（Emergent Capabilities）。Google Cloud 定義 LLM 為以大量資料訓練、可生成與轉換文字的統計語言模型[2]
2026 主流
Claude Opus 4.7 / Sonnet 4.6（Anthropic）、GPT-5 系列（OpenAI）、Gemini 3.5 Flash（Google）為當前旗艦；競爭焦點在長 Context 處理、Tool 呼叫精準度與推理能力
正確理解
LLM 應視為「條件式序列生成器」：輸入是 token 序列，輸出是下一段 token 序列。可靠產品通常還需要工具、檢索、狀態管理、權限與評測
💡

LLM 不是資料庫：訓練截止日後的知識它不知道；私有資料也不知道。這兩個場景正是 RAG 存在的原因。能力來自預訓練資料、模型規模、指令微調、RLHF 與推論時上下文——缺一不可。

🔡

② Token — 詞元

BPE · SUBWORD · COST UNIT
定義
LLM 處理文字的最小計算單位。OpenAI 官方說明 token 可能短至單一字元，也可能長至完整單字；英文常見約 1 token ≈ 4 個字元，但不同語言與 tokenizer 有差異[3]
中英差異
中文每字約 1–2 Token；英文平均約 4 字元 / Token。注意：此為入門估算，精確計費應用 tokenizer 或 API usage metadata
成本影響
API 通常依 input tokens、output tokens、cached tokens、reasoning tokens 分別計價。Claude Sonnet 4.6：輸入 $3 / MTok、輸出 $15 / MTok；快取讀取 $0.30 / MTok（Anthropic 官方）
工程面向
輸入越長，prefill 成本越高；輸出越長，decode 時間越長。RAG chunk size 與 top-k 直接消耗 token budget；靜態內容前置以利 prompt caching
從文字到 Token 預測的流程
① INPUT

輸入文字

原始自然語言

② TOKENIZE

詞元化

BPE / SentencePiece 切分

③ TRANSFORM

模型處理

Attention 建模脈絡

④ PREDICT

預測下一 Token

機率分佈取樣

🔬

Tokenizer 仍在演進：BPE / Unigram 屬貪婪演算法；2026 年的 ConvexTok（arXiv:2605.22821） 改用凸優化建構詞彙表，改善 bits-per-byte 等指標——可逐步提升 embedding 與檢索效能，但下游任務增益不一致、非革命性，現有 tokenizer 與 RAG 架構仍為主流。

// 03

模組 3–4：Context Window 與 Prompt

Context Window 是模型的工作記憶；Prompt 是與模型溝通的主要控制面。兩者品質決定 80% 的輸出品質。

📋

③ Context Window — 上下文視窗

WORKING MEMORY · 1M TOKEN · LOST-IN-MIDDLE
組成（5 層）
① System Prompt（角色/規則/目標）→ ② 對話歷史（先前輪次）→ ③ 檢索內容（RAG 注入）→ ④ Tool 結果（工具回傳）→ ⑤ 用戶訊息（本輪指令）
2026 上限
Claude Opus 4.7 / Sonnet 4.6：1M Token；Claude Haiku 4.5：200K；GPT-5 系列：128K–400K；Gemini 3.5 Flash：1M+（Anthropic 官方模型頁面，2026/05）
中段遺忘
Lost-in-the-Middle 效應：關鍵資訊置於長 Context 中段，模型召回率顯著下降。MIT TACL 研究證實此現象[4]。NVIDIA RULER 測試顯示有效 Context ≈ 廣告容量的 50–65%
管理策略
重要規則放前段、最新問題與關鍵結論放後段；長文件應用 RAG + 摘要 + 分段引用，不要全部塞入；多輪任務建立狀態摘要，不無限保留對話
工程原則
Context Window 是單次推論可見內容，不是模型持久化記憶。OpenAI 說明超過上限時需縮短、拆分、摘要或前處理輸入[3]
⚠️

1M Token ≠ 1M Token 有效：Claude Opus 4.6 在 1M token 下 MRCR v2 得分 76%，代表「質性飛躍」但仍非 100%。重要資訊應放 Context 兩端（開頭 + 結尾），避免中段。

💬

④ Prompt — 提示詞

SYSTEM · FEW-SHOT · OUTPUT FORMAT
標準結構
角色規則（Role & Rules）→ Few-shot 範例 → User Turn（用戶指令）→ 輸出格式約束。OpenAI 建議用 Markdown 或 XML 標籤界定邏輯邊界[5]
四個條件
明確（具體指令比模糊有效）/ 可測（有可驗證完成標準）/ 可分層（系統規則/任務資料/範例/用戶需求分離）/ 可維護（長流程抽成 Skill，不塞進單一 prompt）
System Prompt
定義角色、規則、限制與目標；在 API 中以 system 參數傳入；應放穩定的「永遠開啟」規則，並前置以利快取命中
Few-shot
提供 input/output 示範對，引導模型格式與邏輯。2026 新世代模型已降低對 Few-shot 的依賴，但複雜格式任務仍有效

✓ 高效 Prompt

  • 「以 JSON 格式輸出，含 name / score / reason 欄位」
  • 「步驟不超過 5 條，每條一句話」
  • 「不確定時說『無法確認』，不要猜測」
  • 「若資訊不足，列出缺口」

✗ 低效 Prompt

  • 「請盡量優化這段程式」（模糊，無可驗證標準）
  • 「Be smart and helpful」（人格描述非行為規則）
  • 「保持簡潔」（無具體長度限制）
  • 「你是專家，請幫我處理」（無任務邊界）
// 04

模組 5–6：Tool / Function Calling 與 MCP

Tool 讓模型能呼叫外部函式；MCP 將此機制標準化為開放協定。兩者層次不同：Tool 是呼叫機制，MCP 是連接協定。

🔧

⑤ Tool / Function Calling — 工具呼叫

JSON SCHEMA · TOOL_USE · PARALLEL CALLS
定義
Tool 是具型別定義的函式 Schema（結構描述）。模型不執行函式——輸出結構化 tool_use 指令，由宿主系統執行後以 tool_result 回傳。OpenAI / Google Vertex AI / Anthropic 三家官方均採此架構[6]
標準流程
User 提問 → LLM 輸出 tool_use → 宿主執行函式 → tool_result 回傳 Context → LLM 整合生成最終回覆
Parallel 呼叫
模型可在同一輪輸出多個 tool_calls；Response 有陣列結構，最佳實踐是預設處理多個呼叫（OpenAI 官方[6]）
典型應用
網路搜尋、資料庫查詢、程式執行、第三方 API 呼叫、計算機、日曆操作、寄送郵件
工具設計五原則
原則說明
單一職責一個工具只做一類動作，避免職責重疊
Schema 嚴格參數型別、required 欄位、enum 應清楚定義；無效狀態不可表示
描述可判斷工具描述必須讓模型知道「何時使用」——通過「實習生測試」（intern test）[6]
結果可回填tool_result 應簡潔、結構化、可被模型引用；失敗時回傳錯誤說明而非靜默
安全可審核寫入、刪除、付款、寄信等高風險動作需權限確認
User 請求
→
LLM 決策 tool_use
→
宿主執行函式
→
tool_result 回傳
→
LLM 整合 → Final Answer
🔗

⑥ MCP — 模型上下文協定

OPEN STANDARD · TOOLS / RESOURCES / PROMPTS
定義
Model Context Protocol（MCP）是連接 LLM 宿主與 Tool 伺服器的開放標準，由 Anthropic 於 2024/11 發布；官方規格定義為可讓 LLM 應用與外部資料源、工具無縫整合的開放協定[7]，現已移交 Agentic AI Foundation 治理
三大 Primitive
Tools（行動）：可執行的行動與功能（有副作用）／Resources（資料）：結構化或非結構化靜態上下文資料庫／Prompts（範本）：提示詞範本與最佳實踐
傳輸方式
stdio（本機低延遲）/ SSE + HTTP（遠端跨網路）。最新 2026-07-28 RC：增加無狀態核心 + Tasks 擴充 + MCP Apps（伺服器端渲染 UI）+ OAuth 對齊[8]
採用狀況
6 個月內 9,700 萬次安裝；OpenAI 與 Google DeepMind 已採用；官方 Registry 上線；支援 10+ 語言 SDK（TypeScript / Python / Go / Rust / Java / PHP 等）
核心價值
解決 N×M 整合問題：以前每個模型對每個工具需客製化連接器；MCP 讓「一次整合，多個相容宿主重用」
Tool Calling vs MCP — 層次差異
項目Tool / Function CallingMCP
層級單一模型請求中的工具呼叫機制Host、Client、Server 的標準傳輸協定
重點函式 schema 與呼叫結果工具、資源、提示範本、連線與能力協商
適用場景單一 app 綁定少數工具多工具、多資料源、多 AI host 的企業整合
主要風險錯誤參數、危險動作權限管理、資料外洩、工具注入、跨系統信任
🎯

MCP ≠ RAG，MCP ≠ Agent：MCP 是讓 Agent 或 LLM Host 以標準方式連到工具與資料源的協定層。Tool Calling 是模型呼叫工具的互動機制；MCP 定義此互動的傳輸與結構規範。

// 05

模組 7–8：Agent 與 Skill

Agent 讓 LLM 在迴圈中自主多步驟推理；Skill 讓 Agent 行為可重用、可版本控制。兩者合力使 LLM 從「問答工具」升級為「自主工作系統」。

🤖

⑦ Agent — 智能代理

ReAct · PLAN-ACT-OBSERVE · AGENTIC LOOP
定義
Agent = LLM 在有狀態的自主控制迴圈中運作。OpenAI Agents SDK 定義為：會 plan（規劃）、call tools（呼叫工具）、collaborate（協作）並保留足夠 state 完成多步驟工作的應用[9]
經典模式
ReAct（Reasoning + Acting）：推理與行動交織進行；持續執行 Plan → Act（Tool calls）→ Observe → Re-plan，直到達成目標
關鍵特性
目標持續性（Goal Persistence）、工具使用能力、動態狀態管理
常見風險
無限迴圈（Infinite Loops）、幻覺式工具呼叫（呼叫不存在工具或用錯誤參數）、Context 耗盡（長任務超出視窗）
工程化 Agent 必備控制項
控制項目的
終止條件防止無限迴圈；目標達成或錯誤累積超閾值即停止
最大步數 / 成本控制 token、API、工具呼叫費用上限
狀態摘要避免 Context 無限膨脹；定期壓縮已完成步驟
工具權限破壞性操作（刪除 / 推送 / 付款 / 寄信）需人工確認
可觀測性記錄每步 plan、tool call、result、error；用於 debug 與審計
評測任務成功率、回歸測試、人工審核衡量
Plan 規劃
→
Act（Tool calls）
→
Observe 觀察
→
Re-plan
→ 達成目標 / 終止條件
🧩

⑧ Skill — 技能單元

REUSABLE · VERSIONED · SKILL.MD
定義
Skill 是具名稱與版本的打包單元，讓 Agent 能重用專家行為，而不必部署獨立模型。OpenAI Codex / Claude Code 均採 SKILL.md 規格[10]
打包內容
System Prompt（系統提示）+ Tools（工具清單）+ Few-shot Examples（範例）+ Evaluation（評測標準）
載入機制
Progressive Disclosure：agent 先讀名稱與描述，必要時才載入完整 SKILL.md（節省 Context）。已被 Claude Code / Codex CLI / Antigravity / Cursor / GitHub Copilot 共同採用
觸發條件
同一任務出現 3 次以上；任務有固定流程（PR review、RAG ingest、資料清洗）；需附帶範例、腳本或評測標準
設計原則
單一能力、可版本控制、可測試、可組合。Skill 儲存為 SKILL.md 檔案，或 MCP Resource 進行分發
💡

Skill vs Tool：Tool 是模型呼叫的函式（程式碼執行）；Skill 是封裝了 Prompt + Tool + 示範的行為模組（知識與流程包裝）。一個 Skill 通常會使用多個 Tools。

// 06

模組 9–10：RAG 與 Cache

RAG 解決「模型不知道私有 / 新知識」問題；Cache 解決「重複計算」效能問題。兩者是生產環境的必備機制。

🔍

⑨ RAG — 檢索增強生成

CHUNK · EMBED · VECTOR DB · RE-RANK
定義
結合模型內部參數記憶與外部非參數記憶（dense vector index），以改善知識密集任務。RAG 論文（Lewis et al., 2020）奠定此架構[11]；Google Vertex AI RAG Engine 定義為協助檢索並提供相關上下文的系統[12]
標準流程
資料來源 → Chunk（分塊）→ Embed（向量嵌入）→ 向量資料庫 → Query（查詢）→ Re-rank（重排）→ 注入 Context → Generate（生成）
品質關鍵
2026 業界研究：RAG 失敗 73% 發生在 Retrieval 階段，非 Generation。Naive RAG（只有向量搜尋）已不足；Hybrid Search + Contextual Chunking 是現在最低標準。Anthropic 研究：混合搜尋減少 49% 檢索失敗率
主要用途
私有知識接入（企業文件 / 內部規範）/ 知識更新（不必重訓模型）/ 降低幻覺（依據外部文件）/ 可追溯（回答附 citation）/ 成本控制（只送相關片段）
常見工具
向量 DB：pgvector、Pinecone、Weaviate；嵌入模型：OpenAI text-embedding-3-large、Cohere embed-v3；框架：LlamaIndex、LangChain
RAG 品質 7 大關鍵（GPT 報告）
#關鍵因素說明
1Chunk 策略依語意 / 段落 / 標題 / 表格結構切分；避免語意截斷
2Embedding 模型直接影響語意召回品質；多語言場景選多語言模型
3Metadata保留來源、日期、權限、章節；支援過濾與存取控制
4Hybrid Retrieval向量搜尋 + BM25 詞彙搜尋並行；比單一向量搜尋更穩
5Re-rank處理 top-k 召回過寬問題；二次校準關聯度
6Citation輸出需回指來源；不能只給生成結論
7權限過濾不同用戶只能檢索有權讀取的資料
資料來源
→
Chunk 分塊
→
Embed 向量化
→
向量資料庫
→
Hybrid Search + Re-rank
→
注入 Context → LLM
⚡

⑩ Cache — 快取

KV CACHE · PROMPT CACHING · 4 LAYERS
KV Cache
在 Transformer 推理過程中，將先前 Token 的 Attention Key / Value 矩陣計算結果暫存，避免重複運算；大幅縮短後續 Token 生成的 Prefill 與解碼延遲。屬模型推論內部機制，開發者通常不需直接操作
Prompt Caching
對重複利用的穩定前綴（System Prompt / 工具描述 / 大型文件）進行快取。設計法則：穩定內容置頂，動態內容置底
成本對比
Anthropic：讀取 ×0.10（節省 90%），寫入 ×1.25；OpenAI：自動快取，讀取 ×0.50；Google Gemini：寫入免費但有每小時儲存費（$4.50/MTok/h）[13]
快取四層架構（GPT 報告）
KV Cache（模型層）
  • 所在：模型推論內部
  • 作用：重用 Attention K/V 計算
  • 改善自回歸生成效率
  • 開發者無需設定
Prompt Cache（API 層）
  • 所在：API / 平台層
  • 作用：重複 prompt prefix 降成本
  • Anthropic 需 cache_control 標記
  • OpenAI 自動啟動（≥1024 tokens）
RAG Cache（應用層）
  • 所在：應用程式層
  • 作用：快取查詢結果
  • 含 embedding / rerank 結果
  • 避免重複向量計算
Tool Cache（應用層）
  • 所在：應用程式層
  • 作用：快取外部 API 查詢
  • 含資料庫查詢結果
  • 設定 TTL 防資料過舊
🎯

設計法則：穩定在前，動態在後。System Prompt、工具描述、大型參考文件前置並標記快取；用戶訊息和每輪變動內容放最後。首次請求付快取寫入費，後續讀取節省 50–90%。

// 07

跨概念比較矩陣

釐清容易混淆的概念邊界，以及各概念的工程首要指標。

概念🧠 一句話定義🔧 主要工具📊 工程首要指標
LLM基於 Token 的機率引擎Claude / GPT / GeminiBenchmark 分數、模型版本
Token計費與運算的最小單位Tokenizer（BPE）Token 消耗量、成本
Context單次呼叫的工作記憶Context Engineering視窗利用率、Lost-in-Middle 風險
Prompt與模型溝通的主要控制面Prompt 範本、Few-shot輸出品質、格式遵循率
Tool模型可呼叫的函式JSON Schema 定義工具選擇準確率、執行成功率
MCP標準化的工具連接協定MCP Server / SDK伺服器可靠性、協定版本相容
Agent目標導向的執行迴圈ReAct / Plan-Act-Observe任務完成率、迴圈次數、可觀測性
Skill可重用的行為打包單元SKILL.md觸發準確率、可重用次數
RAG有依據的知識檢索pgvector / Pinecone / LangChainRetrieval 準確率、Answer Faithfulness
Cache成本與延遲最佳化機制Prompt Caching APICache Hit Rate、成本降幅
容易混淆🧠 LLM 層🔧 擴充層📚 知識層
核心角色LLM / Token / Context / PromptTool / MCP / Agent / SkillRAG / Cache
執行位置模型內部（推理時）宿主系統 / Agent 迴圈外部資料庫 + 快取層
易混淆點Context ≠ Memory（前者是單次；後者是跨 session 記憶機制）Tool ≠ MCP（能力 vs 協定）Agent ≠ Chatbot（有迴圈與工具）RAG ≠ Fine-tuning（inference 注入 vs 更新模型權重）Cache ≠ RAG（快取計算 vs 檢索知識）
// 08

常見誤解與校正

整合三模型報告中共同指出的高頻誤解，是教學重點也是工程防雷點。

誤解正確認知
LLM 會「記得」所有對話模型只能看到當次 Context；長期記憶需另建 memory store 或資料庫。Context Window 是工作記憶，不是持久化記憶
Context 越長越好長 Context 成本高，且 Lost-in-the-Middle 效應使中段資訊使用不穩；有效 Context ≈ 廣告容量 50–65%
Prompt 可以解決所有問題需要工具、RAG、權限、評測與工作流；Prompt 是控制面，不是萬能膠
Tool 只要提供 API 就好Tool schema、描述、權限、結果格式都會影響模型是否正確選擇與使用工具
MCP 等於 Tool CallingMCP 是協定層（傳輸 / 結構 / 能力協商）；Tool Calling 是模型呼叫工具的互動機制。Tool Calling 透過 MCP 標準化
Agent 越自主越好Agent 必須有終止條件、成本上限、Observability 與人工審核點；無限自主是生產環境風險
RAG 可以完全消除幻覺RAG 只能降低風險，還需高品質 Retrieval（Hybrid Search）、Re-rank 與答案約束（不得編造）
1M Token 視窗讓 RAG 過時知識庫 > 1M tokens 仍需 RAG；1M 視窗適合「一次性」載入單一大型文件分析，無法取代大型知識庫的管理
Cache 只影響速度Cache 同時影響延遲、成本與系統架構；但設計不當（TTL 過長）可能導致語義結果不一致
中文 Token ≈ 1 字 / Token此為入門估算，精確計費應用 tokenizer 或 API usage metadata；不同模型 tokenizer 有差異
// 09

端到端系統架構

現代工業級 LLM 應用的完整執行路徑（依簡報模組 10 + 三模型報告整合）。四個層次各司其職。

🏗

完整系統層次圖（端到端路徑）

USER → CACHE · 8 LAYERS
1

User（使用者）

發出請求或問題

2

Agent（智能代理）—— 規劃迴圈

接收請求，啟動 Plan → Act → Observe → Re-plan 迴圈；決定需要哪些 Skill 與工具

3

Skills（技能單元）

根據任務類型載入對應 Skill（Prompt + Tools + Examples）；Progressive Disclosure 節省 Context

4

MCP / Tools（協定 / 工具）

透過 MCP 標準協定呼叫外部服務：MCP Server、資料庫 API、第三方工具；tool_result 回傳模型

5

RAG（檢索增強生成）

從向量資料庫 / 知識庫 Hybrid Search，Re-rank 後注入 Context 作為生成依據

6

Prompt / Context Window（提示詞 / 上下文）

組合 System Prompt、對話歷史、RAG 結果、Tool 輸出；靜態前綴快取，動態部分即時處理

7

Cache 層（KV Cache + Prompt Cache）

KV Cache 避免 Attention 重複計算；Prompt Cache 對穩定前綴降成本 50–90%

8

LLM（大型語言模型）

接收完整 Context，推理生成最終回覆；Token by Token 輸出

四層架構職責（GPT 報告）
層次元件主要責任
推論核心LLM、Token、Context生成、理解、推理、上下文使用
控制介面Prompt、Skill行為規範、任務模板、重用流程
外部能力Tool、MCP、RAG查資料、執行動作、連接系統
運維最佳化Cache、Observability、Eval成本、延遲、可觀測性、品質驗證
⚖️

核心三角權衡（Gemini 報告）：延遲 × 能力 × 成本——多步驟 Agent 推理 / 複雜 RAG 多重檢索會拉長延遲；引入越多工具與規劃能力越強但成本越高；Cache 可同時降低延遲與成本但需管理失效機制。工程師的工作是在三者間找到最佳點。

// 10

工程決策樹

根據具體需求選擇應加入哪些 LLM 組件。

🌿 根據需求情境選擇組件

需回答訓練截止日後的新知識
→
RAG（向量檢索 + Context 注入）
需查詢私有資料（企業文件 / 內部資料庫）
→
RAG + 向量資料庫 / Tool 連接私有 API
需操作外部系統（搜尋 / 計算 / API）
→
Tool / Function Calling + MCP
需多步驟自主執行、跨工具協調
→
Agent（ReAct 迴圈 + 終止條件）
需整合多個外部工具且可重用
→
MCP Server（標準化工具暴露）
相同流程重複執行 3 次以上
→
建立 Skill（打包 Prompt + Tools + 示範）
System Prompt / 文件每次都要重複傳入
→
Prompt Caching（穩定內容前置快取）
輸出品質不穩定、格式不一致
→
優化 Prompt（具體規則 + 輸出格式約束）
Context 視窗快滿 / 成本過高
→
Context Engineering（壓縮 / 截斷 / Sliding Window）+ Cache
需要回答有可追溯來源的問題
→
RAG + Citation 機制（回答附出處）
// 11

動手實作路徑

簡報建議實作任務：2 小時內建置一個最小化 RAG + Tool Agent（GPT 報告詳細拆解）。

PATH A — 基礎層（Week 1–2）
  1. 呼叫 API，送出第一個請求
  2. 理解 Token 消耗與成本計算
  3. 設計 System Prompt（角色 + 規則 + 格式）
  4. 測試 Few-shot 對輸出品質的影響
  5. 練習 Context 管理（截斷 / 壓縮）
PATH B — 工具層（Week 3–4）
  1. 實作第一個 Tool（天氣 / 搜尋 API）
  2. 處理完整 tool_use → tool_result 流程
  3. 設置本機 MCP Server（stdio 傳輸）
  4. 建立 Agent 迴圈（ReAct + 終止條件）
  5. 啟用 Prompt Caching 降低 API 成本
PATH C — 知識層（Week 5–6）
  1. 建立文件 Pipeline（Chunk → Embed → DB）
  2. 實作 Hybrid Search（向量 + BM25）
  3. 加入 Re-rank 提升檢索精準度
  4. 整合 RAG 到 Agent 迴圈
  5. 用 RAGAS 框架評估 RAG 品質
2 小時最小化 RAG + Tool Agent 任務拆解（GPT 報告）
時間任務產出
0–20 min準備 5–10 份文件（Markdown / PDF / txt）原始語料庫
20–45 minChunk + Embedding + Vector Store可查詢向量索引
45–70 min建立 RAG 查詢流程（query → retrieve → rerank → answer）可回答文件問題
70–90 min加入一個 Tool（訂單狀態 / 天氣 / 庫存查詢）Tool 呼叫閉環
90–110 min包成 Agent loop（plan → tool/RAG → observe → answer）自主多步驟 Agent
110–120 min加入評測（5 題 golden questions + expected citations）可量化品質基準
✅

驗收標準：回答必須引用檢索來源 / 找不到答案時明確說「資料不足」/ 工具呼叫參數符合 schema / 每次回答記錄 retrieved chunks + tool call + final answer / 至少通過 5 題測試問題。

// 12

品管檢核表

建構或審查 LLM 系統時，用以下標準逐項確認。（GPT 報告 §7）

檢查項合格標準
Token 管理有估算 input / output / cached tokens；API 費用在預算範圍內
Context 結構系統規則、檢索資料、工具結果、使用者問題分層；關鍵資訊置於 Context 兩端
Prompt 可測性有明確輸出格式與失敗處理（找不到 → 說「無法確認」）；禁止事項有明確規則
Tool 安全寫入 / 刪除 / 付費類工具需人工確認；錯誤時回傳說明而非靜默
MCP 安全Server 權限、資料來源、工具描述已審核；跨系統信任已評估
Agent 控制有最大步數、終止條件、成本上限；破壞性操作有 checkpoint
RAG 品質有 Chunk 策略、Metadata、Hybrid Search、Re-rank、Citation；答案有來源可追溯
Cache 策略靜態內容前置；重複資料已設定快取；KV Cache TTL 不過長
可觀測性記錄 prompt / retrieval / tool call / latency / cost；可 debug 與審計
評測有 golden question set、錯誤分類、回歸測試；RAG 用 RAGAS 量化
// 13

參考資料

本指南以下列官方文件與學術論文為主要依據，所有連結以 2026/05/27 為基準日。

Anthropic Docs × 4 OpenAI Developers × 6 Google Cloud / AI × 3 modelcontextprotocol.io × 3 學術論文 × 2
10 大 LLM 核心概念教學指南 v2.0 · 2026-05-27 · Claude × Gemini × GPT 三模型整合 docs.anthropic.com →
關於 · 編輯原則與方法論