甚麼是電腦操作？為何如此重要？電腦操作的概念簡單，影響卻十分廣泛：我們不再要求模型回答問題，而是讓它們操作軟件，自主瀏覽網站、填寫表格、逐步完成工作流程，並從頭到尾完成任務。
這讓系統能夠處理大量目前分散於不同介面的現實任務，例如端對端預訂、電子商務結帳、多步驟旅程規劃，以及沒有合適 API 對應的後台工作流程。這些問題並不新鮮。新的是，如今已可運用通用模型解決這些問題。
Anthropic 和 OpenAI 最近的系統展示了不僅能採取行動，還能推理狀態、從錯誤中恢復，並即時建構任務專用解決方案的智能代理。這使瀏覽器成為智能代理的通用執行環境，但也立即帶來一個設計問題：應向模型開放多少環境資訊？
早期系統的做法，是把瀏覽器封裝成一組固定、安全且預先定義的操作。本文將說明，這種方法正逐漸觸及極限。
建構瀏覽器智能代理時，人們常有一種直覺：不要過度信任模型。
因此，我們把瀏覽器封裝起來。我們提供 click、type、scroll、select 和 read_text 等預先定義的工具。我們簡化文件物件模型（DOM）。我們縮小操作空間。我們嘗試透過自行設計的抽象層，令行為易於理解和控制。
這是合理的起點。但長遠而言，這也日益成為錯誤的架構。
隨着前沿模型持續進步，限制已不再只是模型缺乏工具。更大的問題是，我們迫使模型透過抽象層運作，因而捨棄了過多底層系統資訊。我們把混亂多變的環境壓縮成固定的操作介面，然後要求模型在資訊已流失的情況下仍有出色表現。
這項取捨正變得越來越不划算。
我們一直探索的轉變，描述起來簡單，影響卻十分重大。我們不再把智能代理視為預先定義操作的選擇器，而是把它視為在受限執行環境中運作的程式合成器。
模型已變得非常出色，不再需要抽象化的防護欄；它們需要完整的操作空間，以設計、執行任務並反覆改進，直至達成目標。
本文探討的正是這種轉變：從高度依賴抽象層的瀏覽器自動化，轉向受限的電腦操作，以及以這種方式設計系統後會有甚麼改變。
問題並非固定操作介面在概念上有誤。而是網絡環境不會配合這些介面。
現代介面以 React、Vue 和 Angular 建構，包含非同步狀態更新、合成事件系統，以及嵌入跨來源 iframe、各有自身生命週期的第三方小工具。只有當頁面認同你對「輸入」的定義時，指示「在這個輸入欄位輸入內容」的封裝器才會正確運作。很多頁面並不認同。直接設定數值，往往會完全繞過框架的變更偵測機制。輸入欄位看似已填妥。驗證卻從未觸發。表格仍然無法運作。
你可以修補這個問題。你可以為 React 輸入欄位加入特殊處理、在聚焦後觸發 blur 事件，並等待網絡閒置後才讀取狀態。每項修補本身都正確。但累積起來，系統會變得越來越難維護，也越來越局限於你曾遇過的網站。
更深層的問題是，你把互動方式的假設編碼至抽象層後，才發現網絡環境採用另一套假設。
以透過 Stripe 或 Adyen 嵌入跨來源 iframe 的付款表格為例。由於表格位於獨立來源，封裝器無法直接存取。read_text 工具無法觀察其內部狀態。type 工具無法操作其中的輸入欄位。採用封裝器的智能代理在此便會碰壁。抽象層是為主文件而設。實際任務卻位於抽象層無法看見的地方。
類似的不匹配也會出現在較不明顯的流程中。由框架控制的下拉式選單可能完全不會回應直接點擊，因為可見元素並非實際控制項。它可能需要一連串鍵盤事件，才能觸發底層狀態轉換。從外觀來看，用戶介面似乎可以點擊。抽象層發出「點擊」指令，卻毫無反應。
另一個例子是多步驟的對話框流程，其中可見 DOM 的更新落後於內部狀態變更。正確的下一步取決於某項狀態轉換，但該轉換尚未反映在封裝器可見的元素上。採用封裝器的智能代理只能看到不完整的系統狀態，結果會過早採取行動或讀取過時狀態。
在每種情況下，抽象層都會隱藏智能代理實際需要的訊號。
若模型在較底層運作，檢查即時 DOM、推理框架邊界，並為該介面合成專用互動序列，便能應對這些情況。這並非因為模型本身更聰明。而是因為它能存取原本被捨棄的資訊。
我們一直推動的轉變很容易描述：我們不再要求模型從預先定義的操作中作選擇，而是為它提供較底層的執行介面，並以執行階段政策而非抽象層設計來約束該介面。
這項設計選擇源於更廣泛的業界轉變：業界開始偏好較底層的基礎工具，利用智能代理在執行階段修正和編寫優質程式碼的固有能力，而非採用穩健但硬編碼的專用工具，削弱模型適應不同環境的能力。
Claude Code 已成為許多開發人員工具箱中的首選，加上業界正廣泛轉向終端智能代理，便是例證。Claude Code 最大的優勢並非模型本身，而是較底層的任務執行框架。為模型提供數量更少、模組化程度更高且更底層的工具，也就是終端，可改善工具調用表現。主要原因是智能代理能夠推理並為當前任務建立自訂指令碼，而非嘗試使用會令上下文視窗充斥雜訊的通用工具。
在瀏覽器自動化的實際應用中，這表示模型可直接檢查頁面的即時狀態、跨越不同框架，並為當前介面編寫專用互動程式碼，而非把所有操作映射至一組固定的預建操作。
模型不再像選擇器，而更像執行階段的程式編寫者。它會檢查當前狀態、推理介面，並為特定情況合成互動邏輯。它可以建構多步驟序列、適應不尋常的流程，並在繼續之前驗證結果。操作失敗時，模型會看到底層錯誤並自行修正。這種方式能力更強，風險也更高，但更貼近問題的實際形態。
重要的是，移除抽象層並不會令系統失去規範。只是規範轉移至其他部分。
過往用於封裝器設計和處理邊緣情況的工作，會轉移至三個部分：提示詞（成為一種操作訓練）、執行環境（強制執行瀏覽範圍、敏感操作和重試行為等界線），以及評估層（不僅評估任務是否成功，也評估中間步驟是否正確）。減少脆弱的抽象層。強化周邊系統。
這種轉變帶來的一個結果是：即使整體系統能力更強，產品程式碼往往反而更簡潔。智能代理不再把互動模式編碼成可重用的封裝器，而是在執行階段合成行為。你只需維護一小組功能強大的基礎操作和受限的執行環境，而非不斷增加專用工具和針對邊緣情況的邏輯。
這也改變了系統的泛化方式。採用封裝器的智能代理，能夠很好地泛化至與現有封裝器相似的任務。採用受限執行環境的智能代理，則可泛化至共用同一執行基礎的任務，即使可見介面有所不同。
例如，與搜尋表格、預訂流程或設定頁面互動，在用戶介面層面可能看起來截然不同。但在底層，它們採用相同模式：讀取狀態、觸發事件、驗證結果及處理非同步更新。在這個層面運作的系統，能更自然地把能力轉移至不同任務。
可重用的並非操作清單，而是模型檢查狀態、安全執行操作及驗證結果的能力。
這項工作帶來最明確的啟示是：可靠性並非源於為模型提供更多輔助函數。可靠性往往來自提供數量更少但功能更強大的基礎操作，並以適當方式加以約束。過度協助會把對任務執行方式的假設硬編碼至系統。約束可界定安全的運作界線，並讓模型自行找出更合適的局部解決方案。
功能更強大的執行介面，也需要更嚴謹的安全模型。當智能代理不再局限於一小組預先定義的操作，實際上就是直接操作真實軟件。這會立即改變其風險狀況。
設計時須考慮四個方面：
資料外洩。智能代理與真實介面互動時，往往會接觸敏感資料，因此必須嚴格執行遮蔽和存取控制。只有在執行任務所需時才應披露資料，並須審慎處理日誌和追蹤記錄，以免可觀測性功能反而成為系統中最敏感的部分。
執行範圍。功能強大的智能代理不應能任意操作。實際上，這表示須限制它可瀏覽的位置、可存取的網域，以及獲准互動的系統。這些限制應在執行階段強制實施，而非只視為提示詞中的慣例。
環境可信度。現代介面可能包含具誤導性甚至蓄意對抗的指示、內容或流程。透過頁面內容發動提示注入，是一個真實存在的攻擊面。系統需要清晰的指示層級、驗證檢查和終止條件，以防智能代理遵循非預期指引。
自主程度。並非所有操作都應完全自主執行。在許多生產環境中，重要的是把自主性視為連續的程度範圍。系統在探索和執行方面可以高度自主，但某些類別的操作仍須經過批准。
基本原則很直接：賦予模型越大的能力，就越需要強化其周邊系統。缺乏政策約束的自主系統，尚未適合投入生產。
我們不再問：應開放哪些瀏覽器操作？
我們開始問：怎樣才能為模型提供完整的操作空間，同時制定相應的執行階段政策，確保系統安全？
這種重新定位改變了關注重點。操作分類和封裝器的完整程度變得不再那麼重要。執行階段政策、可觀測性和步驟層級評估則變得更重要。模型能力與系統設計不能互相取代。模型越進步，系統所承擔的工作便越重要，而非相反。
瀏覽器智能代理在示範中能夠成功，往往是因為任務範圍狹窄，而且環境會配合。生產系統需要不同的條件：受限的執行環境、可監測的行為，以及能分辨正確結果與僥倖成功的評估機制。
少一點封裝器設計。多一點系統工程。
雖然本文聚焦瀏覽器智能代理，但這也啟發我們以更廣闊的視角，把電腦操作視為一門系統學科。