If you read about Agents, you will see three terms repeatedly: ReAct, Plan-and-Execute, and Reflection. They are often presented side by side as competing approaches, but they actually answer different questions: What should happen next? (ReAct), how should the whole job be organized? (Plan-and-Execute), and was the result correct? (Reflection). Once that distinction is clear, choosing a pattern becomes much easier. Mature Agents often use all three together.
This guide demonstrates the patterns with one task—research three vector databases and produce a comparison report—then explains the mechanics, trade-offs, and appropriate use cases for each.
The patterns are not mutually exclusive: ReAct handles step-level decisions, Plan-and-Execute handles the overall sequence, and Reflection provides a quality backstop.
ReAct: A Step-by-Step Think-and-Act Loop
ReAct, short for Reasoning + Acting and introduced in a 2022 paper by Yao and colleagues, is the most fundamental and widely used pattern. At each step, the model first produces reasoning, or a Thought, then selects an Action. After receiving an Observation from the tool, it begins the next cycle and continues until it judges the task complete.
Thought: 需要先了解有哪些主流向量数据库
Action: search("主流向量数据库对比 2026")
Observation: [Milvus, Qdrant, Weaviate, pgvector ...]
Thought: 先查 Milvus 的部署方式和性能数据
Action: read_url("https://milvus.io/docs/...")
Observation: ...
...
Thought: 信息足够了，开始撰写对比报告
Final Answer: ...Advantages: ReAct is simple to implement and highly flexible. Every decision uses the latest observation, so the Agent can change direction immediately when a page fails to load or a result is empty. The native multi-turn tool-use loop in almost every model API with tool calling is an engineering implementation of ReAct.
Disadvantages: ReAct is shortsighted. It sees the immediate next step rather than the whole task, so a long run can take detours, jump back and forth, or retry the same dead end. Every step also carries the complete history, causing context and cost to grow linearly. It is best for exploratory work with an uncertain path and fewer than about ten steps.
Plan-and-Execute: Plan Before Acting
Plan-and-Execute separates planning from execution. First, a model—usually the strongest available—decomposes the task into a list of dependent subtasks. It then executes them one by one. The executor can itself be a ReAct loop or even a less expensive model. When assumptions change during execution, the system can replan as needed.
Plan:
1. 确定评测维度（性能、部署、生态、成本）
2. 分别调研 Milvus / Qdrant / pgvector ← 三项可并行
3. 汇总数据，生成对比表
4. 撰写结论与选型建议
Execute: 按清单逐项跑，每项内部是小型 ReAct 循环
Replan: 若某项失败或发现新信息 → 更新剩余计划Advantages: The pattern maintains a global view and keeps long tasks on course. The plan doubles as a progress tracker, allowing users to see which step is underway. Independent subtasks can run in parallel, improving speed and cost. A plan is also a natural approval point: show it to a person first and execute only after confirmation, exactly the safety design recommended in the previous guide to task boundaries.
Disadvantages: No initial plan survives every change. It is based on assumptions about the task, and when an assumption fails during execution, the system must replan. Poor replanning logic can degrade into endlessly rearranging the plan without doing any work. Adding a plan to a simple task is pure overhead. This pattern is best for composite tasks with more than ten steps and a reasonably predictable structure. Claude Code's Plan Mode and many Deep Research products are practical examples.
Reflection: Review and Revise After the Work Is Done
Reflection focuses not on how to do the task, but on whether the result is correct. After producing a draft, a model reviews it. This can be the same model under a critic prompt or a separate model. It identifies problems, revises the result using that criticism, and repeats for one or two rounds.
Advantages: Reflection can improve output quality immediately, especially for tasks with explicit standards: code, where tests and errors drive self-repair; long-form writing; and data verification. Asking a critic to work through a checklist is much easier than expecting the generator to get everything right in one pass.
Disadvantages: Cost begins at roughly double because every round adds a review and a revision. When no clear standard exists, models can fall into self-congratulation or revise without converging. You must cap the number of rounds, usually at one or two, and give the critic external signals whenever possible—test results, compiler errors, and retrieved evidence rather than a purely subjective model-to-model review.
Reflection works best when the task provides an external signal: whether tests pass, what an error says, or whether the data reconciles.
Combining the Three Patterns
The three patterns fit into one table:
| Pattern | Question It Answers | Cost | Typical Use |
|---|---|---|---|
| ReAct | What should happen next? | Low | Short exploratory tasks and tool-assisted Q&A |
| Plan-and-Execute | How should the whole task be organized? | Medium | Long tasks, multiple subtasks, and approval workflows |
| Reflection | Is the result correct? | High, often roughly double | Code, reports, and high-accuracy work |
Common combinations in practice:
- Simple Q&A with one or two tool calls: Plain ReAct is enough; do not overengineer it.
- Medium and long tasks: Use Plan-and-Execute as the structure, with ReAct inside each subtask.
- Quality-sensitive output, including code and external reports: Add Reflection at the end, driven preferably by hard signals such as tests, compilation, and validation scripts.
- Cost-sensitive work: Use a strong model for planning and a cheaper one for execution. Add review only when the value of the task justifies it; model routing can reduce cost substantially.
Frameworks such as LangGraph and LlamaIndex Workflows provide templates for all three patterns. If you implement them directly, Plan-and-Execute is little more than asking a model for a JSON plan and then executing it in a loop. It is not as complicated as it may sound.
A mature Agent often uses a plan as its skeleton, ReAct for execution, and Reflection for quality control.
Who This Is For and Common Pitfalls
This guide is for developers designing an Agent architecture or trying to understand these terms in framework documentation. Three problems appear frequently:
- Using Plan-and-Execute for a short task: If a job takes five steps, planning may cost more than execution and add unnecessary latency. Start with ReAct; upgrade only if the Agent loses its way.
- Leaving Reflection without a round limit: Two models can keep telling each other to revise forever. Stop after one or two rounds, then hand the work to a person if it is still not good enough.
- Treating a pattern as a silver bullet: These patterns solve control-flow problems. None can compensate for poor tools, weak prompts, or careless context management. See Why AI Agents Lose Control for more causes of Agent failure.
Frequently Asked Questions
Q: How does Multi-Agent architecture relate to these three patterns? A: They are orthogonal. Multi-Agent architecture assigns subtasks to multiple roles, while each role may still use ReAct or Reflection internally. In most situations, one well-planned Agent is more controllable and less expensive than a group of Agents holding meetings with one another. Build the single Agent well first.
Q: Do reasoning models such as the o-series and DeepSeek-R1 still need these patterns? A: A reasoning model internalizes part of the Thought process, so simple tasks may need less explicit planning. Tool-call loops, execution boundaries, and result validation still have to be engineered, however. The patterns are not obsolete.
Q: Which pattern should I learn first? A: ReAct. Build a loop with one model and two tools in fewer than a hundred lines of code, and log every step. Your understanding of the other two patterns will follow naturally. See Build an AI Agent from Scratch for a practical starting point.
Summary
ReAct, Plan-and-Execute, and Reflection are not competing schools. They are three building blocks for an Agent: step-level decisions, global planning, and quality review. The rule of thumb is simple: use ReAct for short tasks, add a plan for long ones, and add review for important output—and always impose a limit on every loop. Once you understand these pieces, the many framework labels, including Plan-and-Solve, LATS, and Self-Refine, are simply variations and combinations of the same three ideas.