AI Agent 设计范式：从 ReAct 到 Agentic Workflow

闵浮龙

182人浏览 · 2026-06-21 15:00:00

闵浮龙 · 2026-06-21 15:00:00 发布

一、为什么要学 Agent 设计范式？

很多人一讲 Agent，就只会说“LLM 自己思考、自己调用工具”。这句话没错，但太粗。真正落到工程里，问题会立刻变成：任务流程要不要固定？下一步由代码决定，还是由模型决定？失败后要不要反思？复杂任务要不要先规划？线上成本和延迟怎么控制？

Agent 设计范式解决的不是“概念好不好听”，而是“一个智能系统应该怎么组织执行过程”。同一个业务需求，用不同范式实现，系统的稳定性、成本、可解释性完全不同。

二、Workflow 和 Agent 的核心区别

先把底层问题说清楚：Workflow 和 Agent 最大的区别，不在于有没有调用大模型，也不在于有没有工具，而在于“下一步由谁决定”。

Workflow 是开发者提前把流程写好。比如：先检索，再重排，再生成，再质检。每一步如何走、失败后去哪条分支，都是代码里定死的。LLM 只是流程中的一个能力节点。

Agent 则把下一步决策权交给 LLM。你给它目标、工具和边界，它自己判断该调哪个工具、传什么参数、是否继续、什么时候给最终答案。

代码结构上也能一眼看出来。Workflow 的控制流写在代码里；Agent 的控制流出现在模型每一轮的决策里。

def answer_by_workflow(query: str) -> str:
"""Workflow 风格：流程固定，LLM 只是其中一个节点。"""
docs = vector_store.search(query, top_k=5)
evidence = reranker.rank(query, docs)
answer = llm.generate(query, context=evidence)
return answer
def answer_by_agent(query: str) -> str:
"""Agent 风格：LLM 在运行时决定下一步。"""
state = {"query": query, "steps": []}
for _ in range(MAX_STEPS):
action = llm.decide_next_action(state)
if action.name == "final_answer":
return action.content
result = run_tool(action.name, action.args)
state["steps"].append({"action": action, "result": result})
return "任务已停止：超过最大步数"

所以工程选型的第一原则是：能固定的流程，就不要让模型自由发挥；只有当某个节点真的需要灵活判断，才把它升级成 Agent。

三、ReAct：最经典的 Agent 小循环

ReAct 是 Reasoning + Acting 的缩写。它的核心不是“让模型想很多”，而是把每一轮执行拆成三个清晰阶段：Thought、Action、Observation。

Thought：模型先分析当前状态，判断下一步该做什么。

Action：模型选择一个工具，并生成结构化参数。

Observation：工具返回结果，模型读取反馈，再进入下一轮。

ReAct 适合工具调用链路不长、每一步相对独立的任务。比如查资料、查订单、调计算器、调用一个业务 API。它的好处是执行轨迹非常清楚：模型为什么调这个工具、调完看到了什么、为什么继续或停止，都能记录下来。

# ReAct 的典型轨迹，不是普通聊天，而是可观察的执行过程。
Thought: 用户想比较两个产品，我需要先查询产品 A 的价格。
Action: web_search({"query": "产品A 最新价格"})
Observation: 搜索结果显示产品 A 当前价格为 299 元。
Thought: 还缺产品 B 的价格，继续查询。
Action: web_search({"query": "产品B 最新价格"})
Observation: 搜索结果显示产品 B 当前价格为 259 元。
Thought: 信息已经足够，可以给出对比结论。
Final Answer: 产品 B 更便宜，但还需要结合功能和售后判断。

ReAct 的短板也很明显：它是“走一步看一步”。如果任务需要全局规划，比如写一份完整行业研究报告、迁移一个大型项目、做多轮数据分析，单纯 ReAct 容易在中途偏离目标，或者反复调用工具。

四、Plan-and-Execute：复杂任务先规划再执行

Plan-and-Execute 解决的是 ReAct 的全局视野问题。它会先让 Planner 生成一个完整计划，再让 Executor 按步骤执行。成熟的实现不是死板照计划跑，而是每一步执行完都把结果反馈给 Planner，必要时动态重规划。

这个范式适合步骤多、依赖强、需要全局目标约束的任务。比如“调研某个行业趋势并输出报告”，一上来就让模型自由搜索，很容易乱；先生成计划，再按计划执行，会稳定很多。

def plan_and_execute(goal: str):
plan = planner.create_plan(goal)
state = {"goal": goal, "plan": plan, "results": []}
while not plan.finished():
step = plan.next_step()
result = executor.run(step, state)
state["results"].append(result)
# 动态重规划：如果结果偏离预期，后续步骤需要调整。
if planner.need_replan(step, result, state):
plan = planner.replan(state)
return reporter.generate(state)

Plan-and-Execute 的代价是多了一层规划器。每次规划、重规划都要调用 LLM，延迟和费用都会上升。所以它不适合特别简单的任务，简单问题用它反而是过度设计。

五、Reflection / Reflexion：让 Agent 自己检查自己

Reflection 是在执行流程中加入“自我评估”环节。模型生成结果后，不是立刻返回给用户，而是再经过一次评估：是否满足要求？有没有事实错误？代码能不能通过测试？格式是否正确？如果不合格，就带着反馈再生成一次。

Reflexion 是 Reflection 的增强版。它不是简单重试，而是把失败原因写成一段“反思总结”，作为下一次尝试的上下文。你可以把它理解为模型给自己写“错题本”。

def generate_with_reflection(task: str):
memory = []
for attempt in range(MAX_RETRY):
output = generator.run(task, reflection_memory=memory)
evaluation = evaluator.check(task, output)
if evaluation.passed:
return output
reflection = reflector.summarize_failure(
task=task,
output=output,
feedback=evaluation.feedback,
)
memory.append(reflection)
return "多次反思后仍未通过，建议转人工复核。"

Reflection 很适合质量要求高、允许多花一点时间的场景，比如代码生成、方案评审、长文生成、SQL 生成。它的代价也很直接：多一次评估、多一次反思、多一次重试，token、延迟和费用都会增加。