你寫的每一個應用，本質上都是給人點擊設計的。這個前提正在過期。

AI代理已經不是"將要到來"——它們已經在這里了。它們正在重塑你使用的工具、運行的工作流，以及那些曾經需要人類介入的決策環(huán)節(jié)。與此同時，一層新的基礎設施正在悄然成為標準：代理協(xié)議。MCP、A2A、x402。不是 buzzword，而是代理與系統(tǒng)之間的實際契約。

這個轉變是架構層面的。HTTP為瀏覽器而生，為人類導航、點擊、等待而生。代理協(xié)議為另一種東西設計：它不導航，它決策。它不需要按鈕，它需要動詞。

MCP是這里最實用的切入點。你把現(xiàn)有能力——你的應用已經實現(xiàn)的任何功能——暴露為代理可調用的東西：它能調用的工具、能讀取的數(shù)據(jù)、能獲取的提示模板。你不用重建任何東西，只是給已構建的功能一個代理能夠觸及的表面。

深入這個協(xié)議后，最意外的是它的雙向性。Elicitation 讓你的服務器在執(zhí)行中途暫停，反向詢問代理需要什么。Sampling 完全翻轉——你的服務器調用模型，而非相反。Completions 在代理發(fā)起調用前就引導它完成有效輸入。這不是管道，是對話。

不做這個轉變的應用不會消失。它們只是對替用戶做決策的代理變得不可見。

以下是核心實現(xiàn)路徑：

工具（Tools）

這是入口點，也是最令人滿足的部分。你拿一個可能已經寫好的函數(shù)，加一個裝飾器，它就變成代理能發(fā)現(xiàn)、理解并調用的東西。沒有新基礎設施，沒有膠水代碼。函數(shù)本身就是接口。

資源（Resources）

不是每個能力都該是動作。應用持有的某些東西——參考數(shù)據(jù)、配置、實時狀態(tài)——代理應該能讀但絕不能觸發(fā)。資源處理這個：代理能看，不能碰。這個細微區(qū)別在構建真實系統(tǒng)時至關重要。

提示（Prompts）

這個常被跳過，但跳過是錯的。如果你曾在三個不同集成里復制粘貼同一段系統(tǒng)提示，然后在變更時不得不更新全部三處——提示解決了這個問題。在服務器上定義一次指令，帶參數(shù)，每個連接的客戶端拿到相同內容。一處更新，全局受益。

傳輸與數(shù)據(jù)格式

這里多數(shù)人遇到第一個真正的坑。無論你拿到的是結構化數(shù)據(jù)還是文本塊，你的應用能否據(jù)此行動，取決于這一層的設計。

完整視頻演示在 YouTube 播放列表，結構化課程版本及全部代碼在 Udemy。