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 生成这样的计划：
执行计划：
- 明确核心业务模块：用户模块、商品模块、订单模块、消息模块、支付模块。
- 设计数据库表结构：每个模块的实体、字段、关联关系。
- 设计核心 API 接口：RESTful 风格，列出关键接口及其入参出参。
- 考虑非功能性需求：权限控制、数据安全、异常处理、日志记录。
- 分析高并发场景：秒杀、热门商品、订单峰值的处理方案。
- 总结方案亮点与可优化点。
有了这个计划后，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 全方位对比表
| 维度 | ReAct | Plan-and-Solve | Reflection |
|---|---|---|---|
| 核心思想 | 边想边做，动态调整 | 先规划后执行 | 先完成再优化 |
| 形象比喻 | 探险家 | 建筑师 | 铸剑师 |
| 核心能力 | 环境感知与动态适应 | 结构化拆解与有序执行 | 自我审查与持续优化 |
| 工作模式 | 循环式（想→做→看→想） | 线性式（规划→执行） | 迭代式（生成→审查→优化） |
| 适合任务类型 | 探索性、实时性、工具密集型 | 结构性、多步骤、逻辑密集型 | 质量敏感、高精度要求 |
| 典型场景 | 搜索问答、数据分析、信息检索 | 报告撰写、方案设计、代码架构 | 代码审查、文章润色、方案优化 |
| 优势 | 灵活、适应性强、可解释 | 结构清晰、稳定、可复用 | 质量高、可迭代、自纠错 |
| 劣势 | 成本高、缺乏全局规划 | 计划错误会被放大、灵活性差 | 成本最高、迭代次数难控制 |
| Token 消耗 | 中到高 | 低到中 | 高到很高 |
6.3 如何选择合适的范式？
选择范式的决策逻辑其实很直觉：
问自己三个问题：
这个任务需要和外部世界交互吗？如果需要搜索、查数据库、调 API 获取实时信息——优先选ReAct。
这个任务步骤多、结构复杂吗？如果任务需要生成一份完整方案、一篇长文、一个系统设计——优先选Plan-and-Solve。
这个任务对质量要求特别高吗？如果输出需要达到"可交付"标准，比如生产级代码、正式报告——加上Reflection。
当然，很多时候答案是"都需要"，这时候就需要组合使用——这也是我们下一节要讲的内容。
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 不是所有任务都需要三种范式
当然，组合使用不等于"每次都全部用上"。根据任务特点选择合适的组合才是关键：
| 任务类型 | 推荐范式组合 |
|---|---|
| 快速搜索问答 | ReAct |
| 简单代码生成 | 直接生成 + Reflection |
| 技术方案设计 | Plan-and-Solve + ReAct |
| 长篇报告撰写 | Plan-and-Solve + ReAct + Reflection |
| 代码重构优化 | Reflection |
| 实时数据分析 | ReAct + Plan-and-Solve |
| 关键决策支持 | Plan-and-Solve + Reflection |
选择的标准不是"越多越好"，而是"够用就好"。毕竟，每多一种范式，都意味着更多的 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 │ │ 边想边干 │ 谋定后动 │ 精益求精 │ ├──────────────────┼──────────────────┼───────────────────────────┤ │ 想→做→看→想 │ 规划→执行 │ 生成→审查→优化 │ │ 🔄 循环式 │ ➡️ 线性式 │ 🔁 迭代式 │ ├──────────────────┼──────────────────┼───────────────────────────┤ │ 探险家 │ 建筑师 │ 铸剑师 │ ├──────────────────┼──────────────────┼───────────────────────────┤ │ 探索性任务 │ 结构性任务 │ 质量敏感任务 │ │ 实时信息获取 │ 多步骤推理 │ 代码审查/文章润色 │ │ 工具调用密集 │ 方案设计 │ 关键决策支持 │ └──────────────────┴──────────────────┴───────────────────────────┘选择范式的核心原则：不是越多越好，而是够用就好。根据任务特点，灵活选择单一范式或组合使用，在质量和成本之间找到最佳平衡点。
