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