大概在 2023 年，我在一家 AI 公司工作时，曾尝试用 AsyncAPI 来描述 SSE（Server-Sent Events）相关的协议。但当时发现这个东西的实现效果非常差，AsyncAPI 的工具链基本上都是残缺的，整个完整的流程根本跑不起来。
先简单介绍一下 AsyncAPI：它是一个用于描述异步 API 的规范，定位类似于 OpenAPI（原 Swagger）之于 REST API。它的核心思想是用 YAML 或 JSON 格式来定义事件驱动系统中的消息结构、通道（Channel）和操作（Operation），从而让异步 API 也能像 REST API 一样拥有机器可读的契约文档。规范本身是协议无关的，号称支持 Kafka、RabbitMQ、MQTT、WebSocket、AMQP 等各种消息协议。
理论上，有了这份契约文档，你就可以：自动生成文档、生成客户端/服务端代码骨架、做 Mock 测试等——这套故事和 OpenAPI 生态讲的完全一样。
当时我觉得这种体验极其糟糕。考虑到整个生态中其实没有比 AsyncAPI 更成熟的方案，我将其归结为这种 Stream 生态并没有人在意。我曾认为这是一个风口，但很奇怪为什么没人去做。市面上的方案（如 Socket.io 之类）大多是非常 Low-level 的封装，并没有提供真正有用的抽象。
到了 2026 年的今天，我重新看了一下它的 Slogan。它抹除了之前那种暧昧的描述，只留下了一句：它是为 Event-Driven Architecture（事件驱动架构）服务的。
说到这里其实就很清晰了：
- 它描述的是复杂服务之间的交互，而非终端用户向服务器的交互。这将其服务范围限定得非常小。
- 虽然听起来有用，但实际效果看，它过于 Generic（通用化）了。它试图提供一种涵盖所有 Case 的抽象，例如 Message Broker 和服务间 WebSocket 的用例。
我认为这类抽象的细节是很难闭环的，很难真正对得上。再加上 Code-gen（代码生成）相关的东西很不成熟，社区规范也很少，导致最后生成的代码往往是”牛头不对马嘴”。
在这种情况下，用 AsyncAPI 真的属于没事找事，自己给自己找麻烦。在生态位上，我觉得它完全被 gRPC 加 Protobuf 这种生态的东西爆杀了。我完全不知道用它干什么，听起来也只是各家大公司为了争夺生态位正统，而搞出的一种令人难以理解的形式。