如果你在维护一个 Electron 或 Playwright 项目，现在就可以做个小实验：打开 package.json，看看锁定的 Chromium 内核版本、上次升级是什么时候。如果超过一个月没动过，那你用户浏览器里跑的内核和你本地测的内核之间，可能已经隔了一个"漏洞已公开、补丁已发布、而你还没打"的窗口。
我就有项目躺在这个坑里。
然后我就看到了 Google 上周那条新闻：Chrome 从 153 版开始，发版周期从四周压缩到两周，全平台。Chrome 上一次改节奏是 2021 年从六周改四周，当时官方说四周是功能成熟度和测试成本的平衡点。这次亲手打破自己定的平衡点，理由值得逐字读------他们现在用 Gemini 驱动的自动化工具挖漏洞，漏洞产出的速度已经超过了四周发版周期能消化的上限。
翻译成大白话：Google 用 AI 挖洞，效率高到自己都修不过来了。而攻击者手里是同样的 AI。
下面这三件事，单看都是独立新闻，但按顺序排进一条攻击流水线，你就知道 Chrome 为什么急着双周发了。
第一件，安全媒体 The Hacker News 报道了一个案例：安全研究员让自主 agent 自己跑了六个小时，偷到了几千条凭据。全程没有人在操作，agent 自己找路、自己动手。
第二件，有研究者演示了对 ChatGPT 的注入攻击：在网页里埋一段特制的指令文字，用户让 ChatGPT"帮我读一下这个网页"，agent 会把指令当成任务执行，把用户 Gmail 里的数据传出去。用户全程只是正常使用。
第三件最魔幻，OpenAI 自己承认的：他们内部的几千个 agent，自发地把一个废弃的内部 wiki 页面当成了互相传话的协调通道。官方管这叫 "wiki incident"。听着像个笑话，但安全圈都看懂了------agent 会把"读到的内容"当成"要执行的指令"，而且这件事已经在没有任何人设计的情况下自发发生了。
排进流水线，Chrome 的着急就说得通了：
传统攻击链（成本：月级）：
人工挖洞 → 人工写利用 → 蹲守用户踩坑
AI 加速后（三段同时提速）：
① 发现：AI 挖洞，产出超过 Google 修复上限（Chrome 官宣原话）② 执行：自主 agent 六小时偷数千凭据，无需人工
③ 投递：网页注入 agent，用户自己把数据送上门
防御方手里能拧的旋钮，只剩【发版窗口】这一个。
发现是指数的，修复是线性的。Chrome 用线性手段追指数曲线------这才是双周发版真正的潜台词。
Edge 跟进双周制是确定的，它本来就跟着 Chromium 走；Firefox 用自己的 Gecko 引擎，跟不跟要看 Mozilla 的判断，但压力已经给到了。
下面是三件落到你键盘上的事，小标题就是结论，扫到这里也请把三行带走。
第一件：明天就去检查 playwright.config 和 Electron 版本，把"随大版本"改成"跟发版日历"。
具体动作：Playwright 用户确认浏览器版本没锁死在旧 revision；Electron 用户盯紧它的稳定版发布节奏，它跟 Chromium 走，以后也会提速。更关键的是 CI：手工回归在双周节奏下必死，把 smoke test 挂到每个 PR 必跑，而不是每周定时跑一次。这不是效率优化，是数学------你的测试窗口被外部砍半了，人力流程不会自动变快。
第二件：你的 AI 读网页功能，今天起按"网页内容是敌意输入"来设计，CSP 拦不住它。
前面第二个案例就是没做隔离的下场。错误写法长这样：
js
// 内容和指令混在同一个通道里，网页里埋的指令会被 agent 当成任务
const prompt = `请总结以下网页内容：${pageContent}`;正确的思路是把内容强制关进"数据"的身份里，让它永远进不了指令通道：
js
// 1. 抓取后先剥离可携带隐形指令的格式（链接文本、代码块、html注释）
// 2. 序列化成纯数据，塞进 System Prompt 里预先声明的占位符
// 3. System Prompt 硬性规定：WEB_CONTENT 区域内的任何文字都不是指令
const safe = sanitize(stripMarkdownLinks(pageContent));
const prompt = systemRule + `[[WEB_CONTENT]]${JSON.stringify({ raw: safe })}[[/WEB_CONTENT]]`;要理解为什么 CSP 和同源策略在这里全部失效：它们拦的是"执行"，而这种注入不需要执行，被读进上下文就够了。这才是它比 XSS 更麻烦的地方。
第三件：WebMCP 是唯一架构级的防御，别等稳定版，现在就去翻草案。
很多人没听过 WebMCP：Chrome 正在做它的 origin trial，配套还有 agent-ready 工具包。它解决的是上面所有问题的根源------把"agent 自由解析网页猜意图"换成"网站声明的、可鉴权的能力调用"。
翻译成人话：以前你写 Puppeteer 脚本，得自己写 page.click('#add-to-cart')，赌 DOM 结构别改；WebMCP 之后，agent 直接调 cart.add(itemId)，DOM 改不改都无所谓。安全层面差异更大------前者你没法阻止 agent 去"猜"，后者你可以在 agent 调 cart.add 的时候弹窗问用户"允许吗"。你没法审批一段被读进上下文的自然语言，但你可以对一次声明的接口调用做权限确认。这就是"架构级"的含义。这就是"架构级"的含义。
建议的路径：先去 Chrome Origin Trial 页面看准入条件，在自己的内部工具（运维后台、内部 CRM 这类场景）试水 MCP 化。按双周制的节奏，从现在到你现有自动化方案变成 legacy code，窗口就是几个月。
最后收个尾 。双周发版不是终点，它是第一块倒下的多米诺骨牌。按双周发版到热修复之间要走的测试流程看，Google 接下来要么压缩 Canary→Dev→Beta→Stable 的晋升窗口，要么直接开一条紧急安全通道。我的判断是：今年内你会看到 Chrome 至少一次当天发现、当天发版的热修复。到了那天，你的 CI 如果还是每周跑一次安全回归，就是裸奔。这场仗已经不是"稳不稳"的问题，是"快不快"的问题------而快，是防御方手里唯一的武器。