呢篇係 LangChain 發布嘅工程寫法（vendor engineering write-up），講佢哋點樣為 Managed Deep Agents 揀同調好（tune）瀏覽器操作工具。呢度先交代清楚：呢個係廠商描述自己做法嘅文章，唔係本站獨立實測，文中數字全部係廠商自報。
佢哋做咗乜
LangChain 話，為 Managed Deep Agents（喺 LangSmith 上面構建同部署 agent、唔使自己跑基礎設施嘅服務）喺七套瀏覽器工具入面比較，最後揀咗 Browserbase 嘅 Stagehand。揀完之後，佢哋根據 LangSmith 追蹤（traces，即 agent 執行時嘅逐步驟記錄）入面看到 agent 喺邊度浪費步數或 token，就逐個改工具，每次改動都用 evals（evaluations，自動化評估測試）先確認改動有幫助先收貨。
瀏覽器操作點解會係個大問題
Agent 要做 browser use，主要用喺兩類嘢：API 覆蓋唔到嘅操作（例如用 agent 未預設過的網站），同為 coding agent 建嘅 web app 做端到端測試。佢哋指出瀏覽器操作有兩個特別嘅 context management 挑戰：
- 任務長、串行調用多。用 Playwright MCP，一個 WebVoyager 任務平均 26 個 model turn。
- 網頁內容多，但通常只有一小部分同任務有關。經 Browserbase hosted MCP server 嘅一次 navigation，中位數約 17,000 字元。
呢兩個都係工具要 efficient 管理 context 嘅壓力。
測試方法
用嘅係 agent development lifecycle：跑 benchmark → 讀 LangSmith traces → 改工具 → 跑 evals。佢哋用咗三個跑喺 live website 嘅基準：
- WebVoyager：100 個日常任務（Allrecipes、Amazon、Google Flights 等），用 Claude Sonnet 5.5 跑，Jev judge 評分。佢哋話呢個 benchmark 已經「fairly saturated」，所以適合做 context use、cost、speed 嘅乾淨比較。
- HardBench：Browserbase 提供嘅 102 個較難任務，由佢哋自己嘅 verifier 評分，主要用 Claude Opus 5.5 跑。
- WebTailBench：Microsoft 嘅真實「長尾」任務，每個對一個短 rubric 打分；佢哋跑咗 150 個。
（註：原文喺「We ran 150 of them through the Stageha…」處截斷，冇完整寫晒 Stagehand 喺 WebTailBench 上嘅表現，呢度只交代跑咗 150 個，唔加多餘結論。）
呢個同讀者有乜關係
呢篇對做 AI agent 或者想將 agent 接入手頭工作流程嘅讀者有參考價值：廠商講明用咗乜測試框架、邊個 judge、邊個 benchmark，呢個做法本身就係透明示範。但同時要問：呢啲 benchmark 係廠商自己選、自己跑、自己評分，冇第三方獨立重現。
阿調搞兩下：工具設計真係決定 agent 表現嘅一大因素，呢個結論冇問題。但「Stagehand 係最好嘅」呢個話係廠商自己講、自己揀、自己評，唔好當係獨立結論。
阿調｜深度調教
