我拆了4個頂級AI產品的架構，終於搞懂了Agent、Skill、MCP到底怎麼分
整理版優先睇
拆解四個AI產品架構，搞懂Agent、Skill、MCP嘅關係
呢篇文章係作者透過拆解Claude Code、OpenClaw、飛書CLI同Figma AI四個產品嘅底層架構，整理出一套通用嘅Agent產品設計模式，解答咗好多開發者搞唔清Agent、Skill、MCP呢三堆概念嘅困惑。
作者先以餐廳後廚做比喻：Agent係主廚（判斷決策），Skill係菜譜（標準流程），MCP係廚房設備（工具連接）。結論係呢三個概念唔係獨立嘅，而係Agent產品嘅三個必要組成部分，缺咗任何一個都做唔到真正嘅智能體。
然後作者將四個產品嘅共同點提煉成「6層Agent架構模型」：指令層、Agent層、Skill層、MCP層、模型層、守護層。每個產品對唔同層有唔同側重，但本質上都係圍繞「連接工具、編排流程、劃定邊界」嚟設計。最後佢提出三個判斷：AI產品壁壘在於連接同編排而非模型；Agent能力邊界要設計階段就定義好；輸出標準要從提供信息轉向提供可執行嘅行動建議。
- Agent、Skill、MCP係Agent產品嘅三個必要組成，分別對應角色決策、流程執行同工具連接。
- 透過拆解四款產品，歸納出6層Agent架構模型（指令層、Agent層、Skill層、MCP層、模型層、守護層），係設計Agent嘅實用框架。
- Agent同Chatbot最大分別係Agent能調用工具、多步執行同自主決策，唔係一問一答。
- AI產品嘅真正壁壘唔係模型，而係你連接咗咩數據、編排咗咩Skill同MCP。
- 實戰入門路徑：先用Claude Code封裝一個自己嘅Skill（例如寫週報），再接一個MCP（例如Notion或Google Workspace），逐步擴展。
內容結構
CLAUDE.md（指令層：全局規範 + 項目規則 + 目錄級指令，越近越優先） ↓Skills（能力層：/commit、/review、/qa 等可複用工作流） ↓MCP Server（連接層：Notion、Google Workspace、Figma 等外部工具） ↓Hooks（守護層：工具調用前/後自動執行檢查腳本） ↓多模型切換（模型層：Opus / Sonnet / Haiku，按任務複雜度路由）Agent、Skill、MCP——餐廳後廚比喻
作者用一個好直接嘅辦法講清楚三者關係：想像一間餐廳嘅後廚，Agent 等於主廚，佢識得判斷客人講嘅「隨便來點好食嘅」到底要上咩菜；Skill 等於菜譜，例如紅燒肉有標準步驟：焯水→炒糖色→燉四十分鐘；MCP 等於廚房設備，例如焗爐、炒鍋、冰櫃，主廚靠佢哋完成每一道菜。
三者嘅協作係：客人落單後，主廚（Agent）判斷要做咩菜、用邊個菜譜（Skill），過程入面要用咩設備（MCP）就調用咩。同一口炒鍋可以被唔同菜系嘅廚師共用，同一份菜譜可以被唔同廚師複用，主廚嘅價值在於判斷「呢枱客應該上咩菜」。
點解一定要分清呢三個概念？
好多人用AI仲停留喺「問一句答一句」，呢個本質上係用Chatbot，唔係用Agent。Agent 同 Chatbot 嘅核心分別係：Agent可以調工具、多步執行、有決策能力。作者舉例：問ChatGPT「幫我查上個月德國市場銷量」，佢只會話「抱歉我冇你嘅數據」；但如果係Agent，佢會先理解意圖，自動調用銷量數據庫（MCP），按模板整理成報表（Skill），最後俾你一份可直接用嘅分析。
從「能傾偈」到「能開工」，中間差嘅就係Skill同MCP。作者拆咗四個產品，發現佢哋雖然形態唔同，但底層都係做同一件事：連接工具、編排流程、劃定能力邊界。
- Claude Code：最成熟嘅Agent產品，CLAUDE.md分三級指令層，Skills封裝工作流，MCP接入外部工具，Hooks做自動化守護。
- OpenClaw：自己部署嘅Agent框架，用消息網關統一入口，Skills同MCP分工清楚，適合要完全自控嘅場景。
- 飛書CLI：Agent-first Design嘅典範，設計第一用戶係AI Agent而唔係人，API結構化輸出、dry-run預覽、權限自動管理。
- Figma AI Agent：從「俾建議」變成「直接執行」，MCP雙向通信令AI可以喺畫布上操作圖層，Skills嘅質量直接決定輸出。
六層Agent架構模型同三個判斷
將四個產品放埋一齊，作者總結出6層Agent架構模型：第1層指令層（全局規範+場景規則+單次指令，越近越優先）；第2層Agent層（按角色/場景拆分，每個Agent有明確能力邊界）；第3層Skill層（將業務流程封裝成可複用模塊）；第4層MCP層（連接外部工具同數據源，先開放讀操作再開放寫操作）；第5層模型層（多模型路由，按任務複雜度動態選擇唔係用最好而係用最適合）；第6層守護層（自動化質量檢查、Hooks、評分反饋、人工確認）。
- 1 判斷一：AI產品壁壘在於你連接咗咩數據同編排咗咩流程，唔係用邊個模型。
- 2 判斷二：Agent嘅能力邊界必須喺設計階段就定義好，用Skill+MCP保障執行質量，超出邊界嘅明確拒絕或引導到人工。
- 3 判斷三：輸出標準從「提供準確信息」變成「提供可直接執行嘅行動建議」，例如唔係話「代碼有問題」而係「已修復並通過測試」。
最後作者建議入門路徑：先用Claude Code，封裝一個自己每日重複嘅任務做Skill（例如寫週報），再接一個MCP（例如Notion或Google Workspace），寫好CLAUDE.md定義工作規範。進階就可以用OpenClaw喺VPS上自定義Agent。重點係：揾一個真實、高頻、有數據支撐嘅場景，用Agent+Skill+MCP跑通佢。
最近半年，「Agent」呢個詞出現嘅頻率越嚟越高。
OpenAI 講 Agent，Anthropic 講 Agent，Google 講 Agent，飛書都講 Agent。
然後就緊跟住一堆新詞：Skill、MCP、工作流程、多模型路由、工具調用……
我相信好多人嘅狀態同我一開始一樣：每個詞都聽過，但係擺埋一齊就分唔清。
• Agent 同 Chatbot 有咩分別？ • Skill 同 Prompt 有咩分別？ • MCP 到底係乜，點解突然間周圍都係？ • 工作流程同 Agent 又係咩關係？
呢啲問題我都困惑過。後來我做咗一件事：將我每日用緊嘅幾個 AI 產品拆開嚟睇架構。
拆完之後發現，無論係 Claude Code、OpenClaw、飛書 CLI 定 Figma AI，佢哋雖然形態唔同，底層都係做緊同一件事。
搞明咗呢個共同模式，Agent、Skill、MCP 嘅分別自然就清楚曬。
01. 先用一個比喻將三個概念講清楚
喺拆產品之前，先用一個最直接嘅比喻理清關係。
想像一間餐廳廚房嘅運作方式：
• Agent = 大廚（識菜系、曉判斷客人話「隨便整啲好嘢」到底應該上咩菜） • Skill = 食譜（紅燒肉：汆水 → 炒糖色 → 加料 → 燉40分鐘，標準化嘅執行步驟） • MCP = 廚房裏面嘅設備同食材庫（焗爐、炒鑊、雪櫃、調味架——大廚透過呢啲完成每一道菜）
呢三樣嘢嘅關係係：
客人落單之後，大廚（Agent）判斷應該煮咩菜、跟邊個食譜（Skill）嚟做，製作過程中需要用咩設備同食材（MCP）就調用咩。
重點嚟喇：
• 同一隻炒鑊（MCP）可以俾川菜廚師同粵菜廚師（唔同 Agent）共用 • 同一份食譜（Skill）可以俾唔同廚師重用 • 大廚嘅價值唔在於佢識用焗爐，而在於佢曉判斷「呢枱客應該上咩菜」
翻譯做 AI 嘅語言：
| Agent | ||
| Skill | ||
| MCP |
如果你記唔住呢張表，就記住呢一句：
Agent 決定「做咩」，Skill 決定「點樣做」，MCP 決定「用咩工具做」。
02. 點解你一定要分清呢三個概念？
你對呢三個概念嘅理解深度，直接決定咗你能夠將 AI 用到咩程度。
好多人用 AI 嘅方式仲停留喺「問一句答一句」——呢個本質上係用緊 Chatbot，唔係用緊 Agent。
Agent 同 Chatbot 嘅核心分別得一個：
舉個例子：
你問 ChatGPT「幫我查嚇上個月德國市場嘅銷量」，佢只會話「唔好意思我冇你嘅數據」。
但如果係一個 Agent，佢會：
1. 先理解你想查咩（意圖識別） 2. 自動調用銷量數據庫嘅接口（MCP） 3. 攞到數據之後按模板整理成報表（Skill） 4. 畀返一份可以直接用嘅分析結果你
由「識傾偈」到「識做嘢」，中間差嘅就係 Skill 同 MCP。
03. 第一個產品：Claude Code —— 目前最成熟嘅 Agent
我每日都用緊 Claude Code，一開始只當佢係一個寫代碼嘅工具。
後來越用越深，先發現佢本身係目前最成熟嘅 Agent 產品——唔係因為模型勁，而係因為佢嘅 Agent 架構設計得好完整。
將佢嘅架構拆開嚟睇：
CLAUDE.md（指令層：全局規範 + 項目規則 + 目錄級指令，越近越優先）
↓
Skills（能力層：/commit、/review、/qa 等可複用工作流）
↓
MCP Server（連接層：Notion、Google Workspace、Figma 等外部工具）
↓
Hooks（守護層：工具調用前/後自動執行檢查腳本）
↓
多模型切換（模型層：Opus / Sonnet / Haiku，按任務複雜度路由）3.1 CLAUDE.md = 指令分層系統
Claude Code 有一個設計令我印象好深：指令係分層嘅。
佢支援三級 CLAUDE.md 檔案：
• 全域級（~/.claude/CLAUDE.md）：適用於你所有 Project 嘅通用規則 • 項目級（Project 根目錄/CLAUDE.md）：適用於當前 Project 嘅規則 • 目錄級（某個子目錄/CLAUDE.md）：只適用於特定模組嘅規則
越近嘅規則優先級越高。 例如你全域寫咗「用英文註釋」，但某個 Project 嘅 CLAUDE.md 裏面寫咗「用中文註釋」，咁喺呢個 Project 裏面就會用中文。
呢個設計對做 AI 產品嘅啟發係：
Agent 嘅行為規範唔可以一刀切，要分層管理。全域約束管大方向，場景規則管具體行為，單次指令管臨時調整。
3.2 Skills = 工作流程封裝
Claude Code 嘅 Skills 唔係一個簡單嘅 Prompt 模板，而係將一整套業務流程封裝成一個可重用嘅命令。
比如 /review 呢個 Skill，佢唔係「幫我睇嚇代碼」咁簡單。佢背後包含咗：
• 審查邊啲維度（安全、效能、可維護性） • 按咩標準判斷（通過/需修改/拒絕） • 調用咩工具（讀檔案、跑測試、查 diff） • 輸出咩格式（結構化嘅審查報告）
Skill 同 Prompt 嘅分別就喺呢度：
我自己都封裝咗幾個 Skill。例如「文章改寫」——以前每次改文章都要重新講「保持我嘅風格、融入過往案例、優化 SEO」，而家直接一個命令搞掂。
核心價值就一句：將重複嘅提示詞變成可重用嘅工作流程。
3.3 MCP = 令 AI 嘅手可以掂到真實工具
MCP（Model Context Protocol）係 Anthropic 推出嘅一個標準協議，用一句話講：令 AI 可以安全噉調用外部工具同數據。
Claude Code 透過 MCP 接入咗各種外部服務：
• 接 Notion → AI 識讀寫你嘅文檔同數據庫 • 接 Google Workspace → AI 識操作表格同文檔 • 接 Figma → AI 識讀取設計稿甚至操作畫布
MCP 嘅價值唔在於協議本身，而在於佢令 AI 由「只能傾偈」變咗做「識操作真實業務工具」。
我而家搭建嘅工作流程裏面，AI 可以自己去 Notion 裏面揾資料、去 Google Sheets 裏面寫數據、讀取 Figma 設計稿生成代碼。呢啲操作以前都需要我手動做，而家全部係 AI 透過 MCP 自動完成。
3.4 Hooks = 自動化守衞
呢個係 Claude Code 裏面一個容易被忽略但係非常重要嘅設計：Hooks 機制。
你可以配置「喺某個工具調用前/後，自動執行一段腳本」。例如：
• 代碼提交前自動跑格式檢查 • 檔案寫入後自動跑測試 • 任何破壞性操作前彈出確認
呢個俾咗我一個好大嘅啟發：Agent 嘅輸出品質唔可以淨係靠 Prompt 約束，仲需要自動化嘅守衞機制。
淨係話俾 AI 聽「請你仔細檢查」係唔夠嘅，你需要喺流程層面加上自動化嘅「安全網」。
3.5 多模型路由 = 按任務分配資源
Claude Code 支援喺 Opus（最強但最貴）、Sonnet（均衡）、Haiku（最快最平）之間切換。
成本差異好大——Opus 嘅價格可能係 Haiku 嘅 10 倍以上。
但產品設計上做得幾聰明：唔係俾用戶自己揀，而係按任務複雜度動態推薦。 複雜嘅架構設計用 Opus，簡單嘅格式調整用 Haiku。
模型選擇唔係「用最好嘅」，而係「按任務配最合適嘅」。 呢個思路喺做任何 AI 產品時都適用。
04. 第二個產品：OpenClaw —— Agent 運行嘅最小完整框架
OpenClaw 係一個可以自己部署嘅 Agent 框架。我喺一部 68 蚊/年嘅阿里雲 VPS 上面運行咗，接咗飛書消息通道同瀏覽器自動化。
如果話 Claude Code 係一個成熟嘅 Agent 產品，咁 OpenClaw 就係一個俾你自己搭建 Agent 嘅框架。
佢嘅架構好清晰，三層：
消息入口層：飛書 / / / Web（統一消息網關）
↓
AI Agent 運行層：模型路由 + Skill/MCP 調用編排
↓
工具執行層：瀏覽器自動化 / 定時任務 / API 調用 / 網頁抓取4.1 消息網關 = 將所有入口統一
OpenClaw 最令我印象深刻嘅設計係：佢先解決嘅唔係「AI 點樣回答」，而係「用戶從邊度嚟」。
你可以同時接飛書同 Discord。用戶喺飛書羣組 @ 機械人，同喺 Discord 裏面私訊機械人，背後調用嘅係同一套 Agent 能力。
呢個設計喺企業場景裏面特別有價值——唔同團隊可能用唔同嘅溝通工具，但 Agent 嘅能力只需要建設一套。
4.2 Skills 同 MCP 喺 OpenClaw 裏面嘅關係
OpenClaw 將 Skills 同 MCP 嘅分工講得好清楚：
• Skills = 可直接重用嘅細能力包（瀏覽器抓取、內容生成、定時任務等） • MCP = 連接外部系統嘅協議層（飛書 API、數據庫等）
兩者組合使用：一個 Skill 內部可能會調用多個 MCP 工具嚟完成任務。
例如「幫我總結今日羣組傾咗啲乜」呢個任務：
• Skill（流程編排）：讀取消息 → 篩選時間範圍 → 摘要生成 → 格式化輸出 • MCP（工具連接）：調用飛書 API 拉羣組消息
Skill 定義咗「做咩、點樣做」，MCP 解決咗「點樣連、點樣拎數據」。
4.3 對比 Claude Code：通用框架 vs 成熟產品
但係佢哋驗證咗同一件事：Agent 嘅價值唔在於模型本身，在於你連接咗咩工具、編排咗咩流程。
05. 第三個產品：飛書 CLI —— Agent-first Design 嘅典型
飛書官方出咗個 CLI 工具（lark-cli），6 日攞咗 5000 star，200+ 命令，19 個 AI 技能包。
我之前寫過一篇詳細嘅實測文章。今次轉個角度，從架構層面講嚇點解佢值得關注。
5.1 一個顛覆認知嘅設計哲學
lark-cli 最令我意外嘅唔係佢有幾多命令，而係佢嘅設計哲學：
呢個工具唔係俾人用嘅，係俾 AI Agent 用嘅。
安裝嘅時候佢會自動掃描你電腦上嘅 AI 工具——Claude Code、Cursor、Windsurf、Codex 等——然後將 19 個技能包自動注入到曬所有呢啲工具裏面。
你唔需要記任何命令。裝完之後同 Claude Code 講「幫我睇嚇今日有咩會議」，AI 自己就會調用飛書嘅日曆 API 查詢。
呢個意味住咩？意味住工具設計嘅「第一用戶」正喺度由人變成 AI Agent。
5.2 Agent-friendly 嘅 API 設計
lark-cli 嘅命令設計天生對 Agent 友好：
• 結構化輸入/輸出：唔係自由文本，而係明確嘅參數同 JSON 回傳 • dry-run 預覽：執行前先預覽結果，Agent 確認之後先真正執行 • 權限自動管理：安裝時自動申請合理權限，唔需要人工配置 • 安全掃描：每個 Skill 都有獨立嘅安全評分
我測試嘅時候，同 Claude Code 講咗一句「幫我俾某個羣組發條訊息」，AI 自己做咗三件事：
1. 搜尋羣組名揾到目標羣組 2. 用 dry-run 預覽要發嘅內容 3. 確認之後發出訊息
全程我冇查過文檔，冇手動拼過參數。
5.3 呢個對我哋做產品嘅啟發
如果你喺度做企業內部系統，或者做任何會被 AI Agent 調用嘅工具，lark-cli 嘅設計思路值得參考：
1. API 嘅第一用戶可能唔再係人，而係 AI Agent — 接口設計要對 Agent 友好 2. 結構化 > 自由文本 — Agent 需要明確嘅輸入格式同輸出格式 3. 支援預覽同確認 — 俾 Agent 一個「試咗先再正式執行」嘅能力 4. 權限要明確 — Agent 調用時需要知道自己可以做咩、唔可以做咩
我將呢個趨勢總結為 Agent-first Design——未來越嚟越多嘅工具，設計時要優先考慮 AI Agent 點樣調用，其次先係人點樣操作。
06. 第四個產品：Figma AI Agent —— 由「輔助」到「執行」
Figma 最近推出咗 AI Agents on Canvas。呢個更新嘅力度比我預想中大好多。
6.1 之前 vs 而家
底層係透過 MCP 協議實現 AI 同 Figma 嘅雙向通訊——AI 調用嘅係 Figma 嘅操作 API，唔係生成圖片貼上去，而係真係喺度操控圖層。
6.2 Skills 決定一切
Figma AI Agent 好唔好用，好大程度上取決於你嘅 Skills 寫得好唔好。
Skills 喺呢度係一個 Markdown 檔案，本質上係俾 AI 嘅「設計規則說明書」。你喺裏面寫清楚：用咩顏色、用邊啲元件、間距點樣定義、按鈕圓角幾多，AI 就會跟住嚟做。
唔寫 Skills，AI 就係亂咁估。寫好 Skills，AI 先至可以真正用你嘅設計系統生成一致嘅設計。
呢個經驗同所有 Agent 產品都相通：
Agent 嘅輸出品質 = 模型能力 × Skills 嘅品質。 模型係公共品，大家用嘅都差唔多。真正拉開差距嘅係 Skills——即係你將業務知識、流程規範、品質標準封裝得幾好。
6.3 MCP 嘅價值唔止「讀」，更在於「寫」
之前 AI 同 Figma 嘅整合，基本上係單向嘅——AI 讀取設計稿，然後喺外面生成代碼。
而家透過 MCP，變成咗雙向嘅——AI 唔止識讀，仲識寫入 Figma。呢個意味住 AI 由「參謀」變咗做「執行者」。
呢個係 AI 產品化嘅一個重要趨勢：由「提供建議」到「直接執行」。
07. 拆完四個產品，我發現咗同一套底層模式
將 Claude Code、OpenClaw、飛書 CLI、Figma AI 擺埋一齊睇，佢哋雖然產品形態完全唔同，但底層架構驚人地一致。
我將佢總結為 6 層 Agent 架構模型：
┌──────────────────────────────────────────┐
│ 第1層：指令層 │
│ 全局規範 + 場景規則 + 單次指令 │
│ 越近越優先，分層覆蓋 │
├──────────────────────────────────────────┤
│ 第2層：Agent 層 │
│ 按角色/場景拆分 │
│ 每個 Agent 有明確的能力邊界 │
├──────────────────────────────────────────┤
│ 第3層：Skill 層 │
│ 把業務流程封裝成可複用的標準化模塊 │
│ 一個 Skill 可以被多個 Agent 調用 │
├──────────────────────────────────────────┤
│ 第4層：MCP 層 │
│ 連接外部工具和數據源 │
│ 先開放讀操作，再開放寫操作 │
├──────────────────────────────────────────┤
│ 第5層：模型層 │
│ 多模型路由，按任務複雜度動態選擇 │
│ 不是用最好的，是用最合適的 │
├──────────────────────────────────────────┤
│ 第6層：守護層 │
│ 自動化質量檢查 │
│ Hooks / 評分反饋 / 人工確認 │
└──────────────────────────────────────────┘每個產品對呢 6 層嘅側重點唔同：
| Claude Code | ||
| OpenClaw | ||
| 飛書 CLI | ||
| Figma AI |
但 6 層都唔可以少。 缺咗指令層，Agent 唔知道要遵守咩規則；缺咗 Skill 層，Agent 只識傾偈唔識做嘢；缺咗 MCP 層，Agent 嘅手掂唔到真實數據；缺咗守衞層，Agent 嘅輸出品質冇保證。
08. 一張圖講清楚 Agent、Skill、MCP 嘅關係
驚你頭先睇完仲係有啲模糊，用一個具體場景將三者串埋一齊：
場景：用戶問「幫我查嚇 A 產品喺德國市場上個月嘅銷量，順便生成一段促銷文案」
用戶發出請求
↓
Agent（產品方案專家）接收後判斷：
"這裏有兩個任務——一個是數據查詢，一個是內容生成"
↓
任務1：調用 Skill「銷量查詢」
├── 步驟1：解析意圖 → 產品A、德國、上個月
├── 步驟2：調用 MCP → 連接銷量數據庫，查詢結果
├── 步驟3：調用 MCP → 連接庫存數據庫，補充庫存信息
└── 步驟4：按模板格式化數據
↓
任務2：調用 Skill「促銷文案生成」
├── 步驟1：把任務1的銷量數據作為上下文注入
├── 步驟2：調用 MCP → 檢索產品知識庫，獲取賣點信息
└── 步驟3：按促銷文案模板生成輸出
↓
Agent 組裝兩個任務的結果，返回給用戶三者各自嘅角色：
• Agent 做咗判斷同編排——識別出兩個任務，決定先查後寫，最後組裝結果 • Skill 做咗執行——每個任務有標準化嘅步驟 • MCP 做咗連接——實際去查數據庫、檢索知識庫
如果冇 Agent：用戶要自己將任務拆開，分別去兩個系統操作
如果冇 Skill：Agent 每次都要重新「諗」點樣做，輸出唔穩定
如果冇 MCP：Agent 只能編故仔，冇辦法查到真實數據
09. 三個我越嚟越確信嘅判斷
拆完呢四個產品，加上自己實際搭建 Agent 工作流程嘅經驗，有三個判斷越嚟越清晰：
判斷一：AI 產品嘅壁壘唔在於模型，在於連接同編排
模型係公共品——GPT、Claude、Gemini，大家都用到。
但你嘅 Milvus 向量庫裏面有咩數據、你嘅 Skill 編排咗咩業務流程、你嘅 MCP 連接咗邊啲內部系統——呢啲嘢人哋複製唔到。
一個只用通用模型嘅 Chatbot，同一個接咗內部數據庫 + 知識庫 + 業務 API 嘅 Agent，解決問題嘅能力完全唔同層次。
判斷二：Agent 嘅能力邊界必須喺設計階段就定義
好多人做 AI 產品嘅思路係：先上一個通用模型，俾用戶隨便問，睇嚇答唔答得啱。
呢個思路嘅問題係：模型乜都「答」到，但唔係乜都「答得啱」。
更好嘅方式係：
1. 先定義 Agent 可以做咩、唔可以做咩（能力邊界） 2. 對於做得嘅，用 Skill + MCP 保障執行品質 3. 對於做唔到嘅，明確拒絕或引導去人工 4. 對於唔肯定嘅，標註置信度或者加人工確認
Claude Code 嘅 Hooks、Figma AI 嘅 Skills 規範、OpenClaw 嘅權限系統，本質上都係做緊同一件事：劃定 Agent 嘅能力邊界，等佢喺邊界內做到最好，而唔係喺邊界外亂噏。
判斷三：由「提供資訊」到「提供可執行嘅行動建議」
以前 AI 產品嘅輸出標準係「回答準確」。
而家頂級 Agent 產品嘅輸出標準已經變咗——唔係俾你一個準確嘅知識點，而係俾你一個可以直接拎去用嘅嘢。
• 唔係「呢兩個產品嘅參數如下」，而係「面對客嘅時候你可以噉樣講」 • 唔係「翻譯結果如下」，而係「已經按品牌規範翻譯並通過術語檢查」 • 唔係「代碼有呢啲問題」，而係「已經修復並通過測試」
由「提供資訊」到「提供可直接執行嘅行動建議」——呢個係 AI 產品輸出標準嘅根本轉變。
10. 如果你想自己搭一個 Agent 工作流程
睇完呢啲，如果你都想動手試嚇，我嘅建議係由最簡單嘅開始：
入門路徑：Claude Code + Skills + MCP
1. 先裝 Claude Code，用咗先講 2. 封裝一個你自己嘅 Skill——揾一個你每日重複做嘅任務（寫週報、整理筆記、審查文檔），將流程封裝成一個 Skill 3. 接一個 MCP Server——Notion、Google Workspace 都有現成嘅 MCP，接咗之後 AI 就可以操作你嘅文檔同表格 4. 寫好 CLAUDE.md——將你嘅工作規範、偏好、常用術語寫入去，等 AI 按照你嘅標準嚟
進階路徑：OpenClaw + 自訂 Agent
如果你想完全自己控制 Agent 嘅行為：
1. 租一部最平嘅 VPS（我用嘅 68/年嘅阿里雲） 2. 裝 OpenClaw 3. 接消息通道 4. 配置模型同 Skills 5. 逐步擴展 MCP 工具
無論行邊條路徑，核心都係同一件事：
揾到一個真實嘅、高頻嘅、有數據支撐嘅場景，用 Agent + Skill + MCP 跑通佢。
最後
返到開頭嘅問題：Agent、Skill、MCP 到底點樣分？
答案好簡單：
• Agent = 邊個嚟做（角色 + 判斷 + 決策） • Skill = 做咩（流程 + 步驟 + 標準） • MCP = 用咩做（工具 + 數據 + 連接）
呢三個概念唔係三個獨立嘅嘢，而係 Agent 產品嘅三個必要組成部分。
缺咗任何一個，Agent 一係唔知道應該做咩（缺 Skill），一係做唔到真正嘅嘢（缺 MCP），一係冇判斷能力淨係識機械式執行（缺 Agent 嘅決策能力）。
搞明咗呢個，你再睇任何 AI Agent 產品，都可以快速見到佢嘅架構喺邊、長板喺邊、短板喺邊。
呢個比記住一堆術語有用得多。
最近半年，"Agent"這個詞出現的頻率越來越高。
OpenAI 在講 Agent，Anthropic 在講 Agent，Google 在講 Agent，飛書也在講 Agent。
然後緊跟着就是一堆新詞：Skill、MCP、工作流、多模型路由、工具調用……
我相信很多人的狀態和我一開始一樣：每個詞都聽過，但湊到一起就分不清了。
• Agent 和 Chatbot 有什麼區別？ • Skill 和 Prompt 有什麼區別？ • MCP 到底是什麼，為什麼突然到處都是？ • 工作流和 Agent 又是什麼關係？
這些問題我也困惑過。後來我做了一件事：把我每天在用的幾個 AI 產品拆開看架構。
拆完之後發現，不管是 Claude Code、OpenClaw、飛書 CLI 還是 Figma AI，它們雖然形態不同，底層都在做同一件事。
搞懂了這個共同模式，Agent、Skill、MCP 的區別自然就清楚了。
01. 先用一個比方把三個概念講清楚
在拆產品之前，先用一個最直觀的比方把關係理清。
想象一個餐廳後廚的運作方式：
• Agent = 主廚（懂菜系、能判斷客人點的"隨便來點好吃的"到底該上什麼菜） • Skill = 菜譜（紅燒肉：焯水 → 炒糖色 → 加料 → 燉40分鐘，標準化的執行步驟） • MCP = 廚房裏的設備和食材庫（烤箱、炒鍋、冰櫃、調料架——主廚通過這些完成每一道菜）
這三者的關係是：
客人下單後，主廚（Agent）判斷該做什麼菜、按哪個菜譜（Skill）來做，做的過程中需要用什麼設備和食材（MCP）就調用什麼。
重點來了：
• 同一口炒鍋（MCP）可以被川菜廚師和粵菜廚師（不同 Agent）共用 • 同一份菜譜（Skill）可以被不同廚師複用 • 主廚的價值不在於他會用烤箱，而在於他能判斷"這桌客人該上什麼菜"
翻譯成 AI 的語言：
| Agent | ||
| Skill | ||
| MCP |
如果你記不住這張表，就記住這一句：
Agent 決定"做什麼"，Skill 決定"怎麼做"，MCP 決定"用什麼工具做"。
02. 為什麼你一定要分清這三個概念？
你對這三個概念的理解深度，直接決定了你能把 AI 用到什麼程度。
很多人用 AI 的方式還停留在"問一句答一句"——這本質上是在用 Chatbot，不是在用 Agent。
Agent 和 Chatbot 的核心區別只有一個：
舉個例子：
你問 ChatGPT"幫我查一下上個月德國市場的銷量"，它只能說"抱歉我沒有你的數據"。
但如果是一個 Agent，它會：
1. 先理解你要查什麼（意圖識別） 2. 自動調用銷量數據庫的接口（MCP） 3. 拿到數據後按模板整理成報表（Skill） 4. 返回給你一份可以直接用的分析結果
從"能聊天"到"能幹活"，中間差的就是 Skill 和 MCP。
03. 第一個產品：Claude Code —— 目前最成熟的 Agent
我每天都在用 Claude Code，一開始只當它是個寫代碼的工具。
後來越用越深，才發現它本身就是目前最成熟的 Agent 產品——不是因為模型強，而是因為它的 Agent 架構設計得非常完整。
把它的架構拆開看：
CLAUDE.md（指令層：全局規範 + 項目規則 + 目錄級指令，越近越優先）
↓
Skills（能力層：/commit、/review、/qa 等可複用工作流）
↓
MCP Server（連接層：Notion、Google Workspace、Figma 等外部工具）
↓
Hooks（守護層：工具調用前/後自動執行檢查腳本）
↓
多模型切換（模型層：Opus / Sonnet / Haiku，按任務複雜度路由）3.1 CLAUDE.md = 指令分層系統
Claude Code 有一個設計讓我印象很深：指令是分層的。
它支持三級 CLAUDE.md 文件：
• 全局級（~/.claude/CLAUDE.md）：適用於你所有項目的通用規則 • 項目級（項目根目錄/CLAUDE.md）：適用於當前項目的規則 • 目錄級（某個子目錄/CLAUDE.md）：只適用於特定模塊的規則
越近的規則優先級越高。 比如你全局寫了"用英文註釋"，但某個項目的 CLAUDE.md 裏寫了"用中文註釋"，那在這個項目裏就會用中文。
這個設計對做 AI 產品的啓發是：
Agent 的行為規範不能一刀切，要分層管理。全局約束管大方向，場景規則管具體行為，單次指令管臨時調整。
3.2 Skills = 工作流封裝
Claude Code 的 Skills 不是一個簡單的 Prompt 模板，而是把一整套業務流程封裝成一個可複用的命令。
比如 /review 這個 Skill，它不是"幫我看看代碼"這麼簡單。它背後包含了：
• 審查哪些維度（安全、性能、可維護性） • 按什麼標準判斷（通過/需修改/拒絕） • 調用什麼工具（讀文件、跑測試、查 diff） • 輸出什麼格式（結構化的審查報告）
Skill 和 Prompt 的區別就在這裏：
我自己也封裝了好幾個 Skill。比如"文章改寫"——以前每次改文章都要重新說"保持我的風格、融入過往案例、優化 SEO"，現在直接一個命令搞定。
核心價值就一句話：把重複的提示詞變成可複用的工作流。
3.3 MCP = 讓 AI 的手能夠到真實工具
MCP（Model Context Protocol）是 Anthropic 推出的一個標準協議，用一句話說：讓 AI 能安全地調用外部工具和數據。
Claude Code 通過 MCP 接入了各種外部服務：
• 接 Notion → AI 能讀寫你的文檔和數據庫 • 接 Google Workspace → AI 能操作表格和文檔 • 接 Figma → AI 能讀取設計稿甚至操作畫布
MCP 的價值不在協議本身，而在於它讓 AI 從"只能聊天"變成了"能操作真實業務工具"。
我現在搭的工作流裏，AI 可以自己去 Notion 裏查資料、往 Google Sheets 裏寫數據、讀取 Figma 設計稿生成代碼。這些操作以前都需要我手動做，現在全部是 AI 通過 MCP 自動完成的。
3.4 Hooks = 自動化守護
這是 Claude Code 裏一個容易被忽略但非常重要的設計：Hooks 機制。
你可以配置"在某個工具調用前/後，自動執行一段腳本"。比如：
• 代碼提交前自動跑格式檢查 • 文件寫入後自動跑測試 • 任何破壞性操作前彈出確認
這給了我一個很大的啓發：Agent 的輸出質量不能只靠 Prompt 約束，還需要自動化的守護機制。
光告訴 AI"請你仔細檢查"是不夠的，你需要在流程層面加上自動化的"安全網"。
3.5 多模型路由 = 按任務分配資源
Claude Code 支持在 Opus（最強但最貴）、Sonnet（均衡）、Haiku（最快最便宜）之間切換。
成本差異巨大——Opus 的價格可能是 Haiku 的 10 倍以上。
但產品設計上做得很聰明：不是讓用戶自己選，而是按任務複雜度動態推薦。 複雜的架構設計用 Opus，簡單的格式調整用 Haiku。
模型選擇不是"用最好的"，而是"按任務匹配最合適的"。 這個思路在做任何 AI 產品時都適用。
04. 第二個產品：OpenClaw —— Agent 運行的最小完整框架
OpenClaw 是一個可以自己部署的 Agent 框架。我在一台 68 塊錢/年的阿里雲 VPS 上跑起來了，接了飛書消息通道和瀏覽器自動化。
如果說 Claude Code 是一個成熟的 Agent 產品，那 OpenClaw 就是一個讓你自己搭 Agent 的框架。
它的架構非常清晰，三層：
消息入口層：飛書 / / / Web（統一消息網關）
↓
AI Agent 運行層：模型路由 + Skill/MCP 調用編排
↓
工具執行層：瀏覽器自動化 / 定時任務 / API 調用 / 網頁抓取4.1 消息網關 = 把所有入口統一
OpenClaw 最讓我印象深刻的設計是：它先解決的不是"AI 怎麼回答"，而是"用戶從哪裏來"。
你可以同時接飛書和 /。用戶在飛書羣裏 @ 機器人，和在 / 裏私聊機器人，背後調用的是同一套 Agent 能力。
這個設計在企業場景裏特別有價值——不同團隊可能用不同的溝通工具，但 Agent 的能力只需要建設一套。
4.2 Skills 和 MCP 在 OpenClaw 裏的關係
OpenClaw 把 Skills 和 MCP 的分工講得很清楚：
• Skills = 可直接複用的小能力包（瀏覽器抓取、內容生成、定時任務等） • MCP = 連接外部系統的協議層（飛書 API、數據庫等）
兩者組合使用：一個 Skill 內部可能調用多個 MCP 工具來完成任務。
比如"幫我總結今天羣裏聊了什麼"這個任務：
• Skill（流程編排）：讀取消息 → 篩選時間範圍 → 摘要生成 → 格式化輸出 • MCP（工具連接）：調用飛書 API 拉羣消息
Skill 定義了"做什麼、怎麼做"，MCP 解決了"怎麼連、怎麼拿數據"。
4.3 對比 Claude Code：通用框架 vs 成熟產品
但它們驗證了同一件事：Agent 的價值不在模型本身，在於你連接了什麼工具、編排了什麼流程。
05. 第三個產品：飛書 CLI —— Agent-first Design 的典型
飛書官方出了個 CLI 工具（lark-cli），6 天拿了 5000 star，200+ 命令，19 個 AI 技能包。
我之前寫過一篇詳細的實測文章。這次換個角度，從架構層面聊聊它為什麼值得關注。
5.1 一個顛覆認知的設計哲學
lark-cli 最讓我意外的不是它有多少命令，而是它的設計哲學：
這個工具不是給人用的，是給 AI Agent 用的。
安裝的時候它會自動掃描你電腦上的 AI 工具——Claude Code、Cursor、Windsurf、Codex 等——然後把 19 個技能包自動注入到所有這些工具裏。
你不需要記任何命令。裝完之後跟 Claude Code 說"幫我查今天有什麼會議"，AI 自己就會調用飛書的日曆 API 查詢。
這意味着什麼？意味着工具設計的"第一用戶"正在從人變成 AI Agent。
5.2 Agent-friendly 的 API 設計
lark-cli 的命令設計天然對 Agent 友好：
• 結構化輸入/輸出：不是自由文本，而是明確的參數和 JSON 返回 • dry-run 預覽：執行前先預覽結果，Agent 確認後再真正執行 • 權限自動管理：安裝時自動申請合理權限，不需要人工配置 • 安全掃描：每個 Skill 都有獨立的安全評分
我測試的時候，跟 Claude Code 說了一句"幫我給某個羣發條消息"，AI 自己做了三件事：
1. 搜索羣名找到目標羣 2. 用 dry-run 預覽要發的內容 3. 確認後發出消息
全程我沒查過文檔，沒手動拼過參數。
5.3 這對我們做產品的啓發
如果你在做企業內部系統，或者做任何會被 AI Agent 調用的工具，lark-cli 的設計思路值得參考：
1. API 的第一用戶可能不再是人，而是 AI Agent — 接口設計要對 Agent 友好 2. 結構化 > 自由文本 — Agent 需要明確的輸入格式和輸出格式 3. 支持預覽和確認 — 給 Agent 一個"試一試再正式執行"的能力 4. 權限要明確 — Agent 調用時需要知道自己能做什麼、不能做什麼
我把這個趨勢總結為 Agent-first Design——未來越來越多的工具，設計時要優先考慮 AI Agent 怎麼調用，其次才是人怎麼操作。
06. 第四個產品：Figma AI Agent —— 從"輔助"到"執行"
Figma 最近推出了 AI Agents on Canvas。這個更新的力度比我預想的大很多。
6.1 之前 vs 現在
底層是通過 MCP 協議實現 AI 和 Figma 的雙向通信——AI 調用的是 Figma 的操作 API，不是生成圖片貼進去，而是真的在操控圖層。
6.2 Skills 決定一切
Figma AI Agent 好不好用，很大程度上取決於你的 Skills 寫得好不好。
Skills 在這裏是一個 Markdown 文件，本質上是給 AI 的"設計規則說明書"。你在裏面寫清楚：用什麼顏色、用哪些組件、間距怎麼定義、按鈕圓角多少，AI 就會照着來做。
不寫 Skills，AI 就是在亂猜。寫好 Skills，AI 才能真正用你的設計系統生成一致的設計。
這個經驗跟所有 Agent 產品都相通：
Agent 的輸出質量 = 模型能力 × Skills 的質量。 模型是公共品，大家用的都差不多。真正拉開差距的是 Skills——也就是你把業務知識、流程規範、質量標準封裝得多好。
6.3 MCP 的價值不只是"讀"，更在於"寫"
之前 AI 和 Figma 的集成，基本上是單向的——AI 讀取設計稿，然後在外面生成代碼。
現在通過 MCP，變成了雙向的——AI 不僅能讀，還能往 Figma 裏寫。這意味着 AI 從"參謀"變成了"執行者"。
這是 AI 產品化的一個重要趨勢：從"提供建議"到"直接執行"。
07. 拆完四個產品，我發現了同一套底層模式
把 Claude Code、OpenClaw、飛書 CLI、Figma AI 放在一起看，它們雖然產品形態完全不同，但底層架構驚人地一致。
我把它總結為 6 層 Agent 架構模型：
┌──────────────────────────────────────────┐
│ 第1層：指令層 │
│ 全局規範 + 場景規則 + 單次指令 │
│ 越近越優先，分層覆蓋 │
├──────────────────────────────────────────┤
│ 第2層：Agent 層 │
│ 按角色/場景拆分 │
│ 每個 Agent 有明確的能力邊界 │
├──────────────────────────────────────────┤
│ 第3層：Skill 層 │
│ 把業務流程封裝成可複用的標準化模塊 │
│ 一個 Skill 可以被多個 Agent 調用 │
├──────────────────────────────────────────┤
│ 第4層：MCP 層 │
│ 連接外部工具和數據源 │
│ 先開放讀操作，再開放寫操作 │
├──────────────────────────────────────────┤
│ 第5層：模型層 │
│ 多模型路由，按任務複雜度動態選擇 │
│ 不是用最好的，是用最合適的 │
├──────────────────────────────────────────┤
│ 第6層：守護層 │
│ 自動化質量檢查 │
│ Hooks / 評分反饋 / 人工確認 │
└──────────────────────────────────────────┘每個產品對這 6 層的側重點不同：
| Claude Code | ||
| OpenClaw | ||
| 飛書 CLI | ||
| Figma AI |
但 6 層都不可少。 缺了指令層，Agent 不知道該遵守什麼規則；缺了 Skill 層，Agent 只能閒聊不能幹活；缺了 MCP 層，Agent 的手夠不到真實數據；缺了守護層，Agent 的輸出質量無法保證。
08. 一張圖講清楚 Agent、Skill、MCP 的關係
怕你前面看完還是有點模糊，用一個具體場景把三者串起來：
場景：用戶問"幫我查一下 A 產品在德國市場上個月的銷量，順便生成一段促銷文案"
用戶發出請求
↓
Agent（產品方案專家）接收後判斷：
"這裏有兩個任務——一個是數據查詢，一個是內容生成"
↓
任務1：調用 Skill「銷量查詢」
├── 步驟1：解析意圖 → 產品A、德國、上個月
├── 步驟2：調用 MCP → 連接銷量數據庫，查詢結果
├── 步驟3：調用 MCP → 連接庫存數據庫，補充庫存信息
└── 步驟4：按模板格式化數據
↓
任務2：調用 Skill「促銷文案生成」
├── 步驟1：把任務1的銷量數據作為上下文注入
├── 步驟2：調用 MCP → 檢索產品知識庫，獲取賣點信息
└── 步驟3：按促銷文案模板生成輸出
↓
Agent 組裝兩個任務的結果，返回給用戶三者各自的角色：
• Agent 做了判斷和編排——識別出兩個任務，決定先查後寫，最後組裝結果 • Skill 做了執行——每個任務有標準化的步驟 • MCP 做了連接——實際去查數據庫、檢索知識庫
如果沒有 Agent：用戶得自己把任務拆開，分別去兩個系統操作
如果沒有 Skill：Agent 每次都要重新"想"怎麼做，輸出不穩定
如果沒有 MCP：Agent 只能編故事，沒法查到真實數據
09. 三個我越來越確信的判斷
拆完這四個產品，加上自己實際搭 Agent 工作流的經驗，有三個判斷越來越清晰：
判斷一：AI 產品的壁壘不在模型，在於連接和編排
模型是公共品——GPT、Claude、Gemini，大家都能用。
但你的 Milvus 向量庫裏有什麼數據、你的 Skill 編排了什麼業務流程、你的 MCP 連接了哪些內部系統——這些別人複製不了。
一個只用通用模型的 Chatbot，和一個接了內部數據庫 + 知識庫 + 業務 API 的 Agent，解決問題的能力完全不在一個量級。
判斷二：Agent 的能力邊界必須在設計階段就定義
很多人做 AI 產品的思路是：先上一個通用模型，讓用戶隨便問，看看能不能答對。
這個思路的問題是：模型什麼都能"答"，但不是什麼都能"答對"。
更好的方式是：
1. 先定義 Agent 能做什麼、不能做什麼（能力邊界） 2. 對於能做的，用 Skill + MCP 保障執行質量 3. 對於不能做的，明確拒絕或引導到人工 4. 對於不確定的，標註置信度或加人工確認
Claude Code 的 Hooks、Figma AI 的 Skills 規範、OpenClaw 的權限系統，本質上都是在做同一件事：給 Agent 劃定能力邊界，讓它在邊界內做到最好，而不是在邊界外胡說。
判斷三：從"提供信息"到"提供可執行的行動建議"
以前 AI 產品的輸出標準是"回答準確"。
現在頂級 Agent 產品的輸出標準已經變了——不是給你一個準確的知識點，而是給你一個可以直接拿去用的東西。
• 不是"這兩個產品的參數如下"，而是"面對客戶時你可以這樣說" • 不是"翻譯結果如下"，而是"已按品牌規範翻譯並通過術語檢查" • 不是"代碼有這些問題"，而是"已修復並通過測試"
從"提供信息"到"提供可直接執行的行動建議"——這是 AI 產品輸出標準的根本轉變。
10. 如果你想自己搭一個 Agent 工作流
看完這些，如果你也想動手試試，我的建議是從最簡單的開始：
入門路徑：Claude Code + Skills + MCP
1. 先裝 Claude Code，用起來再說 2. 封裝一個你自己的 Skill——找一個你每天重複做的任務（寫週報、整理筆記、審查文檔），把流程封裝成一個 Skill 3. 接一個 MCP Server——Notion、Google Workspace 都有現成的 MCP，接上後 AI 就能操作你的文檔和表格 4. 寫好 CLAUDE.md——把你的工作規範、偏好、常用術語寫進去，讓 AI 按你的標準來
進階路徑：OpenClaw + 自定義 Agent
如果你想完全自己控制 Agent 的行為：
1. 租一台最便宜的 VPS（我用的 68/年的阿里雲） 2. 裝 OpenClaw 3. 接消息通道 4. 配置模型和 Skills 5. 逐步擴展 MCP 工具
不管走哪條路徑，核心都是同一件事：
找到一個真實的、高頻的、有數據支撐的場景，用 Agent + Skill + MCP 跑通它。
最後
回到開頭的問題：Agent、Skill、MCP 到底怎麼分？
答案很簡單：
• Agent = 誰來做（角色 + 判斷 + 決策） • Skill = 做什麼（流程 + 步驟 + 標準） • MCP = 用什麼做（工具 + 數據 + 連接）
這三個概念不是三個獨立的東西，而是 Agent 產品的三個必要組成部分。
缺了任何一個，Agent 要麼不知道該做什麼（缺 Skill），要麼做不了真正的事（缺 MCP），要麼沒有判斷力只能機械執行（缺 Agent 的決策能力）。
搞懂了這個，你再看任何 AI Agent 產品，都能快速看到它的架構在哪、長板在哪、短板在哪。
這比記住一堆術語有用得多。