AirLane 1.0：从流量代理，到网络编排
我们为什么要从零重做一个客户端：策略树、决策追踪、Mesh 组网与共享资源池。AirLane 1.0 从流量代理走向网络编排。
AirLane 1.0：从流量代理，到网络编排
我们为什么要从零重做一个客户端：策略树、决策追踪、出口池、Mesh 组网与共享资源池。AirLane 1.0 从流量代理走向网络编排。
我们为什么要从零重做一个客户端：策略树、决策追踪、Mesh 组网与共享资源池
多年来，代理客户端解决的是一个非常直接的问题：
"这条流量应该走哪个节点？"
于是我们有了 Proxy、Proxy Group、Rule、Rule Provider，加上一个配置文件。
这个模型曾经非常优秀。
但随着网络越来越复杂——几十个节点、多种协议、多台设备、家庭网络、办公网络、Mesh、共享 VPS、动态故障转移——我们逐渐意识到：
"代理客户端"这个抽象本身已经不够了。
AirLane 1.0 要解决的，不再只是"代理流量"。
我们想做的是：
让用户定义网络意图，让 AirLane 把意图编排成可执行的网络路径。
这就是 AirLane 1.0 的核心：
从流量代理，到网络编排。
1. 为什么还需要一个新客户端？
今天的代理客户端已经非常成熟。
你导入一个订阅：
🇩🇪 德国
🇳🇱 荷兰
🇺🇸 美国
🇸🇬 新加坡
🇯🇵 日本
然后创建几个策略组：
Proxy
Google
Netflix
AI
China
然后配置规则：
DOMAIN-SUFFIX,google.com,Google
DOMAIN-SUFFIX,openai.com,AI
GEOIP,CN,DIRECT
MATCH,Proxy
对普通用户来说，这足够了。
但随着配置规模增长，问题开始出现。
比如：
ChatGPT
↓
为什么走了德国？
Google
↓
为什么走了美国？
某个网站
↓
它到底命中了哪条规则？
这个节点
↓
为什么选了它？
这个策略组
↓
为什么没选延迟最低的节点？
这个节点
↓
昨天还能用——为什么今天被排除了？
传统客户端通常只能告诉你：
当前连接使用德国。
但它们很难回答：
为什么？
对于一个真正的网络系统，"为什么"往往比"是什么"更重要。
2. 从"规则"到"决策"
AirLane 重新定义了流量处理模型。
传统模型是这样的：
流量
↓
规则
↓
代理组
↓
代理
AirLane 把它拆成更清晰的决策链：
流量
↓
流量分类器
↓
流量行为
↓
流量策略
↓
出口 / 出口池
↓
NodeFlow
↓
sing-box
最重要的部分：
每一层只负责一件事。
流量分类器
回答：
这是什么类型的流量？
比如：
AI
Google
社交
流媒体
游戏
国内
GFW
私有
广告
追踪器
它不决定流量应该去哪里。
流量行为
回答：
我们应该怎么处理它？
比如：
路由
直连
阻断
拒绝
DNS
行为不绑定到任何具体节点。
流量策略
回答：
这条流量应该通过哪条网络路径出去？
比如：
AI
→ 路由
→ 美国出口池
→ 延迟感知
或：
国内
→ 直连
或：
其他
→ 路由
→ 欧洲池
→ 故障转移
出口选择只发生在策略层。
整个系统第一次真正成为一个"决策系统"，而不是一张规则列表。
3. 策略树：让复杂网络变得可理解
AirLane 1.0 的一个核心概念是策略树。
一个真实的网络策略可以表达为：
所有流量
│
┌────────────────┼────────────────┐
│ │ │
AI 国内 私有
│ │ │
路由 直连 直连
│
┌─────┴─────┐
│ │
OpenAI 其他 AI
│ │
美国池 全球池
│
┌───┼────┐
│ │ │
US-1 US-2 US-3
与传统配置文件最大的区别：
它描述的是决策关系，不是配置语法。
用户真正关心的是：
AI 流量 → 美国 国内流量 → 直连 其他国际流量 → 欧洲 节点故障 → 自动故障转移
而不是：
DOMAIN-SUFFIX,...
配置文件应该是系统的执行结果，而不是用户必须理解的产品模型。
4. 最重要的新能力：决策追踪
当策略系统变复杂后，最难的问题变成了：
"为什么？"
所以 AirLane 1.0 不只是规则匹配。
我们希望每一个网络决策都可追溯。
比如，当用户访问：
https://chatgpt.com
AirLane 可以告诉你：
决策追踪
目标
chatgpt.com:443
↓
分类器
AI
↓
行为
路由
↓
策略
AI Global
↓
目标
美国出口池
↓
选择策略
延迟感知
↓
候选
US-01 82 ms 健康
US-02 94 ms 健康
US-03 210 ms 降级
↓
选中
US-01
↓
出口
VLESS / US-01
用户不再需要猜测。
系统告诉他们：
我为什么这样做。
5. 网络真正需要的不是"节点"，而是出口
在传统客户端里，我们把一切都叫：
代理 / 节点。
但实际上：
VLESS
VMess
Trojan
Shadowsocks
Hysteria2
WireGuard
这些是不同的传输方式。
对于策略系统来说，它们最终解决的是同一个问题：
一个可以承载流量的网络出口。
所以 AirLane 使用统一的核心抽象：
出口（Exit）
一个出口可以来自：
手动添加
订阅
Clash 导入
自建
AirLane 共享资源
Mesh
它可以使用：
VLESS
Shadowsocks
Hysteria2
WireGuard
...
这样，上层策略永远不需要关心：
"这个节点是 VLESS 还是 Shadowsocks？"
它们只需要知道：
这个出口能否提供我需要的网络能力？
6. 出口池：从"节点列表"到"资源池"
有了出口，我们再往上抽象一层：
出口池
比如：
美国池
├── US-01
├── US-02
├── US-03
└── US-04
或：
欧洲池
├── 德国
├── 荷兰
├── 法国
└── 芬兰
但出口池本身不决定选哪一个。
这是一个非常重要的设计。
池只是：
一组资源。
实际的选择发生在策略里：
AI 策略
→ 美国池
→ 延迟感知
或：
视频策略
→ 亚洲池
→ 健康感知
因此：
出口池
= 有哪些资源可用？
策略
= 应该怎么选？
这两个概念被明确分开了。
7. 健康：节点不是简单的在线 / 离线
传统客户端通常把节点状态简化为：
🟢 在线
🔴 离线
但真实网络远比这复杂。
一个节点可能是：
TCP ✓
TLS ✓
VLESS ✓
延迟 42 ms
HTTPS ✓
IPv6 ✗
UDP ✓
Mux ✗
它显然不是离线。
它更准确的状态是：
降级
所以 AirLane 的出口健康不应该只是一个 ping。
我们评估多个维度：
可达性
延迟
可靠性
传输质量
吞吐量
服务能力
结果是：
出口健康
96 / 100
健康
更重要的是：
健康分数和选择策略是两个不同的概念。
健康回答：
这个节点本身有多好？
选择回答：
这次该选哪个节点？
这为未来更复杂的调度策略留出了空间。
8. 从单机客户端到 Mesh
如果 AirLane 只是 PC 上的一个代理客户端，那它仍然只是一个客户端。
但我们认为网络的未来不应该用：
"一台电脑"
来衡量。
而应该是：
"一组设备"
比如：
AirLane Mesh
│
┌────────────────┼────────────────┐
│ │ │
笔记本 手机 路由器
│ │ │
Windows Android OpenWrt
│ │ │
└────────────────┼────────────────┘
│
出口资源
这意味着：
- 一台设备可以发现另一台
- 多台设备共享网络能力
- 一个节点可以成为另一台设备的出口
- 策略可以跨设备同步
- 网络资源可以集中管理
所以：
AirLane 不再只是一个 VPN 客户端。
它开始成为一个：
个人网络架构
9. 共享资源池：节点也可以成为网络资源
这是 AirLane 更长期的方向。
今天我们买一台 VPS：
VPS
↓
自己用
但如果那台 VPS 可以成为一个标准化的：
出口资源
那它就可以进入资源池。
比如：
我的资源
欧洲池
├── 阿姆斯特丹
├── 法兰克福
└── 赫尔辛基
亚洲池
├── 东京
├── 新加坡
└── 首尔
未来甚至可以有：
AirLane 共享资源池
不同用户可以贡献或购买网络资源。
架构上：
出口
↓
出口池
↓
策略
↓
网络
这已经和传统的"买订阅、导入节点"模型完全不同了。
它更接近于：
一个网络资源市场 + 一个网络编排平台。
10. 为什么 sing-box 仍然是基础？
AirLane 不试图重新实现每一个网络协议。
网络数据面是一个高度专业的领域。
所以我们选择了成熟的 sing-box 作为底层执行引擎。
AirLane 负责：
策略
分类器
行为
出口
出口池
健康
决策
Mesh
资源
sing-box 负责：
TUN
入站
出站
DNS
传输
VLESS
Shadowsocks
Hysteria2
WireGuard
路由运行时
中间通过：
NodeFlow IR
连接
AirLane
│
NodeFlow IR
│
编译器
│
sing-box
│
网络数据面
这意味着 AirLane 永远不需要向用户暴露 sing-box 的配置结构。
用户看到的是：
网络意图。
底层看到的是：
可执行的配置。
11. 兼容 Clash，但不再受限于 Clash 模型
这不意味着 AirLane 与 Clash 生态割裂。
恰恰相反。
Clash/Mihomo 生态积累了大量优秀资产：
- 节点订阅
- 规则提供者
- GeoSite
- GeoIP
- ACL4SSR
- BlackMatrix7
- 各种社区规则集
这些都是有价值的网络数据资产。
AirLane 的做法不是：
"重新发明每一条规则。"
而是：
Clash / Mihomo
↓
解析器
↓
NodeFlow IR
↓
AirLane 策略模型
↓
sing-box 编译器
换句话说：
兼容生态，但不继承旧的产品抽象。
这是 AirLane 和传统 Clash GUI 最大的区别之一。
12. AirLane 1.0 真正想解决什么？
我们不认为：
"今天的代理客户端不好。"
恰恰相反。
过去的客户端把：
代理流量
这件事做得非常好。
但网络在不断演进。
今天一个用户可能拥有：
笔记本
手机
平板
家用路由器
VPS
云服务器
同时使用：
VLESS
Shadowsocks
Hysteria2
WireGuard
同时需要：
AI
流媒体
游戏
工作
国内
隐私
还想要：
自动选择
自动故障转移
健康检查
跨设备同步
Mesh
资源共享
这已经不是一个简单的：
代理 + 规则
能完全表达的问题了。
13. 所以 AirLane 1.0 的核心不是"更多功能"
我们不想做：
一个有 200 个设置项的 Clash GUI。
我们想做的是降低网络系统的认知复杂度。
让用户描述：
AI → 美国
国内 → 直连
视频 → 最佳亚洲
其他 → 欧洲
而不是让用户维护：
几十条规则
十几个代理组
几百个提供者
庞大的 YAML 文件
最终：
用户意图
↓
AirLane 策略引擎
↓
决策
↓
NodeFlow
↓
sing-box
↓
网络
14. 从代理客户端到网络编排器
所以 AirLane 1.0 的变化不是：
一个不同的 UI。
也不是：
又一个 Clash GUI。
真正的变化是抽象层变了。
以前：
代理
规则
代理组
配置
现在：
流量
分类器
行为
策略
出口
出口池
健康
决策
Mesh
资源
用户过去要问：
"我该用哪个节点？"
现在系统回答：
"根据你的网络策略、流量类型、节点健康和当前环境，这是我这次应该为你选择的路径——以及为什么。"
这就是：
AirLane 1.0——从流量代理，到网络编排。
代理只是数据面。
真正值得编排的是整个网络。