附录：环境预检¶

这份附录不引入新概念，只用于确认本机、账号、凭据和部署边界已经准备好。按本次目标检查即可，不必一次安装所有组件。

先判断：你准备走到哪一步¶

目标	最少需要准备
跑通本地 CLI	终端、Python 3、虚拟环境、一个可用 Provider、环境变量中的凭据、可调用的模型
跟做 Skill	在 CLI 基础上，准备示例实际使用的 `curl`、`python3` 等命令
接 Telegram	在 CLI 基础上，准备账号、Bot Token，以及显式 `allowFrom` 或配对方案
长期运行 Gateway	确认状态目录持久化、服务管理器、密钥注入和日志位置
使用 Docker	可用的 Docker Engine/Compose、v0.2.2 源码、两个端口和持久化挂载目录
跟做进阶营	在 CLI 基础上，具备函数、类和 `async`/`await` 等 Python 基础

只想先跑起来时，不要同时调试 Telegram、Docker、systemd 和 Hero 示例。

先确认你能：

python3 --version
python3 -c 'import venv; print("venv 模块可用")'

如果第二条命令报错，在 Debian/Ubuntu 上安装与当前 Python 对应的 python3-venv 后再继续。不要为了测试创建一个随后用递归删除命令清理的目录；第 1 章会直接创建教程真正使用的虚拟环境。

第一次配置前确认：

检查环境变量是否存在时只判断长度，不打印值。把示例变量名替换为自己的名字：

test -n "${PROVIDER_API_KEY:-}" && echo "Provider 凭据已设置" || echo "Provider 凭据未设置"

只检查准备跟做的 Skill 实际声明的依赖：

command -v curl
command -v python3

命令存在不代表网络 API 一定可用。真实天气、汇率和模型调用属于人工冒烟测试，不应放进 CI。

不要临时使用 ["*"] 来寻找自己的 ID。接平台前应先通过：

nanobot agent -m "本地预检"
nanobot plugins list
nanobot channels status

长期运行前确认 nanobot status 显示的是预期配置与工作区，并选择一种托管方式：

安装系统服务前必须先预览：

nanobot gateway install-service --dry-run

确认生成内容使用当前 Python、前台 Gateway、正确工作区和非 root 用户。系统服务不会自动保存当前 shell 的 Token；先设计操作系统级的密钥注入方式。

本仓库约定所有 Docker 命令都通过 sudo 执行：

sudo docker version
sudo docker compose version

继续前确认：

从固定提交 e2e75c913f3524d4bc5b23487a4eed5329eef182 的源码和 Dockerfile 构建，而不是默认信任第三方镜像。
宿主机 ~/.nanobot 挂载到容器 /home/nanobot/.nanobot，使配置、工作区、会话和日志持久化。
官方镜像以 nanobot（UID 1000）运行；挂载目录可由该用户读写，但不把容器改成 root。
容器内 Gateway/WebSocket 监听 0.0.0.0 才能接受端口转发；宿主机默认只发布到 127.0.0.1。
18790 是健康检查端口，8765 才是 WebUI；WebUI 使用 tokenIssueSecret 或 Token 认证。
环境文件权限为 600，且不在项目目录或镜像构建上下文中。