WebMCP Challenge 開跑：OpenAI 用 10 天挑戰「讓網站直接給 AI Agent 使用」
WebMCP Challenge 不只是一場 35,000 美元競賽，更在測試網站如何從給人操作，轉向讓人與 AI Agent 共同操作。
OpenAI 宣布舉辦為期 10 天的 WebMCP Challenge，邀請開發者打造能讓人類與 AI Agent 一起操作的網站。活動由 OpenAI 與 Google Chrome、Cloudflare、Shopify、Vercel、Render、Netlify 共同支持，總現金獎金為 35,000 美元。
獎金只是表面。這場比賽真正值得注意的地方，是 OpenAI 正在推動一種新的網站設計方式：網站不只做給人看，也要主動告訴 AI Agent「我有哪些功能、需要哪些資料、該怎麼執行」。
如果這個方向成為主流，未來的網站除了按鈕、表單與選單，還會多出一層給 AI Agent 使用的結構化介面。WebMCP Challenge 就是一次公開測試，看看這種「Agent 原生網站」能不能做出比一般瀏覽器自動化更可靠的體驗。
WebMCP Challenge 官方活動影片。影片來源：OpenAI Developers 官方 X 貼文。
WebMCP 是什麼？
WebMCP 是一項仍在實驗階段的開放網頁規格。它讓網站把搜尋、預約、填表、購物或資料查詢等功能，註冊成 AI Agent 可以辨識與呼叫的「工具」。AI Agent 是能理解目標並代替使用者採取行動的 AI 助手。
目前的瀏覽器 Agent 多半要先看懂網頁，再模擬滑鼠點擊與鍵盤輸入。按鈕位置一改、欄位名稱不清楚，流程就可能失敗。WebMCP 改成由網站直接提供工具名稱、功能說明、輸入格式與執行方法，Agent 不必再猜畫面上每個元素的用途。
例如，訂位網站可以提供 search_tables 與 confirm_booking 兩個工具。Agent 先查詢可用時段，取得使用者確認後再完成預約。這比讓 Agent 在日期選擇器、下拉選單與確認頁面之間反覆點擊，更容易控制，也更方便驗證結果。
我的看法偏正面。WebMCP 解決的是瀏覽器 Agent 最實際的痛點：不是模型能不能看懂畫面，而是網站能不能提供穩定、可預期的操作方式。不過它目前仍是 Web Machine Learning Community Group 發布的草案，並不是正式的 W3C 標準，技術介面與安全設計都可能繼續變動。
WebMCP 與傳統 MCP 有什麼不同？
MCP（Model Context Protocol）是一套讓 AI 應用連接外部工具與資料的協定。一般 MCP Server 通常在後端或獨立服務中執行，AI 客戶端透過連線呼叫工具。
WebMCP 則把工具放進正在瀏覽的網頁。網站可以用 JavaScript 註冊功能，也可以替既有的 HTML 表單加上結構化描述，讓瀏覽器內的 Agent 在目前頁面直接使用。兩者概念相近，但 WebMCP 規格本身並沒有要求瀏覽器一定要透過 MCP 傳輸工具呼叫。
對產品團隊來說，最簡單的理解是：應用程式介面（API）讓不同程式交換資料與呼叫功能，一般網站介面給人使用，WebMCP 則試著讓同一個網站也能被 Agent 穩定操作。
WebMCP Challenge 活動時間與獎項
WebMCP Challenge 已於美國太平洋時間 2026 年 8 月 25 日中午開放報名與投稿。官方頁面列出的投稿截止時間為 9 月 3 日下午 1 點，換算台灣時間是 9 月 4 日凌晨 4 點。得獎名單預計於 9 月 23 日公布，但官方保留依投稿數量調整日期的權利。
| 項目 | 官方資訊 |
|---|---|
| 活動形式 | 線上 Hackathon，可個人、團隊或組織參加 |
| 投稿截止 | 台灣時間 2026 年 9 月 4 日凌晨 4 點 |
| 得獎名額 | 10 組 |
| OpenAI 現金獎金 | 每組 3,000 美元 |
| Netlify 現金獎金 | 每組 500 美元 |
| 其他主要獎項 | Codex Micro、ChatGPT Pro 一年、OpenAI 周邊與合作廠商服務額度 |
35,000 美元現金的組成，是 10 組得主各獲得 OpenAI 提供的 3,000 美元，以及 Netlify 提供的 500 美元。其他獎項還包括每組最高 10,000 美元的 Cloudflare 額度、Vercel 與 Render 額度、Shopify 周邊，以及 Google AI Ultra 三個月訂閱。
台灣列在 OpenAI API 支援國家與地區名單內，也不在活動規則列出的排除地區。不過參賽者仍需達到居住地的法定成年年齡，並以 Devpost 的完整規則與資格審查結果為準。
要做什麼作品？舊產品也能參加
參賽作品必須是一個可運作的 WebMCP 網站，重點是讓人與 Agent 能在同一個使用情境中協作。可以從零開始做新產品，也可以替既有網站加入 WebMCP，但若使用舊專案，必須用提交紀錄等資料清楚區分原有功能與活動期間新增的部分。
投稿時需要準備四項內容：
- 評審可以開啟的網站網址。
- 說明使用情境、使用 WebMCP 的原因、使用者體驗改善與實作方式的英文介紹。
- 公開的 GitHub、GitLab 或 Bitbucket 程式碼倉庫，並附上可辨識的開源授權。
- 少於 3 分鐘、公開上傳至 YouTube 的英文語音 Demo，或附有英文翻譯的影片。
網站可以部署在 ChatGPT Sites、Cloudflare、Vercel、Render、Netlify、Shopify 或其他平台，不限定一定要使用 OpenAI 的付費開發工具。測試時可使用內建支援 WebMCP 的 ChatGPT in-app browser，或在 Chrome 149 以上版本開啟實驗功能開關。
真正的門檻不是把程式跑起來，而是讓評審能在很短的時間內重現價值。作品網址、測試帳號、README 與 Demo 影片只要有一處斷掉，再好的概念也可能無法進入深入評選。
最小實作長什麼樣子？
網站可以透過 document.modelContext.registerTool() 註冊一個工具。下面用商品搜尋做簡化示意：
document.modelContext.registerTool({
name: "search_products",
description: "依關鍵字搜尋商品目錄",
inputSchema: {
type: "object",
properties: {
query: { type: "string" }
},
required: ["query"]
},
execute: async ({ query }) => searchProducts(query),
annotations: {
readOnlyHint: true
}
});
inputSchema 是一份輸入格式說明，告訴 Agent 要傳入哪些欄位與資料類型。execute 則連接網站原本的功能。readOnlyHint 用來提示這個工具只讀取資料，不會改變購物車、訂單或帳號狀態。
這段程式不難，難的是工具邊界。搜尋與篩選可以直接執行，但送出訊息、取消訂單與付款等動作，需要清楚的確認流程、錯誤回傳與權限控制。WebMCP 規格也把提示詞注入（Prompt Injection）列為重要風險，也就是惡意內容試圖誤導 Agent 改變任務。其他風險還包括工具描述與實際行為不一致，以及敏感資料洩漏。
因此，我不建議參賽者一開始就做全自動付款。更實際的 MVP 是先完成「讀取 → 提議 → 使用者確認 → 執行」的一條完整流程，再用畫面證明 Agent 與使用者共享同一份狀態。
評審看什麼？不是接上 WebMCP 就會得獎
官方將第二階段的評分分成四個等權重項目：WebMCP 使用深度、完成度、潛在影響，以及創意與企圖心。這代表只把一般按鈕包成工具，未必能得到高分。
1. WebMCP 必須真的比點畫面更合理
適合的題目通常有多個欄位、複雜狀態或容易誤操作的流程，例如多人旅行規劃、客服問題診斷、電商商品比較、資料探索或申請表填寫。若任務原本只要按一個按鈕，WebMCP 帶來的改善很難被看見。
2. 做完一條流程，比做十個半成品工具重要
官方把完整、連貫的產品體驗列為評分標準。以 10 天的時程來看，我會先鎖定一種使用者、一個高摩擦任務與一個可量化結果，例如把 12 個人工操作步驟縮短成 3 次 Agent 工具呼叫。
3. 人與 Agent 要各自有清楚角色
WebMCP Challenge 要找的不是「把人完全拿掉」，而是讓雙方一起完成以前很麻煩的工作。Agent 適合整理選項、填入資料與檢查限制，使用者則保留偏好判斷與敏感操作的最後確認。Demo 若能清楚呈現這個分工，會比單純展示自動點擊更符合題目。
4. 評審可能只看文字與影片
官方規則指出，評審不一定會實際測試網站，也可能只依文字、圖片與 Demo 影片評分。因此，影片前 30 秒就應交代「誰遇到什麼問題」，接著用同一個案例比較沒有 WebMCP 與使用 WebMCP 的差別，最後才說明技術細節。
我會推薦哪三種參賽題目？
如果目標是在 10 天內完成，我會優先選擇已經有資料與操作流程的產品，而不是重新打造大型平台。
第一種是「客服診斷助手」。網站提供查詢帳號狀態、執行檢測與建立客服單等工具，Agent 先整理問題，再請使用者確認要送出的資料。這類題目容易展現結構化輸入、錯誤處理與人類確認。
第二種是「複雜表單協作」。例如獎學金申請、保險需求整理或活動報名。Agent 可以從對話整理資料、找出缺漏，再把內容映射到表單欄位，但送出前仍由使用者檢查。這能直接呈現 WebMCP 比畫面辨識可靠的地方。
第三種是「多條件比較與決策」。例如旅遊行程、SaaS 方案或商品組合。Agent 呼叫網站提供的篩選、比較與儲存工具，使用者則在畫面上調整偏好。這種題目最容易做出真正的共同操作感。
三者之中，我最推薦客服診斷助手。原因不是它最炫，而是資料讀取、狀態判斷、敏感操作確認與錯誤處理都能在一個短 Demo 裡呈現，正好覆蓋評審重視的 WebMCP 深度與產品完成度。
WebMCP 現在最大的限制
WebMCP 有潛力，但目前不適合被描述成已經成熟的網路標準。Chrome 目前透過 Origin Trial 讓網站在正式支援前申請測試，也提供本機實驗功能開關。官方文件明確指出規格仍在討論，未來可能改變。
它也不是讓網站「自動支援所有 Agent」的魔法層。瀏覽器必須先開啟網站，才會知道頁面提供哪些工具。複雜網站仍可能需要重構狀態管理。Headless Browser 是沒有一般視窗介面的自動化瀏覽器，這類沒有真人參與的環境也不是 WebMCP 目前的主要設計目標。
安全問題同樣不能忽略。Agent 可能繼承使用者的登入狀態，工具描述可能隱藏惡意指令，回傳資料也可能造成 Prompt Injection。網站端仍要驗證輸入、限制權限、記錄重要操作，並讓付款、傳訊與刪除等高風險行為保留明確確認。
這些限制不會推翻我對 WebMCP 的正面看法，但會改變實作順序。現在值得做的是小範圍試驗與建立經驗，不是把整個產品介面一次改寫。等主要瀏覽器正式支援、API 趨於穩定，而且權限與身分驗證形成一致做法後，才適合擴大到核心交易流程。
結論：這不只是一場 Hackathon，而是網站介面的新測試
WebMCP Challenge 最值得觀察的，不是 35,000 美元獎金，而是 OpenAI、Google Chrome 與多家雲端平台正在共同測試一個問題：當 AI Agent 成為網站使用者，網站是否應該主動提供可呼叫的工具，而不只提供給人看的畫面？
我的結論是，這個方向值得開發者現在投入小型實驗。WebMCP 還沒成熟，卻已經足以驗證哪些流程適合人與 Agent 協作。對想參賽的人來說，最實際的策略不是追求功能數量，而是選一個原本容易失敗的網站任務，把工具定義、使用者確認、錯誤處理與 Demo 做完整。
活動投稿將於台灣時間 2026 年 9 月 4 日凌晨 4 點截止，可前往 WebMCP Challenge 官方頁面了解活動，並透過 Devpost報名與投稿。
WebMCP Challenge 常見問題
WebMCP Challenge 的總獎金是多少？
活動提供 35,000 美元現金獎金，共選出 10 組得主。每組可獲得 OpenAI 的 3,000 美元與 Netlify 的 500 美元，另有 Codex Micro、ChatGPT Pro 一年與合作廠商服務額度。
台灣開發者可以參加嗎？
台灣在 OpenAI API 支援地區名單內，也未列於活動排除地區。個人仍需達到台灣的法定成年年齡，團隊或組織則要指定代表人，最終資格以 Devpost 完整規則及主辦方審核為準。
一定要做全新的網站嗎？
不用。官方允許替既有產品加入 WebMCP，但需要清楚記錄活動期間新增的功能，例如保留有日期的 Git commit，證明專案在比賽期間獲得實質擴充。
一定要使用 Codex 或 OpenAI API 嗎？
不用。官方允許使用其他開發工具與部署平台。參賽作品的必要條件是實際使用 WebMCP，並能在 ChatGPT in-app browser 或開啟 WebMCP 的 Chrome 中操作。
WebMCP 已經是正式 W3C 標準嗎？
不是。WebMCP 目前是 Web Machine Learning Community Group 發布的 Draft Community Group Report，不是 W3C 標準，也不在 W3C Standards Track 上。開發者應把它視為正在形成中的實驗規格。
