1. 项目概述与核心价值最近在探索AI Agent智能体开发领域时发现了一个非常棒的资源仓库fzy2012/rhzl-Agentic-Design-Patterns-cn。这个项目本质上是一个高质量的中文翻译与解读项目其核心是将Andrej Karpathy等人提出的“Agentic Design Patterns”智能体设计模式这一前沿概念系统性地引入中文技术社区。对于任何正在或计划涉足大模型应用、自动化工作流以及智能体系统构建的开发者、产品经理和技术决策者而言这个仓库都是一座亟待挖掘的宝藏。简单来说Agentic Design Patterns 探讨的是如何像搭积木一样用一些经过验证的、可复用的“模式”来设计和构建基于大语言模型的智能体。它回答了一个核心问题当我们需要一个AI去完成一个复杂任务比如分析一份财报、编写一个程序模块、或者规划一次旅行时除了简单的一问一答我们还能如何设计它的“行为逻辑”和“协作方式”这个项目提供的正是一套关于这些设计模式的“菜谱”和“最佳实践”。而rhzl-Agentic-Design-Patterns-cn的价值在于它通过精准的翻译和可能的本地化注解极大地降低了中文开发者理解、学习和应用这些模式的门槛。它不仅仅是文字的转换更是知识的桥梁让前沿的AI工程思想能够更快速、更准确地触达更广泛的实践者。2. Agentic Design Patterns 核心思想拆解在深入具体模式之前我们必须先理解其背后的核心思想。传统的LLM调用往往是“单次、静态”的用户输入一个问题模型返回一个答案交互结束。然而现实世界中的复杂任务很少能通过一次交互解决。Agentic智能体化思维就是将LLM从一个被动的“答题器”转变为一个主动的、拥有一定“自主性”和“目标感”的“执行者”。2.1 从工具调用到智能体思维早期的LLM应用如ChatGPT的插件或Function Calling已经具备了“使用工具”的能力。但这仍然是用户驱动、单步执行的。智能体思维的关键跃迁在于引入了“规划-执行-反思”的循环。一个智能体在接到任务后会先进行任务分解规划然后逐步执行子任务可能涉及调用工具、查询信息并在每一步检查结果是否符合预期反思必要时调整策略。这种循环赋予了系统处理不确定性和复杂性的能力。Agentic Design Patterns可以看作是实现这种智能体思维的一系列标准化“蓝图”。它们定义了智能体内部或智能体之间交互的固定方式就像软件工程中的设计模式如工厂模式、观察者模式定义了代码组件间的协作关系一样。这些模式是可组合的你可以根据任务复杂度选择单一模式或组合多个模式来构建你的智能体系统。2.2 模式的价值标准化与可复用性为什么需要设计模式因为在智能体开发的早期阶段很容易陷入“重复造轮子”和“架构混乱”的困境。每个团队可能都在用自己的方式实现任务分解、工具调用和错误处理。设计模式的价值在于提供共同语言当团队讨论时可以说“我们这里用一个Router模式来分发任务”而不是花半小时描述一个自定义的分发逻辑。提升开发效率模式提供了经过验证的实现模板开发者可以直接参考或基于此进行微调避免了从零开始的试错成本。保证系统质量这些模式通常包含了对于边界情况如工具调用失败、子任务循环的处理建议有助于构建更健壮的系统。促进生态发展标准化的模式使得不同团队开发的智能体组件更容易集成和协作为未来智能体“应用商店”或“工作流市场”打下基础。fzy2012/rhzl-Agentic-Design-Patterns-cn项目所做的正是将这些价值以中文形式固化下来加速国内智能体开发生态的成熟。3. 核心设计模式深度解析根据原版材料及其中文翻译我们可以深入探讨几个最关键、最实用的Agentic设计模式。理解这些模式是构建有效智能体的基石。3.1 Router路由模式这是最基础也是最常用的模式之一。它的核心思想是将一个复杂的、模糊的用户请求精准地分发给最擅长处理该子任务的专用智能体或工具。工作原理一个主控智能体或一个专门的Router组件接收用户原始输入。该Router分析输入内容判断其意图、领域和所需技能。根据预设的规则或通过一个轻量级LLM调用进行判断Router将任务路由到对应的“下游智能体”。下游智能体处理完毕后将结果返回给Router或直接给用户。实操示例 想象一个客服机器人。用户说“我的订单#12345还没收到另外我想问问你们最新款的手机有什么颜色”传统方式一个庞大的LLM试图同时回答物流问题和产品咨询容易混淆或遗漏。Router模式Router识别出两个独立意图1) 物流查询订单相关2) 产品咨询。它将物流问题路由给“订单查询智能体”该智能体接入了物流数据库API将产品咨询路由给“产品知识库智能体”。两个智能体并行处理结果被汇总后返回给用户。注意事项路由规则的粒度规则太粗路由不准规则太细维护成本高。初期可以基于关键词后期建议用一个小型LLM如微调过的轻量模型来做意图分类更灵活。失败回退必须设计默认路由。当Router无法确定或所有候选智能体都失败时应有一个通用的“兜底智能体”或直接提示用户澄清问题。中文语境挑战中文的表述比英文更灵活、更依赖上下文。在实现中文Router时意图识别模型需要针对中文进行优化并充分考虑口语化、省略主语等常见情况。rhzl-Agentic-Design-Patterns-cn的翻译和注释如果能加入一些中文特有的意图分类示例价值会更大。3.2 Agent Supervisor智能体主管模式也称为“管理者-工作者”模式。这是一个用于协调多个智能体共同完成一项复杂任务的强大模式。一个“主管”智能体负责宏观规划和任务分配多个“工作者”智能体负责执行具体指令。工作原理Supervisor接收一个高层级目标例如“为公司季度会议准备一份市场分析报告”。Supervisor将目标分解为一系列有序或并行的子任务例如1. 收集最近三个月行业新闻2. 分析主要竞争对手动态3. 整理我方销售数据4. 撰写报告摘要和PPT大纲。Supervisor根据子任务类型将其分配给不同的Worker智能体例如将任务1分配给“网络爬虫智能体”任务2和3分配给“数据分析智能体”任务4分配给“文案撰写智能体”。Supervisor监控Worker的执行状态和结果确保子任务完成质量并负责将各Worker的输出整合成最终成果。实操示例自动化编程助手。目标“开发一个简单的待办事项Web应用包含任务列表、添加和删除功能。”Supervisor分解前端创建React组件TodoList, TodoItem实现UI和交互。后端设计REST APIGET /todos, POST /todos, DELETE /todos/:id。数据库创建todos表id, task, completed。集成连接前端与后端API。分配与执行Supervisor将任务1分配给“前端专家智能体”任务2和3分配给“后端专家智能体”任务4可能由Supervisor自己或一个“集成智能体”完成。Supervisor需要检查前端组件是否引用了正确的API端点后端API是否返回了前端期望的JSON格式。注意事项通信协议标准化Supervisor和Worker之间必须有一套清晰的指令和结果传递格式例如使用JSON Schema定义任务描述和输出格式否则会出现理解偏差。处理循环与僵局当Worker执行失败或结果不达标时Supervisor应能制定B计划如重试、换一个Worker、将任务进一步分解或请求人工干预。要避免Supervisor和Worker互相等待导致的死锁。成本与延迟每个Worker可能都是一次LLM调用复杂任务会导致调用链很长成本和响应时间激增。需要对任务分解的粒度进行权衡有时合并一些简单步骤是更经济的选择。3.3 其他关键模式简述除了上述两个核心模式该仓库还涵盖其他几种重要模式Chain of Thought (CoT) / Tree of Thoughts (ToT)这更多是提示工程模式但也是智能体推理的基础。CoT要求LLM“一步步思考”展示推理过程ToT则允许在推理的每一步考虑多种可能性形成树状结构然后通过评估选择最优路径。这在智能体进行复杂规划或决策时至关重要。Self-Critique自我批判智能体生成一个输出后不是直接提交而是启动一个“审查者”角色可以是同一个LLM的不同提示也可以是一个专门的批判性LLM对输出进行批判性检查找出逻辑错误、事实不符或风格问题然后进行修订。这能显著提升输出质量尤其适用于代码生成、报告撰写等场景。Tool-Using Agent工具使用智能体这是智能体的基本能力单元。模式重点在于如何让LLM可靠地选择正确的工具、生成正确的调用参数、以及解析工具返回的结果。这涉及到清晰的工具描述名称、功能、参数格式、返回值格式和稳定的调用流程。4. 基于设计模式的智能体系统构建实战理解了模式之后我们如何将它们组合起来构建一个真实的智能体系统这里以一个“智能研发助手”为例演示如何应用上述模式。4.1 场景定义与架构设计场景帮助开发者或产品经理快速启动一个小型项目。用户输入一个模糊的想法如“做一个能记录我每天喝水次数并提醒我的小程序”智能体能输出一份包含技术选型建议、基础代码框架、依赖文件甚至简单部署指南的项目方案。架构设计组合模式入口Router首先一个Router判断用户请求的类别。是“生成新项目”、“调试现有代码”、“解释技术概念”还是“编写测试”本例中它被识别为“生成新项目”。核心协调Agent SupervisorRouter将“生成新项目”请求交给一个Project Supervisor智能体。Supervisor负责整个项目方案的规划和组装。任务分解与执行Supervisor将任务分解为需求澄清、技术栈推荐、项目结构设计、核心代码生成、README编写。它将这些子任务分派给不同的Worker需求分析Worker与用户进行多轮对话如果需要明确“小程序”指的是微信小程序、Web App还是手机App提醒方式是什么需要数据统计吗技术栈顾问Worker根据澄清后的需求推荐前端如React Native、Uni-app、后端如云函数、Node.js、数据库如SQLite、云数据库等。架构师Worker根据技术栈生成标准的项目目录结构。代码生成Worker针对核心功能如“记录喝水次数”的按钮和存储逻辑“提醒”的定时逻辑生成样板代码。文档生成Worker合成以上信息生成项目的README.md文件。质量把关Self-Critique在最终方案输出前由一个Critic Worker检查方案的完整性、技术栈的合理性、代码是否存在明显语法错误或安全漏洞。最终交付Supervisor整合所有Worker的输出形成一份结构化的项目方案文档交付给用户。4.2 关键技术实现要点状态管理Supervisor需要维护一个“任务状态板”跟踪每个子任务的状态待分配、执行中、已完成、失败、执行者哪个Worker、以及产出物。这通常通过一个数据库或内存中的数据结构如字典来实现。Worker的标准化接口每个Worker应该是一个独立的服务或函数它接收一个标准化的任务描述对象并返回一个标准化的结果对象。例如# 任务描述示例 task_spec { task_id: req_analysis_001, task_type: requirement_clarification, input: {user_idea: 做一个喝水提醒小程序..., context: {...}}, expected_output_format: {clarified_requirements: dict, questions_to_user: list} } # Worker结果示例 worker_result { task_id: req_analysis_001, status: success, # or failed output: { clarified_requirements: {platform: WeChat Mini Program, reminder_type: notification, ...}, questions_to_user: [] # 如果无需再问则为空 }, metadata: {llm_calls: 3, tokens_used: 450} }错误处理与重试在Supervisor中必须实现健壮的错误处理。如果某个Worker失败如LLM调用超时、返回格式错误Supervisor应能记录错误并根据策略决定是重试可能更换提示词、分配给另一个同类型Worker还是将任务标记为失败并向上游或用户报告。上下文传递下游Worker通常需要上游的上下文。例如代码生成Worker需要知道技术栈顾问Worker推荐的技术栈和需求分析Worker澄清后的需求。Supervisor需要负责将必要的上下文信息附加到发给每个Worker的任务描述中。4.3 工具链与平台选择构建这样的系统可以选择不同的技术栈低代码/框架方案使用如LangChain、LlamaIndex、Semantic Kernel等框架。它们原生提供了Agent、Tool、Chain等抽象内置了类似Router、Supervisor的逻辑可以快速搭建原型。rhzl-Agentic-Design-Patterns-cn中的模式概念与这些框架的组件有很好的对应关系。纯代码实现如果你需要更高的控制权和定制化可以用Python/Node.js等语言结合OpenAI API、Anthropic Claude API或其他本地模型API从头实现模式逻辑。这更复杂但能让你深入理解每一个细节。云平台服务一些云厂商如Azure AI Studio、Google Vertex AI也开始提供智能体编排的托管服务可以用可视化工具来定义工作流适合对编码要求不高的团队。注意无论选择哪种方式清晰的设计文档和模块化的代码结构至关重要。每个Worker应该尽可能功能单一、接口明确这样便于调试、替换和扩展。5. 实践中的挑战与应对策略在实际应用这些设计模式时你会遇到一些共性的挑战。以下是我在多个项目中积累的一些心得和避坑指南。5.1 幻觉与事实准确性LLM的“幻觉”是智能体系统最大的风险之一尤其在需要提供事实信息如技术栈版本、API用法或生成代码时。策略1工具增强减少生成尽可能让智能体通过调用可靠的工具来获取信息而不是依赖LLM的记忆生成。例如技术栈推荐Worker不应该凭空说“用React 18”而应该调用一个“技术栈知识库查询工具”或直接搜索官方文档。策略2多层验证结合Self-Critique模式。让一个Critic Worker专门检查生成内容的事实准确性。例如对于生成的代码可以启动一个“代码静态分析工具”或“语法检查工具”进行验证。策略3提供参考来源要求智能体在输出中注明关键信息的来源例如“根据Node.js官方文档v20.x...”这既增加了可信度也方便人工复核。5.2 任务分解的粒度难题任务分解得太细效率低下分解得太粗智能体可能无法完成或出错。黄金法则可独立执行与验证一个子任务的最佳粒度是它可以被一个Worker相对独立地执行并且其产出物可以明确地被验证对/错完整/不完整。例如“生成用户登录API的代码”是一个合适的粒度“开发后端”就太粗了。动态调整可以让Supervisor具备初步评估能力。如果某个Worker多次失败于一个任务Supervisor应能尝试将这个任务进一步分解。人工干预点在系统设计时预留“人工审核”节点。对于非常关键或模糊的任务分解结果可以暂停流程交由人类确认后再继续。5.3 成本与延迟优化智能体系统的多次LLM调用会导致高昂的API成本和较长的响应时间。缓存策略对常见的、确定性的子任务结果进行缓存。例如对于“推荐Python Web框架技术栈”这种任务如果输入需求类似可以直接返回缓存结果无需调用LLM。使用轻量级模型并非所有步骤都需要GPT-4级别的模型。Router做意图分类、Critic做简单格式检查完全可以使用更便宜、更快的轻量级模型如GPT-3.5 Turbo、Claude Haiku或本地小模型。异步与并行仔细分析任务依赖关系。没有依赖关系的子任务如“生成前端代码”和“设计数据库表结构”应该由Supervisor并行地分配给Worker而不是串行执行。设置预算与超时为每个任务和整个会话设置token预算和超时时间。当消耗接近预算或超时时系统应优雅地终止或返回当前最佳结果而不是无限期运行。5.4 评估与持续改进如何知道你的智能体系统是否在变好定义可量化的指标不仅仅是“用户满意度”。可以包括任务完成率、平均完成步骤数越少越好、工具调用准确率、人工干预率、单次会话平均token消耗等。建立测试集构建一个涵盖常见和边缘用例的测试任务集。每次对系统或某个Worker进行更改后都在测试集上运行对比关键指标的变化。日志与溯源记录每一次LLM调用输入、输出、工具调用和任务状态转换。当出现错误或低质量输出时完整的日志链是进行根因分析的唯一依据。rhzl-Agentic-Design-Patterns-cn这类项目如果能补充一些关于监控和日志的最佳实践会更具工程价值。6. 未来展望与进阶思考Agentic Design Patterns 为我们提供了构建复杂AI系统的脚手架。随着技术的发展我认为以下几个方向值得关注模式的垂直化与领域化目前的模式比较通用。未来必然会出现针对特定领域如智能客服、代码生成、数据分析优化的专用模式或模式变体。例如在客服领域“情绪识别与安抚”可能成为一个标准子模式。从设计模式到框架与标准就像MVC模式催生了众多Web框架一样Agentic模式也正在催生更高级的智能体编排框架和通信标准如类似“智能体描述语言”的东西。关注像LangGraph用于构建有状态、多智能体应用这样的新兴工具。长期记忆与个性化当前的智能体大多是“会话式”的缺乏长期记忆。如何安全、有效地为智能体引入长期记忆记住用户偏好、历史交互并实现个性化服务是提升体验的关键。这可能涉及到新的“记忆管理”模式。人机协同的深化智能体不是要完全取代人而是增强人。设计模式中应更系统地考虑“人类在环”的节点。什么情况下应该主动询问用户如何将复杂问题的决策权优雅地移交给人类这需要更精细的“人机交互”模式。回过头看fzy2012/rhzl-Agentic-Design-Patterns-cn这个项目它的意义远不止于翻译。它是在为中文AI应用开发者铺设一条通往下一代软件工程范式的快速路。我个人的体会是在学习这些模式时切忌生搬硬套。最好的方式是先深入理解每个模式要解决的核心问题例如Router解决“任务分类”Supervisor解决“复杂协作”然后结合自己手头的具体项目思考“我这里遇到的是类似的问题吗”。很多时候你可能只需要一个简单的Router或者一个CoT提示就能解决80%的问题。从简单模式开始实践积累经验再逐步构建更复杂的多智能体系统这才是稳健的落地之道。这个仓库就是你手边最好的模式词典和灵感来源常翻常新。
AI Agent设计模式解析：Router与Supervisor模式构建智能体系统
发布时间：2026/5/17 0:43:33
1. 项目概述与核心价值最近在探索AI Agent智能体开发领域时发现了一个非常棒的资源仓库fzy2012/rhzl-Agentic-Design-Patterns-cn。这个项目本质上是一个高质量的中文翻译与解读项目其核心是将Andrej Karpathy等人提出的“Agentic Design Patterns”智能体设计模式这一前沿概念系统性地引入中文技术社区。对于任何正在或计划涉足大模型应用、自动化工作流以及智能体系统构建的开发者、产品经理和技术决策者而言这个仓库都是一座亟待挖掘的宝藏。简单来说Agentic Design Patterns 探讨的是如何像搭积木一样用一些经过验证的、可复用的“模式”来设计和构建基于大语言模型的智能体。它回答了一个核心问题当我们需要一个AI去完成一个复杂任务比如分析一份财报、编写一个程序模块、或者规划一次旅行时除了简单的一问一答我们还能如何设计它的“行为逻辑”和“协作方式”这个项目提供的正是一套关于这些设计模式的“菜谱”和“最佳实践”。而rhzl-Agentic-Design-Patterns-cn的价值在于它通过精准的翻译和可能的本地化注解极大地降低了中文开发者理解、学习和应用这些模式的门槛。它不仅仅是文字的转换更是知识的桥梁让前沿的AI工程思想能够更快速、更准确地触达更广泛的实践者。2. Agentic Design Patterns 核心思想拆解在深入具体模式之前我们必须先理解其背后的核心思想。传统的LLM调用往往是“单次、静态”的用户输入一个问题模型返回一个答案交互结束。然而现实世界中的复杂任务很少能通过一次交互解决。Agentic智能体化思维就是将LLM从一个被动的“答题器”转变为一个主动的、拥有一定“自主性”和“目标感”的“执行者”。2.1 从工具调用到智能体思维早期的LLM应用如ChatGPT的插件或Function Calling已经具备了“使用工具”的能力。但这仍然是用户驱动、单步执行的。智能体思维的关键跃迁在于引入了“规划-执行-反思”的循环。一个智能体在接到任务后会先进行任务分解规划然后逐步执行子任务可能涉及调用工具、查询信息并在每一步检查结果是否符合预期反思必要时调整策略。这种循环赋予了系统处理不确定性和复杂性的能力。Agentic Design Patterns可以看作是实现这种智能体思维的一系列标准化“蓝图”。它们定义了智能体内部或智能体之间交互的固定方式就像软件工程中的设计模式如工厂模式、观察者模式定义了代码组件间的协作关系一样。这些模式是可组合的你可以根据任务复杂度选择单一模式或组合多个模式来构建你的智能体系统。2.2 模式的价值标准化与可复用性为什么需要设计模式因为在智能体开发的早期阶段很容易陷入“重复造轮子”和“架构混乱”的困境。每个团队可能都在用自己的方式实现任务分解、工具调用和错误处理。设计模式的价值在于提供共同语言当团队讨论时可以说“我们这里用一个Router模式来分发任务”而不是花半小时描述一个自定义的分发逻辑。提升开发效率模式提供了经过验证的实现模板开发者可以直接参考或基于此进行微调避免了从零开始的试错成本。保证系统质量这些模式通常包含了对于边界情况如工具调用失败、子任务循环的处理建议有助于构建更健壮的系统。促进生态发展标准化的模式使得不同团队开发的智能体组件更容易集成和协作为未来智能体“应用商店”或“工作流市场”打下基础。fzy2012/rhzl-Agentic-Design-Patterns-cn项目所做的正是将这些价值以中文形式固化下来加速国内智能体开发生态的成熟。3. 核心设计模式深度解析根据原版材料及其中文翻译我们可以深入探讨几个最关键、最实用的Agentic设计模式。理解这些模式是构建有效智能体的基石。3.1 Router路由模式这是最基础也是最常用的模式之一。它的核心思想是将一个复杂的、模糊的用户请求精准地分发给最擅长处理该子任务的专用智能体或工具。工作原理一个主控智能体或一个专门的Router组件接收用户原始输入。该Router分析输入内容判断其意图、领域和所需技能。根据预设的规则或通过一个轻量级LLM调用进行判断Router将任务路由到对应的“下游智能体”。下游智能体处理完毕后将结果返回给Router或直接给用户。实操示例 想象一个客服机器人。用户说“我的订单#12345还没收到另外我想问问你们最新款的手机有什么颜色”传统方式一个庞大的LLM试图同时回答物流问题和产品咨询容易混淆或遗漏。Router模式Router识别出两个独立意图1) 物流查询订单相关2) 产品咨询。它将物流问题路由给“订单查询智能体”该智能体接入了物流数据库API将产品咨询路由给“产品知识库智能体”。两个智能体并行处理结果被汇总后返回给用户。注意事项路由规则的粒度规则太粗路由不准规则太细维护成本高。初期可以基于关键词后期建议用一个小型LLM如微调过的轻量模型来做意图分类更灵活。失败回退必须设计默认路由。当Router无法确定或所有候选智能体都失败时应有一个通用的“兜底智能体”或直接提示用户澄清问题。中文语境挑战中文的表述比英文更灵活、更依赖上下文。在实现中文Router时意图识别模型需要针对中文进行优化并充分考虑口语化、省略主语等常见情况。rhzl-Agentic-Design-Patterns-cn的翻译和注释如果能加入一些中文特有的意图分类示例价值会更大。3.2 Agent Supervisor智能体主管模式也称为“管理者-工作者”模式。这是一个用于协调多个智能体共同完成一项复杂任务的强大模式。一个“主管”智能体负责宏观规划和任务分配多个“工作者”智能体负责执行具体指令。工作原理Supervisor接收一个高层级目标例如“为公司季度会议准备一份市场分析报告”。Supervisor将目标分解为一系列有序或并行的子任务例如1. 收集最近三个月行业新闻2. 分析主要竞争对手动态3. 整理我方销售数据4. 撰写报告摘要和PPT大纲。Supervisor根据子任务类型将其分配给不同的Worker智能体例如将任务1分配给“网络爬虫智能体”任务2和3分配给“数据分析智能体”任务4分配给“文案撰写智能体”。Supervisor监控Worker的执行状态和结果确保子任务完成质量并负责将各Worker的输出整合成最终成果。实操示例自动化编程助手。目标“开发一个简单的待办事项Web应用包含任务列表、添加和删除功能。”Supervisor分解前端创建React组件TodoList, TodoItem实现UI和交互。后端设计REST APIGET /todos, POST /todos, DELETE /todos/:id。数据库创建todos表id, task, completed。集成连接前端与后端API。分配与执行Supervisor将任务1分配给“前端专家智能体”任务2和3分配给“后端专家智能体”任务4可能由Supervisor自己或一个“集成智能体”完成。Supervisor需要检查前端组件是否引用了正确的API端点后端API是否返回了前端期望的JSON格式。注意事项通信协议标准化Supervisor和Worker之间必须有一套清晰的指令和结果传递格式例如使用JSON Schema定义任务描述和输出格式否则会出现理解偏差。处理循环与僵局当Worker执行失败或结果不达标时Supervisor应能制定B计划如重试、换一个Worker、将任务进一步分解或请求人工干预。要避免Supervisor和Worker互相等待导致的死锁。成本与延迟每个Worker可能都是一次LLM调用复杂任务会导致调用链很长成本和响应时间激增。需要对任务分解的粒度进行权衡有时合并一些简单步骤是更经济的选择。3.3 其他关键模式简述除了上述两个核心模式该仓库还涵盖其他几种重要模式Chain of Thought (CoT) / Tree of Thoughts (ToT)这更多是提示工程模式但也是智能体推理的基础。CoT要求LLM“一步步思考”展示推理过程ToT则允许在推理的每一步考虑多种可能性形成树状结构然后通过评估选择最优路径。这在智能体进行复杂规划或决策时至关重要。Self-Critique自我批判智能体生成一个输出后不是直接提交而是启动一个“审查者”角色可以是同一个LLM的不同提示也可以是一个专门的批判性LLM对输出进行批判性检查找出逻辑错误、事实不符或风格问题然后进行修订。这能显著提升输出质量尤其适用于代码生成、报告撰写等场景。Tool-Using Agent工具使用智能体这是智能体的基本能力单元。模式重点在于如何让LLM可靠地选择正确的工具、生成正确的调用参数、以及解析工具返回的结果。这涉及到清晰的工具描述名称、功能、参数格式、返回值格式和稳定的调用流程。4. 基于设计模式的智能体系统构建实战理解了模式之后我们如何将它们组合起来构建一个真实的智能体系统这里以一个“智能研发助手”为例演示如何应用上述模式。4.1 场景定义与架构设计场景帮助开发者或产品经理快速启动一个小型项目。用户输入一个模糊的想法如“做一个能记录我每天喝水次数并提醒我的小程序”智能体能输出一份包含技术选型建议、基础代码框架、依赖文件甚至简单部署指南的项目方案。架构设计组合模式入口Router首先一个Router判断用户请求的类别。是“生成新项目”、“调试现有代码”、“解释技术概念”还是“编写测试”本例中它被识别为“生成新项目”。核心协调Agent SupervisorRouter将“生成新项目”请求交给一个Project Supervisor智能体。Supervisor负责整个项目方案的规划和组装。任务分解与执行Supervisor将任务分解为需求澄清、技术栈推荐、项目结构设计、核心代码生成、README编写。它将这些子任务分派给不同的Worker需求分析Worker与用户进行多轮对话如果需要明确“小程序”指的是微信小程序、Web App还是手机App提醒方式是什么需要数据统计吗技术栈顾问Worker根据澄清后的需求推荐前端如React Native、Uni-app、后端如云函数、Node.js、数据库如SQLite、云数据库等。架构师Worker根据技术栈生成标准的项目目录结构。代码生成Worker针对核心功能如“记录喝水次数”的按钮和存储逻辑“提醒”的定时逻辑生成样板代码。文档生成Worker合成以上信息生成项目的README.md文件。质量把关Self-Critique在最终方案输出前由一个Critic Worker检查方案的完整性、技术栈的合理性、代码是否存在明显语法错误或安全漏洞。最终交付Supervisor整合所有Worker的输出形成一份结构化的项目方案文档交付给用户。4.2 关键技术实现要点状态管理Supervisor需要维护一个“任务状态板”跟踪每个子任务的状态待分配、执行中、已完成、失败、执行者哪个Worker、以及产出物。这通常通过一个数据库或内存中的数据结构如字典来实现。Worker的标准化接口每个Worker应该是一个独立的服务或函数它接收一个标准化的任务描述对象并返回一个标准化的结果对象。例如# 任务描述示例 task_spec { task_id: req_analysis_001, task_type: requirement_clarification, input: {user_idea: 做一个喝水提醒小程序..., context: {...}}, expected_output_format: {clarified_requirements: dict, questions_to_user: list} } # Worker结果示例 worker_result { task_id: req_analysis_001, status: success, # or failed output: { clarified_requirements: {platform: WeChat Mini Program, reminder_type: notification, ...}, questions_to_user: [] # 如果无需再问则为空 }, metadata: {llm_calls: 3, tokens_used: 450} }错误处理与重试在Supervisor中必须实现健壮的错误处理。如果某个Worker失败如LLM调用超时、返回格式错误Supervisor应能记录错误并根据策略决定是重试可能更换提示词、分配给另一个同类型Worker还是将任务标记为失败并向上游或用户报告。上下文传递下游Worker通常需要上游的上下文。例如代码生成Worker需要知道技术栈顾问Worker推荐的技术栈和需求分析Worker澄清后的需求。Supervisor需要负责将必要的上下文信息附加到发给每个Worker的任务描述中。4.3 工具链与平台选择构建这样的系统可以选择不同的技术栈低代码/框架方案使用如LangChain、LlamaIndex、Semantic Kernel等框架。它们原生提供了Agent、Tool、Chain等抽象内置了类似Router、Supervisor的逻辑可以快速搭建原型。rhzl-Agentic-Design-Patterns-cn中的模式概念与这些框架的组件有很好的对应关系。纯代码实现如果你需要更高的控制权和定制化可以用Python/Node.js等语言结合OpenAI API、Anthropic Claude API或其他本地模型API从头实现模式逻辑。这更复杂但能让你深入理解每一个细节。云平台服务一些云厂商如Azure AI Studio、Google Vertex AI也开始提供智能体编排的托管服务可以用可视化工具来定义工作流适合对编码要求不高的团队。注意无论选择哪种方式清晰的设计文档和模块化的代码结构至关重要。每个Worker应该尽可能功能单一、接口明确这样便于调试、替换和扩展。5. 实践中的挑战与应对策略在实际应用这些设计模式时你会遇到一些共性的挑战。以下是我在多个项目中积累的一些心得和避坑指南。5.1 幻觉与事实准确性LLM的“幻觉”是智能体系统最大的风险之一尤其在需要提供事实信息如技术栈版本、API用法或生成代码时。策略1工具增强减少生成尽可能让智能体通过调用可靠的工具来获取信息而不是依赖LLM的记忆生成。例如技术栈推荐Worker不应该凭空说“用React 18”而应该调用一个“技术栈知识库查询工具”或直接搜索官方文档。策略2多层验证结合Self-Critique模式。让一个Critic Worker专门检查生成内容的事实准确性。例如对于生成的代码可以启动一个“代码静态分析工具”或“语法检查工具”进行验证。策略3提供参考来源要求智能体在输出中注明关键信息的来源例如“根据Node.js官方文档v20.x...”这既增加了可信度也方便人工复核。5.2 任务分解的粒度难题任务分解得太细效率低下分解得太粗智能体可能无法完成或出错。黄金法则可独立执行与验证一个子任务的最佳粒度是它可以被一个Worker相对独立地执行并且其产出物可以明确地被验证对/错完整/不完整。例如“生成用户登录API的代码”是一个合适的粒度“开发后端”就太粗了。动态调整可以让Supervisor具备初步评估能力。如果某个Worker多次失败于一个任务Supervisor应能尝试将这个任务进一步分解。人工干预点在系统设计时预留“人工审核”节点。对于非常关键或模糊的任务分解结果可以暂停流程交由人类确认后再继续。5.3 成本与延迟优化智能体系统的多次LLM调用会导致高昂的API成本和较长的响应时间。缓存策略对常见的、确定性的子任务结果进行缓存。例如对于“推荐Python Web框架技术栈”这种任务如果输入需求类似可以直接返回缓存结果无需调用LLM。使用轻量级模型并非所有步骤都需要GPT-4级别的模型。Router做意图分类、Critic做简单格式检查完全可以使用更便宜、更快的轻量级模型如GPT-3.5 Turbo、Claude Haiku或本地小模型。异步与并行仔细分析任务依赖关系。没有依赖关系的子任务如“生成前端代码”和“设计数据库表结构”应该由Supervisor并行地分配给Worker而不是串行执行。设置预算与超时为每个任务和整个会话设置token预算和超时时间。当消耗接近预算或超时时系统应优雅地终止或返回当前最佳结果而不是无限期运行。5.4 评估与持续改进如何知道你的智能体系统是否在变好定义可量化的指标不仅仅是“用户满意度”。可以包括任务完成率、平均完成步骤数越少越好、工具调用准确率、人工干预率、单次会话平均token消耗等。建立测试集构建一个涵盖常见和边缘用例的测试任务集。每次对系统或某个Worker进行更改后都在测试集上运行对比关键指标的变化。日志与溯源记录每一次LLM调用输入、输出、工具调用和任务状态转换。当出现错误或低质量输出时完整的日志链是进行根因分析的唯一依据。rhzl-Agentic-Design-Patterns-cn这类项目如果能补充一些关于监控和日志的最佳实践会更具工程价值。6. 未来展望与进阶思考Agentic Design Patterns 为我们提供了构建复杂AI系统的脚手架。随着技术的发展我认为以下几个方向值得关注模式的垂直化与领域化目前的模式比较通用。未来必然会出现针对特定领域如智能客服、代码生成、数据分析优化的专用模式或模式变体。例如在客服领域“情绪识别与安抚”可能成为一个标准子模式。从设计模式到框架与标准就像MVC模式催生了众多Web框架一样Agentic模式也正在催生更高级的智能体编排框架和通信标准如类似“智能体描述语言”的东西。关注像LangGraph用于构建有状态、多智能体应用这样的新兴工具。长期记忆与个性化当前的智能体大多是“会话式”的缺乏长期记忆。如何安全、有效地为智能体引入长期记忆记住用户偏好、历史交互并实现个性化服务是提升体验的关键。这可能涉及到新的“记忆管理”模式。人机协同的深化智能体不是要完全取代人而是增强人。设计模式中应更系统地考虑“人类在环”的节点。什么情况下应该主动询问用户如何将复杂问题的决策权优雅地移交给人类这需要更精细的“人机交互”模式。回过头看fzy2012/rhzl-Agentic-Design-Patterns-cn这个项目它的意义远不止于翻译。它是在为中文AI应用开发者铺设一条通往下一代软件工程范式的快速路。我个人的体会是在学习这些模式时切忌生搬硬套。最好的方式是先深入理解每个模式要解决的核心问题例如Router解决“任务分类”Supervisor解决“复杂协作”然后结合自己手头的具体项目思考“我这里遇到的是类似的问题吗”。很多时候你可能只需要一个简单的Router或者一个CoT提示就能解决80%的问题。从简单模式开始实践积累经验再逐步构建更复杂的多智能体系统这才是稳健的落地之道。这个仓库就是你手边最好的模式词典和灵感来源常翻常新。
