企业官网建设流程全解析

说实话，第一次在架构会上听到"每人一台不关机的云电脑"这个方案时，我差点以为团队打算退回九十年代的胖客户端时代。我们好不容易把单体应用拆成 Web 集群，搞无状态、搞负载均衡、搞会话外置，怎么 AI 一来，反而要给每个用户单独开一台常驻电脑？后来我把 Grok Bot 这类 Agent 部署进一个独立的 Docker 容器里，连续跑了两三个月业务，才慢慢想明白：不是架构倒退，而是我们对"一台电脑"的定义变了。这篇东西想用一次真实选型的视角，把 Web 集群、云电脑、Agent 架构放在一起聊聊，包括我踩过的坑和最终的判断。

1. Web 集群和云电脑，我为什么要把它们放一起聊

1.1 先讲清楚：传统 Web 集群到底解决什么问题

传统 Web 集群，说人话就是：一个业务系统不再只跑在一台机器上，而是跑在 N 台机器后面，前头挂一个网关（比如 Nginx 或云负载均衡）统一分发请求。浏览器或 App 发起请求，网关看哪个实例空闲就扔给谁，每个实例本身尽量做到无状态，数据库、缓存、对象存储全部外置，任何一台机器挂了，其它机器继续扛流量。

这套架构解决的核心问题只有两个词：高并发和容灾。随便一个线上系统，单机在峰值时刻是扛不住的，集群可以横向加机器；单机故障会导致业务中断，集群把故障范围缩小到一个实例的粒度，用户几乎无感知。我经手过的一套业务系统，日活在几十万量级，靠的就是前面 Nginx 后面 8 个应用实例的做法。没有集群，任何一个发布动作、任何一台物理机抖动，都可能变成线上事故。

但所有好处都有代价。集群最大的代价是：状态不能留在服务进程里。登录态要放 Redis，购物车要放 Redis，用户上次操作到哪一步也要从数据库里捞。每次请求都要把状态"取出来、用完再放回去"，这就逼着应用代码写得非常"干净"——不存任何本地记忆，不依赖本机文件，更不能在进程里悄悄保存什么进度。

这套模式在交互简单、单个请求就能完成任务的业务里非常顺。可一旦面对的是"一个需要连续工作几小时、还要记住前面做了什么的 AI 任务"，就会非常别扭。我在接入对话型 Agent 时感受特别明显：用户跟机器人聊到第 20 轮，系统还在反复从数据库里把整段历史拉出来，再塞给模型，就像每次对话都要先重新读一遍聊天记录才能接上话。

1.2 再说"云电脑不关机"：到底是怎么个"一人一台"

云电脑不是新概念，广义上讲就是 DaaS 桌面即服务。微软有 Windows 365，各大云厂商也有云桌面产品。核心思路是把你的桌面环境放到云端，本地只留一个显示客户端，数据和算力都在远端，换台设备也能接着干活。

但最近讨论的热点不太一样。很多技术团队把"云电脑"做成了 Docker 里的常驻个人工作空间：给每个开发人员、每个 AI Agent、甚至每个重度业务用户分配一个独立容器，里面预装好工具链、模型配置、数据卷，容器一直跑着，不关机、不清空、随用随连。这就形成了标题里说的"每人一台云电脑"。

为什么会有这种方案冒出来？核心就两个需求：环境隔离和持久化。团队里同时跑三个 Agent，每个 Agent 都有自己的记忆库、工具目录、依赖版本，如果全部塞进同一个集群进程，资源互相干扰、上下文串台、依赖冲突都是很真实的问题。一人一个容器，边界就非常清晰，想折腾就折腾，搞挂了重建一个也不影响别人。加上现在 AI 任务动不动就是几小时的长流程，容器常驻让"停到哪就从哪继续"变成了默认可选项。

2. 一次基础设施选型的核心差异对比

2.1 Web 集群像"共享食堂"，云电脑像"独立小灶"

我习惯把这两种模式类比成食堂和厨房。Web 集群是共享食堂：一口大锅做饭，来多少人做多少份，高峰期多开几个打饭窗口，也就是横向扩容。食堂的好处是资源利用率高、成本摊薄，坏处是每道菜都必须标准化，不能给某个人单独定制；一个人吃坏肚子还可能连累整个后勤团队。

云电脑是独立小灶：每个人有自己的灶台和锅，菜品随便定制，节奏自己掌握。代价也很明显：厨师、灶台、食材都是独立占用的，资源利用率取决于个人使用习惯，整体成本上去了。这种取舍在技术圈并不陌生——本地开发环境独立还是统一测试环境，两边常年吵架。独立环境舒适、安全、互不干扰，统一环境高效、可控、省钱，没有绝对的对错，只有任务类型适不适合。

放到 AI Agent 场景里，你会很快发现"独立小灶"的价值被放大了。Agent 不是一次请求就结束，它要在一个环境里连续决策、反复调用工具、不断积累中间产物。共享食堂的无状态设计让每一步都变得很累，独立小灶反而天然适配。

2.2 从状态、扩展、故障域看两种架构的取舍

看状态管理。集群拼命把状态外置，云电脑天生把状态留在本地。Agent 的长会话、创作中间产物、已下载的数据集，放在本地卷里直接读，少了一堆网络往返和序列化开销。这是云电脑模式让我最服气的地方。

看扩展方式。集群是按流量横向伸缩，峰值加实例，低谷缩回来；云电脑是按人头或任务数扩展，来一个 Agent 开一个容器，数量可控但每一份都是独立资源。从运维视角看，前者的扩容是自动的、弹性的，后者的扩容是手动的、有规划成本的。

看故障域。集群的单实例故障会被自动吸收，用户无感；云电脑的单容器故障只影响对应个人，但需要重建机制和备份策略。换句话说，集群把"故障恢复"做进了系统里，云电脑则把"故障恢复"留给了运维流程。没有谁绝对更优，只是责任落点不同。

2.3 一张表看清差异背后的代价

看完这张表就明白，这两种架构根本不是替代关系，而是解决不同侧面的问题。Web 集群服务的是"海量短请求"，云电脑服务的是"少数长任务"。以前 AI 还不流行，长任务占比低，集群的劣势不明显；现在 Agent 爆发，长任务成了常态，云电脑模式自然就被推到台前了。

3. 实操：用 Docker 搭一台不关机的个人云电脑

3.1 选型前先想清楚三件事

第一件事：你的"云电脑"是给人看的还是给程序跑的。如果是给人远程办公，需要一个完整的桌面环境，推荐用 LinuxServer 的 Webtop 这类镜像，里面自带浏览器、文件管理器、终端，通过网页就能访问。如果是给 Agent 跑，就不需要桌面，一个 Linux 环境加 Python/Node 运行时、工具链、持久化目录就够，省掉大量图形环境开销。

第二件事：要不要 GPU。如果 Agent 调用的是 Grok Bot 这类云端模型的 API，容器本身只需要发 HTTP 请求，不消耗 GPU。如果你打算本地跑开源模型，就得考虑 GPU 直通或者单独搭推理服务，再让容器走网络去调。我一般建议先把模型推理和 Agent 执行拆开：推理放 GPU 集群，Agent 执行放普通容器，两边都轻松。

第三件事：数据放哪里。Docker 容器本身是"用完即弃"的，镜像层一更新，容器里写的文件可能就没了。所有 Agent 的记忆库、配置、日志、输出产物，都必须放到数据卷里，映射到宿主机目录。这项不做，后面全是坑。

3.2 Docker Compose 搭建常驻云工作环境

我实际用的是一套很简单的 Compose 配置，给每个 Agent 一个 code-server 环境加一个专用数据卷。下面这个例子可以直接抄：

services: agent-workspace: image: linuxserver/code-server:latest container_name: agent-workspace restart: unless-stopped volumes: - /srv/agent-workspace/projects:/config/workspace - /srv/agent-workspace/agents:/config/agents ports: - "8443:8443" environment: - PUID=1000 - PGID=1000 - TZ=Asia/Shanghai - PASSWORD=${WS_PASS} logging: driver: json-file options: max-size: "50m" max-file: "3"

image 用的是 LinuxServer 的 code-server，它在容器里封装了一个浏览器可访问的 VS Code 环境，适合远程开发。volumes 把工作目录和 Agent 目录拆开挂载，projects 放业务代码，agents 放记忆库和工具脚本，备份时按目录处理就行。ports 把容器端口映射到宿主机，外部访问统一走这个入口。PUID 和 PGID 要设成宿主机上对应用户的 UID/GID，避免容器内写出来的文件在宿主机上权限错乱。这些都是实际跑下来的经验，不是文档里会特意提醒你的东西。

3.3 restart、数据卷、资源限制这几个参数一定别搞错

云电脑的核心就是"不关机"，所以 restart 策略必须选对。Docker 有几种 restart 策略：no 是不管，容器崩了就崩了；on-failure 是遇到错误退出才重启，适合一次性任务；unless-stopped 是除非手动 stop，否则自动重启，这是最推荐给常驻工作空间的选项；always 是无论什么原因停了都拉起来，如果容器一直崩溃就会反复重启，反而拖垮宿主机，不推荐给日常环境。

数据卷方面，我建议按职责拆开挂载，比如 memory、workspace、logs 各挂一个目录。这样你的 Agent 记忆不会因为代码目录清理被误删，日志轮转和容量管理也更好做。不要把整个根目录挂进去，会让容器的文件系统边界形同虚设。

资源限制是很多人忽略的点。如果不对容器设置 CPU 和内存上限，一个常驻容器的内存泄漏就可能把宿主机拖垮。我见过一个 Agent 在递归任务中把内存吃满，宿主机上其它所有容器一起卡死，最后只能物理重启。设了限制之后，单个容器再出问题也只是它自己被杀掉，不会殃及整个工作区。

deploy: resources: limits: cpus: "2.0" memory: 4g reservations: cpus: "0.5" memory: 1g

再加上健康检查，让编排工具知道容器是活着的还是假死：

healthcheck: test: ["CMD", "curl", "-fs", "http://localhost:8443/healthz"] interval: 30s timeout: 5s retries: 3

这些配置加完，一台真正意义上的"不关机云电脑"就跑起来了。后面要做的就是定期进去看看日志、清理磁盘、更新镜像。

4. Agent 架构实战：Muse、Grok Bot 为什么会选择"一人一机"

4.1 Agent 的四个特征，决定了它吃不下无状态集群

我把当前主流的 Agent 拆了一下，发现它们有四个共同特征，每个特征都和传统集群的无状态设计直接冲突。

第一个特征是长记忆。Agent 要能记住前面聊过什么、做过什么决策，跨会话甚至跨天保留上下文。集群模式把这部分丢给数据库，每次都要全量拉取。第二个特征是工具调用。Agent 要能执行搜索、跑脚本、读写文件、调 API，这意味着它必须有一个稳定可控的执行环境。第三个特征是自主决策。Agent 会自己决定下一步做什么，可能在某个步骤等待外部条件，再继续推进，这本质上是异步长流程。第四个特征是常驻监听。消息驱动、定时触发、Webhook 推送，要求 Agent 进程长期在线。把这四点拼在一起，结论很清楚：Agent 需要的是一个"有状态、可长时间不退出、随时访问本地工具"的执行环境。

传统 Web 集群擅长的是无状态、短请求、高并发。把 Agent 硬塞进集群里，就等于要求一个需要连续思考和行动的工作者，每次开口说话前都要去档案室重新翻一遍自己的笔记。能跑，但跑得非常累。

4.2 场景一：Grok Bot 这类对话 Agent 的长会话与记忆

Grok Bot 这类对话型 Agent 在团队里的典型用法是接进内部系统，当客服助手或者知识问答机器人。之前我们把它的执行逻辑部署在 Web 集群里，问题很快暴露：每来一条消息，负载均衡可能把请求转发到任意一个实例，实例必须先从数据库把整段会话历史捞出来，再拼上工具执行结果发给模型，处理完还要把新的上下文写回去。

看起来只是多几次读写，但会话一长，开销变得非常大。一个跑了 200 轮的长会话，每一轮都要重建全部上下文，响应延迟越来越明显。后来我把 Grok Bot 的执行进程迁到一个常驻容器里，上下文直接留在进程内存中，工具执行结果写本地文件，整个流程从"每轮重新读历史"变成"接着上次的状态继续走"。在我们团队里的压测里，同样的长会话，平均每轮响应耗时大概降了四成。这个数字跟具体模型和网络环境有关，但趋势非常明确：有状态执行体放在有状态环境中，省掉的可不只是几次数据库查询。

4.3 场景二：Muse 这类创作 Agent 的多步工具调用

另一类 Agent 是创作型，我用 Muse 来代称手头那个负责生成文案、配图和素材的工作流 Agent。它和对话 Agent 不同，更偏多步工具流：理解需求、生成初稿、调渲染工具、人审反馈、再修改、输出成品。每一步都会产生中间文件，每一步的结果都影响下一步的方向。

这种流程丢到集群里会非常难受。中间产物必须传到对象存储，下一步又从对象存储拉回来，一次次上传下载不仅慢，还容易遇到路径错乱、过期清理、权限不对的问题。放到一台"云电脑"里之后，Muse 的每一步工具调用直接操作本地目录，渲染出来的临时文件不需要上传下载，断了还可以从本地缓存继续跑。多步工作流一下子变得非常顺。

我的感受是：创作型 Agent 比对话型 Agent 更依赖本地环境，因为它的"状态"不只是一段文字历史，还有大量二进制中间产物和目录结构。这些东西放对象存储能用，但效率、成本、调试体验全都不好。给 Agent 一台自己的电脑，等于把它的工作台真正固定下来。

4.4 但集群并没有消失：网关和调度还在

看到这里，千万别急着把 Web 集群拆了。云电脑只是 Agent 的执行层，它背后的基础设施依然是集群形态。请求入口需要 API 网关，任务分配需要消息队列，模型调用需要集中转发，向量检索需要专门的存储服务，这些全部还是 Web 集群那一套架构。

我把这个理解成"重心迁移"：不是用云电脑替代集群，而是把原来所有逻辑都塞在集群里的做法，改成集群负责调度和传输，Agent 本体住进各自的云电脑。集群仍然是底座，但它不再扮演"每个请求的执行者"，而变成了"连接器"和"调度器"。这样既保留了集中管理的效率，也给了 Agent 独立空间。

5. 云电脑日常运维的常见问题与排查速查

5.1 从"WPS 云盘+网盘两个图标"看本地与云端的边界

最近网上有个热词挺有意思："我的电脑有 WPS 云盘图标还有 WPS 网盘图标"。乍一看像产品设计事故，但细想正好是"云电脑"话题的民间版本。一个图标是本地客户端入口，把云端文件同步到本地目录；另一个是纯网页入口，文件只在云端。两个图标并存不是功能重复，而是本地与云端的边界正在被重新划分：频繁编辑的文件放本地缓存，偶尔访问的文件直接走云端。

云电脑也是同样的道理。Agent 的核心逻辑长期跑在云端容器里，但模型调用又去访问集群里的推理服务；开发人员的编辑界面在本地浏览器，实际文件却在云端数据卷。你不需要在"本地"和"云端"之间二选一，而是把每层数据放在它最合适的位置。理解了这一点，你再看云电脑架构就不会觉得它是倒退，它只是把边界画得更细了。

5.2 四个高频故障和对应排查思路

常驻容器跑久了，问题不会少。我整理了几个出现频率最高的情况：

日志轮转这件事特别容易忽略。容器默认的日志驱动不限制大小，一个天天打印日志的 Agent 一个月能吃掉几十 GB。我习惯在 Compose 里显式配置日志选项：

logging: driver: json-file options: max-size: "50m" max-file: "3"

5.3 我的几套小习惯

用常驻容器当云电脑，最怕的是环境不可恢复。我现在的习惯是：每个工作空间目录下都放一个 README，写清楚创建时间、用途、依赖版本、恢复步骤；关键数据每天做一次离线快照，哪怕只是把目录打包传到另一台存储机器；遇到需要维护的情况，先 stop 再观察，不要随手 rm，万一数据没挂好还有机会救回来。

还有一条心得：给 Agent 的容器环境尽量保持简单。我看到很多团队在云电脑里装了一堆 GUI、数据库、浏览器，看起来啥都能干，实际维护成本直线上升。Agent 需要什么就装什么，目录越干净，备份和迁移越轻松。

6. 我的结论：不是倒退，是重心迁移

6.1 为什么我最终判定这是"进步"

回到标题的问题：从 Web 集群到每人一台云电脑，是进步还是倒退？我的答案很明确：是进步，但进步的不是"更多机器"或者"更多花哨功能"，而是我们对架构分工的理解更细了。

架构演进从来不是单箭头。大型机时代是集中，PC 时代是分散，云计算时代又集中，现在个人云电脑又是一轮分散。但每一轮"分散"都不是回到原点：云电脑有集群的网络能力，有容器的隔离能力，还有本地的持久状态。它站在了前面所有层次的肩膀上，这不是回潮，而是重新分工。

Web 集群没有过时，它退到了更合适的位置——基础设施层。云电脑也没有取代集群，它补上了集群在"长任务、有状态、个体化环境"上的短板。两者配合，才是 Agent 时代比较务实的架构形态。

6.2 给正在做架构选型的人三个建议

第一，别一上来就全员上"一人一机"。先把任务分类：短请求、无状态、高并发的走集群；长会话、有状态、多步工具的走云电脑容器。混着用比站队更重要。

第二，资源限制和监控必须前置。一个没人看管的常驻容器就是潜在的定时炸弹，CPU、内存、磁盘、日志全部设上限，出问题要有告警。

第三，把恢复能力当一等公民。独立环境容易建，也容易丢，重建流程一定要脚本化、文档化。没有恢复方案的云电脑，只是另一个手动维护的服务器。

我个人现在的架构就是这样：底座是一套 Web 集群，负责网关、调度、模型转发、存储；上层是一排常驻容器，每人一个、每个 Agent 一个。集群管集中和效率，容器管独立和稳定，两者互相兜底。下次再有人问"这是不是回到过去了"，我的回答是：不是回到过去，是过去欠的债，现在用更细的颗粒度来还。