auto-webmcp 的 v0.3.0 版本在 48 小時(shí)內(nèi)緊急上線，核心團(tuán)隊(duì)用了一個(gè)周末處理了過去兩年 AI 代理在網(wǎng)頁表單領(lǐng)域積攢的所有臟活。這不是功能迭代，更像是一份給 React 開發(fā)者的道歉信——你們寫的表單，AI 根本填不了。

項(xiàng)目創(chuàng)始人把首版定位說得干脆：丟一個(gè) script 標(biāo)簽，頁面上所有表單自動(dòng)變成 AI 可調(diào)用的工具，不用手寫 JSON Schema。這個(gè)承諾在原生 HTML 上成立，但在 React 生態(tài)里近乎失效。v0.3.0 的更新日志本質(zhì)上是一份"React 表單兼容性勘誤表"，逐條列出框架與 AI 代理之間的通信故障。

React 的"假輸入"陷阱：DOM 變了，狀態(tài)沒動(dòng)

React 用合成事件系統(tǒng)攔截所有輸入行為。直接執(zhí)行 input.value = 'foo'，DOM 確實(shí)變了，但 React 內(nèi)部狀態(tài)仍認(rèn)為字段為空。表單提交時(shí)，數(shù)據(jù)包里是空白值。這種"視覺欺騙"讓早期 auto-webmcp 用戶在調(diào)試時(shí)崩潰——看著填好的表單，AI 卻收到"未填寫"的反饋。

v0.3.0 的解法是從原型鏈底層繞過 React。團(tuán)隊(duì)提取 HTMLInputElement.prototype 的原生 value 描述符，手動(dòng)觸發(fā)輸入事件，讓 React 的 onChange 誤以為用戶真的敲了鍵盤：

// 內(nèi)部處理 React 受控輸入的邏輯 const nativeSetter = Object.getOwnPropertyDescriptor( HTMLInputElement.prototype, 'value' ).set; nativeSetter.call(input, value); input.dispatchEvent(new Event('input', { bubbles: true }));

對(duì)使用 execCommand 的老式富文本編輯器，則回退到 document.execCommand('insertText', false, value)。兩種路徑覆蓋了近 95% 的生產(chǎn)環(huán)境表單實(shí)現(xiàn)方式。

更隱蔽的 bug 發(fā)生在提交瞬間。AI 填完表單觸發(fā) React 重渲染，組件可能在 submit 事件前重置字段值。v0.3.0 在填充后立即捕獲 DOM 快照，用快照構(gòu)建響應(yīng)而非重新查詢實(shí)時(shí) DOM——這是給 React 的競(jìng)態(tài)條件打補(bǔ)丁。

懶加載的多步表單也有對(duì)策。MutationObserver 的重新分析加了防抖，新字段出現(xiàn)時(shí)自動(dòng)更新 schema，不重復(fù)注冊(cè)工具。這種設(shè)計(jì)針對(duì) React 常見的條件渲染模式：第二步表單在點(diǎn)擊"下一步"后才掛載。

ARIA 角色：AI 終于能"看見"自定義組件

現(xiàn)代網(wǎng)頁的輸入控件大量脫離原生 input 標(biāo)簽。富文本編輯器、自定義下拉菜單、日期選擇器——它們用 role="textbox"、role="combobox"、role="spinbutton" 向屏幕閱讀器描述語義。auto-webmcp v0.3.0 開始讀取這些信號(hào)。

任何帶 ARIA 輸入角色的元素現(xiàn)在會(huì)被納入 schema，字段名從 aria-label 或關(guān)聯(lián)的 label 元素推斷。沒有 name 屬性的輸入（React 中常見，表單狀態(tài)存于 JS 而非 DOM）改用 id 或 aria-label 作為鍵，確保 AI 代理仍能按名引用。

一個(gè)具體修復(fù)：Ghost 博客的新聞?dòng)嗛啽韱斡昧?input type="email"，無 name、無 id，只有 placeholder。舊版直接忽略這類輸入，v0.3.0 將 placeholder 同時(shí)作為字段鍵和標(biāo)題，讓幽靈博客的訂閱表單徹底可被 AI 調(diào)用。

WebMCP 規(guī)范：讓工具對(duì)代理"更有用"

v0.3.0 同步實(shí)現(xiàn)了新版 WebMCP 規(guī)范的字段擴(kuò)展。這些字段不直接影響表單填充，但顯著改變 AI 代理對(duì)工具的理解方式——比如描述字段用途、標(biāo)注必填項(xiàng)、定義輸出格式。規(guī)范合規(guī)意味著 auto-webmcp 生成的工具能被更廣泛的代理生態(tài)識(shí)別。

項(xiàng)目團(tuán)隊(duì)在更新公告中沒提具體數(shù)字，但 GitHub 提交記錄顯示：72 小時(shí)內(nèi)合并 17 個(gè) PR，處理 23 個(gè) issue，其中 14 個(gè)與 React 相關(guān)。這個(gè)節(jié)奏接近創(chuàng)業(yè)公司的"生死時(shí)速"，而非成熟項(xiàng)目的穩(wěn)定迭代。

auto-webmcp 的困境折射整個(gè) AI 代理行業(yè)的盲區(qū)：大家忙著做"大腦"，卻沒人愿意修"手腳"。網(wǎng)頁表單是互聯(lián)網(wǎng)最古老的基礎(chǔ)設(shè)施，但 AI 代理與前端框架的兼容性問題被擱置了兩年——直到有人發(fā)現(xiàn)，讓代理訂一張機(jī)票或填一份報(bào)銷單，比讓它寫代碼更難。

v0.3.0 的發(fā)布說明結(jié)尾留了一個(gè)未解問題：Vue 3 的組合式 API 表單、Svelte 的綁定語法、Solid 的細(xì)粒度響應(yīng)式——這些框架的輸入劫持機(jī)制各不相同。React 只是第一個(gè)被攻克的堡壘，還是唯一值得優(yōu)先處理的堡壘？團(tuán)隊(duì)沒給時(shí)間表，但 issue 列表里已經(jīng)有人提交了 Angular 表單的復(fù)現(xiàn)案例。