浏览器扩展这个赛道这两年肉眼可见地卷了起来。以前大家装扩展无非是广告拦截、密码管理、截图标注这几样工具属性极强用完即走。但最近半年一个明显的变化是越来越多的扩展开始往常驻助手的方向走——不是等你点开才工作而是安静地待在每一个标签页里在你需要的时候恰好出现。EO2Weave 上架 Chrome 应用商店这件事在我看来就是这条路线上的一个典型样本。它主打的是把 AI 助手能力织进浏览器的日常动线里关键词里出现的 Codex OAuth 和 WebMCP 两个词基本暴露了它的技术底牌一个负责身份与授权打通一个负责让网页本身变成可被调用的能力接口。这篇内容我打算从扩展的定位、授权链路、WebMCP 的落地方式、上架前后的实操细节几个角度把这类住进标签页的扩展拆开讲清楚适合正在做浏览器扩展的开发者、想理解 AI 助手如何嵌入浏览器工作流的产品同学以及单纯好奇这类工具怎么跑起来的普通用户。1. 为什么住进标签页是个值得认真对待的产品判断1.1 从工具调用到环境感知的转变传统扩展的交互模型是用户发起—扩展响应。你点图标弹窗出来操作完关掉。这个模型的问题在于它把扩展放在了一个被动的位置用户必须记得它的存在必须主动去调用。而住进标签页的思路完全不同扩展在后台持续感知当前页面的状态理解你正在做什么然后在合适的时机把能力递上来。这个转变背后有一个很实际的观察——人在浏览器里的工作流是高度碎片化的。你可能在查文档、填表单、对比价格、读论文、写邮件之间反复横跳每一次切换都伴随着上下文的丢失。如果 AI 助手只能在某个独立窗口里等你提问那它和搜索引擎的区别其实不大。但如果它能跟着你的标签页走知道你当前在看什么、选了什么、填到哪一步了那它提供的就不是问答而是接力。EO2Weave 这个名字里的 Weave编织其实挺传神。它不是要做一个大而全的入口而是把能力像线一样织进你已有的浏览行为里。这个定位决定了它的技术架构必须是轻量、常驻、低打扰的也决定了它必须解决一个核心问题怎么在不侵犯隐私的前提下让扩展看懂当前页面。1.2 常驻型扩展的三个硬门槛说起来容易做起来难。一个想常驻在每个标签页里的扩展至少要跨过三道坎。第一道是性能坎。Chrome 对扩展的资源占用是有隐性容忍度的如果你的 content script 在每个页面都跑重逻辑用户很快就会感觉到卡顿然后毫不犹豫地禁用你。所以常驻型扩展的核心计算必须尽量放在 background service worker 里content script 只做最轻量的感知和注入。第二道是权限坎。你想看懂页面就得申请相应的 host permissions但权限申请得越宽用户安装时的犹豫就越重。Chrome 应用商店对权限的描述审核也越来越严笼统地写读取和更改您在所有网站上的数据基本等于劝退。合理的做法是按需申请或者用 activeTab 这类临时权限配合用户手势触发。第三道是上下文坎。标签页之间是隔离的扩展要跨标签页维持一个连贯的助手状态就得自己设计状态同步机制。这里涉及 storage、message passing、以及 service worker 生命周期管理的一堆细节稍不注意就会出现助手失忆的情况。EO2Weave 能上架说明这三道坎它至少给出了可用的答案。下面我会结合 Codex OAuth 和 WebMCP 这两个关键词把它的实现思路拆开讲。2. Codex OAuth 在扩展里到底解决了什么问题2.1 扩展做身份授权的天然困境浏览器扩展做用户身份一直是个麻烦事。你没有自己的域名回调页没有传统的服务端 session 可以依赖弹出式授权窗口又容易被拦截。更关键的是AI 类扩展通常需要调用后端模型服务这就意味着必须有一个可靠的身份凭证来计费、限流、区分用户。常见的做法有两种一种是自己搭一套账号体系用户注册登录扩展存 token另一种是接第三方 OAuth。前者开发成本高用户还要多记一套密码后者体验好但回调地址的处理在扩展环境里很别扭。Codex OAuth 这个关键词指向的应该是一套基于 OAuth 流程的授权方案专门为扩展这类无固定回调域的场景做了适配。它的核心思路通常是扩展发起授权请求跳转到授权页用户确认后授权方通过一个约定的机制把凭证回传给扩展而不是依赖传统的 redirect_uri。2.2 授权链路的关键节点与踩坑点如果你正在做类似的集成这条链路上有几个节点特别容易出问题。第一个节点是授权窗口的打开方式。在扩展里你不能直接用 window.open 去开授权页因为很多授权方会检测窗口来源。更稳的做法是用 chrome.identity.launchWebAuthFlow它专门为扩展设计能拿到最终的跳转 URL从中解析出授权码或 token。这个 API 在 MV3 里的行为和 MV2 有差异需要确认你的 manifest 版本和权限配置。第二个节点是 token 的存储。拿到 token 之后存哪里是个学问。chrome.storage.local 是明文存储chrome.storage.session 在 MV3 里是内存级、浏览器关闭即清空。对于长期凭证通常需要配合服务端的 refresh token 机制扩展本地只存短期 access token。这里有个实操经验不要把 refresh token 放在扩展里一旦扩展被逆向等于把长期钥匙交出去了。第三个节点是 token 过期后的静默刷新。用户不会容忍每次打开扩展都重新授权。你需要在 background service worker 里维护一个刷新逻辑在 token 临近过期时自动用 refresh token 换新的。但 MV3 的 service worker 会被浏览器随时挂起所以刷新逻辑不能依赖内存状态必须每次从 storage 读取当前 token 状态再判断。提示MV3 的 service worker 生命周期是这类扩展最大的坑之一。任何依赖常驻内存变量的设计都会在 service worker 被回收后失效所有状态必须持久化到 storage。2.3 为什么选 OAuth 而不是自建账号从产品角度看选 Codex OAuth 这类方案本质是在用授权方的账号体系换自己的开发成本和用户信任成本。用户不需要为新扩展再注册一次授权页上能看到明确的权限范围心理门槛低很多。对开发者来说计费和限流可以挂在授权方的体系上省掉一整套账号后端。代价是依赖。授权方的接口变更、政策调整、服务可用性都会直接影响你的扩展。所以合理的架构是OAuth 只负责身份和凭证核心业务逻辑尽量与授权方解耦这样即使将来换授权方案迁移成本也可控。3. WebMCP让网页变成可被调用的能力接口3.1 WebMCP 想解决的核心矛盾WebMCP 这个词拆开看MCP 通常指 Model Context Protocol 这类让模型与外部能力对接的协议思路加上 Web 前缀指向的应该是让网页本身成为模型可调用的上下文来源。这里有一个长期存在的矛盾AI 助手想帮你操作网页但它看不见网页的结构化语义。它拿到的是 DOM 树、是 HTML 字符串里面混杂着样式、脚本、广告、无关内容。让模型直接读原始 DOM既慢又不准还容易触发注入风险。WebMCP 的思路是在网页和模型之间加一层语义抽象。网页通过某种约定把自己的关键能力比如这个页面有一个搜索框这个列表可以被筛选这个按钮会提交表单暴露成结构化的描述模型通过这层描述来理解和操作页面而不是硬啃 DOM。3.2 扩展如何充当这层抽象的载体浏览器扩展恰好是承载这层抽象的天然位置。它既能注入 content script 去读取和标注页面又能在 background 里和模型服务通信还能通过 message passing 在两者之间传递结构化数据。具体到实现通常有这么几步。扩展的 content script 在页面加载后扫描页面中的关键交互元素按照 WebMCP 约定的格式生成一份能力清单。这份清单不是原始 DOM而是提炼后的语义描述比如每个可交互元素的角色、标签、当前状态、可执行的动作。然后这份清单被送到 background再由 background 转发给模型侧。模型决定要执行某个动作时指令沿着反方向传回 content script由它去实际触发页面上的元素。这个链路听起来简单但实操中有几个细节决定成败。一是元素定位的稳定性你不能依赖易变的 CSS 类名最好用语义角色加文本内容组合定位。二是动作执行的时序很多页面是异步渲染的元素出现有延迟需要配合 MutationObserver 做等待。三是权限边界哪些页面允许被操作、哪些动作需要用户二次确认必须在扩展层面设好闸门。3.3 一个容易被忽略的安全考量让 AI 操作网页风险是实打实的。如果扩展能自动点击、自动填表、自动提交那它被滥用或出错的后果可能很严重。所以 WebMCP 这类方案在落地时通常会设计几层防护。一层是动作分级。读取类动作比如提取页面文本可以自动执行写入类动作比如填表单需要用户确认提交类动作比如点击支付必须显式授权。另一层是域名白名单扩展只在用户明确信任的站点上启用操作能力。还有一层是操作日志每一步动作都记录下来出问题时可追溯。注意任何让模型直接操作页面的设计都必须假设模型会犯错。防护机制不是可选项是必选项。4. 从开发到上架Chrome 应用商店的实操细节4.1 上架前的自查清单Chrome 应用商店的审核这几年越来越细尤其是涉及 AI 能力和页面操作的扩展审核员会重点看你的权限申请是否合理、隐私政策是否清晰、数据处理是否透明。上架前建议对照下面这张表逐项过一遍。检查项常见问题建议做法权限申请申请了过宽的 host permissions用 activeTab 或按需申请manifest 里写清用途隐私政策缺失或过于笼统明确说明收集哪些数据、如何使用、是否上传远程代码从远端加载并执行脚本MV3 禁止远程代码所有逻辑必须打包在扩展内单一用途功能过于庞杂扩展描述聚焦一个核心用途避免万能工具定位截图与描述与实际功能不符截图展示真实界面描述不夸大4.2 MV3 迁移中的典型报错与处理如果你是从 MV2 迁过来的大概率会遇到几个经典报错。background page 变成 service worker 后原本用 window、document 的代码会直接报错因为 service worker 里没有这些全局对象。解决办法是把涉及 DOM 的逻辑全部挪到 content script 或 offscreen document 里。另一个高频问题是持久化连接。MV2 里可以用长连接 port 维持 background 和 content script 的通信MV3 里 service worker 被挂起后连接会断。稳妥的做法是改用一次性消息加事件驱动每次通信都重新建立不要假设连接一直活着。还有一个是定时任务。setInterval 在 service worker 里不可靠因为 worker 随时可能被回收。需要定时执行的逻辑应该用 chrome.alarms API它由浏览器统一调度不受 worker 生命周期影响。4.3 审核被拒后的应对思路被拒不可怕可怕的是不知道为什么被拒。Chrome 的拒审通知通常会给出一个笼统的理由比如权限使用不当或功能描述不清。这时候不要盲目改一版重新提交而是先定位问题。我的经验是先检查权限列表把每一个权限和实际使用场景对应起来用不上的坚决删掉。然后检查隐私政策确保它明确提到了扩展会接触哪些数据。最后检查功能描述确保它和实际行为一致没有夸大或模糊。改完之后在提交说明里简要解释你做了哪些调整审核员是看得到的。5. 常驻型扩展的状态管理与性能优化5.1 跨标签页的状态同步怎么做才稳常驻型扩展最核心的技术挑战是让助手在多个标签页之间保持连贯。用户在 A 标签页问了一半的问题切到 B 标签页继续助手得记得上下文。这背后需要一套状态同步机制。基础方案是用 chrome.storage 作为唯一数据源所有标签页的 content script 都从 storage 读写状态配合 chrome.storage.onChanged 监听变化。这样任何一个标签页更新了状态其他标签页都能感知到。但要注意storage 的写入是异步的高频写入会有性能问题需要做节流和批量合并。进阶方案是在 background 里维护一个逻辑上的会话状态content script 只负责上报当前页面的局部信息全局状态由 background 统一管理。这样职责更清晰但 background 被挂起时状态会丢所以关键状态还是要落 storage。5.2 减少对页面性能的影响用户对扩展的性能容忍度很低。一个常驻扩展如果让页面加载慢了几百毫秒或者滚动时掉帧用户会直接卸载。所以性能优化是常驻型扩展的必修课。几个实操要点。content script 的注入时机尽量用 document_idle避免阻塞页面渲染。页面扫描逻辑要做防抖不要在 DOM 每次变动时都全量重扫而是用 MutationObserver 监听关键区域。和 background 的通信要合并不要每个小动作都发一条消息攒一批再发。重计算逻辑尽量放到 background 或 offscreen document别在主线程上跑。还有一个容易被忽略的点是内存。content script 在每个标签页都有一份实例如果每个实例都持有大量数据标签页一多内存就爆了。所以 content script 里只保留当前页面必需的最小状态其余的都放 background 或 storage。5.3 用户感知层面的轻技术上的轻量是一回事用户感知上的轻是另一回事。一个常驻助手如果总是弹提示、总在动、总在刷存在感用户会觉得烦。好的常驻扩展应该是需要时在不需要时隐形。具体做法包括默认不主动弹窗只在用户触发或明确需要时出现动效克制不要用夸张的动画抢注意力提供清晰的开关让用户能随时暂停助手记住用户的偏好不要每次都问同样的问题。这些细节看起来是产品设计但实现上都依赖前面说的状态管理和性能优化做支撑。6. 这类扩展后续能往哪些方向长6.1 从单页助手到跨页工作流现在的常驻助手大多还是单页思维在当前页面帮你做点事。但真实的工作流往往是跨页的你在 A 页收集信息在 B 页整理在 C 页输出。如果助手能理解这种跨页的意图把多个标签页串成一条工作流价值会大很多。技术上这需要更强的会话管理和意图识别。扩展要能判断用户当前处于工作流的哪个阶段主动把上一个阶段的结果带过来。这比单页助手复杂得多但也是差异化最明显的地方。6.2 与本地能力的结合纯云端的助手有延迟和隐私顾虑。如果扩展能结合本地能力比如本地的小模型、本地的文件处理、本地的剪贴板历史很多场景的体验会更好。WebMCP 这类协议如果支持本地能力的注册扩展就能把本地工具也纳入可调用的范围。6.3 开放能力给第三方一个扩展的能力终究有限。如果 EO2Weave 这类工具能把 WebMCP 的能力接口开放出来让第三方开发者基于它开发针对特定网站或特定场景的增强生态就能长起来。这需要一套清晰的协议和审核机制但方向是值得的。7. 我在实际折腾这类扩展时的一些体会做浏览器扩展这些年最大的感受是技术难度往往不在最显眼的地方。OAuth 授权、WebMCP 协议这些听起来很唬人但真正耗时间的是 service worker 被挂起后状态丢失、是 content script 在某个特殊页面上注入失败、是审核员因为一句描述不清打回你的提交。这些琐碎的问题没有捷径只能一个个踩过去。另一个体会是常驻型扩展的产品感和技术实现是深度绑定的。你不能先想一个炫酷的功能再去考虑性能因为性能约束会直接决定哪些功能可行。反过来你也不能只盯着性能做一个小透明工具因为用户装你是为了解决问题。找到那个能力足够有用、占用足够轻的平衡点是这类扩展成败的关键。最后说个具体的。如果你也在做类似的扩展建议尽早把状态管理这块设计清楚别等到功能堆多了再回头重构。我见过太多项目前期图快把状态散落在各个 content script 里后期想加跨页能力时发现根本改不动。状态这层地基打好了上面盖什么楼都稳。