chrome 操作的是你自己那个已经登录了各种账号的 Chrome，不是沙盒里的一次性浏览器。这是它的全部价值，也是它需要一整套确认策略的原因。
激活条件
profy-chrome 是 user_selectable: true 且 requires: { chrome_connected: true }。需要在插件面板勾选，且 Chrome 扩展在线。路由：目前只有桌面端一条路能走
manifest 里声明了扩展的本地 MCP Server（ws://localhost:19532/mcp），设计上是两条路由：桌面端 sidecar 优先，直连 WebSocket 兜底。
标签页生命周期
claim_tab 才能操作。跳过认领直接 navigate 是无效的——认领是「专家现在接管这个标签页」的显式信号，也是你在浏览器里能看到发生了什么的依据。
13 个 action
type 与 fill 的取舍：需要触发页面 JS 的输入监听（搜索联想、实时校验、字数统计）用 type；只是要把值放进去用 fill。
browser_auth 的 auth_action 三选一：get_credentials / store_credentials / clear_session。
四级确认策略
因为操作的是你的真实登录态，写操作按敏感度分四级：
这套分级同时写在工具的 docstring（约束模型）和扩展的权限门（约束执行）里。模型即使想跳过确认，扩展侧也拦得住——分级的执行点在扩展，不在提示词。
工作流复用（AT2T）
重复性的浏览器任务可以固化成模板，之后零 LLM 成本重放。三个配套工具：
推荐节奏：先 match → 命中就 execute（零 LLM）→ 没命中就正常操作 → 完事 save。第二次做同一件事就快很多。
模板存在扩展的 IndexedDB 里，属于你的浏览器本地数据。
失败与对策
与 browser / computer 的分工
要点很简单：需要你登录态的用
chrome，公开内容用 browser。browser 跑在沙盒里，不占用你的浏览器，也不会让专家看到你的账号。
继续阅读
Browser
沙盒内的隔离浏览器
Computer Use
桌面级操控
录制与回放
另一条把操作固化下来的路
插件全表
28 个内置插件与激活条件