企业官网建设流程全解析

1. 云服务器上把 OpenClaw 学术智能体跑起来：从零到飞书可对话的完整路径

OpenClaw 是一个把大模型从“会聊天”推进到“会干活”的开源智能体框架，它最吸引我的地方是能挂载 MCP 工具链，让模型真正去检索文献、读写笔记、调用外部服务。而学术智能体，说白了就是给 OpenClaw 装上文献检索、笔记整理、任务推送这几件“科研外设”，再通过飞书机器人把它变成一个随时能对话的入口。适合谁？适合每天要读论文、整理综述、跟踪 arXiv 更新，又不想在多个工具之间来回切换的研究生和科研工作者。

我试过在本地笔记本上跑，风扇狂转不说，一关机智能体就“失联”。所以这次直接把它养在云服务器上，7×24 小时待命。整条链路的核心是：云服务器跑 OpenClaw + Qwen-Agent 调用链，通过 TaoToken 统一 Key 接入模型通道，再把飞书机器人作为前端交互层，MCP 工具链负责文献检索和笔记落盘。下面我会把环境变量、MCP 配置片段、飞书回调验证、Qwen-Agent 调用链路全部拆开讲，你照着复制就能跑通。

先明确几个关键概念，避免后面配置时懵。OpenClaw 本身是一个 Agent 运行时，它负责编排“思考—调用工具—再思考”的循环；Qwen-Agent 是阿里开源的一套 Agent 框架，这里我们用它来封装模型调用和工具注册；MCP 是 Model Context Protocol，你可以理解成智能体和外部工具之间的“USB 接口”，只要工具实现了 MCP 协议，智能体就能即插即用。飞书机器人则是把这一切包装成一个聊天窗口，你在飞书里发一句话，消息通过回调打到云服务器，OpenClaw 处理完再把结果推回飞书。

为什么要在云上养？三个现实原因。第一，飞书回调需要一个公网可达的 HTTPS 地址，本地机器没有固定公网 IP，做内网穿透又麻烦又不稳定。第二，文献检索和定时任务推送需要长期在线，云服务器天然满足。第三，MCP 工具链里有些工具依赖较重的 Python 环境，云服务器可以一次性配好，不用每台设备重复折腾。选一台 2 核 4G 的轻量云服务器就够起步，系统用 Ubuntu 22.04，后面所有命令都基于这个环境。

在动手之前，先把 TaoToken 的 Key 准备好。TaoToken 在这里扮演的是统一模型通道的角色，OpenClaw 和 Qwen-Agent 都通过它来调用底层模型，这样你不需要在多个模型供应商之间反复切换 Key。官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api 。注册后在控制台创建 API Key，模型 ID 选你需要的对话模型即可。这个 Key 后面会写进环境变量，OpenClaw 和 Qwen-Agent 共用同一个 Base URL 和 Key，这就是“统一 Key”的意义——一处配置，两处生效。

2. TaoToken 前置准备与云服务器基础环境搭建：统一 Key 怎么配才不踩坑

这一节把前置条件一次性说清楚，包括 TaoToken 的 Key 获取、云服务器基础依赖安装、Python 虚拟环境创建。很多人卡在第一步不是因为难，而是因为环境变量写错位置，导致后面 OpenClaw 读不到 Key，报 401 还找不到原因。我踩过的坑是：把 Key 写进了.bashrc，但 OpenClaw 是用 systemd 拉起的，systemd 不读.bashrc，结果一直 401。所以下面我会把环境变量的写法讲透。

先登录 TaoToken 控制台，在 API Keys 页面创建一个新 Key。创建时注意两点：一是给 Key 起个能认出来的名字，比如openclaw-academic，方便后面轮换；二是创建后立刻复制，页面刷新后就看不到完整 Key 了。模型 ID 方面，学术场景建议选长上下文、支持工具调用的对话模型，具体在控制台的模型列表里能看到可用项。Base URL 统一用https://taotoken.net/api，注意不要加 UTM 参数，API 调用只需要干净的地址。

拿到 Key 之后，登录云服务器，先装基础依赖。Ubuntu 22.04 下执行：

sudo apt update sudo apt install -y python3.10 python3.10-venv python3-pip git curl nginx

Python 版本建议 3.10 及以上，因为 Qwen-Agent 和部分 MCP 工具对类型注解有要求。装完确认版本：

python3.10 --version

接下来创建项目目录和虚拟环境。我习惯把智能体放在/opt/openclaw下，权限清晰：

sudo mkdir -p /opt/openclaw sudo chown $USER:$USER /opt/openclaw cd /opt/openclaw python3.10 -m venv venv source venv/bin/activate

虚拟环境激活后，安装 OpenClaw 和 Qwen-Agent。具体包名以官方仓库为准，这里给出通用安装方式：

pip install --upgrade pip pip install openclaw qwen-agent

如果 OpenClaw 是从源码安装，就 clone 仓库后pip install -e .。安装完成后，用pip list | grep -i claw确认装上了。

现在配置环境变量。关键点：不要只写进.bashrc，因为后面飞书回调服务可能用 systemd 或 supervisor 拉起。我推荐写一个独立的环境文件/opt/openclaw/.env，内容如下：

# /opt/openclaw/.env TAOTOKEN_API_KEY=sk-你的实际Key TAOTOKEN_BASE_URL=https://taotoken.net/api OPENCLAW_MODEL_ID=你的模型ID FEISHU_APP_ID=cli_xxxxxxxx FEISHU_APP_SECRET=xxxxxxxxxxxxxxxx FEISHU_VERIFICATION_TOKEN=xxxxxxxxxxxxxxxx FEISHU_ENCRYPT_KEY=xxxxxxxxxxxxxxxx

这个.env文件权限要收紧：

chmod 600 /opt/openclaw/.env

然后在启动脚本里用set -a; source /opt/openclaw/.env; set +a把变量导出。如果你用 systemd，就在 service 文件里写EnvironmentFile=/opt/openclaw/.env。这样无论怎么拉起进程，Key 都能读到。这一步做完，TaoToken 的前置就齐了，后面 OpenClaw 和 Qwen-Agent 都从这个.env读配置。

顺便说下飞书那边的准备。去飞书开放平台创建企业自建应用，拿到 App ID 和 App Secret，开启机器人能力，事件订阅里填你的回调地址。Verification Token 和 Encrypt Key 在事件订阅页面能看到，填进.env。回调地址需要 HTTPS，所以后面要用 Nginx 做反向代理并配证书。这些先准备好，下一节直接写配置。

3. 可复制的 OpenClaw + MCP + 飞书配置片段：JSON 与 TOML 一次写对

这一节是全文最“硬”的部分，直接给可复制的配置。OpenClaw 的配置文件通常是 TOML 或 JSON，MCP 工具链单独一个 JSON，飞书回调服务再一个配置。我会把路径和字段都写清楚，你按自己的实际路径改。注意：所有涉及 Key 的地方都用环境变量引用，不要把明文 Key 写进配置文件，这是安全底线。

先看 OpenClaw 主配置。假设路径是/opt/openclaw/config/openclaw.toml：

# /opt/openclaw/config/openclaw.toml [model] provider = "openai-compatible" base_url = "${TAOTOKEN_BASE_URL}" api_key = "${TAOTOKEN_API_KEY}" model_id = "${OPENCLAW_MODEL_ID}" timeout = 120 max_retries = 3 [agent] name = "academic-claw" system_prompt = """ 你是一名学术研究助理，擅长文献检索、综述整理和任务跟踪。 当用户提出文献相关问题时，优先调用 mcp__arxiv_search 和 mcp__semantic_scholar 工具。 整理完的笔记通过 mcp__note_writer 落盘到 /opt/openclaw/notes 目录。 """ max_turns = 12 tool_choice = "auto" [mcp] config_path = "/opt/openclaw/config/mcp_servers.json" enabled = true [feishu] app_id = "${FEISHU_APP_ID}" app_secret = "${FEISHU_APP_SECRET}" verification_token = "${FEISHU_VERIFICATION_TOKEN}" encrypt_key = "${FEISHU_ENCRYPT_KEY}" callback_path = "/feishu/callback"

这里provider用openai-compatible，因为 TaoToken 的 API 是 OpenAI 兼容格式，Base URL 指向https://taotoken.net/api即可。model_id从环境变量读，换模型不用改配置文件。

再看 MCP 工具链配置，路径/opt/openclaw/config/mcp_servers.json：

{ "mcpServers": { "arxiv_search": { "command": "python3", "args": ["-m", "mcp_arxiv_server"], "env": { "ARXIV_MAX_RESULTS": "10" } }, "semantic_scholar": { "command": "python3", "args": ["-m", "mcp_semantic_scholar"], "env": { "S2_API_KEY": "${S2_API_KEY}" } }, "note_writer": { "command": "python3", "args": ["-m", "mcp_note_writer"], "env": { "NOTE_DIR": "/opt/openclaw/notes" } } } }

这个 JSON 里三个 MCP 服务分别负责 arXiv 检索、Semantic Scholar 检索、笔记落盘。command和args按你实际安装的 MCP 包名改。如果某个工具暂时没装，先注释掉对应块，OpenClaw 启动时会跳过不可用的 MCP 服务，不会整体崩掉。

飞书回调服务我建议单独写一个轻量 Flask 应用，路径/opt/openclaw/feishu_bridge.py，核心逻辑是接收飞书事件、调用 OpenClaw、把结果推回飞书。配置部分从.env读，不重复写。启动方式：

cd /opt/openclaw source venv/bin/activate set -a; source .env; set +a python feishu_bridge.py

Nginx 反向代理配置，路径/etc/nginx/sites-available/openclaw：

server { listen 443 ssl; server_name your-domain.com; ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem; location /feishu/callback { proxy_pass http://127.0.0.1:8000/feishu/callback; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

证书用 certbot 申请，sudo certbot --nginx -d your-domain.com一条命令搞定。配完sudo nginx -t检查语法，sudo systemctl reload nginx生效。

这里要强调一个容易忽略的点：飞书回调要求 3 秒内响应，否则会重试。所以feishu_bridge.py收到事件后应该先返回 200，再把耗时任务丢到后台线程或队列里处理，处理完通过飞书的消息 API 主动推送。如果你直接在回调里同步跑 OpenClaw，大概率超时，飞书会重复推送同一条消息，智能体就会重复回答。这个坑我在实测时踩过，后来改成异步才稳定。

4. 验证请求与成功结果：飞书回调 + Qwen-Agent 调用链路实测

配置写完，怎么确认真的通了？分三步验证：先验证 TaoToken 通道能调通模型，再验证 Qwen-Agent 调用链能跑，最后验证飞书回调能收到消息并返回结果。每一步都有明确的成功标志，照着看就行。

第一步，验证 TaoToken 通道。写一个最小 Python 脚本/opt/openclaw/test_taotoken.py：

import os from openai import OpenAI client = OpenAI( api_key=os.environ["TAOTOKEN_API_KEY"], base_url=os.environ["TAOTOKEN_BASE_URL"], ) resp = client.chat.completions.create( model=os.environ["OPENCLAW_MODEL_ID"], messages=[{"role": "user", "content": "用一句话说明什么是MCP协议"}], ) print(resp.choices[0].message.content)

运行：

cd /opt/openclaw source venv/bin/activate set -a; source .env; set +a python test_taotoken.py

成功标志：终端打印出一句关于 MCP 协议的解释。如果报 401，说明 Key 或 Base URL 有问题；如果报model not found，说明模型 ID 写错了。这一步通了，说明 TaoToken 统一 Key 生效。

第二步，验证 Qwen-Agent 调用链。写/opt/openclaw/test_qwen_agent.py：

import os from qwen_agent.agents import Assistant llm_cfg = { "model": os.environ["OPENCLAW_MODEL_ID"], "model_server": os.environ["TAOTOKEN_BASE_URL"], "api_key": os.environ["TAOTOKEN_API_KEY"], } bot = Assistant(llm=llm_cfg, system_message="你是一名学术助理") messages = [{"role": "user", "content": "帮我列出三个关于大模型智能体的研究方向"}] for chunk in bot.run(messages): print(chunk)

运行后成功标志：终端流式打印出三个研究方向。这里注意model_server填的是 TaoToken 的 Base URL，Qwen-Agent 会把它当成 OpenAI 兼容端点来调用。如果报reading choices之类的解析错误，通常是返回格式和预期不符，检查 Base URL 是否多了斜杠或路径。

第三步，验证飞书回调。先在飞书开放平台把事件订阅的回调地址填成https://your-domain.com/feishu/callback，然后点“验证”。飞书会发一个url_verification事件，你的服务需要原样返回challenge值。成功标志：飞书页面提示“验证成功”。然后给机器人发一条消息，比如“帮我检索 transformer 高效注意力”，成功标志：飞书里收到智能体的回复，同时服务器日志里能看到 MCP 工具被调用的记录。

实测下来，整条链路跑通后，你在飞书里发一句话，背后发生的事是：飞书回调打到 Nginx，转发给feishu_bridge.py，bridge 调用 OpenClaw，OpenClaw 通过 TaoToken 通道请求模型，模型决定调用mcp__arxiv_search，MCP 服务返回检索结果，模型整理后返回，bridge 再通过飞书 API 推回消息。整个过程通常 5 到 15 秒，取决于检索工具的网络延迟。

如果想让智能体“持续进化”，可以在 OpenClaw 的 system prompt 里加一条：每次整理完笔记后，把本次用到的检索关键词和结论摘要追加到/opt/openclaw/notes/evolution.log。这样日积月累，你的智能体就有了自己的“科研记忆”，下次检索时可以先读这个日志，避免重复劳动。这个技巧不需要额外工具，用note_writer就能实现。

5. 本篇常见报错排查：401、local proxy failed、reading choices、OAuth 逐个击破

这一节把最容易遇到的四类报错拆开讲，每个都给出真实报错文本和排查路径。这些是我在部署过程中实际碰到并解决的，你遇到时可以直接对照。

第一类：401 Unauthorized。报错文本通常是：

openai.AuthenticationError: Error code: 401 - {'error': {'message': 'Invalid API key'}}

排查顺序：先确认.env里TAOTOKEN_API_KEY没有多余空格或换行，用echo $TAOTOKEN_API_KEY | wc -c看长度是否合理。再确认进程真的读到了环境变量，在 Python 里print(os.environ.get("TAOTOKEN_API_KEY")[:8])看前几位对不对。如果用的是 systemd，检查 service 文件里有没有EnvironmentFile=/opt/openclaw/.env。最常见的原因是 Key 写进了.bashrc但进程不是从交互式 shell 拉起的，导致读不到。

第二类：local proxy failed。报错文本类似：

openai.APIConnectionError: Connection error: local proxy failed

这个报错通常和网络环境有关。先确认服务器能正常访问https://taotoken.net/api，用curl -I https://taotoken.net/api看返回状态码。如果 curl 也不通，检查服务器 DNS 和出网策略。如果 curl 通但 Python 不通，检查是否有HTTP_PROXY/HTTPS_PROXY环境变量被意外设置，用env | grep -i proxy查一下，有的话 unset 掉。注意：这里说的是排查本机代理环境变量，不是让你去配代理，方向别搞反。

第三类：reading choices。报错文本：

KeyError: 'choices'

或者

TypeError: 'NoneType' object is not subscriptable

这个通常出现在 Qwen-Agent 调用链里，原因是返回的 JSON 结构不符合 OpenAI 格式预期。排查：先用第 4 节的test_taotoken.py确认原始返回里有choices字段。如果原始返回正常但 Qwen-Agent 报错，检查model_server是否写成了https://taotoken.net/api/（末尾多了斜杠），有些客户端会把斜杠拼成双斜杠导致路由异常。改成不带末尾斜杠的https://taotoken.net/api再试。

第四类：OAuth 相关报错。如果你在飞书侧看到：

OAuth token invalid or expired

或者 OpenClaw 日志里出现OAuth字样，先区分是飞书 OAuth 还是模型侧 OAuth。飞书侧检查 App ID / App Secret 是否和开放平台一致，tenant_access_token是否过期（一般两小时）。模型侧如果出现 OAuth 报错，检查 TaoToken 的 Key 是否被禁用或额度耗尽，去控制台看 Key 状态。另外，如果你用了 Codex 的auth.json做本地认证，注意auth.json里的字段和 TaoToken 的 Key 是两套体系，不要混用。Codex 场景下三件套是 Base URL + Key + Model ID，分别对应https://taotoken.net/api、你的 TaoToken Key、控制台里的模型 ID，写全这三项才能通。

再补充一个飞书回调特有的坑：如果飞书提示“回调地址校验失败”，先确认 Nginx 转发到了正确的端口，再确认feishu_bridge.py对url_verification事件返回了{"challenge": "原值"}。如果返回了但飞书仍报错，检查响应头Content-Type是不是application/json。这些细节看起来小，但卡住的时候很费时间。

6. 把学术智能体养成长期助手：接入文档、模型对话与 Coding Plan 的分流选择

链路跑通只是开始，真正让这只 OpenClaw 学术智能体“持续进化”的，是把它接入日常科研流。这里给几条实用建议，以及不同需求下该走哪条 TaoToken 通道。

如果你主要想验证模型效果、快速试不同模型对学术问题的回答质量，直接用模型对话入口最方便，地址是 https://taotoken.net/api ，在控制台里切换模型 ID 就能对比。如果你需要长期跑编码类任务，比如让智能体帮你写数据分析脚本、调 MCP 工具的实现代码，那 Coding Plan 更合适，地址是 https://taotoken.net/coding-plan 。如果你要管理多个 Key、查看调用量、做额度控制，去控制台 https://taotoken.net/console 。Key 的创建和轮换在 https://taotoken.net/api-keys 。接入文档在 https://taotoken.net/doc ，里面有各语言的调用示例。Claude Code 相关的接入说明在 https://taotoken.net/claude-code-anthropic 。

日常使用上，我建议给智能体设几个固定“技能”。第一个是每日 arXiv 推送：写一个 cron 任务，每天早上 8 点让 OpenClaw 检索你关注的关键词，把结果通过飞书推给你。第二个是笔记自动归档：每次对话结束后，让note_writer把结论追加到当天的笔记文件，文件名用日期，方便回溯。第三个是综述草稿生成：积累一段时间后，让智能体读取笔记目录，生成一份带引用的综述初稿。这三个技能都不需要改 OpenClaw 源码，靠 system prompt 和 MCP 工具组合就能实现。

关于“持续进化”，核心思路是让智能体有记忆。OpenClaw 本身支持多轮对话，但跨会话的记忆需要你自己落盘。我的做法是在/opt/openclaw/notes下维护一个memory.md，每次对话结束后把关键结论追加进去，下次启动时在 system prompt 里用note_reader工具读进来。这样智能体每次回答都会参考历史积累，越用越懂你的研究方向。这个机制不复杂，但效果很明显。

最后提醒几个运维细节。云服务器记得开自动快照，避免配置丢失。.env文件定期轮换 Key，轮换时先加新 Key 再删旧 Key，避免服务中断。飞书机器人的权限按最小必要原则开，只开消息收发和事件订阅，不要开通讯录等无关权限。日志方面，建议把 OpenClaw 和feishu_bridge.py的输出都重定向到/var/log/openclaw/下，按天切割，方便排查。

这套方案跑下来，你得到的不是一个“玩具”，而是一个真正能帮你读论文、整笔记、推任务的云端科研助理。它不需要你时刻盯着，飞书里发一句话就能用，MCP 工具链还能按需扩展。先把基础链路跑通，再慢慢加技能，这只 OpenClaw 会越养越顺手。