AI 代理人跑了 20 分鐘，誰來決定要不要繼續？OpenAI、Google、AWS 給了三種答案

重點一：2026 年 5 月，OpenAI、Google、AWS 各自推出一個新功能，應對的是同一個設計挑戰——AI 代理人在跑長時間任務時，人類怎麼保持控制？三家的答案完全不同。

重點二：OpenAI Codex 把手機變成批准介面（pull）；Gemini API Webhooks 讓任務跑完後主動通知你的系統（push）；AWS AgentCore 讓代理人透過截圖循環控制整個桌面（loop）。

重點三：三種模型背後是三種不同的責任邊界假設。選錯模型，代理人出事的時候，第一個說不清楚的就是誰該負責。

2026 年 5 月，OpenAI、Google 和 AWS 在同一個月各自推出了一個新功能，應對的是同一個設計缺口：AI 代理人跑了 20 分鐘，人類要怎麼保持控制？

OpenAI 的答案是手機批准介面：代理人繼續在遠端機器上跑，你在捷運上滑手機，看到截圖和終端輸出，決定要不要批准下一步。Google 的答案是 Webhook 回調：任務先跑完，跑完了系統主動打 HTTP POST 告訴你，你的服務在幾秒內回 2xx，然後自己去取結果。AWS 的答案是截圖循環：代理人每做一個動作就截圖，用截圖內容推理下一步，連跳出來會卡住自動化流程的列印視窗也能處理。

三種設計不分優劣。但三種設計代表三種不同的批准點位置，批准點在哪，責任就在哪。

長任務代理人的設計挑戰：批准點在哪裡，責任就在哪裡

AI 代理人的任務週期正在拉長：從秒級的一問一答，拉長到分鐘、甚至小時級的自動執行。Deep Research、批次資料處理、跨系統的多步驟工作流、OS 層的 UI 自動化——這些任務在跑的過程中，開發者通常不在旁邊盯著。

這帶來一個之前不存在的設計問題：代理人在你沒看著的時候做了動作，事後的責任要怎麼算？

這個問題聽起來像管理焦慮，實際上是工程架構問題。你的審計日誌怎麼記？你的回退機制在哪個步驟觸發？你的操作員知道批准的意思是「這個步驟我看過了」還是「整個任務我授權了」？批准點設計決定了這些答案。

「長任務代理人的核心問題不是效能，是責任邊界：代理人做了一個你事後不同意的動作，你跟代理人各扛幾成？」

本文用 pull / push / loop 三個詞來對照三家的設計。先說清楚：這是 Signals 編輯部為了比較而起的分類名稱，方便讀者對照用，並非 OpenAI、Google 或 AWS 的官方術語。三家的設計，各有各的假設。

---

Pull 模型：OpenAI Codex 手機批准——代理人等你看完，再繼續

OpenAI 在 2026 年 5 月 14 日把 Codex 帶進 ChatGPT 手機 App 預覽版（iOS 和 Android，逐步開放到所有方案，包含 Free 與 Go）。設計重點只有一句話：手機載入的是代理人工作的即時狀態。

你的筆電、Mac mini、或受管的遠端環境繼續跑 Codex。手機端你能看到截圖、終端輸出、差異（diff）、測試結果；你能批准指令、換模型、或開一個新工作。但檔案、憑證、權限、本機設定全部留在原本機器上，沒有任何東西移進手機。手機只是決定層，執行層在別的地方。

OpenAI 用了一個**安全中繼層（secure relay）**讓受信任的機器可以跨裝置連線，但不直接暴露在公開網路上。Remote SSH 同步正式可用（GA），讓 Codex 桌面版可以偵測 SSH 設定、在遠端機器內建立專案和執行任務。

Pull 模型的責任邊界：你批准了哪一步，就對那一步的執行結果負責。你在手機上看了截圖和輸出之後點了批准，代理人繼續——這個動作的審計紀錄是你的。需要人批准的指令，就等你回來再決定。這個設計把人類判斷時機的選擇權放到使用者手上。

代價是任務節奏。代理人的長任務從「你去忙，它跑完你回來看」變成「你得在某個時間點回來確認，它才能往下走」。Pull 模型假設你願意在任務中途被打斷——而且你能在手機的小螢幕上看懂足夠的資訊做出判斷。

---

Push 模型：Gemini API Webhooks——任務跑完，系統打電話告訴你

Google 在 2026 年 5 月 4 日為 Gemini API 推出 Webhooks，讓長時間跑的非同步任務在完成後主動通知，而不是讓你每隔幾秒問一次「好了嗎」。

設計對象是長時間非同步任務：Deep Research、長影片生成、大型批次任務、高流量處理工作。這些任務可能要跑幾分鐘到幾十分鐘，用輪詢（polling）不只浪費請求，更讓系統架構變複雜。

Gemini Webhooks 的實作是 HTTP POST callback，採用 Standard Webhooks 規格：每個請求帶 webhook-signature、webhook-id、webhook-timestamp 三個標頭。你的端點要在幾秒內回 2xx，然後非同步處理後續邏輯。沒有回 2xx？Gemini 會自動重試，最長 24 小時。

有兩種設定方式：靜態 Webhook（專案層級，簽名密鑰只給你一次，自己存好）和動態 Webhook（請求層級，JWKS 簽名）。事件目錄包括：batch.succeeded、batch.failed、batch.cancelled、batch.expired、interaction.completed、interaction.requires_action、video.generated 等。

回傳內容是薄的（thin payload）：Gemini 只告訴你「發生了什麼、結果在哪」，不把完整輸出塞進 callback body。你要自己去取結果。

Push 模型的責任邊界：任務先跑完，你的系統在收到 callback 後決定怎麼處理結果。人類的批准介面不在任務執行中途，在任務完成之後。這個模型假設你的系統設計是「任務先跑，結果出來再處理」——適合批次作業、非同步資料管線、不需要中途人工介入的生成任務。

這裡有一個你必須自己處理的細節：Gemini Webhooks 是 at-least-once delivery，不是 exactly-once。同一個 webhook-id 可能來兩次，而 Google 不會替你去重——去重邏輯要寫在你這端。

白話講：收到 batch.succeeded 之後，先確認 webhook-id 沒有被處理過，再去取結果，再做你的業務邏輯。這不難，但要記得設計進去。

---

Loop 模型：AWS AgentCore 截圖循環——代理人每一步都讓你看得到

AWS AgentCore Browser 在 2026 年 4 月 8 日宣布、5 月 5 日發布詳細技術文件的 OS Level Actions，解決的是所有 UI 自動化工程師都碰過的限制：有些 UI 就是不在 DOM 裡面。

標準的瀏覽器自動化只在瀏覽器的網頁層（DOM／CDP）內運作。但原生對話框、憑證選擇器、安全提示、Chrome 設定頁、右鍵選單——這些在 DOM 以外，CDP 碰不到。你的代理人要列印一份文件，列印視窗一跳出來，任務就卡住了。

AWS 的解法是把 OS 層的控制權暴露出來，透過 InvokeBrowser API。設計是一個動作──截圖──推理循環（action-screenshot-reaction loop）：送出動作 → OS 桌面執行 → 擷取整個桌面截圖（包含原生視窗）→ 視覺模型推理下一步 → 繼續。

八個動作：mouseClick、mouseMove、mouseDrag、mouseScroll、keyType、keyPress、keyShortcut、screenshot。每個呼叫帶一個動作，回傳 SUCCESS 或 FAILED（含 session ID x-amzn-browser-session-id）。只有 screenshot 動作有資料回傳；其他動作只告訴你成不成功。

AWS 自己舉的例子是列印視窗：代理人截圖看到列印對話框 → 視覺模型定位取消鍵的座標 → 點擊 → 再截圖確認對話框消失。

Loop 模型的責任邊界：每個動作都有一次截圖為證，你的審計紀錄是每一步的畫面。代理人不能跳過任何一個步驟。可見度最高，但操作代價也最高——每個任務步驟都要一次截圖推理才能繼續。

一個你需要知道的限制：AWS 在文件裡自己提醒，右鍵選單這類操作可能不會照預期運作。座標定位式的控制，在 UI 改版或解析度變動時也容易失準——官方沒有給量化的失敗率，導入前要用自己的工作流先測過。

此功能在 AgentCore Browser 可用的 14 個 AWS 區域預設啟用。

---

三種模型怎麼選：先決定批准點，再決定平台

換句話說，三種模型攤開來比的，是你的批准點落在任務生命週期的哪個位置：

模型	批准點	誰主動	適合場景	責任邊界
Pull（Codex）	任務中途，任意時刻	人類主動回來看	需要中途調整方向的開發任務、高風險步驟	你批准了哪一步，那一步你負責
Push（Gemini Webhooks）	任務完成後	系統主動通知	批次處理、生成任務、非同步資料管線	任務設計是你批准的；你的系統處理結果
Loop（AWS AgentCore）	每一個動作步驟	截圖驅動，代理人持續	OS 層 UI 自動化、含原生對話框的工作流	每步有截圖記錄；座標控制可能不穩

導入長任務代理人前，先釐清三個選型判斷：

1. 任務中途，你需要人工介入嗎？ 如果是（需要改方向、確認高風險步驟）→ Pull 模型。如果否（任務設計好了讓它跑完）→ Push 模型。
2. 你的系統有 Webhook callback 基礎設施嗎？ 有（有 endpoint、有重試處理、有去重邏輯）→ Push 模型可用。沒有 → 先用 Pull 或 Loop，暫時不碰 Push。
3. 代理人需要控制 OS 層 UI 嗎？ 需要（原生對話框、列印視窗、憑證選擇器）→ Loop 模型。不需要 → Loop 的座標控制成本，拿來換 Pull 或 Push 的簡單性更划算。

三項判斷的答案可能讓你選同一種，也可能讓你在同一個工作流裡混用（例如：主要任務用 Push，特定步驟用 Loop 處理 OS 層 UI）。下次團隊討論代理人選型，把這張表帶進會議室：先決定批准點放在哪裡，再去比平台功能。順序反過來，你很容易拿著功能清單，選到一個責任邊界跟團隊假設不合的架構。

資料來源：OpenAI 官方公告〈Work with Codex from anywhere〉（2026-05-14）、Google 官方公告〈Reduce friction and latency for long-running jobs with Webhooks in Gemini API〉（2026-05-04）、Gemini API Webhooks 文件、AWS Machine Learning Blog〈Introducing OS Level Actions in Amazon Bedrock AgentCore Browser〉（2026-05-05）、AWS What’s New AgentCore Browser OS actions（2026-04-08）。

林子睿（編輯：廖玄同），《AI 代理人跑了 20 分鐘，誰來決定要不要繼續？OpenAI、Google、AWS 給了三種答案》，矽基前沿 [Si]gnals，2026-06-10。https://signals.tw/articles/agent-long-task-control-patterns/