<p>最近 Anthropic 又刷了一波存在感。作為最早把 MCP 這個概念帶火的“開拓者”，他們顯然沒打算停下來：這兩天又提出了一個新概念，叫<strong>Skills</strong>。更關(guān)鍵的是，Anthropic 還表示會在<strong>2025 年 12 月</strong>把<strong>Agent Skills</strong>以<strong>開放標準</strong>的形式正式發(fā)布。</p><p class="image-package"><img class="uploaded-img" src="https://upload-images.jianshu.io/upload_images/2526335-54e67291671ca144.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" width="auto" height="auto"/></p><p>乍一看，MCP（模型上下文協(xié)議）和 Skills 就像是給大模型裝上的各種“外掛”或者“插件”。既然已經(jīng)有了 MCP 這種能讓 AI 聯(lián)網(wǎng)、讀數(shù)據(jù)的標準，為什么還要搞出一個叫 Skills 的新概念？這到底是技術(shù)真的升級了，還是又一次“換個名字繼續(xù)講”的概念膨脹？</p><p>其實，搞技術(shù)開發(fā)的核心目標就三個：能不能方便擴展、靠不靠譜、值不值得（成本是否劃算）。很多看起來“新東西”的出現(xiàn)，其實都是圍繞這三點在優(yōu)化。</p><p>從這個角度出發(fā)，Skills 之所以出現(xiàn)，是因為現(xiàn)有架構(gòu)在實際落地時暴露了一些明顯的痛點，而它正是用來針對這些問題做補齊和改進的。</p><p><strong>為什么有了 MCP，還需要 SKILLS？</strong></p><p>之所以在 MCP 生態(tài)日漸成熟后又引入 SKILLS，核心原因主要歸結(jié)于以下兩點現(xiàn)實約束與定位缺失：</p><p>MCP 生態(tài)越來越成熟之后，MCP 雖然好用，但隨著功能變強，它也變得越來越“臃腫”。引入<strong>SKILLS</strong>，本質(zhì)上是為了給模型“減負”和“省錢”。</p><p><strong>1) 現(xiàn)實限制：上下文窗口容易“被撐爆”，還顯得笨重</strong></p><p>比如前段時間探索<strong>Playwright MCP</strong>， 給模型加上瀏覽器自動化能力。為了讓模型“會用”這個工具，往往需要在提示詞/上下文里塞進很多東西：</p><ul><li><p>Playwright 一大堆 API 定義</p></li><li><p>各種參數(shù)結(jié)構(gòu)說明</p></li><li><p>甚至還有當前頁面的 DOM 樹信息</p></li></ul><p>這些內(nèi)容一多，<strong>上下文窗口很快就被占滿</strong>，系統(tǒng)也顯得笨重、不靈活。</p><p>更麻煩的是：<strong>工具調(diào)用過程中產(chǎn)生的中間結(jié)果也要占 token</strong>。在典型的 MCP 流程里，模型不僅要做決策，還常常要負責“轉(zhuǎn)發(fā)/整理數(shù)據(jù)”（有點像數(shù)據(jù)路由器），于是中間數(shù)據(jù)來來回回，token 消耗就被放大了。</p><p>官方舉的例子也能說明這個問題：當你讓 Agent 執(zhí)行“從 Google Drive 下載會議記錄，并把它附加到 Salesforce 的線索里”這種跨工具任務(wù)時，過程中會產(chǎn)生很多步驟和中間信息，而這些都會持續(xù)擠占上下文和 token(太費錢了)。</p><p class="image-package"><img class="uploaded-img" src="https://upload-images.jianshu.io/upload_images/2526335-db6638a8e7fb089d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" width="auto" height="auto"/></p><p>在 MCP 這種模式里，數(shù)據(jù)的傳遞方式說白了有點像“人工搬家”，而且是用手扛著著一整套沙發(fā)從一樓爬到二十樓那種笨辦法：</p><p><strong>(1）讀取時怎么做：</strong>模型先調(diào)用 Drive 工具，Drive 不管三七二十一，把一份長達 2 萬字的會議紀要<strong>整份</strong>塞進模型的上下文窗口里。</p><p class="image-package"><strong>(2）寫入時怎么做：</strong>模型把這份長文檔讀完后，又調(diào)用 Salesforce 工具，然后把這<strong>2 萬字原封不動當作參數(shù)</strong>再塞進去，重新發(fā)送一遍。</p><p>結(jié)果就是：<strong>又貴、又卡、還容易出錯。</strong></p><ul><li><p><strong>Token 花費翻倍（貴）：</strong></p><p>比如一場 2 小時的銷售會議，轉(zhuǎn)錄文本可能就有 50,000 個 Token?，F(xiàn)在等于“進一次、出一次”，模型要處理兩遍大文本，額外多吃掉 100,000+ Token，成本直接飆升。</p></li><li><p><strong>上下文容易爆掉（卡）：</strong></p><p>就算是支持長上下文的模型，遇到更大的文檔或更復雜的數(shù)據(jù)結(jié)構(gòu)，也可能一下子把窗口塞滿，導致流程跑到一半直接中斷。</p></li><li><p><strong>穩(wěn)定性變差（錯）：</strong></p><p>模型在“手動搬運”海量內(nèi)容時，就像人 copy-paste 大段文字一樣，容易出現(xiàn)<strong>幻覺、漏內(nèi)容、被截斷、格式亂</strong>等問題。</p></li></ul><p>這種做法不僅讓 Token 消耗暴漲（成本更高），還會因為上下文太長、信息太多而分散模型注意力，讓它在真正需要思考的關(guān)鍵邏輯上反而“變笨”。</p><p><strong>2). 定位缺失：工具和方法“沒連起來”</strong></p><p>MCP 的核心作用，是把“怎么調(diào)用工具”這件事統(tǒng)一成一套標準協(xié)議。它最初要解決的問題很現(xiàn)實：如果有N個模型、M 個工具，兩兩適配會變得特別復雜。</p><p>但問題在于：MCP 只規(guī)定了“手怎么用工具”（調(diào)用方式），卻沒規(guī)定“腦子怎么把事情做完”（業(yè)務(wù)流程/SOP 怎么編排）。</p><p>所以在當前常見架構(gòu)里，就算 Dify、n8n 這類平臺能很方便把 MCP 接進來當“工具庫”，真正的業(yè)務(wù)邏輯往往還是：</p><ul><li><p>藏在大模型的“隱性經(jīng)驗”里（靠模型臨場發(fā)揮），或</p></li><li><p>寫死在人工配置/硬編碼的工作流里。</p></li></ul><p>結(jié)果就是：工具本身是“被動提供能力”的，但“怎么組合這些工具完成復雜任務(wù)”，缺少一個統(tǒng)一、標準的承載方式。</p><p><strong>3). 怎么補這個空？Anthropic 用 Skills 給出答案</strong></p><p>為了解決“有工具但缺流程標準”的問題，Anthropic 提出了<strong>Skills（技能）</strong>。</p><p>你可以把 Skill 理解成：<strong>把某件事做好的標準操作方法（SOP）打包成一個可復用模塊</strong>。</p><p>打個比方：</p><ul><li><p>大模型像廚師，</p></li><li><p>工具像鍋碗瓢盆和灶臺，</p></li><li><p>Skill 就像一道菜的“標準菜譜”：什么時候切菜、先炒什么、火候多少、用哪些廚具——都寫清楚。</p></li></ul><p>因此，Skill 的本質(zhì)是<strong>標準化的 SOP 沉淀</strong>：不僅說明“要做什么”，還把“怎么做、需要哪些資源”一起封裝進去。</p><p>對比一下變化會更直觀：</p><ul><li><p><strong>過去</strong>：因為模型理解有限，業(yè)務(wù)流程通常只能用 Python/JS 或 Dify 的 YAML 這類方式“硬編碼”出來。</p></li><li><p><strong>現(xiàn)在</strong>：模型理解力更強后，很多流程可以直接用自然語言描述；非程序員也能把自己的經(jīng)驗固化成可復用的流程模塊。類似思路早期在 OpenAI 的 GPTs 上出現(xiàn)過，但 Skill 更強調(diào)“工程化與標準化”——不局限在某個聊天產(chǎn)品里，而是能成為 Agent 可調(diào)用的基礎(chǔ)能力單元。</p></li></ul>
<p><strong>核心理念：別一股腦塞給 AI，要“按需投喂”</strong></p><p>雖然現(xiàn)在的 AI 記性越來越好（上下文窗口變大），但如果你把成噸的信息一次性全倒給它，AI 也會“大腦過載”，不僅容易胡言亂語、抓不住重點，而且還特別費錢。</p><p>所以，Skill 的設(shè)計思路就像“剝洋蔥”<strong>或者</strong>“看菜單”：<strong>不問不給，問到哪層給哪層</strong>。這種專業(yè)術(shù)語叫“漸進式披露”，說白了就是：<strong>只在最需要的時候，給最關(guān)鍵的信息。</strong></p><p>為了實現(xiàn)這一點，Skill 把信息分成了三層：</p><p><strong>第一層：店招/名片（元數(shù)據(jù)層 —— 始終亮著）</strong></p><ul><li><p><strong>作用：</strong> 告訴 AI “我是干嘛的”。</p></li><li><p><strong>內(nèi)容：</strong> 只有技能的名字和一句話簡介。</p></li><li><p><strong>好處：</strong> 就像店門口的招牌，AI 一眼就能掃到，占用的“腦力”（Token）極少，非常省錢。</p></li></ul><p><strong>第二層：操作手冊（指令層 —— 選中后再看）</strong></p><ul><li><p><strong>作用：</strong> 告訴 AI “這事兒具體怎么辦”。</p></li><li><p>內(nèi)容：詳細的步驟、規(guī)矩和工作流程（比如<code>SKILL.md</code> 文件）。</p></li><li><p><strong>好處：</strong> 只有當 AI 確定要用這個技能時，才會去讀這份手冊。這樣它能集中注意力，把事兒辦得更穩(wěn)妥。</p></li></ul><p><strong>第三層：工具箱/大倉庫（資源層 —— 干活時才開）</strong></p><ul><li><p><strong>作用：</strong> 給 AI 真正干活用的“原材料”。</p></li><li><p><strong>內(nèi)容：</strong> 復雜的代碼腳本、厚厚的參考文檔、龐大的數(shù)據(jù)模板。</p></li><li><p><strong>好處：</strong> 這是最占內(nèi)存、最費錢的部分。所以，只有當 AI 真正開始動手干活、非用不可時，才會去倉庫里取。</p></li></ul><p><strong>Skill 的標準結(jié)構(gòu)：一個有序的“工作間”</strong></p><p>一個標準的 Skill 通常會按“文件夾 + 文件”的方式來組織。你可以把它想成：<strong>一個技能包</strong>，里面把“說明書、工具、資料、素材”分門別類放好，結(jié)構(gòu)大概是這樣：</p><pre>my-skill/
├──?SKILL.md??????????#?[必需]?核心大腦。包含元數(shù)據(jù)（name、description）和自然語言編寫的指令流程
├──?scripts/??????????#?[可選]?執(zhí)行手腳。存放?Python/Bash?等可執(zhí)行代碼，封裝復雜邏輯
├──?references/???????#?[可選]?知識庫。存放模型決策所需的參考文檔、API?手冊等
└──?assets/???????????#?[可選]?靜態(tài)資源。存放輸出報告所需的模板、圖片、示例數(shù)據(jù)等</pre><p>這種分層設(shè)計有什么好處？</p><ul><li><p><strong>更省 Token、上下文更“干凈”</strong></p><p>模型不會一上來就把所有內(nèi)容都讀進來：</p><p>先只看<code>SKILL.md</code>里的元信息來判斷“要不要用這個技能”；決定要用之后再讀具體流程；真正執(zhí)行時才去加載<code>scripts</code>或<code>references</code>。</p><p>這樣可以有效避免上下文越堆越大。</p><p>也能解決“中間工具結(jié)果把 token 吃光”的問題：在 Skill 模式下，模型更多是<strong>下指令讓腳本去干活</strong>，比如腳本直接從 Google Drive 拉數(shù)據(jù)并寫進 Salesforce，大段會議記錄根本不需要塞進模型的上下文窗口。</p></li><li><p><strong>更穩(wěn)定、更不容易出錯（魯棒性更強）</strong></p><p>把復雜、常用、容易踩坑的操作封裝進<code>scripts</code>，就不需要模型每次都“現(xiàn)場寫代碼、現(xiàn)場調(diào)試”。</p><p>結(jié)果就是：<strong>幻覺更少、錯誤更少、執(zhí)行更一致</strong>。</p><p>這也符合很多工具型產(chǎn)品的思路：把高頻且容易錯的部分固化成“工具/代碼”，把需要靈活判斷的部分留給模型來做。</p></li></ul><p><strong>簡單三步，上手使用 Skill</strong></p><p>使用 Skill 的過程非常直觀，就像給你的 AI 助手安裝了一個“功能插件”。</p><p><strong>1). 怎么安裝？</strong></p><p>你不需要復雜的配置，只需要把寫好的<code>skills</code>文件夾，像放文件一樣丟進特定的目錄即可。</p><p>通常有兩個地方可以選擇：</p><ul><li><p><strong>全局有效：</strong> 放在你電腦的用戶目錄下。</p></li><li><p>項目有效：放在你當前工作項目的根目錄下，路徑通常是<code>.claude/skills</code>。</p></li></ul><p><strong>2). 怎么運行？</strong></p><p>如果你習慣用命令行，直接使用<strong>Claude Code</strong>工具就能調(diào)用。如果你更喜歡在編譯器里操作，比如<strong>Cursor</strong>或<strong>VS Code</strong>，只要符合文件規(guī)范，AI 就能自動識別并學會這個新技能。</p><p><strong>3). 舉個例子：做一份紅燒肉</strong></p><p>開發(fā)一個 Skill 到底有多簡單？以“教 AI 做紅燒肉”為例：你只需要寫清楚步驟和邏輯，保存成文件即可。</p><p>這種方式帶來了一個巨大的變化——<strong>“配置即代碼”</strong>：</p><ul><li><p><strong>以前：</strong> 你可能需要在 Dify 這種可視化平臺上，像連連看一樣拉很多線條、點很多按鈕來設(shè)計工作流。</p></li><li><p><strong>現(xiàn)在：</strong> 你只需要寫一段結(jié)構(gòu)化的文字（代碼）。</p></li></ul><p><strong>這樣做有什么好處？</strong></p><ul><li><p><strong>管理方便：</strong> 像管理代碼文件一樣，你可以隨時查看修改記錄（版本管理）。</p></li><li><p><strong>輕松分享：</strong> 把文件發(fā)給同事，他粘貼到文件夾里就能直接用。</p></li><li><p><strong>隨處復用：</strong> 同樣的功能，可以在不同的項目中無縫切換。</p></li></ul><p>就一句話，Skill 讓 AI 的能力變得“模塊化”了——<strong>寫完即用，復制即學會。</strong></p><p><strong>后記</strong></p><p>這幾個月里，開發(fā)者社區(qū)一直在分享各種 MCP 工具，大家主要是在解決“怎么把手伸出去干活”的問題——也就是讓模型能調(diào)用工具、訪問資源、完成具體操作。</p><p>但從現(xiàn)在開始、以及接下來一段時間，<strong>Skill 很可能會成為的方向</strong>。因為它不只解決“手”，更在解決兩件更關(guān)鍵的事：<strong>怎么思考（腦）</strong>，以及<strong>怎么把事情按步驟做完（流程）</strong>。</p><p>更重要的是，Skill 不只是把工具和資源“收納起來”，它還能把一套做事方法<strong>標準化、流程化</strong>。當大模型的推理能力越來越強，Skill 就像補上了“自主智能體”拼圖里那塊最關(guān)鍵的缺口——讓它不止會做事，還會<strong>按正確的方法持續(xù)把事做成</strong>。</p><p>
</p>
