AI Agent 核心架构总览：从 ReAct 循环到分层设计

AI Agent 核心架构总览：从 ReAct 循环到分层设计

面向想系统构建 Agent 的开发者。本文先给速查表建立全景认知，再逐层深入原理，最后给出架构设计原则。读完你能画出完整的 Agent 架构图，并能为每个层级做技术选型。

一、概念速查

1.1 什么是 AI Agent

AI Agent（智能体）是一个能自主感知环境、做出决策、执行行动的 AI 系统。与普通 LLM 调用的"问一句答一句"不同，Agent 能主动拆解目标、调用工具、多步推理、直至完成任务。

1.2 核心术语速查

1.3 架构分层速查

一个生产级 Agent 系统从底到顶分 4 层：

1.4 快速开始：一个完整的 ReAct Agent

下面用 LangGraph 实现一个带搜索能力的 Agent。这段代码覆盖了全部 4 层的协作方式：

from langgraph.graph import StateGraph, END
from typing import TypedDict, List

# ── 编排层：定义状态（"黑板"结构） ──
class AgentState(TypedDict):
    messages: List[str]
    next_action: str

# ── 工具层：定义外部能力 ──
def search_web(query: str) -> str:
    """搜索 API（示例用，实际接入 Tavily/SerpAPI）"""
    return f"搜索结果：{query} 的相关信息"

# ── 模型层：LLM 推理节点 ──
def agent_node(state: AgentState):
    """模拟 LLM 决策——实际应调用 Qwen API"""
    last = state["messages"][-1]
    if "天气" in last:
        return {"next_action": "call_tool", "messages": ["让我查一下天气"]}
    return {"next_action": "respond", "messages": ["已获取足够信息"]}

# ── 工具执行节点 ──
def tool_node(state: AgentState):
    result = search_web(state["messages"][-1])
    return {"next_action": "continue", "messages": [result]}

# ── 编排层：组装图为 ReAct 循环 ──
graph = StateGraph(AgentState)
graph.add_node("agent", agent_node)
graph.add_node("tool", tool_node)
graph.set_entry_point("agent")

# 条件边——根据 next_action 决定走向
graph.add_conditional_edges(
    "agent",
    lambda s: s["next_action"],
    {"call_tool": "tool", "respond": END}
)
graph.add_edge("tool", "agent")  # 工具执行完回到 agent

app = graph.compile()

# ── 执行 ──
result = app.invoke({"messages": ["今天北京天气怎么样？"], "next_action": ""})
print(result["messages"])
# 输出: ["让我查一下天气", "搜索结果：今天北京天气的相关信息", ...]

关键设计点：

• State 是共享"黑板"：agent_node 和 tool_node 读写同一份数据
• 条件边实现 ReAct 循环：agent 根据推理结果选择走向 tool 还是直接结束
• tool→agent 的回边：工具执行后回到 agent 做下一轮推理，构成闭环

二、底层原理

2.1 ReAct 循环：Agent 的"推理—行动"闭环

ReAct（Reasoning + Acting）是 2023 年 Google 提出的 Agent 范式，核心思想是让 LLM 交替输出推理轨迹和行动指令。

三轮循环详解：

为什么非要用循环？ 因为现实任务很少一步完成：第一次搜索可能不够精确，代码执行可能报错，需要多次"尝试→观察→调整"。典型的科研 Agent 可能需要 5-10 轮循环才能写出一份可靠的文献综述。

2.2 编排层：Agent 的控制中枢

编排层回答的核心问题是：下一步做什么？

核心能力矩阵：

LangGraph 为什么取代了 LangChain Chain？

LangChain Chain 是线性 DAG——A→B→C 一次走完，不支持循环。但 Agent 天然需要循环（工具结果不理想要重试、信息不够要再查）。LangGraph 用有向图替代链式结构，天然支持：

• 循环边：tool→agent 构成闭环
• 条件边：agent→tool 或 agent→END 根据推理结果分支
• 并行边：fan-out 同时调用多个工具

LangGraph 核心数据结构：

# State：图的"黑板"，所有节点共享读写
class AgentState(TypedDict):
    messages: List[BaseMessage]   # 对话历史
    intermediate_steps: List[Step] # 工具调用的中间结果
    remaining_tries: int          # 最大重试次数，防止死循环

# Node：图中的一个处理单元
def agent_node(state: AgentState) -> AgentState:
    # 读取 state → LLM 推理 → 写回更新
    return {"messages": new_messages}

# Edge：节点间的连接
graph.add_edge("node_a", "node_b")                          # 普通边：固定顺序
graph.add_conditional_edges("agent", router, {...})          # 条件边：分支

状态持久化的接入非常简单：

from langgraph.checkpoint.memory import MemorySaver

checkpointer = MemorySaver()
app = graph.compile(checkpointer=checkpointer)

# 使用 thread_id 隔离不同会话
result = app.invoke(
    {"messages": ["查询2024年GDP"]},
    config={"configurable": {"thread_id": "session_001"}}
)

# 中断后可恢复：用相同 thread_id 继续
result2 = app.invoke(
    {"messages": ["再帮我跟2023年对比"]},
    config={"configurable": {"thread_id": "session_001"}}
)

2.3 模型层：Agent 的推理引擎

Agent 场景对 LLM 的要求比普通对话更高。不是所有模型都适合做 Agent。

Agent 对 LLM 的核心能力要求：

Qwen 系列在 Agent 场景的定位：

选型策略： 核心 Agent 链路用 Qwen-Plus 起步；复杂推理场景升级 Qwen-Max；预处理/分类等简单任务用 Qwen-Turbo。不要所有场景用一个模型——既浪费钱又牺牲延迟。

2.4 工具层：Agent 的能力边界

Agent 的能力边界由工具决定——没有搜索工具，Agent 不知道最新信息；没有代码执行器，Agent 算不了精确数学。

工具调用的完整链路：

Function Calling 与 MCP 的分工：

两者不是替代关系。Function Calling 解决的是"怎么说人话→转参数"，MCP 解决的是"怎么找到工具→调用工具"。生产系统中两者共存：Function Calling 做参数提取，MCP 做工具发现和调用。

2.5 记忆层：跨会话的知识持久化

没有记忆的 Agent 每轮对话都是"初次见面"。

短期记忆（Working Memory）：

• 形式：当前对话的完整消息列表
• 容量上限：LLM 上下文窗口（Qwen-Max 128K tokens）
• 超限策略：
  • 滑动窗口：丢弃最早的消息，保留最近的 N 轮
  • 摘要压缩：将旧消息压缩为一段摘要，释放上下文空间

长期记忆（Long-term Memory）：

• 形式：向量数据库中的嵌入向量 + 元数据
• 存储内容：用户偏好、历史事实、项目上下文
• 检索策略：

混合记忆架构：

2.6 Agent vs Workflow：选型决策

这是架构设计的第一选择，定义清楚了才能往下走。

选型原则：能 Workflow 别 Agent。 把确定的部分固化到 Workflow 里，只把需要灵活决策的部分交给 Agent。这也是 Anthropic 官方推荐的最佳实践。一个常见模式是"外围 Workflow + 核心 Agent"——任务的编排骨架是固定的 Workflow，骨架上的关键节点由 Agent 动态填充。

三、架构设计原则

3.1 四层分离原则

每一层只关心自己的职责，不要跨层耦合：

• 编排层不写业务逻辑，只负责"下一步去哪里"
• 模型层不做工具调用，只负责推理和输出结构
• 工具层不参与决策，只负责执行和返回结果
• 记忆层不关心推理细节，只负责存储和检索

3.2 状态可追溯原则

Agent 的不确定性决定了必须做完整的执行追踪：

• 每一轮 Thought 的内容要记录
• 每一次 Tool 调用的输入输出要记录
• 支持按照 session_id 回放整个执行过程

LangGraph 的 Checkpointer + thread_id 天然支持这个模式。

3.3 防御性设计原则

Agent 系统的故障模式比传统软件多：

• 工具调用设超时：每个工具调用都要有 timeout，防止卡死
• 关键步骤设检查点：重要决策前插入人工审批
• 最大循环次数：防止 Agent 陷入死循环
• 输出校验：工具调用的参数做类型和范围校验

3.4 渐进式复杂度原则

不要一开始就上全功能 Agent：

1. 先用 Workflow 跑通流程
2. 把需要灵活决策的节点换成 Agent
3. 给 Agent 加 Memory
4. 加多 Agent 协作
5. 加持久化和恢复

每一步都要验证"这一步真的需要吗"。