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 的 AgentCPU 完全够别为了托管 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三件事在考虑远程方案之前先花半小时给家里的网络做个体检三个必查项有没有公网 IPv4登录光猫的管理页看 WAN 口拿到的 IP 是不是 100.64.x.x 这种 CGNAT 段。如果是那路由器端口映射这条路基本走不通只能靠 UU 远程终端这类免公网方案上行带宽够不够用测速工具测一下上传如果上行只有 5Mbps那远程传文件会非常痛苦。我实测家里上行 30Mbps跑 Agent 的文本响应绰绰有余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 规则例如外部端口内网目标协议用途18787192.168.1.10:8787TCPAgent API18443192.168.1.10:443TCP反代 HTTPS这类方式的优点是流量走自己的宽带没有第三方中转延迟低缺点是动态 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、路由器的管理端口一起映射出去。我没有映射 22SSH 只在内网用外部先经过穿透或反代再跳板进内网防爆破在反代层加 fail2ban 或 Caddy 的 rate_limit同一 IP 一分钟内失败超过 5 次就封禁十分钟。这个策略我在生产环境验证过有效爆破日志肉眼可见地减少了容器隔离Agent 容器用非 root 用户运行文件系统挂载为只读。即使 Agent 被注入恶意指令攻击者想篡改代码也没那么容易。这是一个很关键的纵深防御层很多人忽略依赖更新代码仓库接 Dependabot每周自动检查依赖更新。Agent 的底座是大模型但它附带的工具链一样是软件漏洞该补还得补。这套组合跑了一年端口映射暴露在公网扫描器访问记录不少但没有一次真正进得来。安全不是装一个东西就完事是层层叠出来的。5. 踩过的坑动态IP、并发、断电恢复一个都没少5.1 动态IP和端口失效最典型的一次故障托管第一周的第三天我在公司突然连不上家里 Agent 了。症状很经典早上还能用下午所有请求全部超时。排查链是这样的ping 我用的 DDNS 域名发现解析结果和之前不一样说明 IP 变了登录路由器确认果然是 PPPoE 重拨换了 WAN IP再查端口映射规则规则本身还在但目标还是内网 IP内网 IP 没变问题出在 DDNS 没自动更新把路由器里的 DDNS 客户端换成更稳定的版本同时把 UU 远程终端这类不依赖公网 IP 的方案作为备用入口双活。结论只要运营商还搞动态 IPDDNS 自动更新就一定要配置好而且要多留一个不依赖公网 IP 的备用入口。从那以后我再也没有只用单一路径访问家里的 Agent穿透和端口映射互为备份故障切换时间从一小时缩到了五分钟。5.2 AI Agent 怎么扛并发家用机的性能边界与排队策略热搜里那个ai agent 怎么扛并发的问题我在家里也撞上了。一开始我天真地以为 Agent 就是个 Web 服务并发天然没问题。直到有次我同时从手机 App、CI 流水线和定时任务三个方向触发 Agent8 核 16G 的内存直接飙到 85%响应时间从 2 秒变成 40 秒有的请求直接超时。家用机的性能边界很明显与其硬扛并发不如让流量排队。我后来引入了一个简单的任务队列外部请求先落 RedisAgent 侧用 worker 一个一个处理并发数限制在 CPU 核心数减一。实测 8 核机器设置 5 比较稳再高就会出现上下文切换带来的额外损耗。同时对每个请求加了 60 秒超时和重试机制。改完之后效果非常明显高负载下 Agent 不再被打爆请求都稳定在几十秒内处理完。我的经验是家用机不要追求吞吐量要追求确定性。宁可让请求排队等也比并发一高就整个服务崩掉强。5.3 断电恢复无人值守的第一步家里的电不像机房夏天一个雷雨跳闸Agent 就悄悄下线了。我一开始没做自动恢复第二天早上起来才发现断了一整晚。现在的做法是三件套Docker 容器统一设置restart: alwayssystemd 负责拉起 Docker 服务和 UU 远程终端客户端cron 健康检查脚本每 5 分钟 curl 一次本地端口连续失败就重启容器。做完了还要验证一次。我特意做了断电模拟拔电、等一分钟、插电开机观察 10 分钟内所有服务是否自动拉起、外部入口是否恢复。没做过这个演练就别宣称自己无人值守。这个演练我建议每个想托管 Agent 的人都做一遍成本只要十分钟但能换来长期的省心。5.4 冷启动后端口映射失效的排查链路最有意思的一次故障是断电重启后端口映射明明还开着外部就是连不上。完整排查过程如下ss -tlnp | grep 8787确认 Agent 容器端口监听正常curl http://127.0.0.1:8787/health应用健康查穿透客户端日志发现客户端重启后没有自动重连节点连接状态是断开手动重连外部访问恢复事后排查原因客户端以桌面应用方式运行开机自启没生效。问题就出在最后一步。穿透客户端必须注册成系统服务而不是普通的桌面自启否则会在用户登录后才启动无人值守时等于没启动。我后来把它改成了 systemd 管理的用户服务开机即拉起来。这种冷启动问题最坑因为表面上看配置全是对的但就是差一个自启细节。如果你也遇到重启后连不上的情况优先检查这一步。6. 给也想在家托管 Agent 的人我的最终配置建议6.1 一套可以直接抄的部署组合把上面所有经验浓缩成一份可直接参考的组合硬件旧台式机32G 内存512G SSD无独显系统Ubuntu 24.04 LTSAgent 运行Docker Compose容器restart: always非 root 运行远程入口UU远程终端做免公网穿透 Caddy 反代统一域名 SSH 密钥登录守护systemd 管理穿透客户端和 Dockercron 健康检查脚本兜底安全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 在内网稳定跑一周确认没有内存泄漏、没有频繁崩溃再加远程入口循序渐进比一次性铺开所有方案靠谱得多。希望这篇实测能让你少走几个弯路。