团队里怎么分层放开 provider、模型和 node 能力

OpenClaw 最近几页官方文档一起看，有一个越来越明确的方向：

• provider access 是一层
• model selection 是一层
• image / generation capability 又是一层
• remote node execution 还是另一层

如果团队把这些能力一次性全放开，短期会觉得方便，长期通常会得到：

• 更难解释的权限边界
• 更高的排障成本
• 更危险的远程执行面

第一层：先放开 provider auth，不急着放开所有模型

团队接入新 provider 时，最先确认的通常应该是：

• 能不能完成 auth
• auth profiles 是否稳定
• failover 是否符合预期

这时不一定要同时开放所有模型给前台切换。
更稳的做法是：

• 先让主模型和少数 fallback 可用
• 先验证 provider 侧行为稳定

第二层：再用 allowlist 收口模型选择面

官方 Models 文档现在已经把 agents.defaults.models 定义成 allowlist/catalog。
这意味着你完全可以把团队入口收口成：

• 少数几个稳定 alias
• 少数几种明确用途的模型

而不是一上来把所有 provider/model 都暴露给最终用户。

这样做最值的地方在于：

• 减少误切模型
• 避免把实验模型直接放到主会话
• 给运营和支持留出更清楚的说明口径

第三层：图片相关能力单独审批

很多团队会忽略：

• imageModel
• imageGenerationModel

和普通聊天模型不是一回事。

如果你准备放开共享图片生成或图像理解，更稳的方式是把它当成独立能力线，而不是默认跟着聊天模型一起开。

第四层：remote node 要比模型权限更谨慎

官方 openclaw node 文档现在写得很清楚：

• 远程 node 暴露的是 system.run / system.which
• 仍然要受 local exec approvals 保护
• node host 上还有 per-agent allowlists

这说明 remote node 的本质不是“另一个模型入口”，而是：

• 另一个执行面

它的风险等级通常高于：

• 多开一个 provider
• 多放一个 fallback model

第五层：browser proxy 也应该按 profile 收口

官方最近还把 node browser proxy 的限制条件写明了：

• 默认会暴露 node 上的正常浏览器 profile surface
• 如果设置 nodeHost.browserProxy.allowProfiles，就会变成 restrictive 模式

这对团队环境很重要，因为它意味着：

• 远程浏览器入口也可以只放开被允许的 profile

一个更稳的放开顺序

长期环境里，更推荐按下面顺序推进：

1. 先接 provider auth
2. 再确定 primary + fallbacks
3. 再收口 agents.defaults.models
4. 然后单独评估 image 能力
5. 最后才放 remote node 与 browser proxy

这样做的价值是：

• 问题更容易定界
• 权限扩张速度更可控
• 运营团队更容易知道“到底放开了什么”

哪些迹象说明你放得太快了

如果最近经常出现这些现象，通常说明需要重新分层：

• 前台总有人切到不该用的模型
• auth profile 经常轮转但没人知道为什么
• 图片能力突然可用，但没人确认过 provider
• node 能执行命令了，但 approvals 还没梳理

推荐延伸阅读

• 模型 allowlist、alias 和图片能力门控应该怎么理解
• 认证配置文件怎么轮转，为什么 session 会“粘住”同一套凭据
• 节点能力渐进启用方案