最近大家應該開始用建立自己的 Agent 跟 Skill,常見的場景大概是這樣: 在 Claude Code 裡寫一些 Skills / 在 Cursor 裡讓 AI 操作 codebase / 或是把一些 Workflow 打包成 Plugin 一開始一切都很順利,直到某一天,你突然想:把 Skill 搬到另一個地方用,這時,你一定會問一個問題:
我在 Claude Code 寫了一個 Skill, 能不能在 Cursor + Claude 裡直接用?
我想很多人的直覺答案應該是:
只要都是 Claude 的 AI 模型 (model),應該可以吧?
這個直覺其實非常合理,但他背後其實藏著一個很大的誤解, 因為在 AI Agent 的世界裡,有一件事情很容易被混淆: Claude AI Model ≠ Claude Runtime 而 Skill 的跨平台問題,其實就是這件事造成的。
Claude Model 其實只是推理引擎
當我們說「使用 Claude」時,大部分人其實是在說: Claude AI Model 也就是透過 API 來呼叫一個 LLM,如果從系統角度來看,他做的事情其實非常單純:
input(輸入) → reasoning(推理) → output(輸出)
你給他 prompt,他回傳文字,就這樣。 他不知道:
- 你的 IDE
- 你的 repo
- 你的 workflow
- 你的 plugin
- 你的 skill
這些東西全部都在 模型之外。
但 Cursor 或 Claude Code 不只是 model
很多人第一次用 Cursor+Claude 或 Claude Code 時會有一種錯覺:
Claude 很會處理檔案、串接東西、寫 code。
但其實不是,因為你用的東西,用更準確的說法來說應該是:
Cursor = IDE runtime + Claude model
Claude Code = agent runtime + Claude model
這兩個工具其實都包含一整個 **runtime layer,**例如:
file access
tool system
context loader
workflow planner
sub-agents
當你以為 Claude 在幫你搜尋 Repo、修改檔案、甚至執行工具時,其實很多事情都不是 Model(Claude) 做的,而是 Runtime 在協調(Orchestrate)。
Skill 其實不是 Model Capability
現在回到 Skill,很多人第一次看到 Skill 時,會自然理解為 AI 模型的能力(Model Capability) 好像模型「學會了一個新技能」,但實際上 Skill 更接近 Workflow Module 讓我們看看實例,Claude Skills 通常是一個資料夾,裡面包含:
- instructions
- scripts
- resources
Claude 會在需要時載入這些內容來完成特定任務,換句話說,Skill 的運作依賴的是
skill loader
context injection
tool integration
而這些全部都在:
agent runtime
而不是 model。
(instructions + scripts + resources)"] SL["Skill Loader"] CI["Context Injection"] TI["Tool Integration"] AR["Agent Runtime"] S --> SL S --> CI S --> TI SL --> AR CI --> AR TI --> AR
為什麼 Skill 很難直接跨平台?
假設有兩個環境。 Claude Code = Claude model + agent runtime + skill loader + tools Cursor + Claude = Cursor runtime + Claude model
如果你在 Claude Code 寫了一個 Skill,例如:repo-analysis-skill 裡面可能會假設:
- 可以搜尋 repo
- 可以呼叫工具
- 可以載入 context
當你把這個 Skill 拿到 Cursor 時,通常會發生一件事:就是什麼都不會發生 不是因為 Cursor 的 Claude 不會用這個 Skill,而是因為 Cursor 的 Runtime 不知道怎麼載入它, 所以 Skill 能不能跨平台,其實不是 Model 的問題,真正的問題是 Runtime Architecture
AI Agent 其實有分層
如果把整個 Agent 系統拆開, 通常會看到三層:
(Claude Code、Cursor、Windsurf)"] B["Agent Runtime
(tool execution · skill loading · workflow planning · context management)"] C["Model
(reasoning · language generation)"] A --> B --> C
其中 Model 負責:reasoning、language generation,Runtime 負責:tool execution、skill loading、workflow planning、context management Skill 所在的位置其實就在 **agent runtime,**不是 model。 所以 Skill portability 的問題其實不是:
Claude 能不能跑這個 Skill?
真正的問題是:
這個 Runtime 能不能理解這個 Skill?
下一個問題
當你理解了這一層,你開始研究 Agent 系統時,就會了解到,Agent 並不是單純的 Model 加上 Skills,還有很多東西要考慮,而這時,你很快就會看到三個名詞:
Skills、Tools、MCP
第一次看到時,大部分人都會困惑:
- Skill 是不是 Tool?
- MCP 是不是 Tool?
- Tool 跟 Skill 又差在哪?
如果要理解 AI Agent 的架構,這三個東西其實非常關鍵,雖然常常被混在一起,**但他們其實是三個完全不同的層,**我們下一篇就要來聊聊他們。
參考資料
[1] Anthropic: “Effective Harnesses for Long-Running Agents” — 說明 Claude Agent SDK 作為 “agent harness” 如何管理模型所見的一切 https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
[2] Latent Space: “Is Harness Engineering Real?” — 定義 harness 為連結、保護、協調元件的層;只改 harness(不改模型)就提升了所有 15 個 LLM 的表現 https://www.latent.space/p/ainews-is-harness-engineering-real
[3] Simon Willison: “Agents are models using tools in a loop” — Agent 的精確定義:LLM 請求 harness 執行動作,結果回饋進模型 https://simonwillison.net/2025/May/22/tools-in-a-loop/
[4] Anthropic: “Equipping Agents for the Real World with Agent Skills” — Skills 是 runtime 動態載入的資料夾,不是 model capability https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
[5] Anthropic: “Extend Claude with Skills”(官方文件)— 記錄 progressive disclosure 系統:啟動載入描述,呼叫時才載入完整內容 https://docs.anthropic.com/en/docs/claude-code/skills
[6] Anthropic: “Building Agents with the Claude Agent SDK” — SDK 被描述為 “the agent harness that powers Claude Code”,介於 application 和 model 之間 https://www.anthropic.com/engineering/building-agents-with-the-claude-agent-sdk
支持這個系列
如果這系列文章對你有幫助,考慮請我喝杯咖啡
請我喝杯咖啡
