自托管：让 AI Agent 的数据留在你自己的服务器上
AI Agent 真正开始接手工程任务之后，有一个问题会越来越难回避：
你的代码、你的会话、你的提示词，到底存在哪里？
当 Agent 只是偶尔帮你写一段代码时，这个问题无关紧要。但当 Agent 开始连续工作几小时、读写你的真实代码库、记住你的项目约定和用户偏好时，「数据主权」就从合规部门的术语，变成了每个开发者的日常关切。
自托管不是「不信任云」的偏执，而是「我的数据应该由我控制」的朴素要求。
Helix 的定位一直很直接：Agent 运行在你的机器上，连接方式由你的场景决定。 今天我想聊聊支撑这件事的三条路：本地直连、自托管隧道、VPN 组网。
先想清楚：你为什么需要自托管
每个人的理由不一样，但大体可以归为四类：
数据主权。 代码是公司最值钱的资产之一。把整个代码库的上下文、会话历史、甚至你踩过的坑都交给第三方存储，很多团队过不了这一关——尤其是金融、医疗、政企行业。
私有网络接入。 Agent 跑在公司内网（这是最常见的部署方式），但你需要从家里、从客户现场、从任何地方访问它。内网机器通常没有公网 IP，这就需要一个安全通道。
合规与审计。 数据出境限制、内部审计要求、访问控制策略——这些在云服务上往往说不清，在自己的服务器上却一清二楚。
成本结构。 团队已经有服务器了，为什么还要按席位、按用量向 SaaS 付费？自托管之后，边际成本趋近于零。
Helix 从架构上就为这件事做了准备：桌面端、后端、Web 端都能指向你自己的 Agent 实例。剩下的问题只有一个——怎么连过去。
第一条路：本地直连
最朴素的情况：你的电脑和 Agent 在同一局域网内。比如办公室的台式机跑着 Agent，笔记本在同一 Wi-Fi 下连接它。
这种场景不需要任何额外设施，客户端发现同一网络的 Agent 实例后直接连接，延迟最低、速度最快。
但直连有一个天花板：它只适用于同一网络。
一旦你走出办公室，或者机器在 NAT 后面，直连就失效了。这时候需要第二条路。
第二条路：自托管隧道——穿透 NAT 的安全通道
这是大多数人需要的方案。它的思路是：
在你自己的服务器上部署一个网关（我们叫它 EasyGateway），内网的 Agent 主动连上网关，你在任何网络下访问网关分配的子域名，流量被安全转发到内网 Agent。
你的设备（任意网络）◄────加密连接────► 网关（你的服务器）◄──子域名路由──► 内网 Agent
注意一个关键点：是内网 Agent 主动向外连接网关，而不是外部向内穿透防火墙。 这意味着你不需要改路由器、不需要申请公网 IP、不需要配端口映射。NAT 被「绕过」而不是「打穿」——家庭网络、公司网络、云 VPC 里的机器，一视同仁。
几个值得说说的设计
双向 TLS 认证。 不是「谁连上来都行」。节点启动后通过 CSR 申请客户端证书，网关验证通过才允许接入，传输全程加密。你不需要在公网上裸奔任何端口。
子域名路由。 每个节点拿到专属子域名（比如 mybox.gw.example.com）。多台机器互不干扰，也能清晰地在网关侧看到每台设备的连接状态和实时流量。
心跳保活与自动重连。 网络抖动是常态。控制通道带心跳检测，连接断开后自动恢复；长时间静默的死连接也会被及时识别并重建。你不需要半夜爬起来重启服务。
自包含部署。 网关本身不依赖任何外部服务，一份配置就能跑，完全离线的内网环境也能用。
典型场景
- 公司服务器跑 Agent，回家用桌面端接着干——工作区、会话、工具链完全一致
- 临时把内网的一个 Web 服务暴露给外部同事看，不用动防火墙
- 团队共用一个自托管 Agent，各自从自己的客户端连接
第三条路：VPN 组网——让多台机器像一个局域网
隧道解决「访问单个 Agent」的问题。但真实工程场景往往是多台机器互相访问：笔记本上的 Agent 要连办公室的数据库，构建机要调测试机的 API，测试机要拉模型服务的接口……
这种需求，隧道模式就有点绕了——你不想为每个服务都开一条隧道。更自然的模型是：让这些机器像在同一个局域网里一样。
Helix 的 VPN 客户端在每台设备上创建一个虚拟网卡（macOS 用系统 utun，Linux 用原生 TUN），并接入网关维护的虚拟局域网：
- 每台设备把自己的网段（比如
192.168.1.0/24）注册进路由表 - 其他设备按最长前缀匹配决定如何转发数据包
- 数据转发完全在用户态完成——不需要管理员权限，不需要改系统路由表（macOS/Linux 都无 CGO 依赖）
- 网络切换（Wi-Fi → 热点）后自动重连，不打断工作
用起来的感觉就是：办公室的数据库 IP 在笔记本上直接能 ping 通。 本地开发、跨机器协同、跨地区团队共享内网资源，都变成了同一件事——「在同一个局域网里」。
双链路自动选优：快的那条路，自动走
有一个细节我们花了心思：连接不该只有一条路。
Helix 会同时维护直连和隧道两条链路，持续探测延迟：
- 同一局域网 → 自动走直连，延迟最低
- 跨网络 → 自动切换或并行使用隧道
- 链路质量变化 → 自动重选最优路径
实际体验是：你在办公室和在家，Helix 都「无感」地用着当前最快的那条路。没有「手动切换连接」这个操作——连接是基础设施，不该让用户操心。
安全模型：三层防线
自托管不是「自己搭个服务随便连」。Helix 的安全模型是三层：
- 传输加密 —— 客户端与 Agent 的 API 通信使用长期凭证 + 配对流程，首次配对后颁发凭据，之后的请求全部携带身份校验
- 节点认证 —— 网关侧的 mTLS 确保证书合法、节点真实，未注册的设备根本无法建立连接
- 用户鉴权 —— 网关可以与你的用户体系打通，在网关侧看到每个节点的归属用户，方便审计
三层各司其职：即使某一层被突破，另外两层仍然兜底。
什么时候该用哪条路
| 场景 | 推荐方案 |
|---|---|
| 同一局域网内 | 本地直连 |
| 从任意网络访问内网 Agent | 自托管隧道 |
| 多台机器互相访问服务 | VPN 组网 |
| 既有单机需求又有远程需求 | 直连 + 隧道（自动选优） |
| 完全离线内网 | 自包含网关 + 隧道 |
最后
AI 编码工具过去两年的竞争焦点是「模型强不强」。但模型能力会趋同，数据与基础设施的选择权，才是真正拉开差距的东西。
Helix 的选择是：Agent 的算力可以来自任何模型，但 Agent 的数据和运行环境，应该由你控制。自托管隧道和 VPN 组网，就是把「由你控制」从理念变成可操作的日常。
如果你也想让 Agent 跑在自己的服务器上，欢迎进群聊聊你的部署场景，我们很想知道真实的网络环境长什么样——那往往比任何架构图都更有说服力。