迪图
发布于 2026-10-20 / 12 阅读
0
0

AI Agent 架构设计模式:从 ReAct 到多智能体协作

AI Agent 架构设计模式:从 ReAct 到多智能体协作

Agent 不是更聪明的 chatbot,它是一台会自主决策的任务引擎。这篇给出五种主流模式与选型决策框架。

基础组件:不论哪种架构都一样

组件

职责

实现

感知(Perception)

接收用户输入、工具返回、环境状态

输入解析、API 响应

规划(Planning)

下一步做什么

LLM 推理

行动(Action)

调用工具、执行代码、生成内容

代码执行器、HTTP 客户端

记忆(Memory)

短期上下文、长期知识

对话历史、向量数据库

工具(Tools)

Agent 的手脚

Function Calling、MCP

工具设计的两条要点

要点一:描述要写清"什么时候用、参数含义、返回结构"

模型是靠描述来决策的。描述模糊,模型就乱调。

# 不好的描述
def search(query): """搜索"""

# 好的描述
def search(query: str, max_results: int = 5) -> list[dict]:
    """在内部知识库中搜索文档片段。

    何时使用:用户询问产品文档、政策、FAQ 等内部知识时。
    何时不用:用户问实时信息或公开事实时(用 web_search)。

    Args:
        query: 自然语言查询,不要超过 200 字符
        max_results: 返回片段数,1-20

    Returns:
        [{"text": str, "source_url": str, "score": float}, ...]
    """

要点二:工具数量要克制

给模型 5 个精心设计的工具,胜过 20 个粗制滥造的工具。 工具太多且描述相似时,模型每次选工具都像抽盲盒——这就是"上下文混淆"。

模式一:ReAct(推理-行动循环)

最基础、应用最广泛的模式。循环执行 思考 → 行动 → 观察,直到任务完成。

用户:帮我找出最近一个月 Python 最受欢迎的 10 个开源项目

第一轮
  思考:我需要搜索 GitHub 上近期 Star 增长最快的 Python 项目
  行动:search_web("GitHub trending Python repositories last month")
  观察:返回搜索结果,包含多个项目列表

第二轮
  思考:结果不够精确,应该直接查询 GitHub Trending API
  行动:github_api("trending/repositories?language=python&since=monthly")
  观察:返回结构化的项目列表

第三轮
  思考:数据已获取,需要按 Star 增量排序并格式化
  行动:sort_and_format(data, key="stars_gained", limit=10)
  观察:格式化完成的 TOP10 列表

回答:以下是本月 GitHub 上最受欢迎的 10 个 Python 开源项目……

项

内容

优势

简单直观、可解释性强、适合工具使用类任务

局限

复杂长链任务容易迷失;错误累积无法回溯;无并行能力

适用

信息检索与整合、简单数据处理、单轮代码生成与调试

模式二:Plan-and-Execute(规划-执行分离)

把"规划"和"执行"解耦,交给不同的 Prompt 或不同的模型实例。

Planner(规划者)→ 拆解为子步骤列表
Executor(执行者)→ 逐步执行
Re-Planner(重规划者)→ 根据结果动态调整

以"撰写竞品分析报告"为例:

规划者产出:

1. 搜索市场主要竞争对手

2. 收集每个竞品的功能特性、定价、用户评价

3. 分析竞品优劣势

4. 总结我们的差异化机会

5. 撰写结构化报告

执行者逐步执行,每步产出作为下一步输入。

重规划者:一旦某步结果偏离预期(如竞品数量远超估计),带着"已完成步骤 + 当前结果"重新规划剩余步骤。

项

内容

优势

长链任务能力强;计划可检查、可干预;失败时可局部重规划

局限

初始规划可能遗漏细节;两个 Prompt 需分别优化;Token 消耗更高

适用

深度研究报告、多步骤数据分析流水线、复杂开发任务

模式三:Reflection(自我反思)

初步输出 → Critic 评估 → 发现问题则重新生成 → 循环。

Generator 生成初步输出
   ↓
Critic 评估质量、指出问题
   ↓
Generator 根据反馈修改
   ↓
(循环直到满足标准,或达到最大轮次)

Critic 通常只看三件事:

维度

问什么

准确性

内容是否正确?

完整性

是否覆盖所有要求?

质量

表达是否清晰专业?

发现问题就列出具体改进点;质量达标则返回 PASS,循环终止——典型上限 3 轮。

Reflexion:把反思存进长期记忆

Reflection 的强化版:

失败案例 → 生成反思摘要 → 存入记忆数据库
新任务开始 → 检索相关历史反思 → 注入当前上下文 → 避免重蹈覆辙

Agent 在类似任务上"越做越好",靠的就是这个。

适用

代码生成(测试驱动的自我修正)、内容创作(质量迭代)、复杂推理(答案自检)

模式四:Multi-Agent(多智能体协作)

层级模式(Hierarchical)

Orchestrator(编排者)→ 拆解任务、分派角色、汇总结果
  ├─ Research Agent → 搜索和信息收集
  ├─ Analysis Agent → 数据分析
  ├─ Writing Agent → 内容生成
  └─ Review Agent → 质量检查

协作模式(Collaborative / Debate)

Agent A 提出方案
   ↓
Agent B 评估批判
   ↓
Agent C 整合优化

适用于需要多角度思考的决策场景。

工程实现:LangGraph 状态图

用"状态图"表达多 Agent 协作,三步:

from langgraph.graph import StateGraph, START, END

# 1. 定义共享状态
class State(TypedDict):
    task: str
    search_results: list
    analysis: str
    report: str

# 2. 注册节点
graph = StateGraph(State)
graph.add_node("research", do_research)
graph.add_node("analysis", do_analysis)
graph.add_node("writing", do_writing)

# 3. 连边
graph.add_edge(START, "research")
graph.add_edge("research", "analysis")
graph.add_edge("analysis", "writing")
graph.add_edge("writing", END)

app = graph.compile()

关键设计:每个节点只读自己需要的状态字段,只写回自己负责的字段。

这正是多 Agent 系统能被调试的关键——控制流是显式的,不是藏在某个 Prompt 里。

项

内容

优势

专业分工提升质量;任务可并行;每个 Agent 上下文更聚焦

局限

协调开销大;通信设计复杂;调试和可观测性挑战显著增加

模式五:Handoff(智能体转交)

一个 triage agent 分类用户意图,无缝转交给专业 agent,保留完整对话上下文。

triage = Agent(
    name="Triage",
    instructions="Route to the right specialist.",
    handoffs=[sales_agent, support_agent, tech_agent],
)
result = await Runner.run(triage, user_message)

适用

客服类多领域 Agent

选型决策框架

问题从来不是"哪个架构最强",而是"你的任务落在哪一档":

模式

复杂度

适用场景

ReAct

低

单 Agent + 工具

Tool-Augmented

低

外部系统集成

Handoff

中

多领域路由

Multi-Agent(辩论)

中

需要多角度决策

Plan-and-Execute

中

步骤顺序明确的长任务

Reflection + ReAct

中

需要自我改进

Multi-Agent(并行)

高

复杂任务、可并行分工

Graph Workflow

高

有状态多步骤流水线

一条务实原则:能用单 Agent 解决的,别上多 Agent;能用压缩解决的,别急着上外部存储。

多智能体的一个反面观点

Cognition 团队 2025 年的《Don't Build Multi-Agents》给出了两条重要原则:

原则一:共享上下文(Share context)

原则二:行动携带隐含决策(Actions carry implicit decisions)

翻译成实战语言:两个各自持有部分上下文的子 Agent,会基于不一致的世界观做出互相冲突的决定——而且冲突点往往不在结果上,藏在"这个子 Agent 为什么这么做"的隐含假设里。

2026 年的共识比当年更精细:

  • 隔离适用于"结果可独立验收"的任务(并行检索、批量格式转换)

  • 不适用于"决策相互依赖"的任务(架构设计、长链路编排)

判断标准只有一条:你的子任务之间需不需要谈判?需要谈判的不要拆。

框架选型

框架

核心设计

适合

学习曲线

生产成熟度

LangGraph

状态机 / 有向图

所有模式

中高

高

AutoGen

ConversableAgent 对话

Multi-Agent 对话

低

中

CrewAI

角色 + 任务 + 流程

角色化协作

低

中

LlamaIndex

数据框架 + Data Agent

RAG 密集场景

中

中高

Dify

可视化编排

快速原型

极低

高

  • 单 Agent + 固定工作流 → 用 LangChain 或原生 SDK,不必上框架

  • 复杂有状态多步骤流程 → LangGraph 是当前最稳妥的选择

  • 对话式协作(辩论、多角度评审)→ AutoGen

  • RAG 密集的企业检索 → LlamaIndex

生产落地的三件事

一、可靠性设计

重试与退避:工具调用必须带指数退避重试(最多 3 次),把偶发失败消化在系统内部。

人工干预节点:模型对高影响动作的置信度低于阈值时,把动作计划交给人确认,而不是直接执行。

二、成本控制

Agent 的 Token 消耗是单次对话的 10–100 倍。

策略

说明

工具调用前判断必要性

在选择工具前先判断

最大步骤数硬限制

防止无限循环

小模型处理简单子任务

分类、格式化用小模型

Prompt Caching

降低重复 System Prompt 费用

三、可观测性

生产环境的 Agent 必须记录完整执行轨迹。每一步至少记录:

时间戳 | 节点名称 | 输入 | 输出 | Token 用量 | 延迟

推荐工具:LangSmith、Langfuse、Arize Phoenix。

参考资料

  • ReAct 论文 — https://arxiv.org/abs/2210.03629

  • LangGraph 官方文档 — https://langchain-ai.github.io/langgraph/

  • AutoGen — https://github.com/microsoft/autogen

  • CrewAI — https://github.com/crewAIInc/crewAI

  • Cognition, *Don't Build Multi-Agents* — https://cognition.ai/blog/dont-build-multi-agents

  • Anthropic, *Effective context engineering for AI agents* — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents


评论