这些年来，后端服务以及模型算法都有一个新的发展趋势。

对于常规类后端应用来说，从几年前的微应用趋势开始，由比较零散的服务，逐渐做了一些中间件的提取下沉，形成了很多的中间件。到了云时代以后，又把这些中间件逐渐地沉淀成了云原生的一套基础架构。目前的业界已经逐渐接受了用云原生的部署方式去部署服务。

从另一个方面，从模型的方向上来看，大概也有一个从专用模型到基础模型的演进过程。

很多年前，要做一个什么具体的任务，就要用专用的数据集去训练一个专有的模型来解决特定的问题，可能同一个领域A公司和B公司训出来的模型都不一样，所有的任务可能都需要单独的模型来做。

后来就有了基础模型的概念，用海量的数据加上新的深度学习模型框架，训练出一个参数量非常大的模型。它的泛化能力非常强，在训练出来的基础模型的基础上做一些微调，或者是加一些简单的提示词就可以得到一个非常好的效果，甚至好于之前的专用模型，因此这类的大模型也得到了非常广泛的应用。

总结一下行业目前的状态，工程层面，云的基础设施已经比较完善了，然后也演进出了非常多的微服务；在模型方面，通过基础模型演化出了非常多的微调的专用模型。在基础之上，就形成了很多目前行业里比较火的大模型应用。

最初大模型刚出来的时候，有一个观点：能不能用大模型代替一切的东西。当时甚至有人认为由于大模型的出现，所有程序员都要下岗了，所有的人都要失业了。因为最初的问答大模型出来以后，大家觉得这个大模型的能力非常惊艳，好像无所不知，后来人们才逐渐发现大模型能干的事情其实是有限的。

有几个主要的限制，比方说其中之一就是它的数据更新频率很低。

就比如说像ChatGPT，它的数据可能是几年之前的，新的数据它不知道。要更新数据，必须是通过训练的方式非常多的GPU，非常多的时间非常多的钱才能去更新一次数据。

又比如另一个限制，语言类大模型它本质上也是模型，虽然说它有了一些问答能力看似好像有了很多的提升，但是它本身底层还是基于概率的。所以后来人们发现他经常有这种类似于幻觉的问题。这个东西在很多的场景下是不能忍受的。

因此，人们最终发现难以仅通过大模型就直接代替掉很多的传统应用。

后来，人们又提出来一个观点，我是不是可以把模型的推理程序，然后再加一些业务代码放在一块，部署成一个应用，来作为我的模型服务？后来有人这么做过，在这个推理框架外面包了一些业务代码，然后部署一个模型上去。

但后来人们逐渐发现这个大模型的每一次上线特别慢，大模型本身它更新频率就很低，可能几个月才更新一次模型。它的迭代效率也很低，它要上一次线非常的繁琐，可能要启动就要花很久；最关键的是部署成本非常高，启动一个模型，就要耗费1张GPU卡，创建一个应用就要起一个大模型，对于很多微应用来说是不能接受的。

所以人们很快就有了第二个结论，就是难以将模型推理程序和业务一块部署。

第一个比较成型的方案，是基于远程大模型服务的应用，把大模型作为一个原创服务，比如ChatGPT或者私有化部署。业务方有一些本地的代码，业务逻辑就是基于远程的大模型服务加本地的代码模式。

后面随着发展，应用做得更加深入之后，人们发现很多的功能不需要做在本地，因为本地会有比如语言的限制，或者多个团队协作的限制，于是又回到了微服务的状态：应用被切分成了远程大模型服务、微服务和本地胶水代码这么一个方式，本地的所谓的大模型服务就只剩下了流程的控制、数据的转换、数据的传递这些功能。

这些功能，最后就被编排引擎所取代了。我们目前的很多大模型应用本质上它的内核就是一个编排引擎，加少量的胶水代码，加上一些微服务，再加上远程的大模型服务来组成一个应用。

可以把目前行业里的编排引擎不准确地罗列一下，可能有的编排引擎可能有很多方面的能力，但是可以简单地划分一下侧重点。

早期的编排引擎，大部分都是分布式运行，是有代码和图形化的编排。到了大模型时代，就会发现为了迭代的效率，单机运行的变已经特别多了。但是随着发展，就会发现单机运行的大模型编排引擎无论是在功能、部署成熟度，以及生产环境的稳定性上，都是比不过分布式运行的编排引擎的。

微博的Rill Flow

(https://github.com/weibocom/rill-flow)编码引擎是微博自研的流程编码引擎，如果用刚才那个象限图去划分的话，它是一个分布式的、图形化的编排服务。

先讲一下它的历史，大概要追溯到17年，在做微博多媒体业务的视频编码流程的时候，开发了这么一个编排引擎。

早期版本它是一个基于代码编排的、分布式的编排引擎。上线以后，一直支持核心业务到现在。2020年，为了降低它的使用门槛我们做了一次改造，把代码编排改成了基于图形化的编排。在2022年，随着微博的云原生化的进程，Rill Flow也支持了云原生的能力打通。2023年支持了关于大模型的编排。2024年，开源到了GitHub。

Rill Flow的整体架构大概分成四部分。

左边是它的数据源，可以通过接口、定时任务，或者是通过队列消息去发起一个流程。流程发起之后，在中间是它的核心逻辑，主要是做流程的遍历和流程的派发。右边是具体的执行器，比如说有用户自定义的执行器、跟云原生的serverless结合的执行器，或者大模型的远程的服务等等。最后是用于交互的UI模块。

可以参考视频(https://video.weibo.com/show?fid=1034:5032211628621935) 了解具体功能。

做一个编排引擎，本质上要做两件事。

第一个是要做编排。要把业务的流程通过某种方式在流程引擎里面表达出来。第二个是根据用户表达出来步骤去具体地做执行。

对于编排来说，最核心的就是要灵活，最好能让用户能表达出任何的业务逻辑，因为很多的业务逻辑功能都是非常复杂的。需要变引擎具有非常强的灵活性和通用性；第二是它容易使用，不能说用户写一个东西特别费劲。

对于编排来说，Rill Flow能支持一些基本的流程控制的节点，包括常见的一个分支、for循环、并发执行、子流程等等。

第二个编排方面的优化是数据传递。对于Rill Flow来说，它的数据传递大概五个关键节点，分别是两次参数的映射、两次参数的转换，还有上下文的存储。

Rill Flow中的数据传递不是直接的两个节点之间的传递，而是会有一个中间的上下文中转存储，上一个节点的输出要传到上下文里面去，然后下一个节点再从上下文里面去取。

在传递的过程中会支持各种映射的一些参数转换的一些表达式。具体来说，映射是通过JsonPath来实现的。

完成了映射之后，可以对映射出来的结果通过表达式引擎去求值，Rill Flow内嵌了aviator表达式，可以用表达式进行简单的逻辑处理。

如果逻辑非常复杂，可以把python代码嵌到执行流程里面做一个单独的节点。

第三块就是易用性，对于编排来说，易用也是很重要的，Rill Flow的前端页面和其他的开源项目不太一样的点，就是它的编排页面是一个微应用。

可以把开源Rill Flow后台拆分成两部分，左边菜单部分是一个主应用，右边能拖拽的页面是一个微应用，用了阿里云的qiankun框架，可以理解成高级的iframe。

这样做的好处就是Rill Flow的编排功能可以嵌入到任何的系统里面去。在实践中，Rill Flow编排框架也是嵌入到微博的很多的内部平台里面去，给各种平台提供拖拉拽的功能。各种平台就可以根据自己的特点去定制里面的这些模板，或者去定制里面的一些功能，然后去拖拽出一个流程图来，最后给执行引擎执行。

Rill Flow的模板有点类似于coze或者defi里面的插件。界面左边的节点列表的模板节点是可以通过增删改查去创建的。在模板管理页面创建一个任务模板，保存之后就可以在编排界面拽出来了。

同时，Rill Flow的模板的灵活性也预留了扩展能力，可以定义一个任务里面的所有字段。比如除了配置一个大模型模板之外，还可以定义它是一个大模型的翻译函数。在实际的工作流里面业务A可以在流程里语言翻译成中文，业务B可以翻译成英文。

最后，任务模板里面还有一个输入输出的一个类型化参数，所有参数是类型化的，方便后面在执行的时候去做参数的类型的映射。具体来说是通过json schema做定义，它是描述jason类型的json，做好类型定义之后，在实际执行的过程中，就可以去找到对应的数据结构了。

对于执行部分，执行主要讲究的是稳定性和性能，这也是其实微博比较擅长的部分。

Rill Flow执行器设计的核心是上下文存储。

在很多的编排框架里面没有所谓的上下文的存储的概念，给用户的感觉好像就是数据在两个节点之间直接传递。但实际上它是会有一个所谓的上下文在做中间存储去传输的，只不过可能用户甚至开发者自己都没有意识到。

在Rill Flow里面，是显式的上下文：要传数据，必须把数据传到一个存储里面去（context），其他节点再从里面去取。

与之相对的，隐式上下文，比如说举个最简单的例子：通过代码去做编排。看似好像是第一步和第二步直接传的值。但在执行的过程中，中间结果其实是保存在线程栈上，数据是在内存里面的。

这个概念非常重要，因为它要保存到内存里面，所以这类执行器本质上是有状态的。

常见的工作流引擎都是这种模式：分布式的派发器+有状态的执行器。

派发器会把整个图派到一个执行器里面去完整地执行。在这个过程中，图的运行状态，包括中间的一些结果就会暂存在执行器的内存里面了。

Rill Flow选择的是中心化的上下文的存储和无状态的执行器，派发器会把一个图里面的每一个节点派到一个无状态的运行器里面。执行器不会遍历某个图，它只是做一个具体任务的执行。过程中的数据会保存到一个中心化存储。

这样做有几个好处，首先最大的一个好处就是容错。一个常规的编排引擎，它的容错方式有几种：策略重试、熔断、排队等等。举个场景，当有两个流程都要去访问一个大模型，或者是一个任何服务，这个服务过载了，这个时候希望去保住更高优先级的这个任务。

对于有状态执行器来说，它只能选择要么全做，要么全不做。对于一个流程，它只能选择执行完一个流程，或者是不执行一个流程。对于具体降级的场景，只能把高优先级的工作流接着执行，低优先级的工作流可能都降级掉，不管排队或者别的方式，都是对一个完整的工作流做的降级。

而在Rill Flow里面，因为支持了中心化的存储，它的状态是保存在存储里面的。所有的执行器它没有所谓的执行状态，它可以执行完一个图的某个节点以后，另一个节点不执行了，暂时放在中心化存储里面去，就可以实现无状态执行器的这个效果：它过载的时候，所有图都继续跑，但是只跑每一个图的关键路径。优先级由图级别变成了任务级别。

第二个好处是，Rill Flow同时支持了同步和异步的派发模式。

传统的同步派发器，发出请求，等待执行节点的执行的过程中，是需要消耗掉一些资源，虽然消耗不会消耗CPU之类的核心资源，但可能会消耗线程数或者消耗连接池这种资源。

对于异步派发模式来说，派发器只负责把这个任务派发出去，之后就接着去做别的事。执行服务的或者执行节点执行的过程中，对整个的调度集群是没有任何压力的。当任务执行完成以后，通过回调的方式回调到派发器的任何一个实例，流程就可以接着去执行。

同时支持同步和异步的开发方式，最核心的一个优势就是对任务执行时间不敏感，因为在执行的过程中，不消耗派发器集群的资源，单任务执行时间从一毫秒到30天都可以支持。

同时，因为派发的过程中，只消耗中心化存储的存储，而不会消耗其他的资源。这让服务扩展起来更方便。目前微博内部的执行集群已经达到了万级的规模，派发器每秒可以派发数万个任务。

中心化上下文存储带来了那么多好处，当然也会有代价。

因为引入了一个中心化的上下文存储。它就会带来额外的性能开销，每一个派发都需要去load save数据，包括需要更新流程的状态，更新一些数据的状态。并且在分布式的环境下，因为支持并发编排，也会带来分布式场景下并发更新上下文的问题。

针对这些问题，Rill Flow也做了很多优化。

首先是实现了多级的上下文存储，同时支持内存和磁盘数据库。

对于热的任务、执行时间快的任务，通过内存数据库去做上下文的持久化，几毫秒就可以完成数据的序列化、反序列化。对于一些执行时间长的，比如执行一个月的任务，就通过磁盘数据库来存储上下文，它的性能差一些，但是容量非常高，对于这类低频任务，回调的时候多个几百毫秒，其实可以接受。

同时，Rill Flow对分布式锁也做了一些优化，主要是尽量降低临界区大小，也包括锁的实现也做了优化。

第三个是做了本地派发模式，如果一个任务能在本地快速地派发，就不需要分布式。比如一个流程图里面执行完五步，再去更新一下上下文，就可以减少对中心化上下文的依赖。

最终，在线上刚才的万级集群的规模、每秒派发数万个任务的情况下，平均的任务派发时间是小于三毫秒的。

整体的架构大概分两大块。

下层是算力供给层，包括新浪和其他一些云厂商提供的算力。上层是云原生的pass平台，为业务提供了云原生的环境，包括K8S运行环境、对接混合云、应用混布，devops之类的一些功能。

在PaaS平台中，大模型应用平台有几个核心的模块，首先是编排服务，负责编排和执行。

第二块就是大模型服务，对接了很多的各种的开源，或者是商业化的模型。

第三块是微博平台，包含微博的核心业务，包括比如说用户、信息流、通讯、视频之类微博的基础的业务服务，主要提供的是内容服务（比如说查询一条微博），还有业务能力（比如说发一条视频），另外也提供了一个业务事件的事件总线，可以用来触发流程的编排。

第四块是FaaS平台。因为大模型很多的功能都是探索性的，上线下线特别快，业务的试错也特别快。按传统方案先申请服务器再去搞，可能就太慢了。所以说很多胶水代码，或者说简单业务代码是部署在无服务器平台里面了。能实现快速地部署、按需扩容。没有调用的话，基本上是不占资源的。

最后是AIGC应用平台，它是一个上层的对用户的平台。提供了模型的增强、策略、插件、智能体创建等等。

展开来说，大概分三大块：模型的管理，模型的微调、提示工程等；智能体的创建，包括插件的管理，编排，知识库存储等等的一些功能；还有一个应用市场，用于内部共享。

AIGC应用平台里面的应用在很多领域已经落地了，比如微博的创作工具、互动增强、内容理解、人力提效等等。

举最近上线的一个视频的AI总结的例子。

视频发布事件出来了以后，开始并发的一边抽音频，一边抽画面；结束以后去语音去做转文本，画面去做内容提取，然后输入到内容总结的大模型去做内容的总结，再过一些策略性的胶水的代码。最后去入库。目前一部分视频已经有AI总结这么个功能了，能看到视频里面的一些精彩的片段。

这次分享的大模型应用，本质上还是属于人工智能体，现在的模式是人创造的程序去跟大模型交互完之后，再去跟外部的视界去交互。

智能体的愿景，人只跟智能体完成交互，由智能体去跟外部的世界交互。

要实现这个功能，需要有很多的技术的储备。包括状态的感知：智能体能感知到外部的状态的变化。

其次要有长期的记忆，这样智能体才能不断地去学习和完善智能体的能力。

最重要的，真正的智能体的执行流程应该是不是由人编排，而是具备动态编排和自主决策的功能。可以去自行决策我每一步的执行路径，这也是Rill Flow未来去发展的方向。

活动预告

加入CCF

加入CCF会员享受更多超值活动，为自己的技术成长做一次好投资。

点击链接了解更多会员权益：

CCF个人会员权益  CCF公司会员权益

识别或扫码入会

欢迎关注CCFTF及CCF业务总部公众号，精彩陆续开启！

关注CCFTF获取TF活动资讯

关注CCF业务总部优惠预定会议场地