針對第三方入口網站的 UI 依賴自動化
每個企業都有這樣一份清單：員工每天手動登入的入口網站，做著本該自動化卻沒有自動化的工作。查詢訂單狀態的供應商入口網站。提交監管文件的政府網站。核實資格和查詢理賠狀態的保險支付方入口網站。資質核實的州執照委員會。合規申報的稅務機關入口網站。
這些入口網站沒有 API。或者有的有 API，但未公開文件、有速率限制，或僅限於支付存取費用的「優先合作夥伴」。資料在登入頁面後面以 HTML 渲染，取得它的唯一方法是登入並導航 UI。
傳統自動化使用瀏覽器指令碼。Selenium、Playwright 或 Puppeteer 指令碼登入，導航到正確頁面，透過 CSS 選擇器或 XPath 定位元素，提取資料，然後登出。這些指令碼能用，直到不能用為止。入口網站重新設計更改了 CSS 類別名稱。登入流程新增了新的 CAPTCHA。導航選單從側邊欄移到了漢堡選單。Cookie 同意橫幅開始遮住提交按鈕。指令碼悄然失敗，沒有人知道，直到依賴該資料的下游流程開始回報錯誤。
州醫療委員會是一個特別典型的例子。有 50 個，每個都有不同的網站、不同的版面配置、不同的認證方法和不同的資料格式。它們按自己的時間表重新設計，沒有任何通知。依賴抓取這些網站的資質核實服務，在任何給定時刻可能有五到十個指令碼處於損壞狀態，每個都需要開發人員檢查新版面配置並重寫選擇器。
Triggerfish 的解決方案
Triggerfish 的瀏覽器自動化將 CDP 控制的 Chromium 與 LLM 視覺導航相結合。代理將頁面視為渲染的像素和無障礙快照，而不是 DOM 樹。它透過元素的外觀和功能而非 CSS 類別名稱來識別元素。當入口網站重新設計時，代理能夠適應，因為登入表單仍然看起來像登入表單，導航選單仍然看起來像導航選單，資料表格仍然看起來像資料表格。
視覺導航代替選擇器指令碼
瀏覽器自動化工具透過七種操作工作：navigate、snapshot、click、type、select、scroll 和 wait。代理導航到 URL，對渲染的頁面進行快照，推論所見內容，並決定採取什麼行動。沒有在頁面情境中執行任意 JavaScript 的 evaluate 工具——這是一個有意的安全決策。代理透過 UI 與頁面互動，就像人類一樣，無法執行可能被惡意頁面利用的程式碼。
當代理遇到登入表單時，它透過視覺版面配置、預留位置文字、標籤和頁面結構來識別使用者名稱欄位、密碼欄位和提交按鈕。它不需要知道使用者名稱欄位有 id="auth-input-email" 或 class="login-form__email-field"。當這些識別碼在重新設計時改變，代理不會注意到，因為它從未依賴它們。
共用網域安全設定
瀏覽器導航與網頁擷取操作共用相同的網域安全設定。triggerfish.yaml 中的單一設定區塊定義了 SSRF 拒絕清單、網域允許清單、網域拒絕清單以及網域到分類的對應。當代理導航到分類為 CONFIDENTIAL 的供應商入口網站時，工作階段 taint 自動升級為 CONFIDENTIAL，該工作流程中的所有後續操作都受 CONFIDENTIAL 級別限制。
SSRF 拒絕清單是硬式編碼的，不可覆寫。私有 IP 範圍、連結本機位址和雲端中繼資料端點始終被封鎖。DNS 解析在請求之前進行檢查，防止 DNS 重新繫結攻擊。這很重要，因為瀏覽器自動化是任何代理系統中風險最高的攻擊面。試圖將代理重新導向到內部服務的惡意頁面在請求離開系統之前就會被封鎖。
瀏覽器設定檔浮水印
每個代理維護自己的瀏覽器設定檔，隨著與入口網站的互動不斷累積 Cookie、本機儲存和工作階段資料。設定檔帶有分類浮水印，記錄使用它的最高分類級別。該浮水印只能升級，不能降級。
如果代理使用其瀏覽器設定檔登入了 CONFIDENTIAL 供應商入口網站，設定檔就被標記為 CONFIDENTIAL。隨後以 PUBLIC 分類執行的工作階段無法使用該設定檔，防止透過可能包含敏感資訊的快取憑證、Cookie 或工作階段憑證造成資料洩漏。設定檔隔離是按代理執行的，浮水印執行是自動的。
這解決了入口網站自動化中一個微妙但重要的問題。瀏覽器設定檔會累積反映其存取過的資料的狀態。沒有浮水印的話，登入過敏感入口網站的設定檔可能透過自動填入建議、快取的頁面資料或持久化 Cookie 向較低分類的工作階段洩漏資訊。
憑證管理
入口網站憑證儲存在作業系統金鑰鏈（個人版）或企業金鑰庫（企業版）中，而不是設定檔或環境變數中。SECRET_ACCESS 掛鉤記錄每次憑證擷取。憑證在執行時由工作流程引擎解析，透過輸入介面注入到瀏覽器工作階段中，而不是以程式化方式設定表單值。這意味著憑證與其他敏感操作一樣，流經相同的安全層。
對常見入口網站變更的適應能力
以下是常見入口網站變更發生時的處理方式：
登入頁面重新設計。 代理截取新快照，識別更新後的版面配置，透過視覺情境找到表單欄位。除非入口網站切換到完全不同的認證方法（SAML、OAuth、硬體憑證），否則登入無需任何設定更改即可繼續工作。
導航重構。 代理登入後讀取頁面，根據連結文字、選單標籤和頁面標題而非 URL 模式導航到目標區域。如果供應商入口網站將「訂單狀態」從左側邊欄移到上方導航下拉選單，代理會在那裡找到它。
新的 Cookie 同意橫幅。 代理看到橫幅，識別接受/關閉按鈕，點擊它，然後繼續原來的任務。這由 LLM 的通用頁面理解處理，而不是專門用途的 Cookie 處理程式。
新增了 CAPTCHA。 這是該方法存在誠實限制的地方。簡單的圖像 CAPTCHA 根據 LLM 的視覺能力可能可以解決，但 reCAPTCHA v3 和類似的行為分析系統可以封鎖自動化瀏覽器。工作流程將這些路由到人工介入佇列，而不是悄然失敗。
多因素驗證提示。 如果入口網站開始要求以前不需要的 MFA，代理偵測到意外頁面，透過通知系統回報情況，並暫停工作流程直到人工完成 MFA 步驟。工作流程可以設定為等待 MFA 完成，然後從暫停的地方恢復。
跨多個入口網站的批次處理
工作流程引擎的 for 迴圈支援意味著單一工作流程可以遍歷多個入口網站目標。資質核實服務可以定義一個工作流程，在單次批次執行中檢查所有 50 個州醫療委員會的執照狀態。每個入口網站互動作為獨立的子步驟執行，有自己的瀏覽器工作階段、自己的分類追蹤和自己的錯誤處理。如果 50 個中有 3 個入口網站失敗，工作流程完成其餘 47 個，並將 3 個失敗路由到審查佇列，附帶每個入口網站的詳細錯誤情境。
實際應用案例
一家認證機構作為提供者登錄流程的一部分，跨州醫療委員會核實醫療提供者執照。傳統上，核實助理手動登入每個委員會網站，搜尋提供者，截取執照狀態截圖，並將資料輸入認證系統。每次核實需要 5 到 15 分鐘，該機構每週處理數百次。
使用 Triggerfish，工作流程處理完整的核實週期。工作流程收到一批帶有執照號和目標州的提供者。對於每個提供者，瀏覽器自動化導航到相關州委員會入口網站，使用儲存的憑證登入，搜尋提供者，提取執照狀態和到期日期，並儲存結果。提取的資料因包含提供者 PII 而被分類為 CONFIDENTIAL，寫入降級規則防止它被發送到該分類級別以下的任何頻道。
當州委員會重新設計其入口網站時，代理在下一次核實嘗試時自適應。當委員會新增封鎖自動存取的 CAPTCHA 時，工作流程將該州標記為需要手動核實，並繼續處理批次的其餘部分。核實助理從手動完成所有核實，轉變為只處理自動化無法解決的例外。