把 Claude 当成网络协议栈：一个让 AI 处理 ICMP 报文的有趣实验

一位嵌入式系统博士 Adam Dunkels 最近做了一个有趣的实验：让 Claude Code 充当一个用户态 IP 协议栈，直接读取网络设备 /dev/tun0 上的原始 IP 数据包，逐字节解析报头，计算校验和，然后回复 ICMP echo request（也就是 ping 请求）。

结果？ping 确实能通，往返延迟大约 42.5 秒。虽然慢得离谱，但这个实验验证了一个有趣的概念：Markdown 就是代码，LLM 就是执行这段代码的处理器。

实验原理

整个实验的核心想法很简单：

1. 在系统上创建一个 TUN 虚拟网络设备 /dev/tun0
2. 给 Claude 一份详细的指令（ping-respond.md），告诉它如何解析 IP 报文
3. 让 Claude 逐字节读取 TUN 设备上的数据包
4. Claude 解析 IP 报头（版本、IHL、总长度、TTL、协议号、源/目的 IP）
5. 如果是 ICMP echo request，Claude 计算校验和并构造 echo reply
6. 将回复写回 TUN 设备

Claude 能正确解析 IP 报文吗

令人意外的是，Claude 确实做到了。它能够：

• 正确解析 IPv4 报头的各个字段
• 识别 ICMP 协议类型
• 计算 IP 报头校验和（按 RFC 规范的反码求和）
• 计算 ICMP 校验和
• 构造合法的 echo reply 数据包

使用 Haiku 4.5 模型时，一次完整的 ping 往返大约需要 42.5 秒。速度极慢但功能正确。

这意味着什么

这个实验虽然被作者自己称为”荒谬”和”浪费 token”，但它展示了一个有趣的技术边界：

• LLM 可以作为通用计算引擎：不仅是文本处理，还能处理二进制协议解析和校验计算
• Markdown 即程序：用自然语言描述的协议规范，LLM 可以直接”执行”
• 适用场景有限但概念有趣：42 秒的 ping 延迟显然不适合生产环境，但验证了 LLM 处理底层网络协议的能力

技术细节

实验使用了 Python 辅助脚本来配置 TUN 设备的终端选项（stty），让 Claude 可以通过标准输入输出读写原始数据包。整个协议解析和校验计算完全由 Claude 在”理解”层面完成，没有调用任何网络库。

作者提到了 2001 年著名的”IP over Carrier Pigeon”（RFC 1149）实验作为对比——当年用信鸽传输 IP 数据包的延迟虽然也很高，但至少不用消耗 token 费用。

对开发者的启发

这个实验的实际意义不在于用 LLM 做网络协议栈（那太慢了），而在于它验证了几个有趣的可能性：

1. 用自然语言描述协议就能让 AI 理解和执行：这意味着对不常见的或私有的协议，只需用自然语言写清楚格式，AI 就能解析
2. AI 辅助协议调试：在调试网络问题时，让 AI 帮忙解析原始数据包可能比手写解析器更快
3. 教学价值：用这种可视化方式理解 IP/ICMP 协议，比读 RFC 文档更直观

如果你对这个实验感兴趣，可以在 Adam Dunkels 的博客上找到完整的指令文件和实验代码。虽然不建议在生产环境用 Claude 处理网络流量，但作为理解 AI 能力边界的案例，这个实验值得一读。