项目开源地址：
GitHub - TunPilot
(欢迎 Star
)
为什么做这个项目
不知各位大佬都是什么时候开始接触节点的。
在 AI 狂飙的时代，被 OpenAI 降过智，被 Anthropic 封过号，折腾来折腾去，不知不觉手上就攥着了好几个节点。
随着节点变多，一些纯纯的运维脏活儿就找上门了：
- 管理多台机器的部署、内核调优、掉线排查
- 给朋友分派节点，偶尔还要瞅一眼流量统计
- 针对 Surge、Clash 等各种代理客户端维护配置和订阅转换
…
市面上并不缺优秀的节点管理面板，我也曾兴冲冲地部署过几个，但总感觉没能完全击中我的痛点。
仔细盘算，原因主要有三：
- 极其低频的管理需求：绝大多数时候它只是在默默运转。只有买了新机器才去动手部署，有朋友加入才去开号分配，感觉变卡了才去查账。为了一个月点不开两三次的操作，去维护一个常驻的重型 Web 面板，颇有杀鸡用牛刀的疲惫感。
- 交互范式的迁徙：我已经完全习惯了将 Agent 作为数字世界的入口，日常开发中的 Claude Code、OpenClaw 早已成为我发号施令的首选阵地。
- 让 AI 把脏活干到底：部署和调优节点这类极其耗费脑细胞的系统级操作，如今完全可以交由能力强大的 Agents 全权包揽。既然如此，为 Agents 设计的程序就该彻底抛弃传统的 Web 壳子，摒弃复杂的前后端、组件库和打包工具。褪去了所有给人类看的 UI 包袱后，换来的将是系统底座极致的轻量与干练。
TunPilot 的诞生：属于 Agent 的隧道领航员
既然传统的面板体系"水土不服"，何不跳出固有思维重构一套新的工作流？
我的核心设计原则是：Agent-First，抛开 UI 包袱先行构建底座。将节点部署、用户生命周期管理、流量统计等所有核心能力重写，并全部封装为纯粹的 MCP (Model Context Protocol) 服务暴露给大模型。在这个阶段，AI 既是指令的入口，也是现成的"动态操作面板"——我只需给出一句自然语言指令，它就替我深入系统干完所有的脏活。
于是，便有了 TunPilot 这个项目。
关于命名的初衷，它由 Tunnel（隧道）与 Pilot（领航员）拼接而成。虽然乍一听略微有些像是某个民航的后台调度系统，但在当前的语境下却有着绝佳的隐喻——那四处散落、纵横交错的节点构成了暗网中的隧道，而那个不知疲倦、帮你调配资源、排查故障的 AI Agent，便是你最可靠的领航员。
它能做什么
既然不想要庞杂的 Web 面板，我们就把节点管理做成了纯粹的 MCP (Model Context Protocol) 服务。没有多余的 UI，Agent 既是用户界面，也是操作中心。以下是它的核心能力：
1. 从零到一的自动化部署
以往加节点，总得在服务端敲好一堆配置，再填到面板里的茫茫表单。
但在 TunPilot 的工作流中，只需告诉 Agent：“这是台新机器， IP 1.2.3.4，帮我搭个 Hysteria2 节点”。
配套的 deploying-nodes Skill 会自动替你包揽这些繁琐的工程：自动 SSH 登录、下发配置、生成证书、甚至是开通身份认证，之后默默把它记进 TunPilot。生命周期的起止，都变成了一句话的事。
2. 基于用户维度的订阅分发
手工维护各类客户端的配置是一件令人头疼的事。
而在"全面拥抱 Agent"的交互体系里，一切管理都是围绕着"用户"这个维度开展的。当你需要分享节点的时候，不该由你去操心格式的拼装和转换。
你只需要对 Agent 说上一句：“给 alice 生成一个 Surge 的订阅链接，顺带配一份新手导入教程”。
Agent 就会替你调用内部工具，精准地为你生成并返回一条针对目标客户端的专属安全订阅链接。至于用户去点击这个链接时，底层系统是如何根据他的剩余配额、可用节点并通过 Format Registry 组装出正确的配置文件，这些繁琐的过程全部被巧妙隐藏了。你要做的只有一件事：把这串链接丢给对方就行。
3. 被"自然语言化"的身份鉴权配置
自然语言看似随意，这背后依旧是很严谨的设计：“帮我建个叫 alice 的用户，只能用东京和香港那两台，50G 流量用完即止，最晚用到下个月初。”
这么一段话里，底层的数据关系映射（多对多关联）、精确到字节阈值的扣减逻辑已经在协同工作了。一旦触发配额上限或时间到期，后端的鉴权接口便会在协议层精准阻断连接请求，确保规则被严格执行。
4. 持续静默的后台数据探针
对于长效的节点运维来说，时刻紧盯流量监控不仅繁琐，底层的资源消耗也更高，这显然违背了自动化的初衷。
为此，TunPilot 内部跑着一个轻量级的后台守护进程，专门负责定时从分布式的节点拉取使用数据并持久化落盘。
当你有数据审计的需求时，只需通过 Agent 下达查询指令，例如：“排查一下最近流量消耗异常的用户”，它不仅能迅速调取底层数据完成汇总分析，甚至还能直接为你生成直观的可视化图表，让系统状态一目了然。
实际用起来什么感觉？
为了具象化这种"无 UI 交互"的爽感，我们可以看看它在终端环境里是如何代替传统管理面板运转的：
场景一：买了一台新机器，需要部署拉起服务并记入系统
以往： SSH 登录 → 黏贴一堆安装脚本 → 申请证书 → 编辑配置 → 回到面板后台 → 新建节点 → 复制参数对接。
现在，你只需要在 Claude Code 里敲下：
> 这台服务器 IP 是 1.2.3.4，帮我在这上面自动部署一下 Hysteria2，然后注册进 TunPilot。
Agent 思考中...
[Tool call: ssh_execute] 正在登录 1.2.3.4 安装服务、下发配置与证书...
[Tool call: mcp_nodes_create] 正在将新服务注册入库并建立鉴权回调...
✅ 部署完成。已成功在 1.2.3.4 搭建好隧道，TunPilot 已开始接管该节点的鉴权与流量统计。
场景二：朋友临时来借用节点
以往：打开面板 → 用户管理 → 新增用户 → 分配额度 → 绑定节点组 → 找一端教程 → 拼接出带 Token 的长链接。
现在，指令直达业务核心：
> 创建一个用户 bob，给 100G，只能用日本的节点。然后生成 Surge 的链接丢给我。
Agent 思考中...
[Tool call: mcp_users_create] 录入 bob，配额 100GB...
[Tool call: mcp_nodes_assign] 正在将两台区域归属为"日本"的节点授权给 bob...
[Tool call: mcp_sub_generate] 基于 Surge 模板编译链接...
✅ 搞定。这是 bob 的专属订阅链接：http://tunpilot.local/sub/token-xxx。额度 100G，只下发了日本节点。需要我附上一份使用说明吗？
全程没有打开任何网页，不用去记任何一个管理后台的地址与密码。这种"说句话就把事情办了"的交互流，将从前琐碎的链路极度压缩。
Agent-First 的演进哲学：先有能力，后有界面
可能有人会疑惑：不做 UI，这样的系统是不是意味着没有直觉、门槛极高？
其实不然。这正是 TunPilot 项目的核心理念：Agent-First 绝不代表永远排斥 GUI，而是通过拥抱 Agent 来获取极致的试错与迭代速度。
在这套全新的开发范式中，我们不再需要像传统面板那样，为了加入一个小功能（比如支持某项新协议、拓展一个统计图表）而去反复经历"修改底层模型 → 画前端组件 → 接口联调 → 打包部署"的漫长链路。现在，只要将核心的业务逻辑写好并暴露为 MCP Tool，端到端的交付即告完成。Agent 凭借其高悟性和强大的容错率，天然就充当了一个能执行复杂操作的"全动态交互层"。
这为系统带来了极高的敏捷度。依托于 Agent，我们能够用极低的成本去探路，高速打磨闭环。一旦这套完全为 AI 设计的底层能力与标准接口在迭代中进入真正的稳定期，届时如果真的需要，再去以此为基础搭建一套哪怕极其精致的 GUI 面板，也不过是水到渠成的一件事。
归根结底，这就是探索 Agent-native 工作流的意义：不是给 AI 强行套个壳子，而是起步时就剥离界面的包袱，把所有心智留给核心能力的建设。平时服务在后台安静地跑着，要运维时在对话中说上一句指令即达，将繁杂化为属于极客的那份清爽与干练。