国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

隨著人工智能技術(shù)的飛速發(fā)展，軟件開發(fā)領(lǐng)域正經(jīng)歷一場(chǎng)深刻的變革。傳統(tǒng)的開發(fā)模式和工具正在被重新定義，以適應(yīng)AI代理和智能系統(tǒng)帶來(lái)的新需求。

AI正在深刻改變產(chǎn)品傳統(tǒng)的開發(fā)方式，這個(gè)進(jìn)度遠(yuǎn)超你想象。

此前，YC管理合伙人賈里德·弗里德曼透露：W25中，1/4的創(chuàng)業(yè)公司，用AI生成代碼庫(kù)。

隨著越來(lái)越多AI編程工具的崛起，AI已經(jīng)不僅僅是開發(fā)者編寫代碼的工具，甚至成為軟件構(gòu)建的基礎(chǔ)設(shè)施。

不久前，a16z就發(fā)布了一篇文章關(guān)于AI變革軟件開發(fā)模式的文章。文章里探討了9種新興的開發(fā)模式，這些模式很好地切準(zhǔn)了用戶的痛點(diǎn)，雖然它們?nèi)匀惶幱谄鸩诫A段，但未來(lái)大有可為。

這些模式涵蓋了從重新思考AI生成代碼的版本控制，到LLM驅(qū)動(dòng)的用戶界面和文檔。

接下來(lái)，就讓我們一起去看看吧。

01 AI原生Git：為AI代理重新構(gòu)想版本控制

隨著AI代理越來(lái)越多地編寫或修改應(yīng)用程序中的大量代碼，開發(fā)者所關(guān)注的重點(diǎn)也開始發(fā)生變化。我們不再執(zhí)著于每一行代碼是如何被寫出來(lái)的，而更關(guān)心輸出的行為是否符合預(yù)期：這次更改通過(guò)了測(cè)試嗎？應(yīng)用是否仍然按照預(yù)期運(yùn)行？

這顛覆了一個(gè)長(zhǎng)期存在的思維模型：Git的設(shè)計(jì)初衷是為了追蹤手動(dòng)編寫的代碼精確的歷史變更，但在引入編碼代理之后，這種細(xì)粒度的追蹤開始變得不那么有意義。

開發(fā)者通常不會(huì)再去逐行審核每一個(gè)差異——尤其當(dāng)改動(dòng)很大或者是由AI自動(dòng)生成的時(shí)候 —— 他們只關(guān)心新行為是否與預(yù)期一致。因此，曾經(jīng)作為“代碼庫(kù)狀態(tài)”權(quán)威標(biāo)識(shí)的 Git SHA 開始逐漸失去其語(yǔ)義上的意義。

一個(gè)SHA只能告訴你某些東西發(fā)生了變化，但無(wú)法說(shuō)明原因，也無(wú)法判斷是否正確。在以AI為核心的開發(fā)流程中，一個(gè)更有用的“真實(shí)單元”可能是生成這段代碼的提示詞（prompt）和驗(yàn)證其行為的測(cè)試組合。

在這種模式下，“代碼狀態(tài)”可能更適合由生成代碼的輸入（如提示詞、規(guī)范、約束條件）以及一組通過(guò)的斷言來(lái)表示，而不是一個(gè)固定的提交哈希值。事實(shí)上，我們最終可能會(huì)將 prompt+test打包成可版本控制的獨(dú)立單元，并讓Git來(lái)追蹤這些打包后的單元，而非僅僅是原始源碼。

進(jìn)一步來(lái)看：在由AI代理驅(qū)動(dòng)的工作流中，事實(shí)的源頭可能會(huì)向上游轉(zhuǎn)移，轉(zhuǎn)向提示詞、數(shù)據(jù)結(jié)構(gòu)、API合約和架構(gòu)意圖。

代碼則成為這些輸入的副產(chǎn)品，更像是一個(gè)編譯產(chǎn)物，而非人工撰寫的源碼。在這種世界里，Git 的功能會(huì)逐漸從協(xié)作工作區(qū)轉(zhuǎn)變?yōu)橐粋€(gè)產(chǎn)物日志 —— 一個(gè)不僅記錄“什么改變了”，還記錄“為什么改變”、“是誰(shuí)操作的”的地方。

我們可能會(huì)開始加入更豐富的元數(shù)據(jù)，例如是哪個(gè)代理或模型進(jìn)行了更改、哪些部分受到保護(hù)、在哪些地方需要人工審查 —— 或者像 Diamond 這樣的 AI 審查員何時(shí)應(yīng)該介入流程。

為了讓這個(gè)概念更具體一些，下面是一個(gè)模擬圖，展示了一個(gè) AI 原生的 Git 工作流在實(shí)際中可能的樣子：

02 儀表盤->綜合：動(dòng)態(tài)AI驅(qū)動(dòng)界面

多年來(lái)，儀表盤一直是與復(fù)雜系統(tǒng)交互的主要界面，例如可觀測(cè)性堆棧、分析工具、云控制臺(tái)（比 AWS）等等。

但它們的設(shè)計(jì)常常面臨用戶體驗(yàn)過(guò)載的問(wèn)題：太多旋鈕、圖表和標(biāo)簽頁(yè)，迫使用戶既要“尋找信息”，又要“弄清楚如何使用”。

尤其是對(duì)于非專業(yè)用戶或跨團(tuán)隊(duì)協(xié)作來(lái)說(shuō)，這些儀表盤可能會(huì)顯得令人望而生畏或效率低下。用戶知道自己想要達(dá)成什么目標(biāo)，卻不知道從哪里入手，也不知道應(yīng)該應(yīng)用哪些過(guò)濾條件才能找到答案。

最新一代AI模型為我們帶來(lái)了可能的轉(zhuǎn)變。與其將儀表盤視為固定不變的畫布，不如在其之上疊加搜索和交互能力。

如今的大語(yǔ)言模型（LLMs）可以幫助用戶找到正確的控制選項(xiàng)（例如：“我應(yīng)該在哪里調(diào)整這個(gè)API的限流設(shè)置？”）；可以將整個(gè)屏幕的數(shù)據(jù)綜合成易于理解的洞察（例如：“總結(jié)過(guò)去 24 小時(shí)內(nèi)所有預(yù)發(fā)布服務(wù)的錯(cuò)誤趨勢(shì)”）；甚至可以揭示那些用戶尚未意識(shí)到的問(wèn)題（例如：“根據(jù)你對(duì)我業(yè)務(wù)的了解，生成一份本季度我應(yīng)關(guān)注的關(guān)鍵指標(biāo)清單”）。

我們已經(jīng)看到一些技術(shù)方案，如Assistant UI，使代理能夠利用React組件作為工具。就像內(nèi)容變得動(dòng)態(tài)化和個(gè)性化一樣，UI本身也可以變得自適應(yīng)和對(duì)話式。

相比起一個(gè)由自然語(yǔ)言驅(qū)動(dòng)、能根據(jù)用戶意圖重新配置的界面，純粹靜態(tài)的儀表盤很快就會(huì)顯得過(guò)時(shí)。例如，用戶不必再手動(dòng)點(diǎn)擊五層過(guò)濾器來(lái)篩選特定指標(biāo)，只需說(shuō)一句：“顯示上周末歐洲地區(qū)的異常數(shù)據(jù)。”儀表盤便會(huì)自動(dòng)重組以展示該視圖，并附帶匯總的趨勢(shì)和相關(guān)日志。

更強(qiáng)大的是，用戶還可以問(wèn)：“上周我們的 NPS 分?jǐn)?shù)為什么下降了？”AI可能會(huì)調(diào)出調(diào)查情緒數(shù)據(jù)，將其與一次產(chǎn)品上線進(jìn)行關(guān)聯(lián)，并生成一段簡(jiǎn)短的診斷分析。

從更大的角度看，如果代理現(xiàn)在也成為軟件的使用者，我們也需要重新思考“儀表盤”的本質(zhì)以及它的目標(biāo)用戶是誰(shuí)。例如，儀表盤可以渲染成更適合代理體驗(yàn)的視圖——結(jié)構(gòu)化的、可編程訪問(wèn)的界面，幫助代理感知系統(tǒng)狀態(tài)、做出決策并執(zhí)行操作。

這可能導(dǎo)致出現(xiàn)雙模式界面：一種面向人類用戶，一種面向代理，兩者共享同一個(gè)狀態(tài)，但分別針對(duì)不同的使用方式進(jìn)行優(yōu)化。

在某種程度上，代理正在承擔(dān)原本由告警、定時(shí)任務(wù)或基于條件的自動(dòng)化所扮演的角色，但具備更強(qiáng)的上下文理解和靈活性。不同于傳統(tǒng)的預(yù)設(shè)邏輯（例如：“如果錯(cuò)誤率 > 閾值，則發(fā)送告警”），代理可以說(shuō)：“錯(cuò)誤率正在上升。這是可能的原因、受影響的服務(wù)，以及建議的修復(fù)方案?！痹谶@種新世界中，儀表盤不再只是觀察系統(tǒng)的場(chǎng)所，而是人類與代理共同協(xié)作、整合信息并采取行動(dòng)的空間。

▲ 儀表盤的演變：如何更好地服務(wù)于人類用戶與 AI 代理的雙重需求

03 文檔，工具、索引和交互式知識(shí)庫(kù)的結(jié)合體

開發(fā)者在使用文檔時(shí)的行為正在發(fā)生變化。

現(xiàn)在，用戶不再是從目錄開始逐頁(yè)閱讀或自上而下瀏覽，而是從一個(gè)問(wèn)題開始：“我該如何完成某項(xiàng)任務(wù)？”這種心理模型的轉(zhuǎn)變，意味著文檔的角色已經(jīng)從“讓我來(lái)學(xué)習(xí)這份規(guī)范”轉(zhuǎn)變?yōu)椤罢?qǐng)幫我以我喜歡的方式重新組織這些信息”。

這一微妙的變化——從被動(dòng)閱讀轉(zhuǎn)向主動(dòng)查詢——正在重塑文檔應(yīng)有的形態(tài)。

文檔不再僅僅是靜態(tài)的 HTML 或 Markdown 頁(yè)面，而是演變?yōu)橛伤饕⑶度耄╡mbeddings）和具備工具意識(shí)的AI代理支持的交互式知識(shí)系統(tǒng)。

因此，我們看到像Mintlify這類產(chǎn)品的興起：它們不僅將文檔結(jié)構(gòu)化為語(yǔ)義可搜索的數(shù)據(jù)庫(kù)，還成為跨平臺(tái)編碼代理的重要上下文來(lái)源。

如今，在AI集成開發(fā)環(huán)境（AI IDE）、VS Code插件或終端代理中，Mintlify的內(nèi)容經(jīng)常被AI編碼代理引用，因?yàn)檫@些代理會(huì)利用最新文檔作為生成代碼的基礎(chǔ)背景信息。

這從根本上改變了文檔的目的：它不再只是服務(wù)于人類讀者，也成為AI代理的重要“消費(fèi)者”內(nèi)容。在這種新的關(guān)系中，文檔界面更像是對(duì)AI代理的指令說(shuō)明，它不僅僅展示原始內(nèi)容，更解釋了如何正確地使用一個(gè)系統(tǒng)。

▲ Mintlify的屏幕截圖，用戶可以使用cmd+k快捷鍵打開 AI 聊天窗口，對(duì)Mintlify 文檔進(jìn)行問(wèn)答

04 從靜態(tài)模板到智能生成：Vibe編程正在取代Create React App的時(shí)代

在過(guò)去，啟動(dòng)一個(gè)新項(xiàng)目意味著選擇一個(gè)靜態(tài)模板，比如一個(gè)樣板GitHub倉(cāng)庫(kù)，或者使用像 create-react-app、next init、rails new這樣的命令行工具。

這些模板為新應(yīng)用提供了基本框架，帶來(lái)了統(tǒng)一性，但幾乎沒有定制空間。開發(fā)者只能接受框架提供的默認(rèn)配置，否則就要冒著大量手動(dòng)重構(gòu)的風(fēng)險(xiǎn)。

但現(xiàn)在，隨著“文本生成應(yīng)用”平臺(tái)（如 Replit、Same.dev、Loveable、Convex 推出的 Chef 和 Bolt）以及 AI 集成開發(fā)環(huán)境（如 Cursor）的興起，這種模式正在發(fā)生轉(zhuǎn)變。

開發(fā)者只需描述自己想要什么（例如：“一個(gè)使用 Supabase、Clerk 和 Stripe 的 TypeScript API 服務(wù)”），AI就能在幾秒鐘內(nèi)生成一個(gè)量身定制的項(xiàng)目結(jié)構(gòu)。由此產(chǎn)生的啟動(dòng)模板不再是通用的，而是個(gè)性化的、有針對(duì)性的，反映了開發(fā)者的意圖以及他們選擇的技術(shù)棧。

這為生態(tài)系統(tǒng)開啟了一種新的分發(fā)模式。未來(lái)，我們可能不再依賴少數(shù)幾個(gè)主流框架主導(dǎo)長(zhǎng)尾市場(chǎng)，而是看到更多可組合的、特定技術(shù)棧的生成方式涌現(xiàn)出來(lái)，工具與架構(gòu)可以動(dòng)態(tài)地混合搭配。

重點(diǎn)不再是“選擇一個(gè)框架”，而是“描述一個(gè)目標(biāo)”，然后由AI圍繞這個(gè)目標(biāo)構(gòu)建合適的技術(shù)棧。一位工程師可以用Next.js和tRPC創(chuàng)建一個(gè)應(yīng)用，另一位則從Vite和React開始，但他們都能立即獲得可用的初始結(jié)構(gòu)。

當(dāng)然，這種變化也伴隨著權(quán)衡。標(biāo)準(zhǔn)技術(shù)棧確實(shí)有很多優(yōu)勢(shì)，比如提升團(tuán)隊(duì)效率、簡(jiǎn)化新人上手流程，以及在組織內(nèi)部更容易排查問(wèn)題。

跨框架的重構(gòu)不僅僅是技術(shù)上的挑戰(zhàn)，往往還涉及產(chǎn)品決策、基礎(chǔ)設(shè)施限制和團(tuán)隊(duì)技能等多重因素。但如今發(fā)生變化的是“切換框架”或“從無(wú)框架起步”的成本。借助能夠理解項(xiàng)目意圖并半自主執(zhí)行大規(guī)模重構(gòu)的AI代理，實(shí)驗(yàn)變得更加可行。

這意味著，框架的選擇正變得越來(lái)越可逆。一個(gè)開發(fā)者可能一開始使用Next.js，但后來(lái)決定遷移到Remix 和Vite，并讓AI代理完成大部分重構(gòu)工作。這大大降低了框架曾經(jīng)帶來(lái)的鎖定效應(yīng)，鼓勵(lì)了更多的嘗試行為，尤其是在項(xiàng)目的早期階段。這也降低了采用“有特定理念”的技術(shù)棧的門檻，因?yàn)槿蘸蟮那袚Q已不再是巨大的投入。

05 告別.env：AI代理時(shí)代下的新型密鑰管理方式

幾十年來(lái)，.env文件一直是開發(fā)者在本地管理敏感信息（如API密鑰、數(shù)據(jù)庫(kù)URL和服務(wù)令牌）的默認(rèn)方式。

它們簡(jiǎn)單、可移植且對(duì)開發(fā)者友好。但在一個(gè)由AI代理驅(qū)動(dòng)的世界中，這種范式開始變得不再適用。當(dāng)一個(gè)AI IDE或代理在為我們編寫代碼、部署服務(wù)和協(xié)調(diào)環(huán)境時(shí)，誰(shuí)真正擁有這個(gè).env文件，已經(jīng)不再清晰。

我們已經(jīng)開始看到一些未來(lái)可能形態(tài)的跡象。例如，最新的MCP規(guī)范（Model Communication Protocol）就包含了一個(gè)基于OAuth 2.1的授權(quán)框架，這預(yù)示著我們可能會(huì)轉(zhuǎn)向?yàn)锳I代理提供有作用域、可撤銷的能力令牌（token），而不是直接暴露原始密鑰（secrets）。

我們可以設(shè)想這樣一種場(chǎng)景：AI代理不會(huì)直接獲得你的AWS密鑰，而是獲取一個(gè)生命周期短、權(quán)限受限的憑證或能力令牌，僅允許它執(zhí)行特定的操作。

另一種可能的發(fā)展路徑是“本地密鑰代理（local secret brokers）”的興起——這些是運(yùn)行在你本地機(jī)器上或與你的應(yīng)用并行的服務(wù)，作為AI代理與敏感憑據(jù)之間的中間人。

代理不再通過(guò).env文件注入密鑰，也不再將密鑰硬編碼進(jìn)項(xiàng)目結(jié)構(gòu)中，而是可以請(qǐng)求某種操作權(quán)限（如“部署到預(yù)發(fā)布環(huán)境”或“將日志發(fā)送到 Sentry”），然后由代理服務(wù)決定是否即時(shí)授予該權(quán)限，并全程記錄審計(jì)日志。

這種方式將密鑰訪問(wèn)從靜態(tài)文件系統(tǒng)中解耦出來(lái)，使密鑰管理更像是一種API授權(quán)行為，而非傳統(tǒng)的環(huán)境配置流程。

▲ 以代理為中心的秘密經(jīng)紀(jì)人流程的CLI模型

06 A以輔助功能為通用接口：讓LLM“看見”的應(yīng)用界面

我們開始看到一類新型應(yīng)用的出現(xiàn)（例如Granola和Highlight），它們請(qǐng)求訪問(wèn)macOS的輔助功能設(shè)置，但并不是為了傳統(tǒng)的無(wú)障礙使用場(chǎng)景，而是為了讓AI代理能夠“觀察”和“交互”界面。然而，這并非一種“黑科技”，而是一種更深層次變革的前兆。

輔助功能API最初是為了幫助有視覺或運(yùn)動(dòng)障礙的用戶更好地操作數(shù)字系統(tǒng)而設(shè)計(jì)的。但如果加以合理擴(kuò)展，這些API可能會(huì)成為AI代理的通用接口層。與其通過(guò)像素坐標(biāo)點(diǎn)擊屏幕或解析 DOM結(jié)構(gòu)，AI代理可以像輔助技術(shù)一樣，以“語(yǔ)義化”的方式來(lái)理解和操作應(yīng)用程序。

當(dāng)前的輔助功能樹（accessibility tree）已經(jīng)暴露了結(jié)構(gòu)化的元素，比如按鈕、標(biāo)題和輸入框。如果再加上一些元數(shù)據(jù)（如意圖 intent、角色role、可操作性affordance），它就可能成為AI代理的一等接口，讓代理以更有目的性和精確性的方式感知并操作應(yīng)用程序。

以下是幾個(gè)潛在的發(fā)展方向：

1.上下文提?。–ontext Extraction）

為使用輔助功能或語(yǔ)義API的LLM代理提供一種標(biāo)準(zhǔn)化的方式，讓它可以查詢：

屏幕上顯示了什么？

它可以與哪些元素進(jìn)行交互？

當(dāng)前用戶正在做什么？

這種能力可以讓代理真正理解當(dāng)前的應(yīng)用狀態(tài)，并基于上下文做出反應(yīng)。

2. 有目的的執(zhí)行（Intentful Execution）

無(wú)需讓代理手動(dòng)串聯(lián)多個(gè) API 調(diào)用，而是提供一個(gè)高層級(jí)的接口，允許它聲明目標(biāo)（intent），例如：“將商品加入購(gòu)物車，并選擇最快的配送方式?！?/p>

然后由后端系統(tǒng)負(fù)責(zé)解析這些目標(biāo)，并自動(dòng)規(guī)劃出實(shí)現(xiàn)步驟。這種方式降低了代理對(duì)底層UI實(shí)現(xiàn)細(xì)節(jié)的依賴，也提升了抽象層級(jí)。

3. LLM 的備用 UI（Fallback UI for LLMs）

輔助功能為L(zhǎng)LM提供了一種備用的用戶界面。任何能展示界面的應(yīng)用都可以被AI代理使用，即使它沒有公開的API。對(duì)開發(fā)者而言，這預(yù)示著一種新的“渲染層”概念——不僅僅是視覺層或 DOM 結(jié)構(gòu)，而是一個(gè)可供代理訪問(wèn)的上下文環(huán)境，可能通過(guò)結(jié)構(gòu)化注解或以輔助功能優(yōu)先的組件來(lái)定義。

07 異步代理工作的興起

隨著開發(fā)者與編碼代理之間的協(xié)作日益流暢，我們正在見證一種自然的轉(zhuǎn)變：工作流程正朝著異步化方向發(fā)展。代理可以在后臺(tái)運(yùn)行、并行處理多個(gè)任務(wù)，并在取得進(jìn)展時(shí)主動(dòng)反饋結(jié)果。

這種交互方式正逐漸脫離“結(jié)對(duì)編程”的模式，而更像是一種“任務(wù)編排”：你只需設(shè)定一個(gè)目標(biāo)，交給代理去執(zhí)行，稍后再回來(lái)查看進(jìn)度。

關(guān)鍵在于，這種變化不僅僅是“把工作交給 AI 做”，它還極大地壓縮了協(xié)調(diào)成本。過(guò)去，你需要提醒其他團(tuán)隊(duì)成員更新配置文件、排查錯(cuò)誤或重構(gòu)組件；而現(xiàn)在，開發(fā)者可以將這些任務(wù)直接指派給能夠理解意圖并在后臺(tái)執(zhí)行的代理。

原本需要同步會(huì)議、跨職能交接或冗長(zhǎng)評(píng)審周期的工作，現(xiàn)在可能演變?yōu)橐环N持續(xù)進(jìn)行的“請(qǐng)求—生成—驗(yàn)證”循環(huán)。

與此同時(shí)，與代理交互的方式也在不斷擴(kuò)展。除了在IDE或命令行中輸入提示詞之外，開發(fā)者還可以通過(guò)以下方式與代理互動(dòng)：

• 在 Slack 中發(fā)送消息
• 在 Figma 設(shè)計(jì)稿中添加評(píng)論
• 在代碼差異或 Pull Request 中插入內(nèi)聯(lián)注釋（例如 Graphite 的評(píng)審助手）
• 根據(jù)部署后的應(yīng)用預(yù)覽提供反饋
• 使用語(yǔ)音或通話接口，用口頭描述來(lái)進(jìn)行更改

這形成了一種全新的開發(fā)模型：AI代理貫穿整個(gè)開發(fā)生命周期。它們不只是寫代碼，還能解讀設(shè)計(jì)、響應(yīng)反饋、跨平臺(tái)排查Bug。而開發(fā)者則轉(zhuǎn)變?yōu)椤爸笓]者”，決定哪些任務(wù)線程繼續(xù)推進(jìn)、放棄或合并。

也許在未來(lái)，這種“分支+委托”的代理模型將成為新的Git分支——不再是靜態(tài)的代碼分叉，而是圍繞意圖動(dòng)態(tài)運(yùn)行的異步任務(wù)流，直到準(zhǔn)備就緒才合并落地。

08 MCP距離成為通用標(biāo)準(zhǔn)又近了一步

我們最近發(fā)布了一篇關(guān)于 MCP（Model Communication Protocol，模型通信協(xié)議）的深度解析。自那之后，該領(lǐng)域的發(fā)展勢(shì)頭明顯加快：

OpenAI公開采用了MCP，規(guī)范中也合并了若干新功能，越來(lái)越多的工具開發(fā)者開始將其視為 AI 代理與現(xiàn)實(shí)世界交互的默認(rèn)接口。

從本質(zhì)上講，MCP 解決了兩個(gè)關(guān)鍵問(wèn)題：

第一，為 LLM 提供完成任務(wù)所需的上下文信息，即便這些任務(wù)是它之前從未遇到過(guò)的；

第二，取代原本N×M的定制化集成方式，取而代之的是一個(gè)清晰、模塊化的模型：工具通過(guò)暴露標(biāo)準(zhǔn)接口（稱為“服務(wù)器”），可以被任意代理（“客戶端”）使用。

我們預(yù)計(jì)，隨著遠(yuǎn)程MCP支持和事實(shí)上的注冊(cè)中心（registry）逐步上線，其采用范圍將進(jìn)一步擴(kuò)大。從長(zhǎng)遠(yuǎn)來(lái)看，應(yīng)用程序可能會(huì)默認(rèn)集成MCP接口，就像今天許多服務(wù)默認(rèn)提供API一樣。

想想看，API是如何讓SaaS產(chǎn)品之間相互連接，并在不同工具間構(gòu)建可組合的工作流的。MCP 可以為AI代理實(shí)現(xiàn)類似的互聯(lián)互通 —— 它將原本孤立的工具轉(zhuǎn)變?yōu)榭苫ゲ僮鞯臉?gòu)建模塊。一個(gè)內(nèi)置了MCP客戶端的平臺(tái)，不只是“具備 AI 能力”，更是融入了一個(gè)更大的生態(tài)系統(tǒng)，能夠立即接入不斷增長(zhǎng)的、代理可訪問(wèn)的能力網(wǎng)絡(luò)。

此外，MCP的客戶端和服務(wù)器是邏輯邊界，而非物理隔離。這意味著，任何客戶端也可以作為服務(wù)器運(yùn)行，反之亦然。這種設(shè)計(jì)理論上可以解鎖一種強(qiáng)大的“可組合性”：一個(gè)通過(guò)MCP客戶端獲取上下文的代理，也可以通過(guò)服務(wù)器接口開放自己的功能。

例如，一個(gè)編碼代理可以作為客戶端去獲取GitHub上的問(wèn)題（issues），同時(shí)也可以把自己注冊(cè)為服務(wù)器，向其他代理公開測(cè)試覆蓋率或代碼分析結(jié)果。

09 基礎(chǔ)能力模塊化

隨著氛圍編碼代理功能日益強(qiáng)大，有一點(diǎn)變得清晰起來(lái)：代理可以生成大量代碼，但它們?nèi)匀恍枰恍┛煽康慕涌趤?lái)支持。

就像人類開發(fā)者依賴 Stripe 實(shí)現(xiàn)支付、使用 Clerk 處理認(rèn)證、或通過(guò) Supabase獲取數(shù)據(jù)庫(kù)能力一樣，AI 代理也需要類似這樣清晰、可組合的服務(wù)基礎(chǔ)模塊，才能構(gòu)建出穩(wěn)定可靠的應(yīng)用。

在很多方面，這些服務(wù)——具有明確邊界、提供友好SDK、并具備合理默認(rèn)值以減少出錯(cuò)可能的服務(wù)——正日益成為AI代理的運(yùn)行時(shí)接口。

如果你正在構(gòu)建一個(gè)能生成SaaS應(yīng)用的工具，你肯定不希望你的代理自己寫一套認(rèn)證系統(tǒng)，或者從頭實(shí)現(xiàn)計(jì)費(fèi)邏輯；你希望它直接使用像 Clerk 和 Stripe 這樣的成熟服務(wù)。

隨著這種模式逐漸成熟，我們可能會(huì)看到越來(lái)越多的服務(wù)開始為AI代理優(yōu)化自身體驗(yàn)：除了開放API，還提供數(shù)據(jù)結(jié)構(gòu)定義（schema）、能力元數(shù)據(jù)（capability metadata）以及示例流程（example flows），幫助代理更穩(wěn)定地集成和使用這些服務(wù)。

一些服務(wù)甚至可能默認(rèn)內(nèi)置MCP服務(wù)器，將每一個(gè)核心功能模塊轉(zhuǎn)變?yōu)锳I代理可以直接理解和安全調(diào)用的組件。想象一下，Clerk提供了一個(gè)MCP服務(wù)器，允許代理查詢可用產(chǎn)品、創(chuàng)建新的計(jì)費(fèi)計(jì)劃、或更新客戶的訂閱信息——所有操作都預(yù)先定義了權(quán)限范圍和約束條件。

這樣一來(lái)，代理無(wú)需手動(dòng)編寫API調(diào)用或翻閱文檔查找方法，而是可以直接說(shuō)：“創(chuàng)建一個(gè)每月49美元的‘Pro’套餐，并支持基于用量的超額費(fèi)用。”

而Clerk的MCP服務(wù)器會(huì)公開這一能力、驗(yàn)證參數(shù)并安全地處理編排。

正如早期Web開發(fā)時(shí)代需要Rails的生成器和rails new來(lái)加速開發(fā)，AI代理時(shí)代也需要值得信賴的基礎(chǔ)模塊：即插即用的身份系統(tǒng)、使用追蹤、計(jì)費(fèi)邏輯和訪問(wèn)控制機(jī)制——這些模塊不僅要足夠抽象以便于代碼生成，還要足夠靈活，能夠隨著應(yīng)用一起成長(zhǎng)。

10 總結(jié)

這些趨勢(shì)指向了一個(gè)更廣泛的轉(zhuǎn)變：隨著基礎(chǔ)模型能力的不斷增強(qiáng)，開發(fā)者的行為模式也在隨之演變。作為回應(yīng)，我們正看到諸如MCP之類的新工具鏈和協(xié)議逐漸成形。

這不僅僅是將AI疊加在舊有的工作流程之上，而是一場(chǎng)對(duì)軟件構(gòu)建方式的重新定義——以代理、上下文和意圖為核心來(lái)構(gòu)建軟件。許多面向開發(fā)者的工具層正在發(fā)生根本性的變化，我們非常期待參與并投資于下一代開發(fā)工具的建設(shè)與成長(zhǎng)。