1. 多用户 AI Agent 协同平台到底解决什么问题
OpenClaw 本身是一个单机向的 Agent 运行框架，你在一台机器上跑起来，它就是一个人的助手。但真实团队里往往不是一个人用：产品经理要一个写文档的 Agent，前端要一个改组件的 Agent，运营要一个出文案的 Agent。如果所有人共用一个 OpenClaw 实例，会话历史、文件、技能全糊在一起，A 的聊天记录 B 能翻到，这显然没法交付。
开源多用户 AI Agent 协同平台要解决的就是这件事：把 OpenClaw 从「单人工具」改造成「多租户 SaaS」。核心思路是每个用户在服务端拥有独立的 OpenClaw Gateway 进程，进程之间互不可见；上层用一个 Auth Server 做 JWT 鉴权，根据 token 里的用户身份把请求路由到对应的 Gateway。这样每个用户拿到的是一支有记忆、有分工、持续工作的专属 AI 团队，主 Agent 统筹，子 Agent（比如程序开发、视频制作、新媒体运营）执行并汇报。
适合谁来跟做这篇：已经跑通过 OpenClaw 单机版、想把它变成团队内部可共享服务的 Node.js 开发者；或者你正在做 AI Agent 相关的 SaaS 产品，需要一套可参考的多用户隔离方案。技术栈是 Node.js + Express + SQLite + OpenClaw，门槛不高，但有几个坑必须提前说清楚，尤其是模型调用通道这一层——多用户意味着并发调用量成倍增长，如果每个用户各自配一套 Key，管理会失控。这也是为什么后面要引入 TaoToken 做统一 Key 与 API 通道。
我试过把三个测试用户同时挂在一个实例上跑，最直观的收益是：用户之间彻底不串号，A 的 Agent 生成的文件 B 在文件管理里根本看不到。下面从环境准备开始，一步步把可复制的配置给出来。
2. TaoToken 统一 Key 与 API 通道前置准备
多用户平台最容易被忽略的一环是模型调用凭证的管理。单机版你可以在环境变量里塞一个 Key，但多用户场景下，如果每个用户的 Gateway 进程都去读同一个 Key，一旦要换模型、要限流、要排查是哪个用户把额度跑爆了，你没有任何抓手。更麻烦的是，有些用户会自己带 Key 进来，格式五花八门，服务端还得做兼容。
TaoToken 在这里扮演的是统一入口的角色：所有用户的 OpenClaw Gateway 都通过同一个 Base URL 和同一套 Key 去请求模型，服务端只需要维护一份凭证。它的 API 地址是 https://taotoken.net/api，兼容常见的 OpenAI 风格接口，OpenClaw 的模型配置直接填这个地址即可。这样做的好处有三个：一是 Key 集中管理，换模型只改一处；二是调用量可观测，哪个用户请求多一目了然；三是新用户接入时不用教他配模型，开箱即用。
你需要先拿到自己的 Key。登录 TaoToken 控制台，在 API Keys 页面创建一个，复制出来备用。注意这个 Key 只显示一次，丢了就重新建。控制台地址是 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=multiuser_openclaw，API Keys 页面在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=multiuser_openclaw。
拿到 Key 之后，先别急着改代码，用 curl 单独验证一下通道是否通。这一步能帮你把「Key 问题」和「代码问题」分开，后面排障会省很多时间：
curl https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "claude-sonnet-4-20250514", "messages": [{"role": "user", "content": "ping"}], "max_tokens": 16 }'返回里能看到choices数组就说明通道没问题。如果这里就报 401，先别往下走，去检查 Key 有没有复制完整、有没有多余空格。模型 ID 要和你实际开通的一致，写错了会返回模型不存在的错误。关于可用模型列表和参数说明，可以看接入文档 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=multiuser_openclaw。
注意：TaoToken 是合规的 API 聚合通道，服务端调用即可，不需要在客户端做任何额外网络配置。所有请求走标准 HTTPS。
前置准备做完，你应该手上有三样东西：一个可用的 TaoToken Key、验证通过的 API 地址、以及一份能跑起来的 OpenClaw 单机环境。接下来进入多用户隔离配置。
3. 可复制的多用户隔离配置与 JWT 鉴权
这一节是整篇的核心。多用户隔离的本质是「一个用户一个 Gateway 进程 + 一个用户一个数据目录」，Auth Server 只负责鉴权和路由，不碰业务逻辑。先看目录结构，这是隔离的物理基础：
openclaw-multiuser/ ├── auth-server.js # JWT 鉴权 + 用户路由 ├── openclaw-server/ │ ├── server.js # 单用户 Gateway 启动器 │ └── package.json ├── data/ │ ├── user_1001/ # 用户 1001 的独立数据目录 │ │ ├── sessions.db │ │ └── files/ │ └── user_1002/ │ ├── sessions.db │ └── files/ └── .env每个用户的数据落在data/user_<id>/下，SQLite 会话库和生成文件都在里面。Gateway 进程启动时把工作目录指向这个路径，进程之间天然隔离，不需要在应用层写复杂的权限判断。
先配环境变量。.env文件里放 JWT 密钥和 TaoToken 的统一凭证：
# .env JWT_SECRET=replace-with-a-long-random-string TAOTOKEN_API_KEY=sk-your-taotoken-key TAOTOKEN_BASE_URL=https://taotoken.net/api DEFAULT_MODEL=claude-sonnet-4-20250514 GATEWAY_PORT_BASE=4100GATEWAY_PORT_BASE是端口基数，用户 1001 的 Gateway 监听 4101，1002 监听 4102，以此类推。这样路由层只要根据用户 ID 算出端口就能转发。
接下来是 OpenClaw Gateway 的模型配置。OpenClaw 支持通过配置文件指定模型提供方，把 Base URL 指向 TaoToken，Key 从环境变量读：
{ "model": { "provider": "openai-compatible", "baseUrl": "https://taotoken.net/api", "apiKey": "${TAOTOKEN_API_KEY}", "modelId": "claude-sonnet-4-20250514", "maxTokens": 8192 }, "gateway": { "host": "127.0.0.1", "port": 4101, "dataDir": "./data/user_1001" }, "agents": { "main": { "role": "coordinator" }, "sub": ["dev", "video", "media", "misc"] } }这里三件套要写全：Base URL 是https://taotoken.net/api，Key 是环境变量注入的 TaoToken Key，Model ID 是claude-sonnet-4-20250514。少任何一个，Gateway 启动时都会报模型不可用。
然后是 Auth Server 的 JWT 鉴权逻辑。用户登录后签发 token，token 里带userId和role，后续所有请求都带这个 token，服务端解出userId再路由：
// auth-server.js 关键片段 const jwt = require('jsonwebtoken'); const express = require('express'); const app = express(); app.use(express.json()); function signToken(user) { return jwt.sign( { userId: user.id, role: user.role }, process.env.JWT_SECRET, { expiresIn: '7d' } ); } function authMiddleware(req, res, next) { const auth = req.headers.authorization || ''; const token = auth.replace('Bearer ', ''); try { req.user = jwt.verify(token, process.env.JWT_SECRET); next(); } catch (e) { res.status(401).json({ error: 'invalid token' }); } } app.post('/api/chat', authMiddleware, async (req, res) => { const port = process.env.GATEWAY_PORT_BASE * 1 + req.user.userId; // 转发到该用户专属 Gateway proxyToGateway(port, req, res); });authMiddleware是隔离的第一道闸：没有合法 token 直接 401，token 里的userId决定了请求去哪个端口。用户 1001 的 token 永远算不出 1002 的端口，这就是路由层的隔离。
启动顺序也有讲究。先起 Auth Server，再按用户逐个拉起 Gateway。可以用一个简单的启动脚本：
#!/bin/bash source .env node auth-server.js & for uid in 1001 1002 1003; do USER_ID=$uid GATEWAY_PORT=$((GATEWAY_PORT_BASE + uid)) \ node openclaw-server/server.js & done每个 Gateway 进程启动时读自己的USER_ID，把dataDir指向对应目录。进程之间不共享内存，不共享文件句柄，隔离是操作系统级别的，比应用层判断可靠得多。
4. 用 curl 验证各用户专属 Agent 调用互不串号
配置写完不代表隔离生效，必须实测。验证的目标很明确：用户 A 的 token 只能访问 A 的 Agent 和数据，拿 A 的 token 去访问 B 的资源必须失败。下面这组 curl 动作可以直接复制。
第一步，登录拿两个用户的 token：
TOKEN_A=$(curl -s -X POST http://localhost:3000/api/login \ -H "Content-Type: application/json" \ -d '{"username":"userA","password":"passA"}' | jq -r '.token') TOKEN_B=$(curl -s -X POST http://localhost:3000/api/login \ -H "Content-Type: application/json" \ -d '{"username":"userB","password":"passB"}' | jq -r '.token') echo "A=$TOKEN_A" echo "B=$TOKEN_B"两个 token 应该明显不同，因为 payload 里的userId不一样。如果拿到的是null，说明登录接口有问题，先查用户表。
第二步，用 A 的 token 发一条消息，看返回的 Agent 是不是 A 的：
curl -s -X POST http://localhost:3000/api/chat \ -H "Authorization: Bearer $TOKEN_A" \ -H "Content-Type: application/json" \ -d '{"message":"列出你负责的 Agent 分工"}' | jq '.'正常返回里应该能看到 A 的主 Agent 和它的子 Agent 列表。关键检查点：返回内容里不能出现 B 的任何信息。如果出现了，说明路由层把请求发错了端口。
第三步，做越权测试。拿 A 的 token 去请求 B 的数据目录接口：
curl -s -X GET http://localhost:3000/api/files?userId=1002 \ -H "Authorization: Bearer $TOKEN_A" | jq '.'预期结果是 403 或者空列表。如果返回了 B 的文件，隔离就是失败的。这里要强调：userId参数应该被服务端忽略，一切以 token 里的userId为准。很多隔离漏洞就出在「信任了客户端传的 userId」。
第四步，并发验证。同时用两个 token 发请求，看会不会串：
curl -s -X POST http://localhost:3000/api/chat \ -H "Authorization: Bearer $TOKEN_A" \ -d '{"message":"记住一个数字 111"}' & curl -s -X POST http://localhost:3000/api/chat \ -H "Authorization: Bearer $TOKEN_B" \ -d '{"message":"记住一个数字 222"}' & wait然后分别问 A 和 B「我刚才让你记的数字是多少」。A 应该答 111，B 应该答 222。如果 A 答出了 222，说明两个 Gateway 共用了会话库，去检查dataDir是不是配重了。
第五步，确认模型调用走的是 TaoToken 统一通道。在 Gateway 日志里应该能看到请求发往https://taotoken.net/api。如果日志里出现的是别的地址，说明模型配置没生效，回去检查baseUrl字段。
这一组动作跑完，隔离基本就验证到位了。实测下来，最容易出问题的是第三步的越权测试，很多实现会在路由层做一次userId校验，但忘了在数据层再校验一次，导致直接改 URL 参数就能越权。
5. 本篇常见错误排查
多用户平台跑起来之后，报错往往集中在几个固定位置。下面按真实报错对照排查。
401 invalid token：出现在所有带Authorization的请求上。先确认 token 有没有过期（默认 7 天），再确认JWT_SECRET在 Auth Server 和签发时是同一个。如果重启过服务但没改密钥，旧 token 依然有效；如果改过密钥，所有旧 token 全部失效，需要重新登录。还有一种情况是Bearer后面多了空格，replace('Bearer ', '')处理不干净，建议用正则。
local proxy failed / ECONNREFUSED：Auth Server 转发到 Gateway 端口时连不上。原因通常是 Gateway 没起来，或者端口算错了。检查GATEWAY_PORT_BASE + userId的结果和实际监听端口是否一致。如果用户 ID 是字符串，+会变成拼接而不是加法，务必先转数字。另外 Gateway 绑定的是127.0.0.1，如果 Auth Server 在容器里、Gateway 在宿主机，需要改成0.0.0.0并注意防火墙。
reading 'choices' of undefined：模型返回体里没有choices字段。这几乎都是模型调用失败但代码没做错误处理导致的。先看原始返回，常见原因是 TaoToken 的 Key 无效、模型 ID 写错、或者请求体格式不对。用第 2 节的 curl 单独测一次通道，能快速定位。如果 curl 通但代码不通，检查代码里拼接的 URL 是不是https://taotoken.net/api/v1/chat/completions，少一段路径就会 404。
OAuth / 鉴权相关报错：如果你用的是 Claude Code 或 Codex 这类带 OAuth 流程的客户端接入，报错通常和 token 刷新有关。这类客户端建议直接用 API Key 模式，Base URL 填https://taotoken.net/api，Key 填 TaoToken 的 Key，Model ID 填对应模型。三件套缺一不可，尤其是 Model ID，很多 OAuth 报错其实是模型名不匹配伪装出来的。
用户数据串号：最严重的一类。排查顺序是：先看dataDir配置，确认每个用户指向不同目录；再看 SQLite 连接是不是用了全局单例，多用户场景下每个 Gateway 进程应该各自持有自己的连接；最后看文件下载接口，路径拼接时有没有做path.resolve和前缀校验，防止../穿越。
端口冲突：用户多了之后，GATEWAY_PORT_BASE + userId可能撞上系统占用端口。建议把基数设在 40000 以上，并在启动脚本里加端口占用检测，起不来就报明确错误，而不是静默失败。
提示：排障时优先用 curl 复现，不要一上来就翻代码。curl 能通说明通道没问题，问题在业务逻辑；curl 不通说明是配置或凭证问题，范围立刻缩小一半。
6. 长期运行与团队协作的接入建议
把平台跑起来只是第一步，真正投入使用后，你会遇到额度分配、模型切换、Agent 分工调整这些运营层面的事。这里给几个实操建议。
模型调用统一走 TaoToken 之后，换模型只需要改一处配置。比如你想把默认模型从 Claude 换成别的，改.env里的DEFAULT_MODEL，重启所有 Gateway 即可，用户无感知。这比让每个用户自己去配模型省事太多。如果你要做更细的额度控制，可以在 Auth Server 层加一个请求计数，按userId统计调用量，超限的用户返回 429。
对于长期编码和 Agent 协作场景，可以考虑用 Coding Plan 来承载高频调用，地址是 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=multiuser_openclaw。它更适合持续性的开发任务，和这种多用户 Agent 平台的定位是匹配的。
如果你只是想先验证模型效果，不想动代码，可以直接用模型对话页面测一下通道和模型是否正常，地址是 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=multiuser_openclaw。验证通过再接入平台，能少走弯路。
接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=multiuser_openclaw，里面有完整的参数说明和示例。API Keys 管理在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=multiuser_openclaw，建议给平台单独建一个 Key，方便后续按项目区分调用量。
最后说一个容易忽略的点：多用户平台的日志要按userId分开打。每个 Gateway 进程的日志里带上用户 ID，出问题时能快速定位是哪个用户触发的。我踩过的坑是早期所有日志混在一起，一个用户报错，翻了半天才发现是另一个用户的请求把模型额度跑满了。分开打日志之后，排查时间从半小时降到几分钟。
