这篇文章不讲技术细节，不讲代码。它只讲一件事：你手机里那个会自己干活的 AI，到底是怎么想事情的。
你跟 AI 说：我明天要去北京出差，穿什么合适。
普通聊天 AI 会怎么做？它会问你：北京明天什么天气？你得自己去查，回来告诉它。它再根据温度给你建议。你全程得牵着它走，一步一问。
但如果你用的是 Agent，你只需要说那一句话。它自己去查天气，自己判断温度湿度，自己整理出穿衣建议。你什么都没做，事情办完了。
两种体验之间差的东西，就叫 Agent 范式。
Agent 就是能自己干活、自己用工具的 AI。范式，就是它做事的方式。人做事有不同的方法，Agent 也是。任务执行的主流方式有两种，每一种都对应一种你很熟悉的人类习惯。此外还有一个重要的增强机制，它的职责不是完成任务本身，而是让任务结果变得更好。
---
ReAct，全称 Reasoning + Acting。说人话就是：走一步看一步。
你在厨房做菜。放了一勺盐，尝一口，淡了。再加半勺，再尝，OK 了。你不会一开始就把所有调料精确称好全部倒进去，因为中间的味道变化你预判不了。ReAct 就这样：想一想，做一步，看一眼结果，再想下一步。
举个例子。你让 Agent 整理一份竞品分析。它先想，我得知道有哪些竞品，于是去搜索。搜完一看，出来五家公司。它再想，下一步要对比定价策略，于是去查每家公司的价格页。查完发现有两家没公开价格，它再想，那就用第三方评测数据代替。
每一步的行动，取决于上一步的结果。不是一次性全规划好再执行，像做菜，边走边调。
这范式的优势是灵活，遇到意外能当场转弯。劣势是可能绕路，如果中间一步想偏了，要兜几个圈子才能拐回来。但现实里大部分复杂任务都不是线性的，所以 ReAct 是目前最常用的范式。你手机里那些 AI 助手，底层大概率跑的就是它。
不过说一句现实情况：手机里的 ReAct 不是无限自由的。真实产品会加大量护栏，最多调用几轮工具就停，关键操作要你点确认，敏感行为直接拦截。纯自由的走一步看一步，只存在于实验室里。
---
Plan-and-Solve，翻译过来就是：先想清楚再动手（工程领域也常称 Plan-and-Execute）。
你装修房子，不会先让工人把墙砸了再说。你会先画设计图，确定每个房间的布局，算好水电走线，确认所有材料清单，然后才让施工队进场。Plan-and-Solve 做的就是这件事：花时间做一个完整计划，一口气执行。
回到竞品分析。Agent 会先停下来思考：我需要做三件事，确认竞品名单、收集定价数据、生成对比表格。规划好了之后，按顺序一步接一步地跑。中间不会突然改主意，因为方向在规划阶段已经锁定了。
优势是效率高，目标明确。劣势是僵化。如果跑到一半发现某个数据源打不开了，原始版本的 Plan-and-Solve 会卡住。不过现在很多实现在规划阶段就留了弹性接口，不完全绑死。
---
Reflection。字面意思是反思，但翻译成复盘更贴切：做完之后自己检查。
有一点要先说清楚：Reflection 跟前面两个不太一样。ReAct 和 Plan-and-Solve 是任务执行范式，解决怎么干活的问题。Reflection 是一个增强机制，解决干完之后怎么改得更好的问题。它没法独立完成一个任务，必须依附在执行范式身上，像一个质检员跟在工人后面。
你写完一篇稿子，通读一遍，发现有句重复了，删掉。再看一遍，发现数据引用没标来源，补上。第三遍，觉得开头太啰嗦，改短。这个过程就是 Reflection。
Agent 的做法：先按正常流程生成一个结果。然后切换角色，变成一个审查员，用更挑剔的眼光审视刚才的输出。它检查逻辑有没有漏洞、数据是否准确、格式是否统一。发现问题后，指出哪些要改，再重新生成。
工程上还有更灵活的做法：不一定等全部任务跑完才复盘。ReAct 那种走一步看一步的模式里，可以每走一步就自查一次，发现不对立刻回头重来，不用攒到最后一起改。学术论文里这个机制的原名叫 Reflexion，甚至会把失败经验沉淀成长期记忆，跨任务复用。文章讲的是最容易理解的全局版本。
代价很直白：多花 token。一次反思等于多跑一轮推理，算力成本翻倍甚至更多。但产出质量的提升也非常明显。尤其在代码生成和数学推理这种容错率低的场景里，加不加 Reflection，效果是质变。
---
这三种机制不是非此即彼的。实际项目里一般都混着用：用 Plan-and-Solve 定大方向，每一步的具体执行走 ReAct 的边想边做，Reflection 在中间和结尾都可以介入自查修正。这其实就是现在市面上大部分 Agent 产品的底层运转方式。
你可能会问，这些范式谁在跑？总不能每次都要程序员手写循环逻辑吧。
这就要说一个配套概念了：Runtime。
你把 Agent 想象成一个人，Runtime 就是它的神经系统。呼吸怎么换气、心跳怎么跳、脚迈出去之后重心怎么转移，这些底层操作你不需要有意识地去控制，神经系统自动帮你做了。Runtime 也一样：Agent 思考和执行的循环逻辑、工具调用的调度、对话记忆的管理、出错后的重试，这些杂活它全包圆了。
开发者拿到一个 Runtime，只需要告诉它三件事：你用哪个模型、你能用哪些工具、你要完成什么任务。剩下的推理循环、记忆拼接、容错恢复，Runtime 自己跑。开发者的精力从怎么让 Agent 转起来变成了让 Agent 做什么。
这也是为什么这两年开源社区里 Agent 工程栈多到像超市货架。像 codex、grok-build 这类项目，直接内置了完整的运行时循环。你只需要给它指定一个底层大模型（比如 Claude、GPT 或者 Pi 这类对话模型），写好 prompt，它就跑起来了。Runtime 负责循环和调度，模型负责推理，各管各的。跟几年前什么都要从零手写相比，这个变化用一个词来形容就是：从荒漠到了超市。
---
这篇文章不打算给你讲技术细节。重要的是你有了一个认知框架：下次有人聊 Agent，你不会觉得那是一团模糊的黑箱。你知道它分几种做事方式，知道这些方式跟人类做事的习惯是通的，知道有一层叫 Runtime 的东西在底下默默撑着这一切。
而这些东西，现在确实已经在你手机里了。