Appearance
60. AI Agent 的主流设计模式有哪些？
难度 P1 高频 · 岗位 应用 · 频率 ★★★★☆ · 预计阅读 8 min 公司 OpenAI · Anthropic 相关题 Q61 反射模式 · Q65 多智能体
本题阅读地图
面试场景还原
👔面试官：你在做一个 AI 客服系统，有的问题很简单（查天气），有的很复杂（需要分析订单、联系物流、给用户发补偿券）。如果只用一个 ReAct 循环处理所有请求，有什么问题？
🙋♂️我：简单任务用大模型太慢了，而且复杂任务可能需要分步骤规划，ReAct 循环可能搞不定。
👔面试官：对。实际产品中，不同场景需要不同的设计模式。你能说说 AI Agent 有哪些主流的设计模式吗？比如 Manus 和 Deep Research 的架构差异在哪里？
🙋♂️我：呃……有 ReAct 模式，还有多 Agent 协作？
👔面试官：可以这么说，但更系统一点。按吴恩达的框架，有五种递进的设计模式：反射、工具使用、ReAct、规划、多智能体。你能具体讲讲它们的区别和适用场景吗？
TL;DR 速记
- 五种递进模式：反射 → 工具使用 → ReAct → 规划 → 多智能体，复杂度递增
- 反射模式：自我检查、纠错迭代，适合高精度输出（代码生成）
- 工具使用模式：调用外部 API/工具扩展能力，适合需要实时数据场景
- ReAct 模式：思考-行动循环，适合单任务闭环处理（分析、查询）
- 规划模式：任务拆解 + 多步 ReAct，适合战略级长任务（研究报告）
- 多智能体模式：多 Agent 协作分工，适合跨领域超复杂任务（Manus）
- 实际产品：通常是多种模式组合（如 Manus = 规划 + 多智能体）
图解
图 1：五种设计模式演进图
图 2：模式复杂度与适用场景对比
详细解析
为什么需要设计模式？
Agent 复杂度谱系：
| 复杂度 | 场景 | 需要的模式 |
|---|---|---|
| 低 | 简单问答、翻译 | 单次 LLM 调用 |
| 中低 | 代码生成、写作 | 反射模式（自检） |
| 中 | 天气查询、计算 | 工具使用模式 |
| 中高 | 数据分析、单任务处理 | ReAct 模式 |
| 高 | 研究报告、复杂分析 | 规划模式 |
| 超高 | 跨领域任务、长期项目 | 多智能体模式 |
设计模式的核心价值：
- 结构化问题解决：将复杂任务分解为可管理的步骤
- 能力扩展：通过工具和协作突破单模型局限
- 可靠性提升：通过反思和循环提高输出质量
- 工程化落地：提供可复用的架构模板
反射模式（Reflection）
核心思想： 让 LLM 对自己的输出进行自我检查和优化，类似于人类写完后回头检查。
工作流程：
1. 生成初稿（Generation）
2. 自我检查（Reflection）
- 检查逻辑错误
- 检查格式问题
- 检查完整性
3. 优化改进（Refinement）
4. （可选）重复 2-3 直到满意适用场景：
| 场景 | 为什么适合 |
|---|---|
| 代码生成 | 检查语法、逻辑、边界条件 |
| 文案写作 | 检查流畅度、错别字 |
| 数学推理 | 验证计算步骤 |
| 翻译 | 检查准确性和自然度 |
代码示例：
python
class ReflectionAgent:
"""反射模式 Agent"""
async def generate_with_reflection(self, prompt: str, max_iterations: int = 2) -> str:
# 第一步：生成初稿
draft = await self.llm.generate(prompt)
for i in range(max_iterations):
# 第二步：自我检查
reflection_prompt = f"""
请检查以下输出，找出问题并给出改进建议：
输出内容：{draft}
检查维度：
1. 逻辑是否正确？
2. 格式是否规范？
3. 是否完整回答了问题？
4. 是否有遗漏或错误？
如果没问题，回复"PASS"。
如果有问题，请指出具体问题并给出改进建议。
"""
reflection = await self.llm.generate(reflection_prompt)
if "PASS" in reflection:
break
# 第三步：优化改进
refinement_prompt = f"""
基于以下检查反馈，优化之前的输出：
原输出：{draft}
反馈：{reflection}
请给出优化后的版本。
"""
draft = await self.llm.generate(refinement_prompt)
return draft典型产品：GitHub Copilot 的代码建议（生成后检查）、Claude Artifact（自检查输出）
工具使用模式（Tool Use）
核心思想： LLM 本身能力有限，通过调用外部工具（API、数据库、搜索引擎）扩展能力边界。
工作流程：
1. 识别需要工具（Tool Selection）
2. 准备调用参数（Parameter Preparation）
3. 执行工具调用（Tool Execution）
4. 整合工具结果（Result Integration）
5. 生成最终回答（Response Generation）常见工具类型：
| 工具类型 | 示例 | 用途 |
|---|---|---|
| 搜索工具 | Google Search、Bing API | 获取实时信息 |
| 计算工具 | Python 解释器、计算器 | 精确计算 |
| 数据库 | SQL 查询、向量检索 | 结构化数据访问 |
| API 工具 | 天气 API、股票 API | 外部服务调用 |
| 文件工具 | 文件读写、代码执行 | 本地操作 |
适用场景：
| 场景 | 工具组合 |
|---|---|
| 智能客服 | 知识库检索 + 订单查询 API |
| 数据分析 | Python 解释器 + 数据文件 |
| 旅行助手 | 航班 API + 酒店 API + 地图 API |
| 编程助手 | 代码执行 + 文档检索 + 调试器 |
代码示例：
python
class ToolUseAgent:
"""工具使用模式 Agent"""
def __init__(self):
self.tools = {
"search": SearchTool(),
"calculator": CalculatorTool(),
"weather": WeatherAPI(),
}
async def execute(self, query: str) -> str:
# 1. 分析需要哪些工具
tool_selection = await self.llm.select_tools(query, available_tools=list(self.tools.keys()))
# 2. 并行调用工具
results = {}
for tool_name in tool_selection.selected:
tool = self.tools[tool_name]
params = await self.llm.prepare_params(tool, query)
results[tool_name] = await tool.execute(params)
# 3. 整合结果生成回答
final_prompt = f"""
用户问题：{query}
工具调用结果：{results}
请基于工具返回的结果，生成最终回答。
"""
return await self.llm.generate(final_prompt)典型产品：ChatGPT 插件、MCP 工具调用、Function Calling
ReAct 模式（Reasoning + Acting）
核心思想： 将「思考（Reasoning）」和「行动（Acting）」结合，形成思考-行动-观察的循环，直到任务完成。
工作流程：
Thought（思考）→ Action（行动）→ Observation（观察）→ Thought → ...经典 ReAct Prompt 模板：
请通过思考和行动来解决以下问题。
可用工具：
- search(query): 搜索信息
- calculator(expression): 计算
格式要求：
Thought: [你的思考过程]
Action: [工具名称]([参数])
Observation: [工具返回结果]
开始：
Question: 北京今天的天气如何？
Thought: 需要查询北京的实时天气。
Action: search("北京今天天气")
Observation: 北京今天晴，25°C，微风。
Thought: 已获得天气信息，可以回答用户。
Action: finish("北京今天天气晴朗，气温25°C，微风。")适用场景：
| 场景 | 为什么适合 |
|---|---|
| 多步推理任务 | 每步都需要思考和行动 |
| 工具链组合 | 需要按顺序调用多个工具 |
| 交互式任务 | 需要基于中间结果调整策略 |
| 问题诊断 | 逐步排查，根据反馈调整 |
代码示例：
python
class ReActAgent:
"""ReAct 模式 Agent"""
async def execute(self, task: str, max_steps: int = 10) -> str:
context = []
for step in range(max_steps):
# 1. 思考下一步
thought_prompt = f"""
任务：{task}
已执行步骤：{context}
请思考：接下来应该做什么？
- 如果需要工具，返回 Action: tool_name(params)
- 如果任务完成，返回 Action: finish(answer)
Thought:
"""
thought = await self.llm.generate(thought_prompt)
# 2. 解析思考和行动
action = self.parse_action(thought)
if action.type == "finish":
return action.result
# 3. 执行行动
observation = await self.execute_action(action)
# 4. 记录上下文
context.append({
"step": step,
"thought": thought,
"action": action,
"observation": observation
})
raise RuntimeError("Max steps exceeded")典型产品：LangChain ReAct Agent、AutoGPT 早期版本
规划模式（Planning）
核心思想： 先制定高层计划，再逐个执行计划中的子任务。类似于项目管理中的 WBS（工作分解结构）。
工作流程：
1. 任务理解（Task Understanding）
2. 计划制定（Plan Creation）
- 拆解为子任务
- 确定依赖关系
- 排序执行顺序
3. 计划执行（Plan Execution）
- 每个子任务可用 ReAct 处理
- 跟踪进度
4. 结果整合（Result Synthesis）适用场景：
| 场景 | 计划示例 |
|---|---|
| 研究报告 | 1. 搜索背景 → 2. 收集数据 → 3. 分析 → 4. 撰写 → 5. 校对 |
| 代码重构 | 1. 分析代码 → 2. 制定方案 → 3. 修改文件 → 4. 测试 → 5. 部署 |
| 旅行规划 | 1. 查航班 → 2. 查酒店 → 3. 规划路线 → 4. 预订 |
| 复杂问答 | 1. 拆解问题 → 2. 逐个搜索 → 3. 综合分析 → 4. 给出结论 |
代码示例：
python
class PlanningAgent:
"""规划模式 Agent"""
async def execute(self, task: str) -> str:
# 1. 制定计划
plan_prompt = f"""
请将以下任务拆解为可执行的子任务列表：
任务：{task}
要求：
1. 每个子任务要具体、可执行
2. 明确子任务之间的依赖关系
3. 给出执行顺序
输出格式：
1. [子任务描述] - 依赖: [前置任务]
2. [子任务描述] - 依赖: [前置任务]
...
"""
plan_text = await self.llm.generate(plan_prompt)
plan = self.parse_plan(plan_text)
# 2. 执行计划
results = {}
for step in self.topological_sort(plan):
# 获取依赖结果
dependencies = {dep: results[dep] for dep in step.dependencies}
# 执行子任务（可用 ReAct）
result = await self.execute_subtask(step, dependencies)
results[step.id] = result
# 3. 整合结果
synthesis_prompt = f"""
基于以下子任务执行结果，生成最终答案：
原任务：{task}
子任务结果：{results}
请整合并给出完整回答。
"""
return await self.llm.generate(synthesis_prompt)典型产品：Deep Research、OpenAI Deep Research、Perplexity 深度搜索
多智能体模式（Multi-Agent）
核心思想： 多个专业化的 Agent 协作完成复杂任务，每个 Agent 负责特定领域，通过协作解决单 Agent 无法处理的超复杂问题。
协作架构：
┌─────────────────────────────────────────────────────────┐
│ 用户请求 │
└──────────────────────┬──────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 规划 Agent（Orchestrator） │
│ ├── 理解任务、拆解子任务 │
│ ├── 分配子任务给专业 Agent │
│ └── 协调执行顺序和依赖 │
└──────────────────────┬──────────────────────────────────┘
↓
┌──────────────┼──────────────┐
↓ ↓ ↓
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 搜索 Agent │ │ 分析 Agent │ │ 写作 Agent │
│ (ReAct 模式) │ │ (ReAct 模式) │ │ (反射模式) │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
└────────────────┼────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 整合 Agent（Synthesizer） │
│ └── 汇总各 Agent 结果，生成最终输出 │
└─────────────────────────────────────────────────────────┘角色分工示例：
| 角色 | 职责 | 模式 |
|---|---|---|
| 规划 Agent | 任务拆解、资源分配 | 规划模式 |
| 搜索 Agent | 信息检索、数据收集 | ReAct + 工具使用 |
| 分析 Agent | 数据分析、模式识别 | ReAct |
| 写作 Agent | 内容生成、文案撰写 | 反射模式 |
| 审核 Agent | 质量检查、合规审查 | 反射模式 |
| 整合 Agent | 结果汇总、最终输出 | 规划模式 |
通信机制：
python
class MultiAgentSystem:
"""多智能体系统"""
def __init__(self):
self.agents = {
"planner": PlanningAgent(),
"researcher": ReActAgent(tools=["search", "browse"]),
"analyst": ReActAgent(tools=["calculator", "code_interpreter"]),
"writer": ReflectionAgent(),
"synthesizer": SynthesisAgent()
}
async def execute(self, task: str) -> str:
# 1. 规划 Agent 拆解任务
plan = await self.agents["planner"].create_plan(task)
# 2. 并行/串行执行子任务
context = {}
for subtask in plan.subtasks:
agent = self.agents[subtask.assigned_agent]
result = await agent.execute(subtask, context)
context[subtask.id] = result
# 3. 整合 Agent 汇总
final_result = await self.agents["synthesizer"].synthesize(task, context)
return final_result典型产品：Manus、MetaGPT、AutoGen
五种模式对比：
| 模式 | 核心机制 | 复杂度 | 适用场景 | 典型产品 |
|---|---|---|---|---|
| 反射 | 生成→检查→优化 | ⭐⭐ | 代码生成、写作 | Claude Artifact |
| 工具使用 | LLM + API 调用 | ⭐⭐⭐ | 实时数据查询 | ChatGPT 插件 |
| ReAct | 思考-行动循环 | ⭐⭐⭐⭐ | 单任务闭环 | LangChain Agent |
| 规划 | 任务拆解+执行 | ⭐⭐⭐⭐⭐ | 研究报告 | Deep Research |
| 多智能体 | 多 Agent 协作 | ⭐⭐⭐⭐⭐ | 跨领域复杂任务 | Manus |
常见踩坑与反例
踩坑 1：模式选择不当
错误做法： 用 ReAct 模式处理简单查询（如查天气），增加不必要的延迟。
正确做法： 简单工具调用即可，无需完整的 ReAct 循环。
踩坑 2：过度设计
错误做法： 单 Agent 能搞定的任务，硬上多智能体，增加复杂度。
正确做法： 从简单模式开始，只有当单 Agent 无法满足需求时才升级。
踩坑 3：忽视模式组合
错误做法： 认为只能选一种模式，实际产品需要组合。
正确做法： 复杂系统通常是多种模式组合，如 Manus = 规划 + 多智能体。
踩坑 4：递归过深
错误做法： ReAct 循环不设上限，导致无限循环或 token 耗尽。
正确做法： 设置最大迭代次数，添加退出条件。
踩坑 5：忽视错误处理
错误做法： 假设工具调用一定成功，没有失败处理机制。
正确做法： 工具调用失败应有降级策略（重试、换工具、人工介入）。
面试官可能继续追问
追问 1：Manus 和 Deep Research 分别用了哪些设计模式？ 答题要点：Deep Research 主要是规划模式（任务拆解 + 多步 ReAct）；Manus 是多智能体模式（规划 Agent + 多个专业 Agent 协作），内部每个子 Agent 可能用 ReAct。
追问 2：ReAct 和 Chain-of-Thought（CoT）有什么区别？ 答题要点：CoT 是单纯推理，没有行动；ReAct 是推理+行动闭环，可以与外部工具交互。
追问 3：多智能体系统的通信机制怎么设计？ 答题要点：直接调用（函数调用）、消息队列（异步通信）、共享状态（黑板模式）、分层架构（规划层-执行层）。
追问 4：如何评估应该用哪种设计模式？ 答题要点：任务复杂度（步骤数量）、是否需要实时数据、是否需要多领域协作、延迟要求、成本预算。
面试总结
回答 AI Agent 设计模式题，关键是展示复杂度递进的理解：
- 五种递进模式：反射（自检）→ 工具使用（扩展）→ ReAct（循环）→ 规划（拆解）→ 多智能体（协作），从简单到复杂
- 实际产品通常是组合：如 Manus = 规划 + 多智能体，Deep Research = 规划 + ReAct
- 选型原则：基于任务复杂度选择，从简单开始，必要时再升级
记住：设计模式不是互斥选项，而是工具箱里的工具。面试时展示你能根据场景灵活选择和组合模式的能力，比死记硬背定义更有价值。