你有沒有想過，編程可能會發(fā)生翻天覆地的變化？開發(fā)者們不再只是使用 AI 工具，而是開始將 AI 視為構建軟件的新基礎。這不是小修小補，而是一場徹底的變革。想想看，我們一直習慣的那些核心概念--版本控制、模板、文檔，甚至是“用戶”的概念--都在因為AI Agent驅動的工作流程而被重新定義。

這讓我想起了從馬車到汽車的轉變。一開始，人們只是把汽車看作“不用馬拉的馬車”，但很快意識到，整個交通系統(tǒng)都需要重新思考。道路、法規(guī)、城市布局，全都變了?，F(xiàn)在我們正經歷著類似的轉變。AI Agent 既是協(xié)作者又是消費者，這意味著我們需要重新設計一切。

你會看到基礎開發(fā)工具的重大轉變，比如：提示詞（Prompt）現(xiàn)在可以像源代碼一樣被處理，儀表板能夠進行對話，文檔不僅為人類編寫，也為機器編寫。模型上下文協(xié)議（MCP）和 AI 原生 IDE 指向了開發(fā)循環(huán)本身的深層重塑--我們不僅是在以不同的方式編程，還在為一個 AI Agent 充分參與軟件循環(huán)的世界設計工具。

這就像20世紀70年代個人電腦出現(xiàn)時，我們從主機終端轉向個人工作站。那時候，沒人能想象每個人都會有一臺電腦?，F(xiàn)在，我們正面臨類似的轉折點：每個開發(fā)者都會有自己的 AI Agent 團隊。

今天我們來聊聊九個非常前瞻性的開發(fā)者趨勢，雖然還處于早期階段，但它們都是基于真實的痛點，向我們展示了未來可能的樣子。這些趨勢包括重新思考 AI 生成代碼的版本控制，到大語言模型驅動的用戶界面和文檔。

新范式一、AI 原生 Git：為 AI Agent 重塑版本控制

這個想法一開始可能聽起來很瘋狂，但聽我說完?，F(xiàn)在 AI Agent 越來越多地編寫或修改應用程序代碼的大部分，開發(fā)者關心的東西開始發(fā)生變化。我們不再糾結于一行一行一行寫了什么代碼，而是關心輸出是否按預期運行。改動通過測試了嗎？應用還像預期那樣工作嗎？

這里有個很有趣的現(xiàn)象，我稱之為“真相的上移”。以前，源代碼就是真相?，F(xiàn)在，提示詞和測試組合才是真相。想想看，如果我告訴你“用 React 寫一個待辦事項應用”，然后 AI Agent 生成了1000行代碼，你真的在乎每一行代碼具體怎么寫的嗎？還是更在乎它是不是真的能用？

這顛覆了一個長期存在的思維模式。Git 被設計用來跟蹤手寫代碼的精確歷史，但是有了編程 AI Agent，這種粒度變得不那么有意義了。開發(fā)者通常不會審核每一個差異--尤其是當改動很大或者是自動生成的--他們只是想知道新行為是否符合預期結果。

這讓我想起了軟件工程的一個基本原則：抽象。我們總是在尋找合適的抽象層。匯編語言太低級，所以我們有了高級語言。機器碼太難懂，所以我們有了編譯器?，F(xiàn)在，一行一行的代碼可能也太低級了，我們需要新的抽象。

結果是，Git SHA--曾經是“代碼庫狀態(tài)”的標準參考--開始失去一些語義價值。SHA 只是告訴你有東西改變了，但不告訴你為什么或者是否有效。在 AI 優(yōu)先的工作流中，更有用的真相單元可能是生成代碼的提示詞和驗證其行為的測試的組合。

在這個世界里，你的應用的“狀態(tài)”可能更好地由生成的輸入（提示詞、規(guī)范、約束）和一套通過的斷言來表示，而不是一個凍結的提交哈希。想象一下，未來的開發(fā)者可能會說：“給我看看提示詞v3.1的測試覆蓋率”，而不是“給我看看 commit SHA abc123 的 diff”。

實際上，我們最終可能會將提示詞+測試包作為本身可版本化的單元來跟蹤，Git 被降級為跟蹤這些包，而不僅僅是原始源代碼。這就是我所說的“意圖驅動的版本控制”。我們不是在版本控制代碼，而是在版本控制意圖。

更進一步說，在 AI Agent 驅動的工作流中，真相的來源可能會向上游轉移到提示詞、數(shù)據(jù)架構、API 合約和架構意圖。代碼成為這些輸入的副產品，更像編譯的工件而不是手動編寫的源碼。在這個世界里，Git 開始更少地充當工作區(qū)，更多地充當工件日志--一個不僅跟蹤什么改變了，還跟蹤為什么改變以及由誰改變的地方。

想想這個場景：你正在 Debug 一個問題，你不是在查找“誰在什么時候改了這行代碼”，而是在問“哪個 AI Agent 基于什么提示詞做了這個決定，人類審核者在哪里簽字確認了？”這就是未來的代碼考古學。

新范式二、儀表板的革新：AI 驅動的合成動態(tài)界面

我認為儀表板的演變是一個被嚴重低估的趨勢。多年來，儀表板一直是與復雜系統(tǒng)交互的主要界面，比如：可觀測性堆棧、分析平臺、云控制臺等。然而，它們的設計常常面臨用戶體驗過載的問題，界面充斥著眾多旋鈕、圖表和標簽頁，這不僅讓用戶難以快速找到所需信息，還增加了理解信息的難度。

我的一位運維工程師朋友向我抱怨，他花費大量時間在不同儀表板之間切換，試圖拼湊出系統(tǒng)問題所在，這完全是信息過載的表現(xiàn)，數(shù)據(jù)過多卻不知如何整理。對于非高級用戶或跨團隊使用來說，這些儀表板可能變得令人畏懼且效率低下。用戶清楚自己想要達成的目標，但卻不知道該查看何處或應用哪些過濾器來實現(xiàn)，這就好比在一個工具繁多卻外觀相似的巨大工具箱里尋找特定螺絲刀一樣困難。

如今，新一代的 AI 大模型為儀表板帶來了潛在的變革。我們可以在儀表板中融入搜索和交互功能，使其不再是一成不變的界面。大語言模型（LLM）能夠幫助用戶精準找到正確的控制選項，比如：“哪里可以調整這個 API 的限流設置？”；將滿屏數(shù)據(jù)整合為易于理解的洞察，像“總結過去24小時內預發(fā)布環(huán)境所有服務的錯誤趨勢”；還能挖掘出用戶尚未察覺的重要信息，比如：“基于你對我業(yè)務的了解，生成一個我這個季度應該關注的指標列表”。

一個很酷的概念——“上下文化的數(shù)據(jù)展示”。傳統(tǒng)儀表板是靜態(tài)的，展示固定的指標和固定的方式。而 AI 驅動的儀表板則可以根據(jù)用戶當前的任務、角色，甚至過往的行為模式來自我重新配置。

我們已經見證了像 Assistant UI 這樣的技術解決方案，讓 AI Agent 能夠將 ReAct 組件作為工具使用。就像內容可以變得動態(tài)和個性化一樣，用戶界面本身也可以變得自適應和對話式。在自然語言界面面前，純粹的靜態(tài)儀表板可能很快就會顯得過時，這種界面會根據(jù)用戶的意圖進行重新配置。

比如：用戶可以說“顯示上周末歐洲的異常情況”，儀表板就會重塑以展示該視圖，包括總結的趨勢和相關日志。更強大的是，用戶可以問“為什么我們的 NPS評分上周下降了？”AI 可能會提取調查情緒，將其與產品部署相關聯(lián)，并生成一個簡短的診斷敘述。

但這里還有一個更深層的轉變：儀表板不再只是為人類設計的，AI Agent 也需要“看”和“理解”系統(tǒng)狀態(tài)。這意味著我們可能需要雙模式界面：一個人類友好的，一個 AI Agent 友好的。想象一下這個場景：一個 AI Agent 正在監(jiān)控你的系統(tǒng)，它不需要漂亮的圖表，它需要結構化的數(shù)據(jù)和可執(zhí)行的上下文。

這就像為不同的感官設計：人類用眼睛看，AI Agent 用 API “感知”。未來的儀表板可能需要同時服務這兩種“物種”，這是一個全新的設計挑戰(zhàn)。

新范式三、文檔的轉型：成為工具、索引和交互式知識庫的融合體

這個轉變讓我感到非常興奮。開發(fā)者在文檔方面的行為正在發(fā)生變化。過去，用戶會閱讀目錄或從上往下掃描文檔，而現(xiàn)在，用戶則是從一個問題開始。心理模式從“讓我研究這個規(guī)范”轉變?yōu)椤鞍凑瘴蚁矚g的方式重新整理這些信息”。

我記得剛開始編程時，我會花費幾個小時從頭到尾閱讀 API 文檔。而現(xiàn)在，我打開文檔后會直接搜索我想要的內容，或者詢問 AI “怎么用這個庫做 X”。這并非懶惰，而是效率的進化。

這種從被動閱讀到主動查詢的微妙轉變，正在改變文檔應有的形態(tài)。它們不再僅僅是靜態(tài)的 HTML 或 Markdown 頁面，而是正在演變?yōu)榻换ナ街R系統(tǒng)，由索引、嵌入和工具感知的 AI Agent 支撐。

因此，像 Mintlify 這樣的產品應運而生，它們不僅將文檔結構化為語義可搜索的數(shù)據(jù)庫，還充當跨平臺編程 AI Agent 的上下文源。Mintlify 頁面現(xiàn)在經常被 AI 編程 Agent 引用，無論是在AI IDE、VS Code 擴展，還是終端 AI Agent 中，因為編程 Agent 使用最新的文檔作為生成的基礎上下文。

這改變了文檔的目的：它們不再只是為人類讀者服務，也為 AI Agent 消費者服務。在這種新的動態(tài)中，文檔界面變成了一種 AI Agent 的指令。它不僅暴露原始內容，還解釋如何正確使用一個系統(tǒng)。

這里有一個很有趣的趨勢，稱之為“文檔的雙重性格”。人類讀者需要上下文、例子和解釋，而 AI Agent 需要結構化數(shù)據(jù)、明確的規(guī)則和可執(zhí)行的指令。好的文檔需要同時滿足這兩種需求。

未來的文檔可能會有三個層次：人類閱讀層（有故事性和解釋）、AI 消費層（結構化和精確）、交互層（允許詢問和探索）。這就像為不同的學習風格設計教材，但這次是為不同的“思維方式”設計。

新范式四、從模板到生成：vibe coding 取代 create-react-app

這個趨勢讓我想起了從工業(yè)革命到數(shù)字革命的轉變。過去，開始一個項目意味著選擇一個靜態(tài)模板，比如：樣板 GitHub 倉庫或者像 create-react-app、next init 或 rails new 這樣的 CLI。這些模板作為新應用的腳手架，提供一致性但缺少定制性。

開發(fā)者要么順應框架提供的任何默認值，要么冒著大量手動重構的風險。這就好比工業(yè)時代的標準化生產：你可以擁有任何顏色的汽車，只要它是黑色的。

現(xiàn)在，隨著像 Replit、Same.dev、Loveable、Convex 的 Chef 和 Bolt 這樣的文本到應用平臺的出現(xiàn)，以及像 Cursor 這樣的 AI IDE，這種動態(tài)正在發(fā)生變化。開發(fā)者可以描述他們想要什么，比如“一個帶有 Supabase、Clerk 和 Stripe 的 TypeScript API 服務器”，并在幾秒鐘內得到一個定制的項目腳手架。

結果是一個不是通用的，而是個性化和有目的的啟動器，反映了開發(fā)者的意圖和他們選擇的技術棧。這就好比從工業(yè)化生產轉向大規(guī)模定制化。每個項目都可以有獨特的起始點，而不是從相同的模板開始。

這在生態(tài)系統(tǒng)中解鎖了一個新的分發(fā)模式。與其讓少數(shù)框架坐擁長尾，我們可能會看到可組合的、特定于堆棧的生成更廣泛的分布，工具和架構被動態(tài)地混合和匹配。這更多的是描述一個結果，AI 可以圍繞它構建一個堆棧，而不是選擇一個框架。

但這里有一個有趣的副作用，稱之為“框架民主化”。以前，選擇框架是一個重大決定，因為切換成本很高。現(xiàn)在，框架選擇變得更像選擇今天穿什么衣服：可以隨時改變。

當然，這也帶來了新的挑戰(zhàn)。標準化有它的優(yōu)勢--團隊協(xié)作更容易，故障排除更簡單，知識傳播更快。但隨著 AI Agent 能夠理解項目意圖并執(zhí)行大規(guī)模重構，實驗的成本顯著降低。

這意味著我們可能會看到一個更加流動的技術棧生態(tài)系統(tǒng)，其中選擇不再是永久性的決定，而是演化的起點。

新范式五、超越.env：在 AI Agent 驅動的世界中管理秘密

在當今的開發(fā)實踐中，有一個被廣泛忽視卻極為關鍵的問題，那就是秘密管理。多年來，.env 文件一直是開發(fā)者在本地管理秘密（比如：API 密鑰、數(shù)據(jù)庫 URL 和服務令牌）的首選方式。這種方式簡單、便攜，且對開發(fā)者友好。然而，隨著 AI Agent 時代的到來，這種傳統(tǒng)的秘密管理方式正面臨著前所未有的挑戰(zhàn)。

設想一下這樣的場景：你正在使用一個 AI Agent 來協(xié)助編寫代碼，而這個 AI Agent 需要連接到你的數(shù)據(jù)庫。在這種情況下，你真的愿意將數(shù)據(jù)庫密碼直接交給 AI Agent 嗎？如果發(fā)生數(shù)據(jù)泄露，責任該由誰來承擔？是 AI Agent、你自己，還是 AI Agent 的提供商？

當 AI IDE 或 AI Agent 開始代表我們編寫代碼、部署服務以及協(xié)調環(huán)境時，.env 文件的所有權歸屬變得模糊不清。更重要的是，傳統(tǒng)的“環(huán)境變量”概念可能已經不再適用。我們迫切需要一種新的秘密管理系統(tǒng)，它能夠提供精確的權限控制、可審計性以及可撤銷性。

我們已經看到了一些可能的發(fā)展方向。比如：最新的 MCP 規(guī)范引入了一個基于 OAuth 2.1 的授權框架，這表明未來可能會向 AI Agent 提供有范圍限制且可撤銷的令牌，而不是直接提供原始秘密。我們可以設想這樣一個場景：AI Agent 不會獲得你的實際 AWS 密鑰，而是得到一個短期憑證或能力令牌，僅允許其執(zhí)行明確定義的操作。

另一種可能的發(fā)展方向是本地秘密代理的興起。這些代理服務可以在你的機器上或與你的應用一起運行，作為 AI Agent 和敏感憑證之間的中介。代理可以實時請求訪問特定的能力（比如：“部署到預發(fā)布環(huán)境”或“將日志發(fā)送到 Sentry”），并根據(jù)預設規(guī)則決定是否授予訪問權限，同時確保所有操作都是可審計的。

我將這種趨勢稱為“能力導向的安全”。與其給 AI Agent 提供“鑰匙”（即秘密），不如賦予它們“許可”（即能力）。這就好比從“信任但驗證”的模式轉向“零信任但啟用”的模式。

未來的秘密管理將更像一個權限系統(tǒng)，每個操作都有明確的范圍，每個 AI Agent 都有明確的角色，所有訪問行為都將被記錄和審計。這種新的管理方式不僅更加安全，也更符合 AI Agent 的工作模式：它們不需要知道一切，只需要知道完成任務所必需的信息。

新范式六、無障礙作為通用界面：通過 LLM 的眼睛看應用

這一現(xiàn)象讓我聯(lián)想到“意外創(chuàng)新”的概念。目前，我們正目睹一類新型應用的興起，比如：Granola 和 Highlight，它們請求訪問 macOS 的無障礙設置。不過，它們的意圖并非傳統(tǒng)的無障礙用途，而是為了讓 AI Agent 能夠觀察并交互界面。這并非權宜之計，而是預示著更深層次變革的征兆。

無障礙 API 最初是為了協(xié)助視覺或行動障礙用戶在數(shù)字系統(tǒng)中導航而開發(fā)的。如今，這些 API 卻成了 AI Agent 理解并掌控數(shù)字環(huán)境的通用語言，就如同盲文意外地成為機器人解讀世界的方式一般。

無障礙 API 已然攻克了“如何讓機器理解人類界面”這一難題。它們提供了語義化的元素描述，諸如“這是一個按鈕”“這是一個輸入框”“這是一個鏈接”，而這正是 AI Agent 所渴求的完美數(shù)據(jù)結構。

這里有一個深刻的洞見：我們一直在探尋 AI Agent 與人類世界交互的方法，而答案或許就擺在眼前。無障礙技術已經標準化，被所有主流操作系統(tǒng)所接納，并且歷經了十幾年的實戰(zhàn)檢驗。

若經過深思熟慮的拓展，這有望成為 AI Agent 的通用界面層。AI Agent 可以像輔助技術一樣，語義化地觀察應用程序，而非單純點擊像素位置或抓取 DOM。無障礙樹已然暴露了諸如按鈕、標題和輸入框等結構化元素。若再輔以元數(shù)據(jù)（比如：意圖、角色和功能）進行拓展，這或許能成為 AI Agent 的首類接口，使其能夠有目的、精準地感知并操作應用。

實際上，這一方向有幾條潛在的發(fā)展路徑：

首先是上下文提取，我們需要一種標準化的方法，讓運用無障礙或語義 API 的 LLM Agent 能夠查詢屏幕上呈現(xiàn)的內容、可交互的對象以及用戶正在進行的操作。試想一下，AI Agent 能夠說出“告訴我這個屏幕上所有可點擊的元素”或“用戶現(xiàn)在處于什么位置”，并即時獲得結構化的答復。

其次是意圖式執(zhí)行，與其要求 AI Agent 手動串聯(lián)多個 API 調用，不如暴露一個高層端點，讓其聲明目標，比如：“將物品添加到購物車，并選擇最快配送”，隨后由后端計算出具體步驟。這就好比告訴司機“帶我去機場”，而非逐一給出轉彎指令。

再者是 LLM 的備用 UI，無障礙功能為 LLM 提供了一個備用用戶界面。任何展示屏幕的應用都對 AI Agent 開放，即便它未公開 API。對開發(fā)者而言，這暗示了一個新的“渲染層”的出現(xiàn)--這不僅關乎視覺或 DOM 層面，更是 AI Agent 可訪問的上下文，或許可通過結構化注釋或無障礙優(yōu)先的組件來定義。

這三個方向共同指向一個未來：應用程序不再僅僅為人眼設計，也將為 AI 的“眼睛”設計。每個界面元素都將攜帶豐富的語義信息，不僅描述其外觀，還涵蓋其功能以及使用方式。

這引出了一個有趣的想法：倘若我們將無障礙設計視作“機器可讀性”的標準，那會怎樣？每一個新的 UI 元素、每一種新的交互模式，從一開始就考慮機器的理解能力。這不僅利于殘障人士，也將惠及 AI Agent。

展望未來，我們可能會見證一種“雙重設計”的趨勢：既為人類設計，也為 AI Agent 設計。而無障礙原則有望成為連接這兩者的橋梁，這就好比為多文化世界設計語言，既要考慮母語者，也要顧及學習者和翻譯者。

新范式七、異步 AI Agent 工作的興起

這一趨勢揭示了工作模式的深刻變革。隨著開發(fā)者與編程 AI Agent 的協(xié)作日益順暢，我們正逐步邁向異步工作流，AI Agent 在后臺默默運行，開辟并行任務線程，并在取得關鍵進展時及時反饋。

這讓我想起了從同步編程邁向異步編程的歷史性轉變。曾經，程序都是同步執(zhí)行的：完成一項任務后，才能著手下一項。然而，我們逐漸意識到，等待是低效的，而并發(fā)執(zhí)行才是提升效率的關鍵。如今，這種轉變正在人機協(xié)作領域上演。

這種交互模式不再像傳統(tǒng)的結對編程，更像是精心編排的任務調度：你只需向 AI Agent 下達目標指令，讓它自主運行，稍后再進行檢查。這就好比你擁有一位極為能干的實習生，你可以將一個項目交給他，讓他全權負責，而你則可以將精力集中在其他重要事務上。

關鍵在于，這不僅僅是將任務外包那么簡單，它還極大地簡化了協(xié)調工作。以往，開發(fā)者需要與其他團隊頻繁溝通，以更新配置文件、分類錯誤或重構組件。如今，開發(fā)者可以將這些任務直接分配給 AI Agent，它會根據(jù)開發(fā)者的意圖在后臺高效執(zhí)行。

這種變化背后有著更深遠的意義：我們正從同步協(xié)作邁向異步交響。傳統(tǒng)的軟件開發(fā)模式就像一場面對面的會議，所有參與者必須同時在場，實時交流。而新的模式則更像一場分布式的交響樂演奏：每個演奏者（AI Agent）依據(jù)樂譜（規(guī)范）獨立演奏，而指揮（開發(fā)者）則負責整體的協(xié)調工作。

AI Agent 的交互界面也在不斷拓展。除了傳統(tǒng)的 IDE 或 CLI 提示，開發(fā)者如今可以通過多種方式與 AI Agent 互動，比如：

• 在 Slack 上發(fā)送消息
• 在 Figma 的原型圖上進行評論
• 在代碼差異或 PR 上添加內聯(lián)注釋
• 基于已部署應用的預覽版本提供反饋
• 利用語音或通話界面，直接口頭描述變更需求

在這種模式下，AI Agent 貫穿開發(fā)的整個生命周期。它們不僅負責編寫代碼，還能解釋設計思路、響應反饋，并在不同平臺間對錯誤進行分類處理。開發(fā)者則轉變?yōu)閰f(xié)調者，負責決定哪些線程值得深入探索、哪些需要放棄，以及哪些可以合并。

也許最引人注目的變化是，這種異步模式可能會徹底改變我們對“分支”的理解。在傳統(tǒng)的 Git 分支中，分支代表著代碼的分叉。而在未來，分支可能代表著意圖的分叉，每個分支都由不同的 AI Agent 以獨特的方式進行探索。開發(fā)者不再需要親自合并代碼，而是通過評估和選擇不同的解決方案路徑來推進項目。

新范式八、MCP 距離成為通用標準更近了一步

MCP（模型上下文協(xié)議）無疑是近期最令人矚目的協(xié)議創(chuàng)新成果之一。就在不久之前，我們還發(fā)布了一份深入剖析 MCP 的詳盡報告。自那以后，MCP 的發(fā)展勢頭一路高歌猛進：OpenAI 高調宣布正式采用 MCP，該規(guī)范接連整合了多項全新功能，眾多工具開發(fā)商也紛紛向其靠攏，將其奉為 AI Agent 與現(xiàn)實世界交互的默認接口。

這一發(fā)展態(tài)勢不禁讓我聯(lián)想起90年代 HTTP 協(xié)議所扮演的關鍵角色。彼時，HTTP 并非首個網(wǎng)絡協(xié)議，也絕非最為復雜的存在，但憑借其簡潔性、足夠出色的性能以及廣泛的適用性，它迅速贏得了大眾的青睞。如今，MCP 似乎正沿著相似的軌跡穩(wěn)步前行。

深入探究其核心價值，MCP 一舉攻克了兩大關鍵難題：一方面，它為大語言模型（LLM）精準提供了完成那些可能前所未見任務所需的恰當上下文集合；另一方面，它以一種清晰、模塊化的架構取代了以往繁雜的 N×M 定制化集成模式。在新的架構下，各類工具只需暴露標準化接口（扮演服務器角色），便可供任意 AI Agent（作為客戶端）靈活調用。

這其中蘊含著一個極具前瞻性的洞察：我們正親眼目睹“能力標準化”這一全新概念的誕生。恰似 USB 接口成功標準化了設備之間的連接方式，MCP 如今正在 AI Agent 能力領域掀起一場標準化的浪潮。任何工具都能毫無障礙地展示自身功能，任何 AI Agent 都能輕松使用這些功能，無需再為定制化集成耗費大量精力。

展望未來，隨著遠程 MCP 服務以及事實上的注冊表相繼上線，我們有充分的理由相信，MCP 將迎來更為廣泛、深入的普及應用。假以時日，應用程序或許會默認配備 MCP 界面。不妨回想一下，API 是如何讓 SaaS 產品之間實現(xiàn)相互嵌套、跨工具組合工作流的。MCP 同樣能夠發(fā)揮類似作用，將一個個獨立的工具轉變?yōu)榭苫ゲ僮鞯臉嫿K，為 AI Agent 量身打造高效協(xié)作生態(tài)。

這一趨勢自然而然地引出了一個極具創(chuàng)意的概念--“能力市場”的崛起。試想一下，在不遠的將來，一個規(guī)模龐大、功能豐富的能力注冊表橫空出世，AI Agent 可以像如今的開發(fā)者使用 npm 或 PyPI 一樣，輕松地在其中發(fā)現(xiàn)并調用各種新能力。無論是發(fā)送郵件、處理圖像，還是實現(xiàn)特定的業(yè)務邏輯，都能在 MCP 服務器的龐大陣營中找到相應的解決方案。

這絕非僅僅是一項技術標準的演進，它更是一種全新商業(yè)模式的誕生——能力即服務（Capabilities as a Service）。任何有能力的個體或團隊都可以創(chuàng)建一個 MCP 服務器，將自身獨特的功能能力公之于眾，供所有 AI Agent 自由使用。這就好比云計算領域邁向了新的發(fā)展階段：不僅計算資源實現(xiàn)了商品化，就連各種能力本身也步入了商品化的新時代。

新范式九、抽象原語：每個 AI Agent 都需要認證、計費和持久存儲

這一趨勢揭示了一個基礎性的進化規(guī)律：隨著抽象層次的不斷提升，AI Agent 正逐漸成為開發(fā)流程中的核心力量。如今，AI Agent 已經能夠生成大量代碼，但它們仍需要一些堅實的基礎服務來構建可靠的應用程序。

就像人類開發(fā)者依賴 Stripe 進行支付、Clerk 進行認證或 Supabase 進行數(shù)據(jù)庫管理一樣，AI Agent 也需要同樣清晰、可組合的服務原語。一個有趣的觀察是：AI Agent 并不是要取代現(xiàn)有的基礎設施，而是要更好地利用它們。

這些服務--具有清晰邊界、符合人體工程學的 SDK 和合理默認值的 API--越來越多地成為 AI Agent 的運行時接口。例如，當你告訴 AI Agent“創(chuàng)建一個帶有用戶認證和訂閱管理的 SaaS 應用”時，它需要一個認證系統(tǒng)（如 Clerk）、一個支付系統(tǒng)（如 Stripe）、一個數(shù)據(jù)庫（如 Supabase），以及可能的郵件服務和文件存儲等。

這引出了一個深刻的洞察：AI Agent 正在重塑“框架”的概念。傳統(tǒng)框架提供一個結構，讓開發(fā)者在其中填充邏輯；而 AI Agent 框架則提供一套原語，AI Agent 可以根據(jù)需要組合成任何結構。

隨著這種模式的成熟，我們可能會看到服務不僅暴露 API，還會提供架構、能力元數(shù)據(jù)和示例流程，以幫助 AI Agent 更可靠地集成它們。這就好比從“自底向上”的開發(fā)模式轉變?yōu)椤白皂斚蛳隆钡脑O計方式。過去，開發(fā)者從基礎設施開始，逐層向上構建；現(xiàn)在，開發(fā)者從意圖出發(fā)，讓 AI Agent 找到合適的構建塊，這是一種正向設計。

一些服務甚至可能開始默認附帶 MCP 服務器，將每個核心原語轉化為 AI Agent 可以安全、開箱即用地推理和使用的東西。例如，Clerk 可以暴露一個 MCP 服務器，讓 AI Agent 能夠查詢可用產品、創(chuàng)建新的計費計劃或更新客戶訂閱，所有這些操作都預先定義了權限范圍和約束。

AI Agent 不再需要手動編寫 API 調用或在文檔中搜索，它可以直接聲明需求，如“為產品X創(chuàng)建一個月費49美元的專業(yè)版計劃，支持基于使用量的超額收費”。Clerk 的 MCP 服務器會暴露這個能力，驗證參數(shù)，并安全地處理編排。

這帶來了一個有趣的現(xiàn)象，我稱之為“聲明式基礎設施”。AI Agent 不需要知道如何實現(xiàn)用戶認證，它只需要聲明“這個應用需要用戶認證”，然后讓合適的原生服務處理具體實現(xiàn)。

更深層次的影響是，這可能會導致“即時最佳實踐”的出現(xiàn)。這些服務不僅提供功能，還編碼了最佳實踐。當 AI Agent 使用 Stripe 集成時，它自動獲得了處理訂閱、管理失敗付款、處理退款等的最佳實踐。

這就好比建筑行業(yè)的標準化組件。你不需要每次都從零開始設計電氣系統(tǒng)，而是使用標準的開關、插座和配線方法。AI Agent 也不需要每次都從零開始實現(xiàn)認證，而是使用經過驗證的、標準化的服務。

最有趣的是，這可能會創(chuàng)造一個“能力生態(tài)系統(tǒng)”。隨著越來越多的服務變得對 AI Agent 友好，我們可能會看到一個新的市場出現(xiàn)：專門為 AI Agent 設計的原語服務。這些服務的 SDK 不再針對人類開發(fā)者，而是針對 AI Agent，用簡單的接口和明確的約束來暴露強大的能力。

結語：軟件開發(fā)的下一章

這九大趨勢背后，是一場更為宏大的變革。隨著基礎模型的不斷進化，開發(fā)者的日常行為也在悄然改變。新的工具鏈和協(xié)議，比如：MCP，應運而生。這并非簡單地將 AI 嵌入舊有流程，而是一次從核心出發(fā)，圍繞 AI Agent、上下文與意圖重構軟件開發(fā)的深刻變革。

需要著重指出的是，這些趨勢并非孤立存在，它們相互作用、相互強化，共同塑造了一個全新的開發(fā)者生態(tài)系統(tǒng)。AI 原生的版本控制系統(tǒng)，依賴于標準化的能力接口；合成式界面，得益于語義化的無障礙 API；而異步協(xié)作模式，則呼喚強大的秘密管理系統(tǒng)。

這讓我想起了技術革命的三部曲：最初，新技術模仿舊模式；隨后，我們開始探索新技術的獨特潛力；最終，我們重塑整個系統(tǒng)，以充分發(fā)揮新技術的威力。如今，我們正從第二階段邁向第三階段。

在開發(fā)者工具層面，一場根本性的變革正在發(fā)生。這不僅僅是技術的升級，更是思維方式的徹底轉變。我們正從“編程”轉向“意圖表達”，從“版本控制”轉向“意圖追蹤”，從“文檔”轉向“知識神經網(wǎng)絡”。

也許最為關鍵的是，這些趨勢預示著軟件開發(fā)角色的深刻變化。未來的開發(fā)者，可能不再像如今這般獨自奮戰(zhàn)，更像是交響樂指揮，負責協(xié)調不同 AI Agent 的工作。

這一轉變既令人興奮，又略帶不安。我們正踏入一片未知領域，新的規(guī)則還在不斷形成。但歷史經驗告訴我們，每一次技術革命都創(chuàng)造了比它摧毀的更多機會。關鍵在于保持開放心態(tài)，適應變化，同時堅守那些讓我們成為優(yōu)秀開發(fā)者的核心價值：解決問題、創(chuàng)造價值、服務用戶。

我們滿懷熱情地投身于下一代工具的構建與投資。這不僅是為了更高效地編程，更是為了攻克那些曾經無解的難題，創(chuàng)造那些曾經難以想象的可能性。這，才是技術進步的真正意義：不是更快，而是更多、更好。

本文轉載自??玄姐聊AGI?  作者：玄姐