基于Agent驱动的工作流开发模式探索

工作流我们听得多，Agent最近也听得耳朵起茧，把Agent当节点构建Agent工作流也常见，但是我今天要向你展示的是，用Agent作为底层框架来开发工作流。这是一种新的开发模式，通过本文的探索，你会看到一种新的开发范式的出现，并且你会在将来对此习以为常。

传统工作流开发

当我们讨论工作流时，往往会考虑业务流程。当我们用代码堆出一大堆难以维护的业务逻辑代码之后，迭代变得难以维系，此时我们就会诉诸于工作流来解决我们的开发困境。从概念上讲，工作流（特别是业务流程）在于将复杂的业务逻辑显式地拆解为一系列预定义的、线性的或基于条件的步骤，并且用标准的统一语言（Ubiquitous Language）来进行表达，并在最终落地为一套有流程图界面可供操作的系统。

在我所经历过的几个工作流项目中，存在着这样一对矛盾：业务团队希望所开发的工作流可以完美适配团队业务现状，开发团队希望所开发的工作流可以完美应付任何业务场景，而往往业务团队和开发团队是一批人，他们总会在这对矛盾间纠结，以至于工作流系统开发进度不及预期。

在所有标准工作流模式中，BPMN最为典型和知名，但除了BPMN以外还有一种也比较知名的可用于构建业务流程模型的语言/符号。它们主要有：

• BPMN（Business Process Model and Notation，业务流程模型和符号）：提供了一套标准化的图形符号，用于描绘流程中的活动（Activity）、网关（Gateway，如分支或合并点）、事件（Event）和流向（Sequence Flow）。开发人员的首要任务是与业务分析师一起，将现实世界的业务逻辑转化为严谨的、可执行的BPMN图。
• 状态机（State Machine）： 对于核心是实体状态转换的简单流程（例如文档审批生命周期：草稿 -> 待审核 -> 已拒绝/已批准），状态机模型更为高效和直观。许多轻量级工作流框架（如PHP生态中的Symfony Workflow）正是基于有限状态自动机（FSM）实现的。
• UML活动图（UML Activity Diagram）： 在软件工程领域，UML活动图常用于描述软件内部的控制流和数据流，它在概念上与业务流程图相似，但更侧重于程序行为而非跨部门的业务协作。
• 事件驱动流程链（EPC，Event-Driven Process Chain）： 尤其是在欧洲和SAP相关的环境中，EPC是一种早于BPMN的流程建模标准，它以事件（Event）和功能（Function）交替驱动流程的推进。

无论采用哪种建模方式，传统模式的共同点是：流程结构必须在代码实现之前被预先定义、固化，且运行中不可动态修改。

知名的工作流引擎有 Activiti、Flowable 和 Camunda。这些引擎负责解析BPMN模型、管理流程实例的状态、执行任务分配（Task Assignment）、以及持久化流程数据。基于这些引擎，我们常常是把工作流系统和业务系统分开的，工作流系统独立部署，由开发人员与业务人员一起发布各个流程图，发布之后，通过订阅发布的形式与业务系统进行通信。一般来说，工作流系统本身并不侵入业务系统，也不为业务系统提供特殊的业务逻辑，业务系统则把工作流系统作为第三方依赖，触发和订阅流程，从而实现自身业务状态的变化。但是，实际上，一般来说，这两套系统都是同一个开发团队在管理，开发团队要为工作流系统的稳定性负责，如果因为工作流系统挂掉了，导致业务出现故障，那么责任自己扛。

作为前端，我常用的框架主要是bpmn2.0和xstate这两个。从广义上讲，我们用的DevOps工作流也是符合这个范畴，我在腾讯的时候，参与过早期的公司层面的DevOps工作流开发，后来这个项目逐渐演变成了蓝盾和腾讯流水线。现在，一个非常知名的工具N8N已经占据了整个工作流大半市场，而在AI创作领域，ComfyUI则是绝对的不二选择。

工作流这种模式，优势在于流程的可视化、可审计性强和执行可靠。然而，它的主要弊端在于僵硬性和高昂的维护成本。流程中的任何微小变动——无论是业务规则的调整、外部API的变更还是新步骤的加入——都需要经历“重新建模 -> 重新编译部署后端服务 -> 重新修改前端代码”的漫长周期。这使得传统工作流在面对快速变化的业务需求或非结构化、需要灵活决策的动态场景时，显得过于笨重和迟缓。

因此，将显式的、预定义的流程，转化为自组织、自适应的协作网络，这种新的工作流开发模式悄然崛起。

Agent驱动的工作流开发模式

Agent驱动的工作流开发模式并非简单地将Agent视为BPMN图中的一个“服务节点”，而是将其视为工作流的底层框架（Foundation），甚至是流程本身的运行时（Runtime）。这种范式从根本上颠覆了“先建模，后执行”的传统思维，迈向了“先定义目标，后自组织执行”的新境界。

更为贴近现实写代码的角度的讲，这种模式彻底颠覆我们开发工作流的过程。你要把Agent当作底层的框架，类似Activiti、Flowable那样的带有代码写作范式的东西，也就是说，写代码的方式都会发生翻天覆地的变化。利用Agent来重构业务流程，作为开发者而言，可能需要做非常大的心理建设。因为，我们以前那一套业务梳理、领域模型、状态管理等等方法论，现在统统都不需要了，它就像一个黑盒，但是是非常聪明且准确率高的离谱的黑盒，像似里面住了一个巫师，你把你的业务规则和当前状态丢进去，它就能给你返回你下一步应该执行的函数名与参数，然后你运行这个函数即可，至于它的内部怎么做到的，现在，地球上无人能知。但是，作为开发者，我不管你能不能接受这种模式，我想它都会重溯整个行业。关注我的微信公众号 wwwtangshuangnet 阅读本文原文。

在很多时候，我们创建Agent，都是“应用心态”，也就是以创建应用的心态去创建Agent，一个Agent可以解决一类问题。但是，现在，我们把Agent放到更底层去，它不是应用层面的，而是开发框架、第三方类库层面的。

如何接入此类工作流？

现在先让我们来看一下，这类工作流，在开发层面，是如何工作的。也即，开发者是怎么写代码接入实际业务的。有了这个相当于“快速开始”的感观之后，后面你就好理解了。

第一步，我们需要在一个单独的地方，定义工作流节点和工作流描述。

• 工作流节点，包含名称、描述、参数及其描述，其中描述非常重要，它将向AI展示自己的功能、特性、条件等等，让AI能够在正确的时间和正确的状态下选择运行它
• 工作流描述，对整个工作流的描述，包含工作流的业务背景、业务规则等，也可以包含工作流节点之间的顺序、依赖关系等，用于限定AI在选择节点运行时有一个约束性
• 节点具体实现，就是用代码把节点实现一遍，名称和参数要与描述中的一一对应，另外要有可被阅读的返回结果，禁止返回一些运行时的类实例

第二步，实例化这个Agent，并且向Agent发送消息。然后等Agent返回结果之后，把结果解析为JSON对象，完成后续逻辑。

结束。

以上就是业务侧的整个开发流程，有没有很意外，看上去如此简单。没有与第三方的通信和回调，似乎就是调用了一个黑箱接口一样。没错，基于Agent来实现工作流，完全免除了搭建部署工作流系统的所有成本。这让我想起以前在业务团队搭建 flowable 后端时的造孽过程，当时负责这件事的同事，为此做了非常多的研究，还凭借这些研究完成了晋级。如今回头看看，都有些感慨。

如何对原有业务逻辑代码进行重构？

传统的业务逻辑代码主要通过条件分支来实现数据分流，复杂一点就会用到FSM对状态进行管理，再复杂就会上流程图系统。但我们认真思考一下，工作流的本质是什么？是现实业务，本质上就是人。不同开发团队在不同业务中的位置各有侧重，有的业务团队比较保守，要求系统必须照搬现实工作流程，代码为业务服务，而有的业务团队比较激进，试图让研发团队用技术提供新的工作流程模式来提升工作效率。

我以前所在的腾讯投资业务就是保守与激进兼而有之，当听到业务团队要求必须怎样怎样的时候，就比较痛苦和抗拒，当听到产品经理说我们用什么功能来代替原有工作时，就比较亢奋。

以投资工作中的文件签署流程为例，从资方与创业团队的接触开始，到与团队谈妥，再到打钱，再到后来的退出，这个过程中要签署各种文件，而每次签署文件的流程又或各有不同，最终形成了一套极为复杂的工作流系统。如果用最原始的办法实现，就是理清业务，按照业务流程的逻辑，不同的进行逻辑分支。但随着代码层级的层层下钻，逻辑就会越来越难掌握。

那么，如何用Agent驱动的工作流重构这类已有的工作流程呢？

首先，我们需要重新整理整个业务。这需要产品经理、业务人员、开发团队，一起对已有的业务流程进行梳理，并形成严谨的业务流程文档。这里非常关键的是业务规则，也就是代码层面的逻辑分支。只有详细的规则，才能获得准确。

其次，对不同的业务场景进行区分。以单次业务为单元，列出所有业务场景。这会让我们从原来通用的业务代码中又重新跳脱出来，形成全部一个一个的特殊业务点。

接着，以单个业务点为一个流程Agent，为这个业务点建立规则。

最后，建立一个大的类似路由的Agent，将各个业务点点Agent统一起来，当逻辑进入该部分之后，由这个统一的Agent来调度使用哪一个子Agent来运行。

而在重构后的实际体验上，业务团队的人员，就不需要从原本一个巨大的流程页面进去找到自己当前所在的阶段，然后再去操作，而是直接告诉Agent我要做什么操作，并且把自己的文件上传上去，由Agent自己来完成调度。当然，我们也可以完全保留原来的操作界面，使两者可以统一到一起。

与传统工作流引擎相比有哪些不同？

用Agent作为底层驱动来去构建业务流程，虽然会大大的节省开发量，但是也没有玄乎到程序员什么都不用干，没有到不写代码的地步。这需要和Vibe Coding区分开来。

Vide Coding是由多个Agent协同完成编程任务，目标是写代码，至于具体的业务流程，需要通过vibe的形式，让Agent写成固化的代码，一旦写好后，工作流就是静态的固定的。而我们现在所讲的Agent工作流，是由人来写好代码，在实际业务运行时AI参与其中。两者有着巨大的区别。

先不管这种开发模式好不好，有没有优势，是不是更符合业务降本增效的主旋律，我们先来看一看Agent工作流模式与传统工作流模式的区别，再从中得到自己的一些体悟。

参数自组织

传统工作流引擎需要定义节点，高级一点的用DSL来定义流程，从这些方面来说，基于Agent驱动的工作流在“工作流”概念的本质上没有颠覆。但是，基于AI的推理总结能力，在新模式下，我们不需要因为节点之间的数据传递太过操心，AI可以自己从上下文（当前的和以往的）中提炼节点参数，从而大大的节省了我们在实现节点时的复杂度。

举一个例子，我们的某一个节点，在运行时，需要传入“用户所选的币种”，但是这个节点其实位于位置比较靠后的地方，而用户是在一开始提交的币种信息，这个操作可能是在5天前。传统的做法是要么要求用户在当前也传入当时选的币种，要么是在业务系统一侧通过数据库查询之后再把币种信息连同用户提交一起传入要执行的节点。这在传统开发模式下，非常自然，毫无争议。但是如果是基于Agent的工作流，则不需要在此时关心币种问题，因为Agent有一个“上下文”的概念，我们会通过“上下文工程”去构建上下文，而作为用户提交的信息，往往都在上下文中，虽然当前用户并没有提供币种信息，业务侧代码也没有去查，但是Agent在构造当前节点的入参时，由于我们构建的上下文中包含了用户提交的早期信息，AI会自动识别到这个信息，并把它构造到参数里面去。

光靠文字可能比较难理解，你现在就可以去做一个实验，在deepseek中发起一个新会话，然后在一开始提供一个币种信息，并在多轮会话之后，要求它构造一个JSON对象，并提供一个JSON Schema描述，其中一个字段就描述说是币种，那么它几乎一定会把你最早提供的币种信息填到这个JSON里返回给你。

这就是基于Agent的工作流的参数自组织特性，它包含两个点：

• 无需在工作流中用代码去进行上下游节点数据传递的mapping，AI会自己根据JSON Schema的描述构造正确格式的参数（包括数据类型和格式统一等等）
• 无需处理跨节点数据传递问题，AI会自动从上下文（历史数据）中拿到对应的值作为参数

有了这个特性之后，开发者不再需要关注工作流与实际业务的强关联性，而是可以专注于某个节点的具体实现，不需要考虑说上游节点给的数据对不对，自己的返回数据格式可不可以等等问题，只要专注于把自己的逻辑实现清楚。

上下文自感知

其实上面说的“跨节点数据传递”就是上下文自感知的一种。你不需要明确的告诉Agent要从哪里去拿数据，Agent有自己的推理能力，能根据你的输入，理解出当前工作流的领域概念，并且按照业务的常见模式去提取、汇总、转换。

举一个小例子，比如你的流程里面提供了多用户在某个节点的输入，比如搬家的一个流程，搬家公司可能要分两批完成你们办公室的用品搬迁，那么这就涉及到两批人的协作。比如A批录入了125件物品，B批录入了240件，那么搬完之后，流程就进入到下一阶段，验收阶段。此时有一个工作节点需要验证物品数量是否符合。如果是传统实现，就必须将A和B各自录入的数据都查出来，然后相加之后传入节点。但是，用Agent则不需要，因为AI有简单的数学知识，它自己可以感知总共件数是365件，而无需人为去数据相加。

同样的道理，当一个用户在中午12点在某一个节点上完成了操作，在后续节点上要求只统计2小时以内的数据时，AI能感知这个中午12点的操作是否属于统计的范畴（当然前提是AI得知道当前的确切时间）。

以上举的这两个例子都是非常简单的推理场景，简单的数字加减和时间比较，AI几乎都不会出错。

这种上下文自感知的特性，让Agent工作流在开发时有了更多的灵活性。不过归结起来还是，开发者只需要把精力集中在节点本身的实现上，而无需太为工作流的全盘过度操心。

无固定edge流程，以实现业务为目标

节点与节点的连线即edge（边），表示节点的先后顺序和依赖关系，也表示着数据的流向。而Agent驱动的工作流弱化了强制性edge设计，即弱化了流程“编排”这件事。传统的工作流编程，必然面临节点编排的复杂实现。

我曾在腾讯参与节点与边DSL的设计，我们最初希望通过一套简单的符号描述来代表edge，但是在经过多轮的验证后，发现现实中工作流的编排太复杂了，稍有一个例外案例出现，就会打乱原有设计的美好初衷。在我的博客 www.tangshuang.net 中阅读本文原文。

复杂的工作流系统，往往都有一套独立的编排体系，前端通过bpmn.js或其他流程图UI库来承载，同时前后端在数据结构上要形成统一，在这套统一的数据结构上，后端以这份数据作为配置，去理解配置中各个阶段的顺序、守护条件、并串行逻辑、延时等等各种工作流里面的专有逻辑。

这样一整套的东西，归根到底就是为了解决edge的问题，即数据的流转问题。

而基于Agent驱动的工作流，则没有这种编排。节点选择，或者说数据的流转，靠的是Agent对业务规则的理解和对当前整个上下文中数据、状态的判断，由Agent来决策接下来应该执行哪个工作节点。

不过这并不意味着准确的业务流程不重要。相反，由于AI具有一定的幻觉，如果你所提供的系统提示词不够准确，流程跑错的可能性还是有的，因此，对业务的精确描述就更加重要。当然，由于我们还可以在Agent实现时加上Plan、ReAct等模式，可以打压它执行错误的概率。看上去这种模式多了很多不确定性，然而实际上，它是跳过繁琐，直指业务核心，只要实现了业务目标，走哪条“路”并不重要。

正是因为有了这一特性，基于Agent的工作流就没有编排系统。你可以说，你的产品业务文档就是编排系统。

无需从固定节点开始执行

传统的工作流必须有一个起点，也就是“开始”节点。在一个工作流实例化之后，它的执行顺序是固定的，虽然可能有很多分支，但是每条分支的入参和返回值，都是有强烈约束的。但Agent工作流不一定非得从某个节点开始。

得益于强大的上下文工程，我们可以在系统上下文中，塞入很多有用的信息，而在这些信息的驱使下，Agent相当于有了很多前置信息，当这些前置信息覆盖了某些节点的输出（也就是这些节点就是为了得到这些信息）时，Agent就可能跳过执行这些节点。

作为程序员，其实我们可以理解这种模式。在我们的编程中也存在着两种模式，一种是“激发模式”，一种是“收集模式”。所谓激发模式就是我不断的产生数据，然后把数据传入进去，通过了它的验证，它就会开始运行，这就是激发。而收集模式则是反过来，它在不停的收集可用的数据，一旦收集齐全了自己需要的数据，就会主动运行。这两种模式各有好处，不过我们大多数情况下都是采用激发模式，相对来说，收集模式理解起来和实现起来都更难。

而基于Agent来实现收集模式则异常简单，因为你不需要去通过编程实现依赖收集，AI大模型自己可以提炼相关信息。这也就是说，对于工作流中的节点，它们其实不是被某一个东西推着走，而是在入参满足的情况下，被Agent运行，而适当的工作流流转描述，就可以跳过那些流程中靠前的为后续节点生成数据的节点，从而大大提升业务流转的效率。

更强的通用性和向下兼容

就像我们开发自己的工作流平台或框架一样，一旦一个框架成型发布，那么就可以复用到其他很多业务中。同样的道理，一款好的Agent工作流框架也可以复用到其他业务中。而由于当下Agent开发模式的特殊性，这种框架的通用性更好，比如现在流行的编程Agent（如claude code），它可以复用到很多场景中。特别是一些通用Agent，可以完成跨领域的任务。

由于一套业务系统中，各个业务模块往往具有极强的相关性，因此，在一个业务中为了提升效率而研发的Agent工作流框架，可以几乎非常容易的接入到其他业务模块中。特别是新业务模块，几乎无需做流程开发，就可以复用原有的框架，快速搭好业务流程。

另外还有一个点，就是基于Agent的工作流，可以和老系统兼容，甚至共存。之所以会出现这样的情况，是因为AI对数据格式的不敏感，你是xml的也好，JSON的也罢，就是纯文本它也不挑。因此，你可以在老系统继续运行的基础上，搞一个旁路，用Agent工作流完成和老系统一模一样的能力，但是提供一个聊天+表单融合的界面，操作更简单，要提交的数据也更少，让关系比较好的业务团队成员试用，反馈不错的情况下，再推广到整个业务团队使用，然后把老系统的入口进行切换（不是下架，只是隐藏，因为还可以继续用）。

工具的丰富生态

其实也不算太丰富，但是只要有上游接口，用起来也很方便。例如，如果按照传统的开发模式，如果想要接入一个第三方服务，比如说某个发界面很漂亮邮件的服务，往往需要我们在原有的业务系统中，新增一些代码来完成接入。但是，用Agent的开发模式就不需要，你只需要自己开发一个mcp的npm包，发布到公司内部的npm仓库，然后在你的Agent配置文件中，把这个mcp server的配置信息加进去，在无需修改业务代码的情况下，就可以增加工具调用。（当然，前提是你为你的Agent预留了无需重启服务就可以添加mcp server的能力。）这特别适合用在那种不是核心业务节点，而是一些旁路的节点，例如通知类、信息收集总结类、数据统计类等节点。

构建Agent驱动的工作流框架的核心概念

本来我想要写如何实现一个Agent驱动的工作流框架的，但是由于时间原因，以及篇幅所限，我打算下次再写一篇单独的实战篇来写。到时候再把写好的框架开源，就可以让更多的小伙伴一起来体验这种新的工作流开发模式。

在构建Agent驱动的工作流之前，我们首先需要掌握Agent的构建。当然，这里的掌握是指核心能力，也就是会话、工具调用的能力，毕竟如果啥都掌握了，那还要人家那些构建Agent的创业公司干啥。因此，我们先从最核心的开始，只要一个Agent能够按照常规的Agent模式跑起来，那么我们就可以开始构建自己的工作流框架。

Agent核心组件与角色

一个Agent不仅仅是一个大型语言模型（LLM）的调用接口，它是一个具备以下要素的自主执行单元：

• 感知与推理（LLM Core）： 利用LLM强大的上下文理解和推理能力，理解用户目标、流程状态和环境反馈。
• 工具与行动（Tools & Actions）： Agent被赋予了执行特定任务的工具集（Tools），例如调用企业API、查询数据库、发送邮件或运行自定义代码块。这些工具取代了传统工作流中的“服务任务”（Service Task）。
• 记忆与经验（Memory）： 保持短期记忆（上下文）和长期记忆（历史流程、最佳实践），从而在复杂、长周期的流程中保持连贯性。
• 规划与修正（Planner）： 根据当前目标和状态，Agent可以自主生成、评估和动态调整其执行计划，这取代了传统BPMN中固定的、预定义的流程路径。

传统工作流开发模式中，流程路径是外置的（存储在BPMN图中）；Agent模式中，流程路径是内置的（由Agent的规划器动态生成）。虽然我们可以利用Agent来动态规划流程，但是我们最好还是能够在系统提示词中把我们本来的业务流程写清楚，而不是完全让Agent来自由发挥，毕竟连人在理解业务上都会存在偏差，更何况AI理解我们的复杂业务呢？

作为初学者，我们不需要一上来就各种Agent框架来一堆，我们完全不要什么Agent框架，我们直接自己手撸代码。这些高大上的“执行单元”，本质上不过是各种调用。除了调用工具，就是调用LLM API接口，说起调用，谁能比我们这些CRUD程序员们更厉害呢？只要我们理清楚了Agent的工作原理，那么用一个文件就可以手撸一个Agent，连MCP都给你接上。

一些干货，Agent的记忆就是存数据库，什么数据库都行，我们不需要做什么记忆压缩、筛炼之类的，存起来，然后读取出来，稍加筛选和处理，就可以作为上下文了。核心目标是跑起来。每一个节点的输出，直接转化为JSON字符串存，因为AI完全可以读这种信息，你甚至不需要把它转回Object对象，就是字符串丢给AI。还有就是Agent可以是无状态的，如果你的系统不需要长连接，不需要多人同时协作，就是一个独占进程的业务处理的类型的，那么就是要运行的时候，启动一个Agent实例（给它一个ID），然后把它的记忆（数据）从数据里读出来，塞进去作为上下文，然后再向它发送这个请求的数据就行了，超级简单。

一切皆工具调用

在Agent中，虽说什么规划、反思之类都很重要，但是所有的一切，都要落到“工具调用”这4个字上。而Agent工作流，实际上就是“工具调用”+“流程控制”，如果我们激进一点，我们干掉流程这个概念，我们所做的一切工作，本质上就是利用Agent的工具调用能力，干掉了原来复杂的流程图系统。那么什么是工具？这是一个占据了99%心智重要性的问题。

在Agent中，所谓工具，就是一段被执行的代码，而往往，这段代码还具有非常高的统一格式，以至于我们只要按照这个格式开发全部工具，就可以让这个Agent拥有无限力量。在大模型中，有一个Function Call的能力，这个能力是一切的基础。有了它，我们可以与MCP Server结合，构建出一个可动态注册的，固定运行逻辑的通用Agent框架。而正如前文所说，你的业务团队在业务上关联性很大，所以这个通用Agent有很大可能，可以覆盖你们团队的全部需求，就像万金油一样，哪里有需求就往哪里贴。而有了MCP之后，这个Agent框架还可以做到随时随地增加工具，甚至可以修改系统提示词来增加功能。而，我们还可以把业务封装为MCP Server，一个新业务逻辑上线，变得非常易插拔，都不用动正在运行的老系统。

此外，还有一个更有意思的点，就是你还可以把另外一个Agent当作工具来接入当前的Agent，同样也是基于MCP协议来实现热插拔。也就是说，我们可以让两个业务串联起来，比如你所在的某个销售系统和财务是完全隔绝的两个系统，现在，有了Agent+MCP，你可以在销售系统里把财务系统中的某个能力作为你业务流程里面的一个环节，而无需财务系统做任何改造（如果他们有API的话）。

而流程，落到最后，就是何时何地以何参数调用工具的过程。前面说到Function Call的能力，实际上，Function Call可以多轮调用，大模型可以分批次的执行工具，通过上一批次的执行结果，来自主决策这一批次可以调用的工具，而如果没有可调用的工具，它就会返回空。这对我们执行工作流来说，又把开发难度降低了，传统模式下，我们需要解析流程图中edge的各种内在意思，按规则执行，但是在Agent模式下，只需要来一个自循环（可以是while(true)也可以是递归），就可以做到以前要有个庞大的流程引擎才能做到的事。实在是太神奇了！

最近这几年，经济形式下行，IT行业面临经济周期波动与AI产业结构调整的双重压力，很多人都迫于无奈，要么被裁，要么被降薪，苦不堪言。但我想说的是一个行业下行那必然会有上行行业，目前AI大模型的趋势就很不错，大家应该也经常听说大模型，也知道这是趋势，但苦于没有入门的契机，现在他来了，我在本平台找到了一个非常适合新手学习大模型的资源。大家想学习和了解大模型的，可以**点击这里前往查看**