2026 Browser Agent 技術棧盤點：Browser Use、Jev、Hermes，以及它們跟 Claude Code / Codex 的組合

到 2026 年 9 月，Browser Agent 的重點已經不只是「讓 LLM 看 screenshot → 猜要點哪裡」，而是逐漸分成三層：瀏覽器本身、Agent 操作層、網站原生 API / Connector 層。而且目前最實用的架構，通常不是三選一，而是混合使用。

這篇文章把最近幾個代表性專案——Browser Use、Jev Ultrafast、Hermes Agent——放進同一個架構裡看，並整理 Hermes 跟 Claude Code / Codex 目前實際的組合方式。

Browser Use：從 agent framework 走向 browser runtime

Browser Use 在 2026 年 7 月推出 CLI 3.0，方向有很明顯的改變。以前比較像提供 Agent 一組固定工具，例如 click()、type()、scroll()；現在則讓 coding agent 在 browser harness 裡直接寫、執行 Python。

以前：

LLM → click() → type() → scroll() → Browser

現在更接近：

Codex / Claude Code / Hermes
          ↓
   Browser Use Harness
          ↓
     Python logic
          ↓
 DOM / CDP / Browser state
          ↓
        Chrome

Browser Use 自己甚至把這描述成：與其限制模型只能選固定 action，不如讓 coding agent 使用它本來就很擅長的 code loop。

這個轉向的意義是：Browser Use 越來越不像「另一個 agent」，而比較像給 Agent 使用的 Browser Runtime。如果你正在自建 workflow 系統（FlowGram、Node-RED 加 AI coding agent 那類），這是關鍵差異——你不需要整合一個會搶主導權的 agent，你整合的是一個 runtime。

登入這道門檻：profile、cookie、CDP attach

這是 Browser Agent 最近真正跨過的一個門檻。

Browser Use 現在可以同步 Chrome profile，讓 cloud agent 使用既有的 cookies、登入狀態與 preferences：

你的 Chrome
│
├─ Google Account login
├─ cookies
├─ localStorage
├─ session
└─ saved login
       ↓
 Browser Profile
       ↓
      Agent
       ↓
Google Drive / Sheets / Gmail / Notion...

Hermes 則直接提供 use_real_profile。它不是直接操作你正在使用的 Chrome profile，而是把 active profile 複製成 Hermes 管理的 snapshot 再啟動瀏覽器，裡面包含 cookies、saved logins 和 preferences。這比「Agent 每次自己登入 Google」合理非常多。

另一條路是 CDP attach——直接掛上你已登入的 Chrome：

你已登入的 Chrome
        ↑
       CDP
        │
Hermes / Browser Use
        │
       AI

對「使用既有 Google Drive / Sheet / CMS / ERP 帳號」的情境，這比重新開一個乾淨的 Playwright browser 好用很多。

不過要說清楚：2FA、CAPTCHA、Google suspicious-login challenge 仍然是重要障礙。目前比較成熟的解法仍然是 persistent profile、人工介入、TOTP / password manager，或 cloud browser 的驗證支援——還不存在一套通用的「AI authentication protocol」。

Jev Ultrafast：把 DOM 決策壓到極致

Jev Ultrafast 是另一個值得研究的方向，但要先區分：它目前比較像 browser-action policy 的實驗，而不是完整的 Browser Agent platform。

一般 Browser Agent 的迴圈是：

Screenshot / DOM → LLM → 「我要點搜尋框」 → 找 selector → click

Jev 則是：

DOM
 ↓
建立 element table

[1] button
[2] textbox
[3] combobox
[4] link
...
 ↓
模型直接決定

operation = CLICK
target = 7

它只有 CLICK / TYPE_TEXT / SELECT / SCROLL / WAIT / DONE / BLOCKED 七種 operation，而且 operation 和 target 在一次模型 request 裡決定。更關鍵的是：它預設不傳 screenshot，所以 token 和 latency 可以大幅下降。

官方目前展示的 Google Flights 任務約 7.1 秒，測試中 browser protocol calls 中位數從約 1,092 降到 101。不過作者自己也說明，這只是少量特定任務的測試，不是廣泛 benchmark；對 iframe、canvas、upload、popup tabs、nested scrolling 等也仍有限制。

所以正確的理解是：Jev 是「怎麼讓 Agent 操作 Browser 快 10 倍」的研究方向，而不是「取代 Browser Use / Playwright 的完整平台」。

四層技術棧

把上面這些整理起來，2026 年的 Browser Agent 可以分成四層技術：

層	技術	用途
L1	API / MCP / Connector	Drive、Sheets、Gmail、大量資料
L2	DOM / Accessibility Agent	表單、後台、一般網站
L3	Browser Harness / CDP	Cookie、session、network、JS、複雜控制
L4	Vision / Computer Use	Canvas、地圖、特殊 UI、無法可靠讀 DOM

重點是 Agent 自己決定走哪一層，而不是所有事情都用 screenshot：

• 有 API → API
• 沒有 API / API 做不到 → Browser
• 需要理解 UI 狀態 → Browser
• 大量資料 → API
• 需要真正點「發布」「設定」、拖拉 UI → Browser

這也解釋了為什麼前面三個專案其實不是競爭關係：Jev 是把 L2 做到極致（DOM 壓縮成 structured state、極小 decision model）；Browser Use CLI 3.0 是在強化 L3（coding agent 寫 Python 直通 CDP）；Hermes 則是在做上層 orchestration，把這些 backend 都接起來。

Browser = Authentication + Discovery，API = Execution

還有一個更進一步的模式值得單獨講。現在很值得做的不是：

AI → click → click → click

而是：

AI
 ↓
Browser
 ↓
觀察 Network / DOM
 ↓
發現網站 internal API
 ↓
直接 request

例如某個 SaaS 後台，頁面本來就在打 GET /api/projects、POST /api/search 這類 internal API。Browser 已經有 cookie、CSRF token、session、authorization——所以 Agent 可以先透過 browser 建立 authenticated context，再在允許且合適的情況下，直接利用頁面正在使用的資料介面。

這形成一個很乾淨的分工：

Browser = Authentication + Discovery
API     = Execution

而不是 Browser = Everything。

以「找出 Drive 裡『活動報名』資料夾的 20 個 Sheet，把報名人數加總，再修改某張 Sheet」為例——純 Browser Agent 當然能做：打開 drive.google.com、搜尋、double click、開 Sheet、讀 cells、一張一張切……能做，但非常浪費。更好的做法是 Drive / Sheets 走 API（L1），只有真的需要 UI 的那一步才進 browser。

Hermes 到底是什麼：不是 MCP、不是 Skill、也不只是 CLI

接下來是很多人問的問題：Hermes 現在的定位是什麼？

以 2026 年 9 月的 Hermes Agent 來看，它已經不是「另一個 Claude Code / Codex CLI」。更準確地說：Hermes 正在變成 Agent 的上層 runtime / orchestration shell，而 Claude Code、Codex、Browser、MCP、Skills 都可以成為它下面的能力來源。Nous Research 自己也明確把 Hermes 描述成不是 IDE coding copilot，而是可以長期運行、具有 memory、skills、browser、cron、subagents、messaging gateway 的 autonomous agent。

先把幾個東西的位置分清楚：

東西	比較像
Claude Code / Codex	超強 Coding Agent + Terminal Runtime
Hermes	通用 Personal / Autonomous Agent Runtime
MCP	Agent 接外部工具的協定
Skill	Agent 可累積、重複使用的工作方法 / procedure
Browser Use	Browser execution runtime
CLI	其中一個操作 Hermes 的入口

所以 Hermes 不是 MCP，也不是 Skill，也不只是 CLI——它是把這些東西組織起來的 Agent Runtime。而在 browser 這塊，Hermes 不綁死單一 backend：預設用 Browser Use CLI 3.0，另外能切 Browser Use Cloud、Browserbase、Firecrawl、Camofox、Lightpanda，或本地 Chromium / Chrome / Edge / Brave（含 CDP attach）。

Hermes × Codex：兩種套娃姿勢

這是最近 Hermes 最重要的變化。目前有兩種完全不同層級的組合方式。

姿勢一：Codex 當 execution runtime（Codex App-Server Runtime）

Hermes 現在有一個 Codex App-Server Runtime。啟用後，Hermes 可以把 OpenAI / Codex 的 agent turn 直接交給 Codex CLI runtime 執行：

                Hermes
                  │
        ┌─────────┴─────────┐
        │                   │
     Hermes             Codex Runtime
     Memory                  │
     Skills                  ├─ shell
     Session                 ├─ apply_patch
     Telegram                ├─ sandbox
     Discord                 ├─ MCP
     Cron                    └─ Codex plugins
     Browser

也就是 Hermes 當外殼，Codex 當 execution brain / runtime。這跟「Hermes 呼叫一下 codex 指令」是完全不同層級的整合。

而且 Hermes 會反過來把自己的 tools 暴露成 MCP server 給 Codex：

Codex
  │
  │ MCP
  ↓
hermes-tools
  │
  ├─ web_search
  ├─ browser automation
  ├─ vision
  ├─ image generation
  ├─ skills
  └─ TTS

形成一個雙向結構：Hermes 提供 Memory / Skills / Browser，Codex 提供 coding execution，透過 MCP 互相取用。目前這個 Codex App-Server Runtime 仍被官方標成 opt-in beta。

姿勢二：Codex 當 MCP server（specialist tool）

另一種組合是把 Codex 當成 Hermes 的一個工具。Hermes 直接提供 preset：

hermes mcp add codex --preset codex

本質上就是跑 codex mcp-server。這時候主 Agent 還是 Hermes，Codex 比較像 Hermes 的 coding specialist：

你：「幫我把 FlowGram 的 browser node 改成支援 Browser Use」
        ↓
Hermes
 │
 ├─ 理解你的長期專案（Memory）
 ├─ 查文件、Browser research
 │
 └─ Codex MCP
       ↓
    修改 repo → 跑 test
       ↓
Hermes 整理結果

Hermes × Claude Code：搬家與互通

Hermes 對 Claude Code 的方向則比較偏 migration / interoperability。它可以：

hermes import-agent claude-code

直接讀 ~/.claude/，把 Claude Code 的環境搬進 Hermes：

Claude Code	→ Hermes
CLAUDE.md	Memory
permissions	command allowlist
MCP servers	MCP servers
skills/	Hermes skills

甚至 session 都可以搬過去繼續：

hermes --resume @claude
hermes --resume @codex

Hermes 會讀 Claude Code 的 session logs 或 Codex 的 rollouts，建立自己的 Hermes session。它明顯在解決的問題是：「我已經有 Claude Code / Codex 的工作環境，為什麼要重建一套 Hermes？」——答案變成：不用。

Skill 正在變成可攜式的「工作方法」

Hermes 的 Skills 相容 agentskills.io 開放格式，並把 skill 當成 procedural memory。於是開始出現這種世界：

             SKILL.md
                │
      ┌─────────┼─────────┐
      ↓         ↓         ↓
   Hermes    Claude     Codex
             Code

Hermes import 時，~/.claude/skills/<name>/ 會進到 ~/.hermes/skills/claude-code-imports/<name>/，Codex 的 ~/.codex/skills/ 也一樣有對應的 import 路徑。

這代表 Skill 正逐漸變成 Agent 世界可攜式的工作方法（SOP），而 MCP 是工具介面。這兩個概念不要混在一起：MCP 不是「智慧」，Skill 不是「API」，Codex 不是「MCP」，Hermes 不是「CLI」——它們在不同的 abstraction layer。

訂閱制的現實：ChatGPT OAuth 通，Claude Pro 不通

這也是最近很重要、而且容易搞混的變化。

Hermes 文件目前列出 OpenAI Codex — ChatGPT plan OAuth：支援。也就是可以透過 ChatGPT 的 device-code OAuth 使用 Codex models，不必另外走 OpenAI API billing。不過官方也特別註明：plan quota 的具體 semantics 尚未完整文件化，所以不能理解成「Hermes 可以無限制吃你的 ChatGPT 額度」。

Claude 這邊則不同：Hermes 的 Anthropic OAuth 路徑是透過 Claude Code credential store，但 Claude Pro 不支援這條路；官方描述的 OAuth 情境是 Claude Max 加額外 usage credits，API key 則是另一回事。

所以如果你主要想吃訂閱制而不是 API billing，目前 ChatGPT / Codex subscription → Hermes 這條路，比 Claude Pro → Hermes 清楚。

如果你要自建 workflow 系統

把以上全部收攏，對想自建 workflow 系統（以 FlowGram 這種自控 Workflow UI + AI Agent + MCP / Skills 的架構為例）的建議是：把 Browser 做成一個獨立 Runtime，不要自己實作 browser automation。

┌───────────────────────────────┐
│           FlowGram            │
│                               │
│  Agent Node                   │
│       │                       │
│       ├─ MCP                  │
│       ├─ Skill                │
│       ├─ API                  │
│       └─ Browser              │
└──────────────┬────────────────┘
               │
        Agent Runtime
               │
 ┌─────────────┼─────────────┐
 ↓             ↓             ↓
MCP        Browser Use      Jev
 ↓             ↓             ↓
Drive        Chrome        Fast DOM
Sheets       CDP           actions
Gmail          │
               ↓
        authenticated
        browser profile

用 FlowGram 的思維對照，各個概念的位置就很清楚：

東西	比較像 FlowGram 的什麼
Hermes	整個 Workflow Runtime
Claude Code / Codex	Coding Agent Node
Browser Use	Browser Node
MCP	Node / Tool interface protocol
Skill	reusable workflow / SOP
Memory	persistent state
Cron	trigger
Telegram / Discord	input / output trigger
Subagent	nested agent workflow

一個實際任務——「把 Drive 裡所有 2026 活動報名 Sheet 找出來，整理報名人數，再登入活動後台確認付款狀態」——Agent 應該自己拆成：Drive MCP 搜尋 → Sheets API 批量讀取 → Python 整理 matching → Browser Use 登入活動後台 → Jev-like DOM policy 快速查 UI → 遇到特殊操作才落到 Browser Harness。

結語

把 2026 年 9 月的全貌畫成一張圖：

                    USER
                      │
                      ▼
              ┌──────────────┐
              │    HERMES    │
              │              │
              │ Memory       │
              │ Skills       │
              │ Sessions     │
              │ Cron         │
              │ Subagents    │
              │ Messaging    │
              └───────┬──────┘
                      │
        ┌─────────────┼───────────────┐
        │             │               │
        ▼             ▼               ▼
      CODE           MCP            BROWSER
        │             │               │
   ┌────┴────┐    ┌───┴────┐    ┌────┴─────┐
   │         │    │        │    │          │
 Codex    Claude  Drive   GitHub Browser   CDP
 Runtime   Code   APIs    APIs    Use      Chrome

Hermes 不是想證明「它 coding 比 Claude Code / Codex 強」，而是在問：既然 Codex / Claude Code 已經很會 coding，能不能把它們包進一個長期存在、有 Memory、Skills、Browser、MCP、Messaging、Automation 的 Agent OS？

對自建系統的人來說，這個分層的好處是不必重新發明 Agent runtime：你的 Workflow UI 做你真正想控制的視覺節點層，Hermes 做 orchestration，Codex / Claude Code 做 coding execution，Browser Use 做 Web runtime，MCP 做外部服務介面，Skill 做可累積的工作程序。

Browser Agent 的競賽已經不在「誰的 click 比較準」，而在誰能讓 Agent 在對的層級做對的事。