行业资讯
运行环境下沉不是把 agent 塞进浏览器——先把“门面”搬回用户家，云端只留动脑子的管家
上篇我们把那道账单之痛掰开揉碎讲了一遍一人一 podagent 全跑在云端用户在发呆内存也照样烧钱成本随人头线性往上涨收益却怎么都追不上那个斜率。管家 24 小时住在你家隔壁的酒店房间里房费你全掏——哪怕他大半天啥也没干就站在那儿端茶、递水、报菜名。那这一篇咱们卷起袖子干活讲讲这笔房费到底怎么省下来。我猜你脑子里可能已经蹦出一个词了把 agent 搬进浏览器。前面某篇咱们确实聊过这条未来路径——用浏览器里的虚拟机、WASM 这些技术把整个运行环境塞进用户的浏览器标签页云端趋近于零。那是终局是好东西。但我也把话说死过让大模型这颗大脑整个跑进浏览器眼下还不现实。所以这一篇要讲的不是激进地把整个 agent 塞进浏览器而是先做一件马上能落地、马上能省钱的务实动作——把 agent 那副身体里负责端茶递水的门面活儿搬回你自己家的设备上干云端那间酒店房间只留下动脑子的管家。这句话你先记住它是全篇的地基下沉 ≠ 把 agent 塞进浏览器。这是最常见的一个误解。很多人一听运行环境下沉脑子里立刻蹦出那个终极愿景然后摇摇头说太超前了做不了。其实真正务实的第一步比那个温和得多也早就有巨头替你走通了。一、先把误解拆掉下沉不是搬走大脑是搬走门面咱们把话说得再直白一点。一个 agent 能干活靠的不是它那颗大模型脑袋——大模型是无状态的你调一次它答一次它不记得你、不持有你的文件、也不能替你跑命令。真正让它活着、能干活的是那副常驻在云端、有状态的身体一个能读写文件、跑进程、连工具的运行环境。问题就出在这副身体太胖。你去拆这副身体会发现它干的活分两种一种是动脑子的活——理解你的意图、调度大模型、编排工具、决定下一步干什么另一种是门面活——把界面画出来、响应你的鼠标点击、渲染编辑器、摆布面板。动脑子的活非留在云端不可。它要连大模型、要跑真正的执行环境、要碰不能外泄的数据。门面活呢它压根不需要占着那间酒店房间。你想想你面前这块屏幕、你手上这个浏览器本来就有算力本来就闲着。渲染个界面、接个点击事件这些活儿你家的设备完全扛得住。凭什么要让云端那台按内存和时长收费的云主机专门腾出一大块地方来干画像素这种粗活所以下沉的动作说穿了就一句话不是把管家整个搬回你家住而是先把他手里的门面活分回来。管家继续留在酒店里动脑子端茶递水报菜名这些活儿交给你家早就买好的智能音箱去做。这一分工酒店房间立刻就能退档——从全功能套房退成只放一张办公桌的单间。房里不用再摆餐具、不用再腾出摆盘的台面只留一张桌子供管家坐着想事情。这就是下沉的第一步。它不碰大模型上不上浏览器那道难题它只动一件所有人都同意本来就该你自己扛的事门面。我再强调一遍因为太多人在这里拐错弯下沉不是让管家整个搬回家那是后期的愿景、现在做不了下沉是先把门面活分回来这个现在就能干。二、先拆清楚一个 Web IDE 其实是三个进程要搞明白哪部分能下沉、哪部分不能得先看看 agent 那副身体里界面这套东西到底是怎么搭起来的。现代的 Web IDE 框架比如 OpenSumi、Theia在架构上通常拆成三个进程据 OpenSumi 官方文档前端进程跑在浏览器里负责画界面、处理你的每一次点击和输入。这是纯粹的门面。后端进程跑在服务端的 Node 进程里负责文件、终端这些真正的系统能力。OpenSumi 官方还特意说明它这层后端是无状态的每个连接对应一个独立的容器连接之间严格隔离。扩展进程跑各种插件、扩展拥有完整的运行时权限。你看三个进程里只有前端进程是纯门面。它干的全是渲染和交互本来就该在浏览器里跑。那为什么很多产品把它也塞到云端去了呢因为有一类做法图省事直接把整个编辑器跑在服务端浏览器只当显示器。code-server 就是这类重后端的典型——渲染、交互、执行全在云端你的浏览器只负责把云端画好的像素显示出来跟看直播没啥区别。这么干确实简单但代价是云端要为每一个用户扛下全部的界面渲染负担。这个代价有多贵code-server 官方给出的单实例最低配置是 1GB 内存 2 个 vCPU据 code-server 官方文档。这基本就是一人一后端的地板价——你还啥业务都没干呢光是给一个人撑起一个能跑的编辑器后端1GB 内存就没了。一万个用户就是一万个 1GB 起步。下沉的核心动作就是把前端进程这块门面从云端后端里剥出来让它回到浏览器里原生地跑。这不是什么冒险的实验。OpenSumi 官方就提供了纯前端形态通过把文件映射成 HTTP 接口让前端脱离 Node 后端独立运行据 OpenSumi 官方文档。微软官方的 VS Code 网页版更是同一个思路——完全运行在浏览器里、零安装把编辑、浏览、语法高亮全放进浏览器沙箱里跑据 VS Code 官方文档。下沉不是激进设想是巨头早就走通的路。你现在打开浏览器就能用的那个网页版编辑器就是活生生的证据。三、下沉之后云端那间房里还剩什么把门面搬走之后云端的 pod 里还剩什么答案很干净只剩大脑和手脚。一个 agent 运行时内核——负责调度大模型、编排工具这是真正动脑子的部分一堆业务插件、skill、MCP 编排——负责具体场景的能力这是伸出去干活的手脚。界面渲染、编辑器交互、面板布局——这些门面活全交给用户的浏览器扛了。pod 从一个全功能工作站瘦成了一个决策内核。这个瘦身有多明显我给你一组量级示意——先声明这是某中小厂内部方案里的测算目标值不是已经跑在生产上的实测数据只用来让你对能瘦多少有个体感单个 pod 的内存从 1Gi 量级的水位往 256Mi 量级去压运行时镜像从 1.5GB 以上往 300MB 以内去瘦。以上均为该中小厂内部测算的量级示意非生产实测。内存降到四分之一镜像瘦掉八成——这不是抠抠搜搜省点边角料这是把身体的骨架整个换轻了。道理其实不难想pod 里不再跑那个沉重的界面渲染服务端进程常驻内存自然掉下一大截镜像里不再需要打包完整的编辑器服务端和一大堆前端静态资源镜像自然薄下去一大圈。你省的不是某一项开销你省的是每一个在线用户都要常驻的那台云主机的档次。回到管家那个比喻原来每个用户配一间全功能套房管家住着餐具、摆盘台、报菜名的地方样样齐全一晚房费高得吓人。现在管家只留一张桌子动脑子套房退成单间一晚房费直接掉一档。用户成千上万地涨你省下的就是成千上万间套房降成单间的差价。四、为什么这一步能撬动整条降本链到这儿你可能会说省点内存、瘦点镜像也就那样吧不。这一步真正的分量不在于它自己省了多少而在于它是整条降本链的第一块多米诺骨牌。pod 变轻这一下会顺着一条清晰的因果链把后面一连串省钱动作全带起来。我把这条链摆给你看单 pod 变轻内存降、镜像瘦→ 单节点能塞的 pod 变多密度涨→ 预热池终于养得起有了经济性→ 冷启动从被动扛变成主动预热掉→ agent 加载时间大幅缩短 → 用户等待变短体验涨。你注意这条链的方向最上游是资源开销最下游才是用户能摸到的快慢。想压下游那个让人抓狂的加载等待你绕不开先动上游的成本结构。而下沉让 pod 变轻正是那块最上游的骨牌。我挑最关键的一环给你讲透——预热池也就是 warm pool。所谓预热池就是提前起好一批空的 pod 在那儿待命用户请求一到直接从池子里拎一个绑给他省掉现场起 pod、拉镜像、装环境的那段冷启动时间。听起来是个好东西谁都想要。但预热池有个天生的经济学难题那些预热的 pod 是在空烧钱——没人用也占着内存待命。这里就是关键了pod 不减肥warm pool 就是个烧钱的摆设pod 减了肥warm pool 才养得起。你算笔账就懂了。单 pod 如果重达 1Gi你想维持一个像样的预热池那笔空烧的内存钱高到没法接受老板第一个把这个方案毙掉。可一旦单 pod 瘦到 256Mi 量级同样一笔预算能预热的 pod 数量就翻好几倍warm pool 一下子从奢侈品变成了日用品。这个把初始化挪到用户按下发送之前的思路不是我瞎想的云计算的巨头早就在这么干。AWS Lambda 为了解决冷启动专门推出了 SnapStart官方明确它能把启动从几秒压到亚秒级靠的正是提前用快照把内存初始化好、缓存住据 AWS Lambda 官方文档。他家的 Provisioned Concurrency预置并发更直白官方描述就是让函数保持初始化、随时待命、双位数毫秒内响应——本质就是花钱养一个预热池代价是你为闲着的并发也得付费据 AWS Lambda 官方文档。你品这个代价既然预热本身要花钱那被预热的那个单元当然越轻越好。这就又绕回来了——想让预热池划算先得让 pod 减肥。招式名字不同Serverless 叫 SnapStart、叫预置并发容器世界叫 warm pool骨子里是同一招。所以你看明白了吗下沉浏览器省的不是一笔孤立的内存钱而是把后面密度、预热、快启动这一整套省钱动作的地基先给打好了。地基不牢后面那些花哨的优化全踩空。五、配套工程手段地基打好了还得会砌墙下沉是主干但光把门面搬走还不足以让 pod 真正瘦到位、让 warm pool 真正转起来。它需要一整套配套动作打配合。我挑几个讲原理你不用会写代码听比喻就能懂。第一镜像分层瘦身。容器镜像是分层的好几个镜像可以共用底下同一层。你把不变的公共层基础系统、运行时和常变的业务层插件、配置拆开公共层被所有 pod 复用只有业务层单独存。这就像——别每个人都背一整套厨房出门公共的锅碗瓢盆放在共享厨房各人只带自己那袋调料包。镜像自然就薄了。第二进程瘦身。一个 pod 里往往塞了一堆进程。下沉把渲染服务端整个拿掉之后再对剩下的进程做收敛限制内存堆的上限、关掉用不到的遥测和自动更新、把启动时的安装动作提前到镜像构建期做完。进程少了、每个进程占的内存有天花板单 pod 的内存水位自然压下来。第三共享 sidecar。有些能力是只读的、无状态的、大家都要用的比如某些通用检索工具、模板库。与其每个 pod 各跑一份、白白占 N 份内存不如抽出来做成一个集群共享的服务所有 pod 通过网络连过去用。这就像——小区里不用每家都装一台净水器楼下装一台大的各家接根管子来用。注意用户的私有数据仍然锁在各自 pod 里隔离一点没破被共享的只是那些公共能力。第四warm pool 池化。前面讲过它的经济学了这里说落地的关键待命的空 pod绝不预先挂任何用户数据用户来认领的那一刻才给它打上用户标记、挂上这个人的数据卷、切换工作目录。这样一来速度是快了隔离性却一丝没损失——空 pod 是通用的认领之后才变成你的。第五上下文预烘焙。agent 启动时要加载一堆上下文角色定义、技能、工具配置。要是每次都全量拉启动就慢。预烘焙的思路是——把通用的、全站共享的上下文提前打进基础镜像启动时就地读把场景差异化的那部分放在共享存储里用到了再懒加载。这就像——常用的调料提前摆在灶台上冷门的香料搁储藏室用到再去拿。第六会话粘性。用户中途走开又回来要是每次都重新起 pod就白白吃一次冷启动。会话粘性靠一个用户到 pod的路由索引配上过期续期让用户重连时优先找回上次那个还活着的 pod直接接着用跳过全部加载链路。这也顺带解决了长连接的会话亲和问题——你重连回来找的还是原来那个管家他还记得你上一句说到哪。你数一下这六招没一招是在让大脑更聪明。它们全在干一件朴素的事让身体更轻、让待命更省、让重连更快。省钱这件事从来不是靠某个绝招而是靠一堆不起眼的减法叠出来的。六、代价与边界下沉不是免费的午餐任何架构选择都有代价把话说全才是负责任的科普。下沉这一招也有它扛不住的地方。第一它依赖用户的浏览器和设备。你把一部分门面负担甩给了用户的浏览器那老旧设备、低端机器上的体验就要打折。渲染这活儿本来云端替你扛了现在压到用户设备上设备不给力界面就卡。举个具体的有些高级渲染要靠 WebGPU 这种较新的浏览器能力而它的浏览器支持率目前也就七成上下据 caniuse 公开统计剩下那三成用户的设备你得准备好降级方案伺候。天下没有免费的下沉——你省了云端的钱就得把一部分算力压力转给用户的设备。第二前端复杂度上升了。门面活儿搬回浏览器原生跑意味着你的前端不再是显示云端画好的像素那么省心它得自己扛起渲染、交互、状态管理一大摊子。工程的复杂度从后端挪了一部分到前端——这活儿的总量没凭空消失只是换了个地方待着。第三不是所有能力都能下沉。这条最要命你必须认清。门面渲染、交互能下沉但真正要跑命令、编译代码、执行不可信程序的那些重活下不了浏览器。微软官方就白纸黑字写着VS Code 网页版里终端和调试器是不可用的因为你没法在浏览器沙箱里编译、运行、调试一个原生程序据 VS Code 官方文档。这就把话说圆了下沉下沉的是门面——渲染和交互身体的那双手脚——真正的执行、终端、系统能力该留云端还得留云端。谁要跟你说把整个 agent 塞进浏览器就完事了你就拿这条反问他那终端和调试器你怎么办第四这只是第一步不是终局。下沉门面能让你马上省钱、马上把地基打好但它不是这条路的尽头。它是前期到中期的一步跨越后面还有更远的风景。这就引出最后一段——它到底在整条演进路上站在哪个位置。七、演进路径为什么下沉是通往终局的务实第一步“运行环境下沉不是一个一步到位的开关而是一条前中后三段的演进曲线。看懂这条曲线你才真正明白为什么这一篇讲的东西是第一步”。前期——云端全套。起步生产阶段渲染在云端pod 里装着 IDE 服务端 agent 内核 插件样样齐全云端负担最重。这就是上篇讲的那个全功能套房的老样子。中期——渲染下沉浏览器。也就是这一篇从头讲到尾的那一步把渲染层搬进用户浏览器云端 pod 只留 agent 内核加插件大脑加手脚。云端负担降到中等warm pool 养得起了冷启动被预热掉了加载快了。后期——整个 agent 进浏览器。借助浏览器里的 WASM 虚拟机这类技术把整个 agent连内核带执行都塞进浏览器云端趋近于只剩静态托管加一个大模型网关。这就是前面某篇聊过的那个终极愿景——云端零运行时、冷启动趋近于零。这三段有一个严格的先后顺序不能跳。中期能不能启动前提是 pod 侧的 agent 内核先得瘦到能被 warm pool 经济地预热。你想想如果内核本身还很胖就算你把渲染搬走了pod 依然重、密度依然低、预热依然养不起——中期就是空中楼阁。所以下沉门面 顺手瘦身这件事本身就是中期能站稳的前置作业。而后期那个整个 agent 进浏览器的终局得踩在中期的肩膀上。你连门面都还没搬明白、pod 都还没瘦下来就想一步跨到整个 agent 进浏览器那是好高骛远。所以你看清楚了下沉门面不是终点是通往终局的务实第一步。它的价值不在于它自己有多惊艳而在于——它是那条演进路上你现在就能迈、迈了就有回报、还能给后面所有步骤铺好路的第一步。先把门面搬回家你才有资格谈把整个 agent 搬回家。八、写在最后咱们把这一篇的心思收一收。上篇讲的是病根——一人一 podagent 全跑云端用户在发呆也烧钱。这一篇讲的是第一味药——把门面搬回家云端只留动脑子的管家。我知道很多人一提降本第一反应就是把模型换小一点、把大脑弄聪明一点。可你回头看这一整篇从头到尾没动过大脑一根汗毛。真正把成本压下来的是一件特别朴素的事别让那个只管画界面的显示器也占着一间按内存收费的云端套房。所以几句话你带走就够了——下沉不是把 agent 塞进浏览器是先把不该占酒店房间的门面活儿送回家。把整个管家搬回你家住那是后期的愿景、现在做不了把他手里端茶递水的活儿分回来这个现在就能干、干了就省钱。省钱的第一步从来不是让大脑更聪明是别让显示器也住着套房。大模型该多聪明还多聪明你要动的是那副胖到离谱的身体。pod 不减肥warm pool 就是个烧钱的摆设pod 减了肥warm pool 才养得起。这是下沉是预热的前置最凝练的一句——不是先追速度而是先减身体。下沉省的不是一笔钱是把后面所有省钱动作的地基先打好了。密度、预热、快启动全踩在pod 变轻这块地基上。地基不牢花哨的优化全踩空。下沉的是门面不是手脚。渲染和交互能回家真正跑命令、跑执行的重活该留云端还得留云端——这是它的边界也是它的诚实。先把门面搬回家你才有资格谈把整个 agent 搬回家。它不是终点是通往终点那条路上你现在就能迈的第一步。一台按内存和时长收费的云主机最不该干的事就是替你的浏览器画一辈子界面。把门面还给浏览器把动脑子留给云端——这一步迈出去账单才第一次开始听你的话。关于 ArchAIHarness这篇文章是「看懂 AI 与智能体」专栏的一部分由ArchAIHarness持续输出。ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产主张架构师定义秩序AI 在秩序中生长。人立法AI 执行体系审计。如果你也希望 AI 在明确的架构边界内协作而不是在混沌中碰运气欢迎到 GitHub 上看看我们在做什么组织主页github.com/ArchAIHarness — 了解完整理念与资产全景本专栏zhuanlan-ai-and-agents— 所有文章的源码与发布记录实践指南docs— 架构哲学、工程方法和落地指南开源工具agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools工程样例framework— DDD AI 协作的工程底座展示如何在开发中融合 AIEngineered by Architects · Empowered by AI · Audited by Discipline
郑州网站建设
网页设计
企业官网
)
![[具身智能-634]：Python 封装的地平线 VIO 多媒体库：libsrcampy库详解](http://pic.xiahunao.cn/yaotu/[具身智能-634]：Python 封装的地平线 VIO 多媒体库：libsrcampy库详解)
