用UU远程把家里电脑变成AI Agent常驻服务器：CLI、端口映射与代理实测

为什么要把Agent放家里

我手上的Agent项目大多不重，但有几个特点让云主机不太合适。

一是依赖本地资源。有些任务要读我本地的文档目录、调用本地跑的嵌入模型，甚至只是想让Agent帮我整理下载文件夹。这些东西搬到云上就要重新做一遍同步，成本比省下的电费高。

二是模型调用成本。本地跑一个7B到14B量级的模型做初筛、分类、工具路由，能挡掉相当一部分对云端大模型的调用。云主机上跑本地模型要么没GPU，要么贵得离谱。

三是长期在线的需求。Agent这东西，真正有用的时候是它在你不在的时候干活------定时抓取、定时总结、定时跑一轮任务队列。这就要求机器常开，并且我能随时连回去看状态。

家里的台式机或闲置笔记本正好满足：GPU有、磁盘大、电费可接受。唯一的问题是，我不在家的时候怎么操作它。

这篇文章讲的就是这个"怎么操作"。我用的是UU远程（网易UU的远程控制功能，官方也有终端、端口映射这类能力）。下面所有操作都是我实际跑过的，涉及版本号或具体参数的地方我会写清楚，没验证的我会直接说没验证。

环境与前置条件

先说我这边的情况，方便你判断可迁移性。

被控端：Windows 11 家庭版，AMD 平台，一块消费级N卡，24小时开机
主控端：macOS 笔记本 + 一台安卓手机
Agent运行时：Python 3.11，用venv隔离
Agent形态：一个FastAPI写的HTTP服务（提供/run、/status接口），加一个基于langchain的CLI入口

UU远程需要被控端和主控端登录同一个账号，被控端保持在线。这一点和大多数远控软件一样，没有特别的地方。

【注意】Windows家庭版没有自带的远程桌面服务端，所以纯靠系统RDP是走不通的，这也是我选第三方远控的直接原因。如果你用的是Windows专业版，系统RDP也能用，但它在NAT环境下同样需要额外打洞或映射，不一定更省事。

第一步：先把Agent做成"能后台跑"的东西

在讨论远程之前，有个更基础的问题：Agent本身得能在没人盯着的情况下跑起来，并且崩了能自己起来。

我一开始是直接在终端里python cli.py跑，窗口一关就没了。后来改成用Windows的计划任务在开机时拉起，或者用nssm把它注册成服务。这里给一个最简的FastAPI服务，后面端口映射要用到：

python 复制代码

# agent_server.py
# Python 3.11, fastapi 0.115.x, uvicorn 0.32.x
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import time

app = FastAPI(title="home-agent")
START_TS = time.time()

class RunReq(BaseModel):
    prompt: str

@app.get("/status")
def status():
    return {
        "ok": True,
        "uptime_sec": int(time.time() - START_TS),
    }

@app.post("/run")
def run(req: RunReq):
    if not req.prompt.strip():
        raise HTTPException(status_code=400, detail="empty prompt")
    # 这里换成你自己的Agent调用逻辑
    return {"echo": req.prompt, "ts": int(time.time())}

启动命令：

bash 复制代码

# 监听所有网卡，端口8000
uvicorn agent_server:app --host 0.0.0.0 --port 8000

【踩坑提醒】--host 0.0.0.0是为了让端口映射能访问到，只写127.0.0.1的话本机以外的连接进不来。但这也意味着局域网里任何人都能访问，所以后面必须配鉴权，别裸奔。

写成服务的好处是：机器重启后Agent自动起来，我远程连上就能直接用，不用先手动开一堆窗口。这一步做完，远程才有意义。

第二步：用UU远程的终端连回去

UU远程主控端连上被控端之后，界面上有桌面视图，也有终端/命令行入口。我日常主要用终端，因为传画面在弱网下很卡，敲命令反而流畅。

实际体验下来的几点：

终端里跑uvicorn、git pull、看日志都没问题，中文输出正常。
长时间命令（比如跑一轮Agent任务）建议配合nohup或后台服务，别占着这个终端会话，因为远控会话断了命令可能跟着断。
复制粘贴是有的，但大段粘贴偶尔会掉字符，我一般把长脚本先写到文件里再执行。

这里要说明一点：UU远程终端的具体实现细节（是走SSH还是自研通道）我没有去验证 ，从使用感受上它更像是一个封装好的远程shell，不是标准SSH会话。所以如果你需要scp、端口转发这类SSH原生能力，别指望它，得走下面的端口映射。

第三步：端口映射，让Agent的HTTP接口对外可用

这是整篇文章里最关键的一步。Agent的FastAPI服务跑在8000端口，我要在外面用手机或笔记本直接请求它，就得做端口映射。

UU远程里提供了端口映射/内网穿透类的功能（不同版本叫法可能不一样，我这边看到的是"端口映射"入口）。大致流程是：

在被控端选择要映射的本地端口，填8000。
选择映射协议，HTTP服务选TCP。
系统分配一个公网可访问的地址（域名或IP加端口）。
主控端或任意设备用这个地址访问。

映射成功后，验证分两层。

第一层，本机先确认服务是活的：

bash 复制代码

curl http://127.0.0.1:8000/status

第二层，用映射出来的公网地址访问：

bash 复制代码

curl http://<映射地址>/status

如果第一层通、第二层不通，问题基本在两个地方：映射没真正建立（被控端UU没在线或端口填错），或者被控端防火墙拦了。Windows防火墙默认会拦入站，需要在"入站规则"里给8000端口放行，或者干脆给uvicorn进程放行。

【关键结论】端口映射解决的是"连接可达"，不解决"安全"。映射出去的是一个公网地址，任何人扫到都能打。所以下面这步不能省。

第四步：给映射出去的接口加鉴权

裸奔的Agent接口是灾难。一个/run接口如果谁都能调，等于把你的模型额度、本地文件访问权全交出去了。

最小成本的方案是加一个固定Token头校验：

python 复制代码

# 在 agent_server.py 基础上加鉴权
import os
from fastapi import Header

API_TOKEN = os.environ.get("AGENT_TOKEN", "")

@app.post("/run")
def run(req: RunReq, x_agent_token: str = Header(default="")):
    if not API_TOKEN or x_agent_token != API_TOKEN:
        raise HTTPException(status_code=401, detail="unauthorized")
    return {"echo": req.prompt, "ts": int(time.time())}

调用方：

bash 复制代码

curl -X POST http://<映射地址>/run \
  -H "x-agent-token: <你的token>" \
  -H "Content-Type: application/json" \
  -d '{"prompt":"整理今天的下载目录"}'

Token放环境变量，别写死在代码里。这只是及格线，真要长期暴露在公网，建议再加IP白名单或换成带签名的请求。不过IP白名单在家里动态IP的情况下不好维护，这一点我目前也没找到特别省心的方案，如果你有稳定做法欢迎交流。

第五步：网络代理，让Agent能访问需要代理的资源

Agent经常要访问外部API，其中一部分在国内直连不稳定。这就在家里机器上引出一个问题：Agent进程怎么走代理。

我的做法是在被控端跑一个本地代理客户端（这类工具很多，具体用哪个不影响思路），监听一个本地端口，比如7890，然后让Agent进程通过环境变量走它：

bash 复制代码

# Windows PowerShell
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
uvicorn agent_server:app --host 0.0.0.0 --port 8000

Python里用requests或httpx时会自动读这两个环境变量，langchain底层大多也是走这两个库，所以一般不用额外改代码。

【踩坑提醒】有两个地方容易翻车：

有些库不读环境变量，比如部分底层用socket直连的组件，得手动传proxies参数。
代理客户端本身如果开了"仅代理浏览器"之类的模式，命令行进程是走不到的，要确认它开的是全局或系统代理模式。

另外，如果你是通过UU远程的终端去操作被控端，代理链路和远控链路是两回事，互不影响。远控通道走UU自己的网络，代理只影响Agent进程访问外网，别把这两者搞混。

延迟、稳定性与成本的实际感受

跑了一段时间，说几个真实体感，不吹不黑。

维度	实际表现	说明
终端操作延迟	可接受	敲命令基本跟手，弱网下会有明显延迟
桌面画面	一般	弱网下卡顿明显，所以我尽量不用桌面
端口映射稳定性	中等	长时间连接偶尔需要重连，具体频率和网络环境强相关
本地模型推理	取决于硬件	和远程无关，是机器本身的能力
成本	低	主要是电费，无云主机月租

【注意】上表里"端口映射稳定性"这一行，我没有做长时间压测，只是日常使用中的主观感受。如果你要做生产级依赖，建议自己跑一段时间的可用性监控再下结论。

一个容易忽略的点：被控端休眠

Agent要常驻，机器就不能睡。Windows默认会在闲置后休眠或关屏，虽然关屏不影响运行，但休眠会直接断掉一切。

需要在电源设置里把"睡眠"设为"从不"，同时确认没有其他节能策略把它拉去休眠。这个坑我在刚部署时踩过------远程连上去发现Agent"挂了"，其实只是机器睡了。

这套方案适合谁，不适合谁

适合：

有闲置机器和GPU，想跑本地模型或本地文件相关的Agent
需要Agent定时、长期在线，但预算有限
能接受一定的手动维护，不需要企业级SLA

不太适合：

需要严格公网可用性和高并发的场景，云主机+正规反向代理更合适
对安全要求高、不能接受任何公网暴露的场景，这套方案要额外做很多加固
家里网络本身不稳定、经常掉线的环境

最后

把Agent托管在家里，本质上是用"自己维护"换"成本和安全可控"。UU远程的终端、端口映射、网络代理这三块拼起来，确实能覆盖大部分个人开发者的需求：终端负责操作，端口映射负责让接口可达，代理负责让Agent能出网。

但要清楚它的边界：端口映射不等于安全，远控终端不等于SSH，代理只影响进程出网。这几条分清楚，部署的时候就不会在错误的方向上排查问题。

如果你也在做类似的事，我比较好奇的是：公网暴露的Agent接口，你是怎么处理鉴权和访问控制的？固定Token在个人场景够用，但要再往前一步，方案就开始变复杂了，这块我还在找更省心的做法。