Agent设计模式全景图——从ReAct到Multi-Agent的完整知识体系

Agent概念在2023年就已出现，2024年是框架快速迭代的一年。到了2026年，Agent设计模式逐渐成熟，成为工程实践的关键。

GitHub上关于Agent的开源项目突破10万个，LangChain、LangGraph、AutoGen、CrewAI……框架层出不穷。但翻遍这些文档，你会发现一个尴尬的事实：大家都在造轮子，但很少有人告诉你怎么正确地造轮子。

你写个能调用工具的Agent，跑三次崩两次；想让多个Agent协作，结果他们互相踩坑；好不容易跑通了，代码像意大利面一样难维护。

这不怪你。Agent工程还在早期阶段，业界还在摸索最佳实践。但有些模式已经被反复验证过，能帮你少走弯路。

这篇是"Agent设计模式"系列的开篇，先给你一张全景图。

什么是Agent？

先搞清楚三个容易混淆的概念：RPA、聊天机器人、Agent。

RPA（机器人流程自动化）像是一台不会思考的打字机。你告诉它"打开Excel，复制A列，粘贴到B列，保存"，它就机械地执行。遇到Excel弹个错误框，它就卡住了。

聊天机器人像是一个只能对话的客服。能回答"退货怎么办理"、"快递到哪了"，但你要它"帮我查查昨天的订单，然后给客服发个邮件催一下"，它就无能为力——它不会执行操作。

Agent像是一个有脑子、能干活的真实员工。

听到"查昨天的订单，给客服发邮件催一下"，它会：

• 想一想：昨天的订单在哪？怎么查？
• 查数据：调用API找到订单
• 写邮件：根据订单信息生成邮件内容
• 发邮件：调用邮件接口发送
• 记录：把这件事记下来，下次问起还能回答

Agent和前两者的核心区别在于四个能力：感知、规划、行动、记忆。

感知是Agent的眼睛和耳朵。它能读代码、看文档、查日志、监控指标。感知范围外的世界，对Agent来说不存在。

规划是Agent的脑子。它不会一条道走到黑，会拆解任务、制定步骤、遇到障碍时调整方案。

行动是Agent的手。调用API、执行命令、写文件、发消息——把想法变成现实。

记忆是Agent的本子。它能记住上下文、记住以前做过什么、记住哪些方法有效哪些不行。没有记忆的Agent，每次对话都是从零开始。

这四个能力缺一不可。只有感知和行动，那是RPA；只有对话和记忆，那是聊天机器人；四者齐全，才是Agent。

为什么要学设计模式？

你说："我写个Agent能跑就行，为什么要学设计模式？"

原因有三个。

第一，避免重复造轮子。

ReAct模式已经被LangChain验证过无数次了，你没必要自己再发明一遍。

MCP（Model Context Protocol）已经定义了工具的标准接口，你不需要自己设计一套。用现成模式，省下来的时间可以用来解决真正的问题。

第二，提升系统可靠性。 我见过一个项目，四个Agent并行跑，结果A改了配置文件，B覆盖了A的改，C又覆盖了B的改——最后配置一片混乱。用Multi-Agent的分层模式，就能避免这种冲突。设计模式里沉淀的都是前人踩过的坑。

第三，降低维护成本。 三个月后你自己写的Agent代码，你自己都看不懂。但如果是ReAct模式，一看就知道"哦，这是思考-行动循环"；如果是Planner模式，就知道"这是先规划再执行"。模式提供了认知的框架。

举个真实的例子。某公司用Agent做代码审查，最开始是"单Agent一把梭"——一个Agent读整个PR然后给意见。结果是：小改动也花5分钟，大改动反而3分钟就给不出有用建议（上下文不够了），而且反馈质量不稳定。

后来改成Planner模式：先有一个Agent分析PR结构，拆分成10个子任务；然后10个Worker Agent并行处理；最后一个Evaluator Agent汇总结果。时间从平均8分钟降到2.5分钟，误判率从15%降到4%。

这就是设计模式的价值：不是让你的Agent更聪明，而是让它更靠谱。

设计模式分类

Agent的设计模式可以分成两大类：行为模式和架构模式。

行为模式关注单个Agent怎么做事。它解决的是"一个Agent如何有效完成任务"的问题。

架构模式关注多个Agent如何协作。它解决的是"多个Agent如何组成系统"的问题。

▪ 行为模式

1. ReAct模式（最基础也最重要）

ReAct = Reasoning + Acting。这是Agent最经典的模式：思考→行动→观察→再思考。

用户：帮我查一下昨天的销售额 Agent思考：销售额数据在哪？应该在数据库里 Agent行动：调用SQL查询工具 Agent观察：查询结果：昨日销售额125万元 Agent思考：这个数字需要给用户，但可能需要一些上下文 Agent行动：调用查询前日数据 Agent观察：前日销售额118万元 Agent思考：同比增长6%，需要告诉用户 Agent回复：昨日销售额125万元，比前日增长6%

ReAct的核心是把"思考"显式化——不是让模型直接输出结果，而是让它输出思考过程，然后根据思考调用工具。这样做的好处是可观测、可调试、可改进。

LangChain早期的Agent实现，以及其最经典的示例，都是基于ReAct模式的。这是单Agent任务的起点，90%的简单场景用这个模式就够。

2. Reflection模式（自我反思）

ReAct模式有个问题：Agent会一条道走到黑。比如让它"写一个排序算法"，它可能会写个冒泡排序就结束了，不会反思"有没有更好的方法"。

Reflection模式加入了一个反馈循环：完成任务后，让Agent自我评估，然后根据评估结果改进。

Agent任务：写一个排序算法 Agent初稿：冒泡排序，时间复杂度O(n²) Agent反思：这个算法效率太低，有没有更好的？ Agent改进：改用快速排序，时间复杂度O(n log n) Agent反思：考虑边界情况了吗？重复元素、空数组？ Agent改进：增加边界检查，优化重复元素处理 最终输出：健壮的快速排序实现

Reflection模式特别适合编程、写作这类需要迭代改进的任务。LangGraph的"反思循环"就是典型实现。

3. Tool Use模式（工具使用）

这个模式听起来简单，但坑很多。

Tool Use的核心思想是：Agent不直接执行操作，而是写代码来执行操作。

为什么？有两个原因。

第一，上下文效率。如果你的Agent能调用50个工具，把50个工具的描述塞进上下文，会占大量token。更好的方式是：Agent知道"我需要查数据库"，然后写Python代码调用数据库API——工具的定义在代码库里，不在上下文里。

第二，安全性。工具描述可能被注入恶意指令（Tool Poisoning Attacks）。让Agent写代码调用工具，代码是可见的、可审计的，比直接调用工具更安全。

Anthropic的Artifacts、OpenAI的Code Interpreter，都是Tool Use模式的体现。

▪ 架构模式

4. Planning模式（规划分解）

Planner模式解决的是复杂任务怎么拆解的问题。

一个任务太复杂，让一个Agent从头做到尾，容易半途而废。Planner模式的思路是：先有一个Planner Agent把大任务拆解成小任务，然后由Worker Agent逐个执行。

用户任务：帮我重构这个服务，提升性能 Planner Agent分析： 1. 分析当前代码，找出性能瓶颈 2. 查询系统监控，确认瓶颈是否在运行时 3. 针对瓶颈设计优化方案 4. 实现优化 5. 部署测试 6. 监控效果 Worker Agent 1：执行步骤1 Worker Agent 2：执行步骤2 ... Worker Agent 6：执行步骤6

Planner模式的好处是可中断、可恢复。如果执行到第4步出错了，你不需要从头开始，只需要重做第4步。

AutoGen的GroupChat模式中有专门的Planner角色分解任务，然后分配给其他Worker角色，这是Planning模式的典型实现。

5. Multi-Agent模式（多Agent协作）

Multi-Agent模式解决的是专业分工的问题。

不是所有任务都适合用一个全能Agent来做。专业Agent做专业事，效率更高、质量更好。

代码审查Multi-Agent系统： - Reviewer Agent：负责代码审查，给出修改建议 - Security Agent：专门检查安全问题（SQL注入、XSS等） - Performance Agent：专门检查性能问题 - Documentation Agent：检查文档是否完整 - Orchestrator Agent：协调其他Agent，汇总结果

Multi-Agent模式的核心是职责分离和协调机制。每个Agent有自己的专业领域，但它们之间需要有清晰的沟通协议，否则会互相干扰。

CrewAI是Multi-Agent模式的典型实现，而LangGraph则提供了构建自定义Multi-Agent系统的底层基础设施。

系列预告

这篇是开篇，给你一张全景图。接下来的5篇，我会逐一深入每个模式：

第2篇：ReAct模式深度解析

• ReAct的完整工作流程
• 如何设计有效的思考提示
• 常见坑和解决方案
• 实战：从零实现一个ReAct Agent

第3篇：Reflection模式

• 如何设计反思循环
• 自我评估的技巧
• 何时启用反思，何时关闭
• 实战：用Reflection改进代码生成质量

第4篇：Tool Use模式

• 工具定义的最佳实践
• 代码沙箱安全设计
• 工具发现与组合
• 实战：构建安全的多工具Agent

第5篇：Planning模式

• 任务分解的策略
• Planner与Worker的协作
• 状态管理与恢复
• 实战：实现一个能处理复杂项目的Planner

第6篇：Multi-Agent模式

• Agent角色设计
• 通信协议与消息传递
• 冲突解决与一致性
• 实战：构建Multi-Agent代码审查系统

学习路线建议

如果你刚开始接触Agent，建议的路线是：

1. 先读第2篇（ReAct）这是基础。理解了ReAct，你就理解了Agent的核心机制。
2. 然后读第4篇（Tool Use）这是实战必经之路。工具调用是Agent最常用的能力。
3. 再看第3篇（Reflection）这是进阶。当你发现Agent输出不够稳定时，反思循环能显著提升质量。
4. 接着读第5篇（Planning）这是处理复杂任务的关键。
5. 最后读第6篇（Multi-Agent）这是高级话题。等你需要处理大规模任务时，Multi-Agent的价值才会体现出来。

如果你已经有一定经验，可以直接跳到你感兴趣的部分。

最后说句实话

Agent工程还在早期，很多模式还在演化。我现在写的这些，三年后可能过时了。但设计思维不会过时：识别问题、抽象模式、验证模式、迭代改进。

这就是这个系列的核心——不是给你一个固定的答案，而是给你一个思考的框架。

下篇见，我们深入ReAct模式。

💡 一句话带走：Agent不是会聊天的大模型，是有感知、规划、行动、记忆的数字员工。设计模式不是约束，是前人踩过的坑。