Chrome DevTools MCP：接入你已有的调试现场
chrome-devtools-mcp-skill 的思路很直接：不另起浏览器，而是让 Agent 通过 Chrome 的 remote debugging 协议，直接接进你当前已经打开的 Chrome 会话。
这意味着 Agent 可以：
- 查看 Network / Console / Elements 面板信息
- 分析页面性能问题
- 复用你当前的登录态和浏览上下文
实际使用场景是这样的——你在浏览器里已经打开了页面、登录了账号，想让 AI 帮你看看某个接口为什么慢、DOM 结构哪里有问题。Agent 不需要重新跑一遍登录流程，直接进入你的当前上下文开始工作。
这个 Skill 安装后会自动创建对应的 link 命令，后续 Claude Code 或 Codex 可以通过这个命令直接接入浏览器。
Playwright MCP：自动化场景的登录态复用
playwright-mcp-skill 面向的是更确定性的浏览器自动化任务：打开页面、点击元素、抓取 DOM snapshot、截图、跑脚本。
但 Playwright 有一个老问题始终没被优雅解决：
- head 模式（有界面）会干扰桌面操作
- headless 模式又很难完成需要真实交互的登录流程
playwright-mcp-skill 给出的方案是把登录和执行拆成两步：
- 先用有界面的浏览器会话（
playwright-mcp-ui）完成登录 - 登录态保存在明确的 profile 目录中
- Agent 实际干活时切到 headless 模式（
playwright-mcp-cli），复用同一个 profile
两个模式共享 profile，互不干扰。对于把 OpenClaw 部署到服务器的场景，这条路也走得通：本地完成登录，把 browser profile 带到服务器，远端 Agent 用 headless 模式复用已登录的 profile。
UXC 在这里补的是哪一层
这两个 Skill 能顺畅工作，关键不完全在 Skill 本身，而在 UXC 把 MCP stdio 工具封装成了一层统一的调用接口。它做的几件事：
- 用
uxc link把冗长的启动命令固化成稳定入口 - 用 daemon 维持会话和进程生命周期
- 让 profile 和 session 的复用变得自然
- 让 Skill 可以围绕固定命令名组织，而不是每次手写一串参数
这其实是目前 Agent 工具链里一个被低估的层——不是模型能力的问题，也不是 MCP 协议本身的问题，而是"怎么让 Agent 稳定、可复用地调起一个外部工具"这件事，一直缺一个干净的中间层。UXC 正在填这个位置。
值得试的方向
如果你正在搭建需要浏览器交互能力的 Agent 工作流，这两个 Skill 值得作为起点。尤其是登录态复用的思路——这不只是技术细节，而是决定了 Agent 能不能真正替代你完成需要身份认证的操作。目前这个方向还处于工具层竞争的早期阶段，谁能把"Agent 接入真实浏览器上下文"这件事做到足够顺滑，谁就可能成为 Agent 生态里的基础设施。