DAY 002

Claude Skills 能取代 MCP 嗎?

今天來研究一下最近很紅的 Claude Agent Skills。 起因是最近去 Claude Meetup Taipei 的聚會,看到有人認為 Skills 可以用來取代 MCP。要判斷這個陳述是否正確,必須先了解一下 Skills 跟類似功能的差異。 一直有個疑惑,Agent vs Skills vs MCP 概念都有點像,它們都可以幫 Claude 裝上許多裝備、變得更多才多藝,但究竟差在哪?讓我們退一步,先釐清一下發展的脈絡。 傳統軟體工程追求的是確定的 (deterministic),優點是可靠、不出錯;缺點就是開發耗時,功能必須一個一個設計,沒有實作就不會有功能。 自從 LLM 成熟、大家慢慢進入 Vibe Coding 的年代後,LLM 的本質「文字接龍」可以說是集結了人類的智慧,開始能給出預想不到的東西。訓練出來的大模型已經可以提煉出概念性的內容,優點是靈活、有創意、速度快;缺點是每一次都像在擲骰子,沒人能保證成果的穩定度。 這兩個面向可以說是光譜的兩端,這也是為什麼相對資深的工程師可能對 AI 有較多抵觸,因為這直接挑戰了工程師多年的訓練——這不只是信仰問題,更是寫實的信任問題。但這種時候能做出信仰之躍 (leap of faith) 的人,往往有辦法享受到時代紅利。與其說 AI 哪裡做得不夠好,不妨問問該怎麼做能讓 AI 的產出更穩定,將變化控制在可容許範圍且大幅解放生產力,而不是單純停留在「AI 能不能做到」。 目前我觀察到有兩個主流的探索方向:其一是把任務切碎或套用方法論,讓每個步驟間的「距離」縮短,這樣即使 LLM 有不穩定度也相對能接受;二是不要把所有事情都交給 LLM,如果需求是確定性的(例如圖片轉檔),有既有工具就應優先調用,預期會有更穩定的產出,而不是期望 LLM 自己實作邏輯後給出一樣的結果。 Agent 本質上就是一份描述文件,把你希望它遵守的事情告訴它,給它範例、規範或是方向,比較接近角色扮演。我之前的用法是覺得版控有點花時間,所以寫了個 git-committer 請它幫我把每個 commit 切小,但自己用下來,有時候還是沒有成功調用到。 MCP (Model Context Protocol) 看起來是高大上的縮寫,其實是把既有的程式調用接口整理起來並附上操作說明,讓 AI 知道有什麼需求可以直接調用。這非常適合一些知道 know-how 或資料的應用,例如想問現在比特幣多少錢,它知道去問交易所的接口取得正確資訊,而不是根據訓練資料瞎掰。但缺點是,若把沒用到的詳細接口資訊也一併餵給 AI,有機會造成失憶或是佔用 Context Window 的問題,意味著使用成本上升。 Skills 則介於以上兩者之間。它不只有詳細的說明文件,更可以附上程式指令,且可以是特定程式語言的檔案。最重要的是官方強調 Skills 是 filesystem-based(基於檔案),可以「漸進式揭露」。意思是只要把功能拆得越細、分散在不同檔案,AI 只會根據需求揭露相關資訊進去,沒揭露到的部分就不花錢。所以詳細說明書應該放在獨立檔案裡,而只把最重要的功能摘要放在最外層即可。所追求的是往確定性靠攏,但又不會太燒錢。 終於可以回答一開始的命題:Skills 是否可以取代 MCP? 其實要看情況。如果你過去只把本地調用的程式指令放進 MCP 裡使用,那可以;但如果是資料在人家手上的 MCP,恐怕只能優化成用 Skills 去串接,但這樣就變成長期要維護 Skills,這種情況下答案是否定的。不過,以前的 Agent 確實可以試著加上 Skills,或是改用 Skills 來提升穩定度。 最後要小心提醒,因為 Skills 會直接調用指令,基本上就是在操作你的裝置,未來一定會出現利用這個手法產生的攻擊,所以不是網路上有人分享就可以直接拿來用。我相信很多 Vibe Coding 浪潮衝進來的新人,在不久的將來會在這邊踩一個大坑。呼籲在使用前請 AI 幫忙分析一下有沒有問題,以及可以自己裝在本地的工具就盡量不要往外呼叫,以防未來有心人士把實作內容換掉、輕鬆入侵裝置。 在此附上原討論串: https://www.threads.com/@thecat88tw/post/DS4o-e0EeOc?xmt=AQF03vL3FZgM0D3HEi3Yp3vBf1lYCEHGePBzqND_HWlstM5V7eLecmjOawjl7Rp323TH7w1F&slof=1&fbclid=IwY2xjawPJV4ZleHRuA2FlbQIxMABicmlkETE0NDVHcWtPYW5GQmt4SVFLc3J0YwZhcHBfaWQQMjIyMDM5MTc4ODIwMDg5MgABHhGuzEzvEYbQDW1vLK6nFdk2_18ku9JytZ62qQxA4IOEFyCV4X0qBjK7XZK9_aem_RbUjLsqxt1XE0DCxcvdk8g

延伸閱讀
看完整 167 篇 →