构建大模型应用的6大经典设计模式：从Workflow到Agent的实战指南！

最新推荐文章于 2025-11-04 23:44:10 发布

原创最新推荐文章于 2025-11-04 23:44:10 发布 · 595 阅读

CC 4.0 BY-SA版权

文章标签：

#设计模式 #java #开发语言 #产品经理 #人工智能 #langchain #大模型教程

今天想和大家讨论的的内容，来自Anthropic团队去年年底发表的《Building effective agents》这篇文章，虽然已经过去快一年了，但是文章中构建LLM应用的一些设计模式依然非常经典，也在我今年的工作中得到了印证，所以今天拿出来再重温一遍~（PS：Anthropic的很多文章质量都非常高，建议大家多关注，后面我也会持续拿出一些高质量的文章与大家一起解读。）

一、如何选择WorkFlow和Agent？

Anthropic将LLM应用分为两大类：一类是指完全通过LLM来动态规划任务流程、使用工具完成任务目标的系统，也就是狭义上的Agent，另一类则是，通过提前定义清楚任务的SOP流程，LLM只是该WorkFlow中的一个节点。

先说一个总原则：使用LLM构建应用时，越简单的解决方案越好！能用WorkFlow解决问题，就不要选择Agent。

WorkFlow在处理定义明确、相对复杂任务时，提供更好的性能、可观测性以及可重复性。只有当你的任务解决方案非常灵活，需要LLM来驱动决策时，Agent才是一种更好的选择。

简单举两个例子，来感受一下两者的区别：

选择WorkFlow：一家公司员工提交报销单（格式固定：日期、项目、金额、附件发票）做报销，这种任务步骤固定、规则明确（OCR→校验→审批→出款），任务成功/失败是计算机是可以自动判断的，且该场景要求稳定、可审计、低延迟，所以使用WorkFlow是比较合适的。LLM在WorkFlow中可充当增强节点的角色，比如：智能识别/提取字段、根据上下文进行语义判断（是否符合报销要求）、生成解释/提示、结合历史数据进行反舞弊初筛等能力。
选择Agent：在智能客服场景中，用户的问题类型可能是 “功能询问”“退款”“故障报告”“新需求”等，输入类型多样且有一定模糊性，无法知道用户下一步想干嘛，有时先问问题、有时查订单、有时又要退货退款，因此这种场景下可以使用Agent。Agent可以理解用户问题，决定用哪工具（知识库检索、CRM 查询、退款 API）、并能根据中间反馈（例如用户补充信息）调整下一步。

二、构建LLM应用的设计模式

Anthropic在文章中列举了几类LLM应用的设计模式，这几类设计模式在今年我们团队构建的LLM应用中，或多或少都有涉及到，非常具有代表性，下面我们来一起来逐个分析分析。

首先，要构建真正可用的LLM应用，基础单元不是“裸LLM”，而是具备Retrieval+Tool Use+Memory的Augmented-LLM。这样的模型才能根据任务主动决定何时查资料、用什么工具、保留哪些信息，并通过清晰、标准化的接口（如 MCP）与外部系统协作。下面将要介绍的几种设计模式，都默认所有LLM节点都是Augmented-LLM。

【设计模式一】：Prompt chaining

这种设计模式核心思想是，把一个复杂任务多个可验证的小任务，一次LLM Call拆解为多次LLM Call。并且，在每一次LLM Call前后，都可以加入校验节点/“门禁”，保证每一次LLM输出的内容都符合预期。

当你的任务可以轻松且清晰地分解为固定的子任务、且追求质量与可控性时，可以使用这种设计模式。

案例：一家耳机公司希望给自家公司新出的耳机，生成一份英文版的营销文案，并且将该英文版的营销文案，自动翻译为其他语言，以支持该产品在其他国家的营销活动。该WorkFlow的步骤为：

首先，通过合适的Prompt让LLM根据已知信息，生成一段合理的英文版营销文案。
通过代码来判断上一步LLM生产的内容是否符合规则，比如，“是否80 - 120词”“是否出现禁词”“是否包含核心卖点”等规则，这就是“门禁”的作用。
如果门禁检查结果为不符合要求，则返回到第一步重新生成。否则，则进入到下一步。
利用LLM将英文版营销文案翻译为目标国家的语言。
这里同样可以再加入一个“门禁”来检查上一步LLM输出的内容，若如何要求，则作为最终输出。

【设计模式二】：Routing

该模式的核心思想是，先对用户的输入进行分类，然后路由到不同分类的任务中去。它解决的问题主要是：对于不同用户的输入，最佳的处理方式是不同的，如果用同一套Prompts/模型/逻辑去完成，会出现简单的输入被“大材小用”、复杂的输入被简单逻辑/Prompts拖垮、优化某类输入效果时，可能会拖累另一类输入的表现的情况。

这种设计模式适用于，任务虽然很复杂，但是可以清晰的将复杂的任务分成几类，并且这几类任务都可以被独立处理，让每类任务都有最合适的处理逻辑，对号入座。

我们今年做的LLM应用，最开始就会用LLM充当问题分类器，将用户的问题首先路由到合适的子工作流中，主干工作流的结构就非常简洁清晰，充当了“意图中心”的角色。

案例：在智能客服的场景中，假设用户的问题可以被分为3类，如下表所示：


类别	示例	处理方式
普通咨询	“你们支持花呗么？”	RAG+小模型直接回答
退款/投诉	“我想取消订单并退款”	退款流程+定制化Prompts
技术问题	“我登录时一直报错”	工单/日志关联+技术支持流程

所以，Routing就是通过“先分类再分流”，让不同类型的任务走最适合的模型/Prompt/工具，从而同时获得更高准确率、更低成本和更好的可维护性。它适用于任务类型清晰且可稳定识别的复杂业务场景。

【设计模式三】：parallelization

该设计模式的核心思想是，将串行变为并行，不要让LLM一次把所有事的干完，而是把任务拆成可并行的子任务，同时运行，最终所有子任务完成后，再在主干流程中整合最终结果。

这里有两种典型的用法，一种就是上面说的，把一个大任务拆成多个互不依赖的子任务并行执行，目的是为了提升速度。另外一种用法是，对同一任务让多个LLM实例分别尝试（比如用不同的Prompts、不同的模型等），然后聚合，进行投票/排名/过滤，最终获得质量更高的结果。

在我们的产品中有一个“审批建议”场景，用来辅助审核人员判断版本变更准入是否合理。为了让 LLM 生成更有价值的审批意见，我们需要先丰富其输入信息来源 —— 例如当前版本的需求内容、测试用例、代码仓信息等。

系统会通过多个 API 并行拉取这些结构化数据，再结合我们预先定义的判断规则，将所有信息汇总成统一的 JSON，作为 LLM 的输入，让模型基于完整上下文生成可靠的审批建议。

这正是一种典型的Parallelization设计模式：任务拆分 → 并行获取 → 程序汇聚 → 提供给模型决策。

【设计模式四】：Orchestrator-workers

这种WorkFlow通俗的讲，即使“总指挥 + 多个执行者” 的动态协作式工作流。Orchestrator就是LLM，负责理解用户目标、动态拆解任务、选择worker执行、最终收集结果并汇总成最终回答。

而Workers则负责各自完成 Orchestrator 派发的子任务，子任务之间可以不同类型、不同数量。

与上面的几种设计模式做一个比较：


设计模式	特点	使用场景
Prompt Chaining	步骤可预定义，线性推进	任务可清晰拆分且顺序固定
Parallelization	子任务可预定义，可并行	任务维度已知，追求速度/多视角
Orchestrator–Workers	子任务数量与类型不可预知，动态拆解	复杂开放任务（例如写代码）

最典型的案例就是代码修改，比如，用户要求你重构某个功能，你的产品是无法事先知道会影响多少文件、每个文件怎么改、还可能要多轮调整。比如，当用户提出“将现有系统改造为 OAuth2 并确保前端与网关兼容”这样的需求时：

Orchestrator（总指挥 LLM）会先理解目标，再动态拆解任务，例如识别需要修改的后端认证模块、网关脚本、前端登录流程和测试用例，然后将这些子任务分别分配给不同的 Worker（多个执行 LLM 或工具）并行处理，最后 Orchestrator 收集各 Worker 的修改结果进行统一检查、整合与补充，输出一套完整可直接应用的变更方案。

通过这种模式，系统可以在事先无法预知任务数量和修改范围的情况下，完成复杂多文件、多模块的代码改造任务。

【设计模式五】：Evaluator-optimizer

这种设计模式是一种“先产出、再反馈、再优化”的迭代式工作流，适用于有明确评价标准、且质量提升依赖多轮打磨的任务。optimizer负责产出内容，Evaluator负责根据提前明确好的规则，对结果进行打分、提改进意见、指出问题。根据评审意见，生成者改写，再被评审者复查……直到合格或达到迭代次数。

当我们的任务有明确的评估标准，并且迭代改进能够带来可衡量的价值时，可以考虑使用这种设计模式来优化你的产品。什么叫迭代改进能够带来可衡量的价值？就是说，当我们反馈给LLM意见时，他真的能在下一次输出时变得更好，并且，这个反馈的过程不是我们来做，而是另一个LLM来做。

在高质量技术文档生成场景中，我们可以采用这种设计模式：由Optimizer LLM 先输出初稿，再由Evaluator LLM 根据清晰的评价标准（如逻辑性、准确性、术语一致性、语气合规）对内容打分并提出修改意见；

Optimizer 据此优化文稿并再次提交审查，如此循环多轮，直到审查通过或达到迭代上限。通过这种“写 → 评 → 改 → 再评”的机制，文档质量能在明确标准指引下持续提升，从而获得显著优于一次性生成的最终结果。

【设计模式六】：Agent

随着LLM的通用能力越来越强（理解用户输入、推理与动态规划、稳定调用工具等），Agent这种设计模式才可以真正被用于生产环境中，并且，这也是我们最期望看到的一种模式。一旦任务清晰，Agent就可以自己决定下一步的行动，并根据环境反馈持续推进任务，直到任务完成，或者因为超过了最大迭代次数，而被迫终止。

Agent可以处理复杂任务，但是目前他的实现基本上都是基于环境反馈，然后在循环中使用工具的LLM，所以这里面就隐藏了一个关键的注意事项，就是要好好设计一下工具集以及他们的文档，好让LLM高效的调用这些工具。

如果你的任务是开放式的、无法硬编码路径、需要多轮与环境交互，那可以考虑使用Agent来构建你的应用。但是要注意，这种方式是成本最高，且最不稳定的一种模式，还是强调文章开头的原则：使用LLM构建应用时，越简单的解决方案越好！能用WorkFlow解决问题，就不要选择Agent。

在自动故障排查场景中，我们可以使用 Agent 模式：当用户提出“登录接口频繁报 500，请定位并修复”时，Agent 会先自主制定排查计划，再依次调用日志查询、代码搜索、补丁应用与测试等工具，根据每一步的真实反馈决定下一步行动；如果修复失败，它会自动调整策略并继续迭代，直到问题解决或达到停止条件。

整个过程无需预设固定流程，Agent 能像一名具备专业的运维工程师一样，在开放式任务中自主探索、执行并完成目标。

三、结束语

在我们团队今年的实践中，上述几种设计模式基本都有所涉及，它们更像一套在我们构建LLM应用时，可自由拼装的 “乐高积木”。大家在使用这些设计模式时，要根据不同的业务场景对他们进行灵活组合、动态取舍。

最后要再次强调 —— 一切设计的出发点都是业务价值。不要为了炫技或堆砌复杂架构而复杂，要让复杂度为结果服务，让技术选择反向被指标验证，而不是反过来被技术牵着走！

原文链接：https://www.anthropic.com/engineering/building-effective-agents

四、如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

一直在更新，更多的大模型学习和面试资料已经上传带到CSDN的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇

在这里插入图片描述