把瀏覽器操作交給 MCP 之後，工作流程會怎麼改變，程式碼裡又有哪些部分能消失？本文整理實際使用時的分工方式、最常卡住的四個設定問題，以及遇到問題時的排查順序。
用 Claude Code 寫瀏覽器自動化時，最先讓人受不了的通常是膠水程式碼：啟動瀏覽器、綁定代理、建立環境、等待 handle。這些事情和業務邏輯沒有直接關係，卻得一遍又一遍重寫。把瀏覽器操作透過 MCP 交出去之後，這一層幾乎就能從程式碼裡消失。你只需要描述要做什麼，模型會自己判斷該呼叫哪個工具。
兩者怎麼分工
Claude Code 是命令列裡的程式設計助手，可以讀寫檔案、執行命令，也能操作 Git。它的強項是在程式碼和終端機這一側工作。直接碰瀏覽器不是它擅長的事情，也不應該由它負責。
MCP 剛好補上這一塊。它把瀏覽器自動化環境的能力包成一組工具，註冊之後模型就能呼叫：列出環境、建立環境、啟停瀏覽器、截圖、讀取頁面內容。一邊負責程式碼和日誌，一邊負責瀏覽器和頁面，分工清楚之後，出問題也更容易定位。
工作流程的變化
最明顯的改變是整條鏈路能更快搭起來。以前流程一改就要動腳本，現在可以先用自然語言試一遍：列出目前有哪些環境，在其中兩個登入並截圖，再把結果整理出來。能跑通之後，再固定成腳本。
實際專案裡通常會有三層配合。MCP 承接自然語言指令，適合探索和臨時任務；本機 HTTP API 承接批次動作，例如一次建立幾十個環境，穩定而且方便重試；需要精細互動的部分，例如等待某個狀態出現、抓取頁面裡的結構化資料，就交給 CDP 連接瀏覽器去做。三者並不衝突，而是各自負責不同的一段。
把環境這一層獨立拉出來管理，也是到了這個階段才真正想清楚。環境散落在各個腳本裡時，任務一多，排查問題就很難下手。現在改成用環境層工具集中建立、集中查看、批次回收，腳本只需要拿到一個環境 ID 使用。多帳號情境裡，像 PurpleMark 這類環境隔離方案負責的就是這一層，把每個帳號的環境、工作階段和快取分開，執行層才有辦法穩定調度。
四個最容易卡住的地方
第一個是工具沒有被識別。多數客戶端只會在啟動時讀一次設定，所以註冊完如果不重新啟動，通常不會生效。設定檔路徑寫錯也很常見，因為不同工具的位置不一樣。一個很土但有效的判斷方式是：手動把服務啟動起來。能啟動，問題多半在設定；啟動不了，問題多半在環境。
第二個是驗證失敗。最常見的原因是複製憑證時多帶了空白或換行。先檢查這一點，再看環境變數是怎麼讀取的；不同作業系統、不同啟動方式，結果確實可能不同。
第三個是本機 API 沒有啟動。這類 MCP 服務大多依賴客戶端本身處於執行狀態。客戶端沒有開，服務可能啟動不了，或連線直接逾時。也要順便注意連接埠是否被占用，之前殘留的程序如果沒有完全退出，可能還會占著連接埠。連接埠號可以在客戶端設定裡確認。
第四個是並行任務互相干擾。單一任務跑得好好的，一起跑之後卻出現資料錯亂、登入狀態互相覆蓋。原因通常都是多個任務共用了同一個環境。這種問題不是靠除錯就能解決，而是要靠約束：一個任務一個環境，環境的建立和回收走批次 API，不要在腳本裡臨時建立。
幾個除錯習慣
指令裡要把等待條件說清楚。「點擊送出按鈕」這句話的資訊量不夠；改成「等到送出按鈕可以點擊之後再點」，成功率會明顯不同。模型可以負責判斷要做什麼，但等待時機需要由你說清楚。
先從唯讀任務開始驗證鏈路。列出環境、截圖、讀取頁面文字，這些操作沒有副作用，卻能一次驗證驗證機制、網路和服務三個環節。鏈路還沒打通時，不要急著執行有副作用的操作。
憑證不要寫進程式碼，使用環境變數或本機設定檔，並把檔案加入忽略清單；團隊成員有變動時就輪替一次憑證。本機 API 如果關掉了自己的驗證機制，至少要確保它只監聽本機，不會被外部存取。
最後一條是邊界：MCP 打通的是技術鏈路，不會改變平台規則。整合得再順，任務本身該遵守的服務條款仍然一條都不能少。
