从 ReAct 到 Multi-Agent：AI Agent 架构设计的演进与实践

引言

2024 年到 2025 年，AI Agent 从一个概念逐渐走向工程实践。从最早的单轮对话模型，到支持工具调用的 ReAct 框架，再到如今的多 Agent 协作系统，Agent 的架构设计正在经历快速演进。

本文将系统梳理 AI Agent 架构的发展脉络，深入剖析 ReAct、Plan-and-Solve、Multi-Agent 等核心架构模式，并结合实际工程经验，分享在构建生产级 Agent 系统时的设计思考与最佳实践。

---

一、AI Agent 的核心能力模型

在讨论架构之前，我们需要明确 AI Agent 区别于传统 LLM 应用的核心特征：

1.1 Agent 的三要素

一个完整的 AI Agent 系统通常包含三个核心要素：

• 感知（Perception）：接收环境输入，包括用户指令、系统状态、外部事件等
• 推理（Reasoning）：基于大模型进行思考、规划、决策
• 行动（Action）：通过工具调用与外部环境交互，产生实际影响

[用户输入] → [感知层] → [推理引擎] → [行动执行] → [环境反馈]
                              ↑___________________________|

1.2 从 Prompt Engineering 到 Agent Engineering

传统的 LLM 应用主要依赖 Prompt Engineering，通过精心设计的提示词引导模型输出。而 Agent Engineering 则更进一步：

维度	Prompt Engineering	Agent Engineering
交互模式	单轮/多轮对话	自主循环执行
上下文管理	手动维护	自动状态机
工具使用	一次性调用	链式/并行调用
错误处理	人工介入	自动重试/降级

---

二、ReAct：Agent 架构的奠基范式

2.1 ReAct 的核心思想

ReAct（Reasoning + Acting）由 Google Research 在 2022 年提出，是首个将推理与行动显式结合的 Agent 框架。

其核心循环为：Thought → Action → Observation → ...

# ReAct 伪代码示意
def react_loop(query, max_steps=10):
    context = f"Question: {query}\n"
    
    for step in range(max_steps):
        # 1. 生成思考
        thought = llm.generate(f"{context}\nThought:")
        context += f"Thought: {thought}\n"
        
        # 2. 决定行动
        action = llm.generate(f"{context}\nAction:")
        if "Finish" in action:
            return extract_answer(action)
        
        # 3. 执行工具
        tool_name, tool_input = parse_action(action)
        observation = execute_tool(tool_name, tool_input)
        context += f"Action: {action}\nObservation: {observation}\n"
    
    return "Max steps exceeded"

2.2 ReAct 的局限与改进

ReAct 虽然简洁，但在复杂任务中存在明显局限：

局限 1：短视决策

• 问题：每步仅基于当前观察做局部最优决策
• 改进：引入 Plan-and-Solve 模式，先规划后执行

局限 2：单线程执行

• 问题：工具调用串行，效率低下
• 改进：支持并行工具调用（OpenAI Function Calling）

局限 3：无记忆机制

• 问题：跨会话无法保持上下文
• 改进：引入向量数据库作为长期记忆

---

三、Plan-and-Solve：复杂任务的规划范式

3.1 分层规划架构

对于复杂任务，"先规划、后执行"的模式更为高效：

用户请求
    ↓
[任务分解器] → 子任务列表 [T1, T2, T3, ...]
    ↓
[依赖分析器] → 执行图（DAG）
    ↓
[调度执行器] → 并行/串行执行
    ↓
[结果整合器] → 最终输出

3.2 实际案例：代码审查 Agent

以一个代码审查 Agent 为例，展示分层规划的实现：

class CodeReviewAgent:
    def plan(self, pr_description: str, files: List[File]) -> Plan:
        """生成审查计划"""
        plan_prompt = f"""
        作为资深代码审查员，请为以下 PR 制定审查计划：
        
        PR 描述：{pr_description}
        变更文件：{[f.path for f in files]}
        
        请输出审查步骤（JSON 格式）：
        {{
            "steps": [
                {{"id": "1", "task": "检查代码规范", "depends_on": []}},
                {{"id": "2", "task": "分析架构设计", "depends_on": []}},
                {{"id": "3", "task": "识别潜在 Bug", "depends_on": ["1"]}},
                {{"id": "4", "task": "生成审查报告", "depends_on": ["2", "3"]}}
            ]
        }}
        """
        return self.llm.generate_json(plan_prompt)
    
    def execute(self, plan: Plan, context: Context) -> ReviewReport:
        """按 DAG 执行审查步骤"""
        results = {}
        for step in topological_sort(plan.steps):
            # 收集依赖结果
            deps = {dep: results[dep] for dep in step.depends_on}
            # 执行当前步骤
            results[step.id] = self.execute_step(step, deps, context)
        return self.synthesize_report(results)

---

四、Multi-Agent：协作智能的新范式

4.1 为什么需要 Multi-Agent？

单一 Agent 面临以下瓶颈：

1. 能力边界：一个 LLM 难以同时精通多个领域
2. 上下文限制：长任务导致上下文窗口溢出
3. 单点故障：无容错和负载均衡机制
4. 扩展性：难以适应复杂业务场景

Multi-Agent 架构通过角色分工和协作机制解决这些问题。

4.2 Multi-Agent 的三种协作模式

模式一：层级协作（Hierarchical）

        [Orchestrator Agent]
       /        |         \
      ↓         ↓          ↓
[Agent A]  [Agent B]  [Agent C]
   ↓           ↓          ↓
[Tool 1]   [Tool 2]   [Tool 3]

适用场景：任务可清晰分解为独立子任务

模式二：对等协作（Peer-to-Peer）

[Agent A] ←→ [Agent B] ←→ [Agent C]
   ↑___________________________|
        （消息总线/共享状态）

适用场景：需要多轮协商的复杂决策

模式三：流水线协作（Pipeline）

[输入] → [Agent A: 提取] → [Agent B: 分析] → [Agent C: 生成] → [输出]

适用场景：数据处理、内容生产等流水线作业

4.3 实战：基于 CrewAI 的多 Agent 系统

from crewai import Agent, Task, Crew

# 定义专业 Agent
researcher = Agent(
    role="技术研究员",
    goal="深入研究技术主题并收集关键信息",
    backstory="资深技术专家，擅长技术调研和趋势分析",
    tools=[search_tool, web_scraper],
    llm="gpt-4-turbo"
)

writer = Agent(
    role="技术写作者",
    goal="将技术信息转化为易懂的文章",
    backstory="资深技术写作者，擅长将复杂概念通俗化",
    llm="claude-3-opus"
)

reviewer = Agent(
    role="内容审核员",
    goal="确保内容准确性和可读性",
    backstory="严格的内容审核专家",
    llm="gpt-4-turbo"
)

# 定义协作任务
tasks = [
    Task(
        description="研究 AI Agent 最新架构趋势",
        agent=researcher,
        expected_output="详细的技术调研报告"
    ),
    Task(
        description="基于调研结果撰写技术文章",
        agent=writer,
        expected_output="结构清晰的技术文章",
        context=[tasks[0]]  # 依赖任务1的结果
    ),
    Task(
        description="审核并优化文章内容",
        agent=reviewer,
        expected_output="审核后的最终文章",
        context=[tasks[1]]
    )
]

# 创建协作团队
crew = Crew(
    agents=[researcher, writer, reviewer],
    tasks=tasks,
    process="sequential",  # 也可选择 "parallel" 或 "hierarchical"
    verbose=True
)

result = crew.kickoff()

---

五、生产级 Agent 系统的设计原则

5.1 可靠性设计

1. 超时与重试机制

@retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=4, max=10))
@timeout(30)
def agent_step(agent, context):
    return agent.run(context)

2. 熔断与降级

class CircuitBreaker:
    def __init__(self, failure_threshold=5, recovery_timeout=60):
        self.failures = 0
        self.state = "CLOSED"  # CLOSED, OPEN, HALF_OPEN
    
    def call(self, func, *args):
        if self.state == "OPEN":
            return self.fallback(*args)
        try:
            result = func(*args)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            raise e

3. 可观测性

• 结构化日志：记录每个 Thought/Action/Observation
• 追踪链：使用 LangSmith、Langfuse 等工具追踪 Agent 执行链路
• 指标监控：延迟、成功率、Token 消耗、工具调用分布

5.2 成本控制

策略	说明	效果
模型路由	简单任务用轻量模型，复杂任务用强模型	降低 40-60% 成本
缓存机制	缓存相似查询的响应	降低 20-30% 成本
流式处理	避免一次性生成大段内容	改善用户体验
Token 优化	精简 Prompt，使用压缩技术	降低 10-20% 成本

5.3 安全与权限

class SecureAgent:
    def __init__(self):
        self.tool_registry = ToolRegistry()
        self.permission_manager = PermissionManager()
    
    def execute_tool(self, tool_name: str, params: dict, user: User):
        # 1. 验证工具存在
        tool = self.tool_registry.get(tool_name)
        if not tool:
            raise ToolNotFoundError(f"Tool {tool_name} not found")
        
        # 2. 权限检查
        if not self.permission_manager.can_execute(user, tool):
            raise PermissionDeniedError(f"User {user.id} cannot execute {tool_name}")
        
        # 3. 参数校验（防止 Prompt Injection）
        sanitized_params = self.sanitize_params(params)
        
        # 4. 执行并记录审计日志
        result = tool.execute(sanitized_params)
        self.audit_log.record(user, tool_name, sanitized_params, result)
        
        return result

---

六、未来展望

6.1 技术趋势

1. Agent 即服务（AaaS）：标准化 Agent 接口，支持跨平台调用
2. 自主 Agent（Autonomous Agent）：减少人工干预，实现真正的自主决策
3. 多模态 Agent：融合文本、图像、音频、视频的综合能力
4. 边缘 Agent：轻量化模型支持端侧部署

6.2 工程挑战

• 评估难题：如何量化 Agent 系统的性能？
• 调试复杂：多步骤推理导致问题定位困难
• 安全边界：Agent 拥有实际行动能力后的风险控制
• 伦理对齐：确保 Agent 行为符合人类价值观

---

结语

AI Agent 正在从实验性技术走向生产应用。从 ReAct 到 Multi-Agent，架构设计在持续演进。作为工程师，我们需要在理解底层原理的基础上，结合实际场景做出合理的架构选择。

无论是单 Agent 的简洁高效，还是 Multi-Agent 的协作智能，核心目标始终是：让 AI 真正解决实际问题，创造业务价值。

希望本文能为你的 Agent 工程实践提供一些参考。欢迎在评论区分享你的经验和思考。

---

参考资源

1. ReAct: Synergizing Reasoning and Acting in Language Models
2. CrewAI Documentation
3. LangChain Agent Guide
4. OpenAI Function Calling Guide

---

本文首发于稀土掘金，转载请注明出处。