电脑上的 Agent 还在运行，人却已经离开办公室；换到手机热点或酒店 Wi-Fi 后，最麻烦的往往不是重新启动任务，而是无法回到原来的工作台继续查看输出、补充指令。Termexo v0.10.0 引入远程中继访问，解决的正是这一段断开的体验。
Termexo 面向 Windows 10/11 x64，是一个开源 AI 编程终端工作台。开启远程访问后，桌面端启动的工作可以通过手机或另一台电脑的浏览器继续使用。重点不在于“把终端页面公开到互联网”，而在于让同一个工作台跨网络保持可访问。
远程中继解决了什么
传统做法通常依赖端口转发、动态 DNS 或 VPN。它们并非不能用，但需要处理家庭路由器、公司网络、NAT、防火墙和证书等问题。对正在运行 Agent 的桌面来说，任何一个网络条件变化，都可能让远程接入失效。
中继模式把连接拆成两段：桌面上的 Termexo 主动连接自建中继服务，远程浏览器也连接到同一个中继，再由中继转发经过认证的会话数据。桌面端不必直接暴露在公网，跨网络访问也不再强依赖入站端口。
这带来几个实际变化：
- 在 Windows 桌面上开始的 Agent 任务，可以从手机浏览器查看进度。
- 换用另一台电脑时，不必重新创建工作区或复制上下文。
- 中继服务可以部署在自己的 VPS 或内网边界节点上，连接路径和数据保留策略更容易控制。
- 远程访问与本地工作台保持同一份状态，适合长时间运行的编码、构建和分析任务。
需要注意的是，中继不是计算节点。Agent 仍然运行在原来的 Windows 电脑上；如果电脑休眠、Termexo 进程退出或本地网络完全断开，远程浏览器不能凭空恢复任务。
自建中继应该怎样落地
来源摘要没有给出 Termexo 中继服务的具体镜像名、端口和配置键。下面的部署片段因此是一个可改造的通用方案，假设中继服务提供 HTTP/WebSocket 入口，并监听容器内的 8080 端口。实际部署时，应以 Termexo v0.10.0 的官方配置说明为准，替换镜像名、环境变量和健康检查路径。
先在一台公网 VPS 上准备随机凭据，并限制配置文件权限：
mkdir -p "$HOME/termexo-relay"
openssl rand -hex 32 > "$HOME/termexo-relay/relay-token"
chmod 600 "$HOME/termexo-relay/relay-token"
printf 'Relay token created at %s\n' "$HOME/termexo-relay/relay-token"
可以用下面的 compose.yaml 作为部署骨架。YOUR_TERMEXO_RELAY_IMAGE 是占位符，不能直接当作 Termexo 官方镜像名使用：
services:
relay:
image: YOUR_TERMEXO_RELAY_IMAGE
restart: unless-stopped
environment:
RELAY_BIND: 0.0.0.0:8080
RELAY_AUTH_TOKEN_FILE: /run/secrets/relay_token
secrets:
- relay_token
expose:
- "8080"
secrets:
relay_token:
file: ./relay-token
将凭据文件放在同一目录后启动服务：
cd "$HOME/termexo-relay"
docker compose up -d
docker compose ps
docker compose logs --tail=100 relay
生产环境还应使用 HTTPS，并正确转发 WebSocket 升级请求。以 Nginx 为例，下面是可改造的反向代理配置：
server {
listen 443 ssl;
server_name relay.example.com;
ssl_certificate /etc/letsencrypt/live/relay.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/relay.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 3600s;
}
}
这里的关键不是 Nginx 本身，而是三点：中继入口必须使用 TLS，长连接需要保留 WebSocket 头部，认证凭据不能写死在公开仓库或命令历史中。
从桌面切换到手机时，最容易忽略的边界
远程工作台让“继续使用”变得简单，但也扩大了控制面。浏览器一旦拿到有效会话，可能不仅能查看输出，还能发送新的 Agent 指令。因此自建中继至少要做好以下控制：
- 为中继使用独立域名和有效 TLS 证书。
- 使用高熵随机令牌，定期轮换；不要把令牌提交到 Git。
- 在 VPS 防火墙中只开放
443，管理端口限制为固定办公 IP 或通过 VPN 访问。 - 中继只负责转发时，尽量关闭不必要的日志内容，避免把提示词、代码和命令输出长期写入日志。
- 给远程会话设置明确的生命周期，离开公共设备时主动退出并撤销会话。
- 对 Agent 的高风险动作保留本地确认，例如删除文件、推送代码、执行生产环境命令。
另外，手机浏览器并不适合所有终端操作。长日志、交互式调试和多文件修改仍然更适合大屏幕；移动端更适合作为状态检查、短指令补充和任务暂停入口。
一套可执行的采用清单
可以按下面的顺序引入 Termexo v0.10.0 的远程能力：
- 在 Windows 10/11 x64 机器上升级并确认本地工作台能正常启动 Agent。
- 在个人 VPS 上部署中继，先只开放 HTTPS 入口。
- 用测试工作区验证桌面端连接、浏览器连接、输出同步和断线重连。
- 从手机蜂窝网络访问，确认它确实经过中继，而不是依赖同一局域网。
- 检查日志中是否泄露令牌、提示词、代码或命令输出。
- 为中继令牌、TLS 证书和 Termexo 客户端更新建立维护周期。
Termexo v0.10.0 的价值，是把桌面 AI 工作台从“固定在某台电脑前”变成“可以在不同网络继续接入”。它尤其适合运行时间较长、需要间歇性干预的 Agent 任务。采用时应把中继当作远程控制入口来管理：先明确认证、传输加密和高风险操作边界，再把便利性扩展到日常工作流中。