編者按：本文整理了 Codex 操作外部環境的三種入口：Computer Use、Chrome 擴展和應用內 Browser。三者看似都在解決「讓 Codex 使用電腦」的問題，但對應的是不同的任務場景、權限邊界和信任級別。

其中，Computer Use 的覆蓋範圍最廣，可直接操作 macOS / Windows 上經授權的原生應用、系統設定、iOS 模擬器，甚至跨多個應用完成工作流程。它適用於沒有 API、外掛或結構化工具支援的 GUI 流程，但代價是速度較慢，權限邊界也最寬。Chrome 擴充功能則適用於依賴登入狀態、Cookies、多分頁和瀏覽器身分的任務，例如 Gmail、LinkedIn、Salesforce、內部後台，或跨多個網站的已登入研究。應用內 Browser 偏向開發與除錯情境，尤其適合本地服務、視覺錯誤、響應式佈局和設計註解；它不繼承用戶正常瀏覽器的登入狀態，功能較窄，但隔離性更強。

文章的核心判斷是，Codex 並非只有一種「使用電腦」的方式，真正重要的是根據任務選擇最窄、最安全、最結構化的操作介面。能使用插件或 MCP，就不應優先使用視覺控制；任務僅涉及網頁開發時，應優先使用應用內 Browser；當需要用戶的瀏覽器身份和登入狀態時，再切換至 Chrome；只有當結構化工具無法覆蓋，且任務必須依賴桌面圖形介面時，Computer Use 才是最後一公里。

Appshots 不是第四種控制電腦的方式，而是將當前螢幕上下文「指給 Codex 看」的工具。它解決的是上下文輸入問題，而 Browser、Chrome 和 Computer Use 解決的是行動問題。綜合來看，這套分層實際上揭示了 AI Agent 產品化的關鍵：不是讓模型獲得無限權限，而是在具體任務中不斷收窄權限、明確邊界，並讓使用者保留對關鍵行動的審核權。

以下為原文：

Codex 有三種使用電腦的方式：Computer Use、Chrome 擴展，以及應用內瀏覽器。

它們之間有一定重疊，剛好重疊到容易令人困惑。

閱讀完這篇文章後，你將知道如何安裝並觸發這三種方式，各自適用於什麼情境，Appshots 和 Developer mode 如何將它們連接起來，以及應在 AGENTS.md 中撰寫什麼內容，以讓 Codex 能自行選擇合適的操作介面。

簡易版是：

儘管如此，只要可能，仍應優先使用插件或 MCP。例如，Slack 插件能比在 Slack 中到處點擊更精準地檢索一個線程；GitHub 插件產生的操作，也比讓 Codex 驅動網頁更容易檢查。視覺控制最適合用於結構化工具能力到達邊界的地方。

一切都可以是 @Computer

Computer Use 是這三種操作介面中覆蓋面最廣的一個。它讓 Codex 能在 macOS 和 Windows 上檢視並操作圖形介面，包括視窗、選單、鍵盤輸入，以及你授權應用程式中的剪貼簿。

它通常也是最慢的。結構化插件可直接調用 API；Computer Use 則需要觀察介面、判斷點擊位置、等待應用回應，再檢查下一步狀態。這個視覺迴圈會耗費時間，但也意味著 Codex 可以操作那些完全沒有可用 API 的應用。

在 macOS 上，緩慢並不一定意味著會打擾你。Computer Use 可以在後台運行你授權的應用，而你仍可繼續使用電腦的其他部分。很多時候，我在使用 Codex 時開啟某個應用，才發現 Codex 已經在後台安靜地完成了一套工作流程。

根據您電腦上安裝並授權了哪些應用程式，這些操作對象可包括 Spotify、Xcode、System Settings、iOS 模擬器，甚至是使用 iPhone Mirroring 控制您的 iPhone。它還可以在多個應用程式之間切換，處理跨不同應用程式的工作流程。

當任務依賴以下內容時，可以使用它：

原生桌面應用，例如 Spotify 或金融類應用；

iOS 模擬器、iPhone 鏡像，或其他僅能透過圖形介面操作的流程；

系統或應用程式設定；

無插件或 API 的數據來源；

需要在多個應用之間切換的工作流程；

結構化整合中遺漏的最後一步操作。

安裝方式：打開 Codex 的 Settings > Computer Use，然後點擊 Install。

觸發方式：提及 @Computer，或明確要求 Codex 使用 Computer Use。隨著模型能力提升，未來在需要時它也會自行調用。

可以先試幾個例子：

我最喜歡的一個例子，源於一個包裹被偷了。Amazon 告訴我，需要等待約 25 分鐘才能接通客服。我把一個 Codex 線程交給 Computer Use，讓它每五分鐘檢查一次聊天窗口，等客服出現後改為每分鐘檢查一次，並盡力幫我取得退款。等我洗完澡回來，退款已經完成了。

我也將 Computer Use 用作結構化工作流中的「最後一公里」。在一次發布影片中，Codex 可以從 Slack 讀取反饋、修改代碼並渲染新影片，但當時該線程中的 Slack 集成無法上傳檔案。於是 Computer Use 點擊了 Add file，補上了這個缺失的步驟。

它也是三者中信任邊界最寬的一種。一次只給它一個明確的應用或流程。當某些敏感應用不是任務的一部分時，保持關閉；仔細檢查權限彈窗；涉及金融、帳戶、支付、憑證、隱私和系統安全變更時，最好人在場監督。

使用 @Chrome 處理多個標籤頁和登入狀態

Codex Chrome 擴充程式讓 Codex 能存取你已登入的 Chrome 狀態。當任務依賴帳號、cookies、瀏覽器設定檔，或你已開啟並認證的標籤頁時，應使用它。

此操作介面適用於以下工具：

Gmail 或 LinkedIn；

Salesforce 或客服後台；

內部儀表板；

跨多個網站的已登入研究；

依賴你的帳戶或瀏覽器擴展的表單。

安裝方式：打開 Codex 的 Plugins，新增 Chrome，並按照設定流程操作。Codex 會引導您安裝 Codex Chrome 擴充功能，並批准 Chrome 權限。當擴充功能顯示 Connected 後，開啟一個新線程。

觸發方式：提及 @Chrome，或明確要求 Codex 使用您已登入的 Chrome 瀏覽器：

Chrome 任務會在標籤頁組中運行，這有助於將與某個 Codex 線程相關的標籤頁集中在一起。與應用內瀏覽器不同，此操作介面攜帶的是您的瀏覽器身份，這使其功能更強大，也更敏感。

另一個主要優勢是多標籤頁控制。Chrome 可讓多個標籤頁與同一項任務相關聯，在一個頁面中讀取上下文，在另一個頁面中對照資訊，再於第三個頁面繼續工作流程。Computer Use 也可透過視覺方式驅動瀏覽器，但 Chrome 會將任務理解為一個瀏覽器工作流程，而非一連串螢幕座標操作。

最近有一個線程，我把一個已開啟的 Strudel Composer 標籤頁交給 Codex，讓它把音樂變得更有趣。Chrome 提供了被選中的標籤頁，以及該頁面提供的 WebMCP 工具。Codex 檢查了樂曲結構，重寫了和聲與四分鐘的整體形式，調整了速度，保存了曲目，並讓其繼續播放。它無需在介面上視覺搜尋每個控制項，因為 Chrome 可以將標籤頁上下文與頁面提供的結構化功能結合起來。

我還用它運行一個長期的 Twitter 線程。大致指令是：

有趣的地方不在於 Codex 能打開 Twitter，而在於這個線程能長期回到同一個已登入的工作環境，將發現的內容連結至本地檔案，並留下可供我審核的結果。

這裡的信任邊界很重要。網站可能會將 Codex 的點擊、表單提交和訊息發送視為你本人採取的行動。網頁內容本身也是不可信輸入。將後果較嚴重的步驟明確區分出來：研究、導航和起草可自動完成；在發送、發布、購買或提交之前，需由你審核。

如果整個任務都在瀏覽器中完成，請優先使用 Chrome，而非 Computer Use。Chrome 具備此類任務所需的瀏覽器原生上下文，且不會將存取範圍擴大至整個桌面。

使用應用內 @Browser 處理你正在開發的網站

應用內瀏覽器是存在於 Codex 線程內部的瀏覽器。你與 Codex 共享同一個渲染頁面，因此它特別適合構建和調試 Web 應用。

我通常會從這裡開始處理：

本地開發伺服器；

基於檔案的預覽頁面；

無需登入的公開頁面；

重現視覺 bug；

檢查響應式佈局；

留下對頁面元素的設計反饋。

它最重要的限制是隔離。應用內瀏覽器不會使用您的普通瀏覽器設定、cookie、擴充功能、登入階段或現有標籤頁。當任務需要帳戶身份時，這是一個限制；但當任務不需要帳戶時，這反而是一個有用的邊界。

設定方式：打開 Codex 的 Plugins，新增 Browser 插件並啟用它。

觸發方式：在提示詞中提到 @Browser，或明確要求 Codex 使用應用內瀏覽器：

這會形成一個緊密的反饋迴圈：Codex 可以編輯程式碼、操作頁面、檢查渲染狀態、截圖，然後在修復後重新驗證同一流程。

我最喜歡的部分是標註。當我審核一個本地應用時，可以直接點擊某個元素，或選中一個區域並留下評論。樣式控件也讓我能夠更精準地預覽和反饋文字、字體、間距和顏色。我通常會將其與語音輸入和過程引導結合使用：我審核頁面、留下評論，並在 Codex 處理當前反饋時繼續排隊添加更多意見。這個頁面本身便變成了規格說明書。

這對設計工作尤其有用。我經常要求 Codex 將一個想法、一份研究包或一個項目狀態整理成單個 index.html 檔案，然後用應用內瀏覽器打開它。與其在另一個提示詞中試圖描述整套設計，我可以直接在真實頁面上標註：「這個層級關係反了」「這裡不要那麼像卡片」「這些控件需要更多空間」，或「全站都用這個字號比例」。Codex 會收到附有相關截圖和元素上下文的評論，修改檔案，然後重新打開同一頁面進入下一轮。

這種循環更接近於與一位設計師在同一張畫布上工作，而不是反覆傳送截圖和文字說明。

應用內瀏覽器也適合作為混合工作流的起點。在另一個線程中，我使用應用內瀏覽器打開了一條 X 帖子，讓 Codex 調查相關討論。可見頁面幫助它確認我指的是哪一條帖子；隨後 Codex 切換至 Twitter CLI，檢索了 38 條回覆，其中包括瀏覽器視圖隱藏掉的嵌套回覆。這就是「使用最窄操作介面」原則的實踐：用瀏覽器確認螢幕上的上下文，再用結構化工具進行更深入的檢索。

這裡也有取捨。應用內瀏覽器的隔離性使它成為良好的開發介面，但也意味著它不適合處理 Google 登錄、passkey，或依賴瀏覽器擴展的網站。當身份很重要時，切換到 Chrome。