扫码
40.67M · 2026-04-17
很多人第一次做 AI 应用，通常会从下面这个模式开始：
用户提问 -> LLM 生成答案 -> 返回结果
这类应用当然有价值，但它还不算真正意义上的 Agent。
因为一个真正的 Agent，通常不只是“回答问题”，而是要完成任务。比如：
这时候，问题就不再是“提示词怎么写”，而变成：
这就是 Agent 架构模式存在的意义。
一个非常实用的理解方式是：
核心能力是：
核心能力是：
也就是说，Agent 本质上是一个带闭环的决策系统。
可以把它抽象成下面这张图：
flowchart LR
U[用户目标] --> A[Agent]
A --> T[工具 / API / 数据库 / 文件系统]
T --> O[观察结果 Observation]
O --> A
A --> R[最终结果]
在这个闭环里，LLM 不再只是“回答器”，而是扮演：
无论你选择 React、Plan-Exec、Reflect 还是混合模式，底层几乎都绕不开这几个步骤：
常见闭环如下：
flowchart TD
A[接收用户请求] --> B[分析任务复杂度]
B --> C{是否需要多步执行?}
C -- 否 --> D[直接推理 / 单轮工具调用]
C -- 是 --> E[规划或迭代执行]
D --> F[输出结果]
E --> G[获取反馈]
G --> H{是否达成目标?}
H -- 否 --> E
H -- 是 --> F
理解了这个闭环，再去看不同架构模式，就不会只停留在“名词记忆”层面。
React 模式的核心思想是：
flowchart TD
Q[用户问题] --> T1[Thought 思考]
T1 --> A1[Action 执行动作]
A1 --> O1[Observation 观察结果]
O1 --> T2[Thought 再次思考]
T2 --> A2[Action 再执行]
A2 --> O2[Observation 新结果]
O2 --> F[Final Answer 最终答案]
因为它足够自然，几乎符合人类做事的直觉：
例如：
async function reactAgent(userInput, tools, llm) {
const messages = [{ role: 'user', content: userInput }];
for (let i = 0; i < 8; i++) {
const response = await llm.invoke(messages);
if (response.type === 'final') {
return response.content;
}
if (response.type === 'tool_call') {
const toolResult = await tools[response.toolName](response.args);
messages.push({
role: 'assistant',
content: `调用工具: ${response.toolName}`,
});
messages.push({
role: 'tool',
content: JSON.stringify(toolResult),
});
}
}
throw new Error('超过最大迭代次数，任务未完成');
}
非常适合：
如果你的 Agent 目标是：先做一个能跑起来的多工具智能体，React 往往是第一选择。
Plan-Exec 模式的核心思想是：
它很像一个项目经理先列 todo，再安排执行。
flowchart TD
U[用户任务] --> P[Plan 生成执行计划]
P --> S1[Step 1 执行]
S1 --> S2[Step 2 执行]
S2 --> S3[Step 3 执行]
S3 --> C[汇总结果]
C --> R[最终输出]
当任务具有明显的多阶段结构时，React 容易显得“短视”。
例如：
这类任务如果不提前规划，Agent 很容易：
async function planExecAgent(userInput, planner, executor) {
const plan = await planner(userInput);
const results = [];
for (const step of plan.steps) {
const stepResult = await executor(step, results);
results.push({ step: step.title, result: stepResult });
}
return {
plan,
results,
summary: await summarizeResults(plan, results),
};
}
{
"task_summary": "完成一篇关于 AI Agent 架构模式的技术博客",
"steps": [
{
"step_id": 1,
"description": "梳理 React、Plan-Exec、Reflect 的定义与应用场景",
"depends_on": []
},
{
"step_id": 2,
"description": "设计对比表和架构图",
"depends_on": [1]
},
{
"step_id": 3,
"description": "撰写面向新手的代码示例与实战建议",
"depends_on": [1, 2]
}
]
}
Reflect 模式可以理解为：
它通常会在一个阶段完成后，增加一个“反思 / 评估 / 自检”步骤。
flowchart TD
U[用户任务] --> G[生成初稿 / 执行结果]
G --> E[Reflect 评估与反思]
E --> J{结果是否达标?}
J -- 否 --> R[修正策略并重试]
R --> G
J -- 是 --> F[输出最终结果]
因为 LLM 有一个天然问题：
如果没有反思环节，Agent 很可能：
Reflect 的价值在于引入第二视角：
async function reflectAgent(task, worker, reviewer, maxRounds = 3) {
let draft = await worker(task);
for (let i = 0; i < maxRounds; i++) {
const review = await reviewer(task, draft);
if (review.pass) {
return draft;
}
draft = await worker(task, {
previousDraft: draft,
feedback: review.feedback,
});
}
return draft;
}
如果你在真正的项目里做 Agent，最后往往会发现：
于是，混合模式就出现了。
混合模式不是一种固定套路，而是组合策略。例如：
flowchart TD
U[用户请求] --> C[复杂度判断]
C -->|简单| R1[React 模式]
C -->|复杂| P1[Plan-Exec 模式]
R1 --> RV[Reflect 校验]
P1 --> RV
RV --> D{是否达标?}
D -- 是 --> O[输出结果]
D -- 否 --> RP[重试或重规划]
RP --> O
因为生产环境下你要同时考虑：
一个简单问答没必要先生成 8 步计划； 一个复杂分析任务也不能只靠走一步看一步。
所以最合理的方式往往是：
| 模式 | 核心思想 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|---|
| React | 边思考边行动 | 实现简单、灵活、适合动态任务 | 全局规划弱、可能循环试探 | 工具型助手、查询、调试 |
| Plan-Exec | 先规划再执行 | 全局结构清晰、适合复杂任务 | 计划可能失真、实现更复杂 | 长流程、多阶段任务 |
| Reflect | 执行后自我复盘 | 质量稳定、能纠错 | 成本更高、速度更慢 | 高质量内容、代码审查 |
| 混合模式 | 多模式组合 | 更贴近真实生产需求 | 设计复杂、调优成本高 | 通用型生产 Agent |
如果只给新手一句建议：
下面我们用一个非常简化的 JavaScript 示例，把四种思想串起来。
const tools = {
async searchWeb(query) {
return `搜索结果：找到与“${query}”相关的 3 条资料`;
},
async readDoc(topic) {
return `文档内容：${topic} 的核心概念包括 ...`;
},
async saveMarkdown(content) {
return `已保存 markdown，长度 ${content.length} 字符`;
},
};
async function runReactLoop(task, llm) {
const history = [`用户任务：${task}`];
for (let i = 0; i < 6; i++) {
const decision = await llm(history.join('n'));
if (decision.type === 'final') {
return decision.answer;
}
const result = await tools[decision.action](...(decision.args || []));
history.push(`动作: ${decision.action}`);
history.push(`观察: ${result}`);
}
throw new Error('React loop exceeded max iterations');
}
async function createPlan(task, llm) {
return await llm(`请将任务拆解为步骤：${task}`);
}
async function executePlan(plan, llm) {
const outputs = [];
for (const step of plan.steps) {
const stepOutput = await runReactLoop(step.description, llm);
outputs.push({ step: step.description, output: stepOutput });
}
return outputs;
}
async function reflect(task, outputs, llm) {
return await llm(`请检查以下结果是否满足任务目标。任务：${task}n结果：${JSON.stringify(outputs)}`);
}
async function runHybridAgent(task, llm) {
const plan = await createPlan(task, llm);
const outputs = await executePlan(plan, llm);
const review = await reflect(task, outputs, llm);
if (review.pass) {
return review.finalAnswer;
}
// 不通过时，可以触发补充执行或重规划
const revisedPlan = await createPlan(`基于以下问题重新规划：${review.feedback}n原任务：${task}`, llm);
const revisedOutputs = await executePlan(revisedPlan, llm);
return revisedOutputs;
}
它其实已经包含了生产 Agent 的雏形：
这也是为什么很多团队一开始做 Agent 是一个循环，最后逐渐演化成分层架构。
这一部分很重要，甚至比模式本身更重要。
很多新手会觉得，Agent 不就是把提示词写复杂一点吗？
不是。
Agent 的关键不在“提示词长不长”，而在于：
不是工具越多越强。
如果没有：
你的 Agent 很快就会变成“随机调用器”。
React 和 Reflect 都可能死循环。
一定要有：
不是所有任务都值得规划。
如果用户只是问：
你还先规划 6 步，体验会非常差。
真正能把 Agent 做稳的人，都会重视日志和中间状态。
你至少应该能看到：
否则出了问题只能靠猜。
可以用下面这个决策思路。
建议顺序：
优先考虑：
因为这两种模式最容易展示结构，也最容易说明设计思路。
优先考虑：
一个实用的判断表：
| 任务特征 | 推荐模式 |
|---|---|
| 简单问答、单步工具调用 | React |
| 明显多阶段任务 | Plan-Exec |
| 对质量要求高 | Reflect |
| 任务复杂度差异大 | 混合模式 |
| 工具不稳定、需要兜底 | 混合模式 + Reflect |
如果你想真正学会 AI Agent，不建议一上来就堆框架名词。
更推荐下面这条路线：
目标：理解 Agent 不是一次性回答，而是“决策 + 行动 + 反馈”。
你应该能自己实现：
目标：理解为什么复杂任务需要“任务拆解”。
你应该尝试：
目标：让 Agent 不只是能做，还能检查自己。
你应该加入：
目标：把 Demo 变成可用系统。
你需要逐步加入：
最后，用一句话总结四种模式：
如果你现在正处在 AI Agent 学习初期，我建议你把重点放在这三件事上：
真正的 Agent 开发，本质上不是“让模型更聪明”，而是：
这也是 AI Agent 最迷人的地方。
开源AI Agent Node脚手架
