一句话版：ReAct 像边想边干；Plan-and-Execute 像先写方案再施工；Self-Ask 像自己拆题；Self-Reflection 像干完再复盘。

---

先说一句大实话

很多人聊 Agent，聊到最后就剩一个词：工具调用。

但工具只是手脚。真正决定 Agent 好不好用的，是脑子怎么转——也就是架构模式。

2025 年被称作"AI Agent 元年"。斯坦福 2026 年 AI 指数报告指出，Agent 已从实验室走向生产环境，企业部署率同比翻了近两倍。但一个尴尬的现实是：大多数团队选架构靠感觉，跑通了就用，跑不通就推倒重来。

今天用大白话聊透四种常见模式：ReAct、Plan-and-Execute、Self-Ask、Self-Reflection。不堆术语，只讲：它像什么、适合什么、坑在哪、实战里怎么组合。

---

1. ReAct：边想边干，像现场指挥

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

你可以把它想象成：遇到问题 → 想一步 → 做一步 → 看结果 → 再想下一步。

比如问 Agent：「北京今天适合出门吗？」

它可能会这样：想"得查天气" → 做"调用天气 API" → 看"有雨" → 想"还要看看空气质量" → 做"查 AQI" → 综合判断 → 答"不太合适，建议带伞"。

优点

• 灵活，适合动态、不确定的任务
• 实现简单，LangChain、AutoGPT 等主流框架默认支持
• 能根据中间结果随时改方向，不容易一条路走到黑

缺点

• 步骤一多就容易绕圈、重复调用工具
• 长任务里前面想过的内容可能被后面忘掉（缺乏全局规划）
• Token 消耗偏高——每一步都要"想 + 做 + 看"三个动作

适合什么

• 问答、检索、轻量自动化、需要实时反馈的场景
• 工具调用次数少（≤5 步）的简单任务

不太适合什么

• 步骤很多、要求严格顺序的大项目（写长篇报告、多阶段开发、跨系统工作流）

---

2. Plan-and-Execute：先画蓝图，再开工

Plan-and-Execute = 先规划，后执行

更像项目经理：接到任务 → 拆成 1、2、3、4 步 → 按步骤执行 → 必要时微调计划。

还是"北京适合出门吗"，它的做法完全不同：

先出计划：① 查天气 → ② 查空气质量 → ③ 查用户行程 → ④ 综合给建议。然后按计划一条条执行，而不是走一步想一步。

优点

• 长任务更稳，不容易跑偏
• 结构清晰，调试方便：哪步错了，一眼能看出来
• 可以并行执行部分步骤，效率更高
• 对用户来说，"它要干什么"更透明，体验更好

缺点

• 计划阶段可能想偏——第一步规划错了，后面全白费
• 对突发变化反应慢——得重新规划（Re-plan 也要花钱）
• 实现成本比 ReAct 高（Planner + Executor 两套逻辑）

适合什么

• 写报告、做调研、数据处理、多步骤工作流
• 多文件代码生成、批量文档处理

不太适合什么

• 高度实时、环境变化特别快的任务（实时交易、即时对话博弈）

---

3. Self-Ask：自己给自己出题

Self-Ask = 把大问题拆成小问题，自问自答

核心不是"先计划"或"边想边做"，而是：大题我不会？那我先问自己几个小题，答完再拼成最终答案。

比如：「为什么最近 AI Agent 这么火？」

Agent 自己先追问五个子问题：

• 什么是 Agent？和 ChatGPT 有啥区别？
• 2024–2025 有哪些标志性产品？
• 企业为什么愿意为它买单？
• 技术瓶颈在哪？
• 未来三年会怎么发展？

一个一个答完，再合成一篇完整分析。

优点

• 特别擅长复杂、开放、需要多角度论证的问题
• 检索和推理结合好——每个子问题可以单独查资料
• 回答往往更全面，不容易漏维度
• 子问题之间相对独立，便于并行处理

缺点

• 容易问太多，子问题爆炸（5 个变成 15 个），又慢又贵
• 子问题质量决定上限——问偏了，答再好也没用
• 合成阶段可能出现前后矛盾，需要额外统一整理
• 对简单问题有点"杀鸡用牛刀"

适合什么

• 行业分析、竞品对比、知识密集型问答、深度内容创作

不太适合什么

• 简单 factual 问题（"Python 怎么读 CSV？"直接答就行）

---

4. Self-Reflection：干完再照镜子

Self-Reflection = 做完 → 自己挑毛病 → 改 → 再检查

可以单独用，也常和上面三种叠加：先按 ReAct / Plan / Self-Ask 出结果 → 再问自己"这答案靠谱吗？哪里有问题？"→ 修正 → 必要时重跑。

比如写一段代码：

第一版写出来 → 自检：边界条件处理了吗？有 bug 吗？ → 发现漏了空值判断 → 改一版 → 再检：OK，交付。

优点

• 明显提升质量，减少胡编、漏项、逻辑漏洞
• 对代码、写作、分析这类"有标准答案形态"的任务特别有效
• 可以做成固定环节，用户感知是"更靠谱了"

缺点

• 慢：至少多跑 1–2 轮 LLM
• 贵：Token 成本成倍涨
• 反思也可能过度纠错——本来对的，改错了
• 没有好的评估标准时，反思容易变成"为了改而改"

适合什么

• 代码生成、正式文档、高准确率需求的场景
• 涉及合规、财务、法律等零容错的场景

不太适合什么

• 追求极致速度的场景
• 答案本身没有明确对错的任务（比如创意文案，改来改去可能越改越没味）

---

一张表帮你快速选型

模式	一句话	最大优点	最大缺点	典型场景
ReAct	边想边干	灵活、好上手	长任务易绕圈	搜索、问答、轻量工具调用
Plan-and-Execute	先计划再执行	长任务稳、可追踪	计划错了全盘受影响	报告、调研、多步骤流程
Self-Ask	自己拆小题	复杂问题答得全	子问题过多又慢又贵	深度分析、开放性问题
Self-Reflection	做完再复盘	质量明显提升	慢、贵、可能过度改	代码、正式输出、高准确率

---

实战里怎么选？别教条

真实产品里，很少只用一种。

常见组合：

• ReAct + Reflection：灵活干活，最后质检一遍。很多 coding agent 接近这种——先写出代码，再自检修复。
• Plan-and-Execute + Reflection：大项目先拆步，每步或整体再复盘。适合正式报告、合规文档生成。
• Self-Ask + ReAct：复杂问题先拆题，每个子问题用 ReAct 查和答。适合深度调研。
• Plan + Self-Ask：先粗规划，某几步再细拆子问题。大型分析项目常用。

行业实践中有一种更通用的模式——混合架构（Hybrid）：系统先判断任务复杂度，简单任务走 ReAct 快速通道，复杂任务切 Plan-Exec 模式，关键步骤加 Reflection 校验。这是目前生产环境 Agent 的主流做法。

选型记三句话就够了：

• 任务短、变化快 → 优先 ReAct
• 步骤多、要可控 → 优先 Plan-and-Execute
• 问题大、要挖深 → 加 Self-Ask
• 不能错、要交付质量 → 加 Self-Reflection

---

动手建议：别一上来就追最炫的

很多团队踩过的坑：一上来就搞混合架构 + 多模型调度 + 动态路由，结果调试两周还没跑通一个简单场景。

上手顺序建议（业界共识）：

1. 先做 ReAct：串通"思考 → 行动 → 观察"闭环，实现一个可调用工具的极简 Agent。这是所有模式的地基。
2. 再学 Plan-Exec：理解任务分解，处理明显多阶段的复杂需求。
3. 引入 Reflection：给自己加个质检环节，感受质量提升和成本增加之间的权衡。
4. 最后走混合模式：加入动态路由、状态管理、日志监控、失败降级。到这一步，你已经不是在做 demo 了，是在做产品。

架构是手段，不是目的。用户要的是：快、准、稳、省钱——这四个里你最多同时满足三个，得根据业务做取舍。

---

结尾

你平时用的 AI 产品，更像哪一种？

• A：问一句答一句（偏 ReAct）
• B：先列计划再一步步做（偏 Plan）
• C：会拆成很多小问题（偏 Self-Ask）
• D：会自我检查、改稿（偏 Reflection）

评论区聊聊，或者转发给正在做 Agent 的朋友——选对脑子，比堆工具重要。

---

本文参考：斯坦福 2026 AI 指数报告、LangChain/LlamaIndex 架构文档、"技术栈"社区 AI Agent 架构设计与实践系列。