id, title, type, domain, stack, tags, level, prerequisites, est_hours, related, week, order
| id |
title |
type |
domain |
stack |
tags |
level |
prerequisites |
est_hours |
related |
week |
order |
| ai.agent-design.react-planning |
Agent 推理模式:ReAct、Plan-and-Execute、反思和 Agentic RAG |
lesson |
ai |
|
| ReAct |
| Plan-and-Execute |
| 规划 |
| 反思 |
| Agentic RAG |
| 工作流 vs Agent |
|
intermediate |
| ai.function-calling.tool-loop |
|
3 |
| ai.agent-design.context-skills-multiagent |
| ai.langgraph.state-graph |
| ai.agent-design.interview |
|
|
1 |
Agent 推理模式:ReAct、Plan-and-Execute、反思和 Agentic RAG
解释说明
先问:真的需要 Agent 吗?
| 形态 |
特点 |
适合 |
| 单次调用 |
一个提示词一次输出 |
分类、提取、改写 |
| 工作流(Workflow) |
步骤由代码固定,模型只完成其中的环节 |
流程明确的业务:工单分类 → 起草 → 审批 |
| Agent |
模型自己决定下一步做什么、调用什么工具、何时结束 |
步骤不固定、需要探索的任务:排查问题、调研、复杂查询 |
企业里大多数需求用工作流就够了,更可控、更便宜、更好评测。Agent 用在确实需要灵活性的地方,并且要有步数、预算、权限的边界。面试时能说出这个判断,比背模式名更重要。
常见模式
| 模式 |
做法 |
优点 |
缺点 |
| ReAct(推理 + 行动) |
循环:思考 → 调用工具 → 观察结果 → 再思考,直到给出答案 |
简单通用,现代工具调用 Agent 基本都是这个循环 |
每步都调用大模型,长任务容易跑偏 |
| Plan-and-Execute(先规划后执行) |
先生成完整计划(步骤列表),再逐步执行;失败时把错误反馈给规划器重新规划 |
全局视角,步骤可展示给用户确认,执行步骤可以用便宜模型 |
计划可能不切实际,需要重新规划机制 |
| 反思(Reflection) |
生成后让模型(或另一个模型)按标准检查并修改 |
提升质量 |
成本和延迟翻倍;检查标准要明确 |
| Agentic RAG |
由 Agent 决定是否检索、改写查询、多次检索、选择数据源、检查答案是否有依据 |
能处理多跳、模糊问题 |
延迟高,必须有最大步数 |
规划的工程要点
- 计划用结构化输出(步骤列表:工具、参数、依赖),而不是自由文本。
- 每一步有状态(待执行 / 完成 / 失败),可展示、可恢复(用 LangGraph 检查点)。
- 失败时把具体错误反馈给规划器;设置最大重新规划次数,超过后转人工。
- 有副作用的步骤在执行前让用户确认计划。
案例
运营人员说“生成 9 月各大区销售报表并发给运营组”。Plan-and-Execute:规划出“查询销售数据 → 生成图表 → 发送”三步并展示给用户;第一次查询因为缺少月份参数失败,错误反馈给规划器后修正参数,第二次执行成功。整个过程每一步的状态都在界面上可见。
代码示例
完整可运行版本:examples/agent-patterns/patterns.py。Plan-and-Execute 核心:
输出:
易错点
- 所有需求都做成 Agent:流程固定的用工作流。
- 没有最大步数 / 最大重新规划次数,失败时无限循环、成本失控。
- 计划是自由文本,无法校验和展示。
- 反思步骤没有明确标准(“检查一下有没有问题”),模型只会说“没问题”。
- 只测最终答案,不测中间过程(工具调用序列、步数)。
面试常问
- ReAct 是什么?和 Plan-and-Execute 有什么区别?
- 工作流和 Agent 怎么选?
- Agentic RAG 和普通 RAG 的区别?