AgentLoop 让 Nanobot 自己装好博客靠的是一个 while 循环反复调用大模型 API。这个循环要转起来第一道坎不是 Agent 逻辑而是模型通道官方 Key 额度一尽provider.chat() 第一次请求就抛错。把通道指到 TaoToken——一个统一 API 兼容通道——之后同一个 AgentLoop 才把博客部署流程走完。先进 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿 Key再改 Nanobot 的 provider 配置剩下交给循环本身。原文演示里用户只丢了一句话Nanobot 就从空目录开始建项目、拉脚手架、改配置、启动本地服务。拆开看每一步都是 AgentLoop 在重复调一次模型解析返回的 tool_call在本地执行把结果追加进对话历史再调一次模型。换通道之前循环往往在第 1 次迭代就停住换通道之后问题消失循环能一直转到模型给出最终答案。1. AgentLoop 把博客装完之前先过 provider.chat() 这一关1.1 原文场景一句话变成一串 shell 命令原文的实际演示里模型返回的并不是「我已经帮你装好博客」这种总结而是一串结构化的工具调用指令。比如先创建一个项目目录再写入站点配置文件接着跑一条构建命令最后启动本地静态服务。Nanobot 拿到这些指令后会调用await self.tools.execute(tool_call.name, tool_call.arguments)把真实执行结果——包括报错信息——原样追加到对话记录里然后带着这份新的「操作记录」进入下一轮模型请求。这就是 AgentLoop 和普通聊天的本质差异它不追求一轮对话生成最终答案而是用小步迭代的方式让模型一边看执行结果一边决定下一步动作。整个过程像一个人在终端前面操作先看一眼目录结构再决定写哪个文件写完文件跑一次命令看输出看到报错再调整。只不过这个「人」是模型而它的眼睛和手都通过工具调用接口暴露给 AgentLoop。工具的定义本身是 JSON Schema里面包含工具名称、功能描述、参数要求模型照着 schema 生成调用参数Nanobot 再把这组参数交给对应的本地函数。1.2 循环边界40 次迭代每次都要先发一次网络请求AgentLoop 的循环由 while 实现max_iterations默认是 40。也就是说模型最多被调用 40 次如果 40 轮之内没有给出最终回复循环会被强制终止返回当前已经完成的部分结果。这个上限是为了防止模型陷入反复调用工具的闭环里出不来但也带来了一个副作用每一次迭代都是一次完整的网络请求上下文还会在每轮之后继续膨胀。矛盾点就在这里循环的每一次迭代第一步都是 provider.chat() 这个跨网络请求。Nanobot 本地逻辑再健壮只要模型服务商那边返回鉴权失败、路径不存在或者连接超时循环就直接卡死在第一轮后续 39 次迭代配额全部作废。把模型通道从官方 API 切到统一通道之后这一步的地址被替换成https://taotoken.net/api请求能被正常受理Nanobot 不需要修改任何 AgentLoop 的循环代码。2. 拆开 provider 三要素Base URL、API Key、模型 ID2.1 provider 在六阶段生命周期里的位置按原文对消息生命周期的拆解一条消息从进来到回复用户要依次经过六个阶段Channel 接收Telegram、Discord、飞书等平台的 inbound 消息进入 MessageBus访问控制与路由判断这个来源有没有权限触发 AgentContextBuilder 组装 prompt把系统身份、AGENTS.md 引导文件、长期记忆、Skill 摘要拼成完整的消息数组AgentLoop 阶段四把消息发给 LLM拿到模型返回AgentLoop 阶段五按模型返回执行工具调用把结果回传给模型Channel 发送回复Outbound 消息回到用户所在平台。六个阶段里面只有第 4 步真正跨越网络访问模型服务商。其他步骤要么在本地拼字符串要么在本地执行 shell 命令。所谓「更换模型通道」本质上就是替换第 4 步的请求目标让 provider 把请求发到另一台服务器上而已。ChannelManager 在启动时根据配置动态加载具体频道类这属于第 1 步的工作和模型通道无关所以换 Base URL 不需要动 Channel 相关的任何配置。2.2 provider 只认三个字段Nanobot 的 provider 配置关心三件事Base URL 决定请求发往哪里API Key 决定请求算在谁头上模型 ID 决定调用的是哪个模型。原文演示时这三个值默认指向官方服务使用 TaoToken 时把它们替换成对应的值Base URL 填https://taotoken.net/api末尾不要加/v1API Key 填你从控制台创建出来的那串值示例中统一写作YOUR_API_KEY模型 ID 以模型广场实际列表为准不要靠记忆敲。这里最容易被习惯坑到的是/v1。很多兼容类 API 的官方地址都以/v1结尾但在 TaoToken 的接入方式里https://taotoken.net/api就是 Nanobot 需要的根地址。Nanobot 在组装请求时会自己拼路径如果你额外多加一层/v1后续请求百分百 404。另外provider 的类型字段保持原来的值不动因为 TaoToken 通道兼容 Anthropic 格式Nanobot 发送请求时用的是同一套消息结构和工具定义。3. 动手前先准备TaoToken 拿 KeyNanobot 备份配置3.1 注册、创建 API Key、查看模型广场打开 TaoToken 官网注册登录后进入 Console在 API Keys 页面创建一把新的 Key复制保存好。原文演示没有这一步是因为原作者默认手里已经有官方 Key现在换成 TaoToken就要先完成同等的「申请密钥」流程。创建完 Key 之后顺手去模型广场看一眼当前有哪些模型可调用。这一步很重要模型 ID 不能凭印象填是否上架、版本号是多少都以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场当时列表为准。把模型广场上对应的模型 ID 复制下来后面配置里直接粘贴。如果你打算长期跑 AgentLoop 这类长任务也可以顺便留意一下不同模型的上下文窗口和限流策略避免任务跑到一半被限流打断。3.2 给 Nanobot 的 config 留一份备份Nanobot 的配置文件是 YAML 或 JSON 格式取决于你安装的版本。改动之前先把原文件另存一份。理由很简单之后如果你想对比官方模型和 TaoToken 通道上的同一个模型在 AgentLoop 里的行为差异或者想临时切回原来的 provider有一份备份就能 10 秒还原不用重新手敲一遍配置。备份做完在配置里找到llm或provider这一节把原来的base_url、api_key、model三个字段替换成第 2 章列出的值。其他参数像temperature、max_tokens保持原样即可。通道切换不改变采样参数模型行为保持一致才能公平对比。如果你的启动脚本里设置了环境变量记得一并检查因为环境变量的优先级往往高于配置文件旧的 Key 残留在环境变量里会让新配置看起来没生效。4. 把 Nanobot 的模型通道指到 TaoTokenconfig.yaml 改三个字段4.1 可复制的配置片段下面这段配置是切换通道后的核心片段llm: provider: anthropic base_url: https://taotoken.net/api api_key: YOUR_API_KEY model: 模型ID以模型广场列表为准 temperature: 0.7 max_tokens: 4096保存时注意真实 API Key 不要写进公开仓库或博客示例用YOUR_API_KEY当占位符。provider保持anthropic不动原因是 TaoToken 的通道兼容 Anthropic 的请求格式Nanobot 发送逻辑不需要跟着变。model字段是唯一需要你手动替换的值填你从模型广场复制的那个 ID这一步对应原文里「查看文档确认模型名」的位置只是现在统一到模型广场确认。如果你不想把 Key 明文写在 YAML 里也可以让 Nanobot 从环境变量读取。具体做法取决于你的 Nanobot 版本是否支持${YOUR_API_KEY}这种变量展开语法不支持的话就在启动脚本里先export再把配置文件里的值是YOUR_API_KEY。无论哪种方式都要确保进程实际读到的 Key 与 TaoToken 控制台里创建的那把完全一致。4.2 官网地址和接口地址一个给人、一个给机器配置过程中最容易翻车的是把两类地址弄混。给浏览器打开的落地页是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 用来注册账号、创建 Key、查看模型广场和用量记录。而填进 Nanobot 配置、curl 命令或任何工具里的 Base URL一律是https://taotoken.net/api末尾没有/v1也不带任何 UTM 参数——UTM 参数是网页统计用的带进 API 请求会导致路径拼接异常。如果填反症状很典型Nanobot 日志里出现连接超时或者证书类报错大概率是 Base URL 写成了官网首页出现 404大概率是端点路径拼错。见到这两种报错先回到配置里确认填的是不是https://taotoken.net/api。这个地址是给程序请求的不是给人用浏览器打开的别拿它去网页访问也别拿官网链接去填配置。5. 重启 Nanobot看 AgentLoop 自己跑完博客部署5.1 第一轮迭代从创建目录开始配置保存后用你平时启动 gateway 的方式重启 Nanobot。重启完成重新发一次原文那条请求「帮我在本地部署一个博客网站」。第 1 次迭代里模型首先看到 ContextBuilder 组装好的 system prompt 和用户消息返回一个工具调用——通常是先创建项目目录。Nanobot 在本地执行完后把「目录是否创建成功」写进消息数组进入第 2 次迭代。此时通道扮演的角色仅仅是帮 Nanobot 把这一轮请求送到模型服务商、再把模型返回原样送回来它不会代替 Nanobot 创建任何目录或下载任何依赖。日志里如果把每轮 tool_call 的入参和出参打出来你会看到一条清晰的决策链先建目录再写配置再构建再启动服务。5.2 部署中的每一步工具调用都在本地发生后续迭代里模型会按需返回不同工具调用写入博客站点配置、拉取主题模板、执行静态页面构建、启动本地服务。这些操作全部由 Nanobot 在本地 workspace 里真实执行Shell 类工具会把命令交给终端解释器跑起来再捕获 stdout 和 stderr 作为下一轮模型的输入。如果模型需要查资料或拉远程内容还会调用 WebFetchTool 去抓网页抓回来的内容同样会被拼进下一轮上下文。把这一段和原文对 Agent 的拆解放在一起看分工很清楚模型负责决策——下一步该调哪个工具、参数传什么Nanobot 负责执行——真正建目录、写文件、跑命令TaoToken 只负责把两者之间的对话请求稳定送达并计费。通道再稳不会替 Nanobot 建目录通道再快也不会让模型少做一次决策。AgentLoop 的迭代次数还是 40 次上限token 消耗还是那样大变的只是 provider 这一跳的地址和计费归属。5.3 循环的两种结束方式AgentLoop 只会在两种情况下停下来模型返回纯文本回复而不再请求工具调用或者迭代次数达到 40 次上限。正常部署一个博客网站大多数情况用不到 40 轮如果中途某次工具执行抛错模型读到 stderr 后通常会改换策略重试——前提是下一轮 provider.chat() 依然成功。这也是换通道后同一个任务能跑通的原因TaoToken 并没有提升模型的推理能力而是消除了 provider 层的请求故障让 AgentLoop 能把 40 次迭代额度真正用在「思考 执行」上而不是浪费在连接失败里。原文里 AgentLoop 每轮都会保存 Session、执行内存合并、在超窗口时触发 consolidate这些机制在通道切换后照常工作不依赖具体模型服务商。6. 六阶段生命周期里TaoToken 只占第五格6.1 六个阶段完整过一遍回到原文那张六阶段示意图。一条消息从外部平台进入 Nanobot先由 Channel 接收并放入 MessageBus随后访问控制与路由判断来源是否有权限接着 ContextBuilder 把系统身份、AGENTS.md 引导文件、长期记忆和 Skill 摘要拼成完整 messages再进入 AgentLoop——阶段四是调用 LLM阶段五是执行工具并把结果回传最后 Outbound 消息通过 Channel 发回用户平台。TaoToken 在整条链路里的位置很清晰它只替换阶段四「调用 LLM」时的请求地址。其余五个阶段的代码、配置、执行环境完全不变。Channel 用什么协议接入、ContextBuilder 加载哪些记忆文件、AgentLoop 最多迭代多少次这些都是 Nanobot 本地逻辑不受模型通道影响。换句话说你换掉的只是「问谁要答案」不是「怎么思考、怎么执行」。6.2 ContextBuilder 的拼接逻辑没动原文对 ContextBuilder 的拆解提到build_system_prompt会依次获取核心身份、加载 AGENTS.md 等引导文件、读取长期记忆 MEMORY.md、加载 Skills 摘要最后拼成发给模型的完整 system prompt。切换通道之后这条拼接链路没有任何变化。build_messages也一样历史对话、当前用户消息、图片 base64 编码全部按原有逻辑组装。只要你在模型广场选的模型与原文演示的是同一个模型看到的上下文、历史记录、工具定义就完全一致。行为上的差异只可能来自模型服务商侧的推理参数或版本差异而不会来自 Nanobot 本身的提示词处理。这也是为什么切换通道后不需要重新调 prompt——提示词没有被触碰只是请求路径变了。6.3 Skill 与 Tool 的边界同样不受影响原文还特别区分过 Skill 和 ToolSkill 是 Agent 解决特定问题的工作流通常包含触发条件、处理逻辑和工具编排Tool 是纯粹的执行接口模型用 function call 传参Tool 只负责「输入 A输出 B」。切换模型通道只影响请求目标不改变 Nanobot 加载 Skill 的方式也不改变 Tool 注册表里的 JSON Schema 定义。每一轮 AgentLoop 依然会把所有可用工具的定义随请求发给模型模型照旧按 schema 生成参数。如果你在 TaoToken 模型广场换了一个上下文窗口更大的模型AgentLoop 单轮能塞下的记忆和工具描述会变多但 Skill 的加载逻辑、Tool 的执行方式、40 次迭代上限全部保持不变。这给后续调优留了很大的空间通道稳定后想提升任务完成率优先调 Skill 和提示词而不是反复折腾 API 配置。7. 排障AgentLoop 转不动时查这三个位置7.1 第一轮就 401Key 没对上如果重启后第一次迭代就返回 401 Unauthorized先别怀疑循环逻辑问题几乎都在 Key 上。检查config.yaml里api_key字段是不是真的复制自 TaoToken 控制台再检查 Nanobot 启动时有没有环境变量覆盖了配置文件。很多进程会自动读取ANTHROPIC_API_KEY之类的旧环境变量只要环境变量里残留着以前的官方 Key配置文件写什么都没用。排查时可以先用 TaoToken 模型对话页面手工测一把 Key确认 Key 本身有效再回到 Nanobot 这边找覆盖源。环境变量、启动脚本、shell profile 三个地方都翻一遍通常能找到那个「漏网之鱼」。7.2 404Base URL 多写或多拼了一段404 通常是 Base URL 配置错误导致。最常见的是写成了https://taotoken.net/api/v1或者干脆把官网首页的网址填了进去。Nanobot 拿到 base_url 后会在后面追加模型请求路径多一层/v1或少一段/api拼出来的地址服务器都不认。正确值只有一种写法https://taotoken.net/api末尾不加斜杠、不带/v1。顺手检查一下配置里有没有多余的引号、空格或不可见字符YAML 解析时这些小问题也会让 base_url 变成非法值。7.3 连接超时或 SSL 报错可能填成了官网首页官网落地页是浏览器里给人看的页面API 端点是给 Nanobot 这类工具调用的地址。两个地址长相相似功能完全不同。排障日志如果出现ClientConnectorError、timeout或 SSL 证书相关的提示先回配置里看base_url是不是错填成了官网首页。这四类问题里超时最隐蔽因为配置看起来像是「填了官网」没填错但请求根本打不到 API 服务上。对照第 4 章的配置片段逐字段核对比靠日志猜更快。提示上述报错按顺序排查完之后重启 Nanobot 再看日志。如果失败仍然停留在 provider.chat() 这一行说明配置还没真正生效如果在日志里能看到工具调用的 stdout 输出通道就是通的剩余问题都在 AgentLoop 的决策侧。8. 跑通之后去控制台对一下这次调用8.1 先用模型对话验证同一把 Key如果不想让 Nanobot 来回试错可以先在 TaoToken 模型对话 里用同一把 Key 发一条测试消息。对话页面能正常回复说明 Key 有效、模型 ID 正确此时如果 Nanobot 仍然报错问题只可能在 Nanobot 的配置或环境变量覆盖上排查范围一下就缩小了。这个动作也适合作为每次改配置后的固定检查项先在网页端确认账号和 Key 都没问题再回到终端折腾进程。省掉来回切窗口的时间。8.2 对调用记录再看套餐是否划算确认博客部署跑通后到 控制台 API Keys 找到刚才用的 Key查看它在这一轮 AgentLoop 任务里产生了多少次调用。AgentLoop 是典型的高 Token 消耗场景每轮工具输出都在下一轮被重新发送给模型迭代 20 轮实际烧掉的 Token 相当于几十次独立问答。如果打算长期让 Nanobot 跑这类自动化任务看一眼 Coding Plan 是否比按量计费更合适也能顺带估算这次博客部署的成本。等模型返回「博客已部署访问 http://localhost:8080」AgentLoop 停住任务闭环。这时候再回看日志里那一串工具调用和 40 次迭代上限对一下你对 Nanobot 为什么在长任务里这么能烧 Token就会有最直观的感受。