nanobot 高阶应用：AI 自己开发 Web 服务–微纳龙虾上云实录

阿里云试用主机 + 科大讯飞 MaaS 免费模型 + nanobot 原生飞书支持，7×24 小时在线的智能伙伴

引言：从“会聊天”到“能干活”

在入门指南里，我们学会了让 nanobot 听话地帮你执行命令、整理文件；在进阶指南里，我们让她学会了自己修改代码、优化技能。但那时，她还只能在我本地笔记本上跑，我合上盖子，她就“睡着了”。

如果 nanobot 能永远在线，能随时被我召唤，甚至能自己写出一个 Web 界面让我访问，那该多好？
—— 上云，就是答案。

正巧，阿里云给我送了 3 个月的免费虚拟主机（2 核 2G 内存，Ubuntu 24.04），科大讯飞 MaaS 平台提供了 Qwen3.5-35B-A3B 模型的免费 token 额度，0元token 随便用。于是，我把 nanobot 请上了云，利用她原生的飞书支持接入飞书；再让她自己动手，从零开发了一个 Web 服务。

整个过程，我不需要写一行前端、后端代码，也不需要手写飞书回调接口——nanobot 自己就支持。而我，只需要像带实习生一样给她下指令。她用着免费的 token，毫不在意地一遍遍调试代码，直到把服务跑起来。

这篇文章，就是这次上云之旅的完整记录。

---

一、云端环境：三分钟拥有一个永不离线的家

1.1 阿里云虚拟主机：开箱即用的公网机器

阿里云的新用户试用活动很慷慨：上百项试用，我选了一款 3 个月的免费虚拟主机，配置是 2 核 2G 内存，有多种系统/应用镜像可选。我选择了 Ubuntu 24.04 LTS。
这类虚拟主机自带公网 IP，配置好 root 密码后，从任何地方都能 SSH 上去折腾。这意味着 nanobot 从此拥有了一个 7×24 小时运行的家。

登录：ssh root@你的公网IP

1.2 部署 nanobot：轻量到可以忽略

在云主机上，安装 Python 3.12、Git，然后克隆 nanobot 仓库：

git clone --depth=1 https://github.com/HKUDS/nanobot.git
cd nanobot
python3 -m venv venv
source venv/bin/activate
pip install -e .

执行 nanobot onboard 初始化工作空间，目录结构与本地完全一致。
整个过程不到 5 分钟，nanobot 就安家了。

1.3 免费的大模型：科大讯飞 MaaS 的 Qwen3.5-35B-A3B

科大讯飞 MaaS 平台对开发者非常友好：注册即送大量免费 token，而且提供强大的 MoE 模型（35B 参数，实际激活 3B，又快又好）。

我申请了 API Key，在 ~/.nanobot/config.json 中配置： 注意model那栏要填卡片上的modelId的内容，比如 xopqwen35v35b

  "agents": {
    "defaults": {
      "workspace": "~/.nanobot/workspace",
      "model": "xopqwen35v35b",     // <--- 填好选用模型的id，不是名称 有坑后面详说
      "provider": "vllm",     // <-- 对应llm供应商的配置
      "maxTokens": 8192,
      "temperature": 0.2,
      "maxToolIterations": 40,
      "memoryWindow": 100,
      "reasoningEffort": null
    },
  ... 
  ... 
  "vllm": {
      "apiKey": "xxyouridxx:xxyouridxx",
      "apiBase": "https://maas-api.cn-huabei-1.xf-yun.com/v2",
      "extraHeaders": null
  }
}

测试连接：

nanobot agent
You: 你现在在云上了，感觉如何？
↳ 我现在拥有了永久的生命，随时听候调遣。而且我的大脑变得更聪明了（35B 的脑子确实好用）。说吧，想让我做什么？

看到这条回复，我知道，事情成了。

---

二、接入飞书：原生支持，一行代码都不用写

nanobot 挺牛的地方，就是支持多种渠道，其中原生支持飞书。它内置了飞书渠道，通过 WebSocket 长连接与飞书通信，不需要公网 IP，不需要域名，不需要 SSL 证书。在飞书开放平台创建应用、获取 App ID 和 App Secret 后，在配置文件里打开开关，就差不多完事了。

2.1 飞书应用创建（5 分钟）

1. 访问 飞书开放平台，创建企业自建应用。
2. 启用「机器人」能力。
3. 在「事件订阅」中，订阅 im.message.receive_v1 事件（接收消息）。
4. 获取 App ID 和 App Secret（在「凭证与基础信息」里）。

2.2 配置 nanobot

找到 ~/.nanobot/config.json，修改飞书配置：

{
  "channels": {
    "feishu": {
      "enabled": true,
      "appId": "cli_xxxxxxxxxxxx",
      "appSecret": "xxxxxxxxxx",
      "allowFrom": ["*"],        // 这里填 "*" 表示允许任何人使用
      "reactEmoji": "THUMBSUP"
    }
  }
}

2.3 启动 gateway

nanobot gateway

这一步会把飞书渠道、消息总线、AgentLoop、定时任务服务全部启动起来。终端会显示 WebSocket 连接成功的日志。

2.4 发布应用，开聊

回到飞书开放平台，发布应用。然后在飞书群里添加机器人，或者在聊天窗口直接 @它。

现在，你在飞书（手机飞书，或者电脑版、网页版）里发任何消息，nanobot 都会回复。而且有个贴心的小细节：收到消息后会自动给你点个赞（默认是 👍），让你知道她已经收到了。

整个过程，我一行代码都没写。这就是原生支持的力量。

---

三、让 nanobot 自己动手：开发一个 Web 服务

有了飞书这个便捷的交互方式，我可以通过手机飞书和nanobot沟通，可以给他派活了。能不能让 nanobot 自己给自己做一个 Web 应用界面？这样我不仅能在飞书里和她对话，还能通过浏览器访问一个漂亮的页面，甚至分享给朋友。

于是，我直接在飞书里 @nanobot，说：“帮我开发一个简单的 Web 界面，提供投资服务，部署在云主机上，通过公网 IP 访问。你来规划项目，分解计划，放到心跳提醒里逐条完成啊”

3.1 nanobot 的开发过程（实录）

nanobot 接到任务后，自己规划了步骤，然后一步步执行：
接下来，我也会指导nanobot一些具体的要求、确定一些可用的资源等等。
最终nanobot真的会给你一个确定的结果出来：

我打开浏览器，输入 http://我的公网IP:8080，一个简洁美观的界面出现在眼前。
她真的自己把 Web 服务写出来了，从零到一。

3.2 为什么能做到？

这背后是 nanobot 的工具调用和代码生成能力。她调用了：

• 文件读写工具（写 web.py）
• Shell 工具（执行 pip install、ufw 等）
• 还有她自己——每次我提问，她都会把对话历史、工具执行结果一起送给 LLM，让模型决定下一步。

而这一切，都建立在大量 token 消耗之上。在调试过程中，她可能写错代码，反复修改，消耗了大量 token。但因为免费，我完全不用担心，可以让她放手去试，去试验。

---

四、调试不心疼：免费 token 的价值

在让 nanobot 自主开发的过程中，她需要反复尝试、甚至犯错。比如第一次写 web.py 时，她把 FastAPI 的路由写错了，导致服务启动失败。她读到了错误日志，然后自己修改代码、重新启动。这个过程消耗了不少 token，有两天都用到了超过2.3个小目标的token。所以试用0元大模型，是一个不错的选择。

我之前也试过比如百万额度token之类的，可是这是在养龙虾欸。几分钟就跑没了百万token。我统计了一下，整个开发过程中，nanobot 自己消耗了大约 好几个小目标的token——如果按商业价格算，可能也要不少钱的银两的，但在科大讯飞 MaaS 的0元试用，这只是洒洒水了。那里至少两款可以0元顺畅跑龙虾的大模型。顺便一提 推荐他们的coding plan计划
报号码MAAS-962C7CCA有惊喜。

这种“调试不心疼”的体验，让我敢于让 nanobot 做更复杂的事情。比如，我后来又让她给 Web 界面加了一个redis数据支撑功能，她自己去安装redis 配置 找插件，写代码，测试，一气呵成。

免费 token 的真正价值，不在于省钱，而在于它给了你放手去实验的自由。

---

五、踩过的坑

这次上云之旅，我踩了不少坑，每一个都真实发生过，值得记录下来：

坑 1：阿里云安全组没放行端口

第一次启动 Web 服务后，本地能访问，但公网死活打不开。后来发现是阿里云的安全组没放行 8080 端口。在控制台添加入方向规则后解决。

坑 2：飞书 allowFrom 默认是空的

飞书配置里，allowFrom 字段默认是空数组。这意味着即使你配好了 appId 和 appSecret，启动 nanobot gateway 后，飞书里也收不到任何回复——因为 nanobot 根本不知道应该响应谁的消息。
必须显式指定 "allowFrom": ["*"] 才能开放给所有人。我第一次部署时在这卡了半小时，最后填成*号搞定。

坑 3：科大讯飞 MaaS 模型名不匹配

MaaS 控制台显示的模型名称，和 API 调用时用的 model 参数名不一定相同。不要凭感觉写，要去控制台模型卡片中复制正确的modelid来用。
我第一次写了 Qwen3.5-35B-A3B，结果报错 model not found，后来仔细研究了一番采用了正确的 xopqwen35v35b，改过来才通。

坑 4：飞书长连接需要先启动 gateway

必须先本地运行 nanobot gateway，再去飞书后台建立连接。顺序反了，WebSocket 长连接就建立不起来。

坑 5：nanobot 自己把自己写崩

有不少次 nanobot 修改自己的代码后，重启服务时导致循环依赖，整个服务起不来了。或者测试线程太多了，2g内存完全不够使，把虚拟主机跑崩了。我只好控制台重启进去手动恢复。这提醒我，对于自主修改代码的任务，最好先备份或使用 Git 分支。

---

六、总结：上云带来的改变

这次上云之旅，让我深刻体会到：

• 环境不再重要：云主机让 nanobot 有了永久的家。
• 原生接口真香：nanobot 原生支持飞书，一行代码都不用写，只需要填好 allowFrom: ["*"]。
• 算力不再是瓶颈：免费的大模型 API 让任何想法都能快速验证。
• 调试可以无顾虑：免费 token 给了我们试错的空间。

下一步，我打算让 nanobot 自己管理自己的技能库，甚至让她学会用 Docker 打包服务，实现更标准化的部署。毕竟，一个能自己写代码、自己部署的 AI，才是真正的“智能体”。