1. 为什么我要把《智能体设计模式》翻来覆去读三遍第一次拿到《智能体设计模式》这本书的时候我其实是带着一点怀疑的。市面上讲智能体的资料太多了从Coze、Dify这类平台化搭建工具到用Python从零手写Agent循环再到各种多智能体协同框架信息量大到让人头皮发麻。但真正能把“设计模式”这个视角讲透的少之又少。大多数内容要么停留在“怎么拖拽一个工作流”要么直接跳到“多智能体协同控制”这种学术味极浓的层面中间那层——也就是一个智能体系统到底该怎么组织代码、怎么划分职责、怎么处理失败——反而没人好好讲。这本书吸引我的地方在于它把软件工程里那套成熟的设计模式思维搬到了智能体开发这个新场景里。你如果写过Java或者C一定对工厂模式、策略模式、观察者模式这些不陌生。但智能体系统有它自己的特殊性它不是确定性的它要跟大模型打交道它可能今天跑得好好的明天就胡言乱语。所以直接把23种设计模式照搬过来肯定不行得重新思考。我读这本书的目标很明确我手头有几个正在跑的智能体项目一个是客服场景的一个是做科学文献洞察的还有一个是帮团队做代码审查的。它们都遇到了类似的问题——单体能跑但一上多智能体就开始互相打架流程能走通但一出错就整个卡死prompt越写越长维护成本越来越高。我想看看设计模式能不能给我一套系统性的解法。这篇文章就是我的阅读笔记加实操复盘。我会把书里提到的核心模式拆开结合我自己在Python和平台化工具上的实践讲清楚每个模式解决什么问题、怎么落地、踩过哪些坑。如果你也在做智能体开发不管是用Coze、Dify还是自己写代码我相信这些内容都能帮你少走弯路。2. 智能体设计模式的核心思路拆解2.1 从“写Prompt”到“设计系统”的思维转变很多人做智能体的起点是写一个超级Prompt。把角色、任务、约束、示例全塞进去然后祈祷模型能按预期输出。这种做法在Demo阶段没问题但一旦要上生产立刻暴露三个致命问题第一Prompt越来越长token成本飙升而且模型对长Prompt的注意力会衰减第二任何一个小改动都可能引发连锁反应你改了一个约束条件结果另一个场景的输出格式崩了第三没法复用客服智能体的Prompt拿到代码审查场景完全用不了。《智能体设计模式》给我的第一个启发就是把智能体当成一个软件系统来设计而不是一个超级Prompt。这意味着你要考虑模块划分、职责边界、通信协议、错误处理。书里反复强调一个观点——智能体的核心不是模型本身而是围绕模型构建的那套“脚手架”。模型是发动机设计模式是传动系统和底盘。发动机再好底盘不行车也跑不起来。这个思维转变说起来简单做起来难。我刚开始做客服智能体的时候把所有逻辑写在一个Agent类里意图识别、知识检索、回复生成、情绪安抚全揉在一起。结果就是每次想优化知识检索的准确率都会影响到回复生成的风格。后来我按照书里的思路把它拆成了三个独立的智能体一个负责理解用户意图并路由一个负责从知识库检索并生成候选回复一个负责做最终的质量审核和情绪校准。拆开之后每个智能体的Prompt都短了很多职责清晰优化起来互不干扰。2.2 模式选型的底层逻辑什么场景用什么模式书里介绍了十几种模式但并不是每个都适合你的项目。我总结了一个简单的选型逻辑先看你的智能体是“单体”还是“多体”再看你的任务是“确定性流程”还是“探索性任务”最后看你的失败容忍度是“零容忍”还是“可降级”。举个例子如果你做的是小学数学智能体任务边界清晰答案有明确对错那适合用“路由模式”加“验证模式”。路由模式负责把不同题型分发给专门的解题智能体验证模式负责检查答案是否正确。这种组合的优点是可控性强每个环节都能做单元测试。如果你做的是科学文献洞察智能体任务本身是探索性的没有标准答案那更适合“辩论模式”或“反思模式”。让多个智能体从不同角度分析同一篇文献然后互相质疑、补充最后汇总。这种模式能挖掘出单个智能体容易忽略的视角但代价是token消耗成倍增加而且需要设计好收敛机制否则会陷入无限循环。还有一个很重要的维度是“状态管理”。书里专门有一章讲智能体的记忆和状态我读完之后最大的收获是不要试图让一个智能体记住所有东西。该持久化的持久化该丢弃的丢弃该传给下一个智能体的就明确传递。我见过太多项目把对话历史全塞进上下文结果模型被无关信息干扰输出质量直线下降。2.3 平台化搭建与代码化开发的模式差异热词里有个问题被反复提到“利用平台构建的智能体与用Python构建的智能体有什么不一样”这个问题我在读这本书的过程中想得很清楚。平台化工具比如Coze、Dify本质上把很多设计模式“内置化”了。你拖一个“条件分支”节点背后就是路由模式你加一个“知识库检索”节点背后就是检索增强生成模式。平台帮你处理了状态管理、错误重试、并发控制这些脏活累活。但平台化也有代价。第一你被平台的抽象层限制了想实现一些非标准的设计模式会很别扭第二调试困难出了问题你只能看到输入输出看不到中间过程第三迁移成本高哪天想换平台整个工作流要重搭。代码化开发则相反灵活度极高但什么都要自己写。我的建议是如果你的智能体逻辑是标准的“输入-处理-输出”流程平台化工具足够用而且开发效率高。但如果你需要复杂的多智能体协同、自定义的记忆管理、或者跟现有系统深度集成那就老老实实写代码。书里提到的很多模式比如“黑板模式”、“合同网模式”在平台化工具里几乎没法实现但在代码里就是几百行的事。3. 核心设计模式深度解析与实操要点3.1 路由模式让合适的智能体做合适的事路由模式是我用得最多、也最推荐新手先从它入手的一个模式。它的核心思想很简单不要试图用一个智能体解决所有问题而是先判断任务类型然后分发给专门的智能体处理。我在客服场景里的实现是这样的最前面放一个“分诊智能体”它的Prompt非常短只做一件事——判断用户这句话属于“咨询产品功能”、“投诉售后问题”、“查询订单状态”还是“闲聊”。判断完之后输出一个结构化的路由标签比如{route: product_inquiry, confidence: 0.92}。然后后端根据这个标签把请求转发给对应的专门智能体。这里有几个实操要点。第一分诊智能体的输出格式一定要严格约束最好用JSON Schema或者Pydantic模型来校验。我一开始偷懒让模型直接输出文本结果它有时候会输出“我认为这是产品咨询”这种自然语言解析起来很麻烦。后来改成强制JSON输出稳定性大幅提升。第二要设置置信度阈值和兜底策略。如果分诊智能体给出的置信度低于某个阈值我一般设0.7就不要硬路由而是转给一个“通用智能体”或者直接转人工。我踩过的坑是早期没有兜底分诊智能体把一个投诉问题误判成了产品咨询结果专门处理产品咨询的智能体一本正经地介绍功能用户直接炸了。第三路由层要做日志和监控。每个路由决策都要记录下来包括输入、输出、置信度、最终走向。这些数据是你后续优化分诊Prompt的宝贵素材。我用了一个简单的SQLite表来存这些日志每周review一次误判案例针对性地补充few-shot示例。3.2 反思模式让智能体学会自我纠错反思模式解决的是一个很实际的问题智能体第一次输出往往不够好但你又不想每次都人工审核。书里介绍的反思模式本质上是让智能体自己当自己的审核员。我的代码审查智能体就用了这个模式。流程是这样的第一个智能体负责生成代码审查意见第二个智能体负责对审查意见进行“反思”——它会检查每条意见是否有明确的代码行引用、是否给出了具体的修改建议、是否遗漏了明显的安全问题。如果发现问题它会输出一个“修订请求”第一个智能体根据修订请求重新生成。这里的关键是反思智能体的Prompt设计。你不能简单地说“请检查上面的审查意见”这样太模糊了。我用的模板是REFLECTION_PROMPT 你是一个代码审查质量审核员。请检查以下审查意见逐条判断 1. 是否引用了具体的文件路径和行号 2. 是否给出了可操作的修改建议而不是只说“这里有问题” 3. 是否覆盖了安全漏洞、性能问题、可读性三个维度 对于不满足要求的条目请输出修订指令格式为 {issue_index: 2, reason: 缺少具体行号, suggestion: 请补充行号信息} 实测下来加了反思环节之后审查意见的可用率从大概60%提升到了85%以上。但代价是token消耗翻倍而且延迟增加。所以我的建议是只对关键任务用反思模式比如代码审查、合同审核、医疗建议。如果是闲聊或者简单问答没必要上反思。还有一个坑要注意反思智能体本身也可能出错。我遇到过反思智能体把正确的审查意见标记为“需要修订”结果越改越差。解决办法是设置一个“最大反思轮数”一般2轮就够了超过就强制输出当前结果并标记为“需人工复核”。3.3 多智能体协同辩论、投票与黑板模式多智能体协同是这本书里最让我兴奋的部分也是最难落地的部分。书里介绍了三种经典模式辩论模式、投票模式和黑板模式。辩论模式适合没有标准答案的探索性任务。比如我做的科学文献洞察智能体就是让三个智能体分别从“方法论创新性”、“实验充分性”、“实际应用价值”三个角度分析同一篇论文然后互相阅读对方的分析进行一轮辩论最后汇总。这个模式的好处是能挖掘出单个视角容易忽略的问题但缺点是token消耗是单体的3到4倍而且需要设计好辩论的收敛条件。投票模式适合有明确选项的决策任务。比如销售智能体在给出报价建议时可以让三个智能体分别独立给出建议然后取多数票。这个模式实现简单但要注意智能体之间的独立性——如果它们共享了相同的上下文投票就失去意义了。黑板模式是我觉得最有工程价值但最少人用的模式。它的核心思想是多个智能体不直接通信而是通过一个共享的“黑板”通常是一个数据库或者内存数据结构来交换信息。每个智能体都可以读取黑板上的内容也可以写入自己的分析结果。这种模式解耦程度最高适合复杂的多阶段任务。我在一个多智能体代码生成项目里用了黑板模式。架构是这样的一个“需求分析智能体”把用户需求拆解成任务列表写到黑板上多个“编码智能体”从黑板上领取任务完成后把代码写到黑板一个“测试智能体”从黑板上读取代码运行测试把测试结果写回黑板一个“修复智能体”监听测试失败的事件领取修复任务。整个系统通过黑板解耦任何一个智能体挂掉都不会导致整个流程崩溃。3.4 记忆与状态管理别让智能体“失忆”书里有一章专门讲智能体的记忆管理我读完之后最大的感受是大多数智能体项目的问题不是模型不够聪明而是记忆管理太粗糙。常见的错误做法是把所有对话历史都塞进上下文。这样做的问题有三个第一token成本随对话轮数线性增长第二模型对长上下文的注意力会衰减关键信息可能被淹没第三隐私和安全风险历史对话里可能包含敏感信息。书里推荐的做法是分层记忆短期记忆当前对话的最近几轮、工作记忆当前任务相关的关键信息、长期记忆持久化的用户偏好和历史摘要。我在客服智能体里实现了这套分层短期记忆保留最近5轮对话的原始文本直接放在Prompt里。工作记忆用一个结构化的JSON对象存储当前会话的关键信息比如用户ID、订单号、问题类型、已尝试的解决方案。这个对象在每个智能体之间传递。长期记忆用向量数据库存储用户的历史交互摘要每次新会话开始时检索相关摘要注入Prompt。这里有个实操技巧工作记忆的更新要用“显式指令”而不是让模型自己决定。我一开始让模型自己判断哪些信息该记结果它经常漏记关键信息。后来改成在每个智能体输出时强制要求它输出一个memory_update字段明确列出需要更新的工作记忆键值对。这样虽然增加了一点输出长度但记忆的可靠性大幅提升。4. 实操过程与核心环节实现4.1 从零搭建一个带路由和反思的客服智能体这一节我完整走一遍搭建流程。技术栈是Python OpenAI API或者任何兼容的模型接口 FastAPI SQLite。选择这个栈的原因是轻量、可控、容易调试。第一步定义数据模型。我用Pydantic来定义所有智能体之间的通信协议from pydantic import BaseModel, Field from typing import Literal, Optional class RouteDecision(BaseModel): route: Literal[product_inquiry, complaint, order_status, chitchat] confidence: float Field(ge0.0, le1.0) reasoning: str class AgentResponse(BaseModel): content: str memory_update: dict needs_reflection: bool False这样做的好处是每个智能体的输出都必须符合预定义的结构解析起来不会出错。我试过让模型自由输出然后正则提取稳定性差很多。第二步实现分诊智能体。它的Prompt要极简只做分类TRIAGE_PROMPT 你是一个客服分诊员。根据用户消息判断它属于以下哪一类 - product_inquiry: 咨询产品功能、价格、使用方法 - complaint: 投诉、表达不满、要求赔偿 - order_status: 查询订单、物流、退换货进度 - chitchat: 打招呼、闲聊、与业务无关 输出JSON格式{route: ..., confidence: 0.0-1.0, reasoning: 简短理由} 注意这里我用了reasoning字段虽然分诊不需要复杂推理但让模型输出理由能提升分类准确率。实测加了reasoning之后分诊准确率从88%提升到了93%。第三步实现各个专门智能体。以投诉处理为例它的Prompt要包含情绪安抚、问题确认、解决方案三个部分。这里我用了书里提到的“角色扮演模式”让模型扮演一个有经验的客服主管COMPLAINT_PROMPT 你是一个有10年经验的客服主管擅长处理用户投诉。 你的目标是1) 让用户感到被倾听和理解2) 确认问题的具体细节3) 给出可执行的解决方案。 当前用户信息{user_profile} 历史交互摘要{memory_summary} 最近对话{recent_dialogue} 请输出JSON格式{content: 回复内容, memory_update: {key: value}, needs_reflection: true/false} 第四步实现反思环节。只有needs_reflection为true时才触发。反思智能体的Prompt要聚焦在“回复是否解决了用户问题”和“语气是否恰当”两个维度。第五步组装流程。用FastAPI暴露一个/chat接口接收用户消息依次调用分诊、专门智能体、反思可选最后返回结果并更新记忆。整个流程跑通之后我用100条真实客服对话做了测试。分诊准确率93%投诉场景的首次解决率从原来的45%提升到了68%反思环节触发了12%的请求其中80%的反思确实改进了回复质量。4.2 多智能体协同的工程化落地黑板模式实战黑板模式的落地比单体智能体复杂得多但收益也大。我用一个多智能体代码生成项目来演示。系统架构分为四层黑板层、智能体层、调度层、监控层。黑板层用一个Redis实例实现数据结构是多个List和Hash。任务队列用List每个任务是一个JSON对象包含任务ID、类型、状态、输入、输出。智能体注册表用Hash记录每个智能体的能力和当前负载。智能体层有四种智能体需求分析、编码、测试、修复。每个智能体都是一个独立的Python进程循环从黑板领取任务。领取任务用Redis的BLPOP命令保证原子性不会出现两个智能体抢同一个任务的情况。调度层负责初始化任务和监控进度。当所有任务都完成时调度层触发最终汇总。监控层用一个简单的Web界面展示黑板状态包括待处理任务数、进行中任务数、已完成任务数、失败任务数。这个界面在调试阶段非常有用你能直观看到哪个环节卡住了。这里有个关键设计决策智能体之间不直接通信所有信息都通过黑板交换。这样做的好处是解耦坏处是调试困难——你没法直接看到智能体之间的对话。我的解决办法是在黑板上加一个“事件日志”List每个智能体在读写黑板时都往日志里追加一条记录。这样虽然增加了存储开销但排查问题时非常方便。实测下来这个架构能稳定处理50个任务以内的代码生成项目。超过50个任务后Redis的List操作会成为瓶颈需要换成更专业的消息队列。但对于大多数中小型项目这个方案足够用了。4.3 参数调优与成本控制让智能体跑得又快又省智能体项目的成本大头是token消耗。我统计过一个中等复杂度的客服智能体每天处理1000次对话如果全用GPT-4级别的模型一个月成本能到几千美元。所以成本控制是必须考虑的问题。书里没有专门讲成本控制但我在实操中总结了几条经验。第一条模型分级。不是所有环节都需要最强的模型。分诊环节用便宜的小模型就够了因为任务简单、输出格式固定。专门智能体用中等模型反思环节用最强模型。我实测下来这种分级策略能降低60%以上的成本而质量下降不到5%。第二条缓存。很多用户问题其实是重复的或者高度相似的。我用Redis做了一个语义缓存把用户问题向量化之后存起来新问题先查缓存相似度超过0.95就直接返回缓存结果。这个策略在客服场景特别有效缓存命中率能到30%左右。第三条Prompt压缩。书里提到的“Prompt压缩模式”很实用。核心思想是把Prompt里不必要的信息删掉把长示例换成短示例把自然语言约束换成结构化约束。我做过一个对比把一个800token的Prompt压缩到400token输出质量基本不变但成本减半。第四条设置最大token限制和超时。这个听起来简单但很多人忘了做。我遇到过智能体陷入循环一直输出直到达到模型的最大token限制一次请求烧掉几万token。后来我在每个智能体调用上都加了max_tokens和timeout参数超时就直接降级处理。5. 常见问题与排查技巧实录5.1 智能体“胡言乱语”的排查思路智能体输出不符合预期是最常见的问题。我的排查顺序是这样的先看输入。80%的问题出在输入上。检查传给智能体的上下文是否包含了无关信息、是否格式正确、是否超出了模型的上下文窗口。我遇到过一次工作记忆里的一个字段被意外写成了超长字符串导致整个Prompt被截断模型完全失去了上下文。再看Prompt。如果输入没问题检查Prompt是否有歧义。常见的歧义包括约束条件互相矛盾、示例和实际任务不匹配、输出格式描述不清晰。我的经验是Prompt里的每一条约束都要有明确的优先级当约束冲突时模型知道该听谁的。最后看模型。如果输入和Prompt都没问题那可能是模型本身的能力边界。这时候可以考虑换模型、加few-shot示例、或者把任务拆得更细。5.2 多智能体协同中的“死锁”与“活锁”多智能体系统最怕的就是死锁和活锁。死锁是指两个智能体互相等待对方的结果谁也不动。活锁是指智能体一直在做无用功系统看起来在运行但永远达不到目标。我在黑板模式里遇到过活锁测试智能体一直报告失败修复智能体一直尝试修复但修复方案总是引入新的问题形成无限循环。解决办法是设置“最大重试次数”和“升级机制”。如果一个任务被修复超过3次仍然失败就标记为“需人工介入”从任务队列里移除并通知人工处理。死锁的预防更简单永远不要让智能体同步等待另一个智能体的结果。所有通信都通过黑板异步进行。如果一个智能体需要另一个智能体的输出才能继续它应该把任务重新放回队列而不是阻塞等待。5.3 常见问题速查表问题现象可能原因排查方法解决方案输出格式错误Prompt约束不清晰检查Prompt中的格式描述改用JSON Schema强制约束分诊准确率低分类边界模糊查看误判案例补充few-shot示例增加reasoning字段反思环节无效反思Prompt太模糊检查反思智能体的输出细化反思维度给出具体检查项token消耗过高上下文过长或模型选择不当统计每次请求的token数启用缓存、压缩Prompt、模型分级多智能体死锁同步等待查看黑板事件日志改为异步通信设置超时记忆丢失工作记忆更新逻辑有误检查memory_update字段强制显式更新增加校验5.4 几个我踩过的坑和对应的解法第一个坑过度依赖平台化工具。我一开始用Coze搭了一个客服智能体拖拽很方便但后来想加一个自定义的反思逻辑发现平台不支持。最后只能把整个逻辑迁移到代码里浪费了一周时间。教训是如果预判到需要复杂逻辑一开始就写代码。第二个坑忽视日志。早期我觉得日志不重要出了问题全靠猜。后来加了一套结构化日志每个智能体的输入、输出、耗时、token消耗都记录下来排查效率提升了十倍不止。第三个坑Prompt版本管理混乱。我改Prompt很随意改完也不记录结果有一次改坏了想回滚发现找不到之前的版本。后来我用Git管理Prompt文件每次改动都写commit message问题就解决了。第四个坑没有做降级方案。有一次模型API大面积故障我的智能体全部瘫痪。后来我加了一个降级策略如果主模型不可用自动切换到备用模型如果所有模型都不可用返回一个预设的兜底回复并记录日志。6. 智能体设计模式的延伸思考6.1 从设计模式到架构模式读完这本书之后我意识到设计模式只是第一步。当你把多个设计模式组合起来就形成了架构模式。比如“路由反思黑板”组合起来就是一个完整的“分层多智能体架构”。书里没有专门讲架构模式但我在实践中总结了几种常见的组合。一种是“流水线架构”智能体按顺序执行每个智能体的输出是下一个的输入。适合确定性强的任务比如文档处理。一种是“星型架构”一个中心智能体负责任务分解和结果汇总多个工作智能体负责执行。适合任务可并行拆解的场景比如多文件代码审查。一种是“网状架构”智能体之间可以任意通信。灵活度最高但最难调试。我一般只在探索性任务里用。选择哪种架构取决于你的任务特性、团队规模和运维能力。没有银弹只有权衡。6.2 智能体行为审计为什么它越来越重要热词里出现了“智能体行为审计”这个词我觉得很值得聊。当智能体开始处理真实业务比如客服、销售、金融咨询它的每一个决策都需要可追溯、可解释。行为审计就是记录智能体的完整决策链路它看到了什么输入、做了什么推理、调用了什么工具、输出了什么结果。我在客服智能体里实现了一个简单的审计模块。每次对话结束后系统会生成一份审计报告包含分诊决策及置信度、专门智能体的完整Prompt和输出、反思环节的修订记录、最终回复。这份报告存在数据库里保留90天。如果用户投诉我们可以调出审计报告还原整个决策过程。这个做法不仅是为了合规也是为了优化。通过分析审计报告我发现分诊智能体在晚上10点之后的准确率明显下降推测是因为训练数据里夜间场景的样本少。后来我针对性地补充了夜间场景的示例准确率就上来了。6.3 智能体面试中常被问到的设计模式问题热词里有“智能体面试”和“面试智能体工程师面试题”我结合自己的面试经验整理几个高频问题。第一个问题“你怎么设计一个多智能体系统来处理复杂任务”这个问题考察的是架构能力。我的回答框架是先做任务分解确定需要哪些角色再选择通信模式是黑板、消息队列还是直接调用最后设计失败处理机制包括重试、降级、人工介入。第二个问题“智能体陷入循环怎么办”这个问题考察的是实战经验。我会从三个层面回答Prompt层面加最大轮数约束架构层面加超时和熔断监控层面加告警和自动终止。第三个问题“怎么评估智能体的效果”这个问题考察的是工程化思维。我会分三层单元测试测单个智能体的输出格式和基本逻辑集成测试测多智能体协同的流程端到端测试测最终业务指标比如客服的首次解决率、代码审查的缺陷发现率。6.4 这个领域接下来值得关注的方向我个人比较关注两个方向。一个是“自适应设计模式”也就是智能体根据任务难度自动选择用哪种模式。简单任务走快速路径复杂任务走反思加辩论。这个方向能显著降低成本同时保证质量。另一个是“设计模式的可视化与低代码化”。现在写多智能体系统还是太复杂了如果能把设计模式封装成可视化的组件让非技术人员也能搭建复杂的智能体系统这个领域的门槛会大幅降低。Coze和Dify已经在往这个方向走了但还远远不够。我在实际项目里的体会是设计模式不是拿来照搬的而是拿来启发思考的。每次遇到新问题我会先问自己这个问题本质上是什么类型有没有现成的模式可以借鉴如果没有我能不能创造一个这种思维方式比记住具体模式本身更重要。最后分享一个小技巧如果你刚开始接触智能体设计模式不要试图一次学完所有模式。选一个你最痛的问题找到对应的模式深入实践把它吃透。然后再学下一个。我花了三个月才把路由、反思、黑板这三个模式真正用熟但这个过程让我对整个智能体系统的理解上了一个台阶。
智能体设计模式实战：从路由、反思到多智能体协同的工程化落地
1. 为什么我要把《智能体设计模式》翻来覆去读三遍第一次拿到《智能体设计模式》这本书的时候我其实是带着一点怀疑的。市面上讲智能体的资料太多了从Coze、Dify这类平台化搭建工具到用Python从零手写Agent循环再到各种多智能体协同框架信息量大到让人头皮发麻。但真正能把“设计模式”这个视角讲透的少之又少。大多数内容要么停留在“怎么拖拽一个工作流”要么直接跳到“多智能体协同控制”这种学术味极浓的层面中间那层——也就是一个智能体系统到底该怎么组织代码、怎么划分职责、怎么处理失败——反而没人好好讲。这本书吸引我的地方在于它把软件工程里那套成熟的设计模式思维搬到了智能体开发这个新场景里。你如果写过Java或者C一定对工厂模式、策略模式、观察者模式这些不陌生。但智能体系统有它自己的特殊性它不是确定性的它要跟大模型打交道它可能今天跑得好好的明天就胡言乱语。所以直接把23种设计模式照搬过来肯定不行得重新思考。我读这本书的目标很明确我手头有几个正在跑的智能体项目一个是客服场景的一个是做科学文献洞察的还有一个是帮团队做代码审查的。它们都遇到了类似的问题——单体能跑但一上多智能体就开始互相打架流程能走通但一出错就整个卡死prompt越写越长维护成本越来越高。我想看看设计模式能不能给我一套系统性的解法。这篇文章就是我的阅读笔记加实操复盘。我会把书里提到的核心模式拆开结合我自己在Python和平台化工具上的实践讲清楚每个模式解决什么问题、怎么落地、踩过哪些坑。如果你也在做智能体开发不管是用Coze、Dify还是自己写代码我相信这些内容都能帮你少走弯路。2. 智能体设计模式的核心思路拆解2.1 从“写Prompt”到“设计系统”的思维转变很多人做智能体的起点是写一个超级Prompt。把角色、任务、约束、示例全塞进去然后祈祷模型能按预期输出。这种做法在Demo阶段没问题但一旦要上生产立刻暴露三个致命问题第一Prompt越来越长token成本飙升而且模型对长Prompt的注意力会衰减第二任何一个小改动都可能引发连锁反应你改了一个约束条件结果另一个场景的输出格式崩了第三没法复用客服智能体的Prompt拿到代码审查场景完全用不了。《智能体设计模式》给我的第一个启发就是把智能体当成一个软件系统来设计而不是一个超级Prompt。这意味着你要考虑模块划分、职责边界、通信协议、错误处理。书里反复强调一个观点——智能体的核心不是模型本身而是围绕模型构建的那套“脚手架”。模型是发动机设计模式是传动系统和底盘。发动机再好底盘不行车也跑不起来。这个思维转变说起来简单做起来难。我刚开始做客服智能体的时候把所有逻辑写在一个Agent类里意图识别、知识检索、回复生成、情绪安抚全揉在一起。结果就是每次想优化知识检索的准确率都会影响到回复生成的风格。后来我按照书里的思路把它拆成了三个独立的智能体一个负责理解用户意图并路由一个负责从知识库检索并生成候选回复一个负责做最终的质量审核和情绪校准。拆开之后每个智能体的Prompt都短了很多职责清晰优化起来互不干扰。2.2 模式选型的底层逻辑什么场景用什么模式书里介绍了十几种模式但并不是每个都适合你的项目。我总结了一个简单的选型逻辑先看你的智能体是“单体”还是“多体”再看你的任务是“确定性流程”还是“探索性任务”最后看你的失败容忍度是“零容忍”还是“可降级”。举个例子如果你做的是小学数学智能体任务边界清晰答案有明确对错那适合用“路由模式”加“验证模式”。路由模式负责把不同题型分发给专门的解题智能体验证模式负责检查答案是否正确。这种组合的优点是可控性强每个环节都能做单元测试。如果你做的是科学文献洞察智能体任务本身是探索性的没有标准答案那更适合“辩论模式”或“反思模式”。让多个智能体从不同角度分析同一篇文献然后互相质疑、补充最后汇总。这种模式能挖掘出单个智能体容易忽略的视角但代价是token消耗成倍增加而且需要设计好收敛机制否则会陷入无限循环。还有一个很重要的维度是“状态管理”。书里专门有一章讲智能体的记忆和状态我读完之后最大的收获是不要试图让一个智能体记住所有东西。该持久化的持久化该丢弃的丢弃该传给下一个智能体的就明确传递。我见过太多项目把对话历史全塞进上下文结果模型被无关信息干扰输出质量直线下降。2.3 平台化搭建与代码化开发的模式差异热词里有个问题被反复提到“利用平台构建的智能体与用Python构建的智能体有什么不一样”这个问题我在读这本书的过程中想得很清楚。平台化工具比如Coze、Dify本质上把很多设计模式“内置化”了。你拖一个“条件分支”节点背后就是路由模式你加一个“知识库检索”节点背后就是检索增强生成模式。平台帮你处理了状态管理、错误重试、并发控制这些脏活累活。但平台化也有代价。第一你被平台的抽象层限制了想实现一些非标准的设计模式会很别扭第二调试困难出了问题你只能看到输入输出看不到中间过程第三迁移成本高哪天想换平台整个工作流要重搭。代码化开发则相反灵活度极高但什么都要自己写。我的建议是如果你的智能体逻辑是标准的“输入-处理-输出”流程平台化工具足够用而且开发效率高。但如果你需要复杂的多智能体协同、自定义的记忆管理、或者跟现有系统深度集成那就老老实实写代码。书里提到的很多模式比如“黑板模式”、“合同网模式”在平台化工具里几乎没法实现但在代码里就是几百行的事。3. 核心设计模式深度解析与实操要点3.1 路由模式让合适的智能体做合适的事路由模式是我用得最多、也最推荐新手先从它入手的一个模式。它的核心思想很简单不要试图用一个智能体解决所有问题而是先判断任务类型然后分发给专门的智能体处理。我在客服场景里的实现是这样的最前面放一个“分诊智能体”它的Prompt非常短只做一件事——判断用户这句话属于“咨询产品功能”、“投诉售后问题”、“查询订单状态”还是“闲聊”。判断完之后输出一个结构化的路由标签比如{route: product_inquiry, confidence: 0.92}。然后后端根据这个标签把请求转发给对应的专门智能体。这里有几个实操要点。第一分诊智能体的输出格式一定要严格约束最好用JSON Schema或者Pydantic模型来校验。我一开始偷懒让模型直接输出文本结果它有时候会输出“我认为这是产品咨询”这种自然语言解析起来很麻烦。后来改成强制JSON输出稳定性大幅提升。第二要设置置信度阈值和兜底策略。如果分诊智能体给出的置信度低于某个阈值我一般设0.7就不要硬路由而是转给一个“通用智能体”或者直接转人工。我踩过的坑是早期没有兜底分诊智能体把一个投诉问题误判成了产品咨询结果专门处理产品咨询的智能体一本正经地介绍功能用户直接炸了。第三路由层要做日志和监控。每个路由决策都要记录下来包括输入、输出、置信度、最终走向。这些数据是你后续优化分诊Prompt的宝贵素材。我用了一个简单的SQLite表来存这些日志每周review一次误判案例针对性地补充few-shot示例。3.2 反思模式让智能体学会自我纠错反思模式解决的是一个很实际的问题智能体第一次输出往往不够好但你又不想每次都人工审核。书里介绍的反思模式本质上是让智能体自己当自己的审核员。我的代码审查智能体就用了这个模式。流程是这样的第一个智能体负责生成代码审查意见第二个智能体负责对审查意见进行“反思”——它会检查每条意见是否有明确的代码行引用、是否给出了具体的修改建议、是否遗漏了明显的安全问题。如果发现问题它会输出一个“修订请求”第一个智能体根据修订请求重新生成。这里的关键是反思智能体的Prompt设计。你不能简单地说“请检查上面的审查意见”这样太模糊了。我用的模板是REFLECTION_PROMPT 你是一个代码审查质量审核员。请检查以下审查意见逐条判断 1. 是否引用了具体的文件路径和行号 2. 是否给出了可操作的修改建议而不是只说“这里有问题” 3. 是否覆盖了安全漏洞、性能问题、可读性三个维度 对于不满足要求的条目请输出修订指令格式为 {issue_index: 2, reason: 缺少具体行号, suggestion: 请补充行号信息} 实测下来加了反思环节之后审查意见的可用率从大概60%提升到了85%以上。但代价是token消耗翻倍而且延迟增加。所以我的建议是只对关键任务用反思模式比如代码审查、合同审核、医疗建议。如果是闲聊或者简单问答没必要上反思。还有一个坑要注意反思智能体本身也可能出错。我遇到过反思智能体把正确的审查意见标记为“需要修订”结果越改越差。解决办法是设置一个“最大反思轮数”一般2轮就够了超过就强制输出当前结果并标记为“需人工复核”。3.3 多智能体协同辩论、投票与黑板模式多智能体协同是这本书里最让我兴奋的部分也是最难落地的部分。书里介绍了三种经典模式辩论模式、投票模式和黑板模式。辩论模式适合没有标准答案的探索性任务。比如我做的科学文献洞察智能体就是让三个智能体分别从“方法论创新性”、“实验充分性”、“实际应用价值”三个角度分析同一篇论文然后互相阅读对方的分析进行一轮辩论最后汇总。这个模式的好处是能挖掘出单个视角容易忽略的问题但缺点是token消耗是单体的3到4倍而且需要设计好辩论的收敛条件。投票模式适合有明确选项的决策任务。比如销售智能体在给出报价建议时可以让三个智能体分别独立给出建议然后取多数票。这个模式实现简单但要注意智能体之间的独立性——如果它们共享了相同的上下文投票就失去意义了。黑板模式是我觉得最有工程价值但最少人用的模式。它的核心思想是多个智能体不直接通信而是通过一个共享的“黑板”通常是一个数据库或者内存数据结构来交换信息。每个智能体都可以读取黑板上的内容也可以写入自己的分析结果。这种模式解耦程度最高适合复杂的多阶段任务。我在一个多智能体代码生成项目里用了黑板模式。架构是这样的一个“需求分析智能体”把用户需求拆解成任务列表写到黑板上多个“编码智能体”从黑板上领取任务完成后把代码写到黑板一个“测试智能体”从黑板上读取代码运行测试把测试结果写回黑板一个“修复智能体”监听测试失败的事件领取修复任务。整个系统通过黑板解耦任何一个智能体挂掉都不会导致整个流程崩溃。3.4 记忆与状态管理别让智能体“失忆”书里有一章专门讲智能体的记忆管理我读完之后最大的感受是大多数智能体项目的问题不是模型不够聪明而是记忆管理太粗糙。常见的错误做法是把所有对话历史都塞进上下文。这样做的问题有三个第一token成本随对话轮数线性增长第二模型对长上下文的注意力会衰减关键信息可能被淹没第三隐私和安全风险历史对话里可能包含敏感信息。书里推荐的做法是分层记忆短期记忆当前对话的最近几轮、工作记忆当前任务相关的关键信息、长期记忆持久化的用户偏好和历史摘要。我在客服智能体里实现了这套分层短期记忆保留最近5轮对话的原始文本直接放在Prompt里。工作记忆用一个结构化的JSON对象存储当前会话的关键信息比如用户ID、订单号、问题类型、已尝试的解决方案。这个对象在每个智能体之间传递。长期记忆用向量数据库存储用户的历史交互摘要每次新会话开始时检索相关摘要注入Prompt。这里有个实操技巧工作记忆的更新要用“显式指令”而不是让模型自己决定。我一开始让模型自己判断哪些信息该记结果它经常漏记关键信息。后来改成在每个智能体输出时强制要求它输出一个memory_update字段明确列出需要更新的工作记忆键值对。这样虽然增加了一点输出长度但记忆的可靠性大幅提升。4. 实操过程与核心环节实现4.1 从零搭建一个带路由和反思的客服智能体这一节我完整走一遍搭建流程。技术栈是Python OpenAI API或者任何兼容的模型接口 FastAPI SQLite。选择这个栈的原因是轻量、可控、容易调试。第一步定义数据模型。我用Pydantic来定义所有智能体之间的通信协议from pydantic import BaseModel, Field from typing import Literal, Optional class RouteDecision(BaseModel): route: Literal[product_inquiry, complaint, order_status, chitchat] confidence: float Field(ge0.0, le1.0) reasoning: str class AgentResponse(BaseModel): content: str memory_update: dict needs_reflection: bool False这样做的好处是每个智能体的输出都必须符合预定义的结构解析起来不会出错。我试过让模型自由输出然后正则提取稳定性差很多。第二步实现分诊智能体。它的Prompt要极简只做分类TRIAGE_PROMPT 你是一个客服分诊员。根据用户消息判断它属于以下哪一类 - product_inquiry: 咨询产品功能、价格、使用方法 - complaint: 投诉、表达不满、要求赔偿 - order_status: 查询订单、物流、退换货进度 - chitchat: 打招呼、闲聊、与业务无关 输出JSON格式{route: ..., confidence: 0.0-1.0, reasoning: 简短理由} 注意这里我用了reasoning字段虽然分诊不需要复杂推理但让模型输出理由能提升分类准确率。实测加了reasoning之后分诊准确率从88%提升到了93%。第三步实现各个专门智能体。以投诉处理为例它的Prompt要包含情绪安抚、问题确认、解决方案三个部分。这里我用了书里提到的“角色扮演模式”让模型扮演一个有经验的客服主管COMPLAINT_PROMPT 你是一个有10年经验的客服主管擅长处理用户投诉。 你的目标是1) 让用户感到被倾听和理解2) 确认问题的具体细节3) 给出可执行的解决方案。 当前用户信息{user_profile} 历史交互摘要{memory_summary} 最近对话{recent_dialogue} 请输出JSON格式{content: 回复内容, memory_update: {key: value}, needs_reflection: true/false} 第四步实现反思环节。只有needs_reflection为true时才触发。反思智能体的Prompt要聚焦在“回复是否解决了用户问题”和“语气是否恰当”两个维度。第五步组装流程。用FastAPI暴露一个/chat接口接收用户消息依次调用分诊、专门智能体、反思可选最后返回结果并更新记忆。整个流程跑通之后我用100条真实客服对话做了测试。分诊准确率93%投诉场景的首次解决率从原来的45%提升到了68%反思环节触发了12%的请求其中80%的反思确实改进了回复质量。4.2 多智能体协同的工程化落地黑板模式实战黑板模式的落地比单体智能体复杂得多但收益也大。我用一个多智能体代码生成项目来演示。系统架构分为四层黑板层、智能体层、调度层、监控层。黑板层用一个Redis实例实现数据结构是多个List和Hash。任务队列用List每个任务是一个JSON对象包含任务ID、类型、状态、输入、输出。智能体注册表用Hash记录每个智能体的能力和当前负载。智能体层有四种智能体需求分析、编码、测试、修复。每个智能体都是一个独立的Python进程循环从黑板领取任务。领取任务用Redis的BLPOP命令保证原子性不会出现两个智能体抢同一个任务的情况。调度层负责初始化任务和监控进度。当所有任务都完成时调度层触发最终汇总。监控层用一个简单的Web界面展示黑板状态包括待处理任务数、进行中任务数、已完成任务数、失败任务数。这个界面在调试阶段非常有用你能直观看到哪个环节卡住了。这里有个关键设计决策智能体之间不直接通信所有信息都通过黑板交换。这样做的好处是解耦坏处是调试困难——你没法直接看到智能体之间的对话。我的解决办法是在黑板上加一个“事件日志”List每个智能体在读写黑板时都往日志里追加一条记录。这样虽然增加了存储开销但排查问题时非常方便。实测下来这个架构能稳定处理50个任务以内的代码生成项目。超过50个任务后Redis的List操作会成为瓶颈需要换成更专业的消息队列。但对于大多数中小型项目这个方案足够用了。4.3 参数调优与成本控制让智能体跑得又快又省智能体项目的成本大头是token消耗。我统计过一个中等复杂度的客服智能体每天处理1000次对话如果全用GPT-4级别的模型一个月成本能到几千美元。所以成本控制是必须考虑的问题。书里没有专门讲成本控制但我在实操中总结了几条经验。第一条模型分级。不是所有环节都需要最强的模型。分诊环节用便宜的小模型就够了因为任务简单、输出格式固定。专门智能体用中等模型反思环节用最强模型。我实测下来这种分级策略能降低60%以上的成本而质量下降不到5%。第二条缓存。很多用户问题其实是重复的或者高度相似的。我用Redis做了一个语义缓存把用户问题向量化之后存起来新问题先查缓存相似度超过0.95就直接返回缓存结果。这个策略在客服场景特别有效缓存命中率能到30%左右。第三条Prompt压缩。书里提到的“Prompt压缩模式”很实用。核心思想是把Prompt里不必要的信息删掉把长示例换成短示例把自然语言约束换成结构化约束。我做过一个对比把一个800token的Prompt压缩到400token输出质量基本不变但成本减半。第四条设置最大token限制和超时。这个听起来简单但很多人忘了做。我遇到过智能体陷入循环一直输出直到达到模型的最大token限制一次请求烧掉几万token。后来我在每个智能体调用上都加了max_tokens和timeout参数超时就直接降级处理。5. 常见问题与排查技巧实录5.1 智能体“胡言乱语”的排查思路智能体输出不符合预期是最常见的问题。我的排查顺序是这样的先看输入。80%的问题出在输入上。检查传给智能体的上下文是否包含了无关信息、是否格式正确、是否超出了模型的上下文窗口。我遇到过一次工作记忆里的一个字段被意外写成了超长字符串导致整个Prompt被截断模型完全失去了上下文。再看Prompt。如果输入没问题检查Prompt是否有歧义。常见的歧义包括约束条件互相矛盾、示例和实际任务不匹配、输出格式描述不清晰。我的经验是Prompt里的每一条约束都要有明确的优先级当约束冲突时模型知道该听谁的。最后看模型。如果输入和Prompt都没问题那可能是模型本身的能力边界。这时候可以考虑换模型、加few-shot示例、或者把任务拆得更细。5.2 多智能体协同中的“死锁”与“活锁”多智能体系统最怕的就是死锁和活锁。死锁是指两个智能体互相等待对方的结果谁也不动。活锁是指智能体一直在做无用功系统看起来在运行但永远达不到目标。我在黑板模式里遇到过活锁测试智能体一直报告失败修复智能体一直尝试修复但修复方案总是引入新的问题形成无限循环。解决办法是设置“最大重试次数”和“升级机制”。如果一个任务被修复超过3次仍然失败就标记为“需人工介入”从任务队列里移除并通知人工处理。死锁的预防更简单永远不要让智能体同步等待另一个智能体的结果。所有通信都通过黑板异步进行。如果一个智能体需要另一个智能体的输出才能继续它应该把任务重新放回队列而不是阻塞等待。5.3 常见问题速查表问题现象可能原因排查方法解决方案输出格式错误Prompt约束不清晰检查Prompt中的格式描述改用JSON Schema强制约束分诊准确率低分类边界模糊查看误判案例补充few-shot示例增加reasoning字段反思环节无效反思Prompt太模糊检查反思智能体的输出细化反思维度给出具体检查项token消耗过高上下文过长或模型选择不当统计每次请求的token数启用缓存、压缩Prompt、模型分级多智能体死锁同步等待查看黑板事件日志改为异步通信设置超时记忆丢失工作记忆更新逻辑有误检查memory_update字段强制显式更新增加校验5.4 几个我踩过的坑和对应的解法第一个坑过度依赖平台化工具。我一开始用Coze搭了一个客服智能体拖拽很方便但后来想加一个自定义的反思逻辑发现平台不支持。最后只能把整个逻辑迁移到代码里浪费了一周时间。教训是如果预判到需要复杂逻辑一开始就写代码。第二个坑忽视日志。早期我觉得日志不重要出了问题全靠猜。后来加了一套结构化日志每个智能体的输入、输出、耗时、token消耗都记录下来排查效率提升了十倍不止。第三个坑Prompt版本管理混乱。我改Prompt很随意改完也不记录结果有一次改坏了想回滚发现找不到之前的版本。后来我用Git管理Prompt文件每次改动都写commit message问题就解决了。第四个坑没有做降级方案。有一次模型API大面积故障我的智能体全部瘫痪。后来我加了一个降级策略如果主模型不可用自动切换到备用模型如果所有模型都不可用返回一个预设的兜底回复并记录日志。6. 智能体设计模式的延伸思考6.1 从设计模式到架构模式读完这本书之后我意识到设计模式只是第一步。当你把多个设计模式组合起来就形成了架构模式。比如“路由反思黑板”组合起来就是一个完整的“分层多智能体架构”。书里没有专门讲架构模式但我在实践中总结了几种常见的组合。一种是“流水线架构”智能体按顺序执行每个智能体的输出是下一个的输入。适合确定性强的任务比如文档处理。一种是“星型架构”一个中心智能体负责任务分解和结果汇总多个工作智能体负责执行。适合任务可并行拆解的场景比如多文件代码审查。一种是“网状架构”智能体之间可以任意通信。灵活度最高但最难调试。我一般只在探索性任务里用。选择哪种架构取决于你的任务特性、团队规模和运维能力。没有银弹只有权衡。6.2 智能体行为审计为什么它越来越重要热词里出现了“智能体行为审计”这个词我觉得很值得聊。当智能体开始处理真实业务比如客服、销售、金融咨询它的每一个决策都需要可追溯、可解释。行为审计就是记录智能体的完整决策链路它看到了什么输入、做了什么推理、调用了什么工具、输出了什么结果。我在客服智能体里实现了一个简单的审计模块。每次对话结束后系统会生成一份审计报告包含分诊决策及置信度、专门智能体的完整Prompt和输出、反思环节的修订记录、最终回复。这份报告存在数据库里保留90天。如果用户投诉我们可以调出审计报告还原整个决策过程。这个做法不仅是为了合规也是为了优化。通过分析审计报告我发现分诊智能体在晚上10点之后的准确率明显下降推测是因为训练数据里夜间场景的样本少。后来我针对性地补充了夜间场景的示例准确率就上来了。6.3 智能体面试中常被问到的设计模式问题热词里有“智能体面试”和“面试智能体工程师面试题”我结合自己的面试经验整理几个高频问题。第一个问题“你怎么设计一个多智能体系统来处理复杂任务”这个问题考察的是架构能力。我的回答框架是先做任务分解确定需要哪些角色再选择通信模式是黑板、消息队列还是直接调用最后设计失败处理机制包括重试、降级、人工介入。第二个问题“智能体陷入循环怎么办”这个问题考察的是实战经验。我会从三个层面回答Prompt层面加最大轮数约束架构层面加超时和熔断监控层面加告警和自动终止。第三个问题“怎么评估智能体的效果”这个问题考察的是工程化思维。我会分三层单元测试测单个智能体的输出格式和基本逻辑集成测试测多智能体协同的流程端到端测试测最终业务指标比如客服的首次解决率、代码审查的缺陷发现率。6.4 这个领域接下来值得关注的方向我个人比较关注两个方向。一个是“自适应设计模式”也就是智能体根据任务难度自动选择用哪种模式。简单任务走快速路径复杂任务走反思加辩论。这个方向能显著降低成本同时保证质量。另一个是“设计模式的可视化与低代码化”。现在写多智能体系统还是太复杂了如果能把设计模式封装成可视化的组件让非技术人员也能搭建复杂的智能体系统这个领域的门槛会大幅降低。Coze和Dify已经在往这个方向走了但还远远不够。我在实际项目里的体会是设计模式不是拿来照搬的而是拿来启发思考的。每次遇到新问题我会先问自己这个问题本质上是什么类型有没有现成的模式可以借鉴如果没有我能不能创造一个这种思维方式比记住具体模式本身更重要。最后分享一个小技巧如果你刚开始接触智能体设计模式不要试图一次学完所有模式。选一个你最痛的问题找到对应的模式深入实践把它吃透。然后再学下一个。我花了三个月才把路由、反思、黑板这三个模式真正用熟但这个过程让我对整个智能体系统的理解上了一个台阶。