2026-08-07 — Cloudflare 推出無狀態的 MCP v2 與瀏覽器原生 WebMCP、Google 定義跨平台 Agent Plugins 封裝規格、Microsoft 用 Entra 聯合憑證取代 Azure DevOps 的 PAT

Cloudflare 重整 Agent 基礎設施：MCP v2 拿掉 Session 狀態，WebMCP 把工具接口植入瀏覽器

Cloudflare Blog · 2026-08-06

Cloudflare 於 2026 年 8 月 6 日發布一系列以 AI agent 為對象的基礎設施更新，核心是兩個技術動作：協定層的 MCP 進版到 v2，以及在瀏覽器端新增 WebMCP API。兩者分別解決 agent 與伺服器、agent 與網頁互動時的不同瓶頸。

原本的問題

MCP（Model Context Protocol）v1 要求用戶端與伺服器先完成 initialize/initialized 交握，伺服器再配發 Mcp-Session-Id，之後的請求都得綁在同一個長生命週期連線上。這種設計在 serverless 環境裡很難落地：Cloudflare Workers 這類依請求建立、處理完即回收的執行環境，沒有地方安放這個 session 狀態。另一方面，agent 若要操作一般網頁，過去只能靠解析 HTML 或截圖辨識畫面元素，沒有顯式的工具合約可用。

採用的方法

MCP v2 把協定改成無狀態：每個請求自帶協定版本、用戶端身分與能力宣告，不再依賴前一次交握留下的狀態。伺服器需要額外輸入時（例如部署前的人工核准），回傳 input_required 結果，用戶端蒐集輸入後重試，取代原本需要保持串流開啟的 elicitation 機制，官方稱為 MRTR（Multi-Round-Trip Requests）。請求也新增 Mcp-Protocol-Version、Mcp-Method、Mcp-Name 等 HTTP header，讓閘道與 WAF 不必解析 JSON payload 就能依工具名稱做路由或限流。資源項目另外帶上 ttlMs 與 cacheScope，讓快取行為可預期。

import { McpServer } from "@modelcontextprotocol/server";
import { createMcpHandler } from "agents/mcp/server";

const server = new McpServer({ name: "hello-server", version: "1.0.0" });
server.registerTool("hello", { inputSchema: { name: z.string().optional() } },
  async ({ name }) => ({ content: [{ type: "text", text: `Hello, ${name ?? "World"}!` }] }));

export default {
  fetch(request, env, ctx) {
    return createMcpHandler(() => server)(request, env, ctx);
  }
};

面向瀏覽器的 WebMCP 則是讓網頁自己用 document.modelContext.registerTool() 註冊工具，agent 不再需要爬 DOM 猜測按鈕位置，工具直接在頁面的 JavaScript context 內執行，可以沿用使用者原本的登入 session。

document.modelContext.registerTool({
  name: "add-todo",
  inputSchema: { type: "object", properties: { text: { type: "string" } }, required: ["text"] },
  async execute({ text }) {
    await addTodoItemToCollection(text);
    return { content: [{ type: "text", text: `Added: "${text}"` }] };
  }
});

實際效果

MCP v2 是 Anthropic 發起、目前由 Agentic AI Foundation 管理的產業標準更新，Cloudflare 這次的貢獻是把官方 TypeScript SDK 重寫成基於 Web Standards，並在 Cloudflare Agents SDK 中包一層 Worker 專用的預設值。認證方面 v2 優先採用預先註冊的用戶端，動態註冊場景改用 CIMD（Client ID Metadata Documents），原本的 DCR（Dynamic Client Registration）列為棄用，預計 2027 夏天後移除，同時導入 RFC 9207 的 issuer 識別以避免授權回應混淆。

棄用清單還包含 Roots、Sampling、Logging 與舊版 HTTP+SSE 傳輸，依政策至少保留 12 個月才會真正移除；新能力則先進入 extensions 框架（如 MCP Apps、Enterprise-Managed Authorization、Tasks），不會直接併入核心規格。

原始來源：Building an open Agentic Internet、MCP v2

Google 訂出 Agent Plugins 規格：把 Skill 與 MCP Server 打包成同一個外掛

Google Developers Blog · 2026-08-06

Google 於 2026 年 8 月 6 日公布 Agent Plugins v1.0.0 規格，由 Google DeepMind 與 Google Cloud 團隊共同撰寫。這是一份開放、廠商中立的封裝格式，把 Agent Skills 與 MCP server 打包進單一目錄結構，目標是讓同一套外掛能不改內容就裝進不同的 agent 用戶端。

原本的問題

問題不在 Agent Skills 或 MCP server 本身——這兩種元件各自已經可攜。真正卡住的是「裝它們的盒子」：每個 client 對目錄結構、manifest 格式、MCP 設定形狀的要求都不一樣。開發者為了讓同一個外掛在多個 client 上跑，得維護好幾份幾乎一樣的複製版本，久了就彼此漂移、難以同步修正。

採用的方法

Agent Plugins 選擇用固定路徑取代彈性設定：Skill 一定放在 skills/ 子目錄下，遵循 Agent Skills 規格；MCP server 一定寫在 mcp.json，並明講傳輸型態是 stdio、Streamable HTTP，或舊式的 HTTP+SSE。plugin.json 只要求最少的必填欄位。

reports-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "reports-plugin"
}

規格本身不處理安裝機制、散布協定、權限模型或沙箱與信任驗證——這些被明講列為未來考慮項目，而非被悄悄省略。client 專屬的擴充則透過反向網域命名的資料夾（例如 com.example.client/）放置，元件之間刻意互不依賴失敗：一個壞掉的 MCP server 不會連帶讓同包裡的 Skill 失效。

實際效果

Google 自家的 Agents CLI 與 Data Agent Kit 已經改用這個格式發佈：前者打包用來建置與維運 agent 的專家技能，後者提供連到 BigQuery、Spanner、Cloud SQL 的 Skill 與 MCP server。Google 表示現在的封裝形式「不只是我們自己在用」，同一份外掛可以裝進 Antigravity、Gemini CLI、Claude Code 與 Cursor。

Agent Plugins 被定位成整個生態系裡的其中一層：找資源交給 Agentic Resource Discovery，描述資源交給 AI Catalog，實際執行合約仍是既有的 MCP 與 Agent Skills 規格，這份封裝格式只負責把它們裝進同一個可攜的容器。

原始來源：Agent Plugins package your skills, tools, and more

Azure DevOps 用 Service Connection 取代 PAT：Pipeline 驗證改走 Entra 聯合憑證

Microsoft DevBlogs · 2026-08-06

Microsoft 於 2026 年 8 月 6 日在 Azure DevOps 官方部落格宣布，pipeline 現在可以用 Service Connection 取代 PAT（Personal Access Token）或 build session token 做身分驗證。文章作者為 Eric van Wijk。

原本的問題

PAT 與 build session token 都是長生命週期的明文憑證：PAT 要人工建立、儲存、定期輪替，範圍常常綁在整個組織或整個 build service 帳號上，一旦外洩影響面很大；build session token 則是每次 build 產生的替代方案，但仍是需要另外管理的 secret。兩者都缺乏細緻的權限範圍控制。

採用的方法

新的 Service Connection 改用 Microsoft Entra 的 service principal 或 managed identity 搭配聯合憑證（federated credentials）授權，不需要在任何地方儲存密碼或長效 token。設定時先建立好 service principal 或 managed identity 並加入組織成員，之後在 pipeline 裡以 service connection 名稱引用即可。

resources:
  repositories:
  - repository: external-repo
    type: git
    endpoint: my-azdo-connection
    name: 'external-project/external-repo'

- task: AzureCLI@3
  inputs:
    connectionType: 'azureDevOps'
    azureDevOpsServiceConnection: 'my-azdo-connection'

REST API 呼叫（InvokeRESTAPI@1）與 template 參照也都能改吃 serviceConnection 參數，template 甚至可以把 connection 名稱當成 runtime parameter 傳入，而不是寫死在 YAML 裡。

實際效果

官方列出的效益包括免密碼（不必建立、儲存、輪替 PAT）、最小權限（可以做到單一 pipeline 甚至單一 task 等級的授權，取代原本共用的 build service 帳號）、以及所有驗證嘗試都會寫進 Azure DevOps 的稽核紀錄。若組織帳號沒有足夠的 Microsoft Graph 權限來自動建立聯合身分識別憑證，文章也提到可以退回手動設定，由管理員自行建立 federated identity credential 完成同樣的綁定。

原始來源：You can now use the Azure DevOps Service Connection instead of a PAT or Build Session token