1. 五种 Agent 模式到底在解决什么问题如果你刚开始接触 AI Agent大概率会被一堆名词砸晕Reflection、Tool Use、ReAct、Planning、Multi-Agent。它们不是五个互斥的框架而是五种可以叠加的“思考动作”。你可以把它们理解成一个人干活的五种习惯有人习惯先写草稿再改Reflection有人习惯先查资料再回答Tool Use有人习惯边做边想ReAct有人习惯先列清单再动手Planning还有人习惯拉个小组分工Multi-Agent。这篇内容面向的是想用统一 API 通道把 Agent 工作流跑起来的开发者。核心目标有两个第一用最短时间把这五种模式讲清楚知道每种模式适合什么任务第二给出一份可以直接复制的 TaoToken 配置骨架包含settings.json和config.toml并演示一次 Agent 模式切换后的请求验证动作。读完你应该能自己搭一个最小可跑的 Agent 循环而不是停留在概念层面。先说结论ReAct 和 Tool Use 是基础必绑Planning 负责先拆任务Reflection 负责自我改错Multi-Agent 负责分工组队。所有模式可以任意组合越往高端走AI 占的比重越大但你的配置和验证工作也越不能省。2. TaoToken 前置统一 Key 与接入地址在跑 Agent 之前得先解决“模型从哪来”的问题。Agent 工作流通常要频繁切换模型、切换模式如果每个模型都单独配一套 Key 和地址维护成本会很高。TaoToken 的思路是提供一个统一的 API 通道你只需要一个 Key就能在多种模型之间切换Agent 的模式切换也就变成了改一个配置字段的事。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 根地址是 https://taotoken.net/api 注意 API 地址后面不加 UTM 参数。你需要先去控制台创建一个 API Key控制台入口在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 管理页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。拿到 Key 之后先别急着写 Agent 逻辑用一次最简单的对话请求确认通道是通的这一步能帮你排除掉后面 80% 的“以为是 Agent 写错了其实是 Key 没配对”的问题。模型对话的调试入口在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。如果你后面要长期跑编码类 Agent可以关注 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。Claude Code 相关的接入说明在 https://taotoken.net/claudecode?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 。注意所有配置里的 Key 都不要硬编码进提交到仓库的文件用环境变量或本地未跟踪的配置文件承载。3. 可复制配置settings.json 与 config.toml 骨架下面这份配置是给 Agent 工作流用的最小骨架。settings.json负责运行时参数config.toml负责模型与模式声明。你可以直接复制把YOUR_TAOTOKEN_KEY换成自己的 Key。先看settings.json{ api_base: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, default_model: claude-3-5-sonnet, agent: { mode: react, max_steps: 8, enable_reflection: true, enable_tool_use: true, enable_planning: false, multi_agent: false }, tools: { allowed: [http_get, file_read, calculator], timeout_seconds: 20 }, logging: { level: info, trace_steps: true } }再看config.toml它把五种模式和模型映射写清楚方便你切换[provider] name taotoken api_base https://taotoken.net/api api_key_env TAOTOKEN_API_KEY [models] planner claude-3-5-sonnet executor claude-3-5-sonnet reflector claude-3-5-sonnet tool_runner claude-3-5-sonnet [agent.modes] reflection { enabled true, max_rounds 2 } tool_use { enabled true, max_calls 5 } react { enabled true, max_steps 8 } planning { enabled false, max_subtasks 6 } multi_agent { enabled false, agents [planner, executor, reviewer] } [agent.switch] active react fallback tool_use这份配置的关键点在于[agent.switch]里的active字段。你想从 ReAct 切到 Planning只需要把active改成planning同时把[agent.modes].planning.enabled设为true。模式切换不是玄学就是改配置加验证。环境变量这样设置export TAOTOKEN_API_KEY你的Key如果你用的是 Windows PowerShell$env:TAOTOKEN_API_KEY你的Key4. 验证请求模式切换后的实测动作配置写完必须验证否则你不知道 Agent 到底跑没跑起来。下面用一个最小 Python 脚本演示先以 ReAct 模式发一次请求再把模式切到 Planning观察返回结构里的mode字段是否变化。import os import json import urllib.request API_BASE https://taotoken.net/api API_KEY os.environ[TAOTOKEN_API_KEY] def call_agent(prompt, mode): payload { model: claude-3-5-sonnet, messages: [ {role: system, content: fagent_mode{mode}}, {role: user, content: prompt} ], metadata: {agent_mode: mode} } req urllib.request.Request( f{API_BASE}/v1/chat/completions, datajson.dumps(payload).encode(utf-8), headers{ Content-Type: application/json, Authorization: fBearer {API_KEY} }, methodPOST ) with urllib.request.urlopen(req, timeout30) as resp: return json.loads(resp.read().decode(utf-8)) if __name__ __main__: for mode in [react, planning]: result call_agent(帮我规划一次本地文件整理任务, mode) print(fmode{mode} -, result.get(choices, [{}])[0].get(message, {}).get(content, )[:120])跑通之后你会看到两次请求都返回了内容说明统一 Key 和 API 地址是通的。接下来做真正的模式切换验证把settings.json里的agent.mode从react改成planning同时把enable_planning设为true再跑一次脚本。如果返回内容里出现了任务拆解式的结构比如先列步骤再执行说明 Planning 模式生效了。实测下来验证环节最容易出问题的是metadata字段没被正确透传。有些客户端会把自定义字段丢掉导致你以为切了模式其实模型收到的还是默认模式。所以验证时一定要看返回内容的结构而不是只看有没有报错。5. 本篇常见错排查第一个高频错误是 401。原因通常是TAOTOKEN_API_KEY没设置或者设置在了错误的 shell 会话里。排查方法在跑脚本的同一个终端里执行echo $TAOTOKEN_API_KEY确认有值。如果用的是 IDE 内置终端注意它可能不继承你系统级的环境变量。第二个错误是 404。多半是 API 地址写错了比如把https://taotoken.net/api写成了带 UTM 参数的版本或者漏了/v1/chat/completions路径。记住 API 根地址就是https://taotoken.net/api不带任何查询参数。第三个错误是模式切换不生效。检查config.toml里[agent.switch].active和[agent.modes]下对应模式的enabled是否同时改对了。只改一个字段是常见坑比如只把active改成planning但planning.enabled还是false那实际跑的还是 fallback 模式。第四个错误是工具调用超时。settings.json里tools.timeout_seconds默认 20 秒如果你的工具是访问外部接口可能不够。先把它调到 60 秒试试确认是超时问题再优化工具本身。第五个错误是 Reflection 模式陷入死循环。max_rounds设太大模型会反复自我修改。建议先设 2观察输出质量再决定要不要加。提示排障时优先看日志里的trace_steps把logging.level调到debug能看到每一步的模式和工具调用记录。6. 把配置跑成习惯五种 Agent 模式不需要一次全上。我的建议是先把 ReAct 加 Tool Use 跑顺这两个是基础必绑能覆盖大部分“边想边干”的场景。等这条链路稳定了再加 Planning 做任务拆解加 Reflection 做质量兜底最后才考虑 Multi-Agent 分工。每加一种模式就回到第 4 节的验证脚本跑一遍确认返回结构符合预期。配置文件和验证脚本建议放进版本控制但 Key 用环境变量隔离。这样你换机器、换模型、换模式都只是改配置加跑验证的事。Agent 工作流的门槛不在概念而在“配置对不对、验证做没做”。把这两件事变成习惯剩下的就是不断调参和观察输出了。