如果我把 Skill 直接交給 Subagent 用，會不會兩份指示互相打架？
不會，因為兩者作用的層次不同。Skill 定義的是「這類任務該遵循什麼步驟」，這份定義本身是中立的、不綁定特定執行環境；Subagent 提供的是「執行的空間跟權限範圍」。當一個 Subagent 使用某個 Skill 時，等於是這個獨立實例在自己的上下文裡套用那份步驟指示——就像同一份食譜可以在不同廚房裡照做，食譜不會因為換了廚房就自相矛盾。
真正該注意的反而是另一件事：Subagent 有自己的工具權限範圍，如果 Skill 裡描述的步驟需要用到 Subagent 沒有被授權的工具，步驟會卡住，這不是「兩份指示打架」，是權限範圍沒對齊，設計時要確認 Subagent 的工具權限涵蓋 Skill 實際會用到的操作。
為什麼 Anthropic 要把「知道怎麼做」跟「誰來做」拆成兩個獨立機制，而不是全部整合進 Subagent 裡就好？
如果把步驟知識直接寫死在每個 Subagent 裡，會產生大量重複——你有幾個不同的 Subagent 都需要遵循同一套程式碼審查標準，就得把同一份內容複製貼上到每個 Subagent 的設定裡，之後標準一旦更新，要記得同步改好幾個地方，很容易漏掉某一份沒改到。
把知識抽出來變成獨立的 Skill，好處是它變成「可攜帶」的：同一份標準寫一次，可以被主對話用、被這個 Subagent 用、也被那個 Subagent 用，更新時只要改一份。這跟軟體工程裡「不要重複自己」的原則是同一個邏輯——Anthropic 官方文件也明確把這個分工描述成「Skill 提供可攜帶的專業知識，Subagent 提供獨立的執行空間」，是刻意設計成兩個正交的機制，而不是疊在一起的功能。
什麼情況下我明明有固定流程，卻不需要包成 Skill、也不需要用 Subagent？
如果這件事你這輩子大概只會做一兩次、或是流程雖然固定但每次的細節都差異很大到很難抽象成通用步驟，直接用一句清楚的 Prompt 講清楚可能反而更划算——包成 Skill 的價值在於「未來會重複用到」，如果沒有重複使用的預期，花時間寫 SKILL.md、設計 description 觸發條件，前期投入可能超過它省下的時間。
同樣地，如果這件事產生的中間過程不多、你也不介意它出現在主對話裡，用 Subagent 反而是多此一舉——啟動一個獨立實例本身有一定的協調成本，任務簡單到不需要隔離時，直接在主對話裡處理更直接。判斷標準很單純：先問「這件事會不會重複」，再問「這件事的執行過程需不需要隔離」，兩個都不成立時，最簡單的方式往往就是最好的方式。
我是完全的新手，該先學會用 Skill 還是先學會用 Subagent？
建議先從 Skill 開始。Skill 的心智模型比較單純——就是把你重複交代的步驟寫下來，不涉及「獨立實例」「上下文隔離」這類需要額外理解的概念，上手門檻低很多，而且大部分日常重複性工作（固定格式的報告、固定流程的資料整理）用 Skill 就能解決，不一定需要動用 Subagent。
Subagent 的價值要在你真的遇到「工作量大到會塞爆主對話」或「需要同時平行處理好幾個獨立任務」的情境下，才會真正感受到。與其為了學而學，不如先把 Skill 用熟，等到哪天你發現自己的主對話因為某個任務產生的雜訊變得又長又亂，那就是自然該去了解 Subagent 的時機，而不是一開始就同時學兩套。
你已經知道 Skill 是什麼——一份寫著固定步驟的 SKILL.md，符合情境就自動套用。用過一段時間後，新手常會撞上下一個問題：如果我需要 Claude 做一件複雜的多步驟工作、還想讓過程不要污染目前的對話，這時候該用 Skill 還是該用 Subagent？答案不是二選一，是理解兩者本來就在解決不同問題，多數成熟的用法其實是把兩者搭配起來。
Skill 是可攜帶的知識，它定義的是「這件事該遵循什麼步驟、什麼標準」。Skill 本身沒有獨立的執行環境，它套用在誰身上，就在誰的對話脈絡裡運作——如果是主對話呼叫，就用主對話的上下文；如果是 Subagent 呼叫，就用那個 Subagent 自己的上下文。這也是為什麼官方把 Skill 形容成「可攜帶的專業知識」：同一份程式碼審查標準，可以被主對話用，也可以被任何一個 Subagent 用，不需要為每個執行環境各寫一份。
Subagent 是一個獨立的 Claude 實例，有自己的上下文視窗、自己的工具權限。它解決的問題跟 Skill 完全不同：當你需要做一件會產生大量中間過程（例如翻閱幾十個檔案、跑一堆搜尋指令）但你只關心最終結論的工作，把這件事交給 Subagent 去做，那些雜訊留在 Subagent 自己的上下文裡，不會佔用你主對話的空間。這在需要平行處理多個獨立任務時效果特別明顯——例如同時稽核四個不同模組的安全性，四個 Subagent 各自帶著同一份「安全稽核」Skill，分頭進行，互不干擾彼此的上下文。
官方文件把這個分工講得很直接：Skill 定義「該做什麼」，Subagent 定義「誰來做、在什麼隔離範圍裡做」——兩者不是互相競爭的選項，而是互補的。一個常見的組合模式是：讓一個 Code Review Subagent 帶著「特定程式語言最佳實務」的 Skill 去執行審查，這樣你同時得到了 Subagent 的獨立性（不會拖髒主對話），也得到了 Skill 的可攜帶專業知識（同一份標準可以重複用在其他 Subagent 或主對話上）。
如果你要問的問題是「這件事該遵循什麼固定流程或標準」，答案通常是 Skill；如果你要問的問題是「這件事的執行過程會不會產生大量我不想看到的中間雜訊、需不需要跟主對話隔離」，答案通常是 Subagent；如果兩個問題都成立——有固定標準、又需要隔離執行——答案就是兩者一起用：把標準寫成 Skill，讓 Subagent 在執行時帶著這份 Skill 去跑。
把該隔離的工作留在主對話裡處理，代價是你的主對話上下文會被大量中間過程塞滿，之後每一輪都要重新處理這些用不到的雜訊，長期下來是實質的 token 浪費；反過來，如果你把不需要獨立執行環境的簡單任務硬是包成 Subagent，也會多付出啟動一個獨立實例的額外開銷。真正省錢的做法是先想清楚這件事「有沒有固定標準」跟「需不需要隔離」，再決定用 Skill、用 Subagent，還是兩者一起——而不是每次遇到複雜任務就直覺地丟給 Subagent，或每次都想著寫成 Skill 了事。