跳转至

团队设置

This guide sets up one OpenClaw gateway that a whole team uses: a bot in the workspace chat you already have, shared sessions everyone can open and steer in the Control UI, and roles that bound what each person can do. It is the same product as the personal assistant setup - team operation is configuration, not a separate edition.

For an always-on Linux deployment with Cloudflare Access, GitHub identity sync, role bootstrap, and operations, follow Deploy a team server.

开始之前

  • 一个可保持在线的 Gateway 主机：小型 VPS、办公室 Mac 或任何受支持的安装目标。
  • 该主机上已安装并完成 OpenClaw 初始化——参见快速入门。
  • 团队已经使用的聊天工作区（Discord、Google Chat、Mattermost、Microsoft Teams、Slack、Telegram 等）——参见频道。
  • 一个强大的最新一代模型。共享 gateway 会看到比单人设置更多样的输入，而现代模型对 prompt injection 的抵抗力显著更强——参见安全。
  • 可选：队友的 GitHub 账号，如果你希望获得已验证身份和 commit 署名。

单一信任边界

一个 gateway 是一个信任域。所有能够向启用工具的 agent 发送消息的人，都共享该 agent 被授予的工具权限；所有拥有 operator 访问权限的人共享同一个控制平面。对于成员之间已经相互信任的团队，这是正确的模型——会话所有权、在线状态以及角色是边界内的协作护栏，而不是对抗方之间的隔离。

如果你需要服务彼此互不信任的人员或组织，请改为每个租户运行一个 gateway：多租户托管。

步骤 1：让团队访问 Gateway

Gateway 默认绑定到 loopback。请通过经过身份验证的 ingress 为队友提供访问，而不是公开绑定：

  • Tailnet（推荐）：将主机加入你的 tailnet，并启用 Tailscale Serve。使用 gateway.auth.allowTailscale 后，Control UI 登录可以使用每个人的 Tailscale 身份——无需分发共享密钥。
  • 可信代理：使用 Cloudflare Access 等身份感知代理为 Gateway 提供前置服务——参见可信代理身份验证。
  • 共享密钥：token 或密码身份验证适用于小型团队，但所有人都会使用同一个 owner profile，而不是按个人身份——参见身份验证。

基于身份的方案值得进行配置：它们正是让会话 UI 和下文中的 commit 署名从“某人做了某事”变成“谁做了什么”的关键。

步骤 2：连接团队聊天

连接团队所在的频道。示例：一个 Slack 机器人，被允许在一个团队频道中，并在被提及时回复：

{
  channels: {
    slack: {
      enabled: true,
      mode: "socket",
      appToken: { source: "env", provider: "default", id: "SLACK_APP_TOKEN" },
      botToken: { source: "env", provider: "default", id: "SLACK_BOT_TOKEN" },
      groupPolicy: "allowlist",
      channels: {
        "<SLACK_CHANNEL_ID>": { requireMention: true },
      },
    },
  },
}

群聊是一等部署。默认配置已经面向团队。群访问按房间使用允许列表，并且回复需要提及。DM 保持配对默认设置：队友第一次向机器人发送 DM 时会收到配对码。使用 openclaw pairing approve slack <code> 批准它。这样，机器人被点名时参与，否则保持安静。在成员可信的私有房间中，这就是你所需的全部访问控制。对于范围较广或公开的房间，请添加发送者允许列表和 contextVisibility——参见群组。

如果同一批人需要在多个频道中获准访问，请将列表一次性定义为访问组，并在每个频道的允许列表中引用它。

步骤 3：让团队登录 Control UI

使用按个人登录后，每位队友都通过步骤 1 中的 ingress 打开 Control UI。每个人都会获得一个持久的 Gateway profile：显示名称、头像以及按个人的外观偏好。共享密钥连接使用同一个 owner profile。使用 Cloudflare Access 或 Tailscale Serve 时，基于 GitHub 的登录会验证 profile 背后的账号——参见用户模型。

队友还可以在 Plugins → Skills 下创建和导入个人 skills，而无需更改共享 Gateway 配置的权限。Skills 在明确与团队共享之前保持个人状态。当另一位队友加入时，会话会保留其已选择的 revisions；更改其 assignee 不会替换其 skills。你现有的工作区 skills 保持原样，并且一个 operator 的额外频道身份不会启用团队特定指导。

步骤 4：在共享会话中工作

在团队频道中开始的对话可以继续作为一个整个团队都可以打开、引导和接管的会话。多用户模式为每个会话提供三层归属：不可变的创建者、可分配的 owner，以及实际发出 prompt 的人员历史。你可以像分配 GitHub issues 一样，从会话上下文菜单中分配会话。多用户模式还添加了实时在线状态。在线状态显示谁正在查看、谁正在输入，并带有永远不会到达模型或转录的草稿。

对于编码工作，已验证的 GitHub 身份会在 commit 时发挥作用：启用 Git co-author credit 后，来自共享会话的 commit 会为引导该会话的人携带 Co-authored-by trailers，并且生成的 pull requests 会链接回该会话，以便审阅者可以阅读产生该 diff 的对话。

队友可以在 Settings → Profile → Connected accounts 下添加自己的 provider 账号，并使用每个 provider 提供的登录方式。他们的新会话会优先使用该账号，而不会将其设为 Gateway 范围的默认值。协作者使用会话所选的账号，并且共享的同 provider failover 仍然可以应用——参见按个人的模型账号。

要让团队成员从个人 Gateway 中读取选定的会话，而无需控制该机器，请使用 Session Share。源操作员选择会话组，并配对一个仅广播两个只读会话命令的节点。共享的会话记录会显示在团队 Control UI 中该节点下；查看需要查看他人会话的权限，并且不允许继续源会话。

第 5 步：限定每个人可以执行的操作

命名操作员角色将已认证配置文件绑定到一项策略：他们可以访问哪些会话、可以使用哪些代理、一组最大的操作员作用域，以及他们的新会话是否必须使用沙箱：

{
  gateway: {
    roles: {
      default: "guest",
      definitions: {
        maintainer: {
          sessions: { others: "write" },
          agents: ["roboclaw"],
          scopes: ["operator.read", "operator.write", "operator.approvals"],
        },
        guest: {
          sessions: { others: "view" },
          agents: ["roboclaw"],
          scopes: ["operator.read", "operator.write"],
          sandbox: "required",
        },
      },
    },
  },
}

使用 users.setRole Gateway 方法分配角色；有关完整策略范围，请参阅 命名操作员角色；有关每个会话的工具姿态，请参阅 权限模式。

以访客身份编码

需要沙箱的访客可以在没有管理员角色的情况下工作。在默认 workspaceAccess: "none" 下，文件和 shell 工具使用可写的私有工作区， 而不是共享代理工作区。托管技能说明保持只读。 子会话会继承父会话的沙箱要求，即使代理的 默认沙箱模式处于关闭状态。

本地容器沙箱默认没有网络。如果访客需要克隆 公共仓库或安装项目本地依赖项，请显式启用 编码代理的出站网络，例如：

{
  agents: {
    entries: {
      roboclaw: {
        sandbox: {
          workspaceAccess: "none",
          docker: { network: "bridge" },
        },
      },
    },
  },
}

网络访问不会授予主机执行权限，也不会注入共享凭据。请使用 已预装所需运行时的沙箱镜像；只读根 文件系统仍然会阻止系统软件包安装。启用出站流量会允许 请求访问容器可达的目标，因此当该访问需要更严格控制时，请使用受限的 容器网络。有关工作区和网络策略，请参阅 沙箱化。

验证

  • 在允许的团队频道中提及机器人，并确认它在该频道中回复。
  • 以两个不同身份打开 Control UI：两者都应看到该会话、其所有者头像以及彼此的在线状态。
  • 在主机上运行 openclaw security audit，并解决其标记的关于入站访问或暴露的任何问题。

何时拆分

  • 独立的工作区或角色（不能共享内存或文件的项目）：在一个 Gateway 上使用多个代理 - 请参阅 多代理路由。
  • 互不信任的用户、客户或组织： 使用独立的 Gateway，理想情况下使用独立的 OS 用户或主机 - 请参阅 多租户托管 和 安全。

本页原文 Markdown：在 AtomGit 查看·内容源自开源项目 cl/openclaw