从 OrbStack 到浏览器直连，我给 OpenClaw 补安全底盘的全过程

我不是因为看了多少安全文章，才开始重视 Agent 安全。
我是因为养 OpenClaw 第一晚，就被狠狠干掉了 100 刀。

后来我才慢慢意识到：
OpenClaw 这种东西，一旦开始接工具、接浏览器、接执行能力，
安全就不能再停留在"提示词写严一点"这种层面。

而更有意思的是，偏偏它又在这个时候越来越热：
地方开始给场地、给算力，推动落地；
与此同时，也已有部门提醒，安全风险不容忽视。

所以这篇文章，不是空谈安全。
而是我怎么从 OrbStack、TokenGuard，到 pinchtab 安全集成，再到 Chrome 146 + OpenClaw 3.13 的浏览器直连，一层层给 OpenClaw 补底盘的真实过程。

一开始部署 OpenClaw，我就选了 OrbStack

我部署 OpenClaw 的时候，一开始就选了 OrbStack。

原因其实很直接：对于一个会持续运行、会不断接入新能力、还可能连接浏览器和执行工具的 Agent 来说，容器化几乎是天然选择。

它能带来更清晰的运行边界，也让依赖管理、环境隔离、迁移和回滚都更可控。

所以从第一天起，我就没打算让它裸奔。

但现在回头看，我也承认一个事实：

部署时选择了 OrbStack，说明我重视隔离；但这并不等于安全体系已经成型。

真正让我把这件事想透的，不是部署架构本身，而是后面一次真实的损失。

一晚被干掉 100 刀之后，我才真正把安全当成工程问题

在实际使用 OpenClaw 的过程中，我曾经有一晚被狠狠干掉了 100 刀。

这件事对我的冲击很大。

因为在那之前，我对 Agent 风险的理解，更多还停留在一种抽象认知里：
我知道它存在，也知道要小心，但并没有把它当成一个必须系统解决的工程问题。

直到它真的开始烧钱。

这次损失让我彻底明白了一件事：

如果 Agent 已经具备调用能力、访问能力和执行能力，那它的风险就不再只是"回答得对不对"，而是"它有没有在边界内行动"。

一旦边界没有收紧，损失不会先跟你讲道理。

TokenGuard 不是炫技，而是一次亡羊补牢

所以后来我补上的 TokenGuard，并不是什么从一开始就设计得多先进的安全组件。

它更真实的来历，其实就是——亡羊补牢。

那次之后，我需要一个东西，把原本过于松散的调用边界真正收紧。
不是在理念上收紧，而是在实际执行过程中收紧。

很多人一谈 Agent 安全，先想到的还是：

• • 提示词写严一点
• • 告诉它不要乱来
• • 让它遵守规则

但在真实系统里，这远远不够。

Prompt 可以表达意图，
却不能天然替代权限控制。

你当然可以在提示词里写很多约束。
但如果底层没有相应的边界控制，这些约束最后很容易沦为一种"希望它会乖"的心理安慰。

TokenGuard 对我来说，最大的意义不是"多了一层组件"，而是让我开始把安全问题从"模型层提醒"，推进到"系统层约束"。

真正把安全边界逼到台面上的，是 pinchtab 无头浏览器集成

如果说 100 刀那次损失，是让我开始认真对待安全；

那么后来集成 pinchtab 无头浏览器工具，才是真正逼着我把安全边界彻底想清楚的一步。

原因很简单：

浏览器能力，意味着更接近真实世界的行动能力。

一旦 Agent 能通过无头浏览器去访问页面、读取内容、触发交互、执行流程，那么风险模型就会立刻升级。

这时候你面对的，已经不只是"会不会乱说"，而是：

• • 会不会越权访问
• • 会不会被诱导执行不该执行的动作
• • 会不会在复杂页面环境里被 prompt injection 影响
• • 会不会把原本应该人工确认的步骤自动化掉
• • 会不会绕过你以为已经存在的边界

也正是在这个阶段，我越来越确定：

Agent 的安全边界，不能只存在于说明文档里，也不能只停留在系统提示词里，它必须被落实到代码路径和能力约束中。

在真正接入之前，我先让 Gemini deep think 做了安全审查

所以在 pinchtab 集成这件事上，我没有直接硬接。
我的处理方式是：先做安全审查，再做集成。

具体来说，我先让 Gemini deep think 对这条集成链路做了一轮安全审查。

不是为了"听起来更高级"，而是因为这种能力扩展已经足够敏感，值得先把风险面梳理出来。

这一步的价值在于，它帮我把很多原本模糊的担心，变成了更明确的问题：

• • 哪些能力应该暴露，哪些不该暴露
• • 哪些动作必须保持只读，哪些需要二次确认
• • 哪些接口可能成为越权执行入口
• • 哪些安全约束应该放在 prompt，哪些必须写进代码
• • 哪些能力看起来方便，实际上不该默认开放

基于这轮审查，我后面出的就不是一个"随手接上"的方案，而是一个更接近安全集成方案的工程化实现。

从那一刻开始，我对 Agent 能力扩展的态度，已经不是"这个能不能接"，而是：

这个接进来之后，边界怎么定义，权限怎么收口，风险怎么前置。

OpenClaw 3.13 + Chrome 146：浏览器直连时代来了

就在我把 pinchtab 集成方案落地后不久，OpenClaw 和 Chrome 几乎同时推出了一个让我眼前一亮的能力：

Agent 直接连接你已登录的真实浏览器。

2026 年 3 月 13 日，OpenClaw 发布了 3.13 版本，核心更新是 live Chrome session attach——Agent 可以直接连接你正在使用的浏览器，读取你已登录的页面、操作你的真实会话，而不是另起一个无头浏览器从头登录。

几乎同一时间，Chrome 146 版本上线，原生支持了 MCP（Model Context Protocol）。只需要在 chrome://inspect/#remote-debugging 开一个开关，任何兼容 MCP 的 AI Agent 就可以直接接入你的浏览器——读取页面内容、点击元素、填写表单、切换标签页。

这两件事叠加在一起，意味着什么？

之前 Agent 和浏览器之间最大的鸿沟是"认证隔离"。

你的 Agent 可以上网，但它上的不是"你的网"。你登录了 X、登录了微信公众号、登录了 Google——但 Agent 看不到这些会话。它要么需要你手动注入 cookies，要么需要单独走一遍登录流程。

现在这个鸿沟被填平了。

一行配置：

   
   
   {
  "browser": {
    "defaultProfile": "user"
  }
}

Agent 就能看到你看到的一切。

我立刻做了什么：本地验证 + 全面升级技能链

看到这个更新，我没有只是"了解了"。我做了三件事：

第一件：立刻在本地验证。

我把 Arc 浏览器（基于 Chromium 146）以远程调试模式启动，用 Chrome DevTools Protocol 直连已登录的 X 会话。不注入任何 cookies，直接读取了我的个人主页、帖子列表、每条帖子的浏览量和互动数据。

验证结果：完全可用。Agent 看到的就是我登录后看到的真实页面。

第二件：写了两个公共工具脚本。

• • launch-arc-debug.sh：一键确保 Arc 以调试端口启动，自动检测运行状态
• • arc-x-cookies.py：从已连接的浏览器自动提取 X 的认证信息，供其他工具直接使用

第三件：全面升级了 4 个 AI 技能。

升级前，每次操作浏览器类技能，光认证环节就要花 2-4 步。
升级后，认证环节归零。

但能力越大，风险面也越大

说到这里，我必须诚实地补一句：

浏览器直连，是我目前接入的所有能力里，风险面最大的一个。

为什么？

因为传统的浏览器安全模型（CSP、CORS、沙箱）保护的是"你不要访问恶意页面"。但当 Agent 接入你的真实浏览器后，问题变成了："Agent 在你信任的页面上，会不会被恶意内容诱导？"

安全研究机构已经指出，Chrome 146 的 MCP 集成存在新的攻击面：

• • Agent 可以同时看到你所有标签页——邮件、日历、项目管理工具，一次性关联
• • 恶意网页可以通过隐藏 DOM 注入、零宽字符编码、白底白字等方式向 Agent 注入指令
• • 传统安全防护拦不住这类攻击，因为它们不是在攻击浏览器，而是在攻击 Agent 的理解层

超过 72% 的间接 prompt injection 可以绕过模型层面的防护。

所以我的做法很明确：

用，但不裸用。

• • 每个技能的浏览器操作都有明确的能力边界（只操作特定页面，不扫描所有标签页）
• • 高风险操作（发布、提交）必须经过确认
• • 认证信息不出本地，不传到容器
• • 在新能力接入前，先做安全审查，再做集成——这个原则从 pinchtab 时代就没变过

我现在对 Agent 安全的理解：不是装饰层，而是底盘

走到今天，我对 Agent 安全这件事的理解已经非常直接了：

它不是一个"做得更好当然更好"的附加项，
而是一个决定你敢不敢把 Agent 真正接进现实世界的底层条件。

如果没有真实的架构隔离，
没有清晰的权限边界，
没有落实到代码的安全约束，
没有在新能力接入前做足够严肃的安全审查，
那么 Agent 的问题迟早会从这些缝里漏出来。

平时看不出来。
出事的时候就全出来了。

所以今天如果有人问我，Agent 系统真正该先补的是什么，我不会先说"更强的模型"，也不会先说"更聪明的工作流"。

我会说：

• • 先把运行环境隔离好
• • 先把权限边界收紧
• • 先把安全意图落实到代码
• • 先把高风险能力的集成审查做好

因为能力决定它能做什么，
但安全决定你敢不敢把它放进真实世界里持续运行。

结语

OpenClaw 变热，我一点都不意外。
地方支持它，我能理解。
部门警惕它，我同样觉得合理。

因为真正有前景的东西，才会同时迎来推动和警惕。
前者说明它有价值，后者说明它有现实后果。

而我自己的答案，是继续把这件事往工程里做深。
不是为了把风险说得更漂亮，
而是为了让系统在真实世界里活得更久一点。

Agent 安全不是装饰层，是底盘。

这句话，我不是靠读文章得出的。
我是靠 OrbStack、100 刀学费、TokenGuard、pinchtab 集成、Chrome 146 浏览器直连，以及一次次真实的手动验证和技能升级，慢慢换来的。