Skip to content

Instantly share code, notes, and snippets.

@coodoo

coodoo/skills_and_mcp.md

Created January 2, 2026 07:29
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save coodoo/964ba1d813049e94b6d7680dcc4edfd3 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save coodoo/964ba1d813049e94b6d7680dcc4edfd3 to your computer and use it in GitHub Desktop.
Download ZIP
mcp 與 skills 釋疑。
Raw
skills_and_mcp.md

脆文：https://www.threads.com/@thecat88tw/post/DS__HXfkROF

謝謝 @cab_late 花時間仔細閱讀並如此詳細的回應我的貼文，這兩天跨年比較忙，今天終於有時間坐下來針對他的疑慮提出幾點說明，大家參考看看，希望有幫助。

關於 function call

首先要先對 functionl call 的本質與目地有清楚的認知。

它是讓 LLM 操作外部資料(side effects)的主要途徑，也是最底層的基礎手法。

透過 functional call 可操作各種不同 tools 例如 Bash, Read, Write... 等。

不論 mcp 或 skill 也都是 tools 的一種，皆透過 function calling 來操作。

而這邊藏在細節裏的魔鬼是：雖同為 function call 但操作的方式、頻率與手法會大大影響 agent 最終的結果與表現。

快速複習一下 mcp 幾個硬傷

  1. 沒解決漸進調用問題前用起來成本很高，當數量一多時近乎不實用，因為光啟動就吃光 context 了

  2. 單次操作模式且每次需返還中間暫存資料佔用大量 context

  3. 無法彈性組合工作流程一次執行多支 mcp 完成工作再返還結果

Skills 的出現就是為了解決上述三個主要缺點，並結合 llm 日漸強大的寫扣能力帶來更彈性的應用可能性。

mcp vs. skills 實際用例比較

不囉唆讓我們先看個實際流程對照一下比較有感覺，這裏的例子是：

同時使用 context7、deepwiki 與 github 查詢 react 文件與最新 issues。

→ mcp 的工作流程：

  1. 一啟動先傳送 context7, deepwiki 與 github 三支 mcp 規格 ← 耗用 context

  2. 操作 context7 mcp 讀取文件並返還資料 ← 耗用 context

  3. 操作 deepwiki mcp 讀取文件並返還資料 ← 耗用 context

  4. 操作 github mcp 讀取文件並返還資料 ← 耗用 context

  5. llm 蒐集完前面三份資料後再進行整理然後吐出最終報告

→ skills 的工作流程：

  1. 一啟動僅傳送輕量目錄告知 llm 有三個 skills 可用以及它們個別功能 ← 耗用 context

  2. 操作 context skill 讀取文件，將結果暫存於硬碟內成為 a.md ← 不佔用 context

  3. 操作 deepwiki skill 讀取文件，將結果暫存於硬碟內成為 b.md ← 不佔用 context

  4. 操作 github skill 讀取文件，將結果暫存於硬碟內成為 c.md ← 不佔用 context

  5. 操作事先寫好的 report.py skill 從 a/b/c 三份 md 內挖出需要的部份

4.1 接著可回傳此份 final.md 給 llm 應用 ← 耗用 context

4.2 或就留在硬碟裏等將來 llm 需要時再用 Read tool 讀取 ← 不佔用 context

只要你耐心看懂上面兩個流程比較，就能理解兩者的差異性與優缺點。

skills 核心特色:

  1. 徹底解決漸進調用的問題

它一開始只送輕量目錄，等 llm 決定要用某支工具時才讀取它詳細內容，在此之前不會浪費任何 token 與污染 context

  1. 善用硬碟做為暫存空間不必每次皆返還中間資料

如上則貼文的例子所示

  1. 可彈性組合多支 skills 一次完成工作，以減少多次 llm <> mcp 往返時間和佔用 context

  2. 只要會寫 markdown 就能製作自己專屬 skills 享受一勞永逸的便利性，如果會寫 py/js 則效果更佳！

skills 特殊優點：可提供大量事先寫好的 js/py 供 llm 操作以完成複雜任務

以前面的例子來說，如果每次都需要同時查詢 context7/deepweek/github 三家，你可以事先寫好一支 py/js 做完此事，下面是 pseudo code:

const reports = [
	get_context7('react'),
	get_deepwiki('react'),
	get_github('react'),
]
return generate_report(reports)

在這個劇情裏，llm 只需呼叫一支 report.js 就能直接拿到最終報告，中間省掉多次往返操作的時間，更節省大量中間暫存資料耗用的 tokens

這也是為何網路上 skills market 通常都會附送大量量現成 scripts 的原因，目地就是幫大家省掉重複造輪子的麻煩，畢竟全天下工程師想法都很接近嘛...

skills 的終極超能力：llm 可寫程式一次操作多支 skills 完成任務

如果前面事先提供寫好的 js/py 仍無法滿足你家 agent 需要應付的變化萬千需求，終極之道就是讓 llm 依需求當場寫程式來操作各種 skills。

別忘了所謂的 vibe coding 原本就是大量依賴 llm 寫程式的能力，這代表他原本就非常擅常這件事，為何不發揮它的長處而要自我設限或自廢武功呢？

以上例來說，那支 report.js 可以是你事先手寫，也可以是 llm 當場寫好並執行：

const reports = [
	get_context7('react'),
	get_deepwiki('react'),
	get_github('react'),
]
return generate_report(reports)

但 llm 寫程式每次都不一樣且很可能出錯該怎麼辦？

當然 llm 寫的程式很可能出錯，而 prodution 等級的 agent workflow 講求的是穩定可靠也就是絕對的"確定性"。

這件事 anthronpic 也已想到並提供了解法，答案在這份文件中：

https://www.anthropic.com/engineering/code-execution-with-mcp

跳到頁面最下方 "State persistence and skills" 這段並注意這行：

"Agents can also persist their own code as reusable functions. Once an agent develops working code for a task, it can save that implementation for future use"

因此實務上可採取的解法有兩種：

  1. 開發時讓 agent 盡情寫扣，就算錯一百次也沒關係，但只要其中一次成功就將它存下來以後重複使用。

  2. 在 workflow 裏加上檢核步驟去驗証 agent 即時寫的程式執行結果是否符合預期(例如應同時有 context7/deepwiki/github 三份內容，缺一份就視為失敗)，如果判定為失敗即可中斷 workflow，而非讓錯誤的結果呈現給用戶。

llm 俱有不確定性是它的特色也是它的缺點，我們的目標是善用它的特色(創意與生成程式碼)但避免它的缺點(唬爛或程式寫錯)，這其中可透過許多高明的工程手段解決或降低影響，而絕非因為有不確定性就因噎廢食，關上自己一扇機會大門。

skills 能與 mcp 合作

skills 與 mcp 並非零合遊戲，因為 mcp 可轉換為程式後透過 skills 操作。

可參考這份文件(跳到"Code execution with MCP improves context efficiency"那段)：

https://www.anthropic.com/engineering/code-execution-with-mcp

換個角度看，因為可將 mcp 封裝為程式透過 skills 來執行，因此它可被視為 skills 的 subset 或實作細節。

但重點是只要用了這招，你就能立即享受 skills 帶來的所有好處，也能繼續延用原本 mcp 所有功能，是一個兩全其美的結局，何樂不為呢？

順帶一提，有人已依據那份文件的概念做好一支工具可直接將所有 mcp 轉成 skills 使用：

https://github.com/steipete/mcporter

skills 目前缺點在 auth

當天 anthronpic 工程師有明確指出目前 skills 唯一已知無法解決的問題是 auth，例如在 claude.ai 網站上如何取得用戶的 google drive key 以代為操作？

以往使用 mcp 的解法是由 mcp client 觸發 google oauth 介面讓用戶操作，等成功登入後即取得 token 保管於 mcp server 內部，後續流程即可順利進行。

這裏要注意一個重大區別：他所指的無解問題僅限於像 claude.ai/chatgpt.com 這種網站服務，如果是跑在本機或 container 內的 agent 則同樣可支援述相同的 oauth 流程。

但好消息是他們說已積極在解決此問題，不如就耐心等待坐等收割成果囉？

但 mcp 是標準而 skills 不是？

Skills 已在去年底開源並成為 open standard，且目前已有 openai codex 支援。

官網： https://agentskills.io/home

新聞： https://www.infoai.com.tw/blog/anthropic-agent-skills-open-standard

國外網友怎麼看待 mcp/skill？

Simon Willison 是 Django 與 Datasette 的創始人，也是當今網路上最活躍與權威的 AI 寫手大神(你一定在網上看過許多叫 AI 畫 pelican riding bike 的圖？那就是他的代表性測試題目) 前天他正好貼出 2025 年度回顧中也有提到 MCP，他用的標題是 "The (only?) year of MCP"，建議可仔細讀完他的想法：

https://simonwillison.net/2025/Dec/31/the-year-in-llms/#the-only-year-of-mcp

並且毫不意外這篇文章也在 hacker news 上引起大量討論，國外網友們同樣對 mcp 的角色、定位與去留充滿歧義，可見當新概念出現時正常人覺得困惑不解也是合情合理的事：

https://news.ycombinator.com/item?id=46450209

只能說我個人過去一年的實務經驗與 Simon 完全一致，當一年前我發現 agent 透過 shell 就穩定完成大量工作後，幾乎就立即捨棄所有其它工具(包含 mcp)而全改用 Bash 指令了，而直接成效就是 agent 表現立即改善 200% 很多以往難解的頭痛問題瞬間就消失了。

附帶一提：如果你還沒養成這習慣，可考慮立即訂閱 Simon 的電子報以隨時跟上大神的腳步，看看矽谷最前緣現在玩些什麼！

其它回應 1

"聽說 Claude Meetup 將 LLM 無法穩定寫程式所以必須採取 Function Call 的方式視為一種技術債/歷史共業，但你 Skill 的 Script 跟 Function Call 本質有甚麼不一樣嗎？"

這裏將兩個完全不同的概念混為一談了。

Function calling 是很早就解決的事，但我前文說的是 "llm 即時寫 js/py 程式並執行"的能力，當年模型這方面表現還不穩定，因此只能靠 function calling 傳固定參數這招來解決。

但後來模型能力大幅進步，寫扣也早已非難事，因此讓它直接寫程式操作 skills 就變的非常可行，也是 agent 能力能否大幅進步最重要的關鍵之一(畢竟 agent 最重要的特質就是 agency 也就是自主性能主動做決策不是嗎？)

其它回應 2

"他與 MCP 的標準性質是截然不同的，MCP 給予的標準是一套 Program Protocol，Skills 只能說是一套方法論。" 與 "它還沒有成為一個標準，也很難成為標準"

實際上 Skills 已是開源的標準，網站上也明確規範 spec 每個欄位的命名方式與內容格式，這完全是一套業界可共同遵循的標準手法。

規格書: https://agentskills.io/specification

整合方式: https://agentskills.io/integrate-skills

其它回應 3

"Claude Code 在使用 Skill 上的體驗感極佳，是因為 Claude Code 內部的流程已經對 Skill 這樣的漸進式揭露有良好的支援度。(邏輯推算)"

實際上 skills 功能完全就是靠 prompt 提示與幾個範例就能做到，這點只要有研究過 claude code 程式碼與提示詞就能明白，不需靠猜測。這也是為何很多人用 gpt5 與 gemini3 搭配 claude code 同樣能順利使用的原因。

其它回應 4

"再來就是 LLM 具有隨機性，10 個人產同一功能的程式碼絕對不可能一模一樣，Workflow 最忌諱的就是隨機性，你怎麼會認為讓 AI 總是自己產程式碼去執行「工具」是一條樂觀的方向？(非開發，別拿開發來槓)"

這點可參考前面## 但 llm 寫程式每次都不一樣且很可能出錯該怎麼辦？那段的說明。

其它回應 5

"我是不信 Claude 工程師會無腦說出這種話啦，除非他就是要來推銷 Claude Code。"

當天現場出席的台裔美籍原廠工程師名為 Oliver，在活動主頁上可找到他的資訊，當時現場大約有一打人直接參與對談，也可直接與他求証當天是否有公開講過這句話~😉

所以有取代這回事嗎？

如果將 mcp/skills 視為 "讓 llm 擁有操作外部資源的能力" 來看，大部份情況下兩者是可互相取代的，但可想成 skills 是 mcp 2.0 也就是升級版，或是 mcp 的 superset 也行。

一個簡單的判斷心法是如果你符合下列任何一點即可考慮改用 skills：

  1. 你的 use case 能用 skills 達成與 mcp 相同目地，那就可無痛置換，立即享受 skills 帶來的所有好處

  2. 你的 agent 跑久後老是失憶或注意力潰散，無論怎麼改提示也無法改善，這時可檢查是否 context 內容是否又臭又長且被 mcp 操作佔用大量空間

  3. 你相信 llm 有能力寫程式組合多支 skills 同時工作並達成任務

  4. 你的 agent 用例需要極高的彈性而現有固定提示與 mcp 工具已無法勝任

但終歸一句話，所課「君子不器」，做為工程師不需太糾結名詞差異，從實務觀點來看，哪個工具 work 就用那個才是王道囉！

結語

在學習技術的道路上互相漏氣求進步本是常態也無可厚非，但希望大家能心平氣和、友善理性且就事論事的討論，情緒性用語或冷嘲熱諷通常只會帶來反效果而失去溝通與建立共識的機會。

最後再次感謝 @cab_late 與前篇貼文下回應的各位，讓我有機會更仔細思考如何清楚表達這個全新的概念以及更好的溝通方式，這也正是上社群網站與真人交流最大的價值不是嗎？

PS. 台灣這週開始天氣要急凍了，各位出門注意多保暖，也祝大家 2026 新年事事如意，個個成為這波全球 AI 衝浪中的明日之星！🙌

看完這篇如果仍有疑問，歡迎繼續在下面留言，我會盡力回答(但切記理性、禮貌與友善)！

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment