1. 项目概述从“玩具”到“生产力”的智能体进化之路最近和几个做AI应用开发的朋友聊天发现一个挺有意思的现象大家一提到“智能体”Agent第一反应往往是那些能聊天的对话机器人或者网上流传的、能自动点点点的“脚本小子”Demo。但当我们真正想把手头那个繁琐的报表自动化流程、或者那个需要跨多个系统查询信息的客服助手给做出来时却常常卡在第一步——不知道从何下手感觉Demo和实际可用的产品之间隔着一道鸿沟。这其实反映了一个核心问题我们可能接触了不少Agent的概念但对其背后系统性的工程模式缺乏理解。没有模式就像盖房子没有图纸代码容易变成一坨纠缠不清的“面条”难以维护、扩展和调试。“吃透这5种Agent模式搞定智能体开发”这个标题瞄准的正是这个痛点。它不是一个简单的API调用教程而是一份关于如何结构化地思考和组织智能体行为的实战指南。这五种模式——反射Reflection、工具使用Tool Use、规划Planning、多智能体协作Multi-Agent Collaboration以及ReActReasoning and Acting——构成了现代智能体开发中最核心、最经得起考验的架构范式。掌握它们意味着你拿到了一套从简单到复杂、应对不同场景的“设计模式”工具箱。无论是想做一个能自我纠错的代码助手还是一个能协调多个专家完成复杂任务的项目经理Agent你都能找到对应的模式来搭建骨架从而把大模型的能力稳定、可靠地嵌入到真实的业务流程中。2. 核心模式深度解析五种武器与实战场景智能体开发不是魔法其可靠性建立在清晰的架构之上。下面这五种模式每一种都解决了一类特定的问题并有其最适合的应用场景。理解它们的本质差异是做出正确技术选型的第一步。2.1 反射模式赋予智能体“三思而后行”的能力反射模式的核心思想是引入一个自我评估与修正的循环。一个基础的智能体接收到输入、调用模型、产生输出这个过程是单向的。而反射模式在这个链条中增加了一个“批判者”角色。智能体首先生成一个初始响应或行动计划然后这个响应会被提交给同一个或另一个LLM进行批判性审查审查者会评估其准确性、完整性、安全性或与目标的契合度。如果发现问题审查者会生成反馈智能体再根据反馈进行修正如此循环直到输出满足预设标准。为什么需要反射大模型本质上是概率模型存在“幻觉”编造信息、逻辑错误或偏离指令的风险。单次生成如同“一锤子买卖”质量不可控。反射模式通过多次生成-评估的迭代显著提升了输出的可靠性和质量。它模拟了人类“写完后检查一遍”的思考过程。典型工作流行动Act根据用户查询和上下文生成初始响应如一段代码、一个答案。反思Reflect将初始响应和原始问题一起提交给LLM进行反思。提示词可能是“请批判性地审查以下回答指出任何事实错误、逻辑漏洞、不完整之处或可以改进的地方。”修正Refine根据反思步骤生成的反馈重新生成或修改初始响应。循环判断可以设定固定循环次数如3次或设定一个评估标准如“反思者认为无需修改”时停止。实战场景与心得代码生成与调试这是反射模式的“杀手级”应用。让Agent生成一段代码后立即让另一个“代码审查Agent”检查语法错误、逻辑bug、安全漏洞和性能问题然后让生成Agent根据审查意见修改。实测下来这种模式生成的代码质量远高于单次生成。内容审核与安全对齐让Agent生成营销文案或邮件后用一个经过安全训练的“审核Agent”检查其中是否包含不当言论、敏感信息或偏见确保输出符合规范。复杂问题解答对于需要深度推理的问题如数学证明、策略分析让Agent先给出一个答案再让其解释自己的推理过程并自我质疑往往能发现隐藏的假设错误。注意反射模式会增加延迟和Token消耗多次调用LLM。在实际应用中需权衡质量与成本/速度。一个技巧是对于简单、明确的任务可以跳过反射对于复杂、关键或容易出错的任務则必须启用。另外设计一个好的“反思提示词”至关重要它需要明确、具体地指出需要评估的维度。2.2 工具使用模式让智能体拥有“手脚”如果大模型是智能体的“大脑”那么工具就是它的“手脚”和“感官”。工具使用模式的核心是让智能体能够感知到外部工具的存在并根据需要调用它们来获取信息或执行动作。LLM本身的知识是静态的、可能过时的且无法直接操作现实世界。工具使用模式通过函数调用Function Calling或类似的机制将LLM与一个工具库如搜索引擎、数据库API、计算器、邮件发送服务、业务系统接口连接起来。技术实现关键点工具描述每个工具都需要一个清晰的、结构化的描述通常包括工具名称、功能描述、所需参数名称、类型、描述和返回值的说明。这些描述会被格式化如JSON Schema并放入给LLM的提示词中告诉模型“你有什么工具可以用”。意图识别与参数提取LLM分析用户请求判断是否需要调用工具、调用哪个工具并从自然语言中提取出符合工具参数要求的结构化数据。工具执行与结果整合系统执行工具调用如调用一个API将返回的结果可能是结构化数据或文本重新整合到对话上下文中LLM再根据这个新信息生成面向用户的最终回答。实战场景与心得实时信息查询集成搜索引擎或天气API回答“今天纽约天气如何”或“苹果公司最新股价是多少”。数据操作与可视化连接数据库让用户用自然语言查询数据“给我看看上个月销售额最高的三个产品”并调用图表生成工具展示结果。自动化工作流连接企业内部系统实现“帮我给项目组所有人发一封会议邀请邮件时间定在下周一上午10点”这样的复杂操作。专业计算集成计算器、单位换算、货币转换等工具确保数值计算的绝对准确弥补LLM不擅长精确计算的短板。踩坑记录工具描述的质量直接决定调用成功率。描述必须精确、无歧义。例如一个“查询用户信息”的工具如果参数只描述为“用户标识”模型可能无法理解该传入用户ID、姓名还是邮箱。应改为“用户ID字符串类型唯一的用户标识符”。另外工具不宜过多过多的工具选项会增加模型的认知负荷和出错概率。建议根据智能体的核心功能域精心设计最小必要工具集。2.3 ReAct模式思维链与行动链的结合ReAct模式是当前最流行、最强大的单智能体范式之一它巧妙地将推理Reasoning和行动Acting交织在一个循环中。其核心公式是Thought - Act - Observation。智能体不是直接行动而是先通过“Thought”步骤进行内部推理明确“我接下来该做什么以及为什么”然后再执行具体的行动如调用工具最后观察行动结果并基于此进行下一轮思考。与工具使用模式的区别工具使用模式中LLM直接决定调用哪个工具并提取参数。而在ReAct中LLM会先输出一段自然语言的理由Thought然后再输出一个结构化的动作Act。这个“理由”是透明的、可解释的极大地提升了调试性和可控性。标准ReAct循环示例用户“珠穆朗玛峰的高度是多少米它比富士山高多少”智能体Thought“用户问了两个问题。首先我需要知道珠穆朗玛峰的确切高度。我可以使用搜索工具来获取这个信息。”智能体ActSearchTool(query“珠穆朗玛峰海拔高度 米”)系统Observation搜索结果显示珠穆朗玛峰海拔高度为8848.86米。智能体Thought“好的我得到了第一个答案。现在需要知道富士山的高度才能计算差值。再次使用搜索工具。”智能体ActSearchTool(query“富士山海拔高度 米”)系统Observation搜索结果显示富士山海拔高度为3776米。智能体Thought“现在我有两个数据8848.86米和3776米。计算差值8848.86 - 3776 5072.86米。现在我可以组织最终答案了。”智能体Final Answer“珠穆朗玛峰的高度约为8848.86米。它比富士山高约3776米高出大约5072.86米。”实战场景与心得复杂多步问题求解任何需要多个信息查询、计算、判断步骤的任务如旅行规划、故障排查、研究分析等ReAct都是首选。可解释性要求高的场景在医疗、金融、法律等领域智能体的决策过程需要被审计和解释。ReAct的“Thought”记录提供了完整的推理轨迹。调试与优化当智能体行为出错时开发者可以查看每一步的“Thought”精准定位是推理逻辑错误还是工具返回信息有误或是参数提取不准从而有针对性地优化提示词或工具。核心技巧设计一个清晰的“行动空间”描述至关重要。在系统提示词中必须明确告诉模型它可以采取哪些类型的“Act”如SearchCalculateLookup以及每种Act的格式。同时要鼓励模型在Thought中进行充分的、逐步的推理避免跳跃。在实践中我常发现给Thought步骤一些示例Few-shot Learning能显著提升其推理质量。2.4 规划模式从全局出发的“战略家”当任务非常复杂、步骤繁多且存在依赖关系时让智能体“走一步看一步”如ReAct可能效率低下容易陷入局部最优或循环。规划模式的核心是让智能体在行动之前先制定一个全局性的计划或任务分解树。它体现了“谋定而后动”的思想。规划通常分为两层高层规划High-level Planning将宏观目标分解为一系列有序的子目标或任务。例如目标“组织一场线上技术大会”可分解为“确定主题与议程”、“邀请演讲者”、“宣传推广”、“管理注册”、“进行直播”、“收集反馈”等子任务。低层规划/执行Low-level Planning / Execution对每个子任务进一步规划或直接执行具体步骤。例如“邀请演讲者”子任务可能进一步分解为“拟定邀请名单”、“撰写邀请邮件”、“发送邮件并跟进”。实现方式LLM直接规划给LLM一个任务描述要求它直接输出一个步骤列表或任务树。这种方式简单但对复杂任务可能规划不周全。基于工作流引擎将常见的任务模板抽象成可视化的工作流智能体负责触发和协调工作流的执行。这更稳定但灵活性较低。规划-执行-监控循环这是更高级的模式。智能体制定初始计划然后执行同时监控执行状态如子任务完成情况、外部环境变化并动态调整计划。实战场景与心得项目管理与自动化自动生成项目计划、分配任务、跟踪进度。例如根据“开发一个登录功能”的需求自动创建“UI设计”、“后端API开发”、“前端集成”、“测试用例编写”等任务卡。复杂内容创作撰写一篇深度报告、制作一个视频脚本。智能体先规划大纲章节、要点再为每个部分生成或收集内容。游戏与模拟在游戏环境中智能体需要规划长期策略如资源采集、科技研发、军队部署而不仅仅是下一步动作。注意事项规划模式对LLM的全局理解和逻辑能力要求很高。规划结果可能不切实际或存在逻辑漏洞。一个有效的缓解策略是“规划-评审”循环让一个LLM制定计划让另一个LLM或同一LLM换角色评审计划的可行性和完整性。此外规划不宜过细应保持一定的抽象度给执行阶段的ReAct或工具调用留出灵活应对的空间。2.5 多智能体协作模式构建“团队”与“社会”这是最复杂、也最接近人类协作的范式。其核心是创建多个具备不同角色、能力和目标的智能体让它们通过通信、协商、竞争或合作的方式共同完成一个任务。每个智能体可以专注于自己擅长的领域通过互动产生“112”的群体智能。常见的协作架构主从架构Manager-Worker一个“管理者”智能体负责接收用户指令、分解任务、将子任务分配给不同的“工作者”智能体如代码专家、文案专家、数据分析专家并汇总结果。这类似于一个项目经理带领一个专业团队。平等协作架构多个智能体角色平等通过对话协商来推进任务。例如一个“辩手”智能体和一个“评委”智能体就一个议题进行辩论最终产出深度分析报告。市场或竞拍架构智能体之间通过发布任务、竞价、承接的方式来分配资源和工作模拟了一个微型经济系统。技术挑战与实现要点角色定义为每个智能体设计清晰、差异化的系统提示词定义其角色、职责、专业领域和沟通风格。通信协议设计智能体之间如何交换信息。可以是一个共享的“黑板”系统可以是消息队列也可以是直接的对话轮转。消息格式需要结构化以便于解析和处理。协调机制如何解决冲突如何达成共识如何确保任务不遗漏这需要设计规则例如管理者有最终决定权或者引入投票机制。成本与效率多个智能体意味着多次LLM调用成本高昂。需要精心设计交互流程避免不必要的“空谈”。实战场景与心得复杂产品设计与评审组建包含“产品经理”、“UI设计师”、“开发工程师”、“测试工程师”的虚拟团队对一个需求进行多角度分析和方案设计。模拟会议与头脑风暴围绕一个主题让多个代表不同观点的智能体进行讨论激发创意收集全面意见。游戏与社交模拟构建具有不同性格和目标的虚拟角色观察它们在特定规则下的社会性互动。软件开发生命周期让“需求分析Agent”、“编码Agent”、“测试Agent”、“文档Agent”接力工作完成从需求到上线的部分流程。深度建议启动多智能体项目时切忌一开始就追求大而全的“团队”。我的经验是从两个智能体的简单协作开始。例如先做一个“作家”和“编辑”的协作验证通信链路和角色定义是否有效。稳定后再逐步增加角色或复杂度。另外必须为整个多智能体系统设置一个“超时”和“熔断”机制防止智能体陷入无休止的争论或循环。3. 模式组合与选型策略如何为你的项目挑选“组合拳”在实际项目中几乎不会单独使用某一种模式而是需要根据任务特性将多种模式组合起来形成更强大的解决方案。理解模式之间的关系和组合方式是进阶的关键。3.1 经典组合模式剖析ReAct 工具使用这是最基础、最强大的组合。ReAct提供了推理框架而工具使用则是其“Act”步骤的具体实现。几乎所有的实用型智能体都建立在这个组合之上。规划 ReAct对于宏大任务先用“规划模式”分解出任务树然后对每个叶子节点任务使用“ReAct模式”去具体执行。这实现了战略与战术的结合。反射 任何模式这是一个“质量增强器”。你可以在ReAct的每一步之后加入反射检查这一步做得对不对也可以在最终输出前加入反射检查整个答案的质量还可以在多智能体协作中让一个智能体专门负责反射和评审其他智能体的输出。多智能体 所有基础模式在多智能体系统中每个个体智能体内部可能都在使用ReAct、工具或规划模式。例如一个“数据分析师Agent”内部可能用ReAct模式调用SQL查询工具和图表生成工具。3.2 根据任务复杂度选型一张决策地图为了更直观地指导选型我们可以根据任务的确定性和复杂度两个维度来构建决策地图任务特性描述推荐模式实例简单、确定有明确指令单一步骤或简单查询无需额外信息。基础指令跟随翻译一句话、润色一段文本、分类简单内容。简单、需外部信息指令明确但需要查询实时数据或调用外部API。工具使用模式“今天天气如何”、“将‘Hello’翻译成法语”。复杂、需多步推理问题需要逻辑链条涉及多个信息获取和计算步骤。ReAct模式(核心)“珠峰比富士山高多少”、“帮我分析一下公司Q3财报的亮点和风险。”复杂、需先谋全局目标宏大由多个有依赖关系的子任务构成。规划模式 - ReAct“为我策划一次为期一周的日本关西旅行。”、“开发一个用户反馈分析系统。”输出质量要求极高涉及事实、安全、逻辑严谨性不容有失。Any模式 反射模式生成法律合同条款、医疗建议初稿、关键业务代码。超复杂、需多领域专家任务跨越多个专业领域需要不同视角和技能组合。多智能体协作模式(内含其他模式)“设计并推广一款新的智能手表。”、“为一个社会议题撰写包含正反方观点的深度报告。”选型心法从简单开始逐步叠加不要一开始就设计一个包含规划、多智能体、反射的庞大系统。先用最简单的模式如工具使用跑通核心功能再根据遇到的痛点引入更复杂的模式。例如发现工具调用经常出错就加入反射来校验参数和结果发现任务步骤混乱就引入规划来梳理。成本与效益的权衡每增加一层模式尤其是反射和多智能体都会显著增加API调用次数、延迟和费用。务必评估该模式带来的质量或能力提升是否值得付出的额外成本。对于内部工具可能更看重效率对于面向客户的产品则更看重可靠性。可观测性是生命线无论采用哪种模式尤其是组合模式必须建立完善的日志系统。完整记录每个LLM的输入输出、每个工具的调用请求与响应、每个智能体的内部状态Thought。这是调试、优化和成本分析的唯一依据。4. 实战架构与工具链搭建理解了模式下一步就是将其落地。这里以一个中等复杂度的“智能研究助手”为例演示如何组合模式并选择工具链进行搭建。该助手的目标是用户输入一个复杂问题如“对比一下TensorFlow和PyTorch在深度学习项目中的优缺点”它能自动进行网络搜索、阅读分析、整理信息并生成一份结构化的报告。4.1 系统架构设计我们将采用“规划 - ReAct含工具使用- 反射”的组合模式。规划阶段用户提问后首先由一个“规划器”智能体分析问题制定研究大纲。例如子任务1搜索并总结TensorFlow的核心特性、优点和缺点。子任务2搜索并总结PyTorch的核心特性、优点和缺点。子任务3从性能、易用性、社区、生产部署等维度进行对比。子任务4根据用户可能的身份研究者、学生、工程师给出选型建议。子任务5整合以上信息生成格式优美的最终报告。执行阶段对于每个子任务如子任务1启用一个“研究者”智能体该智能体内部采用ReAct模式并配备搜索工具和网页内容提取工具。Thought: “我需要查找TensorFlow的官方文档和权威技术文章来总结其优缺点。”Act:SearchTool(query“TensorFlow 优点 缺点 核心特性 2024”)Observation: (返回一系列链接和摘要)Thought: “第一个结果看起来是官方博客比较权威。我需要点进去获取详细信息。”Act:BrowseTool(url“https://blog.tensorflow.org/...”)ExtractMainContentTool()Observation: (获取到网页正文内容)Thought: “内容很多我需要提取关键点1. 优点生产部署成熟、跨平台支持好... 2. 缺点静态图模式调试困难...”Act:SummarizeTool(text“获取的正文内容” focus“优点和缺点”)Observation: (得到一份简洁的总结)Final Answer for Subtask 1: (将总结结构化输出)汇总与反射阶段所有子任务完成后由一个“合成器”智能体汇总各部分的发现按照规划的大纲组织成初稿报告。然后由一个“评审员”智能体反射模式对初稿进行审查检查事实准确性是否与来源矛盾、逻辑连贯性、是否遗漏重要对比维度、语言是否通顺。评审员提供修改意见合成器进行修改可能迭代1-2轮。4.2 工具链与框架选择目前市面上已有许多优秀的框架可以降低实现上述架构的复杂度它们抽象了智能体运行、工具调用、记忆管理等底层细节。框架/工具类型核心特点适用场景LangChain / LangGraph开发框架生态最成熟组件丰富链、代理、工具、记忆LangGraph特别适合构建有状态的、循环的智能体工作流。灵活性极高但需要较多代码。需要高度定制化、复杂流程控制的智能体应用。适合有开发经验的团队。LlamaIndex开发框架专精于数据连接与检索RAG。可以轻松将外部数据源文档、数据库、API作为智能体的知识库。常与LangChain结合使用。智能体的核心能力需要建立在私有或领域知识库之上的场景。AutoGen (by Microsoft)多智能体框架为多智能体对话协作而设计内置了多种可配置的智能体类型如AssistantAgent,UserProxyAgent简化了多智能体通信。快速搭建多智能体对话、协作、仿真系统。Dify, Coze 等平台低代码/无代码平台提供可视化的工作流编排界面内置常用工具和模型可以快速搭建和部署智能体应用无需或只需少量代码。产品、运营等非技术角色快速构建原型或简单应用中小企业快速落地AI功能。Semantic Kernel (by Microsoft)开发框架强调“规划”能力内置规划器Planner组件可以将自然语言目标自动分解为可执行的步骤调用插件/函数。任务目标明确、希望由AI自动规划步骤的场景。选型建议如果你是研究者或追求极致灵活性的开发者LangChain LangGraph是你的不二之选它让你能控制每一个细节。如果你的应用严重依赖私有数据问答LlamaIndex作为数据层结合LangChain的智能体层是黄金组合。如果你想快速验证一个多智能体协作的想法AutoGen能让你在几分钟内启动一个多角色对话系统。如果你的目标是让业务人员也能参与构建AI工作流Dify/Coze这类可视化平台能极大降低门槛。对于我们的“研究助手”示例可以选择LangGraph来编排“规划-执行-汇总”的流程用LlamaIndex来管理搜索和浏览工具获取的临时知识并在关键节点插入自定义的反射步骤。4.3 核心代码结构示意基于LangGraph这里以LangGraph为例勾勒出“研究助手”核心执行环节子任务ReAct的简化代码逻辑让你感受一下如何将模式转化为实际代码。import json from typing import TypedDict, List, Annotated from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI from langchain_community.tools import DuckDuckGoSearchResults, BraveSearch # 示例搜索工具 from langchain_core.messages import HumanMessage, AIMessage, ToolMessage # 1. 定义智能体的状态结构 class AgentState(TypedDict): messages: Annotated[List, 对话消息历史] subtask: str # 当前执行的子任务描述 collected_info: str # 收集到的信息 max_turns: int 5 # 最大ReAct循环轮次 # 2. 定义工具 search_tool DuckDuckGoSearchResults(num_results3) llm ChatOpenAI(modelgpt-4-turbo) # 3. 定义关键节点函数 def plan_step(state: AgentState): 规划步骤分析子任务决定第一步做什么。 planner_prompt f 你是一个研究助手。当前需要完成的子任务是{state[subtask]}。 请思考并规划你的第一步行动。你可以选择 1. 使用搜索工具search来查找相关信息。 2. 如果你认为已有足够信息collected_info则直接给出最终答案final_answer。 请以JSON格式回复包含两个字段thought你的思考过程和 actionsearch 或 final_answer。 如果选择search请同时提供 query搜索关键词。 messages state[messages] [HumanMessage(contentplanner_prompt)] response llm.invoke(messages) # 解析响应更新状态... return {messages: state[messages] [response]} def act_step(state: AgentState): 行动步骤执行工具调用。 last_msg state[messages][-1] # 解析出上一步决定要调用的工具和参数 action_decision parse_action(last_msg.content) # 假设有解析函数 if action_decision[action] search: results search_tool.invoke({query: action_decision[query]}) # 将工具执行结果封装为ToolMessage tool_message ToolMessage(contentjson.dumps(results), tool_call_id...) return {messages: state[messages] [tool_message]} # ... 处理其他action def reflect_step(state: AgentState): 反射步骤评估收集到的信息是否足够回答子任务。 reflection_prompt f 子任务{state[subtask]} 目前已收集的信息{state[collected_info]} 请评估这些信息是否足够全面、准确地回答子任务如果不够还缺少什么 请以JSON格式回复is_sufficienttrue/false, missing_parts缺失部分描述如果足够则为空。 # 调用LLM进行评估... # 根据评估结果决定是继续循环还是结束 if is_sufficient: return {decision: finalize} else: return {decision: continue, next_query: 根据缺失部分生成的新搜索词} # 4. 构建图Graph workflow StateGraph(AgentState) workflow.add_node(plan, plan_step) workflow.add_node(act, act_step) workflow.add_node(reflect, reflect_step) workflow.add_node(finalize, lambda state: {result: state[collected_info]}) # 定义边控制流 workflow.set_entry_point(plan) workflow.add_conditional_edges( plan, # 根据plan_step的输出决定下一步是act还是finalize lambda x: act if x[action] search else finalize ) workflow.add_edge(act, reflect) workflow.add_conditional_edges( reflect, lambda x: plan if x[decision] continue else finalize, {plan: plan, finalize: finalize} ) workflow.add_edge(finalize, END) # 编译并运行图 app workflow.compile() initial_state AgentState(messages[], subtask搜索并总结TensorFlow的优缺点, collected_info) final_state app.invoke(initial_state, config{recursion_limit: 10})这段代码勾勒了一个简化的、单子任务的ReAct循环图。在实际项目中你还需要包装更复杂的工具、处理更精细的状态管理、并集成规划器和多智能体通信层。5. 避坑指南与性能优化在真实开发中除了模式选择还有大量工程细节决定成败。以下是我从多个项目中总结出的核心经验。5.1 提示词工程智能体的“灵魂”塑造系统提示词是智能体的“人格”和“行为准则”。写得好事半功倍写得差事倍功半。角色扮演法明确赋予智能体一个具体角色。“你是一个资深的机器学习工程师”远比“你是一个有帮助的AI”更有效。指令清晰具体避免模糊指令。不要说“好好总结”而要说“请用不超过3个要点总结该文章的核心论点每个要点不超过20字”。格式化输出要求明确要求输出格式如JSON、Markdown列表、特定模板。这极大方便了后续的程序化处理。例如“请以JSON格式回复包含summary和confidence两个字段。”提供示例Few-shot对于复杂或易错的任务在提示词中提供1-2个输入输出示例能显著提升模型表现。设定约束与边界明确什么不能做。例如“你只能使用我提供的工具不能编造工具。”“如果信息不足请明确说明‘根据现有信息无法回答’而不要猜测。”5.2 稳定性与可靠性保障智能体运行在非确定性的LLM之上必须为“失控”做好准备。超时与重试机制为每个LLM调用和工具调用设置超时。对于非致命错误如网络波动实施指数退避重试。循环检测与中断ReAct或反射循环可能陷入死循环。必须设置最大迭代次数如10次并在状态中检测重复或无效操作及时跳出。输入输出验证与清洗对用户输入进行基本的敏感词过滤和长度限制。对LLM的输出进行解析验证确保其符合预期的格式如JSON并处理解析失败的情况。后备方案Fallback当智能体多次尝试失败后应有降级策略。例如转接给人工客服、返回一个保守的默认答案、或者引导用户简化问题。5.3 成本控制与性能优化智能体应用的成本可能快速膨胀优化至关重要。缓存层对频繁出现的、结果不变的查询如“什么是机器学习”和工具调用结果如天气API数据短期内不变进行缓存。可以使用Redis或简单的内存缓存。上下文管理LLM的Token费用与上下文长度成正比。定期清理历史消息中不重要的部分只保留关键的任务指令、工具定义和最近的对话。使用“摘要”技术将长段对话历史压缩成一段摘要再放入上下文。模型分级调用并非所有步骤都需要最强大、最贵的模型如GPT-4。可以用小模型如GPT-3.5-Turbo处理简单的分类、格式化任务用大模型处理核心推理和创作任务。异步与流式处理对于耗时长的任务如多个子任务并行采用异步处理不要让用户同步等待。对于生成式输出使用流式响应Streaming提升用户体验。5.4 评估与迭代没有度量就没有改进如何判断你的智能体是否在变好需要建立评估体系。单元测试为智能体的核心功能如工具调用解析、特定问题回答编写测试用例确保代码更改不会破坏现有功能。端到端评估构建一个包含各种典型问题和边缘案例的测试集。定期运行跟踪关键指标任务完成率智能体能独立正确完成的任务比例。工具调用准确率在需要调用工具时是否正确选择了工具并提取了参数。平均对话轮次Turns完成一个任务平均需要多少次LLM交互。优化目标是降低这个数字。人工评分定期抽样让真人从准确性、有用性、流畅性等维度评分。A/B测试当对提示词或流程做出重大修改时进行A/B测试用数据说话选择效果更好的版本。智能体开发是一场结合了软件工程、提示词艺术和产品思维的旅程。这五种模式为你提供了强大的思维框架和设计工具但真正的 mastery 来自于不断的实践、踩坑和迭代。从一个具体而微的小任务开始选择一种模式将其实现然后观察、分析、优化再逐步引入更复杂的模式。在这个过程中你会逐渐培养出对智能体行为的直觉最终能够游刃有余地设计出稳健、高效、真正解决实际问题的智能体系统。记住最好的智能体不是最复杂的那个而是最能可靠解决用户问题的那个。 智能体开发五大核心模式：从ReAct到多智能体协作的工程实践指南
1. 项目概述从“玩具”到“生产力”的智能体进化之路最近和几个做AI应用开发的朋友聊天发现一个挺有意思的现象大家一提到“智能体”Agent第一反应往往是那些能聊天的对话机器人或者网上流传的、能自动点点点的“脚本小子”Demo。但当我们真正想把手头那个繁琐的报表自动化流程、或者那个需要跨多个系统查询信息的客服助手给做出来时却常常卡在第一步——不知道从何下手感觉Demo和实际可用的产品之间隔着一道鸿沟。这其实反映了一个核心问题我们可能接触了不少Agent的概念但对其背后系统性的工程模式缺乏理解。没有模式就像盖房子没有图纸代码容易变成一坨纠缠不清的“面条”难以维护、扩展和调试。“吃透这5种Agent模式搞定智能体开发”这个标题瞄准的正是这个痛点。它不是一个简单的API调用教程而是一份关于如何结构化地思考和组织智能体行为的实战指南。这五种模式——反射Reflection、工具使用Tool Use、规划Planning、多智能体协作Multi-Agent Collaboration以及ReActReasoning and Acting——构成了现代智能体开发中最核心、最经得起考验的架构范式。掌握它们意味着你拿到了一套从简单到复杂、应对不同场景的“设计模式”工具箱。无论是想做一个能自我纠错的代码助手还是一个能协调多个专家完成复杂任务的项目经理Agent你都能找到对应的模式来搭建骨架从而把大模型的能力稳定、可靠地嵌入到真实的业务流程中。2. 核心模式深度解析五种武器与实战场景智能体开发不是魔法其可靠性建立在清晰的架构之上。下面这五种模式每一种都解决了一类特定的问题并有其最适合的应用场景。理解它们的本质差异是做出正确技术选型的第一步。2.1 反射模式赋予智能体“三思而后行”的能力反射模式的核心思想是引入一个自我评估与修正的循环。一个基础的智能体接收到输入、调用模型、产生输出这个过程是单向的。而反射模式在这个链条中增加了一个“批判者”角色。智能体首先生成一个初始响应或行动计划然后这个响应会被提交给同一个或另一个LLM进行批判性审查审查者会评估其准确性、完整性、安全性或与目标的契合度。如果发现问题审查者会生成反馈智能体再根据反馈进行修正如此循环直到输出满足预设标准。为什么需要反射大模型本质上是概率模型存在“幻觉”编造信息、逻辑错误或偏离指令的风险。单次生成如同“一锤子买卖”质量不可控。反射模式通过多次生成-评估的迭代显著提升了输出的可靠性和质量。它模拟了人类“写完后检查一遍”的思考过程。典型工作流行动Act根据用户查询和上下文生成初始响应如一段代码、一个答案。反思Reflect将初始响应和原始问题一起提交给LLM进行反思。提示词可能是“请批判性地审查以下回答指出任何事实错误、逻辑漏洞、不完整之处或可以改进的地方。”修正Refine根据反思步骤生成的反馈重新生成或修改初始响应。循环判断可以设定固定循环次数如3次或设定一个评估标准如“反思者认为无需修改”时停止。实战场景与心得代码生成与调试这是反射模式的“杀手级”应用。让Agent生成一段代码后立即让另一个“代码审查Agent”检查语法错误、逻辑bug、安全漏洞和性能问题然后让生成Agent根据审查意见修改。实测下来这种模式生成的代码质量远高于单次生成。内容审核与安全对齐让Agent生成营销文案或邮件后用一个经过安全训练的“审核Agent”检查其中是否包含不当言论、敏感信息或偏见确保输出符合规范。复杂问题解答对于需要深度推理的问题如数学证明、策略分析让Agent先给出一个答案再让其解释自己的推理过程并自我质疑往往能发现隐藏的假设错误。注意反射模式会增加延迟和Token消耗多次调用LLM。在实际应用中需权衡质量与成本/速度。一个技巧是对于简单、明确的任务可以跳过反射对于复杂、关键或容易出错的任務则必须启用。另外设计一个好的“反思提示词”至关重要它需要明确、具体地指出需要评估的维度。2.2 工具使用模式让智能体拥有“手脚”如果大模型是智能体的“大脑”那么工具就是它的“手脚”和“感官”。工具使用模式的核心是让智能体能够感知到外部工具的存在并根据需要调用它们来获取信息或执行动作。LLM本身的知识是静态的、可能过时的且无法直接操作现实世界。工具使用模式通过函数调用Function Calling或类似的机制将LLM与一个工具库如搜索引擎、数据库API、计算器、邮件发送服务、业务系统接口连接起来。技术实现关键点工具描述每个工具都需要一个清晰的、结构化的描述通常包括工具名称、功能描述、所需参数名称、类型、描述和返回值的说明。这些描述会被格式化如JSON Schema并放入给LLM的提示词中告诉模型“你有什么工具可以用”。意图识别与参数提取LLM分析用户请求判断是否需要调用工具、调用哪个工具并从自然语言中提取出符合工具参数要求的结构化数据。工具执行与结果整合系统执行工具调用如调用一个API将返回的结果可能是结构化数据或文本重新整合到对话上下文中LLM再根据这个新信息生成面向用户的最终回答。实战场景与心得实时信息查询集成搜索引擎或天气API回答“今天纽约天气如何”或“苹果公司最新股价是多少”。数据操作与可视化连接数据库让用户用自然语言查询数据“给我看看上个月销售额最高的三个产品”并调用图表生成工具展示结果。自动化工作流连接企业内部系统实现“帮我给项目组所有人发一封会议邀请邮件时间定在下周一上午10点”这样的复杂操作。专业计算集成计算器、单位换算、货币转换等工具确保数值计算的绝对准确弥补LLM不擅长精确计算的短板。踩坑记录工具描述的质量直接决定调用成功率。描述必须精确、无歧义。例如一个“查询用户信息”的工具如果参数只描述为“用户标识”模型可能无法理解该传入用户ID、姓名还是邮箱。应改为“用户ID字符串类型唯一的用户标识符”。另外工具不宜过多过多的工具选项会增加模型的认知负荷和出错概率。建议根据智能体的核心功能域精心设计最小必要工具集。2.3 ReAct模式思维链与行动链的结合ReAct模式是当前最流行、最强大的单智能体范式之一它巧妙地将推理Reasoning和行动Acting交织在一个循环中。其核心公式是Thought - Act - Observation。智能体不是直接行动而是先通过“Thought”步骤进行内部推理明确“我接下来该做什么以及为什么”然后再执行具体的行动如调用工具最后观察行动结果并基于此进行下一轮思考。与工具使用模式的区别工具使用模式中LLM直接决定调用哪个工具并提取参数。而在ReAct中LLM会先输出一段自然语言的理由Thought然后再输出一个结构化的动作Act。这个“理由”是透明的、可解释的极大地提升了调试性和可控性。标准ReAct循环示例用户“珠穆朗玛峰的高度是多少米它比富士山高多少”智能体Thought“用户问了两个问题。首先我需要知道珠穆朗玛峰的确切高度。我可以使用搜索工具来获取这个信息。”智能体ActSearchTool(query“珠穆朗玛峰海拔高度 米”)系统Observation搜索结果显示珠穆朗玛峰海拔高度为8848.86米。智能体Thought“好的我得到了第一个答案。现在需要知道富士山的高度才能计算差值。再次使用搜索工具。”智能体ActSearchTool(query“富士山海拔高度 米”)系统Observation搜索结果显示富士山海拔高度为3776米。智能体Thought“现在我有两个数据8848.86米和3776米。计算差值8848.86 - 3776 5072.86米。现在我可以组织最终答案了。”智能体Final Answer“珠穆朗玛峰的高度约为8848.86米。它比富士山高约3776米高出大约5072.86米。”实战场景与心得复杂多步问题求解任何需要多个信息查询、计算、判断步骤的任务如旅行规划、故障排查、研究分析等ReAct都是首选。可解释性要求高的场景在医疗、金融、法律等领域智能体的决策过程需要被审计和解释。ReAct的“Thought”记录提供了完整的推理轨迹。调试与优化当智能体行为出错时开发者可以查看每一步的“Thought”精准定位是推理逻辑错误还是工具返回信息有误或是参数提取不准从而有针对性地优化提示词或工具。核心技巧设计一个清晰的“行动空间”描述至关重要。在系统提示词中必须明确告诉模型它可以采取哪些类型的“Act”如SearchCalculateLookup以及每种Act的格式。同时要鼓励模型在Thought中进行充分的、逐步的推理避免跳跃。在实践中我常发现给Thought步骤一些示例Few-shot Learning能显著提升其推理质量。2.4 规划模式从全局出发的“战略家”当任务非常复杂、步骤繁多且存在依赖关系时让智能体“走一步看一步”如ReAct可能效率低下容易陷入局部最优或循环。规划模式的核心是让智能体在行动之前先制定一个全局性的计划或任务分解树。它体现了“谋定而后动”的思想。规划通常分为两层高层规划High-level Planning将宏观目标分解为一系列有序的子目标或任务。例如目标“组织一场线上技术大会”可分解为“确定主题与议程”、“邀请演讲者”、“宣传推广”、“管理注册”、“进行直播”、“收集反馈”等子任务。低层规划/执行Low-level Planning / Execution对每个子任务进一步规划或直接执行具体步骤。例如“邀请演讲者”子任务可能进一步分解为“拟定邀请名单”、“撰写邀请邮件”、“发送邮件并跟进”。实现方式LLM直接规划给LLM一个任务描述要求它直接输出一个步骤列表或任务树。这种方式简单但对复杂任务可能规划不周全。基于工作流引擎将常见的任务模板抽象成可视化的工作流智能体负责触发和协调工作流的执行。这更稳定但灵活性较低。规划-执行-监控循环这是更高级的模式。智能体制定初始计划然后执行同时监控执行状态如子任务完成情况、外部环境变化并动态调整计划。实战场景与心得项目管理与自动化自动生成项目计划、分配任务、跟踪进度。例如根据“开发一个登录功能”的需求自动创建“UI设计”、“后端API开发”、“前端集成”、“测试用例编写”等任务卡。复杂内容创作撰写一篇深度报告、制作一个视频脚本。智能体先规划大纲章节、要点再为每个部分生成或收集内容。游戏与模拟在游戏环境中智能体需要规划长期策略如资源采集、科技研发、军队部署而不仅仅是下一步动作。注意事项规划模式对LLM的全局理解和逻辑能力要求很高。规划结果可能不切实际或存在逻辑漏洞。一个有效的缓解策略是“规划-评审”循环让一个LLM制定计划让另一个LLM或同一LLM换角色评审计划的可行性和完整性。此外规划不宜过细应保持一定的抽象度给执行阶段的ReAct或工具调用留出灵活应对的空间。2.5 多智能体协作模式构建“团队”与“社会”这是最复杂、也最接近人类协作的范式。其核心是创建多个具备不同角色、能力和目标的智能体让它们通过通信、协商、竞争或合作的方式共同完成一个任务。每个智能体可以专注于自己擅长的领域通过互动产生“112”的群体智能。常见的协作架构主从架构Manager-Worker一个“管理者”智能体负责接收用户指令、分解任务、将子任务分配给不同的“工作者”智能体如代码专家、文案专家、数据分析专家并汇总结果。这类似于一个项目经理带领一个专业团队。平等协作架构多个智能体角色平等通过对话协商来推进任务。例如一个“辩手”智能体和一个“评委”智能体就一个议题进行辩论最终产出深度分析报告。市场或竞拍架构智能体之间通过发布任务、竞价、承接的方式来分配资源和工作模拟了一个微型经济系统。技术挑战与实现要点角色定义为每个智能体设计清晰、差异化的系统提示词定义其角色、职责、专业领域和沟通风格。通信协议设计智能体之间如何交换信息。可以是一个共享的“黑板”系统可以是消息队列也可以是直接的对话轮转。消息格式需要结构化以便于解析和处理。协调机制如何解决冲突如何达成共识如何确保任务不遗漏这需要设计规则例如管理者有最终决定权或者引入投票机制。成本与效率多个智能体意味着多次LLM调用成本高昂。需要精心设计交互流程避免不必要的“空谈”。实战场景与心得复杂产品设计与评审组建包含“产品经理”、“UI设计师”、“开发工程师”、“测试工程师”的虚拟团队对一个需求进行多角度分析和方案设计。模拟会议与头脑风暴围绕一个主题让多个代表不同观点的智能体进行讨论激发创意收集全面意见。游戏与社交模拟构建具有不同性格和目标的虚拟角色观察它们在特定规则下的社会性互动。软件开发生命周期让“需求分析Agent”、“编码Agent”、“测试Agent”、“文档Agent”接力工作完成从需求到上线的部分流程。深度建议启动多智能体项目时切忌一开始就追求大而全的“团队”。我的经验是从两个智能体的简单协作开始。例如先做一个“作家”和“编辑”的协作验证通信链路和角色定义是否有效。稳定后再逐步增加角色或复杂度。另外必须为整个多智能体系统设置一个“超时”和“熔断”机制防止智能体陷入无休止的争论或循环。3. 模式组合与选型策略如何为你的项目挑选“组合拳”在实际项目中几乎不会单独使用某一种模式而是需要根据任务特性将多种模式组合起来形成更强大的解决方案。理解模式之间的关系和组合方式是进阶的关键。3.1 经典组合模式剖析ReAct 工具使用这是最基础、最强大的组合。ReAct提供了推理框架而工具使用则是其“Act”步骤的具体实现。几乎所有的实用型智能体都建立在这个组合之上。规划 ReAct对于宏大任务先用“规划模式”分解出任务树然后对每个叶子节点任务使用“ReAct模式”去具体执行。这实现了战略与战术的结合。反射 任何模式这是一个“质量增强器”。你可以在ReAct的每一步之后加入反射检查这一步做得对不对也可以在最终输出前加入反射检查整个答案的质量还可以在多智能体协作中让一个智能体专门负责反射和评审其他智能体的输出。多智能体 所有基础模式在多智能体系统中每个个体智能体内部可能都在使用ReAct、工具或规划模式。例如一个“数据分析师Agent”内部可能用ReAct模式调用SQL查询工具和图表生成工具。3.2 根据任务复杂度选型一张决策地图为了更直观地指导选型我们可以根据任务的确定性和复杂度两个维度来构建决策地图任务特性描述推荐模式实例简单、确定有明确指令单一步骤或简单查询无需额外信息。基础指令跟随翻译一句话、润色一段文本、分类简单内容。简单、需外部信息指令明确但需要查询实时数据或调用外部API。工具使用模式“今天天气如何”、“将‘Hello’翻译成法语”。复杂、需多步推理问题需要逻辑链条涉及多个信息获取和计算步骤。ReAct模式(核心)“珠峰比富士山高多少”、“帮我分析一下公司Q3财报的亮点和风险。”复杂、需先谋全局目标宏大由多个有依赖关系的子任务构成。规划模式 - ReAct“为我策划一次为期一周的日本关西旅行。”、“开发一个用户反馈分析系统。”输出质量要求极高涉及事实、安全、逻辑严谨性不容有失。Any模式 反射模式生成法律合同条款、医疗建议初稿、关键业务代码。超复杂、需多领域专家任务跨越多个专业领域需要不同视角和技能组合。多智能体协作模式(内含其他模式)“设计并推广一款新的智能手表。”、“为一个社会议题撰写包含正反方观点的深度报告。”选型心法从简单开始逐步叠加不要一开始就设计一个包含规划、多智能体、反射的庞大系统。先用最简单的模式如工具使用跑通核心功能再根据遇到的痛点引入更复杂的模式。例如发现工具调用经常出错就加入反射来校验参数和结果发现任务步骤混乱就引入规划来梳理。成本与效益的权衡每增加一层模式尤其是反射和多智能体都会显著增加API调用次数、延迟和费用。务必评估该模式带来的质量或能力提升是否值得付出的额外成本。对于内部工具可能更看重效率对于面向客户的产品则更看重可靠性。可观测性是生命线无论采用哪种模式尤其是组合模式必须建立完善的日志系统。完整记录每个LLM的输入输出、每个工具的调用请求与响应、每个智能体的内部状态Thought。这是调试、优化和成本分析的唯一依据。4. 实战架构与工具链搭建理解了模式下一步就是将其落地。这里以一个中等复杂度的“智能研究助手”为例演示如何组合模式并选择工具链进行搭建。该助手的目标是用户输入一个复杂问题如“对比一下TensorFlow和PyTorch在深度学习项目中的优缺点”它能自动进行网络搜索、阅读分析、整理信息并生成一份结构化的报告。4.1 系统架构设计我们将采用“规划 - ReAct含工具使用- 反射”的组合模式。规划阶段用户提问后首先由一个“规划器”智能体分析问题制定研究大纲。例如子任务1搜索并总结TensorFlow的核心特性、优点和缺点。子任务2搜索并总结PyTorch的核心特性、优点和缺点。子任务3从性能、易用性、社区、生产部署等维度进行对比。子任务4根据用户可能的身份研究者、学生、工程师给出选型建议。子任务5整合以上信息生成格式优美的最终报告。执行阶段对于每个子任务如子任务1启用一个“研究者”智能体该智能体内部采用ReAct模式并配备搜索工具和网页内容提取工具。Thought: “我需要查找TensorFlow的官方文档和权威技术文章来总结其优缺点。”Act:SearchTool(query“TensorFlow 优点 缺点 核心特性 2024”)Observation: (返回一系列链接和摘要)Thought: “第一个结果看起来是官方博客比较权威。我需要点进去获取详细信息。”Act:BrowseTool(url“https://blog.tensorflow.org/...”)ExtractMainContentTool()Observation: (获取到网页正文内容)Thought: “内容很多我需要提取关键点1. 优点生产部署成熟、跨平台支持好... 2. 缺点静态图模式调试困难...”Act:SummarizeTool(text“获取的正文内容” focus“优点和缺点”)Observation: (得到一份简洁的总结)Final Answer for Subtask 1: (将总结结构化输出)汇总与反射阶段所有子任务完成后由一个“合成器”智能体汇总各部分的发现按照规划的大纲组织成初稿报告。然后由一个“评审员”智能体反射模式对初稿进行审查检查事实准确性是否与来源矛盾、逻辑连贯性、是否遗漏重要对比维度、语言是否通顺。评审员提供修改意见合成器进行修改可能迭代1-2轮。4.2 工具链与框架选择目前市面上已有许多优秀的框架可以降低实现上述架构的复杂度它们抽象了智能体运行、工具调用、记忆管理等底层细节。框架/工具类型核心特点适用场景LangChain / LangGraph开发框架生态最成熟组件丰富链、代理、工具、记忆LangGraph特别适合构建有状态的、循环的智能体工作流。灵活性极高但需要较多代码。需要高度定制化、复杂流程控制的智能体应用。适合有开发经验的团队。LlamaIndex开发框架专精于数据连接与检索RAG。可以轻松将外部数据源文档、数据库、API作为智能体的知识库。常与LangChain结合使用。智能体的核心能力需要建立在私有或领域知识库之上的场景。AutoGen (by Microsoft)多智能体框架为多智能体对话协作而设计内置了多种可配置的智能体类型如AssistantAgent,UserProxyAgent简化了多智能体通信。快速搭建多智能体对话、协作、仿真系统。Dify, Coze 等平台低代码/无代码平台提供可视化的工作流编排界面内置常用工具和模型可以快速搭建和部署智能体应用无需或只需少量代码。产品、运营等非技术角色快速构建原型或简单应用中小企业快速落地AI功能。Semantic Kernel (by Microsoft)开发框架强调“规划”能力内置规划器Planner组件可以将自然语言目标自动分解为可执行的步骤调用插件/函数。任务目标明确、希望由AI自动规划步骤的场景。选型建议如果你是研究者或追求极致灵活性的开发者LangChain LangGraph是你的不二之选它让你能控制每一个细节。如果你的应用严重依赖私有数据问答LlamaIndex作为数据层结合LangChain的智能体层是黄金组合。如果你想快速验证一个多智能体协作的想法AutoGen能让你在几分钟内启动一个多角色对话系统。如果你的目标是让业务人员也能参与构建AI工作流Dify/Coze这类可视化平台能极大降低门槛。对于我们的“研究助手”示例可以选择LangGraph来编排“规划-执行-汇总”的流程用LlamaIndex来管理搜索和浏览工具获取的临时知识并在关键节点插入自定义的反射步骤。4.3 核心代码结构示意基于LangGraph这里以LangGraph为例勾勒出“研究助手”核心执行环节子任务ReAct的简化代码逻辑让你感受一下如何将模式转化为实际代码。import json from typing import TypedDict, List, Annotated from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI from langchain_community.tools import DuckDuckGoSearchResults, BraveSearch # 示例搜索工具 from langchain_core.messages import HumanMessage, AIMessage, ToolMessage # 1. 定义智能体的状态结构 class AgentState(TypedDict): messages: Annotated[List, 对话消息历史] subtask: str # 当前执行的子任务描述 collected_info: str # 收集到的信息 max_turns: int 5 # 最大ReAct循环轮次 # 2. 定义工具 search_tool DuckDuckGoSearchResults(num_results3) llm ChatOpenAI(modelgpt-4-turbo) # 3. 定义关键节点函数 def plan_step(state: AgentState): 规划步骤分析子任务决定第一步做什么。 planner_prompt f 你是一个研究助手。当前需要完成的子任务是{state[subtask]}。 请思考并规划你的第一步行动。你可以选择 1. 使用搜索工具search来查找相关信息。 2. 如果你认为已有足够信息collected_info则直接给出最终答案final_answer。 请以JSON格式回复包含两个字段thought你的思考过程和 actionsearch 或 final_answer。 如果选择search请同时提供 query搜索关键词。 messages state[messages] [HumanMessage(contentplanner_prompt)] response llm.invoke(messages) # 解析响应更新状态... return {messages: state[messages] [response]} def act_step(state: AgentState): 行动步骤执行工具调用。 last_msg state[messages][-1] # 解析出上一步决定要调用的工具和参数 action_decision parse_action(last_msg.content) # 假设有解析函数 if action_decision[action] search: results search_tool.invoke({query: action_decision[query]}) # 将工具执行结果封装为ToolMessage tool_message ToolMessage(contentjson.dumps(results), tool_call_id...) return {messages: state[messages] [tool_message]} # ... 处理其他action def reflect_step(state: AgentState): 反射步骤评估收集到的信息是否足够回答子任务。 reflection_prompt f 子任务{state[subtask]} 目前已收集的信息{state[collected_info]} 请评估这些信息是否足够全面、准确地回答子任务如果不够还缺少什么 请以JSON格式回复is_sufficienttrue/false, missing_parts缺失部分描述如果足够则为空。 # 调用LLM进行评估... # 根据评估结果决定是继续循环还是结束 if is_sufficient: return {decision: finalize} else: return {decision: continue, next_query: 根据缺失部分生成的新搜索词} # 4. 构建图Graph workflow StateGraph(AgentState) workflow.add_node(plan, plan_step) workflow.add_node(act, act_step) workflow.add_node(reflect, reflect_step) workflow.add_node(finalize, lambda state: {result: state[collected_info]}) # 定义边控制流 workflow.set_entry_point(plan) workflow.add_conditional_edges( plan, # 根据plan_step的输出决定下一步是act还是finalize lambda x: act if x[action] search else finalize ) workflow.add_edge(act, reflect) workflow.add_conditional_edges( reflect, lambda x: plan if x[decision] continue else finalize, {plan: plan, finalize: finalize} ) workflow.add_edge(finalize, END) # 编译并运行图 app workflow.compile() initial_state AgentState(messages[], subtask搜索并总结TensorFlow的优缺点, collected_info) final_state app.invoke(initial_state, config{recursion_limit: 10})这段代码勾勒了一个简化的、单子任务的ReAct循环图。在实际项目中你还需要包装更复杂的工具、处理更精细的状态管理、并集成规划器和多智能体通信层。5. 避坑指南与性能优化在真实开发中除了模式选择还有大量工程细节决定成败。以下是我从多个项目中总结出的核心经验。5.1 提示词工程智能体的“灵魂”塑造系统提示词是智能体的“人格”和“行为准则”。写得好事半功倍写得差事倍功半。角色扮演法明确赋予智能体一个具体角色。“你是一个资深的机器学习工程师”远比“你是一个有帮助的AI”更有效。指令清晰具体避免模糊指令。不要说“好好总结”而要说“请用不超过3个要点总结该文章的核心论点每个要点不超过20字”。格式化输出要求明确要求输出格式如JSON、Markdown列表、特定模板。这极大方便了后续的程序化处理。例如“请以JSON格式回复包含summary和confidence两个字段。”提供示例Few-shot对于复杂或易错的任务在提示词中提供1-2个输入输出示例能显著提升模型表现。设定约束与边界明确什么不能做。例如“你只能使用我提供的工具不能编造工具。”“如果信息不足请明确说明‘根据现有信息无法回答’而不要猜测。”5.2 稳定性与可靠性保障智能体运行在非确定性的LLM之上必须为“失控”做好准备。超时与重试机制为每个LLM调用和工具调用设置超时。对于非致命错误如网络波动实施指数退避重试。循环检测与中断ReAct或反射循环可能陷入死循环。必须设置最大迭代次数如10次并在状态中检测重复或无效操作及时跳出。输入输出验证与清洗对用户输入进行基本的敏感词过滤和长度限制。对LLM的输出进行解析验证确保其符合预期的格式如JSON并处理解析失败的情况。后备方案Fallback当智能体多次尝试失败后应有降级策略。例如转接给人工客服、返回一个保守的默认答案、或者引导用户简化问题。5.3 成本控制与性能优化智能体应用的成本可能快速膨胀优化至关重要。缓存层对频繁出现的、结果不变的查询如“什么是机器学习”和工具调用结果如天气API数据短期内不变进行缓存。可以使用Redis或简单的内存缓存。上下文管理LLM的Token费用与上下文长度成正比。定期清理历史消息中不重要的部分只保留关键的任务指令、工具定义和最近的对话。使用“摘要”技术将长段对话历史压缩成一段摘要再放入上下文。模型分级调用并非所有步骤都需要最强大、最贵的模型如GPT-4。可以用小模型如GPT-3.5-Turbo处理简单的分类、格式化任务用大模型处理核心推理和创作任务。异步与流式处理对于耗时长的任务如多个子任务并行采用异步处理不要让用户同步等待。对于生成式输出使用流式响应Streaming提升用户体验。5.4 评估与迭代没有度量就没有改进如何判断你的智能体是否在变好需要建立评估体系。单元测试为智能体的核心功能如工具调用解析、特定问题回答编写测试用例确保代码更改不会破坏现有功能。端到端评估构建一个包含各种典型问题和边缘案例的测试集。定期运行跟踪关键指标任务完成率智能体能独立正确完成的任务比例。工具调用准确率在需要调用工具时是否正确选择了工具并提取了参数。平均对话轮次Turns完成一个任务平均需要多少次LLM交互。优化目标是降低这个数字。人工评分定期抽样让真人从准确性、有用性、流畅性等维度评分。A/B测试当对提示词或流程做出重大修改时进行A/B测试用数据说话选择效果更好的版本。智能体开发是一场结合了软件工程、提示词艺术和产品思维的旅程。这五种模式为你提供了强大的思维框架和设计工具但真正的 mastery 来自于不断的实践、踩坑和迭代。从一个具体而微的小任务开始选择一种模式将其实现然后观察、分析、优化再逐步引入更复杂的模式。在这个过程中你会逐渐培养出对智能体行为的直觉最终能够游刃有余地设计出稳健、高效、真正解决实际问题的智能体系统。记住最好的智能体不是最复杂的那个而是最能可靠解决用户问题的那个。