熟悉我的朋友肯定知道，我其实是一个复古计算的爱好者。
如果说前几年玩这种东西，只是作为一个 geek 的一些奇怪爱好，那么在今天这个 Agent 的时代，尤其是 coding agent 能力如此之强、每个 Agent 都是一个超级程序员的时代，我反而觉得这些“上古”的好设计，尤其是那些一直活到今天的，真的是充满智慧，毕竟那个时代的计算机用户，每个人都是程序员。
我先抛出一个观点：现如今做 Agent Infra 与其重新造轮子，不如看看历史中有没有好用的轮子。有些很有意思的设计，其实在很早之前就已经存在了。这些宝藏可能因为过于晦涩，或者不太符合普通用户的人体工学，以至于它们没有成为主流，但是在 Agent 成为用户的时候，马上就会大放异彩，最近这个 CLI 和 UNIX 哲学的复兴就是一个很好的例子。
其实大家知道，最近我的关注点都在构建 Agent 互联网的 Infra（基础设施），或者说 Agent 社会学，是我最近特别感兴趣的一个方向（我其实是攻壳机动队的粉丝，所以不难理解吧）。我觉得包括现在的 Harness Engineering，其实都只是一个小型 Agent 网络的缩影。也许未来会出现这种大规模的 Agent 协同网络，我相信已经有无数的创业公司在做着了
也有很多朋友问我像 A2A 这样的协议，我都持谨慎意见，我的观点是：
这些协议都太新了，也没有经过大规模的验证和时间的考验
从设计细节来看，设计者其实并没有经过太多的深思熟虑，表现上就是一个复杂的东西，因为做加法总是是容易的，但只有简单的协议才会有持久生命力
下面我用几个例子来跟大家说一说，这些是我心目中比较有趣的/简洁的协议，当然包括但不限于这些，还有很多很多。它们来自一个“前 Web”的时代，但如果换一个 Agent 视角，会发现它们并没有过时，反而充满了智慧。
第一个例子，先说 9P。它来自 Plan 9，一个在 80 年代中后期由贝尔实验室做的操作系统。这个项目本身没有成为主流，但里面有不少设计一直在影响后来的系统（其实我觉得 Plan 9 最重要的遗产是 Golang，不过这个我先不展开了）
9P，就是 Plan 9 里最核心的一个协议。如果用一句话讲，9P 是一个“文件协议”，更准确一点说，Plan 9是用“文件”的方式，把整个系统对外的访问统一起来。而这个统一的接口和协议就是 9P，因为 9P 是定义了如何去访问这些“文件”。它的接口非常简单，甚至可以说有点“过分简单”。
它没有试图变成一个复杂的 RPC 系统，而是刻意保持得非常简单。
大致就是一组非常基础的操作，对应文件系统的那套语义：
attach：挂载一个文件系统
walk：在目录树中移动
open / create：打开或创建文件
read / write：读写文件
clunk：关闭文件
remove：删除文件
stat：获取或修改元信息
version：协商协议版本
error / flush：处理异常和中断
看上去 9P 和 Fuse 很像，但是至少在 Plan9 OS 中，9P 是内核的一等公民，几乎所有的系统服务的都是通过 9P 的 Server 实现的，所以 Plan 9 才能做到天然就是一个网络操作系统（想象下，这是在上世纪 80 年代中期到 90 年代早期的工作）
因为是 9P 是类文件系统接口，所以上层就很容易通过 UNIX 工具来对 9P 协议封装的系统能力进行编程：
下面是个通过文件系统通过 HTTP 协议来访问 web 的例子：
conn='{dial tcp!host!80}echo -n 'GET / HTTP/1.0\r\nHost: example.com\r\nUser-Agent: plan9\r\n\r\n' > $conn/datacat $conn/data
9P 其实能干的事情是更多的。例如在 Plan 9 的体系里面，它甚至把一些 CPU 的计算也通过计算能力作为资源，通过 9P 协议封装。于是在 80 年代，就基本上能够做到这种基于网络的存算分离。甚至像一些图形界面以及用户的操作交互的 GUI 工作流，都被 Plan 9 变成了 9P 协议然后通过文件系统来实现。当然，如果没有真正体验过 Plan 9，其实很难理解我在说什么，感兴趣的朋友可以自己去体验下。
另外一个很有意思的点是：9P 协议看起来并没有随着 Plan 9 的消亡而消失，它其实一直活在 Linux 的内核里，是一个 Linux 正式支持的文件系统。现在 9P 最主流的应用场景，其实是在虚拟机跟宿主机之间的文件系统共享上。
例如今天假设 Agent 的文件系统通过 9P 协议来构建（因为 9P 协议比传统文件系统能容纳更多非存储之外的语义），想象一下，如果一些计算逻辑和 Agent 能力也通过 9P 文件系统挂载上去，其他的 Agent 就可以像当年 Plan 9 那样，去调用一个远程虚拟文件系统的能力，调用该 Agent 通过 9P 挂载的文件描述符服务。这样一来，大家就可以通过一套统一的语义接口，构建起 Agent 的存储以及计算网络。
第二个例子是 Gopher。
Gopher 是一个诞生于 1991 年的互联网协议，由 University of Minnesota 开发。
它的核心理念非常简单：
互联网就是一个分层菜单系统（hierarchical menu）
在 Web（HTTP + HTML）出现之前，Gopher 曾经是信息检索的主流方式之一（毕竟那个时代没有浏览器）
Gopher 在历史上是输给了 Web 的，这一点没有争议。但这个结论，其实是站在“人”的角度得出的。
Gopher 很简单：层级结构、文本协议，没有动态渲染，也没有复杂的状态。
Gopher 的设计极其“干净”，可以用一句话描述：
Everything is a menu or a file
它的结构类似这样：
Root├── Documents│ ├── file1.txt│ └── file2.txt├── Links│ └── another server└── Search
作为网络协议，Gopher 是一个极简 TCP 文本协议：
请求就是一行字符串
响应就是文本（带一点结构标记）
例如一个极简的访问 Gopher 站点的例子：
nc gopher.floodgap.com 70
发送：/ （访问根目录），返回：
1About /about gopher.floodgap.com 700README /readme.txt gopher.floodgap.com 707Search /search gopher.floodgap.com 70
每一行的结构
[type][display text]\t[selector]\t[host]\t[port]
于是一个 Gopher 节点，通过这种方式可以构成了一个 Gopher 的网络。
Gopher 拥有一个极简的资源类型系统（也很方便扩展），用一个字符表示资源类型：
类型
含义
0
文本文件
1
目录（菜单）
7
搜索
9
二进制
g
GIF
h
HTML（后期扩展）
当年大家觉得它不够“丰富”。但今天再看，会有一点不一样的感觉，因为在 agent 时代：
HTML 和 JS 对 agent 来说是噪音
结构化、可遍历接口更重要
Gopher 的一些特性反而很友好了：
可遍历（crawl-friendly）
无状态
低复杂度
强结构
现在的 Web 很强大，但同时也非常复杂。
HTML、CSS、JavaScript 混在一起，很多语义是隐含的。
对人来说，这没问题，反正人只需要看最终渲染后的浏览器效果。 但对 Agent 来说，这种复杂性其实是负担。Agent 并不需要一个“好看”的界面，它需要的是一个稳定、可预测的结构。从这个角度看，Gopher 那种简单、低熵的设计，反而变得很有吸引力。
我觉得如果今天重新设计 “Agent Internet”，Gopher 的模型可能比 HTTP 更接近终态。我们看到现在越来越多给 Agent 设计的网站采用 Markdown on HTTP 也是类似的理由。
最后是 IRC
IRC（Internet Relay Chat） 是 1988 年由
Jarkko Oikarinen 创建的一种实时文本通信协议。
一句话总结：
IRC = 最早的大规模实时“聊天室网络”
相信像我年龄这么大的老登当年肯定也在 IRC 上聊过天（暴露年龄）
IRC 的抽象其实非常干净：
Server Network├── #channel1│ ├── userA│ ├── userB├── #channel2│ ├── userC└── private messages
IRC 不是单点：
多个 server 互联（类似 federation）
channel 在整个网络传播
用户可以连接任意 server
有点像：
早期去中心化聊天（像不像 Discord！）
因为 IRC 的文本协议的可以扩展的（只有少数几个固定的命令），你可以在任何 IRC Server 中提供自己的扩展命令。
基础能力
对应的 IRC 命令和概念
命令
JOIN / PART / PRIVMSG
事件
message / join / leave
路由
channel
编码
纯文本
从这个角度来看，其实基于 IRC 可以实现一个 “弱一致” 的分布式系统，毕竟通过扩展命令，IRC 相当于一个 “文本版 RPC + Event Bus”
所以其实 IRC 的本质是：
命令 + 事件流 + 路由（广播）
IRC 常常被当成一个聊天工具，但如果换个角度，它其实更像一个很早期的协作系统。
channel、消息流、pub/sub，这些概念今天看起来都很熟悉。
因为开放/极简的协议，和去中心化的设计，IRC 里一直都有大量的 bot，而且它们是“自然存在”的，不是后来补上去的能力，而是系统的一部分。
如果把 Agent 放进这个模型里，会发现很多东西是可以直接映射的：
多个 Agent 在同一个 channel 里，通过消息协作，基于事件驱动推进任务。
和“调用 API”相比，这种模式更接近一种实时的、多方参与的过程。
而且 IRC 已经存在了几十年，几乎不需要客户端，而且 CLI 和 Bot 生态极其丰富，加上开源和去中心化的特性，很容易就能构成一个大型的去中心化的 Agent 协同网络（简单的桥接到别的 IRC 网络中），我前两天甚至自己已经实现了一个雏形 AIRCd (AI IRC), 开源在了这里：
https://github.com/c4pt0r/aircd
(aircd 的 irc 服务器, 接入了两个 claude code 作为 agent，开始在频道里谈天说地，从量子力学聊到了哥德尔和元数学)
还是挺有意思的。
上面只是几个小例子，其实历史的宝库中还有更多。把这几个东西放在一起看，会有一个很模糊但又挺清晰的感觉。
它们都在做一件类似的事情：
把复杂的问题压缩成一组非常简单的原语。
9P 把系统访问压缩成 read / write
Gopher 把信息组织压缩成层级结构
IRC 把协作压缩成TCP 的文本消息流
这些设计在当年没有成为主流，很大程度上是因为它们不够“适合人”。
但如果用户换成 Agent，情况就有点不一样了。
我不太确定未来的软件形态会是什么样子。但有一种可能是，它不会越来越复杂，而是某种程度上的“回归”。不是回到过去的实现，而是回到那些更简单的抽象。
有些东西，当年看起来太早了。
现在可能刚刚好。
---
P.S. 最后结尾放一张我心目中 90s 赛博朋克美学巅峰，攻壳的草薙素子的经典海报致敬一下，顺便当个题图。
仔细想想好像离 2029 年也不远了？