摘要：Tailcat是一个很小的项目，概念也很简单：像netcat一样在两台机器之间传数据，但底层使用Tailscale的数据平面；同时，它又不需要Tailscale账户，不依赖Tailscale控制平面，不修改系统路由表和DNS，也不要求...
Tailcat是一个很小的项目，概念也很简单：像netcat一样在两台机器之间传数据，但底层使用Tailscale的数据平面；同时，它又不需要Tailscale账户，不依赖Tailscale控制平面，不修改系统路由表和DNS，也不要求root。一个服务端启动后得到一段短连接Token，客户端拿着Token就能建立端到端WireGuard加密连接。初始连接通过DERP中继引导，随后magicsock尝试NAT穿透，如果条件允许就升级成直接P2P UDP。
它看起来不像大模型、机器人或新芯片那样“宏大”，却很适合用来理解现代P2P网络里一个经常被混淆的问题：WireGuard解决的是加密隧道，并没有替你解决“两个在NAT后面的节点怎样找到彼此、怎样穿透、穿不透时去哪中继”。Tailscale真正有价值的一部分，就是围绕WireGuard搭建了节点发现、NAT穿透、DERP和控制平面。Tailcat则做了一个实验：如果只把数据平面拆出来，会得到什么？
WireGuard很简单，公网现实却很复杂
如果两台机器都有固定公网IP，P2P通信非常容易。一端监听UDP端口，另一端连接即可。现实中的家庭宽带、手机网络、企业办公网、云容器大多躲在NAT后面，有的甚至经过CGNAT。节点不知道自己在公网看到的地址，防火墙也不会自动允许陌生UDP包进入。
STUN一类机制可以帮助节点知道自己的公网映射，UDP hole punching则让双方先主动向对方发包，诱导NAT创建映射。但不同路由器和运营商的NAT行为差异很大，并不是每次都能打洞成功。于是还需要TURN/Relay作为最后退路。
Tailscale的DERP承担类似“保证一定能通”的中继角色。连接初期可以先通过DERP交换信息和数据，magicsock在后台尝试更直接的路径；一旦UDP直连建立，就切换到P2P。用户看到的是“一条连接”，底层却可能经历中继、路径探测和升级。
Tailcat直接复用了这套数据平面，因此开发者不需要自己实现NAT Traversal，也不需要配置内核TUN设备。
为什么它可以没有Tailscale控制平面
完整Tailscale里，控制平面负责账户、设备身份、ACL、节点发现、Tailnet网络图、密钥协调等工作。数据平面负责真正的数据包传输。普通用户觉得“输入设备名就能连”，很大一部分便利来自控制平面提前告诉双方彼此是谁、该不该连接、对方可能在哪些地址。
Tailcat主动放弃了这层能力。它把建立连接所需的信息塞进一段ConnBlob连接Token，通过“带外方式”交给另一端。这个Token大约几十字节到更长，包含服务器WireGuard公钥和DERP信息。你可以通过聊天、二维码、命令行参数、已有API甚至U盘把Token交给对端。
换句话说，Tailcat把“节点发现和授权”交还给应用自己处理。它只负责：拿到双方连接元数据以后，建立WireGuard加密通道，并尽量穿透NAT。
这种设计让它非常接近一个Library，而不是VPN产品。项目README直接说，它既可以作为CLI使用，也可以作为Go库嵌入应用。
“Tailscale without Tailscale”为什么对开发者有意义
很多应用只是想获得一个安全P2P Transport，并不想把整台机器加入虚拟网络。比如文件临时传输、远程调试、两台Agent节点通信、浏览器和本地服务建立一次性连接。如果使用完整VPN，往往要管理账户、网卡、路由和ACL；如果自己搭WebSocket中继，又会让全部流量长期绕服务器。
Tailcat提供了一条中间路线：连接建立在用户态，不碰系统路由；能打洞就直连，不能打洞才走DERP；所有流量用WireGuard端到端加密。对于一次性或应用级P2P，这种抽象非常自然。
它和传统netcat也形成有趣对比。netcat是“给我一个IP和端口，我帮你把stdin/stdout接过去”；Tailcat是“给我一段连接Token，我帮你跨NAT把stdin/stdout接过去”。互联网基础环境变化了，工具的地址模型也从IP:Port变成可携带的连接元数据。
Connection Token本质上是一张临时网络名片
Tailcat服务器启动后会生成WireGuard密钥和连接信息，并输出Token。客户端解析Token后知道服务端公钥以及应该先去哪个DERP Bootstrap。初始连接建立后，双方可以交换候选地址，magicsock尝试UDP直连。
这种Token模型很适合二维码。例如一台现场设备屏幕显示二维码，维护工程师手机一扫，临时建立端到端诊断连接，不需要提前把两台设备注册到同一账户。也可以用在桌面应用“配对”：用户只需复制一段短码，而不是配置公网IP、端口映射和VPN账号。
不过这里必须注意，Token本身承担了连接元数据和一定的授权作用，应用如果公开泄露Token，就可能让不该连接的节点尝试建立连接。Tailcat并没有替业务设计完整身份体系，生产系统仍然需要额外认证、Token有效期、权限以及会话生命周期管理。
DERP让“总能连上”有代价
P2P工具最容易做Demo，最难保证全球各种网络环境下稳定。Tailcat默认可以使用Tailscale提供的免费、限速DERP中继，也允许用户自建。README非常明确地写着：这些公共Tailcat DERP没有SLA和吞吐保证，随时可能被撤销。
这说明Tailcat目前更像实验性开发组件，不是可以直接拿来承载关键生产业务的托管网络。真正做产品，要么自建DERP，要么购买有合同保障的服务，还要考虑区域调度、流量费用、拥塞和可观测性。
一旦直连失败，所有数据都经中继，延迟和带宽成本都会明显变化。应用应该能观察当前路径到底是P2P还是DERP Relay，并根据业务决定是否允许大文件传输或实时控制。
对Agent系统有什么想象空间
Agent越来越多以后，一个现实问题是它们不一定都运行在同一个云里。开发Agent可能在用户笔记本，文件Agent在NAS，工业Agent在工厂边缘节点，云端只负责模型推理。传统做法通常是所有节点主动连到中心Broker或云Gateway，由中心转发消息。
P2P Transport可以减少中心带宽，也能让敏感数据不经过云服务器。例如云端智能体只下发任务Token，本地两个Agent直接交换文件；或者现场边缘节点与工程师电脑建立临时加密连接，完成日志和模型更新。
Tailcat本身并没有Agent协议、身份管理和任务编排，不能直接等同于“Agent网络”。但它展示了一种值得关注的基础能力：安全点到点网络也可以被当成应用内部的一个库，而不是必须先让运维配置VPN。
如果和MCP、Agent Identity之类上层协议结合，未来可能形成“身份和权限由Agent平台管理，数据通道根据任务临时建立”的架构。控制平面告诉两个Agent允许协作，随后生成一次性连接元数据，实际大文件、模型权重或日志直接P2P传输。这种Control Plane / Data Plane分离在云网络里非常成熟，Agent基础设施迟早也会遇到同样问题。
工业和边缘计算场景同样有价值，但要谨慎
工厂现场的设备往往位于复杂NAT和防火墙后面，远程运维又不能随意暴露端口。用户态、无需root的临时P2P连接很有吸引力。设备厂商可以让工程师获得一次性连接码，问题处理结束后失效，减少长期VPN账号。
但工业网络对安全要求更高。Tailcat当前明确没有API/CLI稳定性承诺，Wire Format也可能变化，公共DERP没有SLA。它适合研究架构和原型验证，不应该未经加固直接放进生产OT网络。真正产品化还要增加设备身份、证书、审计、白名单、会话审批、跳板策略和网络分区。
另一个问题是企业网络可能主动阻止UDP或未知外连。此时DERP可以提高可达性，但也要符合数据出境和网络边界政策。P2P不是“绕过网络管理”的工具，而应该被纳入既有安全策略。
Tailcat最值得看的其实是控制平面与数据平面的边界
完整Tailscale的优势，很大程度来自强控制平面：身份、ACL、设备管理和网络图让复杂P2P网络变得简单。Tailcat证明，数据平面本身也可以独立成为一种Transport能力。开发者可以选择自己的身份系统、自己的控制面，只复用WireGuard + magicsock + DERP这套连接机制。
这对软件架构有很强的启发。很多基础设施一开始以完整产品形态出现，生态成熟后，其中某一层会被拆成可嵌入组件。数据库从独立服务器变成SQLite、DuckDB；浏览器内核可以嵌入应用；网络能力也可能从VPN产品变成Library。
Tailcat现在很年轻，README明确不承诺稳定API，也不适合作为关键生产网络的默认答案。可它值得技术团队花一点时间理解，因为未来智能体、边缘计算、家庭服务器和临时设备协作会产生越来越多“我只想安全地把这两个节点连起来”的需求。那时，网络不一定需要先成为一个VPN，它可能只是应用的一部分。
参考资料
- Tailscale / Tailcat GitHub
https://github.com/tailscale/tailcat - Horizon Summary 2026-08-27
https://thysrael.github.io/Horizon/2026/08/27/summary-zh.html