作者： @BlazingKevin_ ，資產管理公司Blockbooster研究員

1. Agent Skill 的誕生背景與演進

2025 年的AI Agent 賽道正處於從「技術概念」向「工程落地」跨越的關鍵分水嶺。在這個過程中，Anthropic 關於能力封裝的探索，意外地促成了一次產業級的典範轉移。

2025 年10 月16 日，Anthropic 正式推出了Agent Skill 。起初，官方對此特性的定位表現得極為克制——它僅被視為提升Claude 在特定垂直任務（如複雜程式碼邏輯、特定數據分析）表現的輔助模組。

然而，市場和開發者的回饋遠遠超出預期。大家很快就發現，這套將「能力模組化」的設計在實際工程中展現了極高的解耦性和彈性。它不僅降低了Prompt 調優的冗餘度，也大大提升了Agent 執行特定任務的穩定性。這種體驗，迅速在開發者社群引發了連鎖反應。短時間內，包括VS Code、Codex、Cursor 在內的頭部生產力工具與整合開發環境（IDE）紛紛跟進，陸續完成了對Agent Skill 架構的底層支援。

面對生態的自發性擴張，Anthropic 捕捉了這機制的底層通用價值。 2025 年12 月18 日，Anthropic 做出了一個具有行業里程碑意義的決定：正式將Agent Skill 發佈為開放標準。

緊接著，在2026 年1 月29 日，官方正式發布了Skill 的詳盡使用手冊，從協議層面徹底打通了跨平台、跨產品復用的技術壁壘。 這一系列動作標誌著Agent Skill 已經徹底褪去了「Claude 專屬附屬品」的標籤，正式演變為整個AI Agent 領域中一種通用的底層設計模式。

至此，一個懸念呼之欲出：這個讓大廠與核心開發者紛紛擁抱的Agent Skill，究竟在底層工程上解決了什麼核心痛點？它與目前大熱的MCP之間，又有著怎樣的本質差異與協同關係？

為了徹底釐清這些問題，並最終將其落腳於加密產業投研的實際建置中，本文將層層遞進地展開以下探討：

• 概念解析：Agent Skill 的本質及其基礎架構建構。
• 基礎工作流程：揭示其底層運作邏輯與執行流程。
• 進階機制：深入剖析Reference與Script兩大高階用法。
• 實戰案例：解析Agent Skill 與MCP 的本質差異，並示範在Crypto 投研場景下的組合應用。

2. 什麼是Agent Skill 及其基礎構建

到底什麼是Agent Skill？用最通俗的話來講，它其實就是一份大模型可以隨時翻閱的「專屬說明文件」 。

在日常使用AI 時，我們常常會遇到一個痛點：每次開啟新對話，都要把長長的要求重新貼一遍。而Agent Skill 就是為了解決這個麻煩而生的。

舉個實際的例子：假設你想做一個“智能客服” Agent，你可以在Skill 裡明確寫下規矩：“遇到用戶投訴，第一步必須先安撫情緒，並且絕對不能隨意做出賠償承諾。” 再比如，你經常需要做“會議總結”，你可以直接在Skill 裡定好模版：“每次輸出議版時，必須按照會議參會人員”。

有了這份“說明文檔”，你就不需要每次對話都去重複那一長串的指令了。大模型接到任務時，會自動去翻閱對應的Skill，立刻就知道該用什麼標準來工作。

當然，「說明文檔」只是一個為了方便大家理解的簡化比喻。實際上，Agent Skill 能做的事情遠比單純的格式規格要強大得多，它的那些「殺手級」高級功能我們會在後面的章節詳細拆解。但在起步階段，你完全可以把它當成一個高效率的任務說明書。

接下來，我們就用「會議總結」這個大家最熟悉的場景，來看看究竟該怎麼動手創建一個Agent Skill。整個過程並不需要複雜的程式設計知識。

根據目前主流工具（如Claude Code）的設定，我們需要在電腦的使用者目錄下找到（或新建）一個叫.claude/skill的資料夾，這裡就是存放所有Skill 的「大本營」。

第一步，在這個目錄裡建立一個新資料夾。這個資料夾的名字，就是你這個Agent Skill 的名字。 第二步，在剛剛建造的資料夾裡，建立一個名為skill.md的文字檔案。

每一個Agent Skill 都必須有這麼一個skill.md檔。它的作用就是告訴AI：我是誰，我能做什麼，以及你該怎麼照我的要求工作。打開這個文件，你會發現它清楚地分成了上下兩部分：

在文件的最開頭，通常是被兩段短橫線---包起來的區域。這裡面只寫兩個核心屬性： name和description 。

• name ：就是這個Skill 的名字，必須跟外面的資料夾名字一模一樣。
• description ：這是極為重要的一環。它負責向大模型解釋這個Skill 的具體用途。 AI 在後台會持續掃描所有Skill 的描述，以此來判斷目前使用者的提問到底該用哪一個Skill 來解答。因此，寫一段精準、全面的描述，是確保你的Skill 能被AI 準確喚醒的大前提。

短橫線下方剩下的部分，就是寫給AI 看的具體規則了。官方把這部分叫做「指令」。 這就是你發揮的地方，你要在這裡詳細描述模型需要遵循的邏輯。例如在會議總結的例子裡，你就可以在這裡用大白話規定：「必須提煉出與會者名單、討論的議題以及最終落實的決定」。

把這幾步做完，一個簡單但非常實用的Agent Skill 就誕生了。

不過，一個真正好用的Skill，往往始於周密的前期設計。在鍵盤上敲下第一行字之前，先清楚定義目標、範圍和成功標準，會讓你的建造過程事半功倍。

建構Skill 的第一步，其實不是去想“我能讓AI 搞出什麼花樣”，而是要反問自己：“我到底需要解決日常工作中的什麼重複性問題？ ” 建議一開始先具體定義出2 到3 個這個Skill 應該覆蓋的明確場景。

其次，是定義成功的標準。怎麼知道自己寫出的Skill 好不好用？在動手之前，給它設定幾個能衡量的標準。例如定量的標準可以是“處理速度是否變快了”，定性的標準可以是“它提取的會議決定是不是每次都足夠精準沒有遺漏”。

3. Agent Skill 的基礎運行工作流程

在了解了Agent Skill 的基本面貌後，我們不禁要問：在實際運行中，這套「說明文件」究竟是如何發揮作用的？

如果你最近體驗過像Manus AI 這樣的產品，你大概率經歷過這樣的場景：當你拋出一個特定問題時，AI 並沒有立刻開始「長篇大論」或產生幻覺，而是敏銳地意識到「這件事歸某個特定的Agent Skill 管」。於是，它會在介面上彈出一個提示，詢問你是否允許呼叫該Skill。

當你點擊「同意」後，AI 便像換了一個人一樣，嚴格按照預設的規矩完美輸出結果。

這個看似簡單的「申請-同意-執行」的互動背後，其實隱藏著一套極為精巧的底層運作工作流程。為了徹底講清楚這套機制，我們需要先明確整個流程中參與互動的「三個核心角色」：

1. 使用者：發起任務請求的人。
2. 客戶端工具（如Claude Code 等） ：負責調度和統籌的「中間人」。
3. 大語言模型：負責理解意圖和產生最終結果的「大腦」。

當我們向系統輸入一段需求（例如：「幫我總結一下今天早上的專案例會」）時，這三個角色之間會發生如下的四步驟精密協作：

第一步：輕量級掃描（傳遞元資料）

使用者輸入請求後，客戶端工具（Claude Code）不會一股腦地把所有說明文件都丟給大模型。相反，它只會把使用者的請求，連同目前系統中所有Agent Skill 的「名稱」和「描述」 （也就是我們上一章提到的Metadata 元資料層），打包發送給大模型。 你可以想像一下，就算你安裝了十幾個甚至幾十個Skill，此時大模型拿到的也只是一份「輕量級的目錄」。這種設計極大地節省了模型的注意力，避免了訊息的相互幹擾。

第二步：精準的意圖配對大模型在收到使用者請求和這份「Skill 目錄」後，會進行快速的語意分析。它發現用戶的訴求是“總結會議”，而目錄中恰好有一個名叫“會議總結助手”的Skill，其描述完美契合該任務。 此時，大模型會把這個匹配結果告訴客戶端工具：“我發現這個任務可以用'會議總結助手'來解決。”

第三步：按需載入完整指令得到大模型的回饋後，客戶端工具（Claude Code）才會真正進入「會議總結助手」的專屬資料夾，去讀取那個完整的skill.md正文。請注意，這是一個極其關鍵的設計：只有在此時，完整的指令內容才會被讀取，而且系統只讀取這一個被選中的Skill。其他未被命中的Skill 依然安靜地躺在目錄裡，不會佔用任何資源。

第四步：嚴格執行與輸出回應最後，客戶端工具會將「使用者的原始請求」和「會議總結助理完整的skill.md內容」一起傳送給大模型。 這一次，大模型不再是做選擇題，而是進入了執行模式。它會嚴格遵循skill.md裡所訂下的規則（例如：必須提取與會者、核心議題、最終決定），產生高度結構化的回應，並交由客戶端工具展示給使用者。

4. 核心機制一：按需載入與Reference

上一章的工作流程，引出了Agent Skill 的第一個核心底層機制－按需載入。

雖然所有Skill 的名稱和描述始終對大模型可見，但具體的指令內容，只有在該Skill 被精準命中後，才會被真正拉取到模型的上下文中。

這就大大節省了寶貴的Token 資源。試想一下，即使你同時部署了「爆款文案」、「會議總結」、「鏈上資料分析」等十幾個大體量​​的Skill，模型最初也只需做一次極低消耗的「目錄檢索」。只有在選取目標後，系統才會把那份對應的skill.md餵給模型。這種“按需加載”，就是Agent Skill 保持輕量和高效的第一層密碼。

然而，對於追求極致效率的進階使用者來說，僅僅做到第一層按需載入還不夠。

隨著業務的深入，我們往往希望Skill 變得更加聰明。以「會議總結助手」為例，我們希望它不僅能簡單複述議題，還能提供增量的洞察價值：當會議決定要花錢時，它能直接在總結裡標註是否符合集團的財務合規；當涉及到外部合作時，它能自動提示潛在的法務風險。這樣一來，團隊在看總結時，一眼就能掃到關鍵的合規預警，免去了二次查閱規章制度的繁瑣。

但這在工程上帶來了一個致命矛盾：Skill 要想具備這種能力，前提是必須把冗長的《財務規定》和《法律條文》全都塞進skill.md文件裡。這會導致核心指令檔變得無比臃腫。即使今天開的只是一場純技術的早會，模型也被迫要加載數萬字的財務和法律“廢話”，這不僅造成了Token 的嚴重浪費，還極易引發模型的“注意力渙散”。

那麼，能不能在按需載入的基礎上，再實現一層「按需中的按需」呢？例如，只有當會議內容真真切切聊到了“錢”，系統才把財務規定掏出來給模型看？

答案是肯定的。 Agent Skill 體系中的Reference機制，正是為此而生。

Reference 的本質，是條件觸發的外部知識庫。讓我們來看看它是如何優雅地解決上述的痛點：

1. 建立外部參考文件：首先，我們在該Skill 的目錄下新增一個獨立文件，也就是術語中的Reference。我們將它命名為集团财务手册.md ，裡面詳細列明了各項報銷標準（例如：住宿補貼500 元/晚，餐飲費人均300 元/天等）。
2. 設定觸發條件：接著，回到核心的skill.md檔案中，新增一條專門的「財務提醒規則」。我們可以用自然語言明確約定：“僅在會議內容提及錢、預算、採購、費用等字眼時觸發。觸發後，需讀取集团财务手册.md文件。請根據該文件內容，指出會議決定中的金額是否超標，並明確相應的審批人。”

完成設定後，當我們在下一次會議中複盤預算分配時，一場精妙的動態協作就開始了：

1. 客戶端工具掃描並向你申請使用「會議總結助理」 Skill（完成第一層按需載入）。
2. 模型在閱讀會議記錄時，敏銳地捕捉到了「預算」相關的字眼，立刻觸碰了我們在skill.md中埋下的規則。
3. 此時，系統會向你發起第二次請求：「是否允許讀取集团财务手册.md ？」（完成第二層按需載入：Reference 動態觸發）。
4. 授權通過後，模型將會議內容與動態引入的財務標準進行交叉比對，最終輸出一份不僅包含“參會人員、議題、決定”，更掛載了“財務合規預警”的高質量總結。

請務必記住Reference 的核心特徵：它是嚴格受條件約束的。反過來說，如果今天你們開的是一場探討代碼邏輯的技術複盤會，全場與錢毫無關係，那麼這份集团财务手册.md就會安靜地躺在硬碟裡，絕不會佔用哪怕一個Token 的算力資源。

5. Script與漸進式揭露機制

講完了解決資訊過載的Reference 機制，接下來我們進入Agent Skill 的另一個殺手級能力：程式碼執行（Script） 。

對於一個成熟的Agent 來說，只是「查資料」和「寫總結」是不夠的，能直接上手把活兒乾了，才是真正的自動化閉環。這就是Script 的用武之地。

繼續拿我們的「會議總結助手」舉例。總結寫完後，通常還需要把它同步到公司的內部系統。為了實現這最後一步，我們在Skill 的資料夾裡新建一個Python 腳本，命名為upload.py ，裡面寫好了對接公司伺服器的上傳邏輯。

接著，我們回到核心的skill.md檔案中，追加一條明確的指令：“當用戶提到'上傳'、'同步'或'發送到伺服器'等字眼時，你必須運行upload.py腳本，將生成的總結內容推送到伺服器。”

當你對AI 說：“總結寫得不錯，幫我同步到伺服器。”

客戶端工具會立刻向你申請執行這個upload.py檔。但請注意一個極其關鍵的底層邏輯：在這個過程中，AI 並沒有去「讀取」這串程式碼的內容，它只是去「執行」了它。

這意味著，即使你的Python 腳本裡寫了一萬行極其複雜的業務邏輯，它對大模型上下文的消耗幾乎是零。 AI 就像在使用一個「黑盒子」工具，它只在乎怎麼啟動這個工具，以及最後有沒有成功，至於盒子裡是怎麼運作的，它毫不在意。

這就引出了Reference 和Script 這兩大高階功能在機制上的本質差異：

• Reference（讀）：它是把外部文件的內容「搬」到模型的腦中（上下文）當作參考，因此會消耗Token。
• Script（跑）：它是在外部環境中直接被觸發運行，只要你把運行方法交代清楚，它就不會佔用模型的上下文。

當然，這裡有一個避坑指南：在寫skill.md時，你必須把腳本的觸發條件和執行命令解釋得絕對清楚。如果AI 遇到模糊的指令不知道該怎麼跑，它可能就會“退而求其次”，試圖去偷看代碼內容來尋找線索，這時候你的Token 可就要遭殃了。所以，寫Skill 的鐵律是：盡可能把規則定義得清晰無死角。

講到這裡，我們其實已經把Agent Skill 的所有核心組件拼圖都找齊了。是時候停下來，站在全局視角做個總結了。

如果你仔細回味整個加載過程，你會發現Agent Skill 的設計哲學，其實是一種極為精密的漸進式揭露機制。為了極致地節省算力並保持高效，它的系統被嚴格劃分為了三層，每一層的觸發條件都步步收緊：

• 第一層：元資料層（始終載入）這裡存放著所有Agent Skill 的name和description 。它就像是大模型的“常駐目錄”，極度輕量。大模型每次接單前都會先掃一眼這裡，完成初步的路由配對。
• 第二層：指令層（按需載入）對應skill.md裡的具體規則。只有當第一層確認了任務歸屬，AI 才會「翻開」對應的這一層，把具體的規矩裝進腦子裡。
• 第三層：資源層（按需中的按需載入）這是最深、也是最龐大的一層。它包含了三個核心組件：
  • Reference：如集团财务手册.md ，只有當對話觸發了特定條件（如提到「錢」），才會被讀取。
  • Script：例如upload.py ，只有當需要執行特定動作（如「上傳」），才會被執行。
  • Asset：例如產生研報時需要用到的公司Logo 圖示、專屬字體、特定的PDF 範本等。它們也只在最終生成產物的那一刻才被召喚。

6.Agent Skill 與MCP 的本質區別及組合實戰

聊完了Agent Skill 的高級用法，許多對AI 底層協議有所了解的讀者可能會產生一種強烈的既視感：Agent Skill 的Script 機制，怎麼看都和最近大熱的MCP非常相似。本質上，它們不都是讓大模型去連結和操作外在世界嗎？

既然功能存在重疊，在建構Crypto Research 工作流程時，我們到底該選哪一個？

針對這個問題，Anthropic 官方曾經用一句很經典的話點明了兩者最核心的本質差異：

" MCP connects Claude to data . Skills teach Claude what to do with that data." (MCP 負責將Claude 連接到資料；而Skill 負責教Claude 如何處理這些資料。 )

這句話可謂一語中的。 MCP 本質上是一條「資料管道」 ，它負責標準化地向大模型供給外部資訊（例如查詢某條鏈上的最新區塊高度、拉取交易所的即時K 線、讀取本地的投研PDF）。而Agent Skill 本質上是一套「行為準則（SOP）」 ，它負責規範大模型拿到這些數據後該怎麼幹活（例如規定投研報告必須包含代幣經濟學模型、規定輸出的結論必須帶有風險提示）。

這時可能會有極客提出反駁：“既然Agent Skill 也能跑Python 代碼，我直接在Script 裡寫一段連接數據庫或調用API 的邏輯不就行了嗎？Agent Skill 完全可以把MCP 的活兒一起乾了！”

確實，在工程實作上，Agent Skill 也能去拉取資料。但是極度彆扭且不專業。

這種「不專業」體現在兩個致命維度：

1. 運行機制與狀態保持：Agent Skill 的腳本是「無狀態」的，每次觸發都是獨立的執行，跑完即焚。而MCP 是一個獨立運作的長期服務，它可以保持與外部資料來源的持久化連接（例如下文會提到的WebSocket 長連結），這是單純的腳本根本做不到的。
2. 安全性與穩定性：讓AI 每次都去裸跑一個擁有最高系統權限的Python 腳本，存在極大的安全隱患；而MCP 提供了標準化的隔離環境和鑑權機制。

因此，在建構高階的Crypto Research 體系時，最強大的解法絕不是二選一，而是「MCP 供水，Skill 釀酒」──將兩者強強聯合。

為了讓大家直覺感受到這種組合的威力，我們以Web3 開發者Cryptoxiao 建構的opennews-mcp為例，拆解如何利用API 增強型Skill打造一個全自動的加密新聞情報中心。

這類Skill 的核心邏輯是：將MCP 提供的離散API 能力，透過Skill 的指令編排，封裝成一個面向最終投研目標的智慧Agent。

此體系賦予了AI 四大核心模組能力：

模組一：新聞源發現

這是AI 理解該工具能力邊界的入口。透過discovery.py中的工具，AI 可以動態地了解到它能從哪些管道獲取資訊。

模組二：多維度新聞檢索

這是最核心的查詢模組，由news.py實現，提供了從簡單到複雜的多種新聞檢索方式。

模組三：AI 賦能的分析與洞察

這部分工具利用了6551.io後端已經完成的AI 分析結果，讓AI Agent 可以直接查詢「觀點」而非僅僅是「事實」。

關鍵洞察：AI Agent 在呼叫這些工具時，它並不知道MCP 伺服器在內部執行了「獲取-再過濾」的兩步驟操作。對AI 來說，它只是調用了一個能直接返回「高分新聞」或「利好新聞」的神奇工具，大大簡化了AI 的工作流程。

模組四：即時新聞流

這是opennews-mcp 的「殺手級」能力，由realtime.py實現，賦予了AI 監聽即時事件的能力。

關鍵洞察：這個功能是純Skill 無法實現的，因為它需要維護一個有狀態的、持久的網路連線。只有透過獨立的MCP 伺服器才能做到。

當這些基於MCP 驅動的工具被寫進Agent Skill 的指令流後，你的AI 就正式從一個「通用陪聊助理」蛻變成了一個「華爾街級別的Web3 分析師」。它可以全自動執行以往需要研究員耗費數小時的複雜工作流程：

工作流程範例一：新幣種快速盡職調查(DD)

1. 指令下達：用戶輸入“深度調研一下剛剛上線的@NewCryptoCoin 項目。”
2. 基礎摸底：Agent 自動呼叫opentwitter.get_twitter_user取得官方推特資料。
3. 背書交叉驗證：呼叫opentwitter.get_twitter_kol_followers ，穿透分析有哪些頭部KOL 或VC 已經悄悄關注了這個專案。
4. 全網輿情搜尋：呼叫opennews.search_news_by_coin檢索媒體報道與公關動作。
5. 訊號雜訊比過濾：呼叫opennews.get_high_score_news將無價值的快訊剔除，只精讀高分長文。
6. 輸出研報：Agent 根據Skill 中預設的研報格式，輸出一份包含「基本面、社群籌碼結構、媒體熱度及AI 綜合評等」的標準盡調報告。

工作流程範例二：即時事件驅動的交易訊號發現

1. 指令下達：用戶輸入“幫我全天候盯盤，尋找'零知識證明（ZK）'賽道的突發交易機會。”
2. 部署哨兵：Agent 呼叫opennews.subscribe_latest_news建立WebSocket 長連接，精確監聽內容包含“ZK” 或“Zero-Knowledge Proof” 且關聯具體代幣的新聞流。
3. 捕捉利多：當系統捕捉到某項目（如SomeCoin）在ZK 技術取得突破的高權重利好新聞，且情緒指標判定為Long 時，立刻阻斷休眠。
4. 社群情緒共振測試：Agent 毫秒級調用Twitter 搜尋工具，查閱多位ZK 領域核心KOL 是否在同步發酵該事件。
5. 警報觸發：若符合「媒體首發+社群共振」的條件，Agent 立即向用戶推送高確定性的Alpha 交易警報。

至此，透過Agent Skill 規範行為邏輯，結合MCP 貫通資料大動脈，一套高度自動化、專業化的Crypto Research 工作流程便徹底閉環了。