轉自：https://weibo.com/1648815335/Qn8iCfNyt（微博：jolestar）

去年 MCP 爆火，大家一度有種感覺：只要把工具都接進來，AI Agent 就會“活”過來，像一個長了手腳的人，什麼都能幹。

如果把 LLM 看作大腦（智力引擎），tool call / function call 就像讓它能指揮四肢：模型填參數，代碼去執行，再把結果喂回去繼續推理。

MCP（Model Context Protocol）把這套機制做成了“標準插頭”：以前各家服務各自一套 SDK + API，你要給 Agent 封裝工具，就得處理語言、依賴、鑑權、返回格式，複雜度會指數上升；MCP 的價值是把“接入”這件事工程化、標準化。

所以當時最樂觀的推論很自然：只要 MCP 工具夠多，Agent 就有無限多的手腳，什麼都能幹了。

但很快大家就撞牆了。

第一堵牆：容量瓶頸（上下文預算）

工具的定義本身要進入系統 prompt 或等價的工具上下文；工具越多，佔用越多，留給“幹活”的空間越少。於是你會看到一些很現實的限制：某些 AI coding 工具最多支持配置 100 個 tools，而一個 GitHub MCP 可能就帶 50 多個。你想把世界都接進來，但大腦的工作台面就這麼大。

第二堵牆：任務閉環瓶頸（組合性）

很多 MCP 的調用結果會被直接回填上下文。短結果當然舒服，長結果就會觸發兩個問題：要麼上下文爆炸，要麼被截斷丟尾巴。

我在做 holon 的時候就踩過這個坑：讓 AI 去處理 PR 的 review comments，如果 comments 一多，直接回填上下文就會被截斷，結果總是漏修。 後來反而退回到更“原始”的 GitHub CLI 會更穩——AI 先用 `gh` 把評論拉下來寫成文件，再用 `grep`、`jq` 或簡單腳本去篩選、聚合，只把必要的摘要喂回上下文繼續推理。

這個過程讓我意識到一個很基礎、但之前容易被忽略的問題：上下文更適合承載決策信息，而不是當作數據存放層。 文件、數據庫、對象存儲這些外部介質，天然支持分頁、尋址和重複訪問，更適合用來承接中間狀態。當任務需要反覆回看、局部篩選或增量處理時，把數據外部化，往往比把全文塞回上下文要可靠得多。

從這個角度看，MCP 暴露出來的瓶頸，並不完全在協議本身，而在於我們常常下意識地把它用成了“往上下文裏塞數據”的通道，而不是“把能力接入到工作流裏”的接口。

也正是在這樣的背景下，SKILL 開始受到關注。

如果 SKILL 只是純文本，它更像分層 prompt 的組織方式；但當它和命令行工具、腳本結合起來，它就不只是“提示詞技巧”，而是一種場景化的工作流封裝：同一類任務的步驟、產物、工具鏈、失敗重試方式、輸出格式，都被聚合在一起。普通用户可能搞不清 MCP 是幹啥的，但他能理解“這個技能幫我把評論整理出來並逐條修復”。

從實現上看，這有點像“以前用膠水代碼粘合工具”，現在用“自然語言 + LLM + Bash/腳本”來粘合工具。並且這種範式正在讓 Prompt Engineering 轉向 Skill Engineering。靈活性確實強了，但相比標準化的擴展，SKILL 還有許多未解決的問題。

安全性是第一個難題。Bash + 腳本這些工具主要是開發者用，大家多少有點風險識別能力；但當 Agent + SKILL 普及到普通用户後，安全問題會更嚴重。到那時候，“靠提醒小心”是沒用的，Agent 環境得提供更強的沙箱隔離能力。

標準化是第二個難題。SKILL 天然是按場景聚合的，但也因此更依賴運行環境：目錄結構怎麼約定？中間產物放哪？狀態如何保存與複用？如何跨端複製這套模式？如果這些問題不解決，SKILL 的能力很難跨環境複用，更像是綁定在某個系統裏的私有插件。

説回 MCP，我並不覺得有了 SKILL，MCP 就沒意義了。恰恰相反，我更傾向於一種分工：

MCP 解決“連接標準化”，SKILL 解決“工作流編排與狀態外部化”。前者讓能力能規模化接入，後者讓任務能穩定閉環。

MCP 不一定要“由 Agent 直接調用並回填上下文”，它完全可以被 SKILL 裏的腳本調用，讓結果先落地為可尋址對象（文件/句柄/資源），再把摘要與索引回填給模型。這樣上下文就回到它最擅長的位置：做決策、做推理、做取捨，而不是當緩存。

MCP、SKILL 仍處在早期階段，只是 Agent 插件機制演化中的不同形態。當 Agent 開始承擔複雜任務時，真正重要的已不再是能力本身，而是上下文、狀態與執行邊界如何被拆分和安放。