AI 代理人卡在列印視窗：AWS 讓 AgentCore Browser 伸手到 OS 層

一個 browser agent 正在替你下載報表。網頁上的按鈕都點完了，最後跳出系統 print dialog。畫面上明明有 Cancel，模型也看得出那顆按鈕在哪裡。

問題是，對 Playwright 或 Chrome DevTools Protocol 來說，那顆按鈕不在 DOM 裡。它不屬於網頁元素，是作業系統畫出來的原生介面。代理人可以截圖、可以理解，工具層卻按不到。

AWS 5 月 5 日介紹 Amazon Bedrock AgentCore Browser 的 OS Level Actions，就是針對這段落差。它讓 AgentCore Browser session 透過 InvokeBrowser 執行滑鼠、鍵盤、捷徑、拖曳、滾動、輸入和全桌面截圖，處理那些離開 web layer 的自動化狀態。

這件事把一條很實際的邊界畫出來：網頁自動化到 DOM 為止，很多真實流程會跨出去。

那個按不到的 print dialog

AWS 在文章裡用 window.print() 當例子。網頁觸發列印後，native print dialog 出現。CDP 無法操作它，因為它不是網頁的一部分。

OS Level Actions 的做法是：

1. 代理人先截圖，看見整個 desktop，包括 native dialog。
2. 視覺模型判斷 Cancel button 的座標。
3. 代理人透過 InvokeBrowser 發出 mouseClick。
4. AgentCore 在 full OS desktop 執行點擊。
5. 代理人再截圖確認 dialog 消失。

這個流程的重點不在列印，而在「看得到」和「做得到」之間終於接上工具。對 vision-enabled agent 來說，這很關鍵。模型可能早就能辨識畫面，但如果執行層只摸得到 DOM，它就會卡在最普通的系統對話框。

DOM 邊界外面有哪些東西

AWS 列出幾種 DOM/CDP 很難處理的情境：native dialogs、security prompts、certificate choosers、context menus、Chrome settings、keyboard shortcuts。

這些東西不罕見。測試環境裡可能少見，生產流程裡反而常出現：

狀態	DOM 自動化的問題	OS action 可能補上的能力
Print dialog	沒有可選 DOM 元素	截圖後點擊座標
Certificate chooser	CDP 看不到原生選擇器	用鍵盤或滑鼠操作
Right-click menu	網頁事件和原生 menu 混在一起	mouseClick 設成 RIGHT
Keyboard shortcut	有些流程靠快捷鍵觸發	keyShortcut
Native security prompt	不在 browser viewport DOM 內	full desktop screenshot + 操作

這對 QA、自動化營運、企業內部流程 agent 都有價值。很多任務看起來像瀏覽器任務，實際上會碰到 OS 或 browser chrome 的部分。只靠 DOM selector，會在最不方便的地方斷掉。

八種 action，組成一個截圖迴圈

AWS 把 OS Level Actions 分成三類：mouse control、keyboard input、visual capture。

Action	用途	注意點
mouseClick	點擊座標，可指定 button 和 clickCount	座標錯就點錯東西
mouseMove	移動滑鼠到座標	需要知道 viewport 尺寸
mouseDrag	拖曳到終點	起點終點要清楚
mouseScroll	滾動畫面	delta 有範圍限制
keyType	輸入文字	最多 10,000 characters
keyPress	按單一鍵，可重複	key name 要符合規格
keyShortcut	按快捷鍵組合	最多五個 keys
screenshot	擷取 full OS desktop	這是唯一回傳資料的 action

這些 action 本身不複雜。產品模式藏在 AWS 說的 action-screenshot-reaction loop：

代理人送出 action，AgentCore 回 SUCCESS 或 FAILED。代理人接著截圖，觀察畫面變化，再決定下一步。每一次操作都要有觀察，不然座標控制會很危險。

這也是 OS action 和一般 tool call 的差別。呼叫 API 常常有結構化 response；點擊畫面只有結果狀態和下一張 screenshot。代理人要靠視覺重新確認世界狀態。

能操作 OS，也代表風險往外擴

OS Level Actions 讓 AgentCore Browser 更有用，也讓責任變重。

第一是座標脆弱性。AWS 說座標對應 session viewport。例如 1920x1080 的 session，x/y 要落在對應範圍內。畫面尺寸、縮放、dialog 位置、語言版本，都可能讓同一個 workflow 需要不同座標。

第二是截圖資料。Full desktop screenshot 會看到 browser window 之外的 UI、native dialog、OS modal。企業要知道這些圖像是否被保存、送給哪個模型、如何遮蔽敏感資訊。

第三是權限範圍。AWS 範例需要 IAM execution role，包含 bedrock-agentcore:InvokeBrowser、StartBrowserSession、StopBrowserSession。這類權限不該隨便給所有 agent。

第四是虛擬化限制。AWS 文件提到，某些 context menu items 在 virtualized environment 裡可能表現不如預期。這意味著 OS action 不是萬能鍵，還是要測。

什麼時候值得打開這層能力

如果你的任務全在網頁 DOM 裡完成，OS Level Actions 未必必要。Selector、accessibility tree、CDP、Playwright 仍然更穩、更可讀、更容易測。

適合使用 OS action 的，是那些會跨出 web layer 的流程：

• 下載或列印時跳出 native dialog。
• 企業登入需要 certificate chooser 或安全 prompt。
• 工作流依賴右鍵選單或鍵盤快捷鍵。
• 視覺代理人需要操作整個 browser environment，而不只網頁內容。
• 測試團隊要驗證真實使用者會遇到的 modal 或 OS prompt。

開啟之前，團隊應該先確認：

問題	需要答案
Session 範圍	代理人只能操作哪個 browser session？
Action 範圍	允許 mouse、keyboard、shortcut 到什麼程度？
Screenshot	圖像送去哪裡、保存多久、是否含敏感資料？
Verification	每次操作後是否強制截圖確認？
Stop path	點錯、失敗、畫面不明時如何停止？
Audit	事後能不能重建 action sequence？

Browser agent 的難題，常常卡在「理解畫面」和「可靠執行」中間。AWS 這次把接點往 OS layer 推了一步。這會解掉一批真實流程裡的卡點，也會迫使團隊更嚴格地定義：代理人到底被允許操作哪一層介面。