AI Agent 使用：
從「會開」練到「開得穩」
上一課你搞懂了 Agent 是什麼生物；這一課教你怎麼把牠用得順手。 一小時之後，「context window」「compaction」「MCP」「Skill」這些名詞會從咒語變成你的日常操作—— 而且下次挑 coding agent 的時候，你會知道自己在挑什麼。
第 1 章 · CONTEXT 管理你的 Agent 有一張會坐滿的桌子
先建立一個貫穿全課的畫面：模型工作的時候，眼前有一張桌子。 你的指示、專案的檔案、對話的歷史、工具跑出來的結果——通通要攤在這張桌子上， 它才「看得到」。桌上沒有的東西，對它來說等於不存在。 這張桌子的正式名字，叫 context window（上下文視窗）。
桌子的大小用 token 計算——token 是模型讀寫文字的最小單位， 你可以粗略想成「比字小一點的碎片」：一個英文單字大約 1～2 個 token， 一個中文字大約 1～2 個 token。桌子能攤幾個 token，是模型出廠就定死的硬上限。
桌子有多大？主流模型的量級感
不用背精確數字（各家一直在改），抓住量級就好：早年的模型只有 4k～8k token（幾頁文件就滿）， 現在主流模型普遍在 128k～200k token 這個級距（大約一本中篇小說）， 部分模型已經推進到 100 萬 token 等級。聽起來很大？ 一個中型專案的原始碼、幾輪來回的工具輸出，塞滿 200k 比你想像中快得多。
塞爆的那一刻，會發生什麼事？
桌子滿了，東西還一直來，只有三種下場（取決於系統怎麼設計）：
- 直接報錯。API 拒收：「超過 context 上限」。最誠實，也最掃興。
- 截斷。把最舊的內容默默掃下桌。Agent 突然「忘記」你半小時前的重要指示——不是失憶，是那段被掃掉了。
- 自動壓縮（auto-compact）。比較聰明的做法：快滿的時候，先把舊對話「摘要成一張便條」再繼續。 Claude Code 這類工具內建這個機制——你看過「compacting conversation」跑出來，就是它在收桌子。
殘酷真相：桌子大 ≠ 每個角落都看得清楚
研究者發現一個尷尬的現象：就算內容全部塞得進去，模型對開頭和結尾的內容記得最牢， 對埋在中段的內容卻常常視而不見——術語叫 lost in the middle。 像你讀一份 300 頁的簡報：第一頁和最後一頁印象深刻，第 147 頁寫了什麼？誰知道。 所以「反正塞得下，全部塞進去就對了」是新手最常見的迷信—— 塞得下，不代表看得見。
而且，每一張桌面都是要錢的
API 按 token 計費：桌上攤的東西越多，每一輪的花費越高、回應越慢。 更陰的是「每一輪」三個字——對話式互動裡，之前的內容每輪都要重新攤上桌重新算錢。 塞了 150k 的垃圾上下文，代表你之後的每一句話都在為這 150k 買單。 大桌子是能力，不是免費午餐。
🎮 動手玩：Context 儀表板
口說無憑，看儀表。下面是一個模擬的 200k token 桌面， 平常它被四種東西瓜分：系統提示（Agent 的出廠說明書＋工具清單）、 對話歷史（你們的來回）、工具輸出（讀檔、跑指令的結果）， 剩下的才是可用空間。點一個情境，看看桌面被吃成什麼樣——
📊 選一個情境：
※ token 數為教學示意值，非真實模型即時計算。
Context window 是有硬上限、越滿越貴越慢、而且中段會看不清楚的一張桌子。 所以「管理桌面」不是潔癖，是剛需——你剛剛在儀表板上看到的每一種爆桌姿勢， 下一章都有對應的解法。
第 2 章 · 上下文管理桌子就這麼大，怎麼把日子過好
先講清楚分工：第 1 章講的是「牆在哪裡」——context window 的硬限制和物理機制； 這一章講「怎麼在牆內過日子」——實際的管理策略。 限制不會消失，但用對策略，同一張桌子能做完十倍的事。以下四招，由淺入深。
第一招：對話壓縮（compaction）——把流水帳換成便條
長對話裡真正需要「逐字保留」的內容其實很少。跑了 40 輪之後， 前 30 輪的價值大多可以濃縮成幾行：「使用者要做 X、已決定用方案 B、踩過的雷是 C」。 Compaction 就是讓模型把舊對話摘要成一段短文字，替換掉原文—— 桌面瞬間清出一大塊，代價是細節變粗。所以聰明的工具會讓你選時機： 在一個任務段落結束時壓縮，損失最小；在關鍵指令剛下完時壓縮，就可能把細節摘丟了。
實戰習慣：長任務進行中，感覺 Agent 開始「忘東忘西」，先懷疑是不是剛發生過一次壓縮—— 重要的約定，壓縮後值得再講一次，或者，寫進下面這招的「長期記憶」裡。
第二招：短期 vs 長期記憶——別把家規寫在便利貼上
兩種記憶，性質完全不同：
- 短期記憶＝當前對話的 context。視窗一滿就被壓縮、session 一關就蒸發。 適合放「這個任務當下」的資訊。
- 長期記憶＝寫進檔案的持久化上下文。例如專案根目錄的
CLAUDE.md（或AGENTS.md） 這類慣例文件、或 Agent 自己維護的 memory 檔案——每次開新對話都會被重新讀進桌面。 適合放「每次都該知道」的資訊：專案架構、部署流程、風格規範、踩過的坑。
同一件事你發現自己第二次跟 Agent 講，就該寫進長期記憶檔。 「我們的 API 都用 snake_case」這種家規講一次寫一次，之後每個新對話它自動知道—— 這是所有上下文管理技巧裡投資報酬率最高的一招。
順帶一提，這份檔案不一定叫 CLAUDE.md——那是 Claude Code 的慣例名字。
業界還有一個更通用的名字叫 AGENTS.md，不少 agent 工具都認這個檔名；
有些專案甚至兩個都放，或取自己喜歡的名字。名字不重要，概念是同一個：
放在專案根目錄、每次開新對話都會被讀進來的那份說明書。
除了專案層級的 CLAUDE.md / AGENTS.md，你還可以自己養一份更個人的記憶檔，
隨便取名 memory.md 或 notes.md 都行。做法陽春到不行：
每次任務結束，把「這次學到什麼、踩了什麼坑、跟 Agent 講好了什麼規矩」隨手記幾行進去；
下次開新對話，第一句就是「先讀 memory.md」——Agent 立刻接上上次的脈絡。
這就像護理站的交班筆記：值班的人換了，但筆記還在，新來的人翻一下就知道昨晚發生什麼事。 不用裝任何工具、不用任何設定，一個文字檔就搞定——這是所有「銜接記憶」技巧裡最好上手的一招。
第三招：RAG vs 直接塞——資料要用「檢索」還是「全上」
手上有一堆參考資料（文件庫、程式碼、知識庫），要讓 Agent 用得到，兩條路：
| 做法 | 📎 直接塞進 prompt | 📡 RAG（檢索補充） |
|---|---|---|
| 適合資料量 | 小：幾頁到幾十頁 | 大：塞不下、或塞了很浪費的量級 |
| 優點 | 簡單粗暴、模型看得到全貌、不會漏檢 | 只佔用「相關的那幾段」的桌面，省錢省注意力 |
| 缺點 | 吃桌面、吃錢、大了之後中段失明 | 多一套檢索系統要維護；檢索失準就答錯 |
| 口訣 | 塞得下又需要全貌 → 直接塞 | 資料庫等級的量 → 檢索，別硬塞 |
這不是二選一的宗教戰爭，是「資料量 × 是否需要全貌」的工程判斷。 十頁的規格書直接貼，兩百頁的知識庫上 RAG——第 1 課學過的 RAG，在這裡歸位成「上下文管理工具箱的其中一件」。
這裡只講「什麼時候該用」，真正拆開「檢索怎麼找、向量資料庫怎麼配」的原理， 我們另外開了一堂免費課 RAG 入門課， 有興趣可以去那邊看。
第四招：Multi-agent 的上下文——傳「結論」，不傳「流水帳」
多個 Agent 協作時（主 Agent 派任務給子 Agent），上下文設計有兩條鐵律：
- 隔離：每個子 Agent 用自己乾淨的桌子開工。 派「去查這個 bug 的成因」的偵查兵，不需要背著主對話 80k 的歷史上路—— 隔離讓子任務便宜、專注、不被無關資訊帶偏。
- 傳遞：子 Agent 做完，回報給主 Agent 的應該是結論與關鍵發現（幾百 token 的摘要）， 不是它全程讀過的每個檔案內容（可能幾萬 token）。 主 Agent 的桌面只收「精華」，才撐得起長任務。
你會發現這其實就是好主管的帶人方式：交代任務給明確的目標和必要背景（不是轉寄整串信）， 收報告要重點摘要（不是逐字錄音檔）。上下文管理，本質是資訊的管理學。
第 3 章 · MCP 介紹AI 世界的 USB-C
前兩章管的是「桌面上的資訊」；這章開始講「桌邊的工具」從哪來。 上一課說過，Agent 的能力上限就是它的工具清單——那問題來了： 誰來寫這些工具？每個都要自己做嗎？
標準化之前的黑暗時代：M × N 困境
想像你是 Agent 開發者，想讓你的 Agent 接上 GitHub、Slack、資料庫、Google Drive。 在沒有標準的年代，每一條線都要客製：你的 Agent 接 GitHub 寫一套接口， 別人的 Agent 接 GitHub 再寫一套；你要接十個服務就寫十套， 市面上 M 種 Agent × N 種服務 = M×N 套重複發明的輪子。 就像手機充電線的黑暗時代：每個牌子一種頭，出門要帶一包線。
MCP（Model Context Protocol，模型上下文協定）做的事就是 USB-C 做的事： 定義一套標準介面，規定「工具怎麼被描述、怎麼被呼叫、結果怎麼回傳」。 服務方照規格包一個「MCP server」，任何支援 MCP 的 Agent 都能直接插上用—— M×N 條客製線，變成 M+N 個標準接頭。寫一次，處處能插。
三個角色：Client、Host、Server
MCP 的架構用三個角色講完：
- Host（主機）——你在用的那個 Agent 應用本體（例如 Claude Code、桌面版 AI 應用）。 它管大局：管理連線、決定哪些工具開放給模型。
- Client（連接器）——Host 內部負責跟某一個 server 通話的元件，一對一專線。 （日常使用你幾乎感覺不到它，知道有這層就好。）
- Server（服務端）——真正提供能力的一方：包好一組工具對外開放， 例如「讀寫檔案」「查資料庫」「開 GitHub issue」。可以跑在你自己的電腦上，也可以是遠端服務。
一句話串起來：Host 裡的 Client，按照 MCP 規格跟 Server 通話； Server 提供的工具，就這樣出現在模型的「服務型錄」上。 模型本人完全不知道 MCP 存在——它只看到型錄上多了幾道菜。
常見誤會：MCP 就是 function calling 嗎？
很多人把 MCP 跟「tool use / function calling」混在一起講，其實它們是兩層不同的東西。 Function calling 是底層機制本身：模型說「我要呼叫這個工具、參數是這些」， 你的程式真的去執行，再把結果餵回給模型——這個一來一回的動作，是所有 Agent 框架的地基， 不管有沒有 MCP 都存在。MCP 解決的是另一個問題：工具那麼多、散落在各家服務， 要怎麼標準化地「接」給 Agent 用，不用每家都重新客製一遍。
打個比方：function calling 是「打電話」這個動作本身——拿起話筒、撥號、對方接聽； MCP 是電話簿加上統一規格的電話線路，讓你不用為了打給每一家公司都自己拉一條專線。 MCP 沒有取代打電話，它只是讓「找到號碼、接上線」這件事變得標準化。 所以下次聽到有人說「MCP 就是 function calling」，你可以微笑搖頭：一個是動作，一個是接線標準。
| 📞 Function calling / Tool use | 🔌 MCP | |
|---|---|---|
| 解決的問題 | 模型「怎麼呼叫」一個工具（呼叫的動作本身） | 工具「怎麼接上來」給 Agent 用（散布與整合） |
| 誰負責寫 | 模型廠商內建機制＋你的程式處理呼叫結果 | MCP server 作者寫一次，所有支援 MCP 的 Agent 都能用 |
| 沒有對方行不行 | 沒有 MCP 照樣存在，是 Agent 的地基 | 沒有 function calling 就沒戲，MCP 建立在它之上 |
| 類比 | 「打電話」這個動作 | 電話簿＋標準化的電話線路 |
菜市場逛一圈：常見的 MCP server
社群目錄上還有幾千個——凡是「Agent 想碰的外部系統」，大概率已經有人包好了。
「裝」一個 MCP server 長什麼樣？
以「幫 Agent 接上資料庫」為例，流程大致四步（示意，不是可執行程式碼）：
裝 MCP server ＝ 給 Agent 加手腳。裝之前想一下：這雙手能碰到什麼？ 能刪檔案的 server、能發訊息的 server，來源要挑可信的，權限給最小的。 上一課的鐵則在這裡復活：Agent 能闖的禍，上限就是你給它的工具清單。
第 4 章 · SKILL 介紹把 SOP 寫成 Agent 看得懂的秘笈
MCP 解決了「接工具」，但還有另一種東西工具給不了：做事的方法。 你一定遇過這種情況——Agent 明明有全部需要的工具，卻把一件你每週都做的事搞得七零八落， 因為它不知道你家的流程：部署前要先跑哪個檢查、報告要用什麼格式、哪個坑絕對不能踩。 每次都重新口頭交代一遍？那你就是在當人肉 SOP 復讀機。
Skill 就是把一段可重複使用的操作知識（SOP、領域訣竅、工作流程）寫成文件， 讓 Agent 在需要的時候自動載入照做。 它通常就是純文字（一個 markdown 檔），不需要寫程式、不需要外部服務—— 像武功秘笈：平常收在書架上（不佔桌面），遇到對的情境才抽出來翻。 Claude Code 的 Skills 機制就是這個概念的代表實作。
一個 skill 裡面大概有什麼？
- 觸發時機說明——「什麼情況該用我」：例如「當使用者要求發布新版本、說 release、版本發布時使用」。 Agent 靠這段描述判斷要不要載入這份秘笈。
- 步驟指引——SOP 本體：先做什麼、再做什麼、每步的注意事項、 出錯時怎麼辦（「nginx reload 要用 systemctl，不要用 nginx -s reload」這種血淚教訓）。
- 範例——輸入長怎樣、正確的輸出長怎樣。範例是防止 Agent 自由發揮的最強護欄。
Skill 跟 MCP 差在哪？——「工具」vs「工法」
兩個都是「幫 Agent 加能力」，但加的東西本質不同：
| 🔌 MCP | 📜 Skill | |
|---|---|---|
| 本質 | 接外部工具／資料源的協定 | 封裝好的操作流程／領域知識（通常是純文件） |
| 給 Agent 的是 | 新的「能力」：以前碰不到的系統現在碰得到 | 新的「方法」：工具早就有，現在知道怎麼用得對 |
| 需要什麼 | 一個 server 程式在跑（本機或遠端） | 一份寫清楚的文件，不一定要任何外部服務 |
| 類比 | 買一台新的廚房設備 | 一張貼在設備旁邊的食譜＋操作守則 |
| 誰都能做嗎 | 要會寫程式（或用現成的） | 會寫文件就能做——這是它最親民的地方 |
兩者常常搭配：MCP 接上資料庫（能力），skill 記載「我們家查報表的標準流程與欄位慣例」（方法）。 設備＋食譜，才是完整的廚房。
什麼情境值得寫成 skill？
- 重複出現的流程。每週都要做的發布、每次都同格式的報告——講過三次的事，寫一次 skill。
- 步驟多、順序敏感的操作。「先備份→再改設定→再重啟→再驗證」，漏一步就出事的，寫下來最保險。
- 有血淚教訓的領域。那些「上次就是這樣炸掉的」細節，寫進 skill，Agent 就不會再踩一次。
- 反例：一次性的任務、或每次做法都完全不同的事——寫成 skill 只是增加維護負擔，口頭交代就好。
MCP 給 Agent 手，skill 給 Agent 手感。 而且 skill 的門檻低到不可思議：你今天就可以把自己最常交代的那件事寫成一份文件—— 恭喜，你已經在做 Agent 工程了。
第 5 章 · 裝備迷思裝越多 MCP 和 Skill，Agent 就越強嗎？
學完 MCP 和 skill，很多人的第一反應是：那我裝爆不就好了？MCP server 裝二十個、skill 存五十份， 我的 Agent 豈不是十項全能？
抱歉，事實剛好相反。Agent 的能力不是裝備欄，不會線性疊加——裝過頭，還會倒扣。
MCP 佔的不是硬碟，是桌面
還記得第 1 章那張桌子嗎？每接上一個 MCP server，它提供的工具清單——每個工具的名字、參數、使用說明—— 全部都要攤在桌面上，Agent 才知道有這些工具可以用。裝一兩個沒感覺； 裝到十幾個，你的桌子有一大塊被「工具說明書」永久佔據，真正的任務內容反而要跟說明書搶位子。 你以為在給 Agent 加手腳，其實是在幫它的桌面堆雜物。
Skill 也佔位子，而且多一層「選錯」的風險
Skill 一多，Agent 每次都要先掃過所有 skill 的「什麼時候該用我」說明，才能判斷要載入哪份—— skill 越多，這層判斷越貴。更麻煩的是，如果你的 skill 們長得太像、描述又寫得模糊， Agent 會開始選擇困難：要嘛挑錯那份 SOP 照著做，做出你不要的東西；要嘛乾脆保險起見全部載入， 桌面直接塞爆。兩條路都是輸。
不是裝備越多越強，是背包越輕越好走。每一個 MCP、每一份 skill， 都在為它佔的桌面付租金——裝之前先想清楚，這房客付得起嗎。
實務口訣：裝之前先問三句話
- 這個我這週會用幾次？答案是零，就不要裝。
- 觸發說明寫精準了嗎？skill 之間描述別重疊，讓 Agent 一眼就知道找誰。
- 多久沒用了？定期清點，沒用到的移除——跟衣櫃斷捨離一樣，留下來的每一件都該是你真的會穿的。
第 6 章 · 怎麼選常見 AI coding agent 比一比
概念裝備齊了，來逛街。市面上的 AI coding agent 百家爭鳴， 但別急著問「哪個最好」——先看懂它們差在哪些維度，你才問得出對的問題。 以下挑幾個常見的代表選手（生態變化很快，抓定位就好，別背規格）：
| 工具 | 型態 | 模型彈性 | 大型 repo／終端機 | 定價模式 | 適合誰 |
|---|---|---|---|---|---|
| Claude Code | 終端機 CLI（另有 IDE 整合） | 以 Claude 系列為主 | 多檔案與長任務能力強；terminal 是主場，原生跑指令、測試 | 訂閱方案或 API 計費 | 住在終端機裡的人、要跑長 agentic 任務的個人與團隊 |
| Cursor | 獨立 AI 編輯器（VS Code 系） | 多模型可切換 | 編輯器內多檔案編輯順手，內建 agent 模式與終端機執行 | 訂閱制（含用量分級） | 想要「IDE 裡一站搞定」體驗的個人開發者 |
| GitHub Copilot | IDE 外掛（VS Code、JetBrains 等） | 提供多家模型選項 | 從行內補全起家，後續加入 chat 與 agent 能力；GitHub 生態整合深 | 訂閱制，企業方案成熟 | 團隊／企業導入、重度 GitHub 使用者 |
| Windsurf | 獨立 AI 編輯器 | 多模型可切換 | 主打 agentic 工作流（自動連續多步編輯） | 訂閱制 | 定位近似 Cursor，偏好其 agent 流程設計的人 |
| Cline | VS Code 開源外掛 | 自帶 API key，模型完全自選 | agent 模式可操作檔案與終端機，行為透明可審 | 外掛免費，付你自己的 API 費 | 想完全掌控模型與成本、偏好開源的開發者 |
※ 各家功能與價格迭代極快，此表抓的是「定位差異」；實際採用前請以官方當下資訊為準。
看懂表格的六個維度
- IDE 整合方式——終端機 CLI？IDE 外掛？還是整個編輯器換掉？這決定它嵌入你工作流的姿勢。
- 模型彈性——能不能換模型？鎖定單一家，還是自帶 API key 隨你接？
- 多檔案／大型 repo 能力——改一個函式誰都會；跨十個檔案的重構、在幾十萬行的 repo 裡找對地方下手，差距就出來了。
- Terminal／shell 整合——能不能自己跑測試、看報錯、裝依賴？這決定它能不能「閉環驗證」（上一課的重點）。
- 定價模式——吃到飽訂閱 vs 按量 API 計費：前者花費可預期，後者用多少付多少，重度使用前先算這筆帳。
- 適用情境——個人求快求彈性；團隊／企業要看權限管理、合規、帳務統一。
挑選心法：三個問題，不是一個排名
「哪個最好」是錯的問題；「哪個適合我」才是對的。依序問自己三題：
- 我的工作流長在哪？整天活在終端機 → CLI 型；離不開 IDE 介面 → 外掛或 AI 編輯器。 逆著自己的習慣選工具，再強都用不久。
- 我要多少掌控權？想換模型、控成本、看得到它每一步 → 開源／自帶 key 的路線； 想開箱即用不折騰 → 整合度高的訂閱制產品。
- 誰要用？自己一個人 → 挑體驗最順的就對了； 整個團隊 → 權限、合規、管理後台的重要性瞬間超過個人手感。
答完三題，表格裡的候選人通常只剩一兩個——而且不管選了誰， 前四章的功夫（context 管理、記憶檔、MCP、skill）全部通用，練了不白練。
第 7 章 · 結業考畢業前，八題定生死
全對的人，從此可以理直氣壯地說自己「會用 AI Agent」。答錯也沒關係，解釋就在下面。
🎓 帶走這 6 句話（其他都可以忘）
- Context window 是會坐滿的桌子：硬上限、越滿越貴越慢、中段還會看不清楚（lost in the middle）。
- 上下文管理四招：compaction 收桌面、長期記憶檔存家規、大資料用檢索別硬塞、multi-agent 傳結論不傳流水帳。
- MCP = AI 世界的 USB-C：標準化工具接口，把 M×N 的客製地獄變成 M+N。
- MCP 給手，Skill 給手感：一個接外部能力，一個封裝操作方法——會寫文件就會寫 skill。
- 裝備不是越多越強：MCP 和 skill 都佔桌面，裝之前先問這週會用幾次、值不值得。
- 選 agent 問三題：工作流在哪、要多少掌控權、誰要用——挑「適合」，不挑「最強」。
但把 Agent 用得好的人，贏在同一件事：
「懂它的桌子有多大、給它對的工具、寫下你家的做事方法。」