企业官网建设流程全解析

上篇我们把那道账单之痛掰开揉碎讲了一遍：一人一 pod，agent 全跑在云端，用户在发呆内存也照样烧钱，成本随人头线性往上涨，收益却怎么都追不上那个斜率。管家 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 搬回家。

八、写在最后

咱们把这一篇的心思收一收。

上篇讲的是"病根"——一人一 pod，agent 全跑云端，用户在发呆也烧钱。这一篇讲的是"第一味药"——把门面搬回家，云端只留动脑子的管家。

我知道很多人一提降本，第一反应就是"把模型换小一点、把大脑弄聪明一点"。可你回头看这一整篇，从头到尾没动过大脑一根汗毛。真正把成本压下来的，是一件特别朴素的事：别让那个只管画界面的显示器，也占着一间按内存收费的云端套房。

所以，几句话你带走就够了——

下沉不是把 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 协作的工程底座，展示如何在开发中融合 AI

Engineered by Architects · Empowered by AI · Audited by Discipline