OpenClaw 官方文档里的 Pi，本质上是与 Gateway 协作的一类节点和运行模型。理解 Pi 很重要，因为它决定了“智能体在哪里思考、在哪里执行、怎么连接到长期在线的主机”。
Pi 解决的是什么问题
OpenClaw 的核心思路不是把所有事情都塞进一个聊天窗口，而是把：
- 长期在线的 Gateway
- 控制平面客户端
- 节点执行环境
拆开协作。
Pi 的价值就在这里：
- 让你把执行环境放到更合适的设备上
- 让智能体可以连接到长期在线的 Gateway
- 让命令、浏览器和工具能力不必都绑定在同一台机器上
Pi 和 Gateway 的关系
最容易理解的方式是：
- Gateway 是长期在线的中心枢纽
- Pi / 节点是连接到 Gateway 的能力宿主
- 控制台、CLI、自动化则属于控制平面入口
官方架构文档强调：
- 每台主机通常只运行一个 Gateway
- 节点通过 WebSocket 连接 Gateway
- 节点会声明自己的角色和能力
所以 Pi 不是“第二个 Gateway”，而是接入 Gateway 的执行端。
什么时候应该用 Pi / 节点
官方 CLI openclaw node 的适用场景很明确：
- 你想在远程 Linux/Windows 机器上执行命令
- 你想保持 Gateway 主机更稳定、更少暴露执行面
- 你希望把批准后的执行委托给其他机器
- 你要给自动化或 CI 节点提供轻量执行目标
如果你只是在一台笔记本本地试用，暂时未必需要单独上节点。
一个典型的多机架构
比较推荐的家庭或团队结构是：
- 一台长期在线主机运行 Gateway
- 一台桌面或实验机作为节点主机
- 笔记本通过 Dashboard 或 CLI 控制整个系统
这样做的好处：
- 渠道会话留在长期在线主机
- 高权限执行集中在专门节点上
- 控制平面和执行平面解耦
Pi 与浏览器能力的关系
官方 openclaw node 文档提到一个很实用的点：
- 如果节点上的
browser.enabled没被禁用，节点主机会自动广播浏览器代理
这意味着：
- 你不一定需要在 Gateway 主机上跑浏览器自动化
- 可以把浏览器执行交给某个更适合的节点
Pi 架构下的安全边界
官方文档强调，执行仍然受两类约束：
- 执行审批
- 节点主机上的每智能体允许列表
所以即使把执行扩展到其他机器，也不是“自动拿到所有权限”。这点对长期运行尤其重要。
新手怎么决定要不要先学 Pi
我的建议是：
- 如果你还没跑通基础安装，先不要上 Pi
- 如果你已经开始做多机执行、远程命令或浏览器自动化，就应该理解 Pi
最实用的学习顺序是：
- 先跑通 Gateway
- 再学远程访问
- 最后再引入节点 / Pi 结构