1. 从单机 OpenClaw 到多租户 SaaS为什么 agentClaw 和 ClawHost 会被放在一起比如果你已经在单机上跑通了 OpenClaw接下来大概率会遇到一个绕不开的问题怎么让团队里十几号人甚至上百号人共用一套 Agent 平台同时又不让彼此的对话历史、API Key、工作空间互相污染。这就是 OpenClaw 多租户 SaaS 化的起点。单用户模式下OpenClaw 靠 Docker 容器隔离和 Workspace 机制在单机上跑得很好但一旦进入团队场景问题就集中爆发用户数据没有边界A 的对话历史可能出现在 B 的上下文里每个用户都要单独配模型供应商的 Key管理成本随人数线性上涨资源没有配额一个人跑满 CPU 其他人只能等管理员没有统一后台看不到谁在用、用了多少。多租户要解决的核心就是隔离与治理。隔离分几个层次进程隔离、文件隔离、网络隔离、密钥隔离、资源配额。治理则包括统一认证、配额管理、计费统计、审计日志。OpenClaw 生态里目前有两套被讨论最多的方案一套是 agentClaw走单实例多租户路线用 Docker 容器做隔离适合 5 到 20 人的小团队另一套是 ClawHost走 Kubernetes 原生路线每个机器人一个独立 Pod适合 100 人以上、需要弹性伸缩和商业化运营的场景。两者不是简单的谁替代谁而是对应不同的团队规模和运维能力。我试过把同一套 OpenClaw 分别用这两种方式部署最直观的感受是agentClaw 的上手门槛低到一个人半天就能搞定ClawHost 则要求你先把 K8s 集群、Ingress、PVC、RBAC 这些概念理顺。但当你把模型 endpoint 和 API Key 统一收到 TaoToken 之后两者的配置差异其实被大幅抹平了——你只需要在各自的配置层把 Base URL 和 Key 指向同一个入口剩下的隔离和扩缩容逻辑各管各的。这篇文章就按这个思路先讲清楚两者的架构差异再给出两套可复制的 Helm values 和命名空间配置最后演示统一接入 TaoToken 后的连通性验证。选型上先给一个粗略的判断团队小于 20 人、预算有限、只有基础 Docker 能力选 agentClaw团队超过 100 人、已有 K8s 基础设施、需要金融级隔离和弹性伸缩选 ClawHost。50 人左右是交界点看你对隔离性和运维成本的权衡。下面进入具体对比。2. agentClaw 与 ClawHost 架构差异隔离机制、扩缩容与运维成本全对比先把两者的架构骨架说清楚。agentClaw 的核心是共享实例 Bridge 适配层。它不修改 OpenClaw 源码而是在 OpenClaw Gateway 前面加了一个 Platform GatewayFastAPI PostgreSQL做统一入口负责 JWT 认证和请求路由中间用 TypeScript 写的 Bridge 层把 OpenClaw 的 WebSocket RPC 转成 REST API并注入多租户配置后面是单个共享的 OpenClaw Gateway 服务多个用户靠 Agent ID 区分租户每个租户的任务在按需创建的 Docker 沙箱里执行。这种零侵入设计的好处是升级 OpenClaw 版本时不用担心兼容性坏处是共享实例本身成为单点隔离性依赖 Docker 的边界。ClawHost 的核心是每机器人一 Pod。它由 FastClaw AI 团队开源提供 RESTful API 来创建、部署和管理多租户环境中的 Agent 机器人实例。客户端请求先到 ClawHost 的 Bot API / Admin API / 代理层再路由到 K8s 集群里对应的 OpenClaw Pod每个机器人作为独立 Pod 运行有专用 Service通过子域名路由做流量代理不需要为每个机器人单独配 Ingress共享 PVC 做持久化PostgreSQL 存机器人配置和状态。隔离性上Pod 本身就是强边界配合 NetworkPolicy 和 ResourceQuota 可以做到资源可控。隔离维度上两者差距明显。进程隔离agentClaw 是 Docker 容器ClawHost 是 K8s Pod。文件隔离agentClaw 用 Workspace 目录ClawHost 用独立 PVC。网络隔离agentClaw 允许出站、阻断入站ClawHost 用 NetworkPolicy 精细控制。资源限制agentClaw 默认 2GB 内存、2 CPU、进程数 256ClawHost 可自定义配额。API 密钥agentClaw 存在网关环境变量里租户拿不到ClawHost 用应用级令牌加 RBAC。认证方式agentClaw 用 JWTClawHost 用 Token RBAC。扩缩容是另一个分水岭。agentClaw 是单实例设计扩容基本靠加机器配置不支持水平自动伸缩用户数超过 100 就会吃力。ClawHost 天然支持 HPA机器人 Pod 可以按负载自动扩缩K8s CronJob 还能自动清理过期机器人适合波峰波谷明显的商业化场景。运维成本上agentClaw 一个人维护就够标准 Docker Compose 半小时能部署完ClawHost 需要持续的 K8s 运维能力Helm Chart 部署通常 1 到 2 小时还要配 Ingress Controller、PV、Prometheus Grafana、Cert Manager。成本效率方面agentClaw 最低可以跑在单台 4 核 8GB 服务器上月成本可控在几千元以内ClawHost 建议至少 3 节点、每节点 4 核 16GB月成本两万起步。资源利用率上 agentClaw 的共享实例更高ClawHost 的独立 Pod 更低但隔离性更强。这不是浪费而是为隔离和弹性付的溢价。评估维度agentClawClawHost团队规模 20 人 100 人技术能力基础 Docker熟练 K8s预算投入 5000 元/月 20000 元/月上线时间 1 周2-4 周隔离要求基础隔离金融级隔离扩展需求有限弹性伸缩运维能力1 人维护团队运维这张表不是绝对标准但能帮你快速定位。接下来进入部署环节两套配置我都会给全。3. 两套可复制部署配置agentClaw 的 docker-compose 与 ClawHost 的 Helm values先说 agentClaw。它的部署走 Docker Compose核心是把 Platform Gateway、Bridge、OpenClaw Gateway、PostgreSQL 四个服务串起来。下面这份 docker-compose.yml 可以直接改环境变量后用重点是把模型 endpoint 和 Key 统一指向 TaoToken。version: 3.9 services: postgres: image: postgres:16-alpine environment: POSTGRES_DB: agentclaw POSTGRES_USER: agentclaw POSTGRES_PASSWORD: change_me_strong volumes: - pgdata:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U agentclaw] interval: 10s retries: 5 platform-gateway: image: agentclaw/platform-gateway:latest depends_on: postgres: condition: service_healthy environment: DATABASE_URL: postgresql://agentclaw:change_me_strongpostgres:5432/agentclaw JWT_SECRET: replace_with_random_64_chars OPENCLAW_BASE_URL: http://openclaw-gateway:8080 # 统一模型入口指向 TaoToken LLM_BASE_URL: https://taotoken.net/api LLM_API_KEY: sk-your-taotoken-key LLM_MODEL: claude-sonnet-4-5 ports: - 8000:8000 bridge: image: agentclaw/bridge:latest depends_on: - openclaw-gateway environment: OPENCLAW_WS: ws://openclaw-gateway:8080/rpc PLATFORM_API: http://platform-gateway:8000 openclaw-gateway: image: openclaw/gateway:2026.3.8 environment: OPENCLAW_MULTI_TENANT: true SANDBOX_MEMORY_LIMIT: 2g SANDBOX_CPU_LIMIT: 2 SANDBOX_PIDS_LIMIT: 256 CAP_DROP: ALL volumes: - workspaces:/root/.openclaw volumes: pgdata: workspaces:关键点有三个LLM_BASE_URL 指向 https://taotoken.net/apiLLM_API_KEY 填你在 TaoToken 控制台生成的 KeyLLM_MODEL 填你要用的模型 ID。这样所有租户的模型调用都走同一个入口密钥只存在网关环境变量里租户拿不到。启动命令是docker-compose up -d起来后访问 http://localhost:8000 注册管理员账号。再说 ClawHost。它走 Helm先加仓库再装。下面这份 values.yaml 是生产环境的最小可用配置命名空间单独建一个 clawhost-system。# values.yaml namespace: clawhost-system image: repository: fastclaw/clawhost tag: 0.9.3 pullPolicy: IfNotPresent database: host: clawhost-postgres.clawhost-system.svc.cluster.local port: 5432 name: clawhost user: clawhost password: change_me_strong auth: jwtSecret: replace_with_random_64_chars adminToken: replace_with_admin_token # 统一模型入口指向 TaoToken llm: baseUrl: https://taotoken.net/api apiKey: sk-your-taotoken-key defaultModel: claude-sonnet-4-5 ingress: enabled: true className: nginx wildcardDomain: *.agents.example.com tls: enabled: true secretName: clawhost-wildcard-tls resources: bot: requests: cpu: 500m memory: 1Gi limits: cpu: 2 memory: 4Gi autoscaling: enabled: true minReplicas: 2 maxReplicas: 20 targetCPUUtilizationPercentage: 70 persistence: enabled: true storageClass: standard size: 20Gi命名空间和安装命令kubectl create namespace clawhost-system helm repo add clawhost https://fastclaw-ai.github.io/clawhost helm repo update helm install clawhost clawhost/clawhost \ -n clawhost-system \ -f values.yaml验证 Pod 状态kubectl get pods -n clawhost-system kubectl get svc -n clawhost-system这里要注意ClawHost 的每个机器人 Pod 都会读取 llm.baseUrl 和 llm.apiKey所以你在 values.yaml 里改一次所有新建机器人都走 TaoToken。如果你用的是 Cline MCP 或 Codex 这类客户端配置三件套是 Base URL Key Model ID缺一不可。ClawHost 的 UI 里也支持在模型配置模块单独覆盖但建议统一在 values.yaml 里管避免租户各自为政。4. 统一接入 TaoToken 后的连通性验证从 curl 到 Agent 实际调用配置改完不代表通了必须做连通性验证。分三步先验网关到 TaoToken 的连通再验 OpenClaw 到网关的连通最后验一个真实 Agent 任务跑通。第一步在 agentClaw 的 platform-gateway 容器里直接 curl TaoToken 的模型列表接口。这一步能排除网络和 Key 的问题。docker exec -it agentclaw-platform-gateway-1 sh curl -s https://taotoken.net/api/v1/models \ -H Authorization: Bearer $LLM_API_KEY | head -c 500如果返回 JSON 里有模型列表说明 Key 和网络都正常。如果返回 401说明 Key 不对或没带上如果超时说明容器出网有问题。第二步验 OpenClaw Gateway 到 Platform Gateway 的 RPC 通路。agentClaw 的 Bridge 层是 WebSocket 转 REST可以用一个简单的 REST 调用触发。curl -s http://localhost:8000/api/v1/agents \ -H Authorization: Bearer 你的JWT \ -H Content-Type: application/json \ -d {name:smoke-test,model:claude-sonnet-4-5}返回里应该有 agentId。拿到 agentId 后发一个最小任务curl -s http://localhost:8000/api/v1/agents/agentId/messages \ -H Authorization: Bearer 你的JWT \ -H Content-Type: application/json \ -d {content:回复 OK 两个字母即可}如果返回内容里包含 OK说明从网关到 OpenClaw 到模型再到 TaoToken 的整条链路通了。第三步ClawHost 侧验证。先看 Pod 日志确认它读到了正确的 baseUrl。kubectl logs -n clawhost-system deploy/clawhost-api | grep -i llm.baseUrl然后通过 ClawHost 的 API 创建一个机器人并触发一次对话curl -s https://api.agents.example.com/bot/api/v1/apps/appId/bots \ -H Authorization: Bearer adminToken \ -H Content-Type: application/json \ -d {name:smoke-bot,model:claude-sonnet-4-5}创建成功后用返回的 botId 发消息curl -s https://api.agents.example.com/bot/api/v1/apps/appId/bots/botId/messages \ -H Authorization: Bearer adminToken \ -H Content-Type: application/json \ -d {content:ping}如果返回正常回复说明 ClawHost 的 Pod 已经通过 TaoToken 调通了模型。这一步如果失败优先看 Pod 的 events 和 NetworkPolicy确认出站到 taotoken.net 没被拦。验证通过后你可以在 TaoToken 控制台看到对应的调用记录用来核对租户维度的用量。这一步对多租户计费很关键因为所有租户的调用都汇聚到同一个入口按 Key 或按应用维度统计都方便。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 报错对照多租户部署里报错集中在几个地方我按实际遇到的频率排一下。401 Unauthorized 最常见。agentClaw 侧通常是 LLM_API_KEY 没注入到 platform-gateway 容器或者 Key 前后有空格。检查方法docker exec -it agentclaw-platform-gateway-1 env | grep LLM_API_KEY。ClawHost 侧通常是 values.yaml 里的 llm.apiKey 没生效或者 Helm 升级后 Pod 没重启。检查方法kubectl exec -n clawhost-system pod -- env | grep -i apiKey。还有一种情况是 Key 本身在 TaoToken 控制台被禁用或额度耗尽去控制台确认状态。local proxy failed 这个报错通常出现在客户端侧比如 Cline MCP 或 Codex 配置了本地代理但代理没起来。多租户场景下如果你在 ClawHost 的机器人 Pod 里配了 HTTP_PROXY 环境变量指向一个不存在的地址就会报这个。排查kubectl exec -n clawhost-system pod -- env | grep -i proxy把多余的 proxy 变量删掉。注意这里说的是应用层代理配置不是网络层的东西别混。reading choices 报错一般是模型返回体不符合预期。常见原因是 Base URL 配错了比如把 https://taotoken.net/api 写成了 https://taotoken.net/api/v1导致路径拼接后变成 /api/v1/v1/chat/completions。检查方法在 Pod 里 curl 一下实际请求路径看返回的是不是标准 OpenAI 兼容格式。另一个原因是 Model ID 写错比如把 claude-sonnet-4-5 写成了 claude-sonnet-4.5模型不存在时返回体里没有 choices 字段。OAuth 报错多出现在 Claude Code 或 Codex 这类需要 OAuth 的客户端。如果你在 ClawHost 的机器人里跑 Claude Code它默认走 OAuth 流程但多租户环境里没有浏览器就会卡住。解决办法是改用 API Key 模式把 Base URL 指向 https://taotoken.net/apiKey 用 TaoToken 的 KeyModel ID 填对。Claude Code 的 settings.json 里对应字段是 env.ANTHROPIC_BASE_URL 和 env.ANTHROPIC_API_KEY改完重启会话即可。还有一个容易忽略的ClawHost 的 NetworkPolicy 默认可能只允许特定出站。如果你发现 Pod 里 curl 不通 taotoken.net先看 NetworkPolicykubectl get networkpolicy -n clawhost-system kubectl describe networkpolicy name -n clawhost-system确认 egress 规则里放行了 443 出站。agentClaw 侧则是检查 Docker 网络的出站规则一般默认允许但如果你用了自定义 bridge 网络要确认。最后提醒一个配置一致性问题agentClaw 和 ClawHost 都支持在 UI 里覆盖模型配置但多租户环境下建议统一在部署层管避免租户各自改 Key 导致用量统计混乱。如果你确实需要租户自带 Key那就在应用层做隔离别混到全局配置里。6. 多租户 SaaS 化的下一步从统一入口到 Coding Plan 的长期运营把模型入口统一到 TaoToken 之后多租户平台的运营就顺了很多。你可以在一个控制台里看到所有租户的调用量按应用或按 Key 做配额不用再为每个租户单独对接不同供应商。agentClaw 适合快速起量的小团队ClawHost 适合需要弹性和强隔离的中大型组织两者在接入层其实可以共用同一套模型配置思路。如果你还在选型阶段建议先用 agentClaw 把多租户流程跑通验证租户隔离、配额、计费这些逻辑等团队规模上来再迁到 ClawHost。迁移时重点是把 Skills 和历史数据搬过去模型配置因为已经统一到 TaoToken基本不用动。对于需要长期跑编码 Agent 或多租户 Agent 平台的团队可以关注 TaoToken 的 Coding Plan它在用量和成本上对持续编码场景更友好。接入文档里有各客户端的详细配置示例包括 Claude Code、Cline MCP、Codex 的 auth.json 写法。如果你只是想先验证模型连通性可以直接用模型对话页面发一条消息确认 Key 和 Base URL 没问题再往生产环境配。实际运营中建议把 TaoToken 的 API Key 按租户或按应用拆分这样在控制台里能直接看到每个租户的消耗配额告警也好做。ClawHost 的应用级令牌机制天然适合这种拆分agentClaw 则可以在 Platform Gateway 层做 Key 映射。无论哪种方式统一入口带来的可观测性是单机模式给不了的这也是多租户 SaaS 化最实际的收益之一。 
长河君 · 2026/10/3 6:38:13 · 阅读 1.2k OpenClaw 多租户 SaaS 化实战：agentClaw 与 ClawHost 部署对比及 TaoToken 统一接入
1. 从单机 OpenClaw 到多租户 SaaS为什么 agentClaw 和 ClawHost 会被放在一起比如果你已经在单机上跑通了 OpenClaw接下来大概率会遇到一个绕不开的问题怎么让团队里十几号人甚至上百号人共用一套 Agent 平台同时又不让彼此的对话历史、API Key、工作空间互相污染。这就是 OpenClaw 多租户 SaaS 化的起点。单用户模式下OpenClaw 靠 Docker 容器隔离和 Workspace 机制在单机上跑得很好但一旦进入团队场景问题就集中爆发用户数据没有边界A 的对话历史可能出现在 B 的上下文里每个用户都要单独配模型供应商的 Key管理成本随人数线性上涨资源没有配额一个人跑满 CPU 其他人只能等管理员没有统一后台看不到谁在用、用了多少。多租户要解决的核心就是隔离与治理。隔离分几个层次进程隔离、文件隔离、网络隔离、密钥隔离、资源配额。治理则包括统一认证、配额管理、计费统计、审计日志。OpenClaw 生态里目前有两套被讨论最多的方案一套是 agentClaw走单实例多租户路线用 Docker 容器做隔离适合 5 到 20 人的小团队另一套是 ClawHost走 Kubernetes 原生路线每个机器人一个独立 Pod适合 100 人以上、需要弹性伸缩和商业化运营的场景。两者不是简单的谁替代谁而是对应不同的团队规模和运维能力。我试过把同一套 OpenClaw 分别用这两种方式部署最直观的感受是agentClaw 的上手门槛低到一个人半天就能搞定ClawHost 则要求你先把 K8s 集群、Ingress、PVC、RBAC 这些概念理顺。但当你把模型 endpoint 和 API Key 统一收到 TaoToken 之后两者的配置差异其实被大幅抹平了——你只需要在各自的配置层把 Base URL 和 Key 指向同一个入口剩下的隔离和扩缩容逻辑各管各的。这篇文章就按这个思路先讲清楚两者的架构差异再给出两套可复制的 Helm values 和命名空间配置最后演示统一接入 TaoToken 后的连通性验证。选型上先给一个粗略的判断团队小于 20 人、预算有限、只有基础 Docker 能力选 agentClaw团队超过 100 人、已有 K8s 基础设施、需要金融级隔离和弹性伸缩选 ClawHost。50 人左右是交界点看你对隔离性和运维成本的权衡。下面进入具体对比。2. agentClaw 与 ClawHost 架构差异隔离机制、扩缩容与运维成本全对比先把两者的架构骨架说清楚。agentClaw 的核心是共享实例 Bridge 适配层。它不修改 OpenClaw 源码而是在 OpenClaw Gateway 前面加了一个 Platform GatewayFastAPI PostgreSQL做统一入口负责 JWT 认证和请求路由中间用 TypeScript 写的 Bridge 层把 OpenClaw 的 WebSocket RPC 转成 REST API并注入多租户配置后面是单个共享的 OpenClaw Gateway 服务多个用户靠 Agent ID 区分租户每个租户的任务在按需创建的 Docker 沙箱里执行。这种零侵入设计的好处是升级 OpenClaw 版本时不用担心兼容性坏处是共享实例本身成为单点隔离性依赖 Docker 的边界。ClawHost 的核心是每机器人一 Pod。它由 FastClaw AI 团队开源提供 RESTful API 来创建、部署和管理多租户环境中的 Agent 机器人实例。客户端请求先到 ClawHost 的 Bot API / Admin API / 代理层再路由到 K8s 集群里对应的 OpenClaw Pod每个机器人作为独立 Pod 运行有专用 Service通过子域名路由做流量代理不需要为每个机器人单独配 Ingress共享 PVC 做持久化PostgreSQL 存机器人配置和状态。隔离性上Pod 本身就是强边界配合 NetworkPolicy 和 ResourceQuota 可以做到资源可控。隔离维度上两者差距明显。进程隔离agentClaw 是 Docker 容器ClawHost 是 K8s Pod。文件隔离agentClaw 用 Workspace 目录ClawHost 用独立 PVC。网络隔离agentClaw 允许出站、阻断入站ClawHost 用 NetworkPolicy 精细控制。资源限制agentClaw 默认 2GB 内存、2 CPU、进程数 256ClawHost 可自定义配额。API 密钥agentClaw 存在网关环境变量里租户拿不到ClawHost 用应用级令牌加 RBAC。认证方式agentClaw 用 JWTClawHost 用 Token RBAC。扩缩容是另一个分水岭。agentClaw 是单实例设计扩容基本靠加机器配置不支持水平自动伸缩用户数超过 100 就会吃力。ClawHost 天然支持 HPA机器人 Pod 可以按负载自动扩缩K8s CronJob 还能自动清理过期机器人适合波峰波谷明显的商业化场景。运维成本上agentClaw 一个人维护就够标准 Docker Compose 半小时能部署完ClawHost 需要持续的 K8s 运维能力Helm Chart 部署通常 1 到 2 小时还要配 Ingress Controller、PV、Prometheus Grafana、Cert Manager。成本效率方面agentClaw 最低可以跑在单台 4 核 8GB 服务器上月成本可控在几千元以内ClawHost 建议至少 3 节点、每节点 4 核 16GB月成本两万起步。资源利用率上 agentClaw 的共享实例更高ClawHost 的独立 Pod 更低但隔离性更强。这不是浪费而是为隔离和弹性付的溢价。评估维度agentClawClawHost团队规模 20 人 100 人技术能力基础 Docker熟练 K8s预算投入 5000 元/月 20000 元/月上线时间 1 周2-4 周隔离要求基础隔离金融级隔离扩展需求有限弹性伸缩运维能力1 人维护团队运维这张表不是绝对标准但能帮你快速定位。接下来进入部署环节两套配置我都会给全。3. 两套可复制部署配置agentClaw 的 docker-compose 与 ClawHost 的 Helm values先说 agentClaw。它的部署走 Docker Compose核心是把 Platform Gateway、Bridge、OpenClaw Gateway、PostgreSQL 四个服务串起来。下面这份 docker-compose.yml 可以直接改环境变量后用重点是把模型 endpoint 和 Key 统一指向 TaoToken。version: 3.9 services: postgres: image: postgres:16-alpine environment: POSTGRES_DB: agentclaw POSTGRES_USER: agentclaw POSTGRES_PASSWORD: change_me_strong volumes: - pgdata:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U agentclaw] interval: 10s retries: 5 platform-gateway: image: agentclaw/platform-gateway:latest depends_on: postgres: condition: service_healthy environment: DATABASE_URL: postgresql://agentclaw:change_me_strongpostgres:5432/agentclaw JWT_SECRET: replace_with_random_64_chars OPENCLAW_BASE_URL: http://openclaw-gateway:8080 # 统一模型入口指向 TaoToken LLM_BASE_URL: https://taotoken.net/api LLM_API_KEY: sk-your-taotoken-key LLM_MODEL: claude-sonnet-4-5 ports: - 8000:8000 bridge: image: agentclaw/bridge:latest depends_on: - openclaw-gateway environment: OPENCLAW_WS: ws://openclaw-gateway:8080/rpc PLATFORM_API: http://platform-gateway:8000 openclaw-gateway: image: openclaw/gateway:2026.3.8 environment: OPENCLAW_MULTI_TENANT: true SANDBOX_MEMORY_LIMIT: 2g SANDBOX_CPU_LIMIT: 2 SANDBOX_PIDS_LIMIT: 256 CAP_DROP: ALL volumes: - workspaces:/root/.openclaw volumes: pgdata: workspaces:关键点有三个LLM_BASE_URL 指向 https://taotoken.net/apiLLM_API_KEY 填你在 TaoToken 控制台生成的 KeyLLM_MODEL 填你要用的模型 ID。这样所有租户的模型调用都走同一个入口密钥只存在网关环境变量里租户拿不到。启动命令是docker-compose up -d起来后访问 http://localhost:8000 注册管理员账号。再说 ClawHost。它走 Helm先加仓库再装。下面这份 values.yaml 是生产环境的最小可用配置命名空间单独建一个 clawhost-system。# values.yaml namespace: clawhost-system image: repository: fastclaw/clawhost tag: 0.9.3 pullPolicy: IfNotPresent database: host: clawhost-postgres.clawhost-system.svc.cluster.local port: 5432 name: clawhost user: clawhost password: change_me_strong auth: jwtSecret: replace_with_random_64_chars adminToken: replace_with_admin_token # 统一模型入口指向 TaoToken llm: baseUrl: https://taotoken.net/api apiKey: sk-your-taotoken-key defaultModel: claude-sonnet-4-5 ingress: enabled: true className: nginx wildcardDomain: *.agents.example.com tls: enabled: true secretName: clawhost-wildcard-tls resources: bot: requests: cpu: 500m memory: 1Gi limits: cpu: 2 memory: 4Gi autoscaling: enabled: true minReplicas: 2 maxReplicas: 20 targetCPUUtilizationPercentage: 70 persistence: enabled: true storageClass: standard size: 20Gi命名空间和安装命令kubectl create namespace clawhost-system helm repo add clawhost https://fastclaw-ai.github.io/clawhost helm repo update helm install clawhost clawhost/clawhost \ -n clawhost-system \ -f values.yaml验证 Pod 状态kubectl get pods -n clawhost-system kubectl get svc -n clawhost-system这里要注意ClawHost 的每个机器人 Pod 都会读取 llm.baseUrl 和 llm.apiKey所以你在 values.yaml 里改一次所有新建机器人都走 TaoToken。如果你用的是 Cline MCP 或 Codex 这类客户端配置三件套是 Base URL Key Model ID缺一不可。ClawHost 的 UI 里也支持在模型配置模块单独覆盖但建议统一在 values.yaml 里管避免租户各自为政。4. 统一接入 TaoToken 后的连通性验证从 curl 到 Agent 实际调用配置改完不代表通了必须做连通性验证。分三步先验网关到 TaoToken 的连通再验 OpenClaw 到网关的连通最后验一个真实 Agent 任务跑通。第一步在 agentClaw 的 platform-gateway 容器里直接 curl TaoToken 的模型列表接口。这一步能排除网络和 Key 的问题。docker exec -it agentclaw-platform-gateway-1 sh curl -s https://taotoken.net/api/v1/models \ -H Authorization: Bearer $LLM_API_KEY | head -c 500如果返回 JSON 里有模型列表说明 Key 和网络都正常。如果返回 401说明 Key 不对或没带上如果超时说明容器出网有问题。第二步验 OpenClaw Gateway 到 Platform Gateway 的 RPC 通路。agentClaw 的 Bridge 层是 WebSocket 转 REST可以用一个简单的 REST 调用触发。curl -s http://localhost:8000/api/v1/agents \ -H Authorization: Bearer 你的JWT \ -H Content-Type: application/json \ -d {name:smoke-test,model:claude-sonnet-4-5}返回里应该有 agentId。拿到 agentId 后发一个最小任务curl -s http://localhost:8000/api/v1/agents/agentId/messages \ -H Authorization: Bearer 你的JWT \ -H Content-Type: application/json \ -d {content:回复 OK 两个字母即可}如果返回内容里包含 OK说明从网关到 OpenClaw 到模型再到 TaoToken 的整条链路通了。第三步ClawHost 侧验证。先看 Pod 日志确认它读到了正确的 baseUrl。kubectl logs -n clawhost-system deploy/clawhost-api | grep -i llm.baseUrl然后通过 ClawHost 的 API 创建一个机器人并触发一次对话curl -s https://api.agents.example.com/bot/api/v1/apps/appId/bots \ -H Authorization: Bearer adminToken \ -H Content-Type: application/json \ -d {name:smoke-bot,model:claude-sonnet-4-5}创建成功后用返回的 botId 发消息curl -s https://api.agents.example.com/bot/api/v1/apps/appId/bots/botId/messages \ -H Authorization: Bearer adminToken \ -H Content-Type: application/json \ -d {content:ping}如果返回正常回复说明 ClawHost 的 Pod 已经通过 TaoToken 调通了模型。这一步如果失败优先看 Pod 的 events 和 NetworkPolicy确认出站到 taotoken.net 没被拦。验证通过后你可以在 TaoToken 控制台看到对应的调用记录用来核对租户维度的用量。这一步对多租户计费很关键因为所有租户的调用都汇聚到同一个入口按 Key 或按应用维度统计都方便。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 报错对照多租户部署里报错集中在几个地方我按实际遇到的频率排一下。401 Unauthorized 最常见。agentClaw 侧通常是 LLM_API_KEY 没注入到 platform-gateway 容器或者 Key 前后有空格。检查方法docker exec -it agentclaw-platform-gateway-1 env | grep LLM_API_KEY。ClawHost 侧通常是 values.yaml 里的 llm.apiKey 没生效或者 Helm 升级后 Pod 没重启。检查方法kubectl exec -n clawhost-system pod -- env | grep -i apiKey。还有一种情况是 Key 本身在 TaoToken 控制台被禁用或额度耗尽去控制台确认状态。local proxy failed 这个报错通常出现在客户端侧比如 Cline MCP 或 Codex 配置了本地代理但代理没起来。多租户场景下如果你在 ClawHost 的机器人 Pod 里配了 HTTP_PROXY 环境变量指向一个不存在的地址就会报这个。排查kubectl exec -n clawhost-system pod -- env | grep -i proxy把多余的 proxy 变量删掉。注意这里说的是应用层代理配置不是网络层的东西别混。reading choices 报错一般是模型返回体不符合预期。常见原因是 Base URL 配错了比如把 https://taotoken.net/api 写成了 https://taotoken.net/api/v1导致路径拼接后变成 /api/v1/v1/chat/completions。检查方法在 Pod 里 curl 一下实际请求路径看返回的是不是标准 OpenAI 兼容格式。另一个原因是 Model ID 写错比如把 claude-sonnet-4-5 写成了 claude-sonnet-4.5模型不存在时返回体里没有 choices 字段。OAuth 报错多出现在 Claude Code 或 Codex 这类需要 OAuth 的客户端。如果你在 ClawHost 的机器人里跑 Claude Code它默认走 OAuth 流程但多租户环境里没有浏览器就会卡住。解决办法是改用 API Key 模式把 Base URL 指向 https://taotoken.net/apiKey 用 TaoToken 的 KeyModel ID 填对。Claude Code 的 settings.json 里对应字段是 env.ANTHROPIC_BASE_URL 和 env.ANTHROPIC_API_KEY改完重启会话即可。还有一个容易忽略的ClawHost 的 NetworkPolicy 默认可能只允许特定出站。如果你发现 Pod 里 curl 不通 taotoken.net先看 NetworkPolicykubectl get networkpolicy -n clawhost-system kubectl describe networkpolicy name -n clawhost-system确认 egress 规则里放行了 443 出站。agentClaw 侧则是检查 Docker 网络的出站规则一般默认允许但如果你用了自定义 bridge 网络要确认。最后提醒一个配置一致性问题agentClaw 和 ClawHost 都支持在 UI 里覆盖模型配置但多租户环境下建议统一在部署层管避免租户各自改 Key 导致用量统计混乱。如果你确实需要租户自带 Key那就在应用层做隔离别混到全局配置里。6. 多租户 SaaS 化的下一步从统一入口到 Coding Plan 的长期运营把模型入口统一到 TaoToken 之后多租户平台的运营就顺了很多。你可以在一个控制台里看到所有租户的调用量按应用或按 Key 做配额不用再为每个租户单独对接不同供应商。agentClaw 适合快速起量的小团队ClawHost 适合需要弹性和强隔离的中大型组织两者在接入层其实可以共用同一套模型配置思路。如果你还在选型阶段建议先用 agentClaw 把多租户流程跑通验证租户隔离、配额、计费这些逻辑等团队规模上来再迁到 ClawHost。迁移时重点是把 Skills 和历史数据搬过去模型配置因为已经统一到 TaoToken基本不用动。对于需要长期跑编码 Agent 或多租户 Agent 平台的团队可以关注 TaoToken 的 Coding Plan它在用量和成本上对持续编码场景更友好。接入文档里有各客户端的详细配置示例包括 Claude Code、Cline MCP、Codex 的 auth.json 写法。如果你只是想先验证模型连通性可以直接用模型对话页面发一条消息确认 Key 和 Base URL 没问题再往生产环境配。实际运营中建议把 TaoToken 的 API Key 按租户或按应用拆分这样在控制台里能直接看到每个租户的消耗配额告警也好做。ClawHost 的应用级令牌机制天然适合这种拆分agentClaw 则可以在 Platform Gateway 层做 Key 映射。无论哪种方式统一入口带来的可观测性是单机模式给不了的这也是多租户 SaaS 化最实际的收益之一。