PawWork_ZhuaZhua：把已登录的 Chrome 当成可编程计算机的侧边栏代理
Paw Work - selection-first web agent for Chrome: select on the live page, describe the outcome, take away an editable office file. BYOK, sandboxed, no server.
秒懂
- 它是什么？
- 这是一个 Chrome MV3 未打包扩展，用侧边栏、service worker 和 offscreen 文档串起一个 BYOK 代理，让它在当前标签页上执行动作并产出可编辑的表格与文档。它不解决通用自动化，只解决已经登录的浏览器页面里那些手动重复的活。
- 适合谁用？
- 适合已经在 Chrome 里登录了目标站点、又不想把会话数据交给托管服务的人：把 extension/ 目录 Load unpacked，填入 pagewand_providers 的 BYOK 密钥，从 page-restyle 或一次 sys.fetch 抓取开始试。不适合需要 Chrome Web Store 安装、需要托管模型、或者目标页面是 chrome:// 与 Web Store 的场景，这些情况 README 明确写了不存在或返回 NEED_PAGE。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 6 天前。
- 用什么语言写的？
- 主要是 JavaScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它瞄准的是已登录页面，而不是网页抓取框架
多数浏览器自动化工具从外部驱动浏览器：启动一个新的实例，注入脚本，再想办法把登录态搬过去。PawWork_ZhuaZhua 走的是相反的路。README 的第一句就把定位写死了：把已经登录的 Chrome 当作一台可编程的计算机，爪爪是这台机器上的代理。这句话决定了它的适用范围。你要处理的东西必须在当前这个已经登录的标签页上，cookie、会话、页面身份都是现成的，不需要导出也不需要重放。
目标用户是那种每天在后台系统、内部工具、电商后台里点来点去的人。README 列的场景包括：改写页面样式或隐藏干扰元素、把登录后才能看到的视图抓成表格、用 action 快照自动填表、以页面身份下载文件、批量操作标签页、在同一个标签页注入阅读辅助。这些任务的共同点是不需要跨站点编排，也不需要长期驻留的爬虫，只需要在一个人已经打开的页面上做一次具体的事。
它明确不是选择器小工具，也不是 Chrome Web Store 应用。README 里写得很直白：没有商店上架，只有未打包加载。这个选择带来的是能力上限更高（后面讲 sys 的部分），代价是安装这一步必须手动完成，而且每次改文件都要点一次重新加载。
sidepanel 到 offscreen 的四段数据流
README 用一行箭头概括了架构：sidepanel → service worker → offscreen 的 SessionWorkspaceService → AI SDK 的 ToolLoopAgent。这四段各有分工。侧边栏是交互入口，你在这里输入任务、看到计划卡片。service worker 是 MV3 规定的事件中枢，负责把消息转出去。真正的会话状态放在 offscreen 文档里，因为 MV3 的 service worker 会被回收，而 offscreen 文档可以长期持有 Univer 表格、Univer 文档和站点 HTML 这些会话内的对象。最后一段才是模型循环，由 AI SDK 的 ToolLoopAgent 驱动工具调用。
README 里有一句容易被忽略的话：Plan card is session-only。计划卡片只活在当前会话里。这意味着你关掉侧边栏或者会话结束，之前生成的计划不会留下来变成可复用的资产。想做可复用的东西，得靠打包好的 playbook，而 README 说目前只有一个：page-restyle。
工具分三层。action 面向实时标签页，先 snapshot 拿到一代快照，再用那一代的 ref 加 rev 去改。run 是沙箱 JS，里面的 guest sys 提供 tabs、eval、fetch、cdp、download、screenshot。sheet、doc、web 是三个画布，分别对应 Univer 表格、Univer 文档和带 data-paw-kind=site 的站点视图。另外还有 inspect、acquire、clarify 三个辅助动作，用来读取会话、把公开网络内容拉进来、以及在需要提问或确认计划时暂停。
ref 加 rev 的快照机制决定了它能改什么
action 的用法在 README 里只有一句：Live tab. snapshot, then mutate with that generation's ref + rev。这句话背后是一个明确的约束，快照是有代际的。你拿到的 ref 属于某一代快照，如果页面在这之后发生了变化，那一代的 ref 就可能失效，必须重新 snapshot。
这个设计对静态表单友好，对持续更新的页面不友好。一个每秒刷新价格的行情页，或者一个有轮询的工单列表，快照的窗口期很短。README 没有说明重新快照的代价有多大，也没有给出重试策略，所以从材料上只能确认机制存在，无法确认它在高频变更页面上的实际表现。这是文档偏薄的地方。
fill_form 被单独列出来，说明填表是这个工具里被认真对待的一类操作。填表比点击更适合快照加 ref 的模型，因为表单字段在一段时间内是稳定的，ref 不会立刻失效，而点击往往触发页面跳转或局部重渲染，把快照直接作废。如果你的任务是连续点击一串按钮，这套机制会比填表吃力得多。
sys 不是模型工具，这是理解权限边界的关键
README 里有一句加粗的判断：sys is not a model tool。这句话值得停下来想。sys 的 tabs、eval、fetch、cdp、download、screenshot 这些能力，不是模型可以直接调用的工具，它们存在于 run 的沙箱 JS 里。也就是说，模型写一段 JS，这段 JS 在沙箱里执行，沙箱里的 guest sys 再去碰浏览器。多了一层，也就多了一道可控的边界。
最实际的后果是登录态的处理方式。README 明确说：登录、cookie、验证码走 sys.fetch({ as: "page" })，在 run 里面用。这句提示解决的是一个很常见的问题：普通的 fetch 从扩展上下文发出，带不上页面自己的身份；以页面身份发出，才能拿到登录后才有权限的数据。把抓取结果写进 sheet，就构成了 README 用例里的那条链路。
但这条链路有前置条件。README 的限制表写着：Chrome 138 以上需要在扩展详情里打开 Allow User Scripts，才能用 sys.eval 和页面 fetch。也就是说，升级到较新的 Chrome 反而多了一步手动授权，否则这两个能力不可用。这一点在部署时最容易漏掉。
装载、密钥与那三个会挡住你的错误码
安装路径 README 写得很具体：从 Release 下载 zip，或者 clone 仓库用 extension/ 目录；打开 chrome://extensions，开启开发者模式，点 Load unpacked，选中那个目录，manifest.json 必须在它的根下。然后在侧边栏粘贴 BYOK 密钥，配置键是 pagewand_providers，再到一个正常的 http(s) 页面上发任务。改完加载目录里的文件之后，点扩展卡片上的重新加载。README 特意补了一句：没有日常的 npm。
三个错误码定义了第一批任务能碰到什么。CDP_BUSY 表示目标标签页的 F12 开发者工具开着，CDP 通道被占用，关掉再试。NEED_PAGE 表示当前页面是受限页，README 举了 chrome:// 和 Web Store 两个例子，这类页面拿不到操作权限。还有一个是版本门槛：需要 Chrome 135 以上，低于这个版本直接不成立。
这三个码合起来说明一件事：这个工具的能力边界不在模型上，而在浏览器的权限模型上。受限页、被占用的调试通道、过旧的浏览器版本，都会在你写第一条提示之前就把路堵住。先跑通一个普通 http(s) 页面，再考虑复杂场景，是更省时间的顺序。
和 Tampermonkey 那类脚本方案的真正差别
README 自己给了一个参照系：Anything a Tampermonkey userscript could do is in scope。这句话把能力范围对齐到了用户脚本，同时点出了差别所在。Tampermonkey 需要你写脚本、找脚本、维护脚本，还要面对一个事实：脚本目录里的东西质量参差，而脚本本身是死的，它按预设的匹配规则在预设的时机执行。
PawWork_ZhuaZhua 把执行时机和具体动作交给模型在运行时决定。你在页面上描述想要的结果，模型通过 action 或 run 去达成，不需要事先写匹配规则。代价是确定性下降：脚本每次跑的行为完全一样，代理每次跑可能走不同的路径。对于需要严格可重复的任务，比如每天固定格式的对账导出，脚本方案的确定性是优势而不是缺点。
另一处差别是产物形态。Tampermonkey 脚本的产出通常是页面上的 DOM 改动，或者一次网络请求。PawWork_ZhuaZhua 的产出可以落到 Univer 表格和 Univer 文档里，README 描述的目标是带走一个可编辑的办公文件。这是它区别于纯注入类工具的实质部分。README 也承认目录的薄弱：只有一个打包好的 playbook，page-restyle。想复用别人的成果，目前没有地方可去。
维护成本与 MIT 许可的实际含义
维护成本的结构由未打包这个决定决定。没有商店审核流程，意味着更新不需要等审核，但也意味着没有自动更新通道。用户要么重新下载 Release zip，要么自己 clone 仓库拉取。README 的发布记录里有 v1.0.0-unpacked 以及两个 unpacked 前缀的构建，命名本身就在提示这是按未打包形态分发的。
依赖面看起来是刻意压低的。README 说没有日常的 npm，加载目录就是运行目录。仓库里带了一个测试入口：node --test tests/runtime-regression.test.mjs。这是材料里唯一出现的自动化验证手段，README 没有说明它的覆盖范围，也没有给出 CI 配置，所以它更像是一个回归自测的起点，而不是质量保证。
许可是 MIT，LICENSE 文件在仓库根目录。这意味着你可以修改、再分发，包括用于闭源场景，前提是保留版权声明与许可文本。有一点需要你自己判断而不是照搬：这个扩展会以页面身份发起 fetch、执行 eval、调用 CDP，这些行为在你所在的组织里可能受内部安全策略约束，MIT 许可不会替你解决合规问题。另外，BYOK 意味着密钥存在本地扩展配置里，密钥的保管责任在使用者一侧。以上是关于许可与密钥的事实陈述，不构成法律意见。
编辑结论
适合已经在 Chrome 里登录了目标站点、又不想把会话数据交给托管服务的人：把 extension/ 目录 Load unpacked，填入 pagewand_providers 的 BYOK 密钥，从 page-restyle 或一次 sys.fetch 抓取开始试。不适合需要 Chrome Web Store 安装、需要托管模型、或者目标页面是 chrome:// 与 Web Store 的场景，这些情况 README 明确写了不存在或返回 NEED_PAGE。动手前先确认三件事：Chrome 是否 135 以上，138 以上是否已在扩展详情里打开 Allow User Scripts，以及目标标签页的 F12 是否已经关闭。
社区笔记