1. 为什么你的 Agent 总是“跑偏”：从 AutoGPT 死循环说起
如果你动手写过 Agent，大概率遇到过这种场景：让它“调研一下某个开源项目的生态”，结果它连续七八轮都在搜索同一个关键词，或者反复调用同一个失败的工具，最后 token 烧完了，任务还没开始。这不是模型不够聪明，而是架构里缺了东西。
DeepAgents 这个概念最近被讨论得很多，但很多人把它和“会调用工具的 Chatbot”混为一谈。简单说，DeepAgents 是一类具备规划、工具、记忆、反思、协作五大核心组件的智能体架构，它能做什么？能自主拆解复杂目标、动态调用外部能力、跨轮次记住上下文、从失败中修正策略，甚至多个 Agent 分工合作。适合谁？适合已经跑通单轮 Function Calling、想进一步做多步任务编排的开发者，也适合正在选型 Agent 框架的技术负责人。
我试过用纯 ReAct 循环去跑一个“读取本地 CSV、清洗、生成图表、写报告”的四步任务，结果 Agent 在第 2 步就卡住了——它不知道第 3 步需要第 2 步的输出格式，因为没有全局计划。这就是本篇要拆解的核心：五大组件各自的职责边界，以及它们怎么在真实循环里咬合。同时，我会用 TaoToken 的统一 Key/API 通道作为接入示例，把可复制的配置片段和端到端验证步骤交付给你，避免你在多模型切换上浪费调试时间。
本篇是 DeepAgents 系列第 02 篇，第 01 篇画了全景图，这一篇直接下钻到组件层。读完你应该能回答：ReAct 和 Plan-and-Execute 到底该在什么场景用哪个？记忆溢出怎么处理？反思什么时候触发才不浪费 token？
2. TaoToken 统一接入：一个 Key 打通多模型 Agent 循环
在拆组件之前，先把接入层说清楚。DeepAgents 的五大组件里，规划、反思、协作都高度依赖 LLM 调用，而不同组件可能适合不同模型——规划用推理强的，工具参数生成用快的，反思用长上下文的。如果每个模型都单独配 Key、单独处理 Base URL，调试成本会指数级上升。
TaoToken 在这里的角色是统一通道：一个 API Key、一个 Base URL，就能在 OpenAI 兼容协议下切换不同模型。官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 端点是 https://taotoken.net/api （注意 API 地址不加 UTM 参数）。它的价值不在于“多一个供应商”，而在于让 Agent 的组件配置可以集中管理——你可以在一个 settings 文件里定义规划模型、执行模型、反思模型，全部走同一个通道。
具体操作上，你需要先拿到 Key。进入控制台创建 API Key，路径是 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite ，创建后复制保存。然后确认你要用的模型 ID，可以在模型对话页 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 里先手动试一轮，确认模型可用、响应正常，再写进 Agent 配置。文档页在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，里面有完整的参数说明和错误码对照。
这里有个容易踩的坑：很多人把 Base URL 写成带/v1或者带 UTM 的完整地址，结果 SDK 拼接路径时出现双斜杠或参数污染。正确做法是 Base URL 只写https://taotoken.net/api，让 SDK 自己去拼/v1/chat/completions。另外，如果你用的是 Claude Code 这类工具，它的配置格式和 OpenAI SDK 不同，需要单独处理，后面第 3 节会给完整片段。
对于长期跑 Agent 任务的场景，建议直接看 Coding Plan https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite ，它的额度模型更适合高频、多轮的工具调用循环，而不是按次计费的对话模式。API Keys 管理页在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite ，可以随时轮换 Key，避免硬编码泄露。
接入层搞定后，五大组件的配置才有意义——否则你会在“模型调不通”和“Agent 逻辑不对”之间反复横跳，根本分不清是哪个环节的问题。
3. 五大组件可复制配置：规划、工具、记忆、反思、协作
这一节直接给可复制的配置片段。我按组件拆开，每个片段都能独立跑，也能拼成一个完整的 Agent 循环。路径和原文保持一致，你直接改 Key 和模型 ID 就能用。
3.1 规划组件：Plan-and-Execute + ReAct 混合配置
规划的核心是“先想清楚再边做边调”。下面是一个 JSON 配置，定义了规划模型和执行模型分离的结构：
{ "planner": { "base_url": "https://taotoken.net/api", "api_key": "sk-your-taotoken-key", "model_id": "your-reasoning-model", "paradigm": "plan_and_execute", "max_subtasks": 8, "replan_on_failure": true }, "executor": { "base_url": "https://taotoken.net/api", "api_key": "sk-your-taotoken-key", "model_id": "your-fast-model", "paradigm": "react", "max_iterations": 15 } }这里的关键是paradigm字段：planner 用plan_and_execute，executor 用react。规划模型负责把“调研某项目生态”拆成“搜索官方仓库 → 读取 README → 提取依赖列表 → 搜索每个依赖的活跃度 → 汇总”，执行模型负责逐步跑 ReAct 循环。replan_on_failure打开后，某个子任务连续失败两次会触发重新规划，而不是死磕。
如果你用 TOML 格式（比如某些 Rust 或 Python 工具的配置），等价写法是：
[planner] base_url = "https://taotoken.net/api" api_key = "sk-your-taotoken-key" model_id = "your-reasoning-model" paradigm = "plan_and_execute" max_subtasks = 8 replan_on_failure = true [executor] base_url = "https://taotoken.net/api" api_key = "sk-your-taotoken-key" model_id = "your-fast-model" paradigm = "react" max_iterations = 153.2 工具组件：Function Calling + MCP 双通道
工具配置要解决三个问题：工具选择、参数生成、错误处理。下面是一个工具注册的 settings 片段，同时支持本地 Function Calling 和远程 MCP：
{ "tools": { "local_functions": [ { "name": "read_file", "description": "读取本地文件内容", "parameters": { "type": "object", "properties": { "path": {"type": "string", "description": "文件绝对路径"} }, "required": ["path"] } }, { "name": "write_file", "description": "写入内容到本地文件", "parameters": { "type": "object", "properties": { "path": {"type": "string"}, "content": {"type": "string"} }, "required": ["path", "content"] } } ], "mcp_servers": [ { "name": "search_server", "endpoint": "https://your-mcp-endpoint/mcp", "auto_discover": true } ], "tool_selection": { "strategy": "schema_constrained", "max_tools_per_step": 3, "retry_on_error": 2 } } }auto_discover打开后，Agent 会在运行时查询 MCP 服务器上有哪些工具，而不是预先写死。max_tools_per_step限制每步最多选 3 个工具，避免模型在几十个工具里乱选。retry_on_error是工具调用失败后的重试次数，超过后交给反思组件处理。
3.3 记忆组件：三层架构 + 上下文压缩
记忆配置的核心是短期、工作、长期三层，以及溢出时的压缩策略：
{ "memory": { "short_term": { "type": "conversation_buffer", "max_tokens": 32000 }, "working": { "type": "task_state", "fields": ["todo_list", "current_step", "intermediate_results"] }, "long_term": { "type": "vector_store", "embedding_model": "your-embedding-model", "base_url": "https://taotoken.net/api", "api_key": "sk-your-taotoken-key", "top_k": 5 }, "context_management": { "strategy": "summarize_on_overflow", "trigger_threshold": 0.85, "keep_recent_turns": 6 } } }trigger_threshold: 0.85表示上下文用到 85% 时触发摘要压缩，keep_recent_turns: 6保留最近 6 轮原文，更早的压缩成摘要。这样既不会丢关键信息，也不会让 token 无限膨胀。
3.4 反思组件：触发条件与层次配置
反思不能每步都做，否则 token 消耗翻倍。下面是触发条件和层次的配置：
{ "reflection": { "triggers": [ "tool_call_failed", "result_mismatch", "no_progress_3_steps", "user_requested" ], "levels": { "tactical": {"enabled": true, "model_id": "your-fast-model"}, "strategic": {"enabled": true, "model_id": "your-reasoning-model"}, "meta": {"enabled": false, "model_id": "your-reasoning-model"} }, "max_reflections_per_task": 5, "store_to_long_term": true } }no_progress_3_steps是连续 3 步没有实质进展时触发反思，这是防止死循环的关键。max_reflections_per_task: 5限制单任务最多反思 5 次，避免过度反思。store_to_long_term: true把反思结果存入长期记忆，下次遇到类似任务可以直接参考。
3.5 协作组件：主从模式配置
协作配置定义主 Agent 和子 Agent 的分工：
{ "collaboration": { "mode": "master_worker", "master": { "model_id": "your-reasoning-model", "base_url": "https://taotoken.net/api", "api_key": "sk-your-taotoken-key", "can_delegate": true }, "workers": [ { "name": "researcher", "model_id": "your-fast-model", "tools": ["search_server", "read_file"], "max_concurrent": 2 }, { "name": "coder", "model_id": "your-coding-model", "tools": ["read_file", "write_file"], "max_concurrent": 1 } ], "result_aggregation": "master_summarize" } }master_summarize表示子 Agent 返回结果后，由主 Agent 统一汇总，而不是直接拼接。这样能保证输出的一致性。
4. 端到端验证：从一次请求到完整 Agent 循环
配置写完后，必须验证每个组件是否真的在工作。下面是一个完整的验证流程，从单次请求到多步循环。
4.1 验证 API 通道连通性
先用 curl 确认 TaoToken 通道正常：
curl -X POST https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer sk-your-taotoken-key" \ -H "Content-Type: application/json" \ -d '{ "model": "your-model-id", "messages": [{"role": "user", "content": "回复 OK"}], "max_tokens": 10 }'如果返回{"choices":[{"message":{"content":"OK"}}]}，说明通道正常。如果返回 401，检查 Key 是否复制完整；如果返回local proxy failed，检查 Base URL 是否写成了带/v1的完整路径。
4.2 验证规划组件
用一个需要拆解的任务测试规划：
import requests planner_config = { "base_url": "https://taotoken.net/api", "api_key": "sk-your-taotoken-key", "model_id": "your-reasoning-model" } task = "读取 data.csv，统计每列缺失值，生成报告" response = requests.post( f"{planner_config['base_url']}/v1/chat/completions", headers={"Authorization": f"Bearer {planner_config['api_key']}"}, json={ "model": planner_config["model_id"], "messages": [ {"role": "system", "content": "你是规划器，把任务拆成子任务列表，每行一个，不要解释。"}, {"role": "user", "content": task} ] } ) print(response.json()["choices"][0]["message"]["content"])预期输出应该是类似：
1. 读取 data.csv 文件 2. 检查每列的缺失值数量 3. 汇总缺失值统计 4. 生成报告文件如果模型直接输出了代码而不是子任务列表，说明 system prompt 需要加强约束，或者换一个推理能力更强的模型 ID。
4.3 验证工具调用与记忆
用一个需要多步工具调用的任务测试：
messages = [ {"role": "system", "content": "你可以调用 read_file 和 write_file。先读取 input.txt，把内容转成大写，写入 output.txt。"}, {"role": "user", "content": "开始执行"} ] # 第一轮：模型应该返回工具调用 response = requests.post( "https://taotoken.net/api/v1/chat/completions", headers={"Authorization": "Bearer sk-your-taotoken-key"}, json={ "model": "your-fast-model", "messages": messages, "tools": [ { "type": "function", "function": { "name": "read_file", "description": "读取文件", "parameters": { "type": "object", "properties": {"path": {"type": "string"}}, "required": ["path"] } } }, { "type": "function", "function": { "name": "write_file", "description": "写入文件", "parameters": { "type": "object", "properties": { "path": {"type": "string"}, "content": {"type": "string"} }, "required": ["path", "content"] } } } ] } ) print(response.json()["choices"][0]["message"])预期第一轮返回tool_calls，包含read_file和path: "input.txt"。你手动执行读取后，把结果作为role: "tool"的消息追加回去，再发第二轮，模型应该返回write_file调用。如果模型直接编造文件内容而不调用工具，说明工具描述不够清晰，或者模型不支持 Function Calling。
4.4 验证反思触发
故意让工具调用失败，观察是否触发反思：
# 第一轮让模型读取一个不存在的文件 messages = [ {"role": "system", "content": "你可以调用 read_file。如果失败，分析原因并给出修正方案。"}, {"role": "user", "content": "读取 not_exist.txt"} ] # 模型返回 tool_call 后，你返回错误信息 messages.append({ "role": "tool", "tool_call_id": "call_xxx", "content": "Error: File not found: not_exist.txt" }) # 再发一轮，观察模型是否反思 response = requests.post( "https://taotoken.net/api/v1/chat/completions", headers={"Authorization": "Bearer sk-your-taotoken-key"}, json={ "model": "your-reasoning-model", "messages": messages } ) print(response.json()["choices"][0]["message"]["content"])预期输出应该包含类似“文件不存在，可能路径错误，建议先列出目录确认文件名”的反思内容，而不是简单重试。如果模型只是重复调用read_file，说明反思触发条件没配好，或者需要换更强的推理模型。
4.5 验证协作模式
主从模式的验证需要两个模型配合。主 Agent 收到任务后，应该输出委派指令：
master_messages = [ {"role": "system", "content": "你是主 Agent。收到任务后，判断是否需要委派给 researcher 或 coder。委派格式：DELEGATE: <worker_name> | <subtask>"}, {"role": "user", "content": "帮我调研 Python 的 asyncio 最新特性，并写一个示例"} ] response = requests.post( "https://taotoken.net/api/v1/chat/completions", headers={"Authorization": "Bearer sk-your-taotoken-key"}, json={ "model": "your-reasoning-model", "messages": master_messages } ) print(response.json()["choices"][0]["message"]["content"])预期输出应该包含DELEGATE: researcher | 调研 asyncio 最新特性和DELEGATE: coder | 写示例两行。如果主 Agent 自己开始写代码而不委派，说明 system prompt 的委派约束不够强。
5. 常见报错排查：401、local proxy failed、reading choices、OAuth
这一节对照真实报错，给出排查路径。每个报错都对应配置里的具体字段。
5.1 401 Unauthorized
最常见的原因是 Key 没复制完整，或者 Key 前面多了空格。检查api_key字段是否以sk-开头，长度是否和 TaoToken 控制台显示的一致。另一个原因是 Key 被轮换后旧 Key 失效，去 API Keys 页面 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite 确认当前有效的 Key。
如果 Key 正确但仍然 401，检查请求头格式。OpenAI SDK 用Authorization: Bearer sk-xxx，有些工具用x-api-key: sk-xxx，两者不能混。TaoToken 兼容 OpenAI 协议，统一用 Bearer 格式。
5.2 local proxy failed
这个报错通常出现在 Base URL 配置错误时。如果你写的是https://taotoken.net/api/v1，SDK 再拼/v1/chat/completions就变成/api/v1/v1/chat/completions，服务端找不到路由。正确写法是 Base URL 只到https://taotoken.net/api，让 SDK 自己拼版本路径。
另一个可能是本地网络环境有代理设置，导致请求被拦截。检查环境变量HTTP_PROXY和HTTPS_PROXY是否指向了不可用的地址。如果是公司网络，确认防火墙是否放行了taotoken.net域名。
5.3 reading choices 报错
这个报错一般是响应体解析失败。原因可能是模型返回了非 JSON 格式，或者流式响应没处理完就解析。检查请求里是否误开了stream: true但代码按非流式解析。如果用的是流式，需要逐块拼接delta.content，而不是直接读choices[0].message.content。
还有一种情况是模型 ID 写错了，服务端返回了错误页面而不是 JSON。去模型对话页 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 确认模型 ID 拼写，注意大小写和连字符。
5.4 OAuth 相关报错
如果你用的是 Claude Code 或类似工具，它可能走 OAuth 流程而不是 API Key。TaoToken 的 Claude Code 接入需要单独配置，参考文档 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 里的 ClaudeCodeAnthropic 章节。常见错误是auth.json里的base_url没改，仍然指向默认地址。需要把base_url改成https://taotoken.net/api，api_key填 TaoToken 的 Key，model_id填你要用的模型。
如果你用 CC Switch 或 Cline MCP，配置里必须同时出现三件套：Base URL、Key、Model ID。缺任何一个都会导致连接失败。Base URL 统一https://taotoken.net/api，Key 从控制台复制，Model ID 从模型对话页确认。
5.5 工具调用返回空参数
这不是报错，但很常见。模型返回了tool_calls，但arguments是空字符串。原因是工具 schema 的required字段没写全，或者参数描述太模糊。检查每个工具的parameters里是否明确列出了required数组，以及每个属性的description是否说清楚了用途。如果模型仍然不填参数，换一个 Function Calling 能力更强的模型 ID。
6. 从组件到系统：下一步怎么走
五大组件拆完，你会发现它们不是孤立的。规划决定了工具调用的顺序，工具返回的结果进入记忆，记忆里的失败记录触发反思，反思的结论影响下一轮规划，而协作则是把这一整套循环复制到多个 Agent 上并行跑。
实际落地时，建议先从规划和工具两个组件开始，跑通一个三步以内的任务。然后加入记忆，观察上下文增长曲线。等记忆稳定后，再打开反思，用故意失败的任务测试触发条件。最后才是协作，因为多 Agent 的调试成本远高于单 Agent。
如果你要长期跑编码类 Agent 任务，Coding Plan https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite 的额度模型比按次计费更适合高频工具调用。接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，遇到配置问题先查文档里的错误码对照表。模型对话页 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 可以快速验证某个模型 ID 是否可用，省去写代码测试的时间。
下一篇会进入框架实战，对比 LangChain DeepAgents、CrewAI、AutoGen 在五大组件上的实现差异。如果你现在就想动手，建议先把第 3 节的 JSON 配置复制到本地，改掉 Key 和模型 ID，跑一遍第 4 节的验证流程。跑通之后，你对手里这套 Agent 架构的边界会有完全不同的理解。
