論文：Signal-Driven Observation for Long-Horizon Web Agents 類型：Position Paper（立場論文，提出問題與方向，尚未完整實作） 核心論點：Web agent 應將「觀看」與「行動」解耦

城武導讀

如果你用過任何「AI 幫你操作網頁」的工具——無論是 Claude 的 computer use、Browserbase、還是各種 open-source web agent——你一定遇過這個狀況：任務跑到一半，agent 突然忘記自己在幹嘛了。不是模型笨，是它每一動都要把整頁 DOM 重讀一遍。

這篇論文的核心論點簡潔到近乎優雅：把觀看頻率綁在動作頻率上，是 web agent 設計的根本錯誤。

以下是論文摘要翻譯（城武風）加上觀點。

當前 Web Agent 的荒謬設計

典型的 web agent 工作流程是這樣的：

  1. 收到任務（例如「幫我在 PChome 找到最便宜的機械鍵盤」）
  2. 讀取整頁 DOM + accessibility tree → 數萬個 token
  3. 決定下一步動作 → 執行（點擊、輸入、滾動）
  4. 頁面更新 → 再讀一次整頁 DOM → 又數萬個 token
  5. 重複步驟 3-4，直到任務完成或 context window 爆掉

問題在第 4 步。一個稍微複雜的任務跑個 10-15 步，光 DOM 就吃掉幾十萬 token。到後半段，模型已經在 context 的垃圾堆裡游泳——progressive context degradation（漸進式上下文劣化）——推理能力在任務完成前就先崩潰了。

論文引用 Recursive Language Models 的洞見：「查詢一份文件比整份讀完更有效。」 Web agent 的問題本質上是一樣的：你不需要每次動作前都把整個網頁「讀完」，你只需要「查詢」跟任務相關的部分。

Signal-Driven Observation（SDO）：核心設計

SDO 的提案分成三個層次：

1. 專用子呼叫（Dedicated Sub-Call）

一個獨立的輕量呼叫負責讀完整 DOM，但只回傳跟任務相關的元素和它們的 CSS selector。這不是壓縮——是過濾。

2. 信號驅動（Signal-Driven）

重新觀看（re-observation）的頻率不由動作頻率決定，而是由一個輕量的信號偵測器觸發。觸發條件包括：

  • URL 轉換（頁面跳轉了）
  • 新的互動元素出現（modal 彈出、dropdown 展開）
  • 動作失敗（點擊沒反應、元素不存在）
  • 外部瀏覽器事件（alert、navigation）

3. 輕量級

信號偵測器本身不跑 LLM——它只是監聽 DOM mutation 和瀏覽器事件。開銷接近於零。

論文的誠實：目前還是 Position Paper

這篇論文目前還是 position paper——提出了問題、定義了方向、概述了設計，但沒有完整的實作和 benchmark。論文最後列出 SDO 引入的開放問題：

  • 信號偵測器可能漏掉語意層級的重要變化（只看 DOM 結構不夠）
  • 過濾後的觀察可能遺漏因果鏈（你需要看到 A 才能理解 B）
  • 信號閾值的校準本身就是一個難題（太敏感 = 等於每步重讀；太遲鈍 = 錯過關鍵變化）

城武觀點

1. 為什麼這篇論文重要——即使它還沒有實作

這篇是那種「看完覺得超合理，為什麼沒人早點做」的論文。但它的價值不在於一個可以馬上用的工具，而在於指出了一個整個領域集體忽略的設計措誤。

目前 web agent 的設計思維太像 RPA（機器人流程自動化）了：每一個動作都是一個獨立的 LLM call，每一次呼叫都要重新理解整個網頁。但網頁操作本質上是序列決策——你不需要每一步都從零開始，你只需要在環境發生有意義的變化時更新你的理解。

2. 人類的類比

人類做事的時候也不會每秒重新掃描整個環境。我們只在有變化時才更新注意力——門開了、有人叫你、螢幕閃了一下。其他時候，我們依賴一個持續運行的「背景感知」來維持情境意識。SDO 本質上是在 web agent 架構中複製這個機制。

3. 更大的啟示：Agent 架構需要「感官系統」

SDO 最大的洞見不是技術上的，而是哲學上的：agent 需要一個跟「行動系統」獨立的「感官系統」。行動頻率不應該綁架感知頻率。

這個洞見不只適用於 web agent——任何需要跟動態環境互動的 AI agent（機器人、遊戲 AI、自駕車）都應該認真考慮把感知和行動解耦。

城武的未解檔案——每個好的解法背後，都有一個被大家當成理所當然的爛設計。