AI 名詞太多記不住？從 LLM 到 Agent Skill，八個概念一次講到你懂

🗼 先看整張圖：八個概念是一座塔

LLM、Token、Context、Prompt、Tool、MCP、Agent、Agent Skill —— 這些詞你大概都聽過，但要一個一個「準確說出它是什麼」，多數人會卡住。這支 32 分鐘的教學影片做了一件很體貼的事：不談商業願景，從最底層的工程視角，把八個概念一層一層往上疊。疊到最上層你會發現，市面上的 AI 產品 —— 不管叫什麼名字 —— 本質上都在同一個框架裡運作。

🔁 LLM —— 說穿了是文字接龍

LLM 的全名是 Large Language Model，大語言模型。現在的大語言模型幾乎都建立在 Transformer 這套架構上 —— 它是 Google 團隊在 2017 年的論文〈Attention Is All You Need〉提出來的。戲劇性的是，火種是 Google 發明的，把它點燃引爆全世界的卻是 OpenAI：2022 年底的 GPT-3.5 是第一個「真正達到可用等級」的模型，幾個月後的 GPT-4 又把天花板拉高一截。

那模型是怎麼「想」出答案的？講者的說法非常樸素：它本質上是一個文字接龍遊戲。你輸入「馬克的影片怎麼樣」，模型預測出下一個機率最高的詞 ——「特別」。關鍵來了：它不會停下來，而是把剛吐出來的「特別」接回你的輸入後面，拿這串更長的字再預測下一個詞（「得」），再接回去，再預測（「棒」）……直到它判斷話說完了，輸出一個特殊的結束標記，整個回答才結束。

🔢 Token —— 模型眼裡沒有「字」，只有編號

上一節說模型在「接詞」，其實還簡化了一層。大語言模型本體是一個巨大的數學函式，裡面跑的全是矩陣運算 —— 它收的是數字、吐的也是數字，根本不認識人類的文字。所以中間需要一個翻譯，叫做 Tokenizer：把文字切成一小段一小段（每段叫一個 Token），再把每個 Token 對應到一個編號（Token ID）送進模型；模型吐出編號，Tokenizer 再翻回文字。

最容易誤會的一點：Token 不等於「詞」，也不等於「字」。切法是模型自己從大量文字中學出來的一套規則，切出來的每一塊，就是它一次能處理的最小單位。影片用 OpenAI 的切分工具實測了幾個例子：

🧠 Context —— 它不是記得你，是每次都重看一遍

你跟 AI 說「我叫馬克」，過幾句再問「我叫什麼」，它答得出來 —— 看起來像有記憶。但模型只是個函式：給輸入、得輸出，它並不真的記得任何事。那它怎麼「記住」的？答案很不浪漫：你每次送出訊息時，背後的程式會自動把之前的整段對話歷史一起打包送過去。模型每一次都是把完整對話從頭看一遍，所以才知道之前發生了什麼。

這個「模型每次處理任務時收到的資訊總和」，就叫 Context（上下文）—— 裡面有你的問題、對話歷史、模型正在輸出的每個 Token，還有等一下會講到的工具清單與 System Prompt。你可以把它看成模型的臨時記憶體。而它能塞多少 Token，上限就叫 Context Window（上下文窗口）。

影片提到，主流模型的 Context Window 已經來到百萬 Token 等級 —— 依前面的換算約 150 萬個漢字，整套《哈利波特》都裝得下。不過窗口大不等於萬能：文件一長、成本跟著漲，模型在超長內容裡也可能抓不準重點，所以才會有 RAG 這類「只把最相關的幾段餵給模型」的技術 —— 這條線在系列第二篇會展開。

💬 Prompt —— User 是你說的，System 是老闆定的

Prompt（提示詞）沒有那麼玄，它就是你給模型的問題或指令。「幫我寫一首詩」是 Prompt；但這句太模糊，模型可能給你古詩、現代詩或打油詩。改成「請幫我寫一首五言絕句，主題是秋天的落葉，風格悲涼一點」，輸出立刻貼近你要的 —— 把話說清楚、說具體，就是所謂的提示詞工程。

實務上 Prompt 分成兩種，各管各的事：

🔧 Tool —— 模型只會「開口要」，動手的是平台

問模型「今天上海的天氣怎麼樣」，它只能道歉：我的知識有截止日期，拿不到即時資料。因為文字接龍再會接，也接不出它沒看過的資訊。解法是給它 Tool（工具）—— 說穿了就是一個函式：輸入城市和日期，它去查氣象資料，回傳天氣。

這裡有一個初學者幾乎都會誤會的重點：模型自己不能呼叫工具。它唯一的能力是輸出文字。整個流程其實有四個角色 —— 使用者、模型、工具，以及中間跑腿的平台（一段負責上傳下達的程式）：

🔌 MCP —— 工具界的 Type-C

工具流程有個工程上的麻煩：平台要能把工具清單交給模型、也要能替模型呼叫工具，前提是工具得先「接」進平台 —— 而每家的接法不一樣。同一個天氣工具，接 ChatGPT 要照 OpenAI 的規範寫一套、接 Claude 要照 Anthropic 的再寫一套、接 Gemini 又一套。同一個工具寫三遍，這誰受得了。

MCP（Model Context Protocol，模型上下文協議）就是為此而生的統一接入標準。工具開發者照 MCP 規範寫一次，所有支援 MCP 的平台都能用 —— 就像手機充電孔統一成 Type-C，轉接頭全部丟掉。名字聽起來很學術，記住「工具界的統一插頭」就夠了。

🤖 Agent 與 Agent Skill —— 會自己規劃，還帶著你的 SOP

從「呼叫一次工具」到 Agent

單次的工具呼叫還稱不上 Agent。影片舉的例子是：「我這裡天氣怎樣？如果下雨，幫我查附近哪裡有賣傘。」這個問題模型得一步一步想：先呼叫定位工具拿經緯度 → 拿經緯度呼叫天氣工具 → 發現下雨 → 再呼叫店鋪工具搜「雨傘」→ 綜合所有資訊給答案。能像這樣自主規劃、連續呼叫工具、直到把使用者的任務做完的系統，就叫 Agent。市面上流行的 Claude Code、Codex、Gemini CLI，都是這種東西。

Agent Skill：你寫給 Agent 的 SOP

Agent 會查天氣了，但它不知道你的私人規則：下雨帶傘、光照強帶帽子、空氣差帶口罩、手機無論如何必帶，而且回答要先一句總結、再列清單。每次提問都把這串規則重打一遍？太反人類。Agent Skill 就是把這些規則提前寫好、存成一份說明文件交給 Agent —— 本質上就是一個 Markdown 檔，分兩層：

• 元資料層（封面）：至少要有 Name（技能名稱，例如 go-out-checklist）與 Description（它負責做什麼）。
• 指令層（內文）：目標、執行步驟、判斷規則、輸出格式、示例 —— 格式不拘，把事情向 Agent 說明白就行。

以 Claude Code 為例，存放有兩條硬規定：在 ~/.claude/skills/ 底下開一個與技能同名的資料夾，裡面放一個必須叫 SKILL.md（SKILL 大寫）的檔案 —— 這是接頭暗號，名字寫錯系統不認。啟動時 Agent 只先讀每個技能的封面（名稱與描述）；等你的問題跟某個技能對上了，才去讀完整的指令層 —— 這個「漸進式揭露」的設計能省下大量 Token。之後你只要說「我要出門了，該帶什麼」，它就自己去定位、查天氣、照你的規則整理清單、用你要的格式回答。