智能体设计模式实战指南：从ReAct到多智能体协作的落地经验

1. 为什么“设计模式”这个词放在智能体身上，一开始让我很别扭

刚拿到《智能体设计模式》这个题目的时候，我第一反应是抗拒的。原因很简单：设计模式这个词在软件工程里已经被用烂了，23种设计模式、Java实现、C++实现、期末大作业、游戏开发里的状态机和观察者，这些语境我太熟了。突然有人把“设计模式”和“智能体”拼在一起，直觉上会怀疑是不是又在造概念。

真正让我改变看法的是去年做的一个客服智能体项目。当时团队里三个人各写各的提示词、各接各的工具，最后拼起来发现：同一个“查订单”动作，A同事写成了直接调接口，B同事写成了先问用户要单号再调接口，C同事写成了先查用户身份再决定要不要调接口。三个模块单独跑都没问题，串起来就互相打架。那一刻我才意识到，智能体开发缺的不是模型能力，而是一套描述“这类问题通常怎么解”的共同语言。这正是设计模式原本要解决的问题。

所以这篇阅读笔记不打算复述书里的目录，而是想把我读完之后真正沉淀下来的东西讲清楚：智能体设计模式到底在解决哪几类反复出现的问题，哪些模式是真正能落地的，哪些只是听起来很美，以及在真实项目里怎么判断该用哪个模式。如果你正在做智能体开发、准备智能体面试，或者只是被“智能体框架”“智能体架构”这些词绕晕了，这篇应该能帮你把脉络理出来。

需要先说明一点：智能体设计模式和传统23种设计模式不是一回事。传统设计模式解决的是代码结构复用，智能体设计模式解决的是决策流程、上下文管理、工具调用、多智能体协作这些更上层的问题。把它们混为一谈，是很多人读这类书时第一个卡点。

2. 智能体设计模式的四个问题域：先分清你面对的是哪一类麻烦

读这类内容最容易犯的错，是把所有模式平铺成一张清单，然后试图记住每一个。我的做法是先分类。把书里和热词里反复出现的模式按“它到底在解决什么问题”归堆，最后收敛成四个问题域。这个分类不是书里的原话，是我自己消化后的整理，但我觉得比按字母顺序背模式有用得多。

2.1 决策类：智能体下一步该干什么

这是最核心的一类。智能体的本质是一个循环：观察当前状态，决定下一步动作，执行，再观察。决策类模式回答的就是“怎么决定下一步”。

最基础的是ReAct 模式。热词里“基于react模式构建能思考与行动的ai智能体”说的就是这个。它的核心是把“思考”和“行动”交替进行：模型先输出一段推理，再输出一个动作，执行后把结果喂回去继续推理。听起来简单，但它的价值在于把黑盒的模型输出变成了可追踪的轨迹。我在调试智能体时最常用的手段就是打印 ReAct 的完整轨迹，一眼就能看出它是在哪一步跑偏的。

再往上是Plan-and-Execute 模式。ReAct 是走一步看一步，Plan-and-Execute 是先规划再执行。区别在哪？举个例子，用户说“帮我订明天去上海的高铁并订好酒店”。ReAct 可能会先查高铁，查完再想酒店的事；Plan-and-Execute 会先拆成“查高铁→订高铁→查酒店→订酒店”四个子任务，再逐个执行。后者在任务步骤多、依赖关系复杂时明显更稳，但代价是规划阶段一旦错了，后面全错。

还有一类是Reflection 模式，也就是让智能体自己检查自己的输出。热词里“识的llm智能体自主容错控制”本质上就是这个思路的延伸。Reflection 的关键不是让模型说“我做得很好”，而是给它一个明确的检查清单。我试过让模型自由反思，结果它每次都夸自己；后来改成“检查是否包含用户要求的三个要素，缺哪个补哪个”，效果立刻不一样。

2.2 上下文类：信息怎么进、怎么留、怎么丢

智能体的上下文窗口是有限资源，怎么管理它直接决定智能体能干多复杂的活。这类模式在热词里体现得不多，但实际项目里踩坑最多。

记忆分层模式是我用得最多的。把上下文分成短期记忆（当前对话）、长期记忆（用户偏好、历史事实）、工作记忆（当前任务的中间结果）。短期记忆直接放上下文，长期记忆存外部存储按需检索，工作记忆在任务结束后清理。不分层的话，要么上下文爆掉，要么智能体“失忆”。

上下文压缩模式解决的是长对话问题。当对话轮次多了，不能简单截断，因为早期信息可能还有用。常见做法是让模型把历史对话总结成摘要，保留关键实体和结论，丢掉寒暄和冗余。我实测下来，压缩比控制在 5:1 到 10:1 之间比较稳，压得太狠会丢关键信息。

RAG 模式热词里单独出现了，它其实属于上下文类的一个特例：把外部知识库检索结果作为上下文注入。这里有个容易忽略的点——检索回来的内容不是越多越好。我见过有人一次塞 20 个文档片段，结果模型被无关信息干扰，回答质量反而下降。通常 3 到 5 个高相关片段就够了。

2.3 工具类：智能体怎么和外部世界打交道

智能体再聪明，不调工具就只是个聊天机器人。工具类模式解决的是“怎么让模型可靠地调用外部能力”。

工具注册与描述模式是基础。每个工具要有清晰的名称、参数说明、返回值说明。我踩过的坑是工具描述写得太简略，模型不知道该什么时候用。后来改成“这个工具在什么场景下用、什么场景下不要用”都写清楚，调用准确率明显提升。

工具编排模式处理多个工具的协作。比如“查天气→根据天气推荐穿搭→根据穿搭查商品库存”，这是一条工具链。编排的关键是定义清楚每一步的输入输出契约，否则上一步的输出格式变了，下一步就崩。

错误处理与重试模式是工具类里最容易被低估的。工具调用失败是常态，网络超时、参数错误、权限不足都可能发生。好的模式是：失败后先判断错误类型，可重试的换参数重试，不可重试的降级或告知用户。我见过太多智能体一遇工具报错就整个卡死。

2.4 协作类：多个智能体怎么配合

热词里“多智能体协同”“多智能体代码”“多智能体系统的协同群集运动控制”都指向这一类。单个智能体能力有上限，复杂任务需要多个智能体分工。

角色分工模式是最常见的。比如一个“研究员”智能体负责搜集信息，一个“分析师”负责处理数据，一个“写手”负责成文。关键是角色边界要清晰，否则会互相抢活或互相推诿。

辩论与投票模式用于提高决策质量。让多个智能体对同一问题给出方案，再通过投票或辩论收敛。这个模式成本高，但在我做过的代码审查场景里确实能抓到单智能体漏掉的问题。

层级协作模式是有一个“管理者”智能体负责任务分解和调度，下面多个“执行者”智能体干活。热词里“多智能体协同的电网可靠运行”这类工业场景通常用这种结构。

把这四类分清楚之后，再回头看那些具体模式，就不会觉得是一盘散沙了。每个模式你都能回答：它属于哪一类，解决什么问题，代价是什么。

3. 从 ReAct 到多智能体：几个我真正跑过的模式拆解

分类是地图，但真正干活时你得知道每条路怎么走。这一节挑几个我在项目里实际用过的模式，讲清楚它们的内部逻辑和落地细节。没跑过的我不瞎编，跑过的我会把踩坑的地方标出来。

3.1 ReAct 的循环到底怎么转，以及它什么时候会转晕

ReAct 的伪代码看起来很简单：

while 任务未完成: thought = 模型推理当前状态 action = 模型选择动作 observation = 执行动作 把 thought/action/observation 加入上下文

但实际跑起来，问题全在细节里。

第一个坑是循环终止条件。模型不会自己知道什么时候该停。我早期版本没设终止条件，结果模型在“查资料→觉得不够→再查→还觉得不够”里死循环，烧了一堆 token。后来加了两个约束：最大循环次数（通常 5 到 8 次），以及模型可以主动输出“最终答案”动作来终止。

第二个坑是thought 的质量。如果让模型自由发挥，它的 thought 经常是“我需要查一下”这种废话。有效的做法是给 thought 一个结构，比如“当前已知什么、还缺什么、下一步动作能补上什么缺口”。这个结构一加，轨迹的可读性和任务成功率都上来了。

第三个坑是observation 的格式。工具返回的结果如果是一大坨 JSON，模型容易被淹没。我的做法是工具层做一次预处理，只把关键字段以自然语言形式返回。比如查订单接口返回 30 个字段，我只返回“订单号、状态、预计送达时间”三个。

ReAct 适合什么场景？任务步骤不确定、需要根据中间结果调整策略的场景。不适合什么？步骤固定、依赖明确的场景，那种用 Plan-and-Execute 更省 token 也更稳。

3.2 Plan-and-Execute 的规划质量决定一切

这个模式我是在一个报告生成项目里用的。用户给一个主题，智能体要搜集资料、分析、写成报告。用 ReAct 跑，它经常写着写着忘了前面查过什么；换成 Plan-and-Execute，先规划再执行，结构清晰很多。

规划阶段的关键是子任务的粒度和依赖关系。粒度太粗，执行时还是要临时决策；粒度太细，规划本身就很长。我的经验是每个子任务对应一个明确的工具调用或一段明确的生成任务，子任务数量控制在 3 到 7 个。

依赖关系要显式标注。比如“写报告”依赖“分析数据”，“分析数据”依赖“搜集资料”。有了依赖图，执行阶段可以并行无依赖的任务，也可以在某步失败时只重跑受影响的下游。

这个模式最大的风险是规划错误传播。如果规划阶段把“先分析再搜集”搞反了，后面全错。我的应对是在规划后加一个校验步骤，让模型自己检查规划是否合理，或者用一个轻量规则检查依赖是否有环。

3.3 记忆分层：别让智能体得健忘症，也别让它被记忆淹没

记忆这块我踩的坑最多。早期做法是把所有对话历史都塞进上下文，结果对话到十几轮之后，模型开始忽略早期信息，而且响应变慢、成本飙升。

后来改成三层：

• 短期记忆：最近 3 到 5 轮对话，原样保留。
• 长期记忆：用户偏好、历史事实，存外部存储，用向量检索按需取。
• 工作记忆：当前任务的中间结果，任务结束就清。

这里有个细节：长期记忆的写入时机。不是每句话都值得记。我的做法是让模型在对话结束时判断“这轮对话有没有产生值得长期记住的事实”，有才写。否则长期记忆会被噪音污染，检索出来的东西反而干扰判断。

还有一个容易忽略的点：记忆的时效性。用户三个月前说“我住在北京”，现在可能已经搬家了。长期记忆要带时间戳，检索时优先取新的，冲突时以新的为准。

3.4 多智能体协作：分工容易，收敛难

多智能体我做过两个项目，一个是代码审查，一个是内容生产。最大的体会是：分工本身不难，难的是让它们收敛到一个结果。

代码审查项目里，我设了三个智能体：一个查安全漏洞，一个查性能问题，一个查代码风格。各自跑完给出问题列表，然后合并。问题来了：安全智能体说“这行有注入风险”，性能智能体说“这行写法低效”，风格智能体说“这行不符合规范”，三个问题指向同一行代码，但修复方案互相冲突。最后我加了一个“仲裁”智能体，专门处理冲突，按优先级（安全>性能>风格）决定采纳哪个。

内容生产项目里，研究员、写手、编辑三个角色。研究员给素材，写手成文，编辑修改。跑了几轮发现写手经常抱怨素材不够，编辑经常大改写手的结构。根因是角色之间的接口契约不清晰。后来我定义了明确的交付物格式：研究员必须给出“事实点+来源+可信度”，写手必须按“引言-论点-论据-结论”结构写，编辑只能改表达不能改结构。契约一清晰，返工率大幅下降。

多智能体不是越多越好。我现在的判断标准是：如果单智能体能干，就别拆；如果拆了之后角色之间有大量来回沟通，说明拆分方式有问题。

4. 平台智能体 vs 代码智能体：同一个模式，两种活法

热词里有个问题被反复提到：“利用平台构建的智能体与用python构建的智能体有什么不一样？”这个问题我太有发言权了，因为两种方式我都深度用过。Coze、Dify 这类平台搭智能体，和用 Python 从零写，表面看是工具差异，底层其实是设计模式的实现方式差异。

4.1 平台把哪些模式做成了默认配置

平台智能体最大的价值是把一些基础模式产品化了。你在 Coze 里拖一个“知识库”节点，本质上就是在用 RAG 模式；拖一个“工作流”节点，本质上是在用工具编排模式；配一个“变量”存用户信息，本质上是在用记忆分层里的长期记忆。

好处是快。一个客服智能体，平台上一两个小时能搭出原型，代码方式可能要一两天。对于验证想法、做 demo、轻量级应用，平台优势明显。

但平台也有天花板。第一，模式被固化。平台提供什么节点你就只能用哪些模式，想实现一个平台没内置的决策逻辑，很难。第二，调试黑盒。智能体跑偏了，平台只给你看输入输出，中间轨迹不透明，排查困难。第三，复杂逻辑表达受限。多智能体协作、条件分支、循环重试这些，平台的可视化编排到一定复杂度就变得难以维护。

4.2 代码方式在哪些场景下不可替代

代码方式（Python 为主）的优势在于完全控制。ReAct 的循环条件、记忆的存储结构、工具的错误处理、多智能体的通信协议，全部可以按需定制。

我现在的判断标准是这样的：

有个折中方案我经常用：平台做原型，代码做生产。先用平台快速验证交互流程和提示词，跑通了再用代码重写，把平台里黑盒的部分显式实现出来。这样既快又可控。

4.3 从平台迁移到代码时最容易丢的东西

我做过几次平台到代码的迁移，发现最容易丢的不是功能，而是平台帮你默默处理掉的细节。

比如平台会自动管理对话历史，你迁移到代码时如果忘了做上下文管理，智能体立刻变健忘。平台会自动处理工具调用的超时和重试，代码里不写就是裸奔。平台会自动做输入输出的格式校验，代码里不写就可能因为一个字段缺失整个崩掉。

所以迁移时我的清单是：上下文管理、工具错误处理、输入校验、日志记录、限流。这五样平台默认给的，代码里必须自己补上。

5. 智能体面试里那些设计模式问题，到底在考什么

热词里“智能体面试”出现频率很高。我参与过几次智能体岗位的面试，也帮人做过模拟。发现面试官问设计模式，考的从来不是“你能不能背出 ReAct 的步骤”，而是你有没有真正做过决策。

5.1 高频问题背后的真实考点

“ReAct 和 Plan-and-Execute 你怎么选？”——考的是你有没有权衡意识。标准答案不是哪个更好，而是“取决于任务步骤是否确定、token 预算多少、失败代价多大”。

“智能体调用工具失败了怎么办？”——考的是工程严谨度。只答“重试”是不够的，要分错误类型：参数错误改参数，超时重试，权限问题降级，未知错误上报。

“多智能体怎么避免死循环？”——考的是协作设计。要答出终止条件、最大轮次、仲裁机制、超时兜底。

“上下文太长怎么处理？”——考的是记忆管理。要答出分层、压缩、检索，而不是简单截断。

“怎么评估智能体好不好？”——考的是评估思维。要答出任务成功率、工具调用准确率、平均轮次、成本，以及怎么构造测试集。

5.2 我见过的最加分的回答方式

有个候选人的回答我印象很深。问“怎么设计一个客服智能体”，他没有直接列模式，而是先问：“这个客服要处理几类问题？有没有人工兜底？响应时间要求多少？”然后根据假设给出方案：简单问题用 RAG 直接答，复杂问题走 ReAct 调工具，搞不定的转人工。

这种回答的加分点在于：先澄清需求再谈方案。智能体设计模式不是拿来炫技的，是拿来解决问题的。面试官想看到的是你知道什么时候用什么模式，以及为什么。

反过来，最减分的回答是堆术语。“我用 ReAct 加 Reflection 加多智能体协作”——问他为什么这么组合，答不上来。模式不是越多越好，每个模式都有成本，用之前得说清楚它换来了什么。

6. 把模式用对：几个我反复验证过的判断原则

读完整本书、跑完这些项目之后，我沉淀下来几条判断原则。它们不是书里的原话，是我自己踩坑踩出来的，但我觉得比模式清单本身更有用。

原则一：先用最简单的模式，不够再加。很多人一上来就上多智能体，结果发现单智能体加个好提示词就能解决。模式是有成本的，ReAct 比单次调用贵，多智能体比单智能体贵，Plan-and-Execute 比 ReAct 贵。从便宜的开始，遇到瓶颈再升级。

原则二：模式的选择取决于失败代价。如果智能体答错了用户只是笑笑，那用简单模式快速迭代；如果答错了会造成实际损失，那就得上 Reflection、多智能体投票这些提高可靠性的模式。代价决定投入。

原则三：可观测性比模式本身更重要。再好的模式，如果跑起来是黑盒，你也没法优化。我现在的项目里，每个智能体的决策轨迹、工具调用、上下文变化都有日志。有了可观测性，你才能判断模式有没有起作用。

原则四：模式要跟着模型能力走。模型能力在变，模式的有效性也在变。早期需要复杂编排才能做到的事，新模型可能一个提示词就搞定了。所以别把模式当教条，定期重新评估。

原则五：别为了用模式而用模式。这是最重要的一条。设计模式是工具箱，不是任务清单。你的任务是解决问题，不是把工具箱里的东西全用一遍。

最后分享一个我自己的小习惯：每做一个智能体项目，我都会在结束后记一笔——这个项目用了哪些模式，哪些起了作用，哪些是多余的。积累下来，下次遇到类似问题，判断会快很多。智能体设计模式这东西，看一遍记不住，用一遍才有感觉，用错一遍才真记住。