插座学院第一次意识到 nanobot 这类工具的价值，是在我同时打开三个终端窗口调试 Ollama 的时候。一个窗口跑着模型服务，一个用 curl 手搓接口请求，还有一个开着网页聊天界面，想要切换模型还得反复加载页面。这种状态持续了两周，我决定认真找一款能把本地大模型能力统一管起来的工具。nanobot 就是在这个背景下进入我视线的项目：它以 Ollama 为推理后端，用事件驱动的方式把命令行、WebUI、Slack、Discord、Telegram 等渠道统一到同一套配置体系里。这篇文章我会从零开始记录从安装到深度使用的全过程，包括踩过的坑和最终沉淀的配置模板，适合正在使用 Ollama、想给它加一个统一入口的开发者或自托管爱好者参考。
1. 先搞明白 nanobot 解决了什么问题
1.1 从“一个模型一个界面”到“多模型统一入口”
Ollama 本身只是模型运行时，它把 llama.cpp 的推理能力封装成了 HTTP API，并不带像样的前端和交互管理。你直接面对的是一个 11434 端口和一堆 JSON 请求，每次想跟模型聊两句都得手动拼请求体。而 nanobot 做的，是把这层 API 包装成一个个可交互的入口：你在终端里敲一句话，它在聊天群里回一句话，你在浏览器里打开页面，它给你一个类似 ChatGPT 的对话界面。底层是同一个模型，顶层却是完全不同的交互方式。
这个定位想清楚之后，很多选择就顺理成章了。nanobot 是事件驱动的，内部把每一次交互抽象成一个 event：谁来、说了什么、在哪个 room、来自哪个渠道。不管消息来自 Slack 还是命令行，进入 nanobot 后都走同一条处理管线——模型推理、上下文管理、流式回传。这种设计的最大好处是，接入新渠道时不需要改任何模型层的逻辑，加一个适配器就行。我后来接入 Telegram 只花了十几分钟，就是这个架构带来的直接收益。
对比一下常见的替代方案。Open WebUI 是很多人首选的 Ollama 前端，它确实漂亮，功能也全，但它本质上是一个网页应用，无法把对话延伸到 Slack 或 Telegram。其他方案比如直接写 Python 脚本调用 Ollama API，灵活性高但工程成本也高，多平台时每个平台都要单独开发。nanobot 的差异化在于：它把“模型推理”和“接入渠道”彻底解耦，你只需要维护一份配置文件，就能让多个渠道同时工作。
| 方案 | 支持渠道 | 多模型切换 | 工具调用 | 配置复杂度 |
|---|---|---|---|---|
| Ollama 原生 CLI | 命令行 | 手动换参数 | 无 | 低 |
| Open WebUI | Web | 支持 | 部分支持 | 中 |
| 自写脚本 | 取决于实现 | 需自行实现 | 需自行实现 | 高 |
| nanobot | CLI/Web/IM | 对话内指令切换 | MCP | 中低 |
1.2 事件驱动的内部机制：一个脑，多张口
前面提到事件驱动，这里稍微展开一下。如果你用过消息队列或者事件总线，对这个概念应该很熟悉。nanobot 里每条消息都封装成一个结构体，包含发送者（from）、接收对象（to）、消息文本（text）、所在房间（room）和渠道类型等字段。这个结构体在整个处理链路中流转，不同的插件或处理器可以订阅自己感兴趣的事件类型。
举个例子，当你在 Slack 频道里 @nanobot 问它“今天的代码 review 有什么建议”，这条消息会经过这样一条链路：
- Slack 适配器收到消息，转换成统一 event 格式
- 事件总线把 event 分发给会话管理模块，取出该 namespace 的历史上下文
- 上下文和用户消息一起拼装成 prompt，发送给 Ollama API
- 模型返回流式结果，事件总线把每个 chunk 转发回 Slack 适配器
- Slack 适配器把消息渲染成 Slack 的 markdown 格式并回复
这段链路里，模型推理和 Slack 适配是解耦的，中间只通过事件结构体通信。所以你在 WebUI 里问同样的问题，走的是完全相同的 2-4 步，只是第 1 步和第 5 步的适配器不同。这也是为什么 nanobot 支持多平台却不需要每个平台重写一套模型调用逻辑的根本原因。
1.3 什么场景下你才真的需要 nanobot
我不是说所有人都应该用 nanobot。如果你只是偶尔在本地跑个模型玩，直接 ollama run llama3.2 就够了。但如果你遇到下面这些情况，nanobot 能帮你省下大量重复劳动：
- 多设备访问：你希望在公司电脑、家里笔记本、手机上都能访问同一个本地模型入口，而不需要每台设备都装客户端
- 团队共享：一个小组用同一台 GPU 服务器跑模型，但每个人想要独立的会话记录和上下文
- 聊天工具重度用户：你的日常沟通都在 Slack/Telegram/Discord，希望直接把 AI 拉进现有聊天流，而不是切到浏览器里单独对话
- 自动化扩展需求：未来想让模型具备网页搜索、查数据库、操作文件等工具能力，需要一套标准化的工具调用协议
我当时主要中了前两条，所以决定认真调研并搭建。现在跑了几个月，已经稳定接入团队内部的 Telegram 群和 WebUI，日常文档总结、代码解释、会议纪要整理都在用。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备：从安装 Ollama 到拿到 nanobot 可执行文件
2.1 Ollama 的安装与模型选择
Ollama 的安装其实很无脑。Linux 上一行 curl -fsSL https://ollama.com/install.sh | sh，macOS 上直接下载安装包。装完先别急着拉模型，先执行 ollama serve 确认服务正常，然后 ollama list 看一眼。我在 Ubuntu 22.04 上踩过一个小坑：安装脚本会自动注册 systemd 服务，但如果你的机器是 WSL1，systemd 不生效，就得手动用 ollama serve 前台跑。
模型选择方面，我建议首次别拉 70B 级别的。先跑小模型把链路打通，再逐步升级。中文场景我推荐 qwen2.5 系列，写代码用 deepseek-coder，日常快速问答用 llama3.1 或 gemma2 的小参数版本也足够。拉模型的命令：
bash复制ollama pull qwen2.5:7b
ollama pull deepseek-coder:6.7b
查看本地已有的模型用 ollama list，确认模型服务正常用 curl http://localhost:11434/api/tags，能看到模型列表 JSON 就说明 Ollama API 通了。这一步务必先验，因为后面 nanobot 连不上 Ollama 的时候，很多人第一反应是 nanobot 的问题，实际排查下来八成是 Ollama 服务没起来。
2.2 三种安装 nanobot 的方式，以及我推荐哪一种
nanobot 的安装方式，我实际用过的有三种：
第一种，从 GitHub Releases 下载预编译二进制。 最简单，nanobot 是纯 Go 单文件，下载解压就能跑。注意下载后先 chmod +x，然后放到 /usr/local/bin 下，这样任何目录都能直接执行。
第二种，go install。 前提是机器上有 Go 1.22+ 环境：
bash复制go install github.com/bensam123/nanobot@latest
这条命令会把编译好的二进制放到 $GOPATH/bin 或者 $HOME/go/bin，如果你 shell 的 PATH 没配好，可能会出现“命令找不到”的情况。
第三种，Docker 容器。 适合想隔离环境、用 docker-compose 管理的人。但要注意，Docker 方式多了一层网络转发，容器要能访问宿主机的 Ollama 服务。如果你是 Docker 新手，我不建议一上来就走这条路，端口映射和网络模式会让你多排查不少环节。
我自己最爱的是第一种二进制方案。原因很简单：它是一个小型静态编译文件，没有 Python 依赖、没有 node_modules，放到 /usr/local/bin 就不会再有别的坑。因为 Go 编译出来的二进制把运行环境都打包进去了，换机器就是拷贝文件的事。
2.3 第一份配置文件的完整解读
nanobot 读取一个 YAML 文件，常见的默认文件名是 nanobot.yaml。第一份最简配置长这样：
yaml复制ollama:
endpoint: http://localhost:11434
model: qwen2.5:7b
cli:
enabled: true
web:
enabled: true
listen_addr: ":8080"
namespace: default
这里 namespace 是关键概念，它像一个聊天房间，不同 namespace 的会话互相隔离。多个团队成员共用时，可以每人一个 namespace，互不干扰。endpoint 指向 Ollama 服务的地址，如果 nanobot 和 Ollama 在同一台机器，默认地址就行；如果分开部署，要填 Ollama 所在机器的 IP。
listen_addr 是 WebUI 的监听地址。:8080 表示监听所有网卡接口，如果你只想本机访问，改成 127.0.0.1:8080 会更安全。我第一次部署时直接用了默认值，结果局域网里其他机器也能访问，模型完全裸奔，吓得我赶紧加了访问限制。
3. 跑通第一个对话：命令行、WebUI 和流式输出的完整流程
3.1 命令行模式：三分钟验证链路
配置写好了，先启动 Ollama 服务，再启动 nanobot：
bash复制systemctl start ollama # 或者直接 ollama serve
nanobot -config nanobot.yaml
看到日志输出类似 nanobot listening on :8080，说明服务起来了。如果你在配置里启用了 CLI 模式，直接执行 nanobot chat 就能进入对话界面。这个模式本质上是把终端变成一个聊天客户端，支持流式输出，输入 /help 可以看到所有可用指令。
为什么要先命令行模式？因为它的依赖最少，不需要处理 Web 端口、聊天平台回调这些外部因素，纯粹验证 nanobot 到 Ollama 的链路是否通畅。如果命令行模式能正常对话，就说明模型推理和事件驱动的主干没问题，后面接任何渠道都只是适配器的问题。
我第一次测试时，输入“你好”，模型在终端里一个字一个字地蹦出回复，那种流式输出的体验和 ChatGPT 网页版非常像。当时用的 qwen2.5:7b 在 M 系列 MacBook 上跑，实测速度大概每秒 25-30 token，响应还是挺跟手的。
3.2 WebUI 和浏览器对话的细节
命令行模式验证通过后，打开浏览器访问 http://localhost:8080，会看到一个极简的聊天界面。这个页面左侧通常有 namespace 选择器，中间是消息流，底部是输入框，整体风格和主流的 AI 聊天界面没什么区别。
WebUI 有一个特性让我印象深刻——你可以在同一个界面里输入斜杠指令切换模型。比如当前模型是 qwen2.5:7b，你想临时换一个来对比效果，直接输入：
code复制/model llama3.2:3b
回车之后模型就切过来了。如果想清空当前会话上下文，输入 /clear。这类斜杠指令是 nanobot 的交互核心，入门阶段至少要把这几个记住：/model 切换模型、/namespace 切换会话空间、/clear 清空上下文、/help 查看全部指令。
这里有个容易忽略的细节：WebUI 的每个浏览器标签页通常会绑定一个 namespace。很多人在两个标签页里同时聊不同话题，以为上下文是隔离的，结果发现互相串了——大概率是两个标签页在同一个 namespace 里。解决方法是给不同话题分配不同的 namespace，或者聊完一个话题主动 /clear。
3.3 流式输出与上下文管理的实测感受
流式输出的实现，在代码层面是 Ollama API 的 stream: true 参数。nanobot 向 Ollama 发起请求时带上这个参数，模型返回的不是一个完整的 JSON，而是一串持续推送的分块数据，每个分块包含一小段增量文本。nanobot 拿到一个 chunk 就通过 WebSocket 或 HTTP 流推送到前端，于是用户看到的就是打字机效果。
这种流式体验不只是视觉上的爽快，更重要的是感知延迟大幅降低。模型完整生成可能需要 20 秒，但用户第一次看到文字可能只需 1-2 秒。对于交互型应用来说，这是质的差别。
上下文管理方面，默认情况下每次对话都会携带之前的历史消息。这意味着上下文越长，每次请求的 prompt 就越大，推理耗时和显存占用也随之增加。我在 8B 模型上测试过，把上下文窗口控制在 4096 token 左右是性价比比较高的区间，既能记住足够多的前文，又不会让单次请求慢到无法接受。超过这个长度，可以考虑用摘要的方式压缩历史，或者直接清空。
4. 接入 Slack、Discord 与 Telegram：多渠道统一的关键配置
4.1 Slack 接入：从创建应用到填 token 的完整过程
Slack 接入是我最先尝试的，原因是团队日常沟通都在 Slack。完整的配置过程如下：
第一步，创建应用。 打开 api.slack.com，点击“Create New App”，选择“From scratch”，输入应用名称并选择目标工作区。创建完成后，进入应用管理页面。
第二步，添加 Bot User。 在应用的“Bot Users”页面点击“Add Bot User”，设置显示名称和默认名称。创建完成后，在“OAuth & Permissions”页面点击“Install to Workspace”，授权后会生成 Bot Token，形如 xoxb- 开头的一串字符。
第三步，订阅消息事件。 在“Event Subscriptions”页面启用事件订阅，设置 Request URL 为 nanobot 暴露的回调地址。然后订阅 message.channels 事件，这样机器人才能收到频道消息。
第四步，写入 nanobot 配置。 把 Bot Token 填进配置文件：
yaml复制slack:
token: xoxb-你的token
这一套流程里最大的坑是 Request URL 的问题。Slack 要求回调地址必须是公网可访问的 HTTPS 地址，本地开发环境没法直接满足。我当时的解决办法是优先考虑 Slack 的 Socket Mode——如果 nanobot 支持的话，这种方式不需要暴露公网回调端口，机器人和 Slack 之间走长连接，省去了内网穿透这类操作。建议你在配置前先确认一下你用的 nanobot 版本是否支持 Socket Mode，支持的话会省掉很多网络配置的麻烦。
4.2 Discord 与 Telegram 的配置差异
Discord 的接入相对更简单。去 Discord Developer Portal 创建一个应用，进入“Bot”页面点击“Add Bot”，然后复制 token。有一个关键开关必须打开：MESSAGE CONTENT INTENT。这个开关在 Bot 页面的“Privileged Gateway Intents”区域，默认是关闭的。如果不开，机器人会收不到任何消息内容，表现形式就是——机器人“失聪”了，你发消息它毫无反应。我第一次配置时就栽在这里，排查了十几分钟才发现是这个 intent 没开。
Telegram 的接入是最省心的。去找 BotFather 创建机器人，拿到形如 123456789:ABC... 的 token，填进配置：
yaml复制telegram:
token: 123456789:ABC...
Telegram 走的是长轮询模式，机器人主动向 Telegram 服务器拉取消息，所以不需要公网回调地址，也没有端口暴露的问题。这一点比 Slack 和 Discord 的 Webhook 模式省心很多，尤其适合部署在内网环境里的场景。
4.3 多渠道会话隔离与权限控制的经验
多渠道共存时，nanobot 的 namespace 机制非常有用。每个渠道的每个 room 都会被映射到一个独立的 namespace。Slack 的 #general 频道和 Telegram 的某个群聊，天然就是两个隔离的会话空间。你在 Slack 里问模型一堆代码问题，跑到 Telegram 里问一句生活琐事，两边上下文不会互相污染。
这种隔离带来的调试体验也很好。如果某个渠道出了奇怪的问题，我可以在另一个渠道发同样的消息做对照实验，快速定位是模型问题还是渠道适配问题。
权限控制方面，我要给一个忠告：nanobot 本身不提供严格的用户权限管理，任何能向机器人发消息的人都能调用模型。如果你的机器人接入的是企业级聊天工具，并且模型有联网搜索之类的扩展能力，一定要先在小范围的测试频道里跑几天，确认输出内容合适，再逐步开放。大模型的能力边界由模型决定，工具链越强大，意外行为的可能性也越大。这和自托管任何 AI 服务是一样的原则。
5. 进阶配置：多模型路由、提示词模板与会话记忆管理
5.1 用斜杠指令实现对话内模型切换
多模型切换是 nanobot 最实用的功能之一。传统 WebUI 切模型要在设置里改参数，nanobot 直接把 /model 指令暴露在对话里，随时可以换。
我日常使用的一套模型组合：
| 模型 | 用途 | 显存占用 |
|---|---|---|
| qwen2.5:7b | 日常问答、中文写作 | 约 6GB（Q4 量化） |
| deepseek-coder:6.7b | 代码生成、代码 review | 约 5GB |
| gemma2:27b | 长文档总结、深度推理 | 约 16GB |
切换模型前有个细节要留意：模型切换后，旧模型留下的上下文是否兼容新模型，这取决于不同模型对 prompt 格式的要求。不同模型有不同的 system prompt 模板和对话格式，如果上下文格式不匹配，可能导致生成质量下降甚至报错。我的习惯是切换模型前先 /clear，让新模型从干净的上下文开始。
5.2 自定义 system prompt 与角色设定
system prompt 是塑造机器人行为的核心工具。配置文件里可以设置全局的 system prompt，也可以针对特定 namespace 单独设置。企业场景里，你希望机器人在回复时始终用中文、自称“小助手”、遇到不会的问题要直接说不知道——这些都能通过 system prompt 实现。
我的一个生产配置示例：
yaml复制prompt:
system: |
你是一个经验丰富的软件架构师。你的职责是帮助团队完成代码评审、架构设计和技术方案选型。
要求：
1. 始终使用中文回答
2. 回答要具体、可操作，不要泛泛而谈
3. 如果信息不足，明确指出需要哪些补充信息
4. 涉及安全性问题时，优先强调潜在风险
这个 prompt 让机器人在实际对话中表现出了明显的角色倾向：回答更聚焦技术细节，主动追问信息，而且安全敏感问题的处理明显更谨慎。需要说明的是，不同版本的 nanobot 对 prompt 配置的字段名可能略有差异，建议以官方文档为准，但基本的设置思路是通用的。
5.3 上下文长度控制：防止模型“忘事”和“烧钱”
上下文管理是最值得花时间调的部分。在 Ollama 后端，可以通过 num_ctx 参数控制上下文窗口大小。如果窗口太小，模型记不住前面聊了什么，对话变成“金鱼记忆”；如果窗口太大，每次请求都会变慢，显存占用也暴涨。
我的经验是：8B 级模型建议窗口控制在 4096，27B 级模型可以开到 8192，但要注意显存是否够用。 对话次数多了之后，通过 /clear 手动清空，或者依赖 nanobot 的自动截断策略。
自动截断策略通常有两种思路：滑动窗口，只保留最近的 N 轮对话；摘要压缩，把较早的内容生成摘要再拼入 prompt。滑动窗口实现简单但可能会丢关键信息，摘要压缩效果好但每次压缩都要额外花一次模型推理。对于大多数场景，滑动窗口已经够用了，关键对话及时用摘要方式沉淀。如果团队有长期记忆的需求，建议把重要结论同步到文档系统，而不是完全依赖模型上下文。
6. 让 nanobot 学会使用工具：MCP 扩展接入与实战
6.1 MCP 协议到底解决了什么问题
MCP 是 Model Context Protocol，模型上下文协议。它是一套标准化协议，目标就是解决一个尴尬的问题：大模型自己不会操作外部工具，但很多时候又需要外部信息才能给出有用的答案。
举个我实际遇到的例子。有一次我在群里问“帮我看看本月服务器资源使用情况”，模型本身没有访问监控系统的能力，它只能基于训练数据里的常识来回答，这在动态数据场景下完全没有意义。但如果通过 MCP 接入一个监控系统的工具服务器，模型就能实时查询资源数据，再基于真实数据给出分析。
MCP 的架构分三层：宿主（Host，这里就是 nanobot）、客户端（Client）、服务器（Server）。nanobot 作为 MCP 客户端，连接外部工具服务器。工具服务器的形态可以是一个本地进程，也可以是一个远程 HTTP 服务，只要遵循 MCP 协议就能被 nanobot 调用。
6.2 接入一个真实工具服务器的完整配置
接入 MCP 工具服务器的配置方式大概如下：
yaml复制mcp:
servers:
weather:
transport: sse
url: http://localhost:8000/mcp
这段配置声明了一个名叫 weather 的 MCP 服务器，通过 SSE（Server-Sent Events）协议连接，地址是 http://localhost:8000/mcp。nanobot 启动后会自动连接这个服务器，获取服务器的工具列表，并把工具描述注入到系统提示词中，让模型知道有这些工具可用。
实际对话中的工具调用流程是这样的：
- 用户提问：“北京今天天气怎么样？”
- 模型分析后，判断需要调用
get_weather工具，生成一个工具调用请求 - nanobot 拦截这个请求，转发给 MCP 服务器
- 工具服务器执行查询，返回天气数据
- nanobot 把结果回传给模型
- 模型基于真实天气数据生成最终回答：“北京今天多云，气温 18-26 度...”
这个过程对用户来说是透明的。你只看到问了一句天气，模型就返回了准确答案，但中间其实经历了两次模型推理和一次工具调用。
6.3 工具调用失败的常见原因与日志排错
工具调用最容易出的问题，我按出现频率排序一下：
第一，模型能力不足。 不是所有模型都擅长工具调用。小参数模型（3B、7B）经常不会正确生成工具调用请求，或者生成了格式错误的请求。实测下来，至少 8B 以上模型才具备稳定的工具调用能力，14B/32B 效果更明显。如果你发现工具从来没被调用过，先换个大模型试试。
第二，MCP 服务器 CORS 配置问题。 如果 MCP 服务器是 HTTP 服务且通过 WebUI 触发调用，可能会遇到浏览器的 CORS 拦截。实际表现是调用请求已发出，但被浏览器拦截导致无法正常回传。排查时看浏览器控制台有没有 CORS 报错，有的话需要在 MCP 服务器侧加上对应响应头。
第三，schema 格式不标准。 MCP 工具描述里定义了参数格式，如果格式不符合模型的理解习惯，模型可能会生成无法解析的调用参数。这个问题的排查要打开 nanobot 的日志，看报错信息具体指向哪个字段。
日志排错是这个阶段最重要的技能。nanobot 的日志输出里会包含每一次工具调用的详细记录，包括模型生成了什么工具请求、工具服务器返回了什么内容、最终结果如何拼接。建议在排查时把日志级别调到 debug，能看到的细节会多很多。
7. 稳定运行的关键：常见报错排查与性能优化笔记
7.1 五个高频报错与排查链路
跑了几个月，我把遇到最多的报错和排查链路整理成了对照表：
| 报错信息 | 根因 | 排查步骤 |
|---|---|---|
connection refused to 11434 |
Ollama 服务未启动或地址配置错 | 先 curl http://localhost:11434/api/tags 验证 Ollama 是否可访问，再检查配置文件里的 endpoint |
model not found |
模型未拉取或名称拼写错误 | ollama list 查看本地模型列表，确认名字完全一致，注意版本标签 |
| 中文乱码 | 终端编码问题 | Windows 终端执行 chcp 65001 切换到 UTF-8 |
out of memory |
模型太大或并发请求过多 | 换更小的量化版本，或调低 OLLAMA_NUM_PARALLEL 并发数 |
| token 无效 | 平台 token 类型错误或权限不足 | 确认 Slack 是 Bot Token 而非 User Token，确认 Discord 的 intent 已开启 |
第一个报错是新手最常遇到的。特别注意：如果你的 Ollama 是通过 systemd 启动的，systemctl status ollama 可以看服务状态；如果 curl 通了但 nanobot 仍然连不上，检查配置文件里是否有多余的空格或缩进问题。YAML 的缩进是出了名的严格，一个 Tab 键和空格混用就能让配置解析失败。
7.2 性能调优：并发、显存与响应速度
性能调优的核心目标是让显存利用率和响应速度达到平衡。三个关键参数：
OLLAMA_NUM_PARALLEL 是 Ollama 的环境变量，控制同时处理的请求数。默认值 4 比较保守，如果你的显存足够，比如 24GB 显存跑 7B 模型，可以把它调到 8-12，并发能力会有明显提升。但这个值不是越大越好，过大时显存碎片化会变得严重，反而可能导致 OOM。
量化级别是另一个关键因素。Q4_K_M 级别是性价比之王，模型体积小，推理速度快，质量损失在绝大多数场景下可以忽略。如果你追求极致质量且显存充裕，可以尝试 Q6_K 或 Q8_0，但牺牲的推理速度会实打实地反馈到响应延迟上。
keep_alive 参数控制模型在显存中的驻留时间。默认情况下模型会短时间驻留，如果请求间隔过长会被卸载，下次请求又要重新加载，加载时间可能高达十几秒。把这个参数调长（比如 30m 或 1h），让模型常驻内存，重复对话的响应速度会稳定很多，代价是显存一直被占用。
我的实际调优经验是：先用 ollama ps 观察当前正在运行的模型和显存占用，再结合自己的使用频率逐步调整参数。不要一开始就上高并发，先稳定跑一天，观察显存峰值和响应延迟，再决定要不要加大。
7.3 备份与升级：配置文件迁移的注意事项
nanobot 的所有配置都在一个 YAML 文件里，备份就是复制这个文件的事。我习惯每次调整配置前先备份一份带日期后缀的副本：cp nanobot.yaml nanobot.yaml.bak-20250101。这样如果新配置有问题，可以秒级回滚。
升级方面，Go 项目的升级通常很简单——下载新二进制替换旧文件，重启服务。但有两个注意事项：
第一，先看 release notes。 确认新版本是否有配置格式的变更，尤其是字段名和数据结构的变化。我在一次跨版本升级时遇到过 prompt 配置字段名变更，导致自定义提示词全不生效，排查了很久。
第二，小版本升级可以大胆，大版本升级先在测试环境跑。 如果你用 Docker 部署，升级前先 docker pull 新镜像，在另一个容器里跑起来对比配置差异，确认无误后再切换。不要在生产环境直接升级，这是所有自托管服务都适用的原则。
跨机器迁移时，除了复制配置文件，还要确认目标机器上已经拉取了对应的模型，并且 Ollama API 地址和 nanobot 配置中的 endpoint 一致。看似琐碎的细节，实际出问题的概率都不小。
最后分享一个我这几个月最深刻的体会：nanobot 这种工具的价值，不在于某一个单一功能有多惊艳，而在于它把本地大模型从“玩具”变成了“基础设施”。以前每次想用模型都得专门打开一个页面，现在只需要在常驻的聊天工具里发一条消息，或者直接命令行敲几个字，模型就在那里等着。真正的效率提升不是某一个命令快了，而是整个工作流的阻力变小了。如果你也在跑 Ollama，但总觉得差一个顺手的入口，相信我，花一个下午把 nanobot 搭起来，绝对值回票价。