peerd 实战评估：浏览器 Agent 真正要解决的是权限、隔离和审计

浏览器一直是 Agent 最难落地、也最绕不开的工作现场。代码可以交给 IDE，脚本可以交给终端，但大量真实流程并不在这两个地方：CRM、工单系统、云控制台、内部后台、文档站、支付后台、招聘系统、数据看板，全都在浏览器里。问题是，浏览器里既有机会，也有风险。它带着登录态、Cookie、真实业务数据和一堆不可信网页内容，不能像普通 demo 那样随便交给模型操作。

peerd 这个项目值得看，原因不在于它又做了一个“AI 帮你点网页”的插件，而在于它把浏览器 Agent 最难的几件事放到同一张桌子上：本地密钥、真实标签页、沙箱执行、权限确认、审计日志、网页注入风险，以及不同执行环境之间的隔离。

这篇不把它当成成熟产品吹。peerd 仍然是 0.x experimental beta，README 明确提醒会有 breaking changes，存储格式也可能变化。更合适的读法是：把它当成一个浏览器原生 Agent 架构样本，看看一个本地优先、高权限的浏览器助手应该怎样拆边界。

先把定位说清楚：它不是远程浏览器

很多网页自动化工具会起一台新的浏览器：Playwright、browser-use、远程 Chrome、云端 RPA，大多是这个思路。好处是环境干净、可复现、容易隔离；坏处是它通常不是你正在使用的浏览器。真实登录态、当前打开的标签页、你刚查到的资料、你正在填写的后台表单，都不一定在里面。

peerd 走的是另一条路：作为 Chrome / Firefox 扩展运行在本机浏览器里，侧边栏就是交互入口，当前标签页就是任务现场。它可以读页面、操作 DOM、打开沙箱、跑 notebook 或 WebAssembly Linux VM，也可以把小应用放在浏览器本地跑。这个方向的价值是贴近工作现场；代价是权限变重，安全设计不能含糊。

项目现状：能试，但要按实验工具对待

仓库：NotASithLord/peerd。
创建时间：2026-06-22，最近仍在密集更新。
许可证：Apache-2.0。
版本：当前公开 release 为 v0.2.5。
技术栈：Manifest V3 浏览器扩展，主体是 vanilla JavaScript；仓库里也有 TypeScript、CSS、HTML、Shell。
运行方式：扩展本体没有构建步骤，开发预览直接加载 extension/ 目录。
模型接入：Anthropic、OpenRouter、OpenAI、Ollama 等，采用 BYOK。
官方承诺：无后端、无账号、无遥测，数据路径里没有 peerd 自己的云服务。

安装：建议只在单独浏览器 Profile 里试

如果只是想体验，不要把它装进主力浏览器。新建一个 Chrome Profile，里面只登录测试账号，先不要打开银行、密码管理器、生产云控制台、公司核心后台。浏览器 Agent 的风险不是“模型回答错了”，而是它可能在真实账号里执行动作。

git clone https://github.com/NotASithLord/peerd.git
cd peerd
# 打开 chrome://extensions
# 打开 Developer mode
# Load unpacked -> 选择仓库里的 extension/ 目录

第一次打开 peerd 侧边栏时，需要创建本地 vault。推荐用 Touch ID / passkey，也可以设恢复短语。之后在 Settings 里填自己的模型 API key。密钥会保存在本地 vault 中，调用模型时才发给对应 provider。

Chrome 在 macOS / Windows 上对非商店 CRX 安装限制很严，所以 README 推荐用 unpacked 或 zip 的方式，而不是和 Chrome 的策略机制较劲。Firefox 预览包相对顺一些，但仍属于早期测试通道。

权限为什么重，重在哪里

peerd 要做的是“用户指定哪个页面，就能在哪个页面工作”，所以 <all_urls> 这类权限几乎不可避免。它还需要 scripting 来注入页面操作函数，需要 tabs 管理和识别标签页，需要 storage 保存 vault、会话和审计日志，需要 sidePanel 作为主界面，需要 offscreen 跑语音转写等后台能力。

这些权限不是小事。一个浏览器扩展一旦能读页面、点按钮、跑代码、拿模型密钥，就必须按高信任软件看待。peerd 的文档也没有掩饰这一点，SECURITY.md 第一段就把它定义成 high-trust software。

最值得研究的是 Actor 隔离

普通 Agent 系统很容易把所有东西堆到一个上下文里：网页内容、命令输出、用户请求、工具说明、API key、网络访问能力，全都在同一个模型循环附近。这种结构遇到 prompt injection 很危险。网页里一段恶意文本不一定能“说服”模型，但只要它进入了有权限的上下文，就有机会诱导模型调用工具、发请求或泄露信息。

peerd 的处理方式是把环境操作交给 actor。读网页的 actor 只负责一个 tab，跑命令的 actor 只负责一个 VM 或 notebook。actor 不持有模型 provider 的 key，也没有完整网络能力。它要调用模型、访问网络、操作页面，都要经过 service worker 重新检查。主 Agent 更像调度者，拿到的是被标记为 untrusted 的摘要，而不是把原始网页内容和命令输出直接吞进去。

这不是完美防线，但方向是对的：不要靠一句“模型要小心”来防 prompt injection，而是让可能带毒的内容待在没有钥匙、没有全局权限的地方。

五个模块其实是一张边界图

peerd-provider：模型 provider 适配，处理流式输出、重试、成本、缓存。
peerd-egress：出站网络和密钥边界，包含 vault、allowlist / denylist、audit log。
peerd-engine：执行环境，包含 WebVM、Notebook、App、headless worker。
peerd-runtime：主 Agent 循环、工具、actor、session、memory、skills、review、goal mode、voice。
peerd-distributed：预览通道里的 dweb / WebRTC peer-to-peer 层。

把这五块拆开看，比记功能列表更有用。provider 管模型，egress 管出站，engine 管执行，runtime 管调度，distributed 管 P2P。对于任何准备做 browser agent 的团队，这种拆法都值得参考。

安全文档里有几个细节值得单独看

peerd 的 threat model 明确写了一个前提：会读取攻击者控制内容的 Agent，迟早会遇到 prompt injection；没有任何内容过滤能可靠解决这个问题。因此它的核心不是过滤，而是 memory、policy、chokepoint 三件事。

Memory：读页面的推理运行在单独 worker heap，那里没有 key，也没有网络能力。
Policy：每次工具调用都经过固定 gate 检查。
Chokepoint：所有出站网络和签名路径都经过可审计的统一出口。

红队结果文档也给了一个实际参考：最近一次记录里 8 个场景、98 个 hostile probes 全部 blocked，覆盖 API key exfiltration、跨源敏感站点 fetch、secret summarization、hostile peer bundle、MCP analog tool poisoning、sandbox escape、SSRF、prompt injection benchmark。这个结果不能等同于“绝对安全”，但比只写一句“安全可靠”有价值得多。

建议的试用顺序

第一天只做只读任务：总结公开网页、比较几个文档标签页、提取表格。
第二步再开测试站点：让它填写无风险表单，确认每次动作是否可见、可撤回。
第三步测试 notebook / WebVM：跑一段小脚本，看沙箱的边界和文件保存逻辑。
第四步检查 audit log：不要只看任务成功，要看记录是否足够复盘。
第五步才讨论能否接入内部流程，而且必须使用测试账号和受限 API key。

不适合的场景

peerd 不适合现在就当企业 RPA 替代品，也不适合放进满是敏感账号的日常浏览器。它更适合工程团队、安全研究者、Agent 工具开发者试读架构，或者在隔离 profile 里做浏览器工作流原型。

如果你要的是 CI 里的稳定浏览器测试，Playwright 更合适。如果你要的是云端长任务，远程浏览器或 VM 更合适。如果你要的是企业权限治理，成熟 RPA 和身份系统仍然更稳。peerd 的价值在另一个位置：本地浏览器里的 Agent runtime 应该怎样设计。

结论

peerd 的意义不在于“浏览器也能有 AI 助手”，这个说法太轻。它真正有价值的地方，是把浏览器 Agent 的几个硬问题放到工程层面处理：密钥在哪里、网页脏内容在哪里、工具调用怎么过 gate、动作怎么留审计、沙箱怎么隔离、P2P 预览能力怎么限制。

这类项目还早，但方向值得盯。Agent 迟早要进入浏览器；到那时，比模型会不会点击更重要的是，浏览器能不能成为一个可审计、可限制、可回滚的 Agent 工作场。