未來 AI 的競爭：Model 還是 Skill Ecosystem？

前三篇我們拆解了 AI Agent 系統的核心結構：

1. Model ≠ Runtime: Skill 活在 Runtime 裡，不是 Model 裡
2. 五層架構: Command → Agent → Tool + Skill → Context
3. Context Engineering 是地基: JIT 載入、Token 預算、Progressive Disclosure

現在把這些拼起來，你會看到一個完整的 AI Agent Stack，而這個 Stack 的形狀，決定了 AI 接下來的競爭方向

完整的 AI Agent Stack

把第一篇的「三層技術棧」和第二篇的「五層內部架構」合在一起看：

這裡有三件事值得注意：

第一，五層架構全部活在 Runtime 裡： Command、Agent、Tool、Skill、Context，這些都是 Runtime 的內部結構，Model 不知道這些東西的存在，他只會看到最後被注入的 prompt

2026/3/31 更新： Command 這層正在被合併進 Skill。概念上仍是「使用者觸發的入口」，但實作上不再是獨立機制。詳見這篇新聞報導 [1]。

第二，Context Engineering 是 Runtime 的核心工作： 第三篇談的 JIT 載入、Token 預算、Progressive Disclosure，這些全部由 Runtime 執行，Model 不管你怎麼管理 Context，他只處理收到的 Tokens

第三，同一個 Model 可以跑在不同的 Runtime 上： Claude 可以跑在 Claude Code 裡，也可以跑在 Cursor 裡，但兩個 Runtime 的 Skill Loader、Context Injection、Tool System 完全不同

這就是為什麼第一篇提到的問題如此關鍵：Skill 能不能跨平台，取決於 Runtime，不是 Model

MCP 解決了一半的問題

在上面的 Stack 裡，Tool 的跨平台問題已經有了答案：MCP，MCP 讓不同的 Runtime 可以用同一套協議連接外部系統，不管你用 Claude Code 還是 Cursor，只要支援 MCP，就能用同一個 Slack connector、同一個 GitHub connector，第二篇我們說過，MCP 本質上是 Tool 的子集，但他解決的問題很明確：Tool Portability

Tool portability → MCP（已有標準）
Skill portability → ???（暫時沒有標準）

Tool 是「怎麼執行」，他不外乎是呼叫 API、讀寫檔案、搜尋資料庫，這些動作可以被標準化，因為它們的 interface 很明確：input → action → output，但 Skill 是「怎麼思考」，這要怎麼標準化？

Skill Portability：真正的難題

一個 Skill 要能跨平台運作，Runtime 至少需要理解三件事：

1. 怎麼找到 Skill

• Skill 放在哪裡？在 Claude Code 裡是 .claude/skills/ 目錄。但 Cursor 有自己的結構，Windsurf 也有自己的結構，光是「Skill 放在哪」這件事，每個 Runtime 就不一樣

2. 怎麼載入 Skill

• 第三篇講的 Progressive Disclosure，先載 SKILL.md 摘要，需要時再載子目錄細節，這個載入邏輯是 Runtime 實作的，不同 Runtime 的 Skill Loader 不同，同一個 Skill 可能被完全不同的方式載入，甚至根本不被載入

3. 怎麼跟 Tool 配合

• Skill 本身不執行，它提供知識讓 Agent 決定要呼叫哪些 Tool，但每個 Runtime 可用的 Tool 不同，一個 Skill 假設 Agent 可以用 Bash() 和 WebSearch()，但目標 Runtime 可能根本沒有這些 Tool

這三個問題加在一起，就是為什麼 你在 Claude Code 寫的 Skill 搬到 Cursor 時，什麼都不會發生 不是 Claude 不會用這個 Skill，是 Cursor 的 Runtime 不知道怎麼處理他

這很像早期的 App 生態系

如果你經歷過智慧型手機早期，會覺得這個局面很熟悉，2008 年，iPhone 推出 App Store，Android 有 Google Play，Windows Phone 有自己的 Store。

同一個 App 的概念，比如「To-Do List(待辦清單)」必須為每個平台重寫一次，不是因為邏輯不同，而是因為 每個平台的 runtime、API、UI framework 都不一樣，最後的結果我們都知道了：生態系豐富的平台贏了，不是因為它的硬體最好，而是因為開發者在那裡、用戶在那裡、App 在那裡，而現在，AI Agent 的 Skill 正在走同一條路

競爭的三個層次

如果把 AI Agent Stack 的競爭拆開，有三個層次：

Model 層：推理能力的競爭

Claude vs GPT vs Gemini，這是目前最多人關注的層次，但如果 Model 只是推理引擎，就像 CPU 只是運算引擎，那長期來看，Model 會越來越商品化，就像今天沒有人因為 CPU 的品牌選手機（嗯… 可能還是有一些，比如很技術導向的工程師？）

Runtime 層：開發者體驗的競爭

Claude Code vs Cursor vs Copilot，Runtime 決定了開發者的日常體驗：Tool System 好不好用、Context Management 有沒有做好、Skill Loader 靈不靈活，目前各家 Runtime 的差異遠比 Model 的差異大，就像大家用 Gemini 是為了圖跟影片，用 Claude 是為了 Code，用 GPT 是為了… 他很會嘴砲？

Skill 層：知識生態系的競爭

這是目前發展最初期、但可能影響最深遠的層次，當 Skill 可以被打包、分享、安裝時，哪個平台有最多高品質的 Skill，哪個平台就最有價值，不是因為它的 Model 最強，而是因為它的 Agent 最有可能滿足你的需求，一個有完整 Legal Skill、Security Skill、Finance Skill 的平台，比一個只有更好 Model 的平台更有用，因為專業知識比通用推理更稀缺，Claude 最近推出的 Cowork 就是在做這件事。

目前的局面

• Model → 標準化程度：高（API 介面趨同）→ 競爭狀態：激烈但趨向商品化
• Tool → 標準化程度：中（MCP 正在推動）→ 競爭狀態：逐漸收斂
• Skill → 標準化程度：低（無跨平台標準）→ 競爭狀態：早期，尚無標準
• Context Engineering → 標準化程度：極低 → 競爭狀態：目前幾乎無競爭，但開源社群都在想辦法

第三篇我們講的 Context Engineering，包含 JIT 載入、Token 預算、Progressive Disclosure，還不是現在的通則，大部分 AI 使用者或開發者還在比誰的 prompt 更長、誰的 RAG 更準、誰的 Model 更新，但真正決定 Agent 系統品質的，不是 Model 有多強，而是 Context 管理得有多精準

所以接下來該關注什麼？

如果你正在建構 AI Agent 系統，這四篇的結論可以濃縮成四句話：

**1. Model 是引擎，不是系統：**別把所有注意力放在 Model 上。你的 Agent 好不好用，80% 取決於 Runtime 和 Context Engineering，不是 Model

**2. 架構要分層，但 Context 是地基：**五層架構（Command → Agent → Tool + Skill → Context）給你清楚的分工。但如果 Context Engineering 沒做好，其他層都會降級。

**3. Skill 是下一個競爭戰場：**當 Tool portability 被 MCP 解決之後，下一個問題就是 Skill portability，誰先建立起 Skill 生態系，誰就在下一輪競爭中佔據優勢

**4. 先做好一個 Agent，再想生態系：**Anthropic 說得很對，先從一個 Agent + 好的 Context 開始，把 Context Engineering 做好，比建 MultiAgent 架構更有用

AI 的競爭正在從「誰的 Model 最聰明」轉向「誰的 Skill 生態系最豐富」，Model 會越來越強、越來越便宜、越來越像商品，但**專業知識不會變成商品，**他會變成 Skill，被打包、被分享、被交易，所以未來最有價值的 AI 平台，不一定是 Model 最強的那個。而是 讓最多專業知識變成 Skill、讓最多 Skill 被最多人使用 的那個，這就是我看到的 AI Agent 的下一章，但他很可能已經在轉角處了

延伸閱讀

• Simon Willison: “Claude Skills are awesome, maybe a bigger deal than MCP” [2] — Willison 認為 Skills 可能比 MCP 更重要：“A skill is a Markdown file telling the model how to do something” link

• Communications of the ACM: “The Commoditization of LLMs” [3] — “Low switching costs are a key factor supporting the commoditization of Large Language Models” link

• Microsoft: “LLMs Are Becoming a Commodity — Now What?” [4] — Microsoft 對 model 商品化與競爭動態轉變的觀點 link

• Anthropic: “Effective Context Engineering for AI Agents” [5] — “The quality of every response is determined primarily by what the model is allowed to see in its context window” link

• Skillport — gotalab (GitHub) [6] — “Bring Agent Skills to Any AI Agent and Coding Agent — via CLI or MCP. Manage once, serve anywhere”；此工具的存在確認了 portability gap link

• UC Berkeley (Gorilla): “Agent Marketplace” [7] — 學術觀點討論 agent marketplace dynamics 和生態系競爭 link

參考資料：

[1] Claude Code 將 Command 合併進 Skill 的新聞報導 /news/claude-code-deprecate-command

[2] Simon Willison: “Claude Skills are awesome, maybe a bigger deal than MCP” https://simonwillison.net/2025/Oct/16/claude-skills/

[3] Communications of the ACM: “The Commoditization of LLMs” https://cacm.acm.org/blogcacm/the-commoditization-of-llms/

[4] Microsoft: “LLMs Are Becoming a Commodity — Now What?” https://www.microsoft.com/en-us/worklab/llms-are-becoming-a-commodity-now-what

[5] Anthropic: “Effective Context Engineering for AI Agents” https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

[6] Skillport — gotalab (GitHub): Bring Agent Skills to Any AI Agent https://github.com/gotalab/skillport

[7] UC Berkeley (Gorilla): “Agent Marketplace” https://gorilla.cs.berkeley.edu/blogs/11_agent_marketplace.html