小白爱摸鱼
@chaozuoye
浏览器 agent 未必需要视觉模型——微软的 Playwright MCP 直接拿 Accessibility Tree（辅助功能树）当结构化数据喂给模型，而不是每步截图再让视觉模型猜。
核心能力清单很全：开关页面、点按输入滚动、多标签管理、读 Console 与网络请求、操作 Cookie／localStorage、Mock API、保持登录、录制 Trace 与视频、生成 locator、做元素与文本断言——视觉只在必要时才开，用坐标兜底。
"结构化树替代截图"这个选择，是今晚"结构优于猜测"的又一个落点。截图是给眼睛的，辅助树是给逻辑的——同样一屏内容，前者要模型再解码一次，后者直接是层级化的数据：该省的解码，不该每次都付；这与省前缀、剪假依赖是同一条纪律在感知层的应用。能用结构化表达的，就别让模型用像素猜——这句话几乎可以贴在所有 agent 工具的墙上。
更值得记的是 README 里的一个反向建议：微软现在反而推荐 coding agent 优先用 Playwright CLI＋Skills，而不是 MCP。理由也直接——MCP 要把大量 Tool Schema 与整棵辅助树塞进上下文，token 成本更高；CLI＋Skills 调用更短，适合"一边读大型代码库、一边跑浏览器测试"的 Coding Agent。
MCP 则留给另一类场景：需要保持浏览器状态、持续观察页面结构、自愈测试、长时间自主执行的 agent。同一家官方，给同一个能力发了两张入场券——按 token 账本分配形态，这与今晚档位分流、effort 按任务给是同一个思路从模型层走到了工具层。
这也把"选 MCP 还是选 CLI"翻译成了一道可计算的题：你的 agent 是"持续在场"还是"偶尔伸手"？持续在场（盯页面、长任务、自愈），状态留着划算，MCP 值那个 token；偶尔伸手（跑个断言、点个流程），调完即走的 CLI 显然更便宜。
形态跟着调用模式走，而不是跟着技术时髦走——能被官方写进 README 的这种取舍，通常都是被账单教育过的结果。
对今晚一路的 Skill 叙事，这条是块新拼图：从"说明书变成给 agent 读的接口"到"库自带 skill"、再到"官方劝你用 CLI＋Skills"，方向已经很清楚——工具正在从"被调用的服务"退成"可内联的片段"；能塞进一次短调用的，就不做成常驻连接。什么时候该常驻、什么时候该一次性，就是这份 README 悄悄出的一道选择题。
给要接浏览器自动化的人一句落地的：先按调用模式选形态——大多数团队的起点其实应该是 CLI＋Skills（便宜、够用）；等你的 agent 真长出"连续盯页面"的需求，再补 MCP；两者并存不冲突，微软自己就是这么摆的。选完再做一次 token 对照：同一个任务各跑一遍看上下文涨幅，账单一摊，答案不言自明。
