企业官网建设流程全解析

1. 龙芯 LoongArch 上跑 AI 工具，为什么总卡在“装不上”这一步

如果你手上有一台龙芯 3A6000 的机器，想在上面跑一个 AI 编程助手或者本地知识库，大概率经历过这样的循环：找到源码，cargo build或pip install，然后被某个没有 LoongArch 预编译包的依赖卡住，手动改 Makefile、补汇编指令、换工具链版本，三天过去，程序终于启动了，界面卡成幻灯片，内存直接飙到 2GB 以上。

这不是硬件不行。3A6000 的四核 2.5GHz 主频、双通道 DDR4 内存，跑一个终端 AI 助手绰绰有余。问题出在软件分发层：x86 生态里“下载即用”的默认体验，在 LoongArch 上变成了“源码编译 + 依赖修补”的体力活。更麻烦的是，很多 AI 工具依赖 Python 运行时或 Node.js 环境，这些运行时在龙芯上的版本碎片化严重，装完 A 工具可能就把 B 工具的依赖搞崩了。

芯语 CAP（Xinyu-CAP）应用商店想解决的就是这个分发断层。它把 LoongArch 原生编译好的二进制直接打包分发，用户不需要碰编译器，也不需要处理依赖树。而 TaoToken 在这里扮演的角色是统一 API 通道：芯语 CAP 里的 AI 工具（比如 Crush-Zh 终端助手、XinyuREG 知识库）需要调用大模型时，不用各自去配 Key、改 Base URL，而是通过 TaoToken 的统一 Key 接入，一个 API Key 覆盖多个模型通道。

这篇文章面向的是已经在龙芯平台上做开发、或者准备把 AI 工作流迁移到 LoongArch 的读者。我会从环境准备开始，走一遍芯语 CAP 的安装、TaoToken Key 的配置、MCP 服务的自动发现验证，以及几个我实际踩过的报错排查。全程命令可复制，配置片段可直接用。

核心检索词先明确：芯语 CAP 是龙芯 LoongArch 平台上的原生应用商店，TaoToken 是统一 API Key 接入通道，两者结合解决的是“AI 工具在国产架构上装不上、连不通”的问题。适合谁：信创环境下的开发者、需要在龙芯上跑本地 AI 助手的团队、以及想用 Rust + MCP 构建原生工作流的工程师。

2. TaoToken 统一 Key 与芯语 CAP 的接入前置准备

在开始装应用之前，先把 TaoToken 的 API Key 拿到手，后面配置 Crush-Zh 和 XinyuREG 都要用。TaoToken 的定位是统一 API 通道，你不需要为每个模型单独申请 Key，也不用在龙芯上折腾网络层配置。它的 API 端点直接可用：https://taotoken.net/api。

2.1 获取 API Key 与确认模型 ID

打开 TaoToken 控制台，在 API Keys 页面创建一个新 Key。创建时注意权限范围，如果你只是本地测试，选默认的对话权限即可。创建完成后复制 Key，格式通常是sk-开头的一串字符。

模型 ID 方面，TaoToken 支持的主流模型在文档里有完整列表。对于芯语 CAP 里的 Crush-Zh 终端助手，我建议先用一个通用对话模型做连通性验证，确认通道没问题后再切换到代码专用模型。你可以在模型对话页面先手动发一条测试消息，确认 Key 有效、余额充足。

这里有个细节：TaoToken 的 Base URL 是https://taotoken.net/api，注意末尾没有/v1，有些工具的配置模板里会默认带/v1，需要手动去掉。这个坑我在 Crush-Zh 的配置里踩过，后面排障章节会详细说。

2.2 龙芯环境的基础依赖检查

芯语 CAP 本身是 Rust 构建的静态二进制，但它的部分应用（比如 Browser Bridge）依赖系统级的库。在安装前，先确认你的 LoongArch 系统满足以下条件：

# 检查内核版本，Firejail 沙箱需要 5.4 以上 uname -r # 检查 glibc 版本，Rust 1.85+ 编译的二进制需要 2.31 以上 ldd --version | head -1 # 检查 Firejail 是否已安装 which firejail || echo "需要安装 firejail" # 检查网络连通性（到 TaoToken API） curl -s -o /dev/null -w "%{http_code}" https://taotoken.net/api

如果firejail未安装，用系统包管理器装一下。在龙芯的 Debian 系发行版上：

sudo apt update sudo apt install firejail -y

Firejail 的版本建议 0.9.68 以上，低版本在 LoongArch 上可能有 seccomp 规则不兼容的问题。装完后用firejail --version确认。

2.3 芯语 CAP 的安装方式选择

芯语 CAP 提供两种安装方式：直接下载预编译的 AppImage 式发布包，或者通过它自带的包管理器安装。我推荐先用发布包做首次验证，因为发布包是静态链接的，不依赖系统 Rust 环境。

从芯语 CAP 的发布页面下载xinyu-cap-loongarch64.tar.gz，解压后直接运行：

tar -xzf xinyu-cap-loongarch64.tar.gz cd xinyu-cap ./xinyu-cap --version

如果输出类似xinyu-cap 0.8.x (loongarch64)，说明二进制本身没问题。首次运行会初始化配置目录，默认在~/.config/xinyu-cap/。这个目录后面放 MCP 服务的注册信息和沙箱配置。

3. 可复制的配置片段：TaoToken Key 写入与 MCP 服务注册

这一章是核心操作部分。芯语 CAP 里的 AI 工具通过 MCP 协议互相发现，而每个需要调用大模型的应用，都要配置 TaoToken 的 Base URL、API Key 和 Model ID。我把配置拆成三块：全局 Key 存储、Crush-Zh 的模型配置、XinyuREG 的 MCP 注册。

3.1 全局 TaoToken 配置写入 settings.json

芯语 CAP 支持一个全局的settings.json，放在~/.config/xinyu-cap/settings.json。这个文件里的 API 配置会被所有应用继承，避免每个应用重复填 Key。

{ "api": { "provider": "taotoken", "base_url": "https://taotoken.net/api", "api_key": "sk-你的TaoTokenKey", "default_model": "你的默认模型ID", "timeout_seconds": 60 }, "mcp": { "auto_discover": true, "scan_interval_seconds": 10, "local_only": true }, "sandbox": { "enabled": true, "default_profile": "xinyu-default" } }

注意base_url末尾不要加/v1。TaoToken 的 API 路径设计是https://taotoken.net/api直接接/chat/completions，如果你写成https://taotoken.net/api/v1，请求会 404。这个配置片段可以直接复制，把api_key和default_model替换成你自己的值。

mcp.auto_discover设为true后，芯语 CAP 的守护进程会每 10 秒扫描一次本地 MCP 服务端口。local_only确保只扫描本机，不会把服务暴露到局域网。

3.2 Crush-Zh 的模型配置与 TOML 片段

Crush-Zh 是终端下的 AI 编程助手，它的配置文件在~/.config/crush-zh/config.toml。这个文件需要显式指定 TaoToken 的通道信息：

[model] provider = "openai-compatible" base_url = "https://taotoken.net/api" api_key = "sk-你的TaoTokenKey" model_id = "你的模型ID" max_tokens = 4096 temperature = 0.3 [mcp] enabled = true discovery_mode = "auto" registry_path = "~/.config/xinyu-cap/mcp-registry.json" [sandbox] firejail_profile = "crush-zh" allow_network = true

这里provider写openai-compatible是因为 TaoToken 的 API 兼容 OpenAI 的请求格式。allow_network = true是必须的，因为 Crush-Zh 要调用远程模型 API。但 Firejail 沙箱仍然会限制它只能访问 TaoToken 的域名，其他网络请求会被拦截。

配置写完后，用 Crush-Zh 自带的检查命令验证：

crush-zh --check-config

如果输出Config OK: model endpoint reachable，说明 Base URL 和 Key 都没问题。如果报401 Unauthorized，检查 Key 是否复制完整；如果报connection refused，检查base_url是否误加了/v1。

3.3 XinyuREG 知识库的 MCP 注册

XinyuREG 是本地向量知识库，它作为 MCP 服务运行，Crush-Zh 会自动发现它。XinyuREG 的配置在~/.config/xinyu-reg/config.json：

{ "mcp_server": { "enabled": true, "port": 18789, "host": "127.0.0.1", "capabilities": ["vector_search", "document_ingest", "embedding"] }, "storage": { "path": "~/.local/share/xinyu-reg/vectors", "embedding_model": "local-minilm" }, "api": { "base_url": "https://taotoken.net/api", "api_key": "sk-你的TaoTokenKey", "model_id": "你的嵌入模型ID" } }

XinyuREG 的 embedding 模型也走 TaoToken 通道，这样你不需要在龙芯上单独部署嵌入模型。port默认 18789，如果被占用可以改，但改完后 Crush-Zh 的自动发现可能需要重新扫描。

启动 XinyuREG：

xinyu-reg --daemon

然后用ss -tlnp | grep 18789确认端口在监听。如果没监听，检查mcp_server.enabled是否为true。

4. 验证请求：从 API 连通性到 MCP 自动发现

配置写完后，不要急着在 Crush-Zh 里问问题，先做三层验证：TaoToken API 直连、Crush-Zh 模型调用、MCP 服务发现。每层验证通过后再进下一层，这样出问题容易定位。

4.1 TaoToken API 直连验证

用 curl 直接打 TaoToken 的 chat completions 端点：

curl -s -X POST https://taotoken.net/api/chat/completions \ -H "Authorization: Bearer sk-你的TaoTokenKey" \ -H "Content-Type: application/json" \ -d '{ "model": "你的模型ID", "messages": [{"role": "user", "content": "回复OK两个字母"}], "max_tokens": 10 }'

预期返回是一个 JSON，choices[0].message.content里包含OK。如果返回401，Key 有问题；如果返回404，URL 路径写错了；如果返回model not found，模型 ID 不对。这一步在龙芯上跑和在 x86 上跑没有区别，因为 curl 是纯网络请求。

4.2 Crush-Zh 的模型调用验证

API 直连通过后，在 Crush-Zh 里发一条测试消息：

crush-zh --prompt "用一句话解释 LoongArch 的 LASX 指令集"

如果 Crush-Zh 正常返回模型输出，说明 TOML 配置里的base_url、api_key、model_id三者都正确。如果报reading choices: unexpected end of JSON input，通常是 TaoToken 返回了非 JSON 响应，检查base_url是否被错误地拼接了额外路径。

我实测下来，Crush-Zh 在 3A6000 上的首次响应时间大约 1.2 秒（不含模型推理时间），后续请求因为连接复用会降到 0.8 秒左右。这个延迟主要花在 TLS 握手和请求序列化上，Rust 的 reqwest 库在 LoongArch 上表现稳定。

4.3 MCP 自动发现验证

Crush-Zh 和 XinyuREG 都启动后，检查 MCP 注册表：

cat ~/.config/xinyu-cap/mcp-registry.json

预期看到类似这样的内容：

{ "services": [ { "name": "xinyu-reg", "host": "127.0.0.1", "port": 18789, "capabilities": ["vector_search", "document_ingest"], "last_seen": "2025-01-15T10:30:00Z" } ] }

如果services数组为空，说明自动发现没生效。检查settings.json里的mcp.auto_discover是否为true，以及 XinyuREG 的mcp_server.enabled是否为true。两个都确认后，重启芯语 CAP 守护进程：

xinyu-cap --restart-daemon

等 10 秒再查注册表。如果还是空，手动触发一次扫描：

xinyu-cap --scan-mcp

4.4 端到端调用验证

MCP 注册成功后，在 Crush-Zh 里问一个需要知识库的问题：

crush-zh --prompt "从本地知识库检索 LoongArch 相关的文档，总结三条关键信息"

Crush-Zh 会自动调用 XinyuREG 的vector_search能力，把检索结果作为上下文，再通过 TaoToken 通道发给模型。如果返回的内容里包含你之前导入知识库的文档片段，说明整条链路通了：Crush-Zh → MCP 发现 → XinyuREG 检索 → TaoToken API → 模型响应。

5. 本篇常见报错排查：401、local proxy failed 与 reading choices

这一章列的是我在龙芯平台上实际遇到的报错，以及对应的排查路径。每个报错都给出具体现象和修复命令。

5.1 401 Unauthorized：Key 无效或未加载

现象：Crush-Zh 启动时报401 Unauthorized，或者 curl 测试返回{"error": "invalid api key"}。

排查步骤：

# 确认 Key 是否被正确读取 crush-zh --show-config | grep api_key # 确认 Key 本身有效（直接打 TaoToken 的验证端点） curl -s -H "Authorization: Bearer sk-你的Key" https://taotoken.net/api/models

如果--show-config显示的 Key 是sk-****掩码，说明配置加载了。如果 curl 返回 401，去 TaoToken 控制台确认 Key 是否被禁用或删除。常见原因是复制 Key 时带了空格，或者把 Key 写进了错误的配置文件（比如写到了settings.json但 Crush-Zh 读的是config.toml）。

5.2 local proxy failed：沙箱网络策略拦截

现象：Crush-Zh 报local proxy failed: connection refused或firejail: network unreachable。

这个报错通常出现在 Firejail 沙箱配置过严的情况下。Crush-Zh 需要访问taotoken.net，但默认的 Firejail profile 可能禁用了所有网络。检查~/.config/firejail/crush-zh.profile：

cat ~/.config/firejail/crush-zh.profile

如果看到net none，改成：

net eth0

或者更精确地只允许 TaoToken 的域名：

net eth0 dns 223.5.5.5

改完后重启 Crush-Zh。如果还是报错，临时禁用沙箱验证一下：

crush-zh --no-sandbox --prompt "test"

如果禁用沙箱后正常，说明问题在 Firejail 规则，逐条加回网络权限即可。

5.3 reading choices: unexpected end of JSON input

现象：Crush-Zh 返回error: reading choices: unexpected end of JSON input。

这个报错说明 TaoToken 返回的响应不是预期的 JSON 格式。最常见的原因是base_url配置错误。检查config.toml里的base_url：

# 错误写法 base_url = "https://taotoken.net/api/v1" # 正确写法 base_url = "https://taotoken.net/api"

TaoToken 的 API 路径不需要/v1后缀。如果你从其他工具的配置模板复制过来，很可能带了/v1，导致请求打到了不存在的路径，返回了 HTML 错误页而不是 JSON。

另一个可能原因是模型 ID 写错了，TaoToken 返回了{"error": "model not found"}，但 Crush-Zh 的解析逻辑期望choices字段，所以报了 JSON 解析错误。用 curl 确认模型 ID：

curl -s -X POST https://taotoken.net/api/chat/completions \ -H "Authorization: Bearer sk-你的Key" \ -H "Content-Type: application/json" \ -d '{"model": "你的模型ID", "messages": [{"role": "user", "content": "test"}]}'

如果返回model not found，去 TaoToken 文档里查正确的模型 ID。

5.4 OAuth 相关报错：token 过期或 scope 不足

现象：如果芯语 CAP 的某些应用使用了 OAuth 流程（比如 Browser Bridge 的某些集成），可能报OAuth token expired或insufficient scope。

芯语 CAP 的 OAuth token 存储在~/.config/xinyu-cap/oauth/目录下。检查 token 文件：

ls -la ~/.config/xinyu-cap/oauth/ cat ~/.config/xinyu-cap/oauth/token.json | grep expires_at

如果expires_at已经过期，删除 token 文件后重新触发授权流程：

rm ~/.config/xinyu-cap/oauth/token.json xinyu-cap --reauth

对于 scope 不足的问题，检查应用需要的权限范围。比如 Browser Bridge 需要browser_controlscope，如果 OAuth 应用注册时没勾选这个 scope，就会报错。在芯语 CAP 的 OAuth 管理页面重新配置即可。

5.5 MCP 服务发现失败：端口占用或注册表未更新

现象：mcp-registry.json里看不到 XinyuREG，或者last_seen时间很旧。

排查：

# 确认 XinyuREG 进程在跑 ps aux | grep xinyu-reg # 确认端口在监听 ss -tlnp | grep 18789 # 手动触发 MCP 扫描 xinyu-cap --scan-mcp --verbose

如果端口被占用，改 XinyuREG 的port配置，然后重启。如果进程在跑但端口没监听，检查mcp_server.enabled是否为true。如果注册表文件权限不对（比如被 root 拥有），芯语 CAP 守护进程可能写不进去：

chown $USER:$USER ~/.config/xinyu-cap/mcp-registry.json

6. 在龙芯上把 AI 工作流跑顺，关键在通道统一

芯语 CAP 解决的是“装得上”的问题，TaoToken 解决的是“连得通”的问题。两者结合后，龙芯平台上的 AI 工具链不再需要每个应用单独配 Key、单独处理网络策略。一个settings.json里的 TaoToken 配置，加上 MCP 的自动发现机制，就能让 Crush-Zh、XinyuREG、Browser Bridge 这些工具互相协作。

如果你准备在自己的龙芯机器上试，建议按这个顺序走：先拿 TaoToken 的 Key，用 curl 确认 API 直连；然后装芯语 CAP，写全局settings.json；接着配 Crush-Zh 的 TOML，验证模型调用；最后启动 XinyuREG，检查 MCP 注册表。每一步都有对应的验证命令，出问题就按第 5 章的报错对照排查。

TaoToken 的 API Key 在控制台创建，接入文档里有各工具的配置模板。模型对话页面可以快速验证 Key 和模型 ID 是否匹配。如果你打算长期在龙芯上跑编码 Agent，Coding Plan 的通道稳定性比按次调用更好，适合 Crush-Zh 这种高频交互的场景。