一句话：「每人装一个 AI 管家，公司再放一台公共的」听起来很自然，但真正决定成败的不是装几台，而是员工的电脑里到底跑的是一个客户端，还是一个独立的系统。这两种理解对应三套完全不同的架构，运维成本相差一个数量级。
说明：本文基于 OpenClaw（龙虾）开源版的官方能力整理，结论均可在其文档中复核。文中不含任何内网地址、账号或密钥。
最近有同事问了一个很实际的问题：公司给每名员工配了 AI 管家，公司自己还有一台放在机房的公共管家，那么员工的工作怎么汇总上去？员工之间又怎么互相协作？
这个问题问得好，因为它踩在了一个分界线上。多数人默认「每台电脑装一个」，但装完之后才发现：两个人看不到彼此的工作，公司也看不到任何汇总。于是开始怀疑是不是配错了。
不是配错了。是「装一个」这三个字有歧义。本文把三种可能的架构摊开讲清楚，每种都给拓扑、配置思路、能力边界和验收方式，最后给一张决策路径图。
1. 先确立一个前提：一个网关就是一个信任域
要理解后面所有取舍，先接受这一条：一个 AI 管家服务（下面统称「网关」）就构成一个信任域。
在同一个网关里，会话归属、在线状态、负责人过滤、角色权限这些东西，本质上是协作护栏，不是敌对用户之间的安全边界。谁能操作某个 AI 助手，谁就能让它做这个助手权限范围内的任何事。
这条结论直接推出一个关键判断：
如果每名员工都在自己电脑上装一个独立的网关，那就是每个人各自形成一个信任域。而这种产品目前没有任何「网关联邦」能力，能把 N 个独立信任域自动缝合成一个可以互相协作、自动汇总的整体。
所以本文后面讲的所有跨机器方案，本质上都是在手工搭建这条缝。手工搭建当然能做，但要清楚它的成本。
另一个前提：跨网关没有会话同步
还有一个容易被误解的点：不同网关之间不会自动共享记忆和会话。较新的版本已经移除了跨 AI 助手语料的检索能力，每个助手只搜索自己的记忆。
要让多个助手索引同一批资料，官方只提供一种方式：把它们放进一个显式配置的共享目录。这需要手工配置，不是默认行为。
跨机器的会话可见性，官方只有两条路：只读发布和文本任务派发。没有第三条。
2. 架构 A：公司一台机器，员工只装客户端
这是最容易被误解成「不够用」、实际上却是最好用的那一种。
拓扑很简单：公司机房里那台 Mac mini 运行唯一一个网关，保存所有会话、记忆和工作区。员工的笔记本电脑和手机装的是客户端，连过去使用。
为什么汇总和协作在这里是天然的
因为根本不存在「汇总」这个动作——只有一份数据，没有第二份需要同步。
- 汇总天然成立：所有会话都在同一个管理界面里，不需要任何同步机制。
- 协作天然成立：共享会话、负责人分配、参与者历史、谁在线、谁正在打字，全在同一个界面里。
- 权限可收敛：用命名角色限制谁能看别人的会话、能用哪个助手、是否需要沙箱。
配置要点
第一，员工访问入口必须带身份。有三种方式，粒度完全不同：
| 方式 | 身份粒度 | 适用场景 |
|---|---|---|
| Tailscale Serve | 每人一个身份，映射为独立账号 | 已有内网穿透环境，推荐首选 |
| Cloudflare Access | 企业身份提供商账号 | 已有统一身份认证（SSO） |
| 共享令牌 / 密码 | 所有人共用一个账号 | 仅临时使用，不可用于正式多人 |
最后一行是关键陷阱：用共享令牌省事，但会让系统里所有人显示成同一个身份，「谁做了什么」这件事就此丢失。多人场景必须上身份代理。
第二，角色要收口。给普通员工的是「会话级」权限，只允许读写会话，不包含外发消息、控制设备、查看日志、访问用户目录这些能力。敏感工作放进草稿会话。
第三，员工想要本地算力时，把电脑挂成「节点」。有些工作必须在员工本机跑——访问本机文件、跑本地测试、截图录屏。这时把那台电脑配对成执行节点即可：算力下沉到员工电脑，但网关、状态和记忆仍然在公司。这比「两个对等网关」简单一个数量级，是很多人绕远路的地方。
能力边界
| 维度 | 结论 |
|---|---|
| 员工隐私 | 无。同一份数据，有权限就能读 |
| 离线可用 | 否。断网即不可用 |
| 强隔离 | 无。互不信任必须拆网关、拆系统用户或拆主机 |
| 容量 | 单机上限。并发会话、沙箱容器、浏览器都可能成瓶颈 |
3. 架构 B：员工各装独立龙虾，公司做唯一中转站
这是很多人字面理解出来的那一种：员工电脑上跑完整独立的网关，拥有自己的记忆、工作区和模型凭据；公司那台机器当中心枢纽（hub）。
铁律：员工之间不要两两配对
如果不设中心，5 个员工就是 10 条协作链路，10 个员工就是 45 条。每加一个人，要改全员的配置；有人离职，要清理 N−1 份凭证。这个成本很快就会压过收益。
正确做法是所有跨员工通信都经 hub 中转：
员工 A 的助手 →（文本任务）→ 公司 hub →（文本任务）→ 员工 B 的助手 → 原路返回代价是：hub 必须知道「什么样的请求该转给谁」。而这没有任何自动发现机制，只能靠人工在 hub 的行为规则里写死对应关系。这一点必须提前接受。
汇总：只读发布
汇总走「会话共享」插件。员工在自己机器上把要汇报的会话拖进一个指定分组，公司 hub 就能只读看到这些会话。
三个必须知道的边界：
- 只读。公司能看到记录，但不能继续那个会话，也不能在员工机器上执行命令。
- 有排除项。子任务会话、隐身会话、草稿一律不会发布，即使手动拖进分组也不行。这是设计，不是缺陷。
- 撤回不彻底。员工把会话移出分组，新的读取立即失效，但已经读走的内容收不回来。
连接时务必使用只含两个只读命令的白名单。不加白名单，那台员工机器会对外广播其它能力，等于把执行面暴露出去。
协作：文本任务派发
公司 hub 要主动问员工助手「这周做了什么」，走标准的跨助手协议。但这条路的能力边界很硬：
| 限制 | 实际影响 |
|---|---|
| 只支持文本与结构化数据 | 文件、图片会被忽略，要另找通道传 |
| 不支持流式与推送 | 只能阻塞等待或轮询，没有实时进度 |
| 不支持取消 | 任务一旦开始就停不下来 |
| 任务只存在内存 | 网关重启，所有进行中和历史任务全部丢失 |
| 保留上限 | 已完成任务最多留 24 小时 / 500 条 |
| 限流 | 默认每个对端每分钟 30 次 |
| 审批阻塞 | 员工那边有待审批操作时，任务会一直挂着 |
读完之后你会发现：这不是一条「实时协作」通道，而是一条「异步派活」通道。用它做汇总可以，用它做共同编辑不行。
能力边界
| 维度 | 结论 |
|---|---|
| 员工隐私 | 强。各自本地库，可自主选择发布哪些会话 |
| 离线可用 | 是。各自独立运行 |
| 汇总体验 | 弱。只读、手动分组、有延迟、无法共写 |
| 协作体验 | 弱。经中转、有延迟、需人工维护路由规则 |
| 记忆共享 | 无。只能把共享资料放进配置的共享目录 |
| 运维成本 | 高。N+1 套配置、N+1 份备份、N+1 次升级 |
4. 架构 C：全独立，不设中心
所有机器对等，两两直连，谁也不是中心。
这套架构的问题是结构性的，不是调优能解决的：
- 链路数按平方增长。5 人 10 条，10 人 45 条。
- 没有任何汇总点。公司想知道全员在做什么，只能挨台机器去问。
- 权限无法收敛。A 能问 B，B 就也能问 A，无法只允许单向或只允许特定人。
- 故障会双向传播。一台机器宕机，和它直连的所有人都超时，且没有备用路径。
- 上一节所有协议限制在这里放大 N² 倍：每次跨员工询问都要处理重启丢任务、每分钟限流、不能传文件。
它唯一合理的用途是跨组织一对一对接：两家公司之间的助手互访、和外部顾问的单线协作、临时一次性任务。此时链路数控制在 3 条以内，且每条用独立的高熵凭证。
不适用于「公司内部一个团队」这种需要汇总和多人协作的场景。
5. 三套架构横向对比
| 维度 | A 单网关多客户端 | B 中心辐射 | C 全独立 |
|---|---|---|---|
| 汇总（公司看得到） | 实时、天然、完整 | 只读、手动发布、有延迟 | 做不到 |
| 协作（员工互通） | 同一界面直接共写 | 经中转、需写路由规则 | 两两配对 |
| 员工本地隐私 | 无 | 强 | 最强 |
| 离线可用 | 否 | 是 | 是 |
| 本地算力 | 靠节点下沉 | 天然本地 | 天然本地 |
| 记忆共享 | 天然同一份 | 无 | 无 |
| 运维复杂度 | 最低（1 套） | 中高（N+1 套） | 最高（N 套 + N² 链路） |
| 备份点 | 1 处 | N+1 处 | N 处 |
| 强隔离能力 | 无（同信任域） | 有（每机独立） | 有（每机独立） |
6. 怎么选：一个问题就够了
不要从「装几个」开始想，从员工之间是否需要实时共写同一份工作产物开始想。
如果答案是「需要」
只有架构 A 能满足。所谓实时共写，是指两个人对着同一段文字、同一个文件边改边看。架构 B 的只读发布和文本派发做不到这一点，架构 C 更做不到。
如果答案是「不需要」
再问一层：公司是否需要完整掌握工作过程，而不只是看结果？
如果需要看过程，架构 B 的只读发布覆盖不了，还是要回到 A。如果只看结果就够，再问：是否必须离线可用，或者数据不能离开员工本机？
- 是（安全和合规约束）→ 架构 B
- 否 → 架构 A（更简单，没必要上 N+1 套运维）
架构 C 放在哪里
它不在这棵树上。只有跨组织一对一对接时才用它，且链路数不超过 3 条。
7. 实际的落地建议
先做 A，把 B 当第二阶段。
三个理由：
- A 的每一项能力都是产品的一等公民，配置量最小，官方就有完整的团队部署指南。
- B 里最诱人的「员工本地独立助手」，换来的是 N² 的通信维护、每台机一套升级备份、以及无法自动共享的记忆库。在彼此信任的内部团队里，这些成本通常大于收益。
- 如果真正想要的是「员工本地算力」，用执行节点就够——算力下沉，网关和状态留在公司。这比「两个对等网关」简单一个数量级。
如果确实要走 B，第一步只做一件事验证：一台员工机加公司 hub，跑通只读汇总。如果发现「只读不够，需要能继续会话」，说明你真正需要的是 A。
8. 三条架构共通的红线
备份
架构 A 只需备份公司那一台。架构 B 和 C 的真正项目数据散在 N 台机器上，必须每台都备份——只备份中心节点等于只备份了索引。备份须包含数据库与附件，并校验非空和哈希。
信任边界
三处最容易被误当授权的配置，务必分清：
- 会话共享里的「身份映射」只是把远端账号显示成本地档案，是展示，不是授权。
- 「可见他人会话」是可见性设置，不是隐私隔离。
- 跨助手协议里的用户角色字段不认证真人，不要把它当身份依据。
需要强隔离时，只能拆助手、拆网关、拆系统用户或拆主机。配置层做不到。
身份与凭证
- 多人场景禁止共享令牌（会退化成单一身份）。
- 跨机器通信的凭证走环境变量或密钥管理，不写进配置文件明文，更不入代码仓库。
- 每个对端独立高熵凭证，不复用。员工离职时按「撤销身份 → 检查配对设备残留 → 撤销通信凭证 → 清理共享白名单」的顺序清理。
版本
三条架构的行为都随产品版本变化，尤其是跨助手协议的能力边界和会话共享的发布排除项。升级后须重跑对应验收清单。
9. 常见误区速查
| 现象 | 原因 | 怎么处理 |
|---|---|---|
| 中心看不到员工的会话 | 员工没把会话移进指定分组，或分组名不匹配 | 分组名精确匹配，发布列表不能为空 |
| 某些会话怎么都看不到 | 子任务、隐身、草稿一率不发布 | 这是设计，不是缺陷 |
| 移出分组后中心还能看到旧内容 | 已读走的内容无法收回 | 只能靠事后权限收紧 |
| 任务一直转圈不结束 | 员工侧有待审批操作 | 让员工在本人渠道完成审批 |
| 中心重启后任务全没了 | 任务只存在内存 | 设计如此，长任务改走其它通道 |
| 文件传不过去 | 协议不支持文件与二进制 | 文件另走共享盘 |
| 多人登录后分不清谁是谁 | 用了共享令牌 | 换带身份的访问入口 |
| 所有员工能读所有会话 | 会话可见性默认是「全部」 | 按需收窄为仅本人 / 仅子树 |
写在最后
这个问题表面上在问「装几个」，实际上在问「你要的是协作，还是要的是隔离」。
这两件事在架构上是相反的：越隔离越难协作，越协作越难隔离。产品没有给出一个能同时满足两者的开关，因为那在工程上不存在。
所以真正该先确认的是业务约束：员工之间是否互相信任、公司是否需要掌握过程、数据是否必须留在本机。这三问答完，架构就唯一确定了。反过来先定架构再找理由，通常会在半路上撞到「为什么两个人看不到彼此的活」这个问题。
一个可执行的起点：先用架构 A 把公司内部跑顺，用一个真实项目验证「共享会话 + 负责人分配 + 权限收口」这三件事。跑通之后再评估是否需要引入 B。绝大多数团队的答案是不需要。