企业官网建设流程全解析

2026年，我干了一件朋友圈里被问得最多的事：把一只正在迭代的 AI Agent 从云服务器搬回了家里那台吃灰的台式机上托管。原因很现实——云主机的账单越滚越大，而这只 Agent 跑的全是私有数据和长时间挂机的任务，放本地反而更便宜、更顺手。但搬回家之后真正的麻烦才开始：人不在家，怎么从外面连上这只 Agent？我先后把 UU远程终端、CLI 远程调用、端口映射、网络代理四套方案都过了一遍，折腾了将近两个周末，最终跑出一套稳定能用的组合。这篇文章就把这段实测完整记录下来，给同样动了"把 AI Agent 托管在家里电脑"念头的人做个参考。

1. 为什么把 AI Agent 放家里而不是上云：算一笔实在账

1.1 云主机账单与本地成本的剪刀差

先算钱。我那只 Agent 是 FastAPI + LangGraph 搭出来的，日常挂 2 个常驻工作流，白天跑 3 轮定时任务。放在云上的时候，8 核 16G 的轻量云主机一个月三百多，加上对象存储和 API 调用，一个月五百打底。而且 Agent 经常要跨多个工具调用，日志和中间结果都堆在磁盘上，云盘的存储费用像漏水一样，看着不多，月底一拉账单全是碎账。

搬回家之后，机器的边际成本基本为零。家里那台旧台式机是2020年配的，折旧老早走完了。功耗我实测过，整机待机 55W，满载 150W 左右，按一天平均 8 小时运行算，一个月电费不超过三十块。三十块对三百块，这就是我把 Agent 下班回家的最原始冲动。如果你手头刚好有一台旧电脑，这笔账会比我算的还要划算，因为连硬件采购都省了。

1.2 数据不出门与调试自由度

钱只是其一，更打动我的是数据。Agent 会读我本地的代码仓库、个人知识库文档，有些 prompt 里就带着业务敏感信息。放在云主机上，总有一种数据睡在别人机房的不安感。在本地跑，至少磁盘是我的，备份是我自己的，想删就删。知识库里的那些文档片段，也再也不用走一遍"上传到对象存储再下载回本地"的弯路。

调试自由度也完全不一样。云上跑 Agent 出了问题，我得登上去看日志、改代码、重新部署，一顿操作至少十分钟。本地跑，我直接在 IDE 里打断点，改完重启容器，前后不到一分钟。Agent 开发本来就是高迭代频率的活，这种"改完就能立刻看效果"的体验，一天能省下一两个小时。尤其是我经常要调 LLM 的工具调用逻辑，本地改 prompt、试参数，反馈链路短得多了。

1.3 哪些 Agent 适合在家跑，哪些不适合

不是所有 Agent 都适合搬回家。我的判断标准很简单：看它的任务是不是长时、低并发、重本地数据。

适合在家跑的，我总结了四类：

• 定时型 Agent：每天固定时间抓网页、汇总资讯、生成日报，这类任务对延迟不敏感，慢几分钟无所谓；
• 个人助理型 Agent：管日程、筛邮件、跑本地知识库问答，数据留在本地价值最大；
• 开发辅助型 Agent：像 codex CLI 这类能帮忙改代码、跑测试的命令行 Agent，配合 IDE 用非常顺手；
• 内容生产型 Agent：处理本地文档、批量生成文案初稿，跑的时候占满 CPU 也不影响别人。

不适合在家跑的也有几类：面向用户的高并发 API 服务，家里宽带的上行和稳定性撑不住；需要对外提供 80/443 端口的 Web 应用，家庭宽带多数被运营商封了常用端口；对可用性要求高的线上业务，家里一断电就全崩，扛不起这个责任。

顺带回应一下热搜里总有人问的"个人用 AI Agent 可不可以做期货交易"：技术上当然可以，把行情接口和数据源接进去，Agent 按策略出信号甚至自动下单都能做到。但我的建议是先跑模拟盘，而且不要把交易密钥直接写在 Agent 的配置文件里。这类涉及真金白银的自动化，安全等级要按生产系统来对待，本地托管只是第一步，后面的鉴权、审计、故障回退一样都不能少。

2. 托管前的三条线：硬件、系统、网络一次理清

2.1 硬件底线：内存比显卡更重要

托管之前先盘一下机器。我的配置是 i5-10400 + 32G 内存 + 512G SSD，无独显。实测下来，纯文本类的 Agent 对 CPU 的要求远没有对内存那么高。

Agent 吃内存主要因为两个原因：一是大模型的 context window，十几个工具的对话上下文全堆在内存里，一次长对话下来几个 G 就没了；二是向量数据库和 embedding 索引，我挂了 2 万多个文档片段做本地知识库，启动后常驻吃接近 4G。所以内存 16G 是底线，32G 会比较舒服。硬盘上建议留 100G 以上的剩余空间，用来放模型缓存、向量库和日志，日志这东西不清理的话涨起来比你想的快。

如果你要跑本地模型推理，那显卡另说。但纯走 API 的 Agent，CPU 完全够，别为了托管 Agent 特意买显卡，后面你会发现瓶颈根本不在算力，而在内存和网络的稳定性。

2.2 系统与运行环境：Docker 编排 + 进程守护

系统我用的是 Ubuntu 24.04 LTS，环境统一走 Docker Compose。为什么强调 Docker？因为 Agent 的依赖链太碎了——LangGraph、向量库、Redis、Playwright 无头浏览器，裸机装一遍少说要踩两三个版本冲突的坑。Docker 隔离好、迁移方便，而且配合restart: always策略，断电重启后能自动把容器拉起来。

如果你的 Agent 是 Rust 写的，那就更省心。基于 Rust 的 Agent 编译出来是静态二进制，直接扔到 systemd 里跑，内存占用比 Python 那套低一个量级，很适合家用机长期挂机。我后来有个小工具就用 Rust 重写了，常驻内存从 800M 降到 80M，效果立竿见影。

我另外还写了一个简单的健康检查脚本，放在 cron 里每 5 分钟执行一次，curl 本地的 Agent 端口，连续 3 次不通就自动重启对应容器。这个脚本看起来土，关键时刻比什么监控系统都管用，因为家用场景根本不缺复杂的监控能力，缺的是"断电后没人手工干预也能自己活过来"的兜底机制。

2.3 家庭网络体检：公网IP、上行带宽、动态IP三件事

在考虑远程方案之前，先花半小时给家里的网络做个体检，三个必查项：

1. 有没有公网 IPv4：登录光猫的管理页，看 WAN 口拿到的 IP 是不是 100.64.x.x 这种 CGNAT 段。如果是，那路由器端口映射这条路基本走不通，只能靠 UU 远程终端这类免公网方案；
2. 上行带宽够不够：用测速工具测一下上传，如果上行只有 5Mbps，那远程传文件会非常痛苦。我实测家里上行 30Mbps，跑 Agent 的文本响应绰绰有余；
3. IP 动不动变：看拨号记录。PPPoE 一般 48 小时强制重拨一次，IP 会变。这意味着所有依赖固定 IP 的方案都要加一层 DDNS，或者选能自动更新的穿透工具。

这些检查做完，你才能知道自己到底适合哪条远程路线。我见过不少人跳过这一步，买了个带端口映射的路由器折腾半天，最后发现运营商压根没给公网 IP，白费一晚上。

3. 四个远程入口怎么选：UU远程终端、CLI、端口映射、反向代理

这一章是全文的核心。我分别把 UU远程终端、CLI 远程调用、端口映射、网络代理四条路都实跑了一遍，说一下各自的适用场景和操作路径。

3.1 UU远程终端：免公网IP最省事的第一选择

如果你家和我一样没有公网 IPv4，那最省事的就是 UU远程终端这类穿透方案。我用的是电脑端客户端加账号控制台的组合，机器上装好客户端，登录同一个账号，然后在控制台里找到"远程终端"或"端口映射"的入口，把内网 Agent 的 8787 端口加上一条映射规则。配置完成后，它会生成一个公网可访问的地址，外部设备用这个地址就能直接访问到家里内网的服务。

整个流程走下来，有三点值得注意：

• 这类工具的端口映射入口通常和"远程桌面"入口是分开的，别找错地方。端口映射是给服务用的，远程桌面是给人操作机器用的，弄混了会以为功能不可用；
• 免费档一般有连接时长或流量限制。Agent 这种常驻服务建议长连接挂在里面，如果频繁掉线，看是不是触发了闲置断连策略，可以配合心跳请求保持活跃。我给 Agent 的接口加了一个 30 秒一次的 ping 路由，就是为了让长连接不被掐断；
• 客户端要设成开机自启，否则机器重启之后穿透链路就断了，外部地址会一直连不上直到你手动把客户端拉起来。我后来把客户端注册成了 systemd 服务，而不是普通桌面自启，细节原因第五章会讲。

不需要动路由器、不需要公网 IP，这是 UU 远程终端对我这种场景最大的价值。

3.2 CLI 直连：codex 这类 Agent 的日常操作姿势

Agent 越来越 CLI 化，这是 2026 年一个很明显的趋势。codex CLI、gitlab CLI、openspec CLI 这些工具，本质上都是一个跑在终端里的 Agent 或 Agent 配套工具。热点里提到的/compact、/model、/resume就是 codex CLI 的会话管理命令，分别处理上下文压缩、切换模型、恢复历史会话，这三个命令我在远程场景下几乎天天用。

CLI Agent 的远程托管，我的做法是：

• 在 Agent 机器上用 systemd 拉起一个 tmux 服务，里面常驻 codex 的交互会话；
• 外部通过 SSH 密钥登录到家里机器，ssh home-agent -t 'tmux attach'直接挂到那个会话上；
• 远程对话操作完，按Ctrl-b d脱离，会话在 tmux 里继续跑。

如果是非交互式的自动化调用，codex 有exec模式，一条命令进去、结果出来，适合放在 CI 流水线里。比如我在 GitLab CI 里加了一步，代码合并后自动触发家里 Agent 跑一次 CR，审查意见通过 webhook 回传到 Merge Request 评论区。CLI 在远程场景下最大的价值就是可以像操作本地终端一样操作家里的 Agent，所见即所得，不需要额外开发什么 Web 前端。

3.3 端口映射的两条路：路由器转发与免公网穿透

端口映射本质上是把"外部进来的请求"引到"内网 Agent 所在的机器和端口"上，有两类实现方式。

第一类是路由器端口转发，前提是有公网 IPv4。在光猫或路由器后台配置 DNAT 规则，例如：

这类方式的优点是流量走自己的宽带，没有第三方中转，延迟低；缺点是动态 IP 会让规则失效，而且运营商对家庭宽带的 80/443 管得很严，外网端口尽量选高端口段。

第二类就是 UU 远程终端这类免公网穿透。客户端主动向外部的节点建立长连接，外部流量通过节点转发回内网。这类方式不挑网络环境，CGNAT 的宽带也能用，配置也简单，代价就是流量经过第三方节点，所以千万别把没鉴权的端口随便映射出去。我的习惯是：映射出去的端口一定是带 token 鉴权的接口，宁可在外面多绕一圈，也不要裸奔。

3.4 反向代理：把多入口收拢成一个域名

当你同时跑了好几个 Agent 服务，或者想统一管理访问入口时，就该套一层反向代理了。我这里说的"网络代理"，指的是给内网服务做统一网关出口，让外部的访问都先打到一台反代上，再按域名或路径分发到内网不同的 Agent。它不是流量加密工具，就是一个正经的流量分发网关。

我用的是 Caddy，配置极简，自动申请和续期 HTTPS 证书，一个 Caddyfile 就够：

agent.example.com { reverse_proxy 127.0.0.1:8787 } schedule.example.com { reverse_proxy 127.0.0.1:7878 }

配合 3.3 里的路由器端口映射，把外部 18443 转发到内网反代的 443，外部访问https://agent.example.com时，流量路径就是：外部 -> 路由器公网端口 18443 -> 反代 -> Agent 的 8787。反代层还可以统一加限流、日志、超时控制。这一步做完，家里跑多少 Agent，外部只需要记住一个域名就行，不用记一堆 IP 和端口。我后来所有 Agent 都走这一个入口，管理成本立刻降下来了。

4. 实测中的流量走向与安全加固清单

4.1 从外部到 Agent 的完整链路长什么样

先描述一下完整链路，方便后续排查时对照。我用文字画一遍："外部设备（手机/笔记本） -> 访问地址（UU远程终端生成的公网地址或 agent.example.com） -> 穿透节点或路由器的公网端口 -> 家里的宽带入口 -> 内网 Agent 主机 -> Caddy 反向代理（127.0.0.1:443） -> Agent 服务（127.0.0.1:8787）"。

这条链路上任何一环断了，外部就访问不到 Agent。排查的时候从外到内一层一层测：先看公网地址通不通，再看路由器或穿透客户端日志，最后看内网端口监听。把这个链路图记在脑子里，排错会快很多。我后来所有排障都遵循这个顺序，基本十分钟内能定位到问题出在哪一段。

4.2 鉴权三板斧：SSH密钥、Bearer Token、IP白名单

托管在家里的 Agent 不等于裸奔，我给自己立了三条安全规矩。

第一，SSH 只允许密钥登录。ssh-keygen -t ed25519生成密钥对，公钥放家里机器，外部用私钥连。把密码登录和 root 直接登录在 sshd_config 里关掉，这一步能挡掉 99% 的爆破。

第二，Agent 对外提供的每个 HTTP 接口都要带鉴权。我在 FastAPI 应用里加了中间件，所有/api路径都要求Authorization: Bearer <token>，没有 token 一律 401。千万别把内网端口裸映射出去，公网扫描器几分钟就能扫到。我自己测过，把 18787 端口映射出去后一小时，日志里全是来自世界各地的扫描连接，不带鉴权的话早就被打穿了。

第三，能加白名单就加白名单。反代层用 Caddy 的@allowed规则，只允许自己常用的几个 IP/网段访问管理路径，其他人即使拿到地址也进不来。白名单不能依赖一辈子，但作为分层防御的一层非常有用。

4.3 加固细节：最小暴露、防爆破、容器隔离

除了鉴权，还有几个容易被忽略的加固点：

• 最小暴露原则：只映射 Agent 的 API 端口，不要图省事把家里 NAS、路由器的管理端口一起映射出去。我没有映射 22，SSH 只在内网用，外部先经过穿透或反代，再跳板进内网；
• 防爆破：在反代层加 fail2ban 或 Caddy 的 rate_limit，同一 IP 一分钟内失败超过 5 次就封禁十分钟。这个策略我在生产环境验证过有效，爆破日志肉眼可见地减少了；
• 容器隔离：Agent 容器用非 root 用户运行，文件系统挂载为只读。即使 Agent 被注入恶意指令，攻击者想篡改代码也没那么容易。这是一个很关键的纵深防御层，很多人忽略；
• 依赖更新：代码仓库接 Dependabot，每周自动检查依赖更新。Agent 的底座是大模型，但它附带的工具链一样是软件，漏洞该补还得补。

这套组合跑了一年，端口映射暴露在公网，扫描器访问记录不少，但没有一次真正进得来。安全不是装一个东西就完事，是层层叠出来的。

5. 踩过的坑：动态IP、并发、断电恢复一个都没少

5.1 动态IP和端口失效：最典型的一次故障

托管第一周的第三天，我在公司突然连不上家里 Agent 了。症状很经典：早上还能用，下午所有请求全部超时。

排查链是这样的：

1. ping 我用的 DDNS 域名，发现解析结果和之前不一样，说明 IP 变了；
2. 登录路由器确认，果然是 PPPoE 重拨换了 WAN IP；
3. 再查端口映射规则，规则本身还在，但目标还是内网 IP，内网 IP 没变，问题出在 DDNS 没自动更新；
4. 把路由器里的 DDNS 客户端换成更稳定的版本，同时把 UU 远程终端这类不依赖公网 IP 的方案作为备用入口，双活。

结论：只要运营商还搞动态 IP，DDNS 自动更新就一定要配置好，而且要多留一个不依赖公网 IP 的备用入口。从那以后我再也没有只用单一路径访问家里的 Agent，穿透和端口映射互为备份，故障切换时间从一小时缩到了五分钟。

5.2 "AI Agent 怎么扛并发"：家用机的性能边界与排队策略

热搜里那个"ai agent 怎么扛并发"的问题，我在家里也撞上了。一开始我天真地以为 Agent 就是个 Web 服务，并发天然没问题。直到有次我同时从手机 App、CI 流水线和定时任务三个方向触发 Agent，8 核 16G 的内存直接飙到 85%，响应时间从 2 秒变成 40 秒，有的请求直接超时。

家用机的性能边界很明显，与其硬扛并发，不如让流量排队。我后来引入了一个简单的任务队列：外部请求先落 Redis，Agent 侧用 worker 一个一个处理，并发数限制在 CPU 核心数减一。实测 8 核机器设置 5 比较稳，再高就会出现上下文切换带来的额外损耗。同时对每个请求加了 60 秒超时和重试机制。

改完之后效果非常明显：高负载下 Agent 不再被打爆，请求都稳定在几十秒内处理完。我的经验是，家用机不要追求吞吐量，要追求确定性。宁可让请求排队等，也比并发一高就整个服务崩掉强。

5.3 断电恢复：无人值守的第一步

家里的电不像机房，夏天一个雷雨跳闸，Agent 就悄悄下线了。我一开始没做自动恢复，第二天早上起来才发现断了一整晚。

现在的做法是三件套：

• Docker 容器统一设置restart: always；
• systemd 负责拉起 Docker 服务和 UU 远程终端客户端；
• cron 健康检查脚本每 5 分钟 curl 一次本地端口，连续失败就重启容器。

做完了还要验证一次。我特意做了断电模拟：拔电、等一分钟、插电开机，观察 10 分钟内所有服务是否自动拉起、外部入口是否恢复。没做过这个演练，就别宣称自己"无人值守"。这个演练我建议每个想托管 Agent 的人都做一遍，成本只要十分钟，但能换来长期的省心。

5.4 冷启动后端口映射失效的排查链路

最有意思的一次故障是断电重启后，端口映射明明还开着，外部就是连不上。完整排查过程如下：

1. ss -tlnp | grep 8787确认 Agent 容器端口监听正常；
2. curl http://127.0.0.1:8787/health，应用健康；
3. 查穿透客户端日志，发现客户端重启后没有自动重连，节点连接状态是断开；
4. 手动重连，外部访问恢复；
5. 事后排查原因，客户端以桌面应用方式运行，开机自启没生效。

问题就出在最后一步。穿透客户端必须注册成系统服务而不是普通的桌面自启，否则会在用户登录后才启动，无人值守时等于没启动。我后来把它改成了 systemd 管理的用户服务，开机即拉起来。这种冷启动问题最坑，因为表面上看配置全是对的，但就是差一个自启细节。如果你也遇到"重启后连不上"的情况，优先检查这一步。

6. 给也想在家托管 Agent 的人：我的最终配置建议

6.1 一套可以直接抄的部署组合

把上面所有经验浓缩成一份可直接参考的组合：

• 硬件：旧台式机，32G 内存，512G SSD，无独显；
• 系统：Ubuntu 24.04 LTS；
• Agent 运行：Docker Compose，容器restart: always，非 root 运行；
• 远程入口：UU远程终端做免公网穿透 + Caddy 反代统一域名 + SSH 密钥登录；
• 守护：systemd 管理穿透客户端和 Docker，cron 健康检查脚本兜底；
• 安全：API Bearer Token、IP 白名单、fail2ban、Dependabot。

这套组合我从去年底跑到现在，除了运营商光猫偶尔抽风需要重启，其他基本不用管。如果你完全照着抄，应该能在半天内把 Agent 从"本机能跑"升级到"外网可访问、断电能自愈"的状态。

6.2 日常维护的节奏

托管在家里不等于彻底撒手。我每周花大概二十分钟做维护：

• 看一眼 Agent 日志，有没有异常报错；
• 清一次向量库的临时片段和日志文件，避免磁盘被占满；
• 检查穿透客户端和容器版本有没有更新。

每季度做一次端口映射安全复核，看看哪些端口还开着、有没有必要继续暴露。维护节奏不用太密，但要稳定，形成一个习惯就不会觉得累。我给自己定了每周五下午做这件事，现在已经变成固定程序了。

6.3 一些没必要做的事

最后说几个我踩过的"过度设计"：

• 没必要为了托管 Agent 专门买高性能显卡，纯 API 型 Agent 用不上，我的旧台式机到现在还用着核显；
• 没必要把家里整个内网都暴露出去，只映射 Agent 需要的那一两个端口就够，多映射一个端口就多一个攻击面；
• 没必要上 Kubernetes 这类重平台，家里的场景 docker compose 完全兜得住，上 K8s 只会给自己找罪受；
• 没必要把 Agent 的所有数据实时同步到云端，本地磁盘加定时备份反而更简单，我每天凌晨 rsync 一次到家中的另一块硬盘，恢复也方便。

我个人跑下来的体会是，把 AI Agent 托管在家里电脑，核心不是"家里电脑性能多强"，而是"远程通道是否稳定、安全是否兜得住"。优先让 Agent 在内网稳定跑一周，确认没有内存泄漏、没有频繁崩溃，再加远程入口，循序渐进，比一次性铺开所有方案靠谱得多。希望这篇实测能让你少走几个弯路。