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、多智能体投票这些提高可靠性的模式。代价决定投入。原则三可观测性比模式本身更重要。再好的模式如果跑起来是黑盒你也没法优化。我现在的项目里每个智能体的决策轨迹、工具调用、上下文变化都有日志。有了可观测性你才能判断模式有没有起作用。原则四模式要跟着模型能力走。模型能力在变模式的有效性也在变。早期需要复杂编排才能做到的事新模型可能一个提示词就搞定了。所以别把模式当教条定期重新评估。原则五别为了用模式而用模式。这是最重要的一条。设计模式是工具箱不是任务清单。你的任务是解决问题不是把工具箱里的东西全用一遍。最后分享一个我自己的小习惯每做一个智能体项目我都会在结束后记一笔——这个项目用了哪些模式哪些起了作用哪些是多余的。积累下来下次遇到类似问题判断会快很多。智能体设计模式这东西看一遍记不住用一遍才有感觉用错一遍才真记住。