編者按： 我們今天為大家帶來的這篇文章，作者的核心觀點是：相較於依賴複雜且高成本的動態 MCP 工具加載機制，以 Skills 為核心的能力摘要與自維護模式，在當前階段反而更加高效、穩定且可控。

文章系統梳理了延遲工具加載（deferred tool loading）的工程現實與限制，指出即便工具可以延後注入，對話級別的工具集合仍然是靜態的，且發現機制高度依賴正則匹配，收益並不如預期。作者進一步深入分析了 MCP 在上下文佔用、API 穩定性、緩存失效與推理軌跡丟失等方面帶來的隱性成本，並結合 Sentry MCP、Playwright 等實踐案例，説明為何將 MCP 轉換為 Skills，反而能讓 Agent 更好地發揮既有工具的能力。文章最後還探討了 MCP 是否可能完全轉化為 Skills 的可行性，並坦率指出當前協議與生態在穩定性與摘要機制上的不足。

作者 | Armin Ronacher

(作者為 Flask、Jinja2 等開源項目的創建者)

編譯 | 嶽揚

我正把所有的 MCP 都遷移到 Skills 上，包括之前還在使用的最後一個：Sentry MCP（譯者注：Sentry 是流行的應用監控與錯誤追蹤平台）。早前我就已經完全棄用 Playwright（譯者注：由 Microsoft 開發的現代 Web 自動化測試和瀏覽器自動化框架），轉向使用 Playwright Skill。

過去一個月左右，關於使用“動態工具配置（dynamic tool loadouts）[1]”來推遲工具定義的加載的討論一直不少。Anthropic 也在探索通過代碼來串聯 MCP 調用的思路，這一點我也嘗試過[2]。

我想分享一下自己在這方面的最新心得，以及為什麼 Anthropic 提出的“延遲工具加載方案（deferred tool loading）”並未改變我對 MCP 的看法。或許這些內容對他人會有所幫助。

01 什麼是工具（Tool）？

當 Agent 通過強化學習或其他方式接觸到工具定義時，它會被鼓勵在遇到適合使用該工具的場景時，通過特殊的 token 輸出工具調用。實際上，工具定義只能出現在系統提示詞（system prompt）中特定的工具定義 token 之間。從歷史經驗來看，這意味着我們無法在對話狀態的中途動態發出新的工具定義。因此，唯一的現實選擇是在對話開始時就將工具加載好。

在智能體應用場景中，我們當然可以隨時壓縮對話狀態，或更改系統消息中的工具定義。但這樣做的後果是，我們會丟失推理軌跡（reasoning traces）以及緩存（cache）。以 Anthropic 為例，這將大幅增加對話成本：基本上就是從頭開始，相比於緩存讀取，需要支付完整的 token 費用，外加緩存寫入成本。

Anthropic 最近的一項創新是“延遲工具加載”（deferred tool loading）。我們仍然需要提前在系統提示詞（system message）中聲明工具，但這些工具不會在系統提示詞發出時就注入到對話中，而是會稍後才出現。不過據我所知，這些工具定義在整個對話過程中仍必須是靜態的 —— 也就是説，哪些工具可能存在，是在對話開始時就確定好的。 Anthropic 發現這些工具的方式，純粹是通過正則表達式（regex）搜索實現的。

02 與 Skills 的對比

儘管帶延遲加載的 MCP 感覺上應該表現更優，實際上卻需要在 LLM API 端做不少工程化工作。而 Skills 系統完全不需要這些，至少從我的經驗來看，其表現依然更勝一籌。

Skills 實質上只是對現有能力及其説明文件位置的簡短摘要。這些信息會被主動加載到上下文中。 因此，智能體能在系統上下文裏（或上下文的其他位置）知曉自己具備哪些能力，並獲知如何使用這些能力的“手冊鏈接”。

關鍵在於，Skills 並不會真正把工具定義加載到上下文中。 可用工具保持不變：bash 以及智能體已有的其他工具。Skills 所能提供的，只是如何更高效使用這些工具的技巧和方法。

由於 Skills 主要教的是如何使用其他命令行工具和類似實用程序，因此組合與協調這些工具的基本方式其實並未改變。讓 Claude 系列模型成為優秀工具調用者的強化學習機制，恰好能幫助處理這些新發現的工具。

03 MCP 能否轉換為 Skills？

這自然引出了一個問題：既然 Skills 效果這麼好，我能不能把 MCP 完全移出上下文，轉而像 Anthropic 提議的那樣，通過 CLI 來調用它？答案是：可以，但效果並不好。Peter Steinberger 的 mcporter[3] 就是其中一種方案。簡單來説，它會讀取 .mcp.json 文件，並將背後的 MCP 暴露為可調用的工具：

npx mcporter call 'linear.create_comment(issueId: "ENG-123", body: "Looks good!")'

確實，它看起來非常像一個 LLM 可以調用的命令行工具。但問題在於，LLM 根本不知道有哪些工具可用 —— 現在你得專門教它。於是你可能會想：那為什麼不創建一些 Skills，來教 LLM 瞭解這些 MCP 呢？對我而言，這裏的問題在於：MCP 服務器根本沒有維持 API 穩定性的意願。它們越來越傾向於將工具定義精簡到極致，只為節省 token。 這種做法有其道理，但對 Skills 模式來説卻適得其反。舉個例子，Sentry MCP 服務器曾徹底將查詢語法切換為自然語言。這對 Agent 來説是一次重大改進，但我之前關於如何使用它的建議反而成了障礙，而且我沒能第一時間發現問題。

這其實和 Anthropic 的“延遲工具加載方案”非常相似：上下文中完全沒有任何關於該工具的信息，我們必須手動創建一份摘要。我們過去對 MCP 工具採用的預加載（eager loading）方式，如今陷入了一個尷尬的局面：描述既太長，不便預加載；又太短，無法真正教會 Agent 如何使用它們。 因此，至少從我的經驗來看，你最終還是得為通過 mcporter 或類似方式暴露出來的 MCP 工具，手動維護這些 Skills 摘要。

04 最省事的路線

這讓我得出了目前的結論：我傾向於選擇最省事的方式，也就是讓 Agent 自己以“Skills”的形式編寫所需的工具。 這樣做不僅耗時不多，最大的好處還在於工具基本處於我的掌控之中。每當它出問題或需要新增功能時，我就讓 Agent 去調整它。Sentry MCP 就是個很好的例子 —— 我認為它可能是目前設計得最好的 MCP 之一，但我已經不再使用它了。一方面是因為一旦在上下文中立即加載它，就會直接消耗約 8k 個 token；另一方面，我也一直沒能通過 mcporter 讓它正常工作。現在我讓 Claude 為我維護一個對應的 Skill。沒錯，這個 Skill 可能有不少 bug，也需要不斷更新，但由於是 Agent 自己維護的，整體效果反而更好。

當然，這一切很可能在未來發生變化。但就目前而言，手動維護的 Skills，以及讓 Agent 自行編寫工具，已成為我的首選方式。我推測，基於 MCP 的動態工具加載終將成為主流，但要實現這一點，可能還需要一系列協議層面的改進，以便引入類似 Skills 的摘要機制，以及為工具內置使用手冊。 我也認為，MCP 如果能具備更強的協議穩定性，將大有裨益。目前 MCP 服務器隨意更改工具描述的做法，與那些已經固化下來的調用方式（materialized calls）以及在 README 和技能文件中編寫的外部工具説明很難兼容。

END

本期互動內容 🍻

❓拋開現有方案，你理想中的AI工具調用範式應該長什麼樣？用一句話描述你最核心的需求。

文中鏈接

[1]https://www.anthropic.com/engineering/advanced-tool-use

[2]https://lucumr.pocoo.org/2025/7/3/tools/

[3]https://github.com/steipete/mcporter

原文鏈接：

https://lucumr.pocoo.org/2025/12/13/skills-vs-mcp/