企业官网建设流程全解析

1. 引言：SOLO 模式刚跑起来，却卡在模型 API 通道上

用 TRAE SOLO 的 SOLO 模式搭一个 AI 服务，本地跑通之后想发给远程的同事联调，第一反应是开 cpolar 把端口穿出去。但真正动手才发现，拦路的不是端口映射，而是模型 API 通道：SOLO 模式里的 Coding Agent 要调用大模型，Key 分散在好几家供应商手里，环境变量改来改去，日志里一会儿鉴权失败一会儿模型名对不上。TaoToken 要做的就是在 cpolar 穿透之前先把这段路铺平——在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 上创建 Key，统一从 https://taotoken.net/api 这个 Base URL 走模型调用，SOLO 模式就有了稳定的模型通道，接下来再穿透本地服务，团队访问到的才是一个真正能跑通的应用，而不是一个半路卡在模型请求上的空壳。

TRAE SOLO 本身不生产模型，它把任务拆解后要反复调用大模型来写代码、做结构优化、做逻辑审查。如果这个调用通道是临时的、不稳定的，后面 cpolar 穿出去的 URL 就只是个空壳。所以这篇文不打算把 TRAE SOLO 和 cpolar 从头到脚再介绍一遍，而是补上两者之间最容易被跳过的一层：模型 API 通道怎么配、怎么验、怎么排障。按三步走：先把 TRAE SOLO 的模型通道切到 TaoToken，让它能稳定地拆任务写代码；再验证 Key 和模型 ID 在真实请求下返回正常；最后开 cpolar 把本地服务穿透给远程协作者。三步的顺序不能反——先穿透后配通道，协作者访问到的只会是一个不断转圈的页面。

2. TRAE SOLO 的 SOLO 模式：先解决「Coding Agent 调哪个模型」的问题

2.1 SOLO 模式从「辅助补全」到「主导开发」，靠的是持续调用模型

传统 AI 编程助手做的是「你敲代码它补全」的辅助动作，而 SOLO 模式把一个完整的开发任务交给 Coding Agent：你把需求描述给它，它自己拆解成几个子任务，比如先搭项目结构、再实现某个函数、最后跑一遍测试。这些子任务的每一步都意味着一次模型请求。项目结构搭到一半，API 连接断了，SOLO 就停在原地；模型名填错，它在拆解任务的规划阶段就直接报错，后边的代码生成根本不会发生。

这意味着 SOLO 模式比普通补全工具更依赖模型 API 通道的稳定性。普通补全模式遇到接口超时，顶多是你敲的代码不出提示，光标还停在那里等你继续输入；SOLO 模式遇到接口超时，是整个任务链中断，计划清单停在某一项，你得手动干预把它推到下一步。另外要留意，SOLO 模式里 Coding Agent 的每一次工具调用都可能触发新的模型请求，一个复杂的编码任务一小时内可能发起几十次调用，通道稍有不稳，失败的次数会被放大。多花一分钟把模型通道配好，就是在减少后面无数次打断。

2.2 多个供应商的 Key 混在一起，SOLO 的每次调用都是一次猜谜

团队用 TRAE SOLO 做联调时，最常遇到的不是代码问题，而是模型通道问题。A 同事用的是某厂商的 Key，B 同事用的是另一家的，等到要把项目分享给远程协作者时，对方那边的环境变量里根本没有可用的模型 Key。更麻烦的是，不同供应商对模型名的命名规则不一样，SOLO 拆解出的任务队列里填了一个 A 家的模型 ID，到了 B 家的 Key 上就返回 model not found。

TaoToken 在这个环节解决的是「统一接入」：它提供一个 Base URL，你只需要一个 API Key，就可以在这个通道下访问多个主流模型。对 TRAE SOLO 来说，配置里不需要为每一家供应商各写一套 Key 和模型 ID，只需要填统一的地址和 Token，模型 ID 以模型广场的标注为准。这样远程协作者拿同一套配置就能跑，不用再问「你那个 Key 是多少，环境变量配了吗」。团队里新增成员时，也不需要单独申请各家 API Key，一份配置直接复用。

2.3 settings.json 里把 TRAE SOLO 的模型调用指到 TaoToken

TRAE SOLO 的模型通道走 Anthropic 兼容协议，配置方式与 Claude Code 类似：既可以在环境变量里设置，也可以写在 ~/.claude/settings.json 的 env 字段中。下面以配置文件为例，把 TRAE SOLO 的模型请求全部收敛到这个统一入口：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY", "ANTHROPIC_MODEL": "你的模型ID，以TaoToken模型广场为准" } }

ANTHROPIC_BASE_URL 是模型请求的入口，注意不要在这里加 /v1。ANTHROPIC_AUTH_TOKEN 填你在官网创建的 API Key，YOUR_API_KEY 是占位符，记得替换成真实值。ANTHROPIC_MODEL 这一项，打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 的模型广场页面，选一个当前需求对应的模型，把模型 ID 复制过来填进去。

保存配置后重启 TRAE SOLO，新建一个 SOLO 对话，输入一句「帮我创建一个 Python FastAPI 服务，包含 liveness 探活接口」，观察它能不能正常拆解任务并生成代码。如果它开始规划子任务并逐条完成，说明模型通道已经通了。这一步做完，后边的 cpolar 穿透才有意义。

3. 穿透之前，先把 TaoToken 的 Key 和模型 ID 定下来

3.1 去官网创建 Key，而不是继续翻之前散落的 Key

打开 TaoToken，注册账号后进入控制台，创建 API Key。创建出来的 Key 是一段随机字符串，复制后立即保存，因为完整 Key 只在创建时展示一次。拿到 Key 后，把它填到上一节 settings.json 的 ANTHROPIC_AUTH_TOKEN 里。

对比一下以前的做法：给团队每个人发一套不同供应商的 Key，或者在一个共享文档里维护十几个环境变量。TaoToken 的做法是只维护一个 Key，一个 Base URL 入口。对 TRAE SOLO 这类支持 Anthropic 兼容协议的编程工具来说，配置量从「每个供应商一套」缩减到「一套通用配置」。这也意味着，后续协作者加入时不需要再单独申请各家 API Key，只需要拿这个 Key 填进自己的工具配置就可以开始干活。

3.2 用一次真实请求验证 Key 能不能用

配置写好后先别急着穿透，先用 curl 验证一下模型通道。TRAE SOLO 最终调用的是 Anthropic 兼容接口，手动发一个最小请求确认 Key 和模型 ID 是否配对：

curl https://taotoken.net/api/v1/messages \ -H "x-api-key: YOUR_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "你的模型ID", "max_tokens": 1024, "messages": [{"role": "user", "content": "ping"}] }'

注意：curl 路径里的 /v1/messages 是 Anthropic 兼容接口的固定路径，而填进 TRAE SOLO 的 Base URL 是 https://taotoken.net/api，不带 /v1，工具会自动拼接。

如果请求返回了正常的内容字段，说明 Key 有效、模型 ID 正确、Base URL 可达，这一步过了再继续。如果返回鉴权报错，先回控制台核对 Key，不要急着改配置。

3.3 模型 ID 不要猜，以模型广场为准

TRAE SOLO 在拆解任务时会按 ANTHROPIC_MODEL 指定的模型发起请求。很多开发者在配置模型 ID 时喜欢凭印象填，填错了日志里就会出现类似 "model not found" 的报错。最稳妥的做法是登录 https://taotoken.net/?utm_source=taotoken_aicg_blog_end，打开模型广场页面，找到你需要的模型，把页面标注的模型 ID 原样复制。不同的模型 ID 对应不同的能力侧重，代码生成任务选通用代码模型，逻辑审查任务可以选推理型模型，这个按实际需要挑即可。

选好模型后把 ID 填进 settings.json。如果你在 3.2 的 curl 里已经验证过这个 ID，那它一定是对的；如果验证时返回模型相关错误，回到模型广场重新核对，不要凭记忆改。模型 ID 看起来像是「厂商前缀 + 版本号」的组合，但每家命名风格不同，有的模型预期会在某个日期后下架，有的只是换了写法，唯一权威的来源就是模型广场页面。

4. cpolar 穿透：把本地服务共享给远程协作者

4.1 先让本地服务监听在 0.0.0.0 而不是 localhost

TRAE SOLO 在本地生成一个 FastAPI 服务后，默认可能监听 127.0.0.1。cpolar 穿透的是端口，如果服务只监听在 localhost，公网请求到了隧道出口也转发不进去。启动服务时建议显式指定监听地址。一个最小化的示例：

# app.py from fastapi import FastAPI app = FastAPI() @app.get("/healthz") def healthz(): return {"status": "ok"}

启动命令用 uvicorn 指定 0.0.0.0：

uvicorn app:app --host 0.0.0.0 --port 5000

本地先用浏览器访问 http://localhost:5000/healthz，能返回 {"status":"ok"} 再继续。这一步和模型通道是隔离的：即使 TRAE SOLO 后续要做更多代码生成工作，只要这个服务进程在跑，穿透就不受模型调用状态影响。把服务和 IDE 分开理解，后面排查问题时思路会清楚很多。

4.2 cpolar http 5000：一条命令生成公网地址

本地服务确认可访问后，启动 cpolar 客户端，执行：

cpolar http 5000

cpolar 会分配一个公网 URL，类似 https://xxxx.cpolar.top。这个 URL 指向本地 5000 端口，访问它等价于访问你电脑上的服务。把 URL 发给远程协作者，对方直接打开 https://xxxx.cpolar.top/healthz 就能看到健康检查返回结果。

注意：cpolar 分配到的 URL 是随机子域，有效期取决于你的套餐。如果团队需要长期使用同一个地址，建议在 cpolar 后台配置固定二级子域名，这样穿透 URL 不会每次重启都变。

需要更稳定的入口时，也可以绑定自定义域名，cpolar 后台都有对应的配置入口。

4.3 协作者访问到的不只是一个 URL，而是整套服务

远程协作者拿到 URL 后，可以把它填到自己的接口配置里，也可以直接在浏览器打开调试。如果这个本地服务本身还依赖别的本地资源，比如数据库、文件目录，这些资源不需要暴露给外网，协作者只要访问服务暴露出的接口即可。这就是 TRAE SOLO + cpolar 的协作闭环：TRAE SOLO 负责生成和迭代服务代码，TaoToken 保障模型调用不断，cpolar 把本地运行的服务直接送到协作者手里。

整条链路里有一处容易误解的地方：cpolar 穿透的是服务端口，不是 TRAE SOLO 本身。TRAE SOLO 是开发环境，它运行在你本机，做代码生成和调试；生成出来的服务进程跑在你本机的一个端口上，cpolar 把这个端口暴露出去。所以协作者访问到的始终是你的服务实例，而不是你的编辑器。

5. 通道配置排障：这三个信号说明 Key 或地址没填对

5.1 日志里出现 401 或 403

TRAE SOLO 报 401 通常是 ANTHROPIC_AUTH_TOKEN 里的 Key 不对。先回官网控制台确认这个 Key 是否还有效、是否被完整复制，注意不要选中前后多余的空格。如果 Key 创建后一直没用过，也可能是创建流程没有走到最后一步，重新建一个再试。

如果 Key 本身没问题，再看 ANTHROPIC_BASE_URL 是否填成了带 /v1 的地址。TaoToken 的 Base URL 是 https://taotoken.net/api，不带版本号，路径拼接由工具自己完成。手写地址时不要照抄 curl 里那种带 /v1 的完整路径，两者作用不同：配置项给工具读，curl 是手动发请求用的。

5.2 日志里提示 model not found

这个报错几乎都是模型 ID 填错。检查 settings.json 里 ANTHROPIC_MODEL 的值，不要凭记忆填，去 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 的模型广场复制完整的模型 ID。另外确认调用方发送的模型 ID 和你填的完全一致，包括大小写和连字符，这类 ID 通常区分大小写，差一个字母就找不到模型。

还有一个容易忽略的场景：同一个 Key 下可以访问多个模型，但不同模型 ID 的能力范围不同。如果你选的模型 ID 本身不在模型广场的列表里，也会报 model not found。所以模型 ID 一定以模型广场页面标注为准，不要参考网上别人贴出来的旧 ID，那些可能已经下架。

5.3 cpolar 生成了 URL 但页面白屏

cpolar 生成了地址但访问白屏，先绕开 cpolar 直接访问本地服务。如果 localhost 能通而公网地址不通，多数是服务监听在 127.0.0.1 而不是 0.0.0.0，按 4.1 的方式重启 uvicorn。如果本地服务本身就 500，那就是服务代码的问题，和穿透无关。

这类问题排错顺序应该是：先服务后穿透，先模型通道后端口映射。模型通道有问题，TRAE SOLO 生成的服务可能根本没写完，端口上跑的是一个半成品，外面看到的自然是白屏或报错；端口映射有问题，本地健康的服务在公网上也进不来。一分为二定位，不要混在一起查。

另外，如果你把 3.2 的 curl 命令改了 URL、改了路径做测试，记得把改动同步回 settings.json。命令行单独验证用的地址可以带完整路径，工具配置里的 Base URL 必须保持 https://taotoken.net/api 的原始形态，两处的作用不同，不要互相覆盖。

6. 收尾：跑通第一次调用后，回控制台看一眼这笔调用

现在 TRAE SOLO 能正常规划任务和生成代码，cpolar 也把本地服务映射成了公网 URL。建议你把这次生成的服务实际调用一两次，然后回到 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 的控制台，查看刚才那几下调用有没有被记录下来。这一步看起来不起眼，但它能让你确认两件事：一是静默消耗不会发生，二是调用量和计费对得上。确认没问题之后，再把 URL 发给团队，进入真正的联调阶段。

工具链的分工也会在踩过一次坑后变得清晰：TRAE SOLO 是开发执行者，它负责把自然语言变成代码；TaoToken 是模型通道，它保证执行者每一步都能叫到模型；cpolar 是连接器，它让本地跑起来的服务能被远程访问。三者各管一段，哪一段先卡壳，后续工作都推进不下去。配置好的 settings.json 也可以随手提交到团队的配置仓库，新成员拉下来改一下 Key 就能开跑，省掉每次联调都要从头对一遍环境变量的流程。