面向LLM的App架构——业务维度

这是两篇面向LLM的大前端架构的第一篇，主要写我对LLM业务的认知以及由此推演出的大前端架构。由于我是客户端出身，所以主要以客户端角度来描述，并不影响对前端的适用性。

对LLM的认知

基于Google对AGI的论文，AGI或者LLM一定会朝着在决策过程中越来越重要的方向发展。任务过程可以简单抽象为目标设定、信息收集、任务拆分、retro、执行。目前成型的LLM应用，主要还是在任务过程的某几个点作为最叶子的工具存在的，后续一定会向着主导完整过程的方向走。
曾经有个大佬说过，LLM是对世界的压缩。还有另一个大佬说过，语言可以完整描述世界。那么逻辑上，LLM在足够强的提示词/过程工具的加持下，是足够仅靠语言来接受所有世界信息，并利用语言反作用于世界的。而仅仅把LLM当做AIGC的手段来用，多少有点暴殄天物了。
最近也开始有LVM（Large Vision Model）等直接多模态的模型，但是，个人感觉除了图片、音视频之外，可能并不会再有其他多模态的模型了，而且LVM也会想办法融合到LLM而不是独立提供服务。原因是文字是最大量存在的数据源，其他在信息量维度都是数量级的小于文字的，而且有效的表达力并不会超过文字太多。
LLM成本非常高，如果所有层级的信息都放给唯一大模型迟早破产，而且是不可能变好的那种，除非是顶级烧钱大厂（如头条）。
综上，LLM会大概率会成为一个计划、调度和整合的大脑，其他都是工具，人会作为纠错工具存在。

App的定位

由上面对LLM的认知，我猜App会有几个维度的变化：1. 继续以流量分发为基本逻辑，但这时分发的不仅是内容，更是逻辑；2. 充分利用设备能力，为LLM的信息收集服务；3. 极端低码，让UGL（用户生产逻辑）变成必有功能。
这里多说一嘴UGL，我自己瞎取的名字，但是是我认为的web3.0该有的含义。web1.0平台生产内容和逻辑；web2.0用户生产内容，平台只负责逻辑和内容生产工具；web3.0 应该是用户生产内容和逻辑，平台只负责平台运营和工具搭建。传统的逻辑生产工具其实就是低码和代码，前者很难做出复杂逻辑，后者很难推广。而LLM在两个维度能极大的简化生产过程：逻辑终结点可以以自然语言的形式描述，表达效率极大提升，可以看一下我的(github)[https://github.com/pouloghost/pseudo-gpt]；梳理逻辑流程对于麻瓜来说很麻烦，对于LLM来说通过对话把整个流程排布出来就很简单了。而逻辑抽象看其实就是这两个维度，我相当相信UGL会站起来，web3会站起来。
生态角度：头部流量App会进一步占有用户时间。其他功能类App或者垂类分发类App会被弱化成LLM的agent。会有真正的低码平台出现，让用户生产并分享逻辑（GPTs的进阶状态）。

App架构的变化

App定位的变化带来了架构的少量变化和具体能力的大量变化。
整体架构方面仍然可以保持portal-biz-common（有公司语义通用）-foundation（无公司语义通用）四层，且仍然能把业务粗暴的分为分发型和承载/能力型两个类型。
区别是LLM作为最核心的业务是分发型，会强迫让整体围绕着分发来组织，而不是之前非平台类（i.e.支付宝）App的功能、流程来组织。由于大量的路由、微服务的构建，路由（不同公司会放在biz最下或者common最上）会极为庞大，之前解耦带来的Android打包优势会不复存在，可能会像支付宝一样把直接按业务拆出来api-biz两个模块，来提速打包。

App具体能力

LUI

很火的一个词，Language UI。这个其实很简单，与IM逻辑基本一致的长链接+消息列。和普通IM比有几个不同点：

• 对于接收到的消息是要有完整修改能力的。修改后的内容是需要即时回传的。可能会以一个修改消息上传，也可能直接把assistant消息改了，这个得看模型响应
• 如果是多媒体内容，是需要有原始数据的（类比PS的psd文件）
• 由于中间有修改过程，整个聊天的存储是一个树形结构而非链式。进而，有概览整棵树的需求，快速的查找和跳转到节点
• 提示词模板，大部分非自由聊天的提示词都是模板。把随意输入变成填空，这时候普通的输入框并不靠谱，应该是一个特殊适配的填空输入UI。延伸出来，这里需要一套基于模板的渲染和拼装系统，注意这里要有多模态。见特殊的编辑器。

端智能

又一个很火的词，恰好之前也做过。如果能在端上把LLM的前几层给做了，对于大规模服务来说一定是有明显降本增效效果的。同时，在各种角度看，从多模态向文本转换的过程也都更适合在端上进行，甚至可以在转换后进行人肉纠错的hook。
那么端智能就又有几个核心能力需要在端上建立：

• 运行时，这个不熟，之前是魔改的TensorFlow-lite
• 模型本身的同步和下载。稍后资源离线包单独说
• 模型外围代码的动态化。稍后动态化单独说
• 推理调度。这个是之前的一个经验，当时的场景是模型并不作为核心业务执行，而是个锦上添花（屎上雕花）的功能，所以一定不能影响UI流畅度。所以需要一个推理调度功能，主要就是一套带优先级的多线程调度系统（Android不难，iOS见鬼）
• 训练调度。这个应该是普适的，设备上最终一定会开始跑离线数据的训练，哪怕只是利用模型对设备上的局部数据进行压缩。但是这种耗电、耗CPU的任务一定是要偷偷执行的，如果在用户使用时跑一定会被搞。所以会有一套设备使用状况监控（特别是电池）+后台调度的机制，跟推理调度不太一样。

动态化

别的App不做动态化其实无所谓，对接模型的App一定是主要能力动态化的。模型的能力迭代是有两部分组成的：基础模型/ft和prompt。我相信（无实证）大部分应用层都会加上基础prompt，而且会持续迭代场景化的prompt。参见我之前的prompt自动优化，prompt的迭代会是超乎想象的快。
那么对接提示词的客户端功能，不论是简单展示（见LUI），承接页还是感知能力，都是需要极为动态的，覆盖率方面能够跟得上prompt迭代（至少是不构成限制prompt迭代的阻碍，也不会因为版本兼容带来大量的accidental complexity）。
这里的动态化与旧有的RN、lynx不一样，需要更加关注的是动态提供平台能力和计算能力，相机、GPU、传感器等等，让逻辑动态化，而非让UI动态化，也不非常关心跨端一致。可能会比较接近hummer的实现原理。
当然动态化也会有离线包的一系列问题，统一到资源离线包说。

三方业务容器

本文的逻辑是利用LLM做AGI，信息收集和执行两步都是有强分发属性的，这时候不做三方业务就太浪费流量了。想象一下，如果LLM流量入口对话找吃的，只会找到饿了么的数据，美团是否会哭死（新时代的SEO），能不能在流量入口的信息源和落地页中可能是变现业务的关键点。
那么，像小程序、BFF一样的三方业务容器或者对接方案就一定是必不可少的。这里包括了前后端。
而大前端让三方业务顺利承接流量的就是小程序，当然也能是其他技术，但必须有以下几个特征：

• 加载性能足够好，排除原始的webview
• 动态化，如果能想办法和上面的内部业务动态化整合也是极好的
• 稳定性隔离，不能三方业务导致本App crash
• 资源隔离，完整的信息安全沙盒
• 能力支持，提供足够多的设备能力访问。这个讲道理应该和下面的微服务化整合到一起，在foundation甚至common层的能力都自动port出来

微服务化

或者说超级路由、客户端中台化，即所有业务都是组件、所有业务都可以被直接拉起。这里非常契合原教旨中台的定义，只不过这些能力不是为了让人类业务方来编排出新业务，而是为了让LLM有足够的agent可以调用。但是，这些能力一定还是有非LUI的入口可以进入的。
所以最大的挑战是对齐和管理三种调用方式的接口：端内代码强类型直接调用、跨端序列化调用和LLM agent声明调用。前两者做过靠谱的路由框架应该都知道咋做，第三个是新东西，不太能想到除了人肉维护或者LLM label的其他手段。试过GPT-4做代码label，效果还行。
还有一个和动态化一样差异。这里的服务同时包含了页面跳转和方法调用，甚至在环境感知维度更强调方法调用。
另外还有一个与普通路由相去甚远的变化：需要能唤醒其他App。大概逻辑是本地获取所有已安装App，发给服务端，服务端会根据版本号和数据库识别出所有可以调用的三方App，也作为agent的一部分灌给LLM。

资源离线

本来这是一个并没有很重要的能力。但是在LLM下，资源离线的使用场景非常广，值得单独强调一下。
标准的文件同步系统，需要关注：文件对外接口定义（毕竟大部分资源都是可执行模块）、兼容性、文件本身版本管理、下载、缓存、差量更新等。这里的接口自动抓取和匹配会是重点，因为所有动态化会更倾向于对接能力（方法调用）而不是页面（路由定义），前者的变化频率和兼容性都会比后者差很多。

低码/流程编排

这个之前完全没做过，所以简单查了一下。基本上现在的低码平台都是后端+web的，我坚定认为后面一定也会有App上完整的低码构建平台。因为手机是覆盖率最高设备，随着交互的简化和过程的智能化，小窗口也能做出大逻辑。可以类比剪映之于final cut。
低码这里核心有几个部分：

• 逻辑表示，如何把编辑好的保存下来，这个有不少服务端的开源/闭源库
• 版本管理，类似于git，应该开源库能包含类似功能（没细查，反正能序列化，大不了对序列化后的内容做git管理）
• 画板，用于展示和编辑整个流程，这里的展示方式应该和web不一样，应该更符合总分双屏这种适合小屏的结构
• 对话和preview，一定会有一个copilot来协助创建低码逻辑，同时快速验证某个逻辑块的正确性
• 能力节点，把微服务化部分的能力都开放供调用。而且，应该是会有一些UGL会被当做能力节点暴露出来，相对会复杂一些。包括出入参、接口说明、稳定性、兼容性等提供服务的常见问题。
• 执行，这个一定不发生在客户端，略过

特殊的编辑器

这个专指prompt格式化编辑器，基本可以认为是一个可视化的python f str。单独提出来说是因为这个东西大概会形成一个类似于markdown/富文本编辑器的一个面向LLM的文档标准，再叠加上合适的前后端服务。

总结

我认为的业务两个突出变化：LLM作为中心大脑来完成一个任务，成为流量分发核心，所有其他作为agent；UGL的真实落地，下一代互联网的真正到来。
为此，App会形成几种突出的能力：

• for LLM：LUI、端智能、动态化、特殊的编辑器
• for 分发：三方业务容器、微服务化
• for UGL：低码/流程编排

背景碎碎念

大概率这是两篇没实际意义的文章，一方面我并没有供职于一个能生长出这种业务形态的公司；另一方面大前端真的还有架构吗？还有，我已经快35了…不过出于一种强烈的FOMO感，我还是要记录一下，万一呢。