AI Agent 核心范式
ReAct、Plan-and-Execute、MRKL、Function Calling — AI Agent 四大核心范式深度解析
AI Agent 概述
AI Agent（智能体）是一种能够自主感知环境、进行推理决策并采取行动的智能系统。与传统 LLM 调用的"一问一答"模式不同，Agent 具备自主性、目标导向性和持续交互能力，能够在复杂环境中逐步推进任务直至完成。
传统 LLM 调用是无状态的单次推理：用户输入 prompt，模型返回回复，一次交互即结束。而 Agent 则运行在持续循环之中，其核心循环可以概括为 感知（Perceive）→ 思考（Think）→ 行动（Act）→ 观察（Observe） 四个阶段：
- 感知：接收用户指令和环境反馈，包括工具返回的结果、外部数据源的状态等。
- 思考：基于当前状态和目标进行推理，决定下一步该做什么。
- 行动：执行具体的操作，可能是调用工具、查询数据库、执行代码或返回信息给用户。
- 观察：获取行动后的反馈结果，更新内部状态，为下一轮循环做准备。
这个循环使得 Agent 能够处理多步推理任务（如复杂问答、自动化工作流、代码生成与调试等），而这些任务超出了单次 LLM 调用的能力范围。围绕这一核心循环，学术界和工业界衍生出了多种范式，以下逐一解析。
ReAct 推理-行动循环
ReAct（Reasoning + Acting）由 Shunyu Yao 等人在 2022 年的论文《ReAct: Synergizing Reasoning and Acting in Language Models》中提出，核心思想是将推理轨迹（reasoning trace）与行动步骤（action steps）交织在一起，让模型在思考的同时采取行动，并通过行动结果修正后续推理。
核心机制
ReAct 的核心运行模式是一个 Thought → Action → Observation 的三步循环：
- Thought（思考）：模型用自然语言进行推理，分析当前状态、拆解子目标、评估下一步方案。
- Action（行动）：基于思考结果，生成具体的动作指令，如调用搜索引擎、执行计算、查询数据库等。
- Observation（观察）：接收行动执行后返回的客观结果，将其纳入推理上下文，进入下一轮思考。
与 CoT 的对比
思维链（Chain-of-Thought, CoT）仅通过"思考"来增强推理，模型在内部推理步骤中逐步推导答案，整个过程不依赖外部信息。ReAct 在此基础上引入了"行动"和"观察"环节，让模型能够获取实时外部信息并据此修正推理，有效缓解了 LLM 的幻觉问题和知识截止问题。简单来说，CoT 是闭卷思考，ReAct 是开卷推理。
伪代码示例
def react_agent(task, max_steps=10):
context = f"任务: {task}\n"
for step in range(max_steps):
# Thought: 模型进行推理
thought = llm.invoke(f"{context}\n请思考下一步应该做什么:")
# Action: 决定并执行动作
action = parse_action(thought)
if action["type"] == "finish":
return action["answer"]
# Observation: 执行工具并获取结果
observation = execute_tool(action["type"], action["args"])
context += f"思考: {thought}\n行动: {action}\n观察: {observation}\n"
return "达到最大步骤限制，任务未完成"Plan-and-Execute 范式
Plan-and-Execute（计划-执行）范式将 Agent 的工作流程拆分为两个独立的阶段：先制定完整计划，再逐步执行。这与 ReAct 的"边想边做"形成鲜明对比。
两阶段架构
阶段一：计划生成与拆解
Agent 在接收到任务后，首先对任务进行整体分析，将其拆解为一系列有序的子步骤。这一过程类似于编程中的"自顶向下设计"：从顶层目标出发，逐层分解为可执行的原子任务。计划通常以列表或图结构的形式呈现，每个步骤包含明确的输入、输出和前置依赖。
阶段二：执行与进度追踪
执行阶段按照计划逐步推进。与 ReAct 不同，执行器通常不进行额外推理，而是忠实地执行既定计划。遇到失败时，可以选择重试、回滚或请求重新规划。进度追踪器维护当前步骤的状态，并在全部步骤完成后汇总最终结果。
与 ReAct 的对比
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 推理时机 | 边行动边推理，实时调整 | 先规划再执行，分阶段推进 |
| 灵活性 | 高，能动态应对环境变化 | 中，计划制定后不易大幅调整 |
| 可控性 | 低，推理路径可能发散 | 高，计划可审查和修改 |
| 适合场景 | 开放域探索、信息搜集 | 确定性任务、工作流自动化 |
| 失败处理 | 通过观察自动纠偏 | 需要显式重规划机制 |
MRKL 架构
MRKL（Modular Reasoning, Knowledge and Language，模块化推理、知识与语言系统）由 Karpas 等人在论文《MRKL Systems: A modular, neuro-symbolic architecture that combines large language models, external knowledge sources and discrete reasoning》中提出。其核心理念是将大语言模型作为"中央调度器"，将不同能力封装为独立模块，由调度器根据任务需求动态路由到最合适的模块。
架构组成
MRKL 系统由三个核心组件构成：
中央语言模型（中央调度器）：负责理解用户输入、分析任务类型，并将请求路由到对应的专家模块。中央模型不需要具备所有专业知识，只需要具备"路由判断"能力。
专家模块：每个模块封装特定领域的能力，如数学计算器、知识图谱查询器、代码解释器、数据库接口等。模块可以是神经网络、符号系统或传统程序。
路由机制：中央模型根据输入判断应该调用哪个（或哪些）专家模块，并将模块的输出整合为最终回复。
专家模块路由示例
def mrkl_router(query):
# 中央语言模型判断任务类型
task_type = llm.classify(
query,
categories=["math", "knowledge", "code", "general"]
)
# 路由到对应专家模块
if task_type == "math":
return calculator.execute(extract_expression(query))
elif task_type == "knowledge":
return knowledge_base.query(extract_entities(query))
elif task_type == "code":
return code_interpreter.run(extract_code(query))
else:
return llm.generate(query)MRKL 的优势在于模块的可插拔性和可扩展性：新增能力只需添加新的专家模块，无需重新训练中央模型。这种"神经-符号"混合架构兼顾了神经网络的灵活性和符号系统的精确性。
OpenAI Function Calling / Tool Use
OpenAI 在 2023 年 6 月发布的 GPT-4 和 GPT-3.5 Turbo 更新中引入了 Function Calling 功能，后在后续版本中演进为更通用的 Tools API。这标志着 AI Agent 范式从学术研究走向了工业级应用。
原理与机制
Function Calling 的核心是让模型能够理解并使用开发者定义的函数/工具。开发者通过 API 向模型注册一系列函数（包括函数名、参数描述和类型信息），模型在推理过程中判断是否需要调用某个函数，并以结构化 JSON 格式返回函数名和参数，由开发者负责实际执行。
Tools API 参数格式
import openai
tools = [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的当前天气",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称，如北京、上海"
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "温度单位"
}
},
"required": ["city"]
}
}
},
{
"type": "function",
"function": {
"name": "search_news",
"description": "搜索最新新闻文章",
"parameters": {
"type": "object",
"properties": {
"keyword": {
"type": "string",
"description": "搜索关键词"
},
"limit": {
"type": "integer",
"description": "返回结果数量上限"
}
},
"required": ["keyword"]
}
}
}
]并行函数调用
OpenAI 支持在一次请求中同时调用多个函数（Parallel Function Calling）。当多个操作彼此独立时（如同时查询多个城市的天气），模型可以在单次响应中返回多个函数调用，大幅减少交互轮次。
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "北京和上海今天天气怎么样？"}],
tools=tools,
tool_choice="auto"
)
# 模型可能同时返回 get_weather("北京") 和 get_weather("上海") 两个调用
for tool_call in response.choices[0].message.tool_calls:
function_name = tool_call.function.name
arguments = json.loads(tool_call.function.arguments)
print(f"调用函数: {function_name}, 参数: {arguments}")
# 执行函数并返回结果...Function Calling 的核心贡献在于定义了一套标准化的"模型-工具交互协议"，使得开发者可以用极少的代码将外部工具接入 LLM 工作流，极大地降低了 Agent 系统的构建门槛。
范式对比表
| 维度 | ReAct | Plan-and-Execute | MRKL | Function Calling |
|---|---|---|---|---|
| 核心思想 | 推理与行动交织 | 先规划后执行 | 模块化专家路由 | 标准化工具调用 |
| 推理方式 | 在线推理，边想边做 | 离线规划 + 在线执行 | 中央模型判断路由 | 模型自主选择工具 |
| 灵活性 | 高 | 中 | 高 | 中高 |
| 复杂度 | 中 | 高 | 高 | 低 |
| 可控性 | 低 | 高 | 中 | 高 |
| 可扩展性 | 中（需修改 prompt） | 高（可插件化） | 高（模块即插即用） | 高（API 级扩展） |
| 失败恢复 | 自动纠偏 | 需重规划机制 | 模块级容错 | 依赖开发者处理 |
| 适用场景 | 开放域问答、信息搜集、探索性任务 | 多步工作流、数据分析流水线、自动化流程 | 混合推理、多领域知识问答 | 工具增强型应用、ChatGPT Plugins、API 编排 |
| 代表系统 | ReAct Agent、LangChain Agent | BabyAGI、AutoGPT（部分实现） | 早期 MRKL 系统 | OpenAI GPTs、LangChain Tool Agent |
| 工业成熟度 | 高 | 中 | 低 | 高 |
总结
四种范式并非互斥，而是从不同角度回答了"Agent 如何做决策和行动"这一核心问题。ReAct 适合需要实时交互和动态调整的场景；Plan-and-Execute 适用于确定性强的多步工作流；MRKL 提供了模块化扩展的架构蓝图；Function Calling 则是最接近工业化标准的工具交互协议。
在实际工程中，成熟的 Agent 系统往往融合多种范式：以 Function Calling 作为工具交互层，以 ReAct 作为推理循环，同时在复杂任务中引入 Plan-and-Execute 的分层规划机制。理解这些范式的设计哲学和适用边界，是构建高效、可靠的 AI Agent 系统的前提。