别再只会调工具了！三种 Agent 范式，教你看懂智能体到底怎么“自己干活“

1 你以为 Agent 就是"会调 API 的聊天机器人"？

如果你最近在技术圈子里混，大概率听过这样的对话：

“你搞 Agent 了吗？”
“搞了啊，就是让大模型调工具嘛，加个搜索、加个计算器，完事了。”
“哇，好厉害！”

这段对话的问题在于——它把 Agent 理解成了"会按按钮的大模型"。

但真正的 Agent，核心价值不在于"能调几个 API"，而在于它怎么思考、怎么行动、怎么规划、怎么反思。换句话说，Agent 真正的灵魂不是工具，而是它的工作方法。

这篇文章就讲清楚三种经典范式：ReAct（边想边干）、Plan-and-Solve（谋定后动）、Reflection（交稿前自己审三遍）。读完之后再看各种 Agent 框架，你就能真正看懂：智能体到底是怎么工作的。

2 先搞清楚一个问题：Agent 和普通大模型到底差在哪？

2.1 普通大模型：一个超级学霸，但只能"一问一答"

你可以把普通大模型想象成一个学识渊博但非常"被动"的人。

你问他："地球到月球有多远？"他脱口而出：384,400 公里。

你再问：“那如果我要造火箭去月球，需要多少燃料？”

他可能会给你一个基于训练数据的估算，但这个数字准不准？他自己也不知道。因为他不能去查 NASA 的最新数据，不能打开计算器精确运算，更不能说"等等，我觉得这个问题的前提条件需要再确认一下"。

他只能基于"记忆中见过什么"来回答。这就是普通大模型的局限：知识有截止日期，无法与真实世界交互，不能主动拆解复杂任务。

2.2 Agent：学霸 + 工具箱 + 工作方法

Agent 在"学霸"的基础上，多了两样东西：

第一，工具箱。 它能调用搜索引擎查最新信息，用计算器做精确运算，访问数据库读取业务数据，甚至操作浏览器、发邮件、写文件。

第二，也是更重要的——工作方法。 它不是拿到问题就直接回答，而是会判断：

• 当前信息够不够？
• 要不要先搜索一下？
• 这个任务要不要拆成几步？
• 生成的结果靠不靠谱？
• 要不要再检查一遍？

这种"判断—行动—观察—调整"的能力，才是 Agent 和普通大模型的本质区别。

而不同的"工作方法"，就构成了我们今天要讲的三种范式。

3 ReAct：边想边干，见招拆招

3.1 一句话理解 ReAct

ReAct = Reasoning（推理） + Acting（行动）。

翻译成人话就是：想一步，做一步，看结果，再调整。

如果你是一个喜欢"边走边看"的人，那你天生就是一个 ReAct 选手。

3.2 从一次旅行说起

假设你打算周末去一个从没去过的城市玩一天。

你会在周一就把每个小时干什么都安排得死死的吗？大概率不会。因为你不知道那天天气如何、景点是否开放、网红餐厅要不要排队、地铁线路有没有临时调整。

你更可能的做法是：

整个过程，你没有提前规划好一切，而是根据每一步获取到的新信息，不断调整下一步行动。

这就是 ReAct 的精髓。

3.3 ReAct 的技术流程

在 Agent 的技术语境下，ReAct 的工作流程是一个不断循环的三步：

Thought（思考） → Action（行动） → Observation（观察） → 回到 Thought …

具体来说：

Thought（思考）：Agent 分析当前掌握的信息，判断下一步应该做什么。这一步是纯粹的"推理"，不涉及任何工具调用。Agent 会想：“用户问的是最新产品价格，我的训练数据可能已经过时了，需要搜索一下。”

Action（行动）：Agent 根据思考结果，选择并调用合适的工具。可能是搜索引擎、计算器、数据库查询、API 调用，甚至代码执行。

Observation（观察）：工具返回结果后，Agent 把这些结果当作新的"事实依据"，重新进入思考阶段。

这个循环会一直持续，直到 Agent 判断"信息已经足够，可以给出最终答案"为止。

3.4 一个更贴近开发的例子

用户问 Agent：

“帮我整理一下最近适合学生党的轻薄本推荐，预算 4000-6000 元。”

这个问题，模型记忆中的信息大概率是过时的。电脑价格会波动，新品会发布，老款会降价。

一个 ReAct Agent 的处理过程可能是这样的：

第一轮：

• Thought：需要最新的笔记本推荐信息，先搜索一下近期热门轻薄本。
• Action：调用搜索引擎，搜索"2026 年学生轻薄本推荐 4000-6000 元"。
• Observation：得到了若干品牌和型号的推荐列表。

第二轮：

• Thought：列表里有七八款，但不知道哪些真正适合学生。学生的核心需求是：轻便、续航长、性能够用、性价比高。我来筛选一下。
• Action：针对其中几款搜索详细评测和用户反馈。
• Observation：获取到了各款的重量、续航、性能跑分、用户口碑。

第三轮：

• Thought：信息差不多了，但有两款价格近期波动比较大，再确认一下实时价格。
• Action：查询电商平台实时价格。
• Observation：发现其中一款正在做活动，性价比突然变高了。

第四轮：

• Thought：现在信息充分了，可以生成推荐了。
• Action：输出最终推荐结果。

你看，Agent 不是一次性把答案"想"出来的，而是通过多次与外部世界交互，逐步拼出了完整答案。

3.5 ReAct 的三大优势

第一，环境适应性强。 外部信息变了，Agent 可以通过工具获取最新数据。它不会被"训练数据截止日期"限制住。

第二，动态纠错能力强。 第一次搜索关键词不好？没关系，换一个再搜。工具返回不完整？可以继续追问。这种"见招拆招"的能力让 Agent 在面对不确定性时非常灵活。

第三，可解释性好。 通过 Thought 链，你可以看到 Agent 每一步在想什么、为什么选择调用这个工具、看到结果后又做了什么判断。这种透明度对于调试和信任建立非常重要。

3.6 ReAct 的两个"坑"

当然，ReAct 不是万能的。

第一个坑：成本高。 每一轮"思考—行动—观察"都需要调用一次大模型，如果任务复杂，可能需要循环五六次甚至更多。这意味着更多的 API 调用、更长的响应时间、更高的 Token 消耗。

第二个坑：缺少全局视野。 ReAct 的本质是"走一步看一步"，这在探索性任务中是优势，但在步骤明确、结构复杂的任务中就成了劣势。它可能会在某些环节反复尝试，甚至偏离最优路径——就像一个没有导航的司机，虽然最终也能到目的地，但可能绕了不少弯路。

3.7 ReAct 小结

一句话总结：

ReAct 是一个"边走边查边判断"的执行者，最适合探索性强、需要实时信息、依赖外部工具的任务。

如果用游戏角色类比，ReAct 就像是一个探险家——没有详细地图，但有指南针和望远镜，每走一步都在观察地形、调整方向。

4 Plan-and-Solve：谋定而后动，步步为营

4.1 一句话理解 Plan-and-Solve

如果说 ReAct 是"边走边看"，那 Plan-and-Solve 就是"先画好路线图，再按图索骥"。

它的核心逻辑是两个阶段：

• Planning（规划）：先把任务拆解成清晰的步骤。
• Solving（执行）：按照步骤逐步完成。

4.2 从一次 PPT 汇报说起

假设你要做一个课程项目的汇报 PPT。

如果你一上来就打开 PowerPoint 开始做，大概率会出现这种情况：

• 第一页写了项目背景。
• 第二页突然想到一个技术亮点，赶紧写上。
• 第三页又觉得应该先讲需求分析。
• 做到一半发现顺序乱了，开始大调整。
• 最后匆匆收尾，总结页只有两行字。

但如果你先花十分钟列一个大纲呢？

有了这个框架，再逐页填充内容，效率和质量都会高得多。

这就是 Plan-and-Solve 的核心价值：面对复杂任务，先结构化拆解，再逐步执行，远比"想到哪做到哪"更靠谱。

4.3 Plan-and-Solve 的技术流程

在 Agent 的技术实现中，Plan-and-Solve 分为两个明确阶段：

阶段一：Planning（规划）

Agent 拿到任务后，不是立刻动手，而是先生成一个执行计划。这个计划会回答以下问题：

• 这个任务可以拆成哪几个子任务？
• 每个子任务的先后顺序是什么？
• 哪些子任务之间有依赖关系？
• 最终输出应该如何组织？

阶段二：Solving（执行）

按照计划中的步骤，逐一完成。每完成一步，Agent 都会对照计划，确认进度和方向。

4.4例如

用户说：

“帮我设计一个校园二手交易平台的后端方案。”

这是一个典型的复杂任务。如果 Agent 直接开写，很容易变成一锅粥：一会说数据库设计，一会跳到接口定义，突然又插了一段安全方案。

Plan-and-Solve 会先让 Agent 生成这样的计划：

执行计划：

有了这个计划后，Agent 再逐步展开每一部分的内容。最终输出的方案，结构清晰、逻辑完整、覆盖全面——就像一份真正经过深思熟虑的技术文档，而不是即兴发挥的随笔。

4.5 Plan-and-Solve 的深层价值

Plan-and-Solve 的价值不仅仅是"有条理"，它还解决了大模型的一个核心痛点：长文本生成时的逻辑漂移问题。

你可能注意到，如果让大模型一次性生成一篇很长的文章或方案，前半部分和后半部分的逻辑连贯性往往会下降。这是因为模型在生成过程中，"注意力"会逐渐偏移。

Plan-and-Solve 通过先拆解再执行的方式，相当于给模型一个"导航仪"。每一步都只需要专注于当前子任务，而不需要在脑子里同时装着整个任务的全貌。这大大降低了逻辑漂移的风险。

4.6 Plan-and-Solve 的三大优势

第一，结构性强。 输出结果天然有清晰的层次和逻辑，特别适合需要"方案感"的任务。

第二，稳定性高。 因为执行路径是预先规划好的，不会像 ReAct 那样出现"绕弯路"或"跑偏"的情况。

第三，可复用性好。 同一个任务的计划模板可以被复用。比如"设计后端方案"的计划，对不同项目都可以套用类似的结构。

4.7 Plan-and-Solve 的两个风险

第一个风险：计划本身的错误会被放大。

如果规划阶段就出了问题，后面执行得再认真也是在错误方向上越走越远。比如设计后端方案时，计划中遗漏了"权限控制"这个模块，那后面所有内容都不会涉及安全设计。而在 ReAct 范式中，这种遗漏可能会在后续搜索或工具调用时被"意外发现"并弥补。

第二个风险：灵活性不足。

Plan-and-Solve 假设任务的执行路径是可以提前规划的，但现实中很多任务充满了不确定性。如果执行过程中发现计划需要大改，Agent 可能缺乏动态调整的能力。

4.8 Plan-and-Solve 小结

一句话总结：

Plan-and-Solve 是一个"先画蓝图再施工"的规划者，最适合结构清晰、步骤明确、逻辑密集的任务。

如果继续用游戏角色类比，Plan-and-Solve 就像是一个建筑师——在动第一块砖之前，已经有了完整的施工图纸。每一步施工都严格按照图纸执行，确保最终建筑的结构稳固、功能完整。

5 Reflection：交稿之前，自己先审三遍

5.1 一句话理解 Reflection

ReAct 解决"怎么边做边调"，Plan-and-Solve 解决"怎么先拆再做"，而 Reflection 解决的是一个完全不同的问题：

结果出来了，但不够好，怎么办？

Reflection 就是给 Agent 装上一个"内置审稿人"：生成结果后，不是直接交付，而是自己检查一遍、发现问题、修改优化，然后再检查、再优化——直到质量达标。

5.2 其实你每天都在用 Reflection

Reflection 听起来很"高级"，但其实你在日常工作中一直在用它：

• 写作文：第一版叫初稿，改完之后叫终稿，有些人的终稿和初稿几乎不是同一篇文章。
• 写代码：第一版写完能跑，然后做 Code Review，发现命名不规范、边界条件没覆盖、性能可以优化，于是重写一版。
• 做题：算完答案之后验算一遍，发现中间某一步算错了，赶紧改过来。
• 写方案：交付前检查一遍，发现有个重要场景遗漏了，赶紧补上。
• 发邮件：写完之后读一遍，觉得措辞不太合适，改了几个词再发出去。

这些行为的本质都是一样的：第一版不求完美，但求有；然后通过反复审查和修改，让结果从"能用"变成"好用"。

Reflection 就是把这种人类习以为常的"自我迭代"能力，赋予了 Agent。

5.3 Reflection 的技术流程

Reflection 的工作流程分为三个核心阶段：

Execution（执行） → Reflection（反思） → Refinement（优化） → 回到 Reflection …

Execution（执行）：Agent 先生成一个初始结果。这个结果可以是代码、文章、方案、分析报告——任何类型的输出。

Reflection（反思）：Agent 切换到"审查者"角色，对初始结果进行严格审查。它会问自己一系列问题：

• 结果是否正确？有没有事实性错误？
• 逻辑是否连贯？有没有前后矛盾？
• 是否覆盖了所有重要方面？有没有遗漏？
• 有没有更优的实现方式？
• 是否符合目标受众的需求？

Refinement（优化）：根据反思阶段发现的问题，Agent 对结果进行针对性修改。

这个"反思—优化"的循环可以执行多轮，直到结果质量达到预期标准。

5.4 代码场景：写一个限流工具类

用户让 Agent 写一段代码：

“用 Java 实现一个接口限流工具类，支持滑动窗口算法。”

第一版（Execution）：Agent 生成了一段代码。能编译、能运行、基本逻辑也对了。

审查阶段（Reflection）：Agent 切换成"高级工程师"视角，对代码进行审查：

• 并发安全：多个线程同时调用时，计数器的原子性有保证吗？用了 AtomicInteger 还是普通的 int？
• 异常处理：如果传入的参数是 null 或者负数，会抛异常吗？有友好的错误提示吗？
• 边界条件：窗口大小为 0 或者 1 的时候，算法还正确吗？
• 扩展性：限流策略是硬编码的，还是可以通过策略模式替换的？
• 可测试性：核心逻辑是否容易写单元测试？
• 代码规范：变量命名是否清晰？关键逻辑有没有注释？

第二版（Refinement）：Agent 根据上述反馈，重写代码：引入 ConcurrentHashMap 保证线程安全、增加参数校验、抽取策略接口提升扩展性、补充关键注释。

再来一轮（可选）：Agent 甚至可以再审查一次第二版代码，看看还有没有遗漏——比如是否考虑了分布式场景、是否需要引入 Redis 做跨实例限流。

这个过程的价值，远不只是"修了几个 Bug"。它让最终输出从"能用"变成了"可靠"，从"Demo 级别"变成了"生产级别"。

5.5 写作场景：写一篇公众号文章

再来看一个非代码场景。

用户让 Agent 写一篇关于"程序员如何保护颈椎"的公众号文章。

第一版：文章写完了，信息完整，有病因分析、有动作建议、有就医提醒。但读起来像一篇医学百科——正确，但无趣。

审查阶段：Agent 从"读者体验"角度重新审视：

• 开头：第一句话是"颈椎病是一种常见的退行性疾病"——读者到这就划走了。能不能换成一个更有代入感的开头？比如"你有没有过这种体验：加完班站起来，脖子像被灌了水泥？"
• 段落长度：有好几段超过 200 字，在手机屏幕上就是一整面文字墙。能不能拆短？
• 重点突出：关键建议混在大段文字里，不够醒目。能不能加粗、加小标题？
• 例子和比喻：全程都是专业术语，能不能用更生活化的比喻？比如"你的颈椎就像一个 24 小时值班的保安，你越不理它，它越会闹脾气"。
• 结尾：平平淡淡的"希望对你有帮助"——能不能给读者一个立刻能做的行动？比如"现在就放下手机，做三个颈部环绕动作"。

第二版：根据反馈重写，文章风格大变：开头有共鸣感，中间有节奏感，结尾有行动感。

这就是 Reflection 的威力——它不只是"纠错"，更是从"能用"到"好用"的质变过程。

5.6 Reflection 的三大核心价值

第一，内置纠错回路。 Reflection 不依赖外部工具来发现问题，而是让 Agent 自己成为自己的"质检员"。这种自我审查能力在很多没有外部反馈渠道的场景中尤其重要。

第二，提升最终质量。 对于代码、方案、报告、文章这类"质量没有上限"的任务，Reflection 提供了持续优化的机制。每一次反思循环，都在把结果推向更高的质量标准。

第三，形成迭代记忆。 Agent 不仅知道最终答案，还保留了"初稿—反馈—修改"的完整过程。这种过程信息对于理解"为什么最终方案是这样的"非常有价值，也为后续的多轮优化提供了基础。

5.7 Reflection 的成本与适用边界

Reflection 不是免费的午餐。

每一次"反思 + 优化"循环，至少需要额外调用两次大模型（一次审查，一次修改）。如果反复迭代三四轮，成本和耗时都会显著增加。

所以，Reflection 本质上是一种用时间和成本换质量的策略。

适合使用 Reflection 的场景：

• 生产级代码生成
• 正式技术报告或方案
• 复杂逻辑分析与推理
• 高质量内容创作
• 关键业务决策辅助

不太适合的场景：

• 快速问答（“今天星期几？”）
• 简单的格式转换
• 对质量要求不高的临时任务

简单来说：如果你只需要一个"60 分答案"，直接生成就够了；但如果你需要"90 分答案"，Reflection 几乎是必经之路。

5.8 Reflection 小结

一句话总结：

Reflection 是一个"自带审稿人和质检员"的智能体，最适合对准确性、可靠性和最终质量要求极高的场景。

如果用游戏角色类比，Reflection 就像是一个铸剑师——第一版是粗锻，第二版是精磨，第三版是淬火。每一轮都不是推倒重来，而是在上一版基础上让作品变得更锋利、更坚韧、更完美。

6 三种范式的深度对比：什么时候该用谁？

6.1 核心差异一句话版

讲到这里，我们可以用最简洁的方式区分三种范式：

• ReAct 解决的是：信息不够的时候怎么办？ 答案是——去行动、去获取、去交互。
• Plan-and-Solve 解决的是：任务太复杂的时候怎么办？ 答案是——先拆解、再规划、后执行。
• Reflection 解决的是：结果不够好的时候怎么办？ 答案是——自己审、找问题、再优化。

6.2 全方位对比表

6.3 如何选择合适的范式？

选择范式的决策逻辑其实很直觉：

问自己三个问题：

当然，很多时候答案是"都需要"，这时候就需要组合使用——这也是我们下一节要讲的内容。

7 组合拳才是王道：三种范式的协同作战

7.1 真实场景中的 Agent 不会只用一种范式

在实际项目中，一个成熟的 Agent 系统很少只用单一范式。就像现实中的优秀工作者，往往是"身兼数职"的：

• 接到任务时，先规划（Plan-and-Solve）。
• 执行过程中，根据需要搜索和交互（ReAct）。
• 完成后，自己检查一遍（Reflection）。

7.2 一个完整的例子：生成行业分析报告

假设你的 Agent 要完成这个任务：

“帮我生成一份 2026 年中国新能源汽车行业分析报告，面向投资人。”

这个任务同时具备以下特征：

• 结构复杂：报告需要包含市场规模、竞争格局、技术趋势、政策分析、投资建议等多个维度。
• 需要实时信息：市场数据、政策动向、企业财报都是最新的。
• 质量要求高：面向投资人，不能有事实性错误，逻辑必须严谨。

一个优秀的 Agent 会这样工作：

第一步：Plan-and-Solve——规划报告结构

1. 行业概览与市场规模
2. 竞争格局与主要玩家
3. 技术发展趋势
4. 政策环境与监管动态
5. 产业链分析
6. 投资机会与风险提示
7. 结论与建议

第二步：ReAct——搜索填充每个章节

对于"市场规模"章节：

• Thought：需要最新的市场规模数据。
• Action：搜索 2026 年新能源汽车销量数据。
• Observation：获取到 2026 年 1-5 月的销量统计。
• Thought：还需要同比数据和增长率。
• Action：搜索同比数据。
• Observation：获取到完整数据。

对于"政策环境"章节：

• Thought：需要了解最新的补贴政策和其他相关政策。
• Action：搜索 2026 年新能源汽车相关政策。
• Observation：获取到政策清单。

…依次类推。

第三步：Reflection——审查与优化

• 数据是否准确？有没有前后矛盾的数字？
• 逻辑是否连贯？从行业概览到投资建议，推理链条是否完整？
• 有没有遗漏重要信息？比如某个重要的新入局者没提到？
• 表达是否专业？面向投资人的报告，措辞不能太口语化。
• 结论是否有充分的数据支撑？不能"拍脑袋"给建议。

根据审查结果，修改并优化报告。

7.3 组合使用的流程图

接到任务
↓
Plan-and-Solve：规划任务结构与执行路径
↓
ReAct：按计划逐步执行，通过工具获取外部信息
↓
生成初始结果
↓
Reflection：审查结果，发现问题
↓
优化结果
↓
（可选）再次 Reflection
↓
输出最终结果

这个流程体现了一个完整的 Agent 工作流：

先规划 → 再行动 → 看反馈 → 再优化

这才是 Agent 真正有价值的地方——它不是简单地"调用一次大模型生成一段文字"，而是在执行一个有策略、有章法、有质控的完整工作流程。

7.4 不是所有任务都需要三种范式

当然，组合使用不等于"每次都全部用上"。根据任务特点选择合适的组合才是关键：

选择的标准不是"越多越好"，而是"够用就好"。毕竟，每多一种范式，都意味着更多的 Token 消耗和更长的响应时间。

8 超越三种范式：Agent 的未来方向

讲完三种经典范式，有必要简单展望一下 Agent 领域正在发生的变化。

8.1 多 Agent 协作

三种经典范式聚焦的是单个 Agent 如何工作。但在更复杂的场景中，可以让多个 Agent 分工协作：

• 一个 Agent 负责搜索信息（ReAct 专家）。
• 一个 Agent 负责结构化规划（Plan-and-Solve 专家）。
• 一个 Agent 负责质量审查（Reflection 专家）。
• 一个"管理者" Agent 负责协调它们。

这种多 Agent 架构在 LangGraph、AutoGen 等框架中已经开始普及。

8.2 记忆与学习

经典范式中的 Agent 是"无状态"的——每次任务都从零开始。但更先进的 Agent 系统会引入长期记忆：

• 记住用户偏好：这个用户喜欢简洁风格还是详细风格？
• 记住任务经验：上次类似的报告，哪些章节被要求修改了？
• 记住工具使用经验：这个搜索 API，用什么关键词效果更好？

这种"越用越聪明"的能力，是 Agent 从"工具"进化为"助手"的关键。

8.3 主动性与自主性

当前的 Agent 还是"被动接受任务"的模式。未来的 Agent 可能会更加主动：

• 发现你的代码有潜在问题，主动提醒你。
• 注意到你关注的行业新闻有新动态，主动推送给你。
• 在执行任务过程中发现更好的方案，主动建议调整。

从"你让它做什么它就做什么"到"它能主动帮你想到你没想到的"——这是 Agent 发展的长远方向。

9理解范式，才能真正理解 Agent

回到文章开头那个问题：Agent 到底是什么？

如果你只看表面，Agent 就是"大模型 + 工具调用"。

但如果你理解了今天讲的三种范式，你会发现 Agent 的真正价值不在于"能调几个 API"，而在于它能像一个有方法论的工作者一样完成任务：

• 信息不够的时候，它会像探险家一样主动出击，通过行动获取反馈，在不确定中找到方向。
• 任务复杂的时候，它会像建筑师一样先画蓝图，按部就班地拆解和执行，确保结构完整。
• 结果不够好的时候，它会像铸剑师一样反复打磨，审查问题、持续优化，直到质量达标。

这三种能力——动态适应、结构化规划、自我优化——构成了 Agent 的"工作灵魂"。

而更让人兴奋的是，这三种能力不是互斥的，而是可以组合使用的。一个真正成熟的 Agent，就像一个经验丰富的专业人士：接到任务后先规划，执行过程中灵活应变，完成后认真复盘。

所以，下次当有人告诉你"Agent 就是让大模型调工具"的时候，你可以笑着回他一句：

“调工具只是手脚，会思考才是灵魂。”

附录：一张图看懂三种 Agent 范式

┌─────────────────────────────────────────────────────────────────┐
│ Agent 三大经典范式 │
├──────────────────┬──────────────────┬───────────────────────────┤
│ ReAct │ Plan-and-Solve │ Reflection │
│ 边想边干 │ 谋定后动 │ 精益求精 │
├──────────────────┼──────────────────┼───────────────────────────┤
│ 想→做→看→想 │ 规划→执行 │ 生成→审查→优化 │
│ 🔄 循环式 │ ➡️ 线性式 │ 🔁 迭代式 │
├──────────────────┼──────────────────┼───────────────────────────┤
│ 探险家 │ 建筑师 │ 铸剑师 │
├──────────────────┼──────────────────┼───────────────────────────┤
│ 探索性任务 │ 结构性任务 │ 质量敏感任务 │
│ 实时信息获取 │ 多步骤推理 │ 代码审查/文章润色 │
│ 工具调用密集 │ 方案设计 │ 关键决策支持 │
└──────────────────┴──────────────────┴───────────────────────────┘

选择范式的核心原则：不是越多越好，而是够用就好。 根据任务特点，灵活选择单一范式或组合使用，在质量和成本之间找到最佳平衡点。