agent browser 和 playwright-cli 区别？
agent-browser 和 Playwright CLI 的区别不在"谁更好"，而在谁在做决策——是 LLM 自己看着办，还是人写好每一步指令。
- agent-browser 目标驱动：给自然语言目标，LLM 自己规划并执行
- Playwright CLI 步骤驱动：open → click → fill，每一步都得人写清楚
- agent-browser 用 Accessibility Tree + @ref，Token 仅为完整 DOM 的 5%
- Playwright CLI 交互结果写磁盘，Agent 按需读，Token 比 MCP 方案省更多
- agent-browser 直连 CDP 复用登录会话；Playwright CLI 默认隔离上下文
- 容错逻辑相反：agent-browser LLM 语义兜底，Playwright CLI ref 变就挂
- 两条路都能走，走反了就是纯烧 Token
agent-browser 和 Playwright CLI 经常被放在一起比——都能让 AI 操作浏览器，都能省 Token。但它们的思路完全相反。
agent-browser 把 Agent 当"用户"：你给目标，它自己看页面、自己做决策、自己执行。Playwright CLI 把 Agent 当"写脚本的人"：每一步指令你写，它执行，结果存磁盘。
说白了，一个信 LLM 的判断力，一个信人的控制力。
agent-browser：LLM 是司机
agent-browser 的核心循环极简：
agent-browser snapshot -i 只返回可交互元素，长这样：
- button "Sign In" [ref=e1]
- textbox "Email" [ref=e2]
不是完整 DOM，没有 <div> 嵌套，没有样式信息。只有"这页面能点哪里、填哪里"。Token 仅为原始 HTML 的 5%。
然后 agent-browser click @e1 → ✓ Done（6 个字符）。交互确认极其廉价，每步只传当前可交互元素列表加一个操作结果。
但这套方案的前提是 LLM 足够聪明。页面结构变了、按钮文字改了、布局调整了——LLM 通过语义理解重新定位，不需要你改脚本。代价是 LLM 必须参与每一步决策，Token 随着任务步骤线性增长。
Playwright CLI：人写剧本，它省钱
Playwright CLI 做的不是"让 AI 更聪明"，而是把页面快照从对话上下文里踢出去。
常规 Playwright MCP 的问题是：每次工具调用，返回整个页面 Accessibility Tree 快照，几万字符。Agent 对话上下文的大头全被它吃了。
Playwright CLI 的解法很粗暴：快照不再塞进对话，改成存磁盘文件。Agent 只有在需要检查页面状态时才 read 文件，读完继续写下一步指令。Token 消耗降 4 倍左右。
代价也明显：Agent 不再"理解"页面状态（大部分时候它根本不看），只是在逐条执行预设脚本。控制力换 Token 效率。
Token 谁更省？取决于任务
| 维度 | agent-browser | Playwright CLI |
|---|---|---|
| LLM 角色 | 决策者 + 执行者 | 脚本执行者 |
| 每次交互 Token | ~200-400 | ~100-200（磁盘模式） |
| 容错机制 | LLM 语义理解，元素变了也能找 | ref 不变才不出错 |
| 控制粒度 | 目标级（粗） | 步骤级（细） |
如果任务是"去 GitHub 搜某项目的 star 数"，agent-browser 一条指令搞定，LLM 自己翻页。Playwright CLI 你得写完整流程：open → snapshot → fill search-box → click search-btn → snapshot → extract。每步都在烧 Token，加起来未必比 agent-browser 省。
反过来，CI 里每天跑 50 次同一个表单提交流程——Playwright CLI 完胜。步骤固定、页面不变，每次只花极少量 Token 确认结果。
被忽视的差异：会话管理
agent-browser 支持 --cdp 9222 直连 Chrome DevTools 端口。
这意味着它能复用你已经登录的浏览器。 Cookie、localStorage、OAuth 登录态全在。访问自己的 GitHub Settings 直接进，不需要填密码。
Playwright CLI 默认创建隔离上下文（类 Incognito），看不到已登录会话。虽然 --profile 和 state-save 能持久化，但得额外配。
这就是为什么 agent-browser 更适合"日常辅助"——帮你在内部系统填表、查数据、走审批流。复用现有会话才是常态，不是特例。
怎么选
让 Agent 自己探索网页 → agent-browser数据采集、多步业务流程、需要适应页面变化的任务。LLM 做决策比人手动枚举所有分支靠谱得多。
流程固定、需要确定性 → Playwright CLICI 里的 E2E 测试、固定表单提交、已知页面的数据提取。能写清楚每一步就别让 LLM 猜。
两个都装也不冲突。记住一个原则：别用 agent-browser 跑确定性测试，也别用 Playwright CLI 探索动态网站——工具选反了，Token 白烧。