那次调试卡在一个很干脆的 401。
我从已登录的 Chrome 里复制 Cookie，交给普通 HTTP 客户端。浏览器明明能访问，脚本拿着“同一张门票”却被保安拦下。再复制几遍也没用，像把门票复印成彩色：看起来更努力，保安还是不放行。
最后，我用 CDP 连接原来的浏览器，在已登录页面里直接执行 fetch，请求通过了。
Cookie 不等于完整会话
CDP，全称 Chrome DevTools Protocol，是 Chrome 的调试与控制协议。程序可以用它执行页面脚本、观察网络请求、读取页面状态，也可以点击和输入。
它通常通过 WebSocket 建立持续连接，Runtime、Network、Page 等域分别负责执行脚本、监听请求和导航页面。和只凭截图猜按钮不同，CDP 能直接读到浏览器内部发生了什么。
那次 401 的关键在于，能被站点接受的会话不只有 Cookie。浏览器里还有页面脚本生成的动态参数、本地登录状态和安全上下文，有些凭证也会和当前环境绑定。普通客户端只抄走几行文本，CDP 则让请求回到了站点已经认可的浏览器上下文。
我也在这时意识到：浏览器不只是页面容器，更像一张数字工牌。 Cookie 只是这次门禁检查的一部分；完整会话才代表“谁正在操作”。CDP 把这张工牌对应的行动权也给了 AI，鼠标操作仅是表层交互。
行动之后，还要回读结果
后来做本地前端验收时，代码还没发布，却要放进真实域名、真实数据和 SSO 登录环境中验证。我让代理只把改动相关的资源导向本地，其余请求仍走生产服务；测试运行在专用 profile（独立用户目录）的隔离 Chrome 中，再用 CDP 操作并回读 URL、标题、关键元素和截图。
这等于在没有发版前，先做一次带身份的生产环境彩排。
这比“点完了”重要。Agent 能行动，也能拿结果证明自己没点错。
一次动作是否成功，也不能只看接口返回 200：页面可能仍在轮询、弹出确认框，或者被前端回滚。CDP 的价值，是让动作和证据留在同一个会话里。
但 CDP 也有边界。一次整理发布回退周报，我要确认某次活动是否曾被监控短暂阻断。CDP 顺利通过 SSO，接口也正常返回，可活动结束后，短暂的中断态早已被“已关闭”覆盖。
CDP 能过门禁，不能穿越时间。 要保留瞬时状态，必须在事件发生时实时监听和落盘。
从那以后，我总先问：正式 API 能不能做？能，就不碰 CDP。非用不可时，我会新开专用 profile，把调试端口留在本机，只交给可信 agent。写入前先 dry-run，结束后再从业务页面读回结果。流程会麻烦一些，但总比身份失控后再补救便宜。
所以今天再看 CDP，我首先想到的是“授权”：该浏览器中登录着谁，它就能以谁的身份行动。把协议交给 agent 之前，应先确认这项授权是否也交出了对应的网页身份。
