Daytona 沙箱接上 OpenAI 電腦操作循環

摘要： Daytona 在官方文件指南中示範如何用 OpenAI 的 ComputerToolset helper 驅動一台 Daytona 沙箱桌面：模型負責看截圖、下指令，Daytona 提供桌面，你的應用程式負責決定哪些動作真的會被執行。對 builder 來說，重點不是「能操作瀏覽器」，而是這份範例把權限邊界寫成程式碼，而不是寫進 prompt。

三個角色，各自負責一件事

這份指南的架構把 computer-use 拆成三塊。Daytona 提供帶有 Computer Use 套件的沙箱桌面，負責回傳截圖、接受滑鼠輸入；OpenAI 的 ComputerToolset（隨 Python SDK 3.31.0 和 Node SDK 7.33.0 提供）負責跑「截圖→送模型→執行動作」的循環；夾在中間的是你自己寫的 driver，一個實作九個方法的小類別。

工具集本身完全不建立或管理沙箱。這個設計決定很關鍵：沙箱的生命週期、瀏覽器怎麼開、模型能做什麼，全部留在應用程式手裡。

範例故意做到極度限縮

指南的示範腳本只允許模型做兩件事：截圖，以及在顯示範圍內點一次普通左鍵——而且前提是你在終端機回答 y 同意。其餘所有動作（雙擊、拖曳、按鍵、捲動、輸入、移動、等待）都被 alias 到會直接 raise 的 unsupported。

class DaytonaDriver:
    def click(self, action):
        if self.clicked or action.button != "left" or action.keys:
            raise RuntimeError("Only one plain left click is allowed.")
        # 另有顯示範圍內的 bounds 檢查，略
        self.clicked = True

除了 driver 層，run() 還有兩道關卡：before_action 在每次動作派發前過濾類型；approve_safety_checks 一律回傳 False，遇到待決的安全檢查就停，而不是替模型放行。指南明確建議：要擴充能力時，用同樣的 bounds 檢查一次加一個方法，而不是放寬 safety callback——寬鬆的 driver 無法靠嚴格的 prompt 補救。

成本與生命週期的務實處理

每次執行會同時計費 OpenAI 模型用量和 Daytona 沙箱執行時間。腳本用 auto_stop_interval=20、auto_delete_interval=60 幫沙箱設壽命上限，就算中途出錯沒跑到清理，沙箱也會自動回收；正常路徑下，巢狀的 finally 確保即使 toolset.close() 出錯，沙箱刪除仍然執行。

另外兩個值得抄的細節：請求帶 store: False，對話不留存在 OpenAI 端；tool_choice: "required" 強迫模型真的使用電腦工具，腳本最後還會檢查 driver.clicked，抓出「沒動手就用記憶回答」的模型。

下手前先想清楚的三件事

指南的安全段落說得很直白：截圖會送進 OpenAI 的模型請求，所以桌面上看得到的東西都等於分享了，請用乾淨、拋棄式的桌面，不要放任何真實帳號或憑證。模型說它點了什麼不算證據——範例只驗證 driver 接受過一次點擊，不驗證點到哪裡，結果要另外獨立驗證。

這和我先前整理過的 Reflex 對視覺代理與結構化 API 的成本實測指向同一個結論：computer-use 是強大但昂貴、需要嚴格護欄的工具。若你的任務能用結構化 API 解決，先量一下比例再決定要不要讓模型看螢幕。想跑得更快的話，指南建議把瀏覽器和頁面狀態預先做成 Daytona snapshot，並在建立沙箱時用 allow-list 把網路限制在任務需要的網域。

原始指南見 Daytona 文件，需要完整滑鼠、鍵盤與螢幕錄製 API 時可參考其 Computer Use 頁面。

參考來源

原始貼文

在 X 上查看原貼文