WebMCP整合Domino與AI作業整合：老舊系統轉型的全新遊戲規則

 一、前言與背景：企業核心系統的AI轉型困境

近年AI Agent的發展蔚為風潮。過去當AI Agent執行網頁任務時，多半採用Backend-to-Backend的技術路線，然而，若要將大語言模型(LLM)引入既有的Domino工作流程表單，往往面臨一個巨大的挑戰，面對舊系統中錯綜複雜的後端業務邏輯、簽核關卡以及代代相傳的技術包袱，現有的整合程式很難在不觸動核心架構的前提下進行層層修改。

這樣的改造代價太過昂貴。不論是官方提供的DominoIQ或MCP(Model Context Protocol)，或是透過RAG(檢索增強生成)、模型微調、甚至重新開發系統，都免不了要對執行穩定的系統大刀闊斧地修改。這是目前開發人員都面臨的共同問題，一旦為了串接AI重新設計表單或大量重寫後端核心邏輯，隨之而來的回歸測試成本與資安風險將是開發人員最大的惡夢，也讓許多公司望而卻步。

二、橫空出世的WebMCP：輕量安全的頂級落實方案

這時就要提及剛橫空出世的WebMCP(Web Model Context Protocol)，這為老舊系統綁定AI帶來了全新的遊戲規則。簡單地說，WebMCP的核心優勢在於：

「幾乎完全不用對Domino原有表單程式或後端業務邏輯做任何更動」，僅需將簡單的前端程式置於副套表中，並只嵌入有AI用途的狀態及表單之中。這絕對是目前最輕量、最安全，也最理想的AI落實方案。

 WebMCP也是目前AI生態圈中最前衛的技術之一。它是針對瀏覽器提出的一項網頁標準草案，由Anthropic主導發展的MCP延伸而來的「前端網頁版」，讓前端開發者可以用結構化、標準化的方式，將網頁的功能「自我宣告」並暴露給AI Agent。

現階段技術限制： 在目前階段，使用者必須使用支援WebMCP的瀏覽器(目前只有Chrome的早期實驗版本，需開啟特定Flag)才可正常執行。

 三、實例：主管費用申請簽核自動化

為使大家更容易理解WebMCP的運作模式，我們以常見的「主管簽核費用申請單」作為範例。

• 傳統的簽核流程

過往申請單送至主管時，主管需根據申請單上的說明、類別及金額欄位值加以判斷後，手動   點選「核准」或「退回」按鈕，並在「簽核意見」欄位中自行輸入對應的意見說明。

[圖片1] 傳統簽核流程畫面 (包含核准、退回按鈕，以及待輸入的空白簽核意見欄位)

• 輕量化改造：安插AI副套表

接著，我們在表單最下方安插一個「副套表」，這個副套表只在特定的AI簽核狀態下(例如透過公式設定：@If(FlowNo="1";"sfAIAgent";""))才安全地被載入並計算。

[圖片2] 安插AI副套表與條件公式設計

• AI浮動面板與語音互動

當主管開啟表單時，前端程式會在畫面右下方固定一個飄浮的互動面板，此時便啟動了與AI的即時互動。

[圖片3] Domino AI助理浮動面板 (右下方固定出現的AI助理對話互動介面)

 主管可以直接透過語音或口語化的文字，指示助理該如何處理這張申請單。

[圖片4] 主管輸入直白口語化指令畫面

•  職場黑話翻譯與流程自動化

這AI助理也很懂人情世故，知道不能就這麼將直白粗魯的話送出去，於是開始動腦筋幫主管解讀。

[圖片5] AI正在幫主管翻譯職場黑話提示

 AI助理會自動將主管的口語指令「翻譯」為專業且符合公司規範的官腔說詞，並準備將表單退回給申請人。同時，面板會提供5秒倒數的緩衝時間，讓主管隨時可以按下「中止」反悔。

[圖片6] AI翻譯成果與自動退回5秒倒數畫面

 當倒數結束，我們讓申請人重新打開被退回的單子，可以看到「簽核意見」欄位已經過AI美化修飾，且表單已被正確、安全地執行「退回」流程。

[圖片7] 最終表單成功退回畫面 (簽核意見已帶入修飾後的官腔文字，狀態變更為退回)

 四、談HTML減肥與精準度

•  為什麼不用傳統AＩ抓取？

看到這裡您可能會問：「這不過是按個按鈕、填個欄位的事，為什麼要搞得這麼複雜？即使不使用WebMCP，單純把網頁丟給AI，不是也能做出判斷嗎？那WebMCP的價值在哪？」

答案就在「效能」與「準確性」。事實上，當那小小的Panel出現時，雖然已經將文件的原始碼傳至AI，AI僅憑此也足以做出主管要退回時的相關作業，但重點應該在於以下三個不可忽視的核心關鍵：

1. Domino原生渲染出的HTML非常臃腫，充斥著大量與業務邏輯無關的Style樣式表、後端自動產生的ViewState以及隱藏欄位。如果直接把整頁HTML塞給地端的Ollama模型，相當於讓AI每次對話都要讀取幾萬字的廢話。這會導致地端電腦的顯示卡瞬間滿載，AI的推理思考速度會從原本流暢的0.5秒暴跌到5秒以上。
2. 如果某些金額是主管打開網頁後才手動修改、或是透過JavaScript動態計算出來的，這些資料往往只存在於瀏覽器記憶體或輸入框的value屬性中。若AI只讀取後端傳回的靜態HTML原始碼，極有可能漏掉這些動態改變的即時數值。
3. 假設主管輸入指令：「金額超過1000就退回」，但該份費用申請單的結構同時飄浮著多個數字(如：車資小計$800、雜項小計$500、扣除折扣$-200、實付總金額$1100)。當AI吞下整頁HTML時，由於大語言模型本質上是在進行語義機率的猜測，在雜訊過多的情況下，它極有可能誤把「車資小計800」當成這張單子的主金額，進而做出「800沒有超過1000，所以不退回」的錯誤決策。

• WebMCP的解決之道：透過「工具宣告」實現精準的Tool Calling

WebMCP的核心精髓在於，大語言模型不再需要依整頁臃腫的HTML程式碼給出完整回應，而是透過標準化的方式，由AI「自我宣告」當前網頁所具備的自動化工具清單中，找出符合及其宣告的工具即可。在這個費用申請的案例中，前端只向AI宣告了兩個工具(例如ai_approve_document與ai_reject_document)，並在工具描述中明確定義了觸發條件與所需參數。

這樣做帶來了決定性的改變：

1. Token大幅減肥、推理速度飛快： AI只需要閱讀輕量化的工具定義與精簡的上下文，不再需要去啃幾萬字包含ViewState與Style的無用HTML，地端顯卡負載大減，速度自然流暢。

2. 100%的決策精準度： 由於AI的大腦被限縮在網頁明確宣告的「工具清單」與「參數規格」內，它不需要大海撈針似地去猜測網頁語義。當主管發出指令時，AI 能夠非常精準地進行工具調用，直接輸出要執行的工具名稱與美化後的參數內容，交由網頁端執行。這徹底杜絕了傳統AI抓取網頁時，因動態數值漏讀或多個數字干擾而產生幻覺的風險。

五、為什麼不採Chrome Extension方案？架構碰撞的經驗談

如前所述，WebMCP尚未正式套用至任何正式版本。Chrome裡面有一個隱藏的「實驗功能開關頁面」，所有Flag預設全都是關閉，若要使用，得先將中的WebMCP Flag開啟。

[圖片8] Chrome實驗性功能Flag開啟頁面 (啟用WebMCP support in DevTools等相關實驗Flag)

要讓企業內部所有員工都去下載實驗版瀏覽器、還要手動修改chrome://flags頁面，這在企業內部的推廣上極其不便。因此，我原先的架構規劃並不是修改瀏覽器Flag，而是依直覺自行開發專屬的Chrome Extension(擴充功能)。

[圖片9] 原本規劃開發的Chrome外掛側邊欄面板介面 (試圖透過Chrome Side Panel讀取網頁特定物件並對接地端LLM)

 當初選擇Chrome外掛來作為AI助理的Side Panel，是因為外掛擁有極高的瀏覽器權限。我們可以直接寫一段JavaScript去模擬並實現WebMCP的對接邏輯，也就是直接讀取網頁上的特定物件並傳給地端LLM。

最終宣告失敗的血淚原因： Chrome瀏覽器的安全機制將網頁世界嚴格切分為「原生網頁頁面」與「擴充功能頁面」，兩者之間的通訊機制錯綜複雜。當側邊面板的AI試圖跨越邊界去取得Domino原生元件時，經常會觸發瀏覽器的安全防禦機制而導致程式意外終止，這使得後續的開發與整合窒礙難行。

因此，目前最穩健的路徑依然是回歸到網頁原生層面，暫時透過開啟瀏覽器Flag的方式來橋接WebMCP。相信自下半年起，隨著各大瀏覽器與前端框架對WebMCP標準的支援越來越完善，WebMCP Flag的設定也將被移出設定頁面，且「成為Agent-ready的網站」將會變成每家企業及網站的基本要求。

六、WebMCP的前端核心執行邏輯

回到WebMCP的邏輯面，當此網頁需要 AI 助理支援時，嵌入的 JavaScript 會做到以下幾件事：

// 1. Agent 自動初始化，並建立一個專屬的 Context Session const session = await navigator.modelContext.createSession(); // 2. 註冊此表單文件所需要用到的工具清單 (以 ai_approve_document 為例) await navigator.modelContext.registerTool({     name: "ai_approve_document",     description: "當主管表達核准、同意、沒問題時呼叫。請將主管的原話，轉換為專業優雅的核准評語放在 comment 中。",     parameters: {         type: "object",         properties: {             comment: { type: "string", description: "轉換後的專業官腔評語" }         },         required: ["comment"]     } });

1.  宣告工具說明： 撰寫工具的Function，並在description中加以詳細說明。例如：「當主管表達核准、同意、沒問題時呼叫。請將主管的原話，轉換為專業優雅的核准評語放在comment中」。而Function本身非常單純，就是把AI美化後的回應寫入欄位中，並模擬按下對應的按鈕。
2. 包裝與傳送： 當使用者輸入對話後，Agent會把「使用者的對話輸入」、「當前網頁的Context」以及「此網頁宣告的WebMCP工具清單」，全包裝成一個Prompt送至LLM。
3. 精準工具調用： 當LLM發現網頁有註冊對應工具時，它不會直接輸出聊天文字，而是消化工具描述後，精準輸出一個適用的工具調用指令(Tool Calling)，並帶入相應參數。
4. 網頁端觸發： 網頁前端接收到指令後，觸發對應的JavaScript函式，自動將美化後的文字填入簽核意見欄位並代點選按鈕。

七、核心安全防線：原生 Session 繼承與文件級防護

1. 在WebMCP的世界中，AI助理並不是一個系統外的「第三方服務」，它只是寄生在使用者網頁前端的一個JavaScript 代理程序，當 AI 讀取網頁內容作為 Context 時，它只能讀到當前這個使用者在能看得到的文字。 
2. 原生Session與Token的延用：WebMCP 運作時所有與Domino後端發生的互動，包含在範例中代為按鈕或填寫文字，完全都是直接延用現有操作者的Web Session或Oauth Token。 
3. 完全相容Domino文件等級的資安規格：Domino其細緻到單一文件的權限防護，如讀者欄位、作者欄位可以完全延用，而 WebMCP 因為不與後端直連，而是「等網頁被Domino依照讀者權限安全產生後，AI才在前端讀取」，因此直接繼承了Domino最嚴格的文件級資安防禦，也無需任何第三方特權帳號。

八、結論

總結來說，WebMCP的精髓在於「前端宣告，後端零改動」。開發人員只需在前端副套表插入輕量的JavaScript，負責Agent初始化、註冊工具清單、連接LLM並執行Function Calling。後端原有的核心業務邏輯與複雜的簽核公式完全不需要做任何調整。

對於架構包袱沉重、卻又急需擁抱AI轉型潮的Domino而言，WebMCP毫無疑問是目前最具效益的解決方案！