Token 被誰吃掉了? AI Agent & MCP & Skill
Who Eat the Token? AI Agent & MCP & Skill
AI (Artificial Intelligence)
先來一點簡單的角色介紹，很重要不准跳過OuO
AI Model
- 訓練完成的「參數檔」(weights)，本身是靜態的、不會自己運作
- 只有在被載入到記憶體並由推論程式(inference/runtime)執行後，才會「動起來」，能依照 prompt 產生回應
- ex. Claude Opus 4.5, Claude Sonnet 4.5, Claude Haiku 4.5, ...
AI Agent
- 以模型為核心，在外層再加上「任務導向」的控制與工具能力，讓模型不只回答問題，還能把事情做完，常見組成：
- RAG(Retrieval Augmented Generation, 檢索增強生成)：查資料、引用知識庫/文件
- 工具使用(Tool)：呼叫 API、執行指令、操作瀏覽器等
- 規劃與迭代：把目標拆步驟、執行、檢查結果、失敗就重試
- 記憶/狀態：保留任務 context
- ex. IDE 裡面的 Copilot Agent Mode
Software&Product
- 軟體本身不等於模型或 Agent!!!
- 但它可以「提供 AI 或 AI Agent 的功能」，把上述能力包裝成可用的工具
- 有些服務會提供數個模型讓 user 決定要用哪個模型當 Agent 的大腦
- ex. Claude Desktop, Cursor, Microsoft VS Code, ...
Claude Code 是什麼 ?
Claude Code 是一個可被安裝使用的 CLI 工具，很明顯他是個 Software&Product
同時，這個工具提供了 AI Agent 的功能，user 可以透過它來跟模型互動、讀寫檔案、跑指令、整合開發流程
Microsoft VS Code 是什麼 ?
微軟大戰代碼
Microsoft VS Code 是一個可被安裝使用的 IDE (整合開發環境)，很明顯他是個 Software&Product
另外，VS Code 可以透過 Plugin 提供 AI 或 AI Agent 的功能；重點是「VS Code 本體是載體」，Agent 能力通常來自外掛或整合服務
MCP
- 全名叫 Model Context Protocol
- 一套讓「AI Agent / App」用一致方式連接外部能力(工具、資料、服務、別的AI、...)的標準協定；重點是把「發現工具」(
tools/list) 與「呼叫工具」(tools/call) 的流程標準化，降低每個平台各做各的整合成本
(圖片來源: link) - 在 MCP 裡，工具(tool)是 server 對外暴露的一個可呼叫能力，每個 tool 會有：
- name：唯一識別工具
- description/title：給人/模型看的用途描述
- inputSchema：參數的 JSON Schema
- (可選)outputSchema：輸出結構的 JSON Schema
- 兩個最常見的動作：
tools/list- 列出可用工具清單，用來「發現」有哪些工具可以用
tools/call- 呼叫工具，server 執行後回傳結果
- 小小補充，MCP 規格提到 tools 以「model-controlled」為設計目標（模型能自行決定何時呼叫工具），但實作端仍可用任何互動模式(例如 UI 勾選、權限白名單、路由/篩選)，協定本身不強制某一種 UX
Skills
- Anthropic 提出的 Agent Skills
- 把「指令(instructions) ＋腳本(scripts) ＋資源(resources)」整理成一個有結構的資料夾，讓 Agent 能動態發現與載入
- 一個最簡單的 skill 只需要一個
SKILL.md檔案，必要欄位包含name與description - Agent Skills 的核心設計原則是 progressive disclosure (漸進式揭露)：
- 啟動時只把每個 skill 的
name/description這類 metadata 預載到 system prompt (第一層) - 當模型判斷某個 skill 可能有用時，才去讀完整的
SKILL.md內容進 context (第二層) - 若 skill 很大，還可以把內容拆到更多檔案 (第三層、第四、...) 成樹狀結構，由
SKILL.md以檔名指引模型需要時在看實際內容
- 啟動時只把每個 skill 的
- Skills 也可以包含可執行程式碼(例如 Python script)，讓 Agent 用「跑程式」完成某些事情，這通常比「用 token 生成步驟」更便宜
- 有沒有感覺很像 module? 其實 Skill 的本質就是透過模組化把 context 消耗降低，彌補 MCP 本身的問題而不是直接取代 MCP
- 目前沒有類似 npm、pip 之類的管理工具，要手動自己抓
Agent Skills 是什麼？
為什麼說它是一種「資料夾打包」的能力擴充方式？
Skills 是把指令、腳本、資源打包成一個可重用模組(常見是資料夾/檔案結構)，啟動時只載入 metadata
Progressive Disclosure 是什麼？
為什麼「只先載入 metadata」能有效降低 token 成本？
Skills 啟動時只載入 metadata，之後 Agent 會用字少少的 metadata 判斷需求跟內容的相關性，避免把 Skills 整包內容一次塞進 context
類似看書先看目錄(table of contents)，找到有相關的tool再詳細了解內容，而不是把整本書一次讀完
用 Playwright/Selenium/... 逐步自動化 UI 為什麼容易造成對話歷史膨脹？
UI 自動化很容易膨脹通常是因為 「每一步都會產生大量文字輸出」
比如說 DOM 節點、console log、network log、錯誤堆疊、甚至截圖 OCR 後的文字，這些一旦被完整塞回對話，就會快速吃掉 context
UI 自動化造成的對話歷史膨脹，可以怎麼減少？
- 只回傳「關鍵」而不是整包資料：例如只回傳失敗 selector、期望/實際、目前 URL、以及最小可重現步驟；不要貼整份 HTML/Network log
- 把長資料改成檔案附件，把 HAR、console log、HTML snapshot、trace 存檔，對話只回傳檔名與摘要；需要時再讓 agent 讀檔做二次分析(progressive disclosure 的精神)
- 分段驗證、不要讓 agent 一次跑太長，每個測試 case 跑完就輸出精簡報告，避免把整個 session 的逐步記錄都堆在同一串對話裡
對話歷史膨脹同時會伴隨那些現象？
對話過程中 Agent 的注意力被轉移，遺失原本的重點，或是觸發 auto compact
Token 被誰吃掉了?
回到一開始的問題，Token 被誰吃掉了? 明明有 200k context window 還是常常覺得不夠用 因為 Agent 在「做事」時，吃 token 的通常不只 user 下的那一句 prompt 而是一整串系統提示、工具定義、工具輸出、對話歷史、...
Token 吞噬獸
- System prompt / policy / agent 指令
- 為了讓 Agent 行為穩定，會在最前面放一大段系統規則與角色指令，這是固定成本
- 工具清單與 schema (尤其是 MCP tools)
- 每個 tool 的 description、inputSchema/outputSchema 都會佔 context
- 工具越多、描述越長，成本越高
- 工具執行後的回傳內容
- 像是網頁 HTML、Console log、Network log、錯誤堆疊、diff、trace、或一大段 JSON；只要「原封不動」塞回對話，token 會爆很快
- 對話歷史
- Agent 為了保持連貫性，會把前面做過的嘗試、決策、失敗原因一路帶著走，回合越多，成本越難控制
安全性問題
能呼叫外部工具就代表能對外部世界做事，這邊只簡單整理規格層面的安全要點，實際上目前 沒有 強制要求使用過程中要安全傳輸
MCP 的安全重點
MCP 規格在 tools 的安全注意事項中，明確要求
- server 端要做到驗證輸入、存取控制、rate limit、以及清理輸出，避免把危險內容或敏感資料直接回灌到模型
- client 端則被建議對敏感操作要求使用者確認、在呼叫前顯示 tool inputs、對 tool results 做驗證、設 timeout、並記錄 tool 使用以利稽核
Skills 的安全重點
Skills 可以夾帶指令與程式碼，惡意 skill 可能引導外洩資料、或在執行環境中做出非預期動作，官方建議
- 只從可信來源安裝
- 來源不完全可信，先審核 skill 目錄內所有檔案內容，特別注意 code dependencies、腳本、以及任何可能連到外部網路的指令或資源
如果想安全檢查外部專案，可以考慮: vscode.dev (沒錯，這傢伙其實是大大的webview) (但還是要注意瀏覽器可以取得的權限) (零信任很重要! 零信任很重要! 零信任很重要!)