認識 Stagehand：用自然語言操作瀏覽器的 AI 自動化框架

📅 2026年8月16日

stagehandaie2e-testingplaywrightvue

Stagehand 是 Browserbase 開源的 AI 瀏覽器自動化框架，讓你在程式碼裡用自然語言操作網頁：act() 執行動作、extract() 擷取結構化資料、observe() 觀察頁面上有什麼可以互動。它底層直接走 Chrome DevTools Protocol，提供 TypeScript、Python、Go 三種 SDK，MIT 授權，官方給它的定位是「browser agent 的 SDK」。

會想寫這篇，是因為最近社群上不少人在討論 Stagehand。點進官網一看，首頁開門見山就是跟 Playwright 的比較：標語直接寫「Playwright 為測試而生，Stagehand 為 agent 而生」，旁邊還掛了一張宣稱連執行速度都比 Playwright 快的圖表，這個嗆聲的力道讓我大感興趣。

---

結果一查才發現，Stagehand v4 在 2026 年 8 月 10 日剛發佈，API 整個大改。網路上九成的教學文，甚至 AI 助手憑訓練資料生出來的程式碼，都還是 v2/v3 的舊寫法，直接照抄會烙賽。剛好趁著這幾天幫一個 Vue 專案接了一輪 v4，我把正確的用法、適用場景，連同另外兩個常被拿來比較的工具 browser-use 和 Playwright MCP，一起整理成這篇筆記。

文中的完整範例放在 stagehand-vue-demo 這個 repo，clone 下來填一把 OpenAI API key 就能跑。

Stagehand 想解決什麼問題

寫過 E2E 測試的朋友應該都有這個經驗：辛苦寫好的測試，隔週設計師改了版，.btn-primary 變成 .btn-cta，測試就紅了。公平地說，Playwright 這幾年力推的 getByRole() 這類語意 locator 已經耐摔很多，但前提是頁面是你的、結構你說了算。碰上第三方網站或常改版的頁面，綁著 DOM 結構的 CSS selector 和 XPath 寫得再漂亮，指路的地圖還是會過期。

Stagehand 的做法，比較像僱了一位看得懂畫面的 AI 助理。你不用告訴它 selector，只要說「幫我點新增按鈕」，它會自己看頁面結構找到那顆按鈕。按鈕從藍色變紅色、class 名稱重取、位置從左邊搬到右邊，指令都不用改，因為「新增按鈕」這個語意沒變。

當然，天下沒有白吃的午餐。這位助理每次聽你用自然語言下指令，背後都是一次 LLM 推論，有成本、有延遲，而且偶爾會看走眼。但還好 Luna 出現後整體成本變得很便宜。所以 Stagehand 的核心設計哲學是讓你自己決定 AI 的介入程度：穩定的部分照舊寫死程式碼，只在容易變動的地方請 AI 出手。

一個初學者很容易搞混的地方先講清楚：Stagehand 是開源框架，Browserbase 是開發它的公司與雲端瀏覽器服務，兩者可以分開用。在自己電腦上跑 Stagehand 完全免費，只要自帶模型的 API key；接上 Browserbase 雲端則多了 server-side 快取和 Model Gateway（連模型都不用自己配）這些進階功能。

這篇的範例全部在本地跑，不需要 Browserbase 帳號。

三個核心 API

先從安裝開始。官方套件一行搞定，TypeScript 版要求 Node.js 22.18 以上（另有 Python 和 Go 版，API 完全對等，本文以 TypeScript 示範）：

npm install @browserbasehq/stagehand zod

zod 是待會 extract() 定義資料形狀要用的，順手一起裝。更完整的起手式可以看官方的 Installation 和 Quickstart。

裝好之後，Stagehand v4 的使用流程是先啟動一個 headless 瀏覽器，再把它交給 Stagehand：

import { localBrowser, Stagehand } from "@browserbasehq/stagehand";

const browser = await localBrowser.launch({ headless: true });
const stagehand = await Stagehand.create({
  browser,
  model: {
    modelName: "openai/gpt-5.6-luna",
    apiKey: process.env.OPENAI_API_KEY,
  },
});

在開始前，這裡有幾個需要新手提前注意的地方：

第一，Stagehand 不讀環境變數也不載入 .env，key 要自己讀自己傳，要用 dotenv 請自己 import "dotenv/config"。

第二，modelName 一定要帶 provider/ 前綴（目前可支援 openai、anthropic、google、groq、cerebras 五家），SDK 內建合法模型清單，打錯字會在 create() 時直接報錯。

第三，如果你看過的教學寫 new Stagehand({ env: "LOCAL" }) 加 stagehand.init()，那是 v3 的舊語法，v4 已經整組不存在了。

搜尋引擎和 AI 助手給你的 Stagehand 範例，很高機率是 v2/v3 寫法：new Stagehand({ env: "LOCAL" })、page.act()、stagehand.agent() 這些在 v4 全部改掉或移除了。

認語法就能分辨版本：v4 的初始化是 Stagehand.create({ browser })，三個核心方法都掛在 stagehand 實例上。

如果遇到「Constructor of class 'Stagehand' is private」這個錯誤訊息，就是抄到舊教學了。

act()：用一句話執行動作

await stagehand.act("在待辦事項輸入框輸入「買牛奶」");
await stagehand.act("點擊新增按鈕");

act() 接一句自然語言，Stagehand 會把頁面的 accessibility tree 交給 LLM，找出對應元素並執行動作。回傳值是 { data, metadata } 的結構，data 裡有成功與否和實際執行的動作明細，metadata 裡有快取狀態這些資訊。這個包一層的設計是 v4 統一的規格，三個 API 都一樣，解構的時候別忘了先取 .data。

用 act() 有一條官方反覆強調的鐵則：一次只做一件事。

「輸入帳號密碼然後登入」這種複合指令很容易出錯，拆成三句各自明確的指令，成功率會高很多。另外，要往輸入框填敏感資料時，可以用 %password% 這種佔位符搭配 variables 參數，實際的值不會被送進 prompt。

extract()：把頁面變成型別安全的資料

import { z } from "zod/v4";

const { data } = await stagehand.extract(
  "擷取目前清單上所有待辦事項的文字，以及底部顯示的未完成事項數量",
  z.object({
    todos: z.array(z.string()),
    remaining: z.number(),
  }),
);

console.log(data.todos);     // ["買牛奶", "寫部落格文章"]
console.log(data.remaining); // 2

extract() 是我覺得三個 API 裡最實用的一個。

你用自然語言描述要什麼資料，附上一個 Zod schema（Python 版用 Pydantic），拿回來的就是驗證過、帶完整型別的物件。爬蟲場景不用再寫一堆 querySelector 加字串清洗，E2E 測試的斷言也可以直接對這個結構化結果下。

注意官方範例的 import 是 "zod/v4"，可以照抄就好。

observe()：先觀察，再出手

const { data: actions } = await stagehand.observe("找出所有表單輸入欄位");

for (const action of actions) {
  await stagehand.act(action); // 這裡不會呼叫 LLM
}

observe() 會回傳一個 Action 陣列，每個元素都帶著 selector 和操作方式。

重點來了：把這個 Action 物件餵回 act()，Stagehand 會直接照著執行，完全不經過 LLM。猜猜看這樣重放一次要花多少推論成本？答案是零。

這就是 Stagehand 對付「AI 又貴又慢又不穩定」的解法：第一次讓 AI 看懂頁面（付一次推論成本），之後走熟了就不用再問路。官方推薦的「plan then execute」模式就是這個概念，一次 observe 拿到整張表單的動作清單，接著 N 次零推論重放。搭配 Stagehand.create() 的 selfHeal 選項，哪天 selector 真的失效了，它會自動退回 AI 模式重新推論一次。

如果接上 Browserbase 雲端，還有跨機器的 server-side 快取可以用，不過本地的 observe 重放已經夠應付多數場景。

還記得開頭官網截圖右邊那張速度對比圖嗎？它宣稱同樣的操作、同一顆模型下，Stagehand 連執行層都比 Playwright 快（點擊 97ms 對 364ms、輸入 291ms 對 1.5s）。原理是 v4 把 runtime 用 extension 的形式塞進瀏覽器裡，省掉傳統自動化工具 client 與瀏覽器之間的往返。不過這是官方自家測的，方法細節揭露有限，v4 blog 自己都提醒單次實測別當 benchmark 看，數字聽聽就好，架構方向倒是說得通。

還有一條跟 act 鐵則同等重要的安全原則：要重試就重試 observe，不要重試 act。因為 act 失敗的當下，動作可能已經做了一半，按鈕可能已經按下去、表單可能已經送出，直接重試會把副作用執行兩次。這在碰付款流程的時候尤其要命。

agent() 去哪了？

如果你查過 Stagehand 的舊資料，可能會問：說好的 agent() 呢？那個丟一句「幫我上網比價然後把最便宜的加入購物車」就能自主完成任務的模式呢？

v4 把它移除了，而且官方講得很直接：「agent() is gone. Nothing in v4 replaces it one-for-one.」

理由同樣值得玩味：agent() 當年是為了「模型還不太會操作瀏覽器」的時代設計的包裝迴圈，現在模型本身的 agent 能力夠強，這層包裝反而顯得多餘。官方給的替代路線有兩條：一條是 code mode，讓 Claude Code 這類 coding agent 直接產生 Stagehand 腳本來執行；另一條是把 act/extract/observe 當工具接給模型，自己組 agent loop。

換句話說，Stagehand v4 選擇退回去做好「手和眼睛」，把「大腦」的位置讓出來。這個取捨也剛好成了它跟 browser-use 最大的分水嶺。

什麼場景適合用 Stagehand

聊完 API，我們來談一個更實際的問題：你的專案到底需不需要它？我的建議是看「selector 的變動頻率」和「網站是不是你的」這兩個軸來判斷。

最典型的甜蜜點是 E2E 測試裡那些 UI 常變、selector 易碎的路段。官方在遷移指南裡給的策略我覺得很務實：行銷頁、第三方結帳、正在跑 A/B 測試的介面，這些地方換成 act() 搭配 selfHeal；後台管理這種穩定的頁面，繼續用原本的 page.locator() 寫死。Stagehand 保留了 Playwright 風格的 page API，兩種寫法可以在同一份測試裡混用，你可以只在最痛的那 20% 引入 AI。

第二個適合的場景是對別人網站的爬蟲和資料擷取。網站不是你的，改版你管不著，selector 綁得再穩都是在賭。extract() 加 Zod schema 的組合直接把「找元素、抓文字、清洗、驗證」壓成一句自然語言，網站改版了八成還能動。

第三個是幫 AI 產品做瀏覽器操作層。如果你在做的產品需要讓 agent 上網操作（訂位、查價、填表單），Stagehand 的三個 primitive 就是現成的手腳，v4 的 code mode 路線也是衝著這個場景設計的。

反過來說，這幾種情況我會勸你別用。純內部專案、selector 完全在自己掌控之下，直接寫 Playwright 又快又省，每一步都零成本零延遲，引入 LLM 是拿確定性去換你不需要的彈性。需要 Firefox 或 WebKit 覆蓋的相容性測試也出局，Stagehand 只支援 Chromium 系。想要完整測試框架體驗的人（fixtures、trace viewer、平行分片這些），會發現 Stagehand 根本沒有這些東西，它自己都說了「Stagehand is not a test framework」，這時候你要的是 Playwright Test 本人。最後，想丟一句模糊指令讓 AI 自己想辦法完成整趟任務的，v4 已經沒有 agent()，這個需求是 browser-use 的主場。

補一個安全面的提醒：讓 AI 讀第三方頁面，頁面內容本身就可能是 prompt injection 的來源，惡意網頁可以把指令藏在文字裡騙模型做事。實務上請限制允許造訪的網域、在隔離環境跑瀏覽器、付款這類不可逆操作前留一道人工確認，也不要把 API key 或密碼放進頁面上下文。

與 Vue 專案搭配：實際寫一個 E2E 測試

講了這麼多概念，我們動手把 Stagehand 接進一個 Vue 專案，也就是開頭提到的 stagehand-vue-demo。被測目標是一個 Vue 3 + Vite 的待辦清單，我刻意不加任何 data-testid，模擬真實世界那種「元件寫得很自然、對測試很不友善」的頁面。

架構上有一個關鍵決定要先講：前面提過 Stagehand 不是測試框架，官方的建議是「留著你原本的 runner，在裡面呼叫 Stagehand」。所以 demo 用 Vitest 當 runner，Stagehand 當操作瀏覽器的手，斷言交給 Vitest 的 expect。對 Vue 專案來說這個組合特別順，因為單元測試八成已經在用 Vitest，E2E 只是多一個測試資料夾，不用引入第二套測試工具。

環境準備三步：pnpm install 安裝依賴套件、複製 .env.example 為 .env 填入 OpenAI API key、確認本機有 Chrome。

接著看測試的骨架，我在 beforeAll 裡用 Vite 的 API 直接把 dev server 拉起來，一個指令就能跑完整包，不用先手動開 server：

import "dotenv/config";
import { createServer, type ViteDevServer } from "vite";
import { localBrowser, Stagehand } from "@browserbasehq/stagehand";

beforeAll(async () => {
  server = await createServer({ server: { port: 5199, strictPort: true } });
  await server.listen();

  browser = await localBrowser.launch({ headless: true });
  stagehand = await Stagehand.create({
    browser,
    model: {
      modelName: "openai/gpt-5.6-luna",
      apiKey: process.env.OPENAI_API_KEY,
    },
  });
});

測試本體就是前面三個 API 的組合技。

先用 act() 操作、再用 extract() 拿結構化資料給 expect 斷言：

it("可以新增待辦事項並正確顯示統計", async () => {
  const [page] = await browser.context.pages();
  await page.goto("http://localhost:5199");

  await stagehand.act("在待辦事項輸入框輸入「買牛奶」");
  await stagehand.act("點擊新增按鈕");
  await stagehand.act("在待辦事項輸入框輸入「寫部落格文章」");
  await stagehand.act("點擊新增按鈕");

  const { data } = await stagehand.extract(
    "擷取目前清單上所有待辦事項的文字，以及底部顯示的未完成事項數量",
    z.object({
      todos: z.array(z.string()),
      remaining: z.number(),
    }),
  );

  expect(data.todos).toContain("買牛奶");
  expect(data.remaining).toBe(2);
});

第二個測試示範 observe 到 act 的零推論重放，也就是前面說的「問過路就不用再問」。注意它自己重新載入頁面、自己新增資料，不依賴上一個測試留下的狀態，這是 E2E 測試隔離的基本功：

it("observe 先找到動作，act 再零推論重放", async () => {
  const [page] = await browser.context.pages();
  await page.goto("http://localhost:5199"); // 重新載入，自己準備狀態

  await stagehand.act("在待辦事項輸入框輸入「買牛奶」");
  await stagehand.act("點擊新增按鈕");

  const { data: actions } = await stagehand.observe(
    "找出「買牛奶」這個待辦事項的完成核取方塊",
  );
  expect(actions.length).toBeGreaterThan(0); // 先確認 observe 真的有找到

  await stagehand.act(actions[0]); // 這一步沒有 LLM 呼叫

  const { data } = await stagehand.extract(
    "擷取底部顯示的未完成事項數量",
    z.object({ remaining: z.number() }),
  );
  expect(data.remaining).toBe(0);
});

實測結果給大家一個具體的量感：兩個測試共 9 次 LLM 呼叫（6 次 act、2 次 extract、1 次 observe），跑一輪大約 20 到 30 秒，token 用量大約 8,000 輸入加 580 輸出，用 gpt-5.6-luna 的價格算下來一次執行約 0.002 美元。

而且從 log 可以清楚看到，act(actions[0]) 重放那一步真的沒有出現任何推論記錄。

上圖是其中一輪的執行紀錄（不同輪的秒數會浮動）。注意「Observation completed」之後直接跳到最後一次 extraction，中間沒有半行推論 log，那個空隙就是重放發生的地方。

第二個測試顯示的 10 秒，花的其實是它自己準備狀態的那幾次 act 推論，重放本身就是免費的那一步。

有兩個實務設定值得一提。Vitest 的 timeout 記得放寬（demo 設 testTimeout: 180_000），因為每個自然語言操作都要等一輪推論，用預設的 5 秒必爆。

另外中文指令經人體測試完全沒問題，我整份測試的指令都用中文寫，模型讀 accessibility tree 對照語意的能力比想像中可靠。

橫向比較：browser-use 與 Playwright MCP

「用 AI 操作瀏覽器」這個賽道上，最常跟 Stagehand 一起被點名的是 browser-use 和 Microsoft 官方的 Playwright MCP。三個工具乍看做一樣的事，骨子裡的設計哲學差很多，選錯了會很痛苦，我們先看總表再逐一拆解。

面向	Stagehand v4	browser-use	Playwright MCP
本質	程式庫 / SDK	agent 框架	MCP server
語言	TS / Python / Go	Python	不限（掛在 AI 工具下）
維護者	Browserbase	Browser Use（YC W25）	Microsoft
控制粒度	低階 primitive，流程在你手上	高階任務描述，LLM 自主決策	逐步工具，決策在 AI 工具端
模型與費用	自帶 API key	自帶 key 或官方自家模型	不內建模型，走 AI 工具的額度
可重複執行	observe 重放、雲端快取	需另裝早期的 workflow-use	codegen 產出 Playwright 測試碼
嵌入自家程式	一等公民	可（限 Python）	只能嵌 server，不含決策
瀏覽器支援	僅 Chromium 系	Chromium（CDP）	Chromium / Firefox / WebKit
GitHub stars（2026-08）	約 24k	約 109k	約 36k

註：本文查證於 2026-08-16，對應版本：Stagehand 4.0.1、browser-use 0.13.7、Playwright MCP 0.0.79。

browser-use：把方向盤整個交給 AI

browser-use 是三者中聲量最大的（一年破 10 萬 stars，YC W25 出身、拿了 Felicis 領投的 1,700 萬美元種子輪），走的是與 Stagehand 相反的路線。它的主 API 就一句話：

from browser_use import Agent, ChatOpenAI

agent = Agent(
    task="幫我到 Hacker News 找出 Show HN 排名第一的貼文",
    llm=ChatOpenAI(model="gpt-5.6-luna"),
)
await agent.run()

你描述目標，AI 自己規劃每一步、自己執行、自己修正，最多跑一百步。這種「丟一句話就開工」的體驗很迷人，對一次性的自動化任務（幫我把這 50 筆資料填進那個系統）幾乎零學習成本。結構化輸出也有支援，掛個 Pydantic model 就能拿回驗證過的資料。

代價是控制權和帳單。每一步都是一次 LLM 決策，token 成本最不可控，跑一次和跑十次的路徑可能不一樣，出錯時的除錯體驗也比較痛苦（你要翻 agent 的決策歷史找它在哪一步想歪了）。官方其實很誠實，另開的 workflow-use 專案 README 直接寫「這個專案的誕生是因為客戶希望 browser-use 更可靠、更確定性」，等於自己承認裸跑 agent 的變異性是痛點。

另外要注意本地函式庫只有 Python，TypeScript 那個是雲端 API 的 SDK，兩回事；官方力推自家的 ChatBrowserUse 模型（宣稱快 3 到 5 倍，廠商自薦請自行判斷），商業模式明顯往「模型加雲端」走。

Playwright MCP：不帶腦，借你 AI 工具的腦

Playwright MCP 的定位跟前兩者有個根本差異：它是一個 MCP server，本體完全不含 LLM。

它把「開網頁、點按鈕、打字、讀取頁面」做成 40 多個工具，掛在 Claude Code、VS Code Copilot、Cursor 這些 MCP client 底下，由 client 的模型來決策。裝起來就一行：

claude mcp add playwright npx @playwright/mcp@latest

這個架構帶來一個很實際的成本優勢：模型費用走你 AI 工具的既有額度。如果你已經付了 Claude Pro 或 Copilot 的訂閱費，讓它操作瀏覽器不用再多買一把 API key。技術上它跟 Stagehand 一樣讀 accessibility tree 而非截圖（官方數字是每份 snapshot 約 200 到 400 個 token），另外有 opt-in 的 vision mode 對付 canvas 和地圖這種特例。

它的可重複性方案也很有 Microsoft 風格：與其快取 AI 的決策，不如讓 AI 產出正規的 Playwright 程式碼。

多數操作型工具的回應都會附上等價的 Playwright code，搭配官方的 Test Agents 工作流（planner 探索頁面產出測試計畫、generator 寫出可執行的 Playwright Test、healer 修復壞掉的測試），AI 只在產生測試的當下介入，之後測試就是普通的 Playwright，跑起來零推論成本。「先讓 AI 探索、再固化成傳統測試」這條路線，跟 Stagehand「執行期保留 AI 彈性」是兩種世界觀。

弱點方面，它無法像 Stagehand 那樣當函式庫嵌進你的程式提供 act/extract 這種 API，一定要掛在一個帶模型的 MCP client 底下才有腦。而且官方自己承認 token 開銷偏高（工具 schema 加 snapshot 都要進 context），甚至在文件裡直說 coding agent 場景建議改用新的 Playwright CLI。它是輔助開發的利器，卻不太是拿來「在產品裡跑自動化」的積木。

那到底怎麼選？

你是寫程式的人，要在自己的程式碼裡精準控制 AI 何時介入（測試、爬蟲、產品功能），選 Stagehand。你想丟一句話讓 AI 自己想辦法完成整趟任務，而且團隊用 Python，選 browser-use。你已經在用 Claude Code 或 Copilot，想讓它伸手操作瀏覽器，順便幫你產出正規 Playwright 測試，裝 Playwright MCP 就對了，這也是三條路裡試錯成本最低的一條。

值得投入嗎？

最後回答那個大哉問：這個賽道現在值得押時間下去嗎？我分三個面向聊聊。

成熟度方面，三個工具都很年輕，而且變動劇烈。

Stagehand 不到兩年連出四個大版本、兩次砍掉重練（v3 脫離 Playwright、v4 把核心搬進瀏覽器 extension），你今天學的 API 明年可能又要搬家；但反過來看，npm 週下載 125 萬（2026 年 8 月數字，下同）是實打實的採用量，迭代快也代表專案活著而且有錢養（Browserbase 拿了 4,000 萬美元 B 輪）。

browser-use 有最兇的社群聲量，不過它把寶押在自家模型和雲端服務上，開源庫的定位會不會漂移值得觀察。

Playwright MCP 目前是三者中最穩的：Microsoft 維護、程式碼直接併進 Playwright 主專案、npm 週下載 660 萬，GitHub Copilot 的 Coding Agent 內建就在用它。

另外，廠商綁定風險要攤開講。Stagehand 最香的兩個功能（server-side 快取和 Model Gateway）都綁 Browserbase 雲端，本地跑等於用降級版，這是它商業模式的一部分，入坑前要有認知。browser-use 的商業引力同樣明顯，官方文件會很積極地推你用自家模型。Playwright MCP 沒有廠商綁定問題，但它的能力上限取決於你掛的 AI 工具。

至於學習成本的層面，會 Playwright 的人上手 Stagehand 幾乎無痛，概念相通、page API 還能混用；已經在用 Claude Code 的人裝 Playwright MCP 只要一行指令。真正該投資的其實是概念層，accessibility tree、observe 先行、AI 決策快取重放這些想法，比任何一家的 API 都長壽。框架會改版，心智模型不會。

所以我的建議是小規模試點，按身分入場。

前端工程師從 Playwright MCP 開始最划算，成本幾乎是零，還順便摸熟 MCP 生態；等到要把 AI 瀏覽器能力嵌進產品或測試管線，再上 Stagehand；Python 背景、手上有一堆一次性自動化雜務的，browser-use 直接開箱。至於「全面改寫既有測試」這種豪賭，現階段我不建議，混用策略（穩定處寫死、易碎處交給 AI）才是能睡好覺的作法。

最後我想補充一個很多人關心的成本問題。

這些工具能不能吃我手上的 Claude Pro 或 ChatGPT Plus 訂閱額度，不要再多付一筆 API 費用？查證的結論是：標準的模型介接吃不到。Anthropic 在 2026 年上半年已明文禁止把 Claude 訂閱的 OAuth token 交給第三方工具直連；官方留的通道是 Claude Agent SDK 這類自家整合介面（寫這篇時仍可使用訂閱額度），但那不是通用的模型 API，Stagehand 的 Anthropic provider 接不上去。

OpenAI 這邊類似，Codex 生態有官方支援的訂閱驗證整合，但同樣限定在 Codex 自家介面，沒辦法當一般 OpenAI API 給 Stagehand 用。所以 Stagehand 和 browser-use 這類要嵌模型的工具，實務上就是乖乖用 API key 計費。唯一的例外正是 Playwright MCP：它自己不帶模型，掛在 Claude Code 底下跑就是走你訂閱的額度，這也是它成本結構上獨一無二的優勢。

好消息是 API 計費真的不貴，我的 demo 跑一整輪 E2E 才 0.002 美元。與其糾結訂閱額度，不如挑一顆便宜的小模型，把「AI 什麼時候該介入」這件事想清楚，這比省下的那點 API 費用值錢多了。

讀到這裡，如果你開始焦慮「那我到底該學 Playwright 還是 Stagehand」，先說結論：不用二選一。Playwright 解決的是「可程式化、可重複的瀏覽器自動化」這個大問題，確定性、速度、零推論成本、跨瀏覽器加上完整的測試框架，都是 Stagehand 給不了的。與其說誰取代誰，更像是互補，知道什麼時候該用哪一邊，比選邊站重要得多。