從 LLM 到 Agent：打通底層邏輯
從 Token、Context、Prompt，到 Tool、MCP、Agent，完整梳理 AI 應用開發的核心概念與底層運作原理。
Gary
LLM 是什麼？
LLM（Large Language Model，大型語言模型）的核心能力只有一件事：預測下一個 token。
給定一段輸入文字，模型計算「下一個最可能出現的詞」，再把這個詞接到輸入後面，繼續預測下下一個，如此循環，直到產生完整回覆。
這個過程看似簡單，但在海量語料上訓練後，模型學會了語言規律、邏輯推理、知識記憶。GPT、Claude、Gemini，背後都是這套機制。
輸入：「台灣的首都是」
預測：「台」→「北」→「市」→「。」
輸出：「台北市。」
關鍵在於，LLM 沒有記憶，也不會主動做任何事。它只是一個函式：給輸入，回傳輸出。所有「智能」的外觀，都是在這個函式之上建構的。
Token：模型的基本單位
模型不是逐字元讀文字，而是把文字切成 token（語言片段）再處理。
"Hello, world!" → ["Hello", ",", " world", "!"] → 4 tokens
"你好世界" → ["你", "好", "世", "界"] → 4 tokens
"PostgreSQL" → ["Post", "gre", "SQL"] → 3 tokens
Token 的切分取決於模型使用的 tokenizer，不同語言的效率差很多。英文大約 1 個單字 = 1～2 tokens；中文則通常每個字就是 1 token。
Token 在工程上有兩個重要影響：
| 面向 | 影響 |
|---|---|
| 費用 | API 通常按 token 計費（輸入 + 輸出分開算） |
| 限制 | 每次呼叫有 context window 上限（例如 200K tokens） |
理解 token 讓你在設計 prompt 時更有感知，知道什麼樣的寫法會讓費用暴增。
Context：模型唯一能看見的東西
LLM 沒有記憶。每次呼叫，模型只能看到你這次傳進去的內容，稱為 context window。
Context 的內容通常包含：
System Prompt → 角色設定、行為規則
對話歷史 → 過去幾輪的 user / assistant 訊息
當前輸入 → 使用者這次說的話
工具回傳結果 → 如果有用到 tool，結果也會塞進來
「AI 記得你說過什麼」其實是應用層把歷史對話每次都一起送進去，不是模型真的記得。
Context window 的大小決定了模型能「記住」多長的對話。超過上限，最早的訊息就會被截掉。這是 AI 應用設計時最常踩的坑之一：對話太長導致模型「忘記」前面的指令或資料。
Prompt：和模型溝通的介面
Prompt 是你傳給模型的輸入。寫得好，模型表現好；寫得差，結果一塌糊塗。
System Prompt
定義模型的角色與行為邊界：
你是一個後端工程師助手，用繁體中文回答問題。
回答要簡潔，只給關鍵結論，不用解釋廢話。
如果不確定，就說不知道，不要亂猜。
Few-shot Prompting
提供幾個範例，讓模型學習你期望的輸出格式：
將以下錯誤訊息翻譯成繁體中文，格式如下：
原文：Connection refused
翻譯：連線被拒絕
原文：Timeout exceeded
翻譯：連線逾時
原文：Permission denied
翻譯：
Chain-of-Thought
要求模型逐步推理，再給出答案，對複雜問題準確率明顯提升：
請一步一步思考，然後給出結論。
Prompt 工程本質上是在告訴模型「你是誰、你要做什麼、你怎麼做」。越清楚，模型越可靠。
Tool：讓模型有手腳
LLM 本身只能輸出文字，無法執行任何操作。Tool（工具調用） 讓模型能呼叫外部函式，突破這個限制。
流程如下：
1. 你定義一組工具（函式簽名 + 描述）
2. 把工具定義連同 prompt 一起送給模型
3. 模型決定要呼叫哪個工具，輸出結構化的呼叫指令
4. 應用層執行這個函式，取得結果
5. 把結果塞回 context，模型繼續生成回覆
範例：定義一個查天氣的工具
{
"name": "get_weather",
"description": "查詢指定城市的目前天氣",
"parameters": {
"city": { "type": "string", "description": "城市名稱" }
}
}
模型收到「台北現在幾度？」，就會輸出：
{ "tool": "get_weather", "arguments": { "city": "台北" } }
應用層執行後把結果傳回去，模型再組合成自然語言回覆給用戶。
Tool 讓 LLM 從「只會說話」變成「說話 + 做事」。
MCP：Tool 的標準化協議
當你的系統有幾十個工具，每個都要自己寫定義、串接、維護，會很累。
MCP（Model Context Protocol） 是 Anthropic 提出的開放協議，定義了「模型如何和外部工具溝通」的標準格式，讓工具可以被任何支援 MCP 的模型複用。
LLM ←→ MCP Client ←→ MCP Server ←→ 資料庫 / API / 檔案系統
MCP Server 暴露三種能力：
| 類型 | 說明 | 範例 |
|---|---|---|
| Tools | 模型可以呼叫的函式 | 查資料庫、送 API |
| Resources | 模型可以讀取的資料 | 讀檔案、讀文件 |
| Prompts | 預設的 prompt 範本 | 分析報表的固定格式 |
有了 MCP，工具開發者只需要寫一次 MCP Server，任何相容的 AI 應用都能直接使用。類似 USB 統一了硬體接口的概念。
Agent：自主完成任務的執行者
把上面所有東西組合起來，就是 Agent。
Agent 的核心是一個循環（ReAct Loop）：
思考（Think）→ 行動（Act）→ 觀察結果（Observe）→ 再思考 → …
用戶：「幫我分析這週的銷售數據，找出異常。」
Agent 循環：
第 1 輪：呼叫 get_sales_data(week="this_week")
第 2 輪：讀取資料，呼叫 calculate_stats()
第 3 輪：發現週三數字異常低，呼叫 get_order_logs(date="週三")
第 4 輪：分析日誌，整理出結論
輸出：「週三下午 3 點系統有 2 小時停機，導致 47 筆訂單流失，影響營業額約 NT$12 萬。」
Agent 不需要人在每一步指示，它會自己決定下一步要做什麼，一直到任務完成。
與一般的「問答模型」最大的差別：
| 問答模型 | Agent | |
|---|---|---|
| 執行方式 | 一問一答 | 自主多步執行 |
| 工具使用 | 可以 | 可以，且自主決定何時用 |
| 任務長度 | 單輪 | 多輪，直到完成 |
| 需要人介入 | 每步都需要 | 只需給目標 |
Agent Skill：可組合的專業能力
隨著 Agent 的應用越來越複雜，出現了 Agent Skill 的概念：把某個專業領域的能力封裝成獨立模組，讓 Agent 可以像呼叫工具一樣呼叫「技能」。
主 Agent（協調者）
├── Skill: 資料分析 → 專門處理數據、統計、圖表
├── Skill: 程式碼生成 → 專門寫 / 審 / 解釋程式碼
├── Skill: 網路搜尋 → 專門搜尋、整理外部資訊
└── Skill: 報告撰寫 → 專門把結果整理成文件
Skill 和 Tool 的差別：
- Tool：一個具體的函式，做一件事（查天氣、送 email）
- Skill：一個包含 prompt + tools + 邏輯的完整能力模組（分析報表、產生程式碼）
Skill 讓複雜任務可以被分解、分工，不同 Skill 可以平行執行，最後由主 Agent 整合結果。這是目前 AI 應用走向「Multi-Agent 系統」的基礎架構。
總結
從 LLM 到 Agent，每一層都在解決上一層的限制：
| 層次 | 解決的問題 |
|---|---|
| LLM | 理解語言、推理、生成文字 |
| Token / Context | 理解模型的輸入邊界與費用結構 |
| Prompt | 讓模型的行為可預測、可控制 |
| Tool | 讓模型能操作外部系統 |
| MCP | 標準化工具協議，可重複使用 |
| Agent | 自主多步執行，完成複雜任務 |
| Agent Skill | 模組化能力，支撐 Multi-Agent 架構 |
理解這條鏈路，才能在實際開發 AI 應用時做出正確的架構決策：什麼情況下用單輪問答就夠了、什麼情況下需要 Agent、工具要怎麼設計、context 要怎麼管理。
LLM 只是起點，Agent 才是終點。