Skill、MCP 還是 CLI？一件重複的事該接成哪一種，掛錯的成本比你想的高
同一件每週重複三次的行銷工作，該寫成 skill、接成 MCP，還是包成 CLI 指令？判準是它缺的是知識、通道還是執行效率。這篇把 MCP 2026 年新規範、token 開銷與漸進式揭露，翻譯成品牌主算得出來的三筆帳。
工具的說明書，在你開口之前就先花掉錢了
Anthropic 的工程團隊在 2025 年 11 月的進階工具使用說明裡公開過一組自家的數字：在做最佳化之前，光是把可用工具的說明書塞進模型的工作記憶，就先吃掉 134,000 個 token。這筆錢的用途只有一個，讓 agent 知道你手上有哪些東西可以用。使用者的第一句話，這時候還沒送進去。
同一批工程師在另一份工程紀錄裡示範了另一種做法：讓模型寫一小段程式去取用，而不是一次呼叫一個工具、每個結果都回到模型面前。他們用一個搬移逐字稿的示例估算，這樣做可以把用量壓到 2,000 個 token，原本要花 150,000 個，省下 98.7%。同一篇也提到，一份兩小時的銷售會議逐字稿如果走完整個工具往返，可能額外處理約 50,000 個 token。這兩個數字是該文的示例估算，不是跨環境通用的基準。
這兩組數字講的是同一件事。接一個工具進來，從來不是免費的動作，它有價格標籤，而且是每次開工都要重付一次的那一種。
那份沒有人負責砍的清單
我們把多次工具盤點裡常見的狀況合成一個場景：內部的工具清單愈接愈長，每接一個的當下，大家的反應都是多這一個沒差。某個週一早上，會議室裡有人問，同樣的問題為什麼上個月答得比較準。
那份清單沒有人負責砍。要開口說砍掉誰，其實有點尷尬。從來沒有人算過它的價錢，所以也沒有人有立場說它太貴。
三個名詞，回答的是三個不同的問題
行銷團隊在討論 AI 工具的時候，Skill、MCP、CLI 這三個詞常常被擺在同一個句子裡比較，好像是在問哪一個比較強。這個問法從一開始就歪了，因為它們解決的根本不是同一種缺口。
名詞本身的定義，站上另一篇文章已經處理過，Skill、Prompt 與 MCP 各自回答不同的工作問題。這裡不重做定義，只處理下一步：選擇順序，以及掛在那裡的常駐成本。
| 放法 | 它補的是哪一種缺口 |
|---|---|
| Skill | 這件事該怎麼做的判準與步驟，也就是知識 |
| MCP | 讓 agent 讀得到、動得了外部系統的通道與權限 |
| CLI | 把已經確定的動作壓成一行指令，換取執行效率 |
這張表講的是主要責任歸屬，三者並不互斥。Skill 主要承載判準與流程，也可能附帶腳本；MCP 標準化 agent 與外部系統的互動，實際權限仍要另外設定；CLI 是命令列介面，當它包裝的是已經確定的腳本時，才可能減少重複推理與執行波動。同一個工作流經常同時用到三者。
責任歸屬分清楚之後，實務上的差別就出來了。Skill 記的是「碰到這種狀況，我們家的做法是這樣，這幾個數字要用這個口徑，這種例外要停下來問人」。一個 agent 就算什麼系統都連得上，沒有這份判準它還是會用自己的方式做，每次的方式都不太一樣。
MCP 處理的是agent 與外部系統之間那套標準化的互動方式，讓它讀得到訂單資料、動得了廣告帳號、拿得到會員名單，跟工程師平常在接的 API 是兩種不同的設計目的。
CLI 的價值在於執行確定、波動小，代價是它不做判斷，你叫它做什麼它就做什麼。
於是判準就浮出來了。本文為了讓選型可以討論而提出一組三分法：拿起手上這件重複的事，先問它現在卡住的是知識、通道，還是執行效率。
卡在知識，代表這件事沒有共識，同一份報表三個人做出三種樣子。這種事接再多通道也沒用，接通道只會讓你更快拿到三份不一樣的答案。它該先寫成 skill。
卡在通道，代表大家都知道怎麼做，但資料在別的系統裡，每次都要有人手動下載、貼上、對格式。這種事寫再多劇本也繞不過那道牆，它需要的是 MCP。
卡在執行效率，代表判準有了、通道也有了，只是同樣的動作一週要跑幾十次，每次都讓模型重新想一遍太慢也太貴。這種事該被包成 CLI 指令。
協定正在替「一次掛很多工具」鋪路
上面的判準是靜態的，但 AI 工具這一年變化很快，值得看三件已經發生、而且查得到原始出處的事，因為它們決定了這個判準在未來一年還站不站得住。
MCP 在 2026 年做了最大的一次改版
MCP 官方在 2026 年 5 月 21 日鎖定新版規範的候選版本，經過十週的驗證窗口，於 2026 年 7 月 28 日發布正式版。官方在候選版公告裡的說法是，這是這個協定自問世以來最大的一次改版。
改的內容偏工程，但方向對品牌有意義。正式版公告列出的主要變動有這幾項：
- 協定核心改成請求與回應各自獨立，不再需要一直維持連線。原本比較像講電話，兩邊得先接通、全程佔線；現在比較像寄信，一封一封各自送達。
- 退掉了原本的初始化握手與連線階段的識別碼，改由標頭欄位直接帶路由資訊。這相當於把地址寫在信封外面，中間的收發室不必拆開信件就知道要送去哪一層。
- 清單類的回應開始帶快取時效，同樣的清單不必每次重問一遍。
- 授權那一塊做了強化，並且把擴充機制正式化。
把工程語言翻回商業語言，這一版是在替「一個組織同時掛很多工具、而且要經過中間的閘道器統一管控」這件事鋪路。協定的設計者顯然預期，接下來企業裡的 agent 不會只接兩三個系統。
代價要一起講。既有的連線階段實作要跟上新版就有遷移工作，品牌端在採購時應該直接要求供應商交代支援到哪一版、什麼時候升級、升級期間會不會斷。
這個協定已經不屬於單一家公司了
2025 年 12 月 9 日，MCP 捐給了 Linux 基金會旗下新成立的 Agentic AI Foundation。Linux 基金會的公告顯示，這個基金會由 Anthropic、Block、OpenAI 共同創立，白金會員包含 Amazon Web Services、Bloomberg、Cloudflare、Google、Microsoft。
規模也一併公開了。MCP 官方部落格在同一天說明，這個協定當時已有每月 9,700 萬次的開發套件下載量與 1 萬個活躍的伺服器；Linux 基金會的公告則獨立記載已發布的伺服器超過 1 萬個。官方也把治理界線講得很清楚：做決定的仍然是原本那批維護者，基金會提供中立的家與基礎設施，不會指導技術方向。
對品牌的意義在採購風險這一端。當一個接口標準的治理權不在單一供應商手上、而且主要的雲端與模型廠商都在同一張桌子上，選擇它的鎖定風險就低於每家廠商各給你一套私有接口。
廠商公開了按需載入前後的量測
還有一件事最不像新聞，卻最該被行銷主管看見。Anthropic 在 2025 年 11 月的進階工具使用說明裡，公布了自家系統的量測結果。
除了前面提過的 134,000 個 token，他們還量了另外兩件事。準確率方面，在同一組評測上開啟「先搜尋工具、只載入這次用得到的那幾個」這個機制之後，Opus 4 的表現從 49% 提升到 74%。用量方面，改用程式化的方式呼叫工具之後，複雜研究任務的平均用量降到 27,297 個 token，原本是 43,588 個，減少 37%。
準確率那一組數字比省錢那一組更該停下來看，但也要把話講準。這組結果支持的是「在該測試設定下，按需載入有幫助」，它沒有單獨證明工具數量與錯誤率之間存在普遍且線性的因果關係，因為搜尋步驟本身、工具彼此相似的程度、評測怎麼設計都會影響結果。能說的是：帳單會變厚，agent 在相似選項之間選錯的風險也可能上升。
為什麼工具愈多，答案愈不準
表面上看，接口愈開放愈好，能接的都接起來，反正用不到也不會怎樣。
實際運作起來要看你的系統怎麼設計。在會把全部工具定義預先載入的那種設定裡，每次請求都可能帶著這些定義，占用模型的工作記憶，也就是模型一次能讀進去的文字上限，並且產生輸入 token。清單裡有二十個工具，這一次只用到一個，另外十九份說明書還是跟著一起送。
要不要按原價再付一次，取決於三件事：有沒有做延遲載入、快取命中率高不高、你買的方案怎麼計價。Anthropic 自己也註明核心工具定義可以走快取。所以這筆錢會不會全額重付，別的系統未必跟你一樣，但它是一筆存在的固定開銷這件事不會變。
更麻煩的是注意力被稀釋。模型要在一堆功能相近的選項裡挑出對的那一個，清單愈長，挑錯的機率愈高。這也是為什麼你給 agent 的工作環境，常常比模型本身更決定成效，因為錯誤不會自己舉手。
Anthropic 公開的兩種做法都在處理同一件事：把常駐換成按需取用。
一條叫漸進式揭露。Anthropic 在說明 Agent Skills 設計原則時講得很直接：啟動的時候只把每個 skill 的名稱與描述預先載入，agent 判斷這次用得到，才去把完整的內容讀進來，附帶的檔案再等真的需要時才開。這個設計讓一個團隊可以裝很多 skill，而不必為了沒用到的那些每次付費。
另一種是讓模型寫程式去呼叫工具，而不是每次呼叫都讓結果回到模型面前繞一圈。中間的資料在執行環境裡處理完再回報結論，模型只看到它需要看到的那一段。前面那個從 150,000 壓到 2,000 的示例，走的就是這條路。
token 對應到的是入場費、返工費與機會成本
這一節只算一件事：工具清單造成的增量。訂閱、輸出、重試那些用量成本，訂閱費與用量費屬於不同的計價結構那篇已經處理過，這裡不重複。行銷主管不必懂 token 怎麼計算，只要知道這筆增量對應到哪三種代價。
- 入場費，也就是工具定義的增量成本。算法是每次任務多帶的工具定義 token，乘上任務次數，再乘上適用快取之後的輸入單價。它的特性是掛在那裡不呼叫也要付，而且每次任務都重算一次。要看它有多大，只要把「不常用的那幾個」暫時拿掉，比較前後每次任務的輸入 token 差額就知道。
- 返工費。agent 挑錯工具、拿錯欄位、算錯口徑，人要花時間發現、確認、重跑。這筆錢不會出現在任何一張帳單上，它藏在行銷企劃的加班裡。前面那組 49% 到 74% 只描述特定評測的表現差距，不能直接換算成人力成本；要估自己的返工費，得用團隊自己的錯誤呼叫率、每次平均返工時間與人力單價去乘。
- 機會成本。當團隊的注意力被「這個工具怎麼又壞了」佔滿，就沒有人在想「這個活動的分眾該怎麼切」。工具維護吃掉的是策略時間。
這三種代價合起來看，會得到一個跟直覺相反的結論：控制工具清單的長度，常常比多接一個工具划算。不常用的東西應該收在按需取用那邊，不必常駐。
至於「那乾脆都不要接標準協定，各自寫死接口就好」，這條路要看情況。如果你只有單一穩定系統，而且公司已經有統一的 API 閘道、身分驗證與稽核機制，私有介接的短期成本可能更低。但系統數量一多、或哪天要換供應商，就該回頭比較標準化的收益：MCP 這一版規範花了很多力氣在授權，包含發行者驗證、用中繼資料文件取代動態註冊，還把企業託管授權列為正式擴充。這些東西自己重寫一遍，代價是每個系統各一套認證方式、稽核紀錄散在各處對不起來、換供應商時整套重做。
這些放法都在搬運資料，沒有一個在生產資料
前面談的都是架構選擇，但架構選對了，還有一件事它們誰也解決不了。
Skill 寫的是判準，MCP 開的是通道，CLI 壓的是動作，三個都在處理資料怎麼流動。沒有一個在處理資料本身乾不乾淨。一個通道全開的 agent，如果讀到的會員資料散在官網、門市、客服、廣告帳號各自的表裡，同一個人在四張表上是四個身分，它給出的答案一樣接不起來。資料品質常是 agent 出錯的根源之一，這一點在換模型或換工具之後都不會自己消失。
這也是 91APP CDMP 在這件事裡的位置。它做的不是再多開一條通道，是把散在各處的顧客資料收攏成同一個會員身分：線上線下的消費歸到同一個人身上、標籤與名單的定義只有一套、分群的口徑跨團隊一致。底座統一之後，上面接什麼載體都站得住，因為每一條通道讀到的是同一份事實。
實務上的順序通常是這樣：先把歸戶與標籤口徑收乾淨，再決定哪幾件事寫成 skill、哪幾條資料開 MCP 通道。若在歸戶與口徑還沒對齊之前就大量接工具，常見的風險是不同工具讀到不同版本的會員數；什麼時候會浮上檯面、影響多大，取決於資料同步與治理的現況。
先問這件事缺什麼，再決定它住在哪裡
以下四件事不需要等預算，這個月就可以開始。
- 把清單攤開來分類。請團隊列出每週要做三次以上的重複工作，逐項標上它現在卡在哪：缺知識、缺通道，還是缺執行效率。分類本身就會篩掉一批採購需求，因為高頻、可標準化而且資料拿得到的任務，才比較值得先寫成 skill（預期效果：三個月後回頭比對候選工具數量，確認缺口說不清楚的採購項目已經被移除；建議週期：一次盤點，每季重看）。
- 把有爭議的口徑先寫進 skill 劇本，再開通道。同一份報表三個人做出三種樣子，這件事接了 MCP 之後只會變成三個人更快做出三種樣子。順序是先把口徑定義寫成 skill，讓 agent 每次都照同一套規則做，等產出穩定了再把資料源接上（預期效果：報表口徑爭議變成一次性問題；建議週期：每個口徑爭議發生時就補寫一條）。
- 替新增工具設一道門檻，並指定一個人有權拒絕。門檻不必是一個全公司共用的數字，可以依每類任務的工作記憶預算來訂。要新增一個工具，提案者得交代它服務哪個任務、工具定義大約多大、預估使用率、以及什麼條件下退場（預期效果：清單長度停止單向成長；建議週期：每月看一次使用紀錄）。
- 用「常駐或按需」重看現有清單，判準不要只看次數。除了使用頻率，還要看能不能忍受延遲、工具定義有多大、選錯的後果多嚴重。低頻但緊急的客服或資安工具，不該只因為次數少就丟去延遲載入。至於怎麼分工，廣告工作流同樣要把判準、存取與執行拆開看，那篇整理過實際的組合（預期效果：每次任務的固定開銷下降；建議週期：每季調整一次）。
清單有價格，只是沒人開發票
回到那份沒有人負責砍的清單。它一路變長，往往源於成本從未被換算成可檢查的數字。工具的訂閱費有發票，工具掛在那裡的入場費沒有。
現在這筆錢算得出來了。廠商把量測結果公開，協定往「很多工具、統一管控」的方向改版，治理權也交給了中立的基金會。這些都在說同一件事：接工具已經從技術細節，變成一個要有人負責的架構決定。
清單沒有發票，卻會在每次任務裡留下成本。說不清楚它補的是哪一個缺口，這筆架構帳就還沒有算完。
品牌最常問的 AI 工具選型問題
Q1：Skill、MCP、CLI 用一句話講差在哪？
A1：Skill 是給 agent 的做事劇本，寫的是判準與步驟；MCP 是讓 agent 讀得到、動得了外部系統的通道與權限；CLI 是把已經確定的動作壓成一行指令，換取執行效率與穩定度。三者互補，不是三選一。
Q2：如果只能先做一個，該從哪一個開始？
A2：沒有固定答案，看缺口在哪。缺判準就先整理成 skill；判準已經有了但資料拿不到，先處理 MCP 或其他資料介面；判準與資料都穩定、而且執行頻率高，再評估 CLI。多數行銷團隊盤點完會發現缺判準的比例最高，所以實務上常從 skill 起步，但決定的依據仍然是當前缺口。
Q3：工具掛多了真的會變慢變貴嗎？
A3：會，準確率也可能受影響。在會把全部工具定義預先載入的設定裡，每次任務都帶著整份清單，占用工作記憶也產生輸入 token；實際負擔多大，取決於有沒有做延遲載入、快取命中率與你買的方案怎麼計價。Anthropic 公開的量測顯示，改成只載入當次用得到的工具之後，準確率在同一組評測上由 49% 提升到 74%。那是特定評測設定下的結果，方向可以參考，數值不宜直接套用到自己的環境。
Q4：預算有限的小團隊怎麼開始？
A4：先做零成本的那一步：把每週重複三次以上的工作列成清單，標出各自缺什麼。這一步只需要一個下午。清單出來之後，可能會發現有些工作只需要先統一做法，不必買任何工具；實際比例由盤點結果決定。真的要花錢的部分，也會因為排序清楚而變小。
Q5：CLI 是不是只有工程師才用得上？
A5：指令本身要工程師或熟悉工具的人先包好，但包好之後行銷團隊可以直接使用。實務上的分工通常是行銷提出需要重複執行的動作、技術側包成指令、行銷側日常呼叫。判斷標準是這件事的做法是否已經完全確定，還在調整的事不適合先包成指令。
Q6：換模型或換平台，這些投入會不會白做？
A6：MCP 的開放規格可以降低協定層的綁定，這個協定已由中立的基金會治理，技術方向不由單一供應商決定。但實際移轉成本仍取決於平台支援到哪一版、授權方式、工具規格與自訂擴充；2026 年這一版對既有的連線階段實作本身就有遷移工作。Skill 的移轉成本相對低，因為它記錄的是你們自己的做法與口徑，換平台時內容還在。