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