MCP峰會3天敲定OAuth 2.1

Python MCP SDK上次更新還是1月24日。68天零版本迭代，TypeScript那邊卻連發了多個更新——這種落差讓用Python寫AI工具的人心里沒底。4月2日紐約峰會開幕當天，v1.27.0終于推送，同時V2開發狀態首次公開。如果你正在用Python搭MCP服務，這次更新直接決定了你接下來半年的代碼該怎么寫。

v1.27.0的四個補丁，全是V2的"提前劇透"

新版本沒搞大動作，但每個改動都指向同一件事：V2分支已經成熟到可以往v1.x回搬功能了。

OAuth資源驗證（RFC 8707）是這次的頭號更新。它解決的是客戶端問題——當你的MCP工具需要訪問多個資源服務器時，怎么讓令牌帶上明確的資源標識。StreamableHTTP會話加了空閑超時，TasksCallCapability從V2分支直接backport，還有主分支的合規測試集成。這些backport不是修bug的權宜之計，是V2功能穩定到能下沉的信號。

換句話說，V2不是PPT狀態，是已經跑在main分支上的實時代碼。

但別急著切分支。Python V2沒有發布時間表，官方口徑是"積極開發中"，最早Q3前別指望有能用的release。TypeScript那邊倒是快：峰會前一天剛發了v2.0.0-alpha.1和alpha.2，Standard Schema支持、重構的TaskManager、Fastify框架包全上了。Python的V2顯然還在pre-alpha，兩邊進度差著至少一個季度。

OAuth 2.1成為共識：不是新方案，是老標準終于被認真對待

認證軌道六場session的核心信息高度一致——MCP不需要發明新認證協議，把OAuth 2.1用對就行。

Aaron Parecki的session標題定調了："Evolution, Not Revolution"。作為OAuth 2.1 spec作者和Okta身份標準總監，他的立場一直很明確：別在MCP里過度設計認證，標準OAuth 2.1加PKCE，正確實現現有RFC，收工。六場專門討論這個，不是認證方案還在搖擺，是生態終于統一口徑了。

對寫代碼的人來說，這意味著mcp.server.auth的當前API就是終局形態。v1.27.0里BearerAuth（BearerAuthProvider、BearerAuthBackend）零變動，相關PR沒合進去，V2的auth API調整也沒宣布。RFC 8707影響的是OAuth客戶端側的資源綁定，你的服務端代碼不用動。

如果你這周新開MCP服務項目，現在的mcp.server.auth寫法就是V2要標準化的模式——不是臨時方案，是未來兼容的基準。

TypeScript先跑半步，Python開發者的實際策略

兩邊SDK的分化已經很明顯。TypeScript的V2 alpha帶著Zod v4/Valibot/ArkType的Standard Schema兼容性、全新的Fastify包，架構層面在做減法（廢棄方法清理、TaskManager重構）。Python這邊還在把V2的功能往v1.x搬運，說明底層結構還在定型。

務實的做法是：繼續用v1.27.0的auth模式寫新代碼，別等V2重構。峰會釋放的信號足夠清晰——當前API不會被推翻，V2是演進不是革命。OAuth 2.1的共識也意味著認證層不會有顛覆性變化，你可以放心把精力放在業務邏輯上。

那個68天的版本空窗期，現在看像是團隊在憋V2的架構定型。v1.27.0的backport策略很聰明：讓生產環境的開發者提前用上經過驗證的功能，同時給V2主分支爭取更多測試時間。

Max Isbey在4月3日的演講里沒給V2時間表，但main分支的活躍度和backport的頻率說明一件事——Python V2的代碼每天都在跑，只是還沒到能貼版本號的程度。對于討厭踩坑的Python開發者，這其實是好消息：等它正式發布的時候，你遷移的成本會比TypeScript早期采用者低得多。

你現在用mcp.server.auth寫的每一行代碼，都是在給V2的終局形態做預演——這算是68天等待換來的確定性嗎？