面向LLM的App架構—

這是兩篇面向LLM的大前端架構的第一篇，主要寫我對LLM業務的認知以及由此推演出的大前端架構。由于我是客戶端出身，所以主要以客戶端角度來描述，并不影響對前端的適用性。

對LLM的認知

基于Google對AGI的論文，AGI或者LLM一定會朝著在決策過程中越來越重要的方向發展。任務過程可以簡單抽象為目標設定、信息收集、任務拆分、retro、執行。目前成型的LLM應用，主要還是在任務過程的某幾個點作為最葉子的工具存在的，后續一定會向著主導完整過程的方向走。
曾經有個大佬說過，LLM是對世界的壓縮。還有另一個大佬說過，語言可以完整描述世界。那么邏輯上，LLM在足夠強的提示詞/過程工具的加持下，是足夠僅靠語言來接受所有世界信息，并利用語言反作用于世界的。而僅僅把LLM當做AIGC的手段來用，多少有點暴殄天物了。
最近也開始有LVM（Large Vision Model）等直接多模態的模型，但是，個人感覺除了圖片、音視頻之外，可能并不會再有其他多模態的模型了，而且LVM也會想辦法融合到LLM而不是獨立提供服務。原因是文字是最大量存在的數據源，其他在信息量維度都是數量級的小于文字的，而且有效的表達力并不會超過文字太多。剛寫完就被打臉，gemini就是硬靠有錢把圖片、音視頻和文本做了個真多模態，有錢真好。
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會被當做能力節點暴露出來，相對會復雜一些。包括出入參、接口說明、穩定性、兼容性等提供服務的常見問題。
執行，這個一定不發生在客戶端，略過