：從 MCP 工具、Skill 體系到 AI 應用端到端交付)
一個真實的困惑2026 年AI Coding 的貢獻率在頭部團隊已經(jīng)超過 90%。菜鳥網(wǎng)絡的數(shù)據(jù)顯示他們的 AI 生成代碼占比從 10% 一路漲到 90%但一個反直覺的事實是需求交付周期只縮短了約 10%。編碼自動化并沒有等比例地加速交付。原因很簡單編碼只占需求交付鏈路的 30% 左右剩下的需求澄清、方案設(shè)計、測試用例、聯(lián)調(diào)、部署、驗收每一步都還在等人推動。人成了端到端流程里的瓶頸。這意味著會寫 Agent 調(diào)用的代碼和能交付一個真正跑通的 Agent 應用是兩件完全不同的事。這篇文章想聊的是后者當你把 MCP 工具、Skill 體系和端到端交付流程拼在一起時會遇到什么以及怎么解決。一、MCP 工具別把它當成“更高級的 Function Calling”MCP 和 Function Calling 的關(guān)系很多人的理解是錯的。Function Calling 是模型在單次請求中“決定調(diào)什么”MCP 是工具能力的標準化接入層。用現(xiàn)實店舖打比方Skill 是知道怎么干的店員MCP 是貨架和通道的訪問權(quán)。店員再懂沒有貨架也拿不到東西。MCP Server 的工程現(xiàn)實一個生產(chǎn)可用的 MCP Server遠不止把函數(shù)包一層。TypeScript SDK 的官方示例里每個工具定義包含五個必填字段name、description、inputSchema、outputSchema、execute。關(guān)鍵設(shè)計原則有三條錯誤要用返回值表達不要拋異常。 MCP Server 的 execute 函數(shù)應當返回人類可讀的錯誤信息而不是拋出異常讓上層崩潰。比如刪除一個不存在的 TODO返回 “TODO with id 5 not found.”而不是 throw new Error()。模型能理解這段文字并據(jù)此調(diào)整策略。Schema 是模型能看到的唯一接口文檔。 inputSchema 定義參數(shù)類型和必填項outputSchema 定義返回結(jié)構(gòu)。如果 schema 寫得含糊模型就會亂傳參數(shù)。把每個 MCP 工具當成給一個“很聽話但不會猜”的實習生寫的 API 文檔。工具結(jié)果要有穩(wěn)定的標識符。 OpenAI 的 MCP 構(gòu)建指南明確指出返回結(jié)構(gòu)化結(jié)果時使用穩(wěn)定 ID讓后續(xù)工具調(diào)用能引用同一條記錄。不要返回一堆沒有主鍵的數(shù)據(jù)。MCP 的戰(zhàn)略位置AWS 的 Agentic AI 框架指南給出了一個清晰的分工建議MCP 作為生產(chǎn)環(huán)境工具集成的首選協(xié)議框架原生工具留給快速原型和非關(guān)鍵場景。理由是可互操作性和未來靈活性——MCP 工具可以在不同 Agent 框架之間遷移框架原生工具則綁定在特定生態(tài)里。但 MCP 不解決“工具設(shè)計得好不好”。一個描述含糊的 MCP Server和一個描述含糊的 Function Calling 工具一樣會讓模型亂調(diào)。二、Skill 體系把“某人會做”變成“誰都能做”Skill 的本質(zhì)不是文件格式。它的價值在于把某位同事腦子里的程序性知識變成可發(fā)現(xiàn)、可加載、可共享的能力包。漸進披露為什么你的 Agent 上下文總是不夠用Agent 的上下文窗口看起來很寬裕但 System Prompt、歷史會話、工具定義、工具調(diào)用結(jié)果、文件內(nèi)容全都在搶這塊空間。長程任務跑到一半上下文就爆了。Skill 的漸進披露機制就是為此設(shè)計的。系統(tǒng)提示詞里只放 Skill 的名稱和描述用 XML 格式掛在 available_skills 里。Agent 判斷需要某個 Skill 時才通過工具調(diào)用加載 SKILL.md 的詳細指令。如果指令里引用了參考文檔或腳本Agent 在真正需要時才去讀取。這意味著 Skill 的激活本身會消耗 1-2 步工具調(diào)用。description 寫得準不準直接決定 Token 消耗和響應質(zhì)量。誤觸發(fā)是浪費漏觸發(fā)是能力缺失。寫 Skill 的兩個關(guān)鍵Description 決定“什么時候用”。 好的描述要同時回答三個問題能做什么、包含哪些核心能力、用戶說什么話時應該觸發(fā)。知乎專欄的對比很直觀“管理 Linear 項目工作流包括迭代規(guī)劃、任務創(chuàng)建和狀態(tài)跟蹤。當用戶提到’迭代’、‘Linear 任務’、項目規(guī)劃’時使用”遠比 “Helps with projects” 有效。如果你的 Skill 經(jīng)常在不相關(guān)場景被加載可以在描述里加“負向觸發(fā)”“不要用于簡單的數(shù)據(jù)瀏覽那個用> 實踐 Agent 全棧開發(fā)：從 MCP 工具、Skill 體系到 AI 應用端到端交付
一個真實的困惑2026 年AI Coding 的貢獻率在頭部團隊已經(jīng)超過 90%。菜鳥網(wǎng)絡的數(shù)據(jù)顯示他們的 AI 生成代碼占比從 10% 一路漲到 90%但一個反直覺的事實是需求交付周期只縮短了約 10%。編碼自動化并沒有等比例地加速交付。原因很簡單編碼只占需求交付鏈路的 30% 左右剩下的需求澄清、方案設(shè)計、測試用例、聯(lián)調(diào)、部署、驗收每一步都還在等人推動。人成了端到端流程里的瓶頸。這意味著會寫 Agent 調(diào)用的代碼和能交付一個真正跑通的 Agent 應用是兩件完全不同的事。這篇文章想聊的是后者當你把 MCP 工具、Skill 體系和端到端交付流程拼在一起時會遇到什么以及怎么解決。一、MCP 工具別把它當成“更高級的 Function Calling”MCP 和 Function Calling 的關(guān)系很多人的理解是錯的。Function Calling 是模型在單次請求中“決定調(diào)什么”MCP 是工具能力的標準化接入層。用現(xiàn)實店舖打比方Skill 是知道怎么干的店員MCP 是貨架和通道的訪問權(quán)。店員再懂沒有貨架也拿不到東西。MCP Server 的工程現(xiàn)實一個生產(chǎn)可用的 MCP Server遠不止把函數(shù)包一層。TypeScript SDK 的官方示例里每個工具定義包含五個必填字段name、description、inputSchema、outputSchema、execute。關(guān)鍵設(shè)計原則有三條錯誤要用返回值表達不要拋異常。 MCP Server 的 execute 函數(shù)應當返回人類可讀的錯誤信息而不是拋出異常讓上層崩潰。比如刪除一個不存在的 TODO返回 “TODO with id 5 not found.”而不是 throw new Error()。模型能理解這段文字并據(jù)此調(diào)整策略。Schema 是模型能看到的唯一接口文檔。 inputSchema 定義參數(shù)類型和必填項outputSchema 定義返回結(jié)構(gòu)。如果 schema 寫得含糊模型就會亂傳參數(shù)。把每個 MCP 工具當成給一個“很聽話但不會猜”的實習生寫的 API 文檔。工具結(jié)果要有穩(wěn)定的標識符。 OpenAI 的 MCP 構(gòu)建指南明確指出返回結(jié)構(gòu)化結(jié)果時使用穩(wěn)定 ID讓后續(xù)工具調(diào)用能引用同一條記錄。不要返回一堆沒有主鍵的數(shù)據(jù)。MCP 的戰(zhàn)略位置AWS 的 Agentic AI 框架指南給出了一個清晰的分工建議MCP 作為生產(chǎn)環(huán)境工具集成的首選協(xié)議框架原生工具留給快速原型和非關(guān)鍵場景。理由是可互操作性和未來靈活性——MCP 工具可以在不同 Agent 框架之間遷移框架原生工具則綁定在特定生態(tài)里。但 MCP 不解決“工具設(shè)計得好不好”。一個描述含糊的 MCP Server和一個描述含糊的 Function Calling 工具一樣會讓模型亂調(diào)。二、Skill 體系把“某人會做”變成“誰都能做”Skill 的本質(zhì)不是文件格式。它的價值在于把某位同事腦子里的程序性知識變成可發(fā)現(xiàn)、可加載、可共享的能力包。漸進披露為什么你的 Agent 上下文總是不夠用Agent 的上下文窗口看起來很寬裕但 System Prompt、歷史會話、工具定義、工具調(diào)用結(jié)果、文件內(nèi)容全都在搶這塊空間。長程任務跑到一半上下文就爆了。Skill 的漸進披露機制就是為此設(shè)計的。系統(tǒng)提示詞里只放 Skill 的名稱和描述用 XML 格式掛在 available_skills 里。Agent 判斷需要某個 Skill 時才通過工具調(diào)用加載 SKILL.md 的詳細指令。如果指令里引用了參考文檔或腳本Agent 在真正需要時才去讀取。這意味著 Skill 的激活本身會消耗 1-2 步工具調(diào)用。description 寫得準不準直接決定 Token 消耗和響應質(zhì)量。誤觸發(fā)是浪費漏觸發(fā)是能力缺失。寫 Skill 的兩個關(guān)鍵Description 決定“什么時候用”。 好的描述要同時回答三個問題能做什么、包含哪些核心能力、用戶說什么話時應該觸發(fā)。知乎專欄的對比很直觀“管理 Linear 項目工作流包括迭代規(guī)劃、任務創(chuàng)建和狀態(tài)跟蹤。當用戶提到’迭代’、‘Linear 任務’、項目規(guī)劃’時使用”遠比 “Helps with projects” 有效。如果你的 Skill 經(jīng)常在不相關(guān)場景被加載可以在描述里加“負向觸發(fā)”“不要用于簡單的數(shù)據(jù)瀏覽那個用>