Agent 不是更聪明的 chatbot,它是一台会自主决策的任务引擎。
AI Agent 的本质是:LLM 作为推理内核,通过感知、规划、行动、记忆的循环,自主完成多步骤任务。
随着工具调用(Function Calling)能力的成熟,Agent 已从学术概念走向规模化落地。本文系统梳理当前最主流的架构设计模式。
一、Agent 的基础组件
无论哪种架构,所有 Agent 都共享以下基础组件:
┌─────────────────────────────────────────┐
│ Agent 核心 │
│ │
│ 感知(Perception) │
│ └── 接收用户输入、工具返回、环境状态 │
│ │
│ 规划(Planning) │
│ └── LLM 推理:下一步做什么? │
│ │
│ 行动(Action) │
│ └── 调用工具、执行代码、生成内容 │
│ │
│ 记忆(Memory) │
│ ├── 短期:当前对话上下文 │
│ └── 长期:向量数据库、结构化存储 │
└─────────────────────────────────────────┘工具(Tools) 是 Agent 的手脚,典型工具包括:
| 工具类型 | 示例 | 用途 |
|---|---|---|
| 信息检索 | web_search, RAG查询 | 获取外部知识 |
| 代码执行 | Python REPL, bash | 计算、数据处理 |
| 文件操作 | read_file, write_file | 持久化数据 |
| API调用 | REST API, 数据库查询 | 系统集成 |
| UI操作 | browser_use, 截图分析 | 自动化操作 |
二、架构模式一:ReAct(推理-行动循环)
核心思想
ReAct(Reasoning + Acting)是最基础也是最广泛使用的 Agent 架构。它将"推理"和"行动"交织成一个循环:
[Thought] → [Action] → [Observation] → [Thought] → ...工作流程示例
用户问题:帮我找出最近一个月Python最受欢迎的10个开源项目
Thought: 我需要搜索GitHub上近期Star增长最快的Python项目
Action: search_web("GitHub trending Python repositories last month")
Observation: 返回搜索结果,包含多个项目列表
Thought: 结果不够精确,应该直接查询GitHub Trending API
Action: github_api("trending/repositories?language=python&since=monthly")
Observation: 返回结构化的项目列表,包含名称、Star数、描述
Thought: 数据已获取,需要按Star增量排序并格式化
Action: sort_and_format(data, key="stars_gained", limit=10)
Observation: 格式化完成的TOP10列表
回答: 以下是本月GitHub上最受欢迎的10个Python开源项目...优势与局限
优势: 简单直观、可解释性强、适合工具使用类任务
局限: 面对复杂长链任务容易"迷失方向";错误累积无法回溯;无并行能力
适用场景
三、架构模式二:Plan-and-Execute(规划-执行分离)
核心思想
将"规划"和"执行"解耦,由不同的 LLM 实例或不同的 Prompt 担任:
Planner(规划者)→ 分解任务为子步骤列表
Executor(执行者)→ 逐步执行每个子任务
Re-Planner(重规划者)→ 根据执行结果动态调整计划工作流程示例
# 第一步:Planner 制定计划
plan = planner_llm("""
任务:为我们的SaaS产品撰写竞品分析报告
请制定详细的执行计划:
1. 搜索市场上主要竞争对手
2. 收集每个竞品的功能特性、定价、用户评价
3. 分析竞品的优劣势
4. 总结我们的差异化机会
5. 撰写结构化报告
""")
# 第二步:Executor 逐步执行
for step in plan.steps:
result = executor_llm(step, previous_results)
results.append(result)
# 第三步:Re-Planner 动态调整
if needs_replanning(result):
plan = replanner_llm(original_task, completed_steps, result)优势与局限
优势: 处理长链任务能力强;计划可检查可干预;执行失败时可局部重规划
局限: 初始规划可能遗漏细节;Planner 和 Executor 的 Prompt 需要分别优化;Token 消耗更高
适用场景
四、架构模式三:Reflection(自我反思)
核心思想
Agent 在产生初步输出后,由一个 Critic(评判者)对输出进行评估,发现问题后重新生成,形成"自我改进"循环:
Generator → 生成初步输出
Critic → 评估质量,指出问题
Generator → 根据反馈修改
(循环直到满足标准或达到最大轮次)工作流程示例
max_rounds = 3
output = generator_llm(task)
for round in range(max_rounds):
critique = critic_llm(f"""
原始任务:{task}
当前输出:{output}
请从以下维度评估:
1. 准确性:内容是否正确?
2. 完整性:是否覆盖所有要求?
3. 质量:表达是否清晰专业?
如果发现问题,列出具体改进点。
如果质量已达标,回复 "PASS"
""")
if "PASS" in critique:
break
output = generator_llm(f"根据以下反馈修改输出:{critique}\n原输出:{output}")Reflexion 框架
Reflexion 是 Reflection 的强化版:将反思内容存入长期记忆,使 Agent 在类似任务上"越做越好":
失败案例 → 生成反思摘要 → 存入记忆数据库
新任务开始 → 检索相关历史反思 → 注入当前上下文 → 避免重蹈覆辙适用场景
五、架构模式四:Multi-Agent(多智能体协作)
核心思想
将复杂任务分配给多个专业化的 Agent,各司其职,协同完成。
两种协作模式:
层级模式(Hierarchical):
Orchestrator(编排者)
├── Research Agent(负责搜索和信息收集)
├── Analysis Agent(负责数据分析)
├── Writing Agent(负责内容生成)
└── Review Agent(负责质量检查)协作模式(Collaborative / Debate):
Agent A 提出方案 → Agent B 评估批判 → Agent C 整合优化
(适用于需要多角度思考的决策场景)工程实现示例(LangGraph)
from langgraph.graph import StateGraph, END
# 定义状态
class ResearchState(TypedDict):
task: str
search_results: list
analysis: str
final_report: str
# 定义各节点
def research_node(state):
results = search_agent(state["task"])
return {"search_results": results}
def analysis_node(state):
analysis = analysis_agent(state["search_results"])
return {"analysis": analysis}
def writing_node(state):
report = writing_agent(state["task"], state["analysis"])
return {"final_report": report}
# 构建图
graph = StateGraph(ResearchState)
graph.add_node("research", research_node)
graph.add_node("analysis", analysis_node)
graph.add_node("writing", writing_node)
graph.add_edge("research", "analysis")
graph.add_edge("analysis", "writing")
graph.add_edge("writing", END)
app = graph.compile()优势与局限
优势: 专业分工提升质量;任务可并行加速;每个 Agent 的上下文更聚焦
局限: 协调开销大;Agent 间通信设计复杂;调试和可观测性挑战显著增加
适用场景
六、架构选型决策框架
任务复杂度如何?
├── 简单(单工具、1-3步)
│ └── → ReAct 即可
│
├── 中等(多工具、4-10步)
│ ├── 需要自我改进? → Reflection + ReAct
│ └── 步骤顺序明确? → Plan-and-Execute
│
└── 复杂(需专业分工、长流程)
├── 任务可并行? → Multi-Agent(并行模式)
└── 需要多角度决策? → Multi-Agent(协作/辩论模式)七、生产落地的关键工程考量
可靠性设计
# 必须实现的容错机制
@retry(max_attempts=3, backoff=exponential)
def tool_call_with_retry(tool, args):
...
# 人工干预节点
if confidence < threshold:
result = await human_approval(action_plan)成本控制
Agent 的 Token 消耗是单次对话的 10-100 倍。关键策略:
可观测性
生产 Agent 必须记录完整执行轨迹:
每一步记录:时间戳 | 节点名称 | 输入 | 输出 | Token用量 | 延迟
推荐工具:LangSmith、Langfuse、Arize Phoenix八、2026年的Agent格局
当前主流 Harness 框架对比:
| 框架 | 适合模式 | 学习曲线 | 生产成熟度 |
|---|---|---|---|
| LangGraph | 所有模式,状态机 | 中 | 高 |
| AutoGen | Multi-Agent 对话 | 低 | 中 |
| CrewAI | 角色化 Multi-Agent | 低 | 中 |
| Dify | 可视化编排 | 极低 | 高 |
| OpenHands | 代码 Agent | 低 | 中高 |
探索智能,酷在前沿