给 Buzz 的 AI Agent 填模型端点时先把两件事拆开TaoToken 的 Key 管鉴权Base URL 管请求发往哪里Key 和入口从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentbuzz_agent_entry 获取。很多人第一次在 Buzz 里配 Agent会直接找api_key输入框填完发现要么 401要么模型列表为空要么请求发到了错误路径。问题通常不在 Buzz 本身而在于把“入口页面”和“端点字段”混成了一件事入口负责拿到身份和模型信息字段负责让 Agent 真正发出可鉴权的请求。Buzz 最近被一些营销号说成“AI 代理自动接管公司”的赚钱工具但从工程视角看它更像是基于 Nostr 的协作底座把聊天、Git 仓库、代码审查和 AI Agent 放进同一个窗口。本文不讨论它能不能赚钱只讨论作为 Buzz 中 AI Agent 的模型入口维护者怎么把 TaoToken 的 Key、Base URL、模型名和请求日志串起来。下面给出一份字段对照、可复现配置、请求日志和排障顺序。TaoToken 侧统一 Base URL 用https://taotoken.net/apiKey 占位符用YOUR_API_KEY不要提交到 Git。1. Buzz Agent 模型入口字段对照api_key、base_url、model 谁管谁Buzz 的部署形态可能不同AI Agent 配置页的字段名也可能有差异但语义基本固定一个是身份一个是路由一个是模型选择一个是 Agent 行为。把这几类字段分开排障会快很多。字段语义常见字段名应该填什么常见错误鉴权 Keyapi_key、auth_token、env_keyYOUR_API_KEY把 Key 写进前端、提交到仓库、前后有空格端点根地址base_url、api_base、endpointhttps://taotoken.net/api在后面乱加/chat/completions或带 UTM 参数模型名model、model_id、agent_model从 TaoToken 模型对话页确认的模型 ID用展示名当模型 ID或复制了带空格的名称协议类型provider、protocol、api_typeOpenAI-compatible 或控制台说明的兼容类型选了 Anthropic 协议却填 OpenAI 路径流式输出streamtrue或false按 Buzz Agent 支持情况开启流式但日志解析按整包 JSON 处理超时timeout_ms、timeout建议 60000 起步代码审查长 diff 超时后误判为 Key 失效重试retry、max_retries2 到 3 次避开 401/404对 401 疯狂重试触发更多失败日志系统提示词system_prompt、prompt限定 Agent 只输出审查结论让 Agent 直接操作生产环境事件绑定event、trigger、channel聊天提及、Git 事件、审查事件Agent 已配好但没有任何事件触发这里最关键的是别把入口和端点混用。入口是你在浏览器里操作的地方注册登录、看模型、创建 Key、看套餐、读文档。端点是 Buzz Agent 运行时真正请求的 URLhttps://taotoken.net/api。Key 是身份凭证不是模型名模型名是选择哪个模型不是 Base URL。三者任何一个填错表现都可能是“Agent 不回消息”但日志里的状态码完全不同。从维护者视角建议在 Buzz 部署里用环境变量保存 Key不要写进 Agent 配置文件明文。比如在服务端启动脚本里注入然后让 Buzz 的 Agent 配置只引用变量名。如果 Buzz 必须填明文也至少保证该配置文件不进 Git并在轮换 Key 后重启 Agent。2. 从 TaoToken 入口拿 Key模型对话、Coding Plan、API Keys 的分工TaoToken 的几个入口各管一段流程不要指望一个页面解决所有问题。建议按下面顺序走打开总入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentbuzz_agent_console 。注册或登录后先别急着复制 Key。去模型对话确认模型名https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentbuzz_agent_chat 。在这里你可以看到当前可用的模型标识、对话能力和基本表现。Buzz Agent 的model字段要填模型 ID不要填页面展示名。如果这个 Buzz Agent 要长期跑代码审查、聊天摘要、仓库事件响应去看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentbuzz_agent_plan 。它解决的是持续使用时的套餐和用量预期不是替代 Key。创建或轮换 Keyhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentbuzz_agent_keys 。复制出来的值就是YOUR_API_KEY。建议按环境命名比如buzz-prod-agent、buzz-dev-review方便后续删除和审计。如果你同时维护 Claude Code再看 Claude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentbuzz_agent_claudecode 。它的配置字段和 Buzz Agent 不是一套别直接复制ANTHROPIC_*到其他工具。Key 和入口的分工可以记成一句话入口负责“拿到什么”字段负责“怎么用”。模型对话告诉你能用什么模型API Keys 告诉你是谁Coding Plan 告诉你长期怎么用Claude Code 文档告诉你在 Claude Code 里怎么写。Buzz Agent 的模型入口只认三件核心事Base URL、Key、模型名。另外Base URL 不要带 UTM。https://taotoken.net/api?utm_source...这种写法可能让某些客户端把它当成路径的一部分导致 404。入口链接可以带 UTM 用于统计但配置字段里的 Base URL 必须保持干净https://taotoken.net/api。3. 可复现配置模板Buzz Agent、Claude Code、Codex 三套不要混Buzz Agent 的配置 schema 取决于你的部署版本下面先给一份语义模板。字段名以你实际 Buzz 配置页为准但值的来源是固定的。# Buzz Agent 模型入口语义模板字段名请按你的 Buzz 部署调整 agent: id: code-review-agent provider: openai-compatible base_url: https://taotoken.net/api api_key: YOUR_API_KEY model: your-model-name stream: true timeout_ms: 60000 retry: 2 system_prompt: | 你是 Buzz 里的代码审查 Agent。 只针对本地 diff 给出风险、测试建议和最小修改。 不要直接连接生产数据库不要执行破坏性命令。如果 Buzz 支持环境变量引用推荐改成这样export TAOTOKEN_BASE_URLhttps://taotoken.net/api export TAOTOKEN_API_KEYYOUR_API_KEY export TAOTOKEN_MODELyour-model-name然后在 Buzz 的 Agent 配置里引用TAOTOKEN_BASE_URL、TAOTOKEN_API_KEY、TAOTOKEN_MODEL。这样轮换 Key 时不用改配置文件只需更新环境变量并重启 Agent。如果你同时维护 Claude Code配置入口是settings.json字段用ANTHROPIC_*。示例{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: your-model-name } }有些 Claude Code 版本使用ANTHROPIC_API_KEY有些使用ANTHROPIC_AUTH_TOKEN。按你当前版本文档二选一不要同时填两个冲突值。关键点是Claude Code 的ANTHROPIC_*只属于 Claude Code 这一套。如果你维护 Codex配置入口是config.toml不要套用ANTHROPIC_*。示例model your-model-name model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEYCodex 读取的是model_provider、base_url、env_key这类字段。把ANTHROPIC_BASE_URL写进 Codex 的config.toml不会生效常见结果是 Codex 仍然走默认端点或者直接报缺少 provider。CC Switch 这类切换工具可以记成“三件套”Base URL、API Key、模型名。切到 Claude Code 时把三件套映射到settings.json的ANTHROPIC_*环境变量切到 Codex 时把三件套映射到config.toml的model_provider、base_url、env_key、model。切换工具只负责改文件不负责把 A 工具的变量名翻译成 B 工具的变量名所以不要混用。Buzz Agent 则按 Buzz 自己的字段名来base_url填https://taotoken.net/apiapi_key填YOUR_API_KEYmodel填你在模型对话页确认的模型 ID。如果 Buzz 配置页有“协议类型”选与控制台说明一致的兼容类型。没有明确说明时先用 OpenAI-compatible 风格的最小请求验证。4. 请求日志与排障401、404、429 在 Buzz Agent 里的定位顺序当 Buzz Agent 不回消息时不要先改提示词。先在本地用 curl 直连 TaoToken确认 Key、Base URL、模型名三件事是否成立。示例命令export TAOTOKEN_BASE_URLhttps://taotoken.net/api export TAOTOKEN_API_KEYYOUR_API_KEY export TAOTOKEN_MODELyour-model-name curl -i ${TAOTOKEN_BASE_URL}/v1/chat/completions \ -H Authorization: Bearer ${TAOTOKEN_API_KEY} \ -H Content-Type: application/json \ -d { model: ${TAOTOKEN_MODEL}, messages: [ {role: system, content: 你是 Buzz 里的代码审查 Agent只输出审查结论。}, {role: user, content: 检查本地 diff if (user) login();} ], stream: false }如果客户端已经自动拼接/v1那么 Buzz 的base_url只填https://taotoken.net/api不要在配置里再写/v1/chat/completions。如果客户端不自动拼接curl 里可以显式写/v1/chat/completions做验证但最终以你使用的 Buzz Agent 和客户端要求为准。正常返回日志示意HTTP/1.1 200 OK Content-Type: application/json { id: chatcmpl_xxx, object: chat.completion, choices: [ { index: 0, message: { role: assistant, content: 风险空值判断可能不足。建议补充 else 分支和对应测试。 }, finish_reason: stop } ], usage: { prompt_tokens: 42, completion_tokens: 28, total_tokens: 70 } }Key 错误日志示意HTTP/1.1 401 Unauthorized Content-Type: application/json { error: { message: invalid api key, type: authentication_error } }模型名错误日志示意HTTP/1.1 404 Not Found Content-Type: application/json { error: { message: model not found, type: invalid_request_error } }排障顺序建议固定成下面四步看状态码。401 先查 Key 是否复制完整、是否被空格污染、是否已删除或轮换。404 先查 Base URL 和模型名不要先怀疑 Buzz 聊天窗口。看请求地址。日志里如果出现https://taotoken.net/api/chat/completions和https://taotoken.net/api/v1/chat/completions混用确认客户端是否自动拼接版本号。Base URL 保持https://taotoken.net/api。看模型字段。把模型对话页确认的模型 ID 原样填入不要用页面标题、别名或带空格的名字。看事件绑定。如果 curl 正常、Buzz Agent 没反应问题可能在 Nostr 事件、Git 事件或聊天触发条件而不是模型端点。429 通常表示请求频率或用量策略触发。先降低重试次数避免多个 Agent 同时循环请求。代码审查场景建议把长 diff 分块而不是一次性塞入巨大上下文。500 或 502 这类上游错误先记录请求 ID 和时间再做低频重试。5. 把代码审查 Agent 接进 Buzz 工作流本地命令 事件触发Buzz 把聊天、Git 仓库、代码审查和 AI Agent 放在同一个协作窗口里。要让代码审查 Agent 真正可用建议按“本地验证、配置注入、事件触发、日志核对”四段来做。第一步在本地准备 diff。所有命令由读者本地执行不要让 Agent 直接持有生产库凭证。git diff --no-color /tmp/buzz-review.diff wc -l /tmp/buzz-review.diff第二步用本地脚本或 curl 把 diff 摘要发给 TaoToken 验证。不要把完整大 diff 直接打印到公共聊天窗口先截取关键片段。head -n 120 /tmp/buzz-review.diff第三步在 Buzz 的 Agent 配置里绑定事件。不同部署可能叫trigger、event、channel或subscription。你要做的是把“代码审查事件”或“聊天提及”指向code-review-agent。如果 Buzz 里没有明确事件字段就先在聊天窗口手动 Agent 测试。第四步重启 Buzz Agent 服务让新的base_url、api_key、model生效。重启后在 Buzz 聊天里发一条最小测试code-review-agent 请审查本地 diff 摘要新增了 if (user) login(); 没有 else 分支。第五步看请求日志。你至少要能看到时间、模型名、状态码、耗时、token 用量。如果 Buzz 日志只显示“Agent failed”就去服务端日志或网关日志里搜索401、404、429、model、taotoken。不要只看前端提示。第六步轮换 Key。在 API Keys 页面创建新 Key更新 Buzz 环境变量重启 Agent确认新请求成功后再删除旧 Key。不要直接删除唯一 Key否则 Buzz Agent 会立刻 401。第七步限制 Agent 权限。代码审查 Agent 只应读取本地 diff 或只读仓库内容不应直接连接生产数据库不应执行破坏性 SQL。需要查询时由读者在本地执行 SQL或使用只读环境不应把生产库凭据交给 Agent。6. 文末 CTA模型对话 → Coding Plan → 创建 Key → Claude Code 文档如果你还没决定 Buzz Agent 用哪个模型先去模型对话确认模型 IDhttps://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentbuzz_agent_chat 。如果这个 Agent 要长期跑代码审查、聊天摘要和仓库事件去看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentbuzz_agent_plan 。确定套餐后去 API Keys 创建或轮换YOUR_API_KEYhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentbuzz_agent_keys 。如果你同时维护 Claude Code再看 Claude Code 文档避免把ANTHROPIC_*和 Codex 的config.toml混用https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentbuzz_agent_claudecode 。入口总览在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentbuzz_agent_final 。记住Buzz Agent 的base_url用https://taotoken.net/apiKey 用YOUR_API_KEY模型名从模型对话页确认请求日志优先看状态码。