企业官网建设流程全解析

1. 多用户办公场景下 DeepThink 自托管接入的真实痛点

团队把 DeepThink 这类开源 AI Agent 跑起来之后，最先撞上的往往不是功能问题，而是模型通道的管理问题。DeepThink 本身是面向企业客户的多用户自托管 Agent 平台，支持桌面端、浏览器和移动端，每个用户拥有独立主工作区、独立 IM 通道和独立会话记忆。这套架构在协作层面很舒服，但一旦落到「谁来提供模型 API」这件事上，麻烦就来了。

我见过最常见的三种混乱状态。第一种是每个成员各自去申请一份 API Key，填进自己的个人设置里。表面上看是「各管各的」，实际上团队根本不知道谁在用哪个模型、花了多少 Token、有没有人把 Key 泄露到聊天记录里。第二种是管理员图省事，把同一个 Key 复制给所有人用。结果是并发一上来就撞限流，日志里全是 429，排查时连是谁触发的都定位不到。第三种更隐蔽：有人用官方直连，有人用某个第三方兼容地址，模型 ID 写法还不统一，导致同一个 Agent 在不同成员那里表现完全不一样，讨论问题时鸡同鸭讲。

DeepThink 的设计其实已经预留了解决空间。它的「模型服务商配置」支持多提供商与负载均衡，提供 Round-Robin、Weighted、Failover 三种策略，还有连续错误追踪和自动健康检测。也就是说，平台层面是鼓励你把模型通道做成一个可管理的池子，而不是散落在每个人手里。问题在于，很多人装完 DeepThink 就直接进设置向导填了一个 Key，后面再没动过这块配置。

这篇要解决的就是这件事：用 TaoToken 作为统一的模型接入层，把 DeepThink 的多用户模型通道收敛成「一份 Key、一个 Base URL、一组模型 ID」，同时保留 DeepThink 原生的多提供商负载均衡能力。适合谁看？正在自托管 DeepThink 的团队管理员、需要给多个成员分配 Agent 工作区的技术负责人，以及想把办公 Agent 从「个人玩具」升级成「团队基础设施」的开发者。

具体会交付三样东西：可复制的 TaoToken 统一 Key 配置片段、多用户环境变量模板，以及一次对话请求验证接入是否生效的完整动作。全程不涉及任何网络工具，只讲配置和验证。

2. TaoToken 前置准备：统一 Key 与模型通道规划

在动 DeepThink 的配置文件之前，先把 TaoToken 这边的准备工作做完。这一步的核心目标是拿到三件套：Base URL、API Key、Model ID。这三样东西后面会反复出现，建议先记在一个临时文档里。

先访问 TaoToken 官网了解服务范围，然后进入控制台创建 API Key。控制台地址是 https://taotoken.net/console ，登录后找到 API Keys 管理页面。创建 Key 的时候有个习惯值得养成：按用途命名，比如deepthink-team-prod或deepthink-admin-host。DeepThink 是多用户系统，admin 用宿主机模式、member 用容器模式，两类工作区的模型调用量差异很大，分开建 Key 方便后面做用量归因。

创建完成后，Key 只会完整显示一次，复制下来妥善保存。TaoToken 的 API 入口是 https://taotoken.net/api ，这个地址就是后面要填进 DeepThink 的 Base URL。注意它和官网地址不是一回事，配置时别填错。

接下来是模型 ID。DeepThink 底层跑的是 Claude Agent SDK，SDK 又调用完整的 Claude Code CLI 运行时，所以模型 ID 要按 Anthropic 兼容格式来写。在 TaoToken 的模型列表里确认你要用的模型标识，常见的是claude-sonnet-4-5这类写法。如果你不确定该选哪个，可以先在模型对话页面手动试一次，确认模型能正常响应再写进配置。

这里有个规划上的建议。DeepThink 支持配置多个提供商并做负载均衡，所以你可以准备两组 Key：一组作为主通道，一组作为 Failover 备用。TaoToken 的 Key 可以创建多个，分别命名，然后在 DeepThink 的提供商池里配置成主备关系。这样即使主 Key 触发限流，DeepThink 的自动健康检测会在连续错误达到阈值后标记不健康，5 分钟后自动恢复探测，期间流量走备用通道。

关于 Coding Plan：如果团队是长期高频使用 Agent 做编码任务，可以了解一下 Coding Plan 的配额模式，它比按量计费更适合稳定的团队场景。入口在 https://taotoken.net/coding-plan 。不过这一步不是必须的，先用按量 Key 把通道跑通，再根据实际用量决定是否切换。

最后确认一下 DeepThink 的前置要求。Node.js 需要 20 或以上，容器模式需要 Docker。admin 主工作区默认走宿主机模式，不装 Docker 也能跑；member 注册后自动创建容器模式工作区，需要先执行./container/build.sh构建镜像。这些在官方仓库的快速开始里都有，按步骤来即可。

3. 可复制配置：DeepThink 模型服务商与多用户环境变量

DeepThink 的配置有个特点：官方推荐所有配置通过 Web 界面完成，API 密钥用 AES-256-GCM 加密存储，不依赖配置文件。但多用户场景下，纯靠 Web 界面点选有两个问题——一是成员多了之后逐个配置容易漏，二是环境变量层面的覆盖关系需要提前理清。所以这一节既给 Web 界面的填写值，也给环境变量模板。

先看 Web 界面里「设置 → 模型服务商」的填写。DeepThink 的提供商配置需要三个核心字段，对应关系如下：

如果你要配置多个提供商做负载均衡，在提供商池里添加多条记录，策略选 Failover 或 Weighted。Failover 适合主备关系，Weighted 适合按权重分流。健康检测的默认行为是连续 3 次错误标记不健康，5 分钟后恢复探测，这个阈值在监控页面可以看到每个提供商的活跃会话计数。

接下来是多用户环境变量模板。DeepThink 支持 Per-workspace 环境变量，群组级环境变量覆盖优先级高于全局配置。这意味着你可以给不同工作区配不同的模型通道。下面这份模板可以直接改：

# DeepThink 多用户模型通道环境变量模板 # 全局默认通道（所有工作区继承） ANTHROPIC_BASE_URL=https://taotoken.net/api ANTHROPIC_API_KEY=sk-你的主Key ANTHROPIC_MODEL=claude-sonnet-4-5 # 备用通道（Failover 场景，部分工作区覆盖） # ANTHROPIC_BASE_URL=https://taotoken.net/api # ANTHROPIC_API_KEY=sk-你的备用Key # ANTHROPIC_MODEL=claude-sonnet-4-5 # 服务端口与并发（按团队规模调整） WEB_PORT=9898 MAX_CONCURRENT_CONTAINERS=20 MAX_CONCURRENT_HOST_PROCESSES=5 CONTAINER_TIMEOUT=1800000 IDLE_TIMEOUT=1800000

这份模板的用法是：全局配置填主通道，然后在需要独立通道的工作区里覆盖ANTHROPIC_API_KEY。DeepThink 的环境变量文件存放在data/env/{folder}/env，容器启动时会读取。注意 admin 主工作区走宿主机模式，读的是宿主机环境；member 工作区走容器模式，环境变量通过挂载传入。

如果你用的是 Claude Code 生态里的配置习惯，DeepThink 的提供商配置本质上和 Claude Code 的 settings 是同一套逻辑。下面这个 JSON 片段可以作为对照参考，帮助你理解字段映射关系：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-你的Key", "ANTHROPIC_MODEL": "claude-sonnet-4-5" } }

需要强调的是，DeepThink 本身不直接读这个 JSON，它读的是 Web 界面配置和data/env/下的环境变量文件。这个片段的价值在于帮你建立「Base URL + Key + Model ID」三件套的认知，后面排查问题时能快速定位是哪个字段出了问题。

配置完成后，DeepThink 的提供商池会接管后续的调用。每个用户的主工作区在发起请求时，队列通过提供商池选择 API 密钥，然后启动宿主机进程或 Docker 容器。容器内的 agent-runner 调用 Claude Agent SDK 的 query() 函数，流式事件通过 stdout 标记协议传回主进程。这条链路里，TaoToken 只负责模型通道这一段，其余都是 DeepThink 自己的调度逻辑。

4. 验证请求：一次对话确认接入生效

配置填完不代表通道通了。DeepThink 的配置项多，任何一个字段写错都可能导致请求失败，而且失败信息不一定直观。所以这一步要用一次最小化的对话请求来验证整条链路。

验证的入口在 DeepThink 的 Web 聊天页面。启动服务后访问http://localhost:9898，用管理员账号登录，进入聊天界面。在发送消息之前，先做两个检查：一是「设置 → 模型服务商」里确认 Base URL 是https://taotoken.net/api，没有多余的空格或斜杠；二是确认 Model ID 和 TaoToken 模型列表里的一致。

然后发送一条最简单的消息，比如「你好，请回复你的模型名称」。观察三个地方：

第一，看聊天界面的流式渲染。DeepThink 的实时流式体验会把 Agent 的思考过程、工具调用、文本输出逐字推送。如果配置正确，你应该能看到打字机效果的内容逐步出现。如果卡住不动，说明请求没有到达模型通道。

第二，看「监控 → 提供商」页面的活跃会话计数。请求发出后，对应提供商的活跃会话数应该从 0 变成 1，请求结束后回落。如果计数一直是 0，说明请求根本没走提供商池，可能是工作区的环境变量覆盖了全局配置，或者提供商被标记为不健康。

第三，看日志。DeepThink 的日志会记录请求的耗时和状态。如果返回 401，说明 Key 无效或格式不对；如果返回 404，通常是 Base URL 写错了；如果返回 429，说明触发了限流，需要检查是不是多个工作区共用了同一个 Key 且并发过高。

一次成功的验证应该看到：聊天界面正常流式输出、提供商活跃会话计数有变化、日志里没有错误状态码。如果这三项都正常，说明 TaoToken 统一接入已经生效，后续所有工作区的模型调用都会走这条通道。

验证通过后，建议再做一次多用户场景的确认。用另一个成员账号登录，在它的工作区里发一条消息，观察提供商池的活跃会话计数是否变成 2。这一步能验证多用户并发下通道是否稳定。如果第二个用户请求失败，大概率是容器模式的环境变量没有正确传入，检查data/env/{folder}/env文件是否存在且内容正确。

对于需要长期跑 Agent 任务的团队，验证完基础通道后，可以进一步测试 Failover。在提供商池里配置主备两个 Key，然后手动把主 Key 改错，观察 DeepThink 是否在连续错误后自动切换到备用通道。这个测试能帮你确认高可用配置真的生效，而不是停留在纸面上。

5. 常见报错排查：401、local proxy failed 与 OAuth 问题

配置过程中撞报错是常态，关键是能快速定位。这一节按真实报错分类，给出排查路径。

401 Unauthorized。这是最常见的错误，含义是 Key 无效或认证失败。排查顺序：先确认 Key 有没有复制完整，TaoToken 的 Key 只在创建时完整显示一次，如果当时没保存，需要重新创建；再确认 Base URL 是不是https://taotoken.net/api，如果误填成官网地址或其他路径，认证会失败；最后确认环境变量有没有被工作区级配置覆盖，DeepThink 的优先级是工作区 > 全局，如果某个工作区填了旧的 Key，会覆盖全局的正确配置。

local proxy failed。这个报错通常出现在容器模式的工作区。DeepThink 的 member 工作区跑在 Docker 容器里，容器需要能访问外部网络。如果宿主机的网络配置有问题，或者容器的 DNS 解析失败，就会出现这个错误。排查方法：进入容器的 Web 终端，执行curl -I https://taotoken.net/api看能否连通。如果连不通，检查 Docker 的网络模式，以及宿主机的 DNS 设置。注意 DeepThink 的容器镜像基于 node:22-slim，预装了 curl，可以直接用来测试。

reading choices 相关报错。这类错误通常和响应格式有关。如果 TaoToken 返回的响应结构不符合 Anthropic 兼容格式，Claude Agent SDK 在解析时会报错。排查时先确认 Model ID 是否正确，错误的模型 ID 可能导致返回非预期格式；再确认请求有没有被中间层改写，比如某些反向代理会修改响应体。DeepThink 支持配置多个提供商，如果只有某一个提供商报这个错，说明问题出在那个提供商的配置上。

OAuth 凭据问题。DeepThink 支持 Claude Code OAuth Token，兼容各类认证方式。如果你用的是 OAuth 而不是 API Key，需要注意 OAuth Token 的有效期和刷新机制。OAuth 过期后会返回认证错误，表现和 401 类似。排查时确认 Token 是否在有效期内，以及 DeepThink 的 OAuth 配置是否完整。对于团队场景，建议优先用 API Key，管理起来更简单。

Codex auth.json 相关。如果你的团队同时用 Codex 类工具，可能会遇到 auth.json 的配置冲突。DeepThink 本身不读 auth.json，但如果宿主机上其他工具修改了环境变量，可能间接影响 DeepThink。排查时检查宿主机的全局环境变量，确认ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY没有被其他工具覆盖。

CC Switch / Cline MCP 场景。如果团队用 CC Switch 管理多个 Claude Code 配置，或者用 Cline 的 MCP 功能，需要确保三件套一致：Base URL 是https://taotoken.net/api，Key 是 TaoToken 创建的 Key，Model ID 是 Anthropic 兼容格式。这三者任何一个不一致，都会导致请求失败。DeepThink 的提供商配置和这些工具的配置逻辑是相通的，配好一个，其他的照搬即可。

排查时有个通用技巧：先在模型对话页面手动发一次请求，确认 TaoToken 侧通道正常；再在 DeepThink 里发请求，确认平台侧配置正常。这样能把问题范围缩小到具体环节，避免在多个配置项之间反复试错。

6. 团队落地建议与后续接入路径

把通道跑通只是第一步，团队真正用起来之后，还有几件事值得提前规划。

第一是 Key 的轮换和归因。TaoToken 控制台支持创建多个 Key，建议按工作区或按角色分配。admin 宿主机模式用一个 Key，member 容器模式用另一个 Key，这样在用量统计页面能直接看出两类工作区的消耗差异。DeepThink 本身也有 Per-model Token 追踪和计费系统，两者结合可以做更细的成本归因。

第二是提供商池的维护。DeepThink 的自动健康检测会在提供商连续错误后标记不健康，5 分钟后恢复探测。这个机制能兜住临时的限流，但如果某个 Key 长期不稳定，还是需要人工介入。建议定期看监控页面的提供商状态，把频繁被标记的 Key 换掉。

第三是多用户环境变量的管理。DeepThink 支持 Per-workspace 环境变量覆盖，这个能力很强，但也容易失控。建议约定一个规则：全局配置只放默认通道，工作区级覆盖只用于特殊场景，比如某个项目需要独立计费或独立模型。规则定清楚，后面排查问题时能少走很多弯路。

后续如果要深入接入，几个入口按场景分流：需要管理 Key 和查看用量，去 API Keys 页面 https://taotoken.net/api-keys ；需要查接入文档和字段说明，去文档页 https://taotoken.net/doc ；需要验证某个模型是否可用，去模型对话页面手动试一次；如果是长期高频的编码 Agent 场景，了解 Coding Plan 的配额模式会更划算。

DeepThink 的桌面版打包和移动端 PWA 也值得一试。桌面版支持 macOS、Windows、Linux 三平台，移动端 PWA 可以一键安装到手机桌面，团队成员在外面也能查看 Agent 执行状态。这些都不影响模型通道的配置，通道配好之后，端只是入口，底层走的还是同一条 TaoToken 链路。

最后提醒一个容易忽略的点：DeepThink 的make reset-init会清空整个data/目录，包括配置、工作区、记忆和会话。生产环境慎用。如果只是要改模型通道配置，在 Web 界面里改就行，不需要重置数据。