Notte 評測：把腳本與 AI 代理混在同一條工作流裡的瀏覽器自動化框架

Notte 想解決的是「全 AI 太貴、純腳本太脆」這個夾縫

多數網頁自動化的失敗不是發生在點擊本身，而是發生在頁面結構變了、元素順序換了、彈窗插進來的時候。傳統 Playwright 腳本對這種變動沒有抵抗力，selector 一失效整條流程就斷。另一邊，把整段流程交給 LLM 代理去決策，雖然對變動容忍度高，但每一步都要呼叫模型，成本隨步驟數線性上升，而且模型的判斷本身不保證可重現。

Notte 的定位就在這兩者之間。README 的敘述是「combines AI agents with traditional scripting for maximum efficiency」，並聲稱可以「script deterministic parts and use AI only when needed, cutting costs by 50%+」。那個 50% 是專案自己的說法，沒有附上計算方式，讀者應該當成方向性描述而不是可引用的數字。真正值得注意的是它把這個混合模式做進了同一套 API：同一個 Session 物件底下，你可以用 Playwright 相容的原語做確定性操作，也可以丟一個自然語言 task 給 Agent 去跑。

目標使用者因此相當明確：已經有 Python 自動化基礎、手上有一批需要登入或需要繞過反機器人機制的流程、並且願意為省下的 LLM 呼叫次數付出框架相依性的團隊。如果你的流程只有三步而且頁面三年沒改過，這個框架帶來的複雜度大於收益。

Session 與 Agent 的分工：狀態留在瀏覽器，決策交給模型

從 README 的程式碼可以看出架構的核心切分。notte.Session 負責瀏覽器實例的生命週期，用 with 語句管理，建構時可以指定 headless=False 或 browser_type="chrome"。notte.Agent 則綁定到某個 session，接收 reasoning_model 與 max_steps 兩個關鍵參數，然後用 run(task=...) 執行任務。

這個設計的意思是：瀏覽器狀態（cookies、登入態、當前頁面）活在 Session 裡，模型只負責在既有的頁面狀態上做決策。這是為什麼混合工作流在理論上可行，你先用腳本登入、導航到目標頁面，再把剩下的判斷工作交給 Agent，Agent 接手時看到的是一個已經就緒的瀏覽器，不需要從零開始摸索。

max_steps 是一個硬性預算。README 的範例從 10 到 30 不等，這不是隨意的數字，它直接決定單一任務最多能花多少輪模型呼叫。設得太低，複雜任務會在半途被截斷；設得太高，失控的迴圈會把成本吃光。這個參數沒有預設值可以依賴，必須針對任務自己調。

reasoning_model 採用的是 LiteLLM 風格的字串格式（範例是 gemini/gemini-2.5-flash），代表模型是可換的。這對成本控制是好事，但也意味著任務表現會隨模型選擇浮動，換模型等於換一套行為。

安裝與啟動：兩行指令，但本地與託管是兩條路

安裝本身很直接，README 給的是：

pip install notte patchright install --with-deps chromium

第二行值得注意。Notte 用的是 patchright 而不是標準的 Playwright 瀏覽器安裝，patchright 是 Playwright 的一個修補分支，針對反偵測做過調整。這解釋了為什麼 README 強調 stealth 能力，也意味著你的執行環境需要能安裝 Chromium 與相關系統相依套件（--with-deps 會處理後者）。在容器或 CI 環境裡，這一步通常是部署時第一個出問題的地方。

啟動本地模式需要自備 LLM API key，README 範例用 dotenv 載入：

with notte.Session(headless=False) as session: agent = notte.Agent(session=session, reasoning_model='gemini/gemini-2.5-flash', max_steps=30) response = agent.run(task="doom scroll cat memes on google images")

要走託管路線則換成 notte_sdk 的 NotteClient，需要先在 Notte Console 註冊並取得 NOTTE_API_KEY：

client = NotteClient(api_key=os.getenv("NOTTE_API_KEY")) with client.Session(open_viewer=True) as session: agent = client.Agent(session=session, reasoning_model='gemini/gemini-2.5-flash', max_steps=30)

README 把這個關係描述為「drop-in replace the import and prefix notte objects with cli」。這個說法在範例層級成立，但要注意 open_viewer 這類參數只出現在 SDK 範例中，而 Vault、Persona、CAPTCHA 求解、代理伺服器都列在 API service 那一側。也就是說，兩條路徑的介面相似，功能集合不同，切換時要重新確認你依賴的功能是否還在。

Structured Output 把結果綁進 Pydantic，這是最實用的一塊

run() 接受 response_format 參數，傳入一個 Pydantic 模型，回傳的 response.answer 就會符合該結構。README 的 Hacker News 範例定義了 HackerNewsPost 與 TopPosts 兩層模型，欄位包含 title、url、points、author、comments_count。

這件事的價值在於它把「模型自由發揮的文字」變成「可以往下游系統送的資料」。做過 LLM 抽取的人都知道，最麻煩的從來不是抽取本身，而是抽取結果的欄位型別不穩定。用 Pydantic 宣告 schema 等於在框架層做了一次驗證約束。

但這裡有個沒說清楚的地方。README 沒有交代當模型無法從頁面取得某個欄位時會發生什麼，是回傳 None、拋出驗證錯誤，還是讓模型自行編造一個合理值。對需要資料準確性的流程來說，這個行為差異決定了你要不要在外層再加一層人工覆核。這是採用前應該實測的第一個問題。

Vault 與 Persona：把登入態與身分當成一級物件

Vault 是附加到 Agent 的憑證容器。範例中先用 client.Vault() 開啟，呼叫 add_credentials(url=..., username=..., password=...) 寫入，再把 vault 傳給 Agent。README 的說法是「The agent automatically uses these credentials when needed」，也就是模型會自行判斷何時填入哪組帳密。

這個自動判斷是方便也是風險。把憑證交給模型決策，等於信任模型在正確的網域上使用正確的憑證。README 沒有描述網域綁定的強制機制，add_credentials 帶了 url 參數，但是否嚴格限制只能在该 url 使用，從給的資料看不出來。

Persona 走得更遠，提供「unique email addresses, phone numbers, and automated 2FA handling」，範例用 client.Persona(create_phone_number=False) 建立。這明顯是為帳號註冊類流程設計的。這類功能牽涉到目標網站的使用條款，框架提供能力不等於使用場景合法，這部分要由採用者自己判斷。

Vault 與 Persona 都列在 API service 之下，不在開源核心裡。這是評估時最容易忽略的一點：你在本地跑得起來的版本，並不包含這些功能。

SSPL-1.0 是這份程式碼最需要先讀懂的部分

repo 的 License 欄位顯示 NOASSERTION，但 README 的授權徽章明確標示 SSPL-1.0，並連到 spdx.org 的 SSPL-1.0 頁面。這兩個訊號不一致，實務上應該以 repo 內的 LICENSE 檔案為準，而本文無法確認該檔案的內容。

SSPL 是 MongoDB 主導的授權，它的特徵是：一般使用與修改沒問題，但如果你把這個軟體當成服務提供給第三方，就必須以同等條件開源你整個服務堆疊的原始碼。這對「把 Notte 包成 SaaS 賣出去」的商業模式是實質限制，對「內部流程自動化」則通常不構成問題。

這裡不提供法律意見。要判斷你的用途是否落入 SSPL 的服務化條款，需要的是法務而不是工程判斷。但工程團隊至少該先確認一件事：授權徽章與 GitHub 的 NOASSERTION 標記哪個才反映實際的 LICENSE 檔案，這個落差本身就是採用前該釐清的訊號。

版本節奏方面，近期釋出記錄顯示 v1.8.39 到 v1.8.41 集中在三天內發布，這種密度通常意味著活躍維護，也意味著 API 表面仍在變動。鎖定版本並在升級前讀 release notes 是合理的做法。

與 browser-use 的取徑差異，以及 Notte 不適合的情況

README 的 benchmark 表把 Notte 與 Browser-Use、Convergence 並列，數字是 Notte 86.2% 自評、79.0% LLM 評、47 秒每任務、96.6% 可靠度。這張表由專案自己發布在 open-operator-evals 倉庫，屬於自建評測，數字本身不該當成獨立驗證的結果。但它透露了一個有用的架構差異：時間。47 秒對 113 秒，差距接近兩倍，這與「只把 AI 用在需要的步驟」的設計是一致的，因為減少的模型呼叫輪數會直接反映在牆鐘時間上。

browser-use 的取徑更偏向讓代理主導整個流程，開發者提供任務描述，代理自行決定步驟。這種做法上手快，但每一步都要過模型，成本和延遲都隨任務複雜度上升。Notte 反過來，要求你先想清楚哪些步驟是確定的，把它們寫成腳本，只在真正需要判斷的地方呼叫模型。前者的開發者體驗較好，後者的執行成本較低。選擇取決於你的任務是「一次性的探索」還是「每天跑一萬次」。

Notte 明顯不適合的情況有三種。第一，你的流程完全不需要登入、不需要繞過反機器人機制、頁面結構穩定，那直接用 Playwright 就好，多一層框架只增加相依性。第二，你需要寬鬆授權的開源元件，SSPL-1.0 會擋住某些商業模式。第三，你的團隊沒有能力管理 LLM API key 與 token 預算，max_steps 這種參數在無人監督的情況下很容易失控。

還有一個 README 沒有回答的問題：當 Agent 在 run() 中途失敗時，Session 的狀態是什麼。瀏覽器是留在當前頁面、被關閉，還是回到起始狀態？這決定了你能不能做重試，以及重試時要不要重建整個 Session。這是採用前必須自己實測的行為。

編輯結論

Notte 適合已經在用 Python 寫爬取或流程自動化、想把 AI 只用在真正需要的步驟上的團隊，尤其是需要登入態、2FA 或反偵測瀏覽器而不想自己維運瀏覽器叢集的場景。若你要求寬鬆的開源授權、或想把整套流程完全交給模型自行決策，Notte 不是合適的選擇，前者要面對 SSPL-1.0，後者會直接放大它的成本與不確定性。採用前先確認三件事：一是你的用途是否落在 SSPL-1.0 的服務化條款內，二是 reasoning_model 與 max_steps 這兩個參數在你自己的任務上會產生多少 token 消耗，三是本地 Session 與 NotteClient 託管 Session 在你需要的功能上是否真的可以互換，README 只說可以 drop-in 替換，但 premium 功能顯然只存在於後者。

官方來源

1. Issues
2. nottelabs/notte on GitHub
3. Project website
4. README
5. Releases