1. 三大 Agent 设计范式到底是什么为什么面试官总盯着它问如果你刚开始接触大模型应用开发可能会被一堆名词绕晕Agent、Workflow、Multi-Agent、Tool Calling、Function Calling……但真正落到“单个智能体内部怎么思考、怎么行动、怎么纠错”这件事上行业里公认的基础设计范式其实只有三个ReAct、Plan-and-Execute、Reflection。它们不是互斥的三选一而是可以分层叠加的三块积木。搞懂这三块积木你既能应付面试里“请设计一个 Agent 架构”这类开放题也能在实际项目里判断该用哪种组合。先说清楚一个容易混淆的层级问题。Agent 设计范式描述的是单个智能体内部的运行规则也就是 LLM 如何推理、如何调用工具、如何根据反馈调整。而 Multi-Agent、SubAgent 这类概念属于系统架构编排模式它解决的是多个智能体之间怎么分工、怎么通信、怎么汇总结果。每个子 Agent 的内核依然要落到这三大范式上。面试时如果你把多智能体说成“第四大范式”基本会被追问到哑口。这三大范式分别解决什么问题ReAct 解决“边想边做”的闭环问题让模型不会冲动地直接调工具Plan-and-Execute 解决“长任务跑偏”的问题先规划再执行Reflection 解决“结果质量不稳定”的问题通过自我评估和重试来迭代优化。三者组合起来覆盖了绝大多数单 Agent 业务场景。我试过在同一个需求上分别用纯 ReAct 和 PlanReAct 组合跑差距非常明显纯 ReAct 在第三步就开始遗忘初始约束而带规划层的版本能稳定走到第八步还不跑偏。这也是为什么工业落地几乎不会只用单一范式。下面我会先讲清楚每个范式的机制和伪代码再给出可复制的 Prompt 模板最后用 TaoToken 统一 Key 和 API 通道跑通一个多轮工具调用的验证流程。你跟着做就能在自己的环境里复现三种范式的行为差异。2. 用 TaoToken 统一 Key 与 API 通道先把调用环境跑通在写 Agent 循环之前你需要一个稳定的模型调用通道。很多小白卡在第一步不同模型的 API 格式不一样Key 管理混乱切换模型要改一堆代码。TaoToken 的思路是提供一个统一的 API 入口你用同一个 Key 就能调用多种模型Base URL 和鉴权方式保持一致这样 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 之后把它放到环境变量里不要硬编码在代码中。如果你用的是 OpenAI 兼容的 SDK配置方式如下。Python 环境下可以这样设置import os from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlhttps://taotoken.net/api ) response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: 用一句话解释什么是 ReAct 范式}] ) print(response.choices[0].message.content)如果你更习惯用 curl 直接验证可以这样写curl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: 你好做个连通性测试}] }对于 Claude Code 这类工具如果你要接入需要配置三件套Base URL 填 https://taotoken.net/api Key 填你创建的 API KeyModel ID 填你实际要用的模型名称。Claude Code 的接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有详细的配置说明。如果你打算长期做编码类 Agent 开发可以考虑 Coding Plan入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 它更适合高频调用的场景。环境跑通的标准很简单上面任意一段代码能返回正常文本就说明 Key、Base URL、网络链路都没问题。接下来我们进入范式本身的实现。3. 三大范式的可复制伪代码与 Prompt 模板这一节是全文的核心我会给出每个范式的最小可运行伪代码和对应的 Prompt 模板。你可以直接复制到自己的项目里改。3.1 ReAct 范式的 Thought-Action-Observation 循环实现ReAct 的核心是一个 while 循环模型输出 Thought 和 Action你解析 Action 调用工具把 Observation 拼回上下文再让模型继续。终止条件是模型输出 Final Answer。先看 Prompt 模板这是让模型按格式输出的关键你是一个可以使用工具的智能助手。你可以使用以下工具 {tool_descriptions} 请严格按照以下格式回复 Thought: 你的推理过程说明当前需要做什么 Action: 工具名称 Action Input: 工具参数JSON 格式 当你已经获得足够信息可以回答用户问题时输出 Thought: 我已经知道最终答案 Final Answer: 你的最终回答 用户问题{user_query}对应的 Python 伪代码def react_agent(user_query, tools, max_steps8): messages [ {role: system, content: REACT_PROMPT.format( tool_descriptionsformat_tools(tools), user_queryuser_query )} ] for step in range(max_steps): response call_llm(messages) text response.choices[0].message.content if Final Answer: in text: return text.split(Final Answer:)[-1].strip() thought extract_between(text, Thought:, Action:) action extract_between(text, Action:, Action Input:) action_input extract_between(text, Action Input:, None) observation execute_tool(action.strip(), action_input.strip()) messages.append({role: assistant, content: text}) messages.append({role: user, content: fObservation: {observation}}) return 达到最大步数任务未完成这个循环的关键在于每一轮都把模型之前的输出和工具返回结果都保留在上下文里模型能看到完整的推理链路。ReAct 的优点是调试非常直观你打印 messages 就能看到模型每一步在想什么。缺点是步数一多上下文膨胀很快而且模型容易在某个步骤陷入循环。3.2 Plan-and-Execute 的规划层与执行层拆解Plan-and-Execute 把任务分成两个阶段。第一阶段用 Planner 生成步骤清单第二阶段用 Executor 逐步执行每个步骤内部可以嵌套 ReAct。Planner 的 Prompt 模板你是一个任务规划专家。请将以下复杂任务拆解为有序的子任务列表。 要求 1. 每个子任务必须是一个可独立执行的动作 2. 标明子任务之间的依赖关系 3. 每个子任务注明需要使用的工具 4. 输出 JSON 格式包含 steps 数组 任务{user_query} 输出格式 { steps: [ {id: 1, description: 子任务描述, tool: 工具名, depends_on: []}, {id: 2, description: 子任务描述, tool: 工具名, depends_on: [1]} ] }执行层的伪代码def plan_and_execute(user_query, tools): plan call_llm_for_plan(user_query) steps json.loads(plan)[steps] results {} for step in steps: context build_context(step, results) if step[tool] none: result call_llm(context) else: result react_agent(context, tools, max_steps3) results[step[id]] result if need_replan(step, result): steps replan(user_query, steps, results) return synthesize_results(results)动态重规划是 Plan-and-Execute 的亮点。每完成一个子任务你可以让模型判断结果是否符合预期如果偏差太大就重新生成后续步骤。这样既保留了全局视野又不会死板地执行错误计划。3.3 Reflection 的生成-评估-反思-重试闭环Reflection 可以叠加在任何范式之上。它的结构是先跑一轮完整任务得到初始结果然后让评估模型找问题再根据反思重新执行。评估 Prompt 模板你是一个严格的结果评审员。请检查以下任务结果是否存在问题。 原始任务{task} 执行结果{result} 请从以下维度评估 1. 是否完整回答了任务要求 2. 是否存在事实性错误或幻觉 3. 逻辑是否自洽 4. 是否有遗漏的关键信息 输出格式 { passed: true/false, issues: [问题1, 问题2], suggestions: [改进建议1, 改进建议2] }重试逻辑def reflection_agent(task, max_rounds3): result execute_task(task) for round in range(max_rounds): evaluation evaluate(task, result) if evaluation[passed]: return result reflection_context f 原始任务{task} 上一轮结果{result} 发现的问题{evaluation[issues]} 改进建议{evaluation[suggestions]} 请根据以上反思重新完成任务。 result execute_task(reflection_context) return resultReflection 的代价很直接每轮反思至少多一次评估调用和一次重试调用Token 消耗和延迟都会上升。所以在低容错场景才值得开比如代码生成、金融分析、法律文书。普通问答开 Reflection 就是浪费。4. 验证请求用统一通道跑通多轮工具调用并观察三种范式差异环境配好、代码写好之后你需要一个可验证的测试用例来观察三种范式的实际行为差异。我建议用一个需要多步工具调用的任务比如“查询北京今天天气然后根据天气推荐适合的户外活动最后用一句话总结”。先定义一个简单的天气工具和活动推荐工具def get_weather(city): return f{city}今天晴气温 22-28 度微风 def recommend_activity(weather, preference): if 晴 in weather and 微风 in weather: return 适合户外跑步或骑行 return 建议室内活动 tools { get_weather: get_weather, recommend_activity: recommend_activity }用 ReAct 跑这个任务你会看到模型先输出 Thought 说要查天气然后 Action 调 get_weather拿到 Observation 后再 Thought 说要推荐活动再调 recommend_activity最后输出 Final Answer。整个过程大概 3 到 4 轮。用 Plan-and-Execute 跑Planner 会先生成一个两步计划第一步查天气第二步根据天气推荐活动。然后 Executor 逐步执行。如果你在第一步之后插入一个检查点发现天气结果和预期不符还可以触发重规划。用 Reflection 叠加第一轮结果出来后评估模型可能会指出“总结不够具体没有提到温度范围”然后重试一轮最终结果会更完整。验证成功的标志是你能在日志里清楚看到每一轮的 messages 变化工具被正确调用最终答案符合预期。如果模型没有按格式输出 Action你需要检查 Prompt 模板是否足够明确或者在解析层加容错。对于模型对话类的快速验证你可以直接用模型对话入口 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 手动测试 Prompt 效果确认格式稳定后再写进代码。5. 本篇常见报错排查401、local proxy failed、reading choices、OAuth这一节列出你在跑 Agent 循环时最可能遇到的几个报错以及对应的排查方向。401 Unauthorized最常见的原因是 API Key 没有正确设置。检查环境变量 TAOTOKEN_API_KEY 是否为空或者 Key 是否被撤销。如果你在代码里硬编码了 Key确认没有多余空格。另外注意 Base URL 是否写成了 https://taotoken.net/api 末尾不要加斜杠。local proxy failed这个报错通常出现在你本地有网络代理配置但代理没有正常工作时。检查你的环境变量 HTTP_PROXY 和 HTTPS_PROXY 是否指向了一个不可用的地址。如果你不需要代理直接 unset 这两个变量再试。reading choices 相关报错这通常意味着 API 返回的 JSON 结构和你代码里解析的字段不匹配。比如你用的是 OpenAI SDK但返回体里没有 choices 字段可能是模型名称写错了或者请求被路由到了不兼容的端点。打印完整 response 对象确认结构。OAuth 相关报错如果你在用 Claude Code 或其他需要 OAuth 的工具报错可能出现在 token 刷新环节。检查你的配置文件里 Base URL、Key、Model ID 三件套是否完整。Claude Code 的配置文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 对照检查。模型不按格式输出 Action这不是报错但会导致解析失败。解决办法是在 Prompt 里加 few-shot 示例或者用 JSON mode 强制输出结构。如果模型频繁输出多余的解释文字可以在解析层用正则提取关键字段。循环次数超限ReAct 的 max_steps 设太小会导致任务没完成就退出设太大可能浪费 Token。建议从 8 开始根据任务复杂度调整。同时加一个重复动作检测如果连续两轮调用同一个工具且参数相同直接终止。6. 选型速查与接入入口把三大范式用熟之后选型其实有清晰的判断路径。短链路、单轮工具调用、逻辑简单的任务单用 ReAct 就够了轻量且调试方便。多步骤、长周期、结构化的复杂任务用 Plan-and-Execute 做全局规划每个子任务内部嵌套 ReAct 做灵活执行。对准确率要求极高、容错率低的专业场景在关键节点叠加 Reflection 做质量校验。大型工程任务可以在系统层用多智能体编排但每个子 Agent 的内核依然复用这三块积木。面试里被问到“你怎么设计一个 Agent 架构”时先判断任务类型再给出范式组合最后说明成本取舍。不要一上来就说“用多智能体”那会暴露你对范式层级的理解不清。如果你要开始动手接入API Key 管理入口在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。需要快速验证模型行为时用模型对话长期做编码类 Agent 开发可以看 Coding Plan。把环境跑通把三种范式的伪代码各跑一遍你对 Agent 的理解就不再停留在概念层面了。