peerd 不是网页自动化玩具，而是浏览器 Agent 权限模型样本

浏览器 Agent 的难点从来不只是“点得准”。真正麻烦的是权限。一个能读页面、点按钮、联网、跑代码、拿 API key 的工具，放进已经登录各种后台的浏览器里，本质上就是高信任自动化软件。它不是普通聊天助手。

peerd 值得重新写，是因为它没有把这个问题藏起来。项目文档反复强调：0.x、experimental、BYOK、no backend、no telemetry，同时把 vault、egress chokepoint、actor 隔离、audit log、red-team suite 都摆出来。它的重点不是炫一个网页自动化 demo，而是回答浏览器 Agent 权限应该怎么拆。

权限不是附属问题，而是产品本身

浏览器扩展要完成任意网页任务，必然会申请强权限。<all_urls>、scripting、tabs、storage 看起来吓人，但如果没有这些权限，它又很难完成“在用户指定页面工作”的目标。关键不在于假装权限不重，而在于每个权限有没有边界、记录和用户确认。

peerd 的 store permission 文档把这些权限解释得比较清楚：scripting 用于读取页面和 DOM 操作；tabs 用于跨标签页工作；storage 用于本地 vault、设置、会话和审计；offscreen 用于本地语音转写；host permission 用于用户临时指定的任务页面。

为什么 Actor 模型比提示词更关键

很多 AI 安全讨论喜欢把焦点放在 system prompt 上：告诉模型不要泄露、不要听网页里的指令、不要越权。但浏览器页面天然是不可信输入。只要不可信输入和高权限工具待在同一个上下文里，提示词迟早会被绕。

peerd 的做法是把读页面、跑 VM、跑 notebook 这些任务交给 keyless actor。actor 有自己的 worker heap，拿不到 provider key；它要出站、要调用模型、要操作页面，都要经过 service worker 的 gate。主 Agent 拿到的是被 fenced 的摘要，而不是所有原始内容。这个设计比“加一段安全提示词”更接近真正的工程防线。

值得团队借鉴的三层防线

• 第一层是 memory boundary：网页文本、命令输出、文件内容先留在 keyless actor 中。
• 第二层是 policy gate：写操作、网络、工具调用、origin、session grant 都要检查。
• 第三层是 audit：动作不是模型说做了就算，而是要留下本地日志，v0.2.5 还加入了 hash-chain tamper evidence。

这三层不只适用于 peerd。任何做 browser agent、desktop agent、company agent 的团队，都应该有类似边界。否则功能越强，事故半径越大。

评估 peerd 的正确方式

不要问“它能不能帮我自动处理公司后台”。先问四个问题：第一，是否能在隔离 profile 里稳定运行；第二，动作确认是否清楚；第三，审计日志能不能复盘；第四，遇到敏感站点和恶意页面时是否会停住。

git clone https://github.com/NotASithLord/peerd.git
cd peerd
# chrome://extensions -> Developer mode -> Load unpacked -> extension/

试用顺序应该从公开网页总结开始，再到测试表单，再到 notebook / WebVM，最后才是内部系统。API key 也应该用低额度、可随时撤销的 key。不要把它和主力密码库、银行、生产云账号放在同一个浏览器 profile。

结论

peerd 还早，不适合被包装成“马上替你上班”的浏览器 AI。但它给出了一个重要样本：浏览器 Agent 的核心竞争力不是点击，而是权限、隔离和审计。谁把这三件事做扎实，谁才有机会进入真实工作流。