注：本文来自@oasisfeng 推特，MarsBit整理如下：
ChatGPT 新推出的插件机制，在普通用户眼中，或许只是又一个引入了插件机制的产品。然而从开发者的视角来看，其中的实现机制是颠覆性的，它有着解决我思考了很多年的「去中心化互联网的互操作性难题」的潜力。
这一切的缘起，还要回望 Web 2.0 时代，那是一个基于 Open API 创造 Mashup 的黄金年代。
21 世纪之初，交互式互联网兴起和蓬勃发展的原始时代，几乎每一个新兴的互联网应用，都在响应「开放」的互联网精神，推出各自的 Open API。很多应用也将对接其它 Open API 作为自己的一大潮酷卖点。
这背后，是一个个深受开放文化熏陶的开发者，在孜孜不倦的用代码和汗水搭建起通过 API 互联的桥梁。
在经历 Open Web 乱世和 Mashup 泡沫后，伴随互联网用户的去极客化，大家越来越追求稳定可靠而非精彩纷乱的互联网应用。
成长起来的巨头纷纷筑起高墙来巩固自己的圈地。Open API 逐步被藩篱之内的 Platform API 和企业间基于商业合作的 Private API 所取代。
Open 也不再是文化，更多只是商业宣传。
当互联网不再 Open，API 也不再需要被精心设计，因为调用 API 的，已非昔日有着极客精神的开拓者，大多只是码农。
曾经被津津乐道的 SOAP、Restful、Stateless，逐渐被 OAuth、gRPC、GraphQL 所取代，API 研究社区的关注重心转向了 安全、效率 和 控制，「开放」逐渐变成了一个鲜有问津的研究领域。
蛰伏的 Open API，在等待开放互联网的再度回归。即将踩着五彩祥云来迎娶她的，是 Web 3.0 还是 AI？
在 OpenAI 推出 ChatGPT 插件机制前，我一直在思考「自解译 API 设计」和「API 进化模式」。前者是解决 API 调用依赖开发者阅读和理解其 API 文档，后者则确保开放生态中 API 灵活迭代的后向兼容。
然而 OpenAI 以 AI-first 思维，借助 LLM 强大的自然语言理解能力和海量「文档 + 代码」语料，试图改写 API 对接以开发者为中心的模式。
它尝试让 AI 像人类开发者那样阅读并理解规范书写的 API 文档，并依照文档自动生成 API 的调用代码。这种沿袭传统 API 调用工作流程的路径，无疑是门槛很低的。
ChatGPT 插件机制虽在实现层面引入 AI，但本质仍然还是藩篱之内的 Platform API。它能否在未来影响开放互联网 API 对接的普遍模式，还有待进一步的观察。
可以确定的是，这种以 LLM 为基础的 API 调用模式，将大幅降低互联网巨头对接大量外部 API 的开发和运维成本，对促进互联网开放也有积极意义。
另一方面，基于 LLM 的 API 调用从根本上改变了「平台」与「插件」的约束关系。
过去一个平台要支持插件，是由平台方先定义接口，插件开发者探索应用场景并按照接口进行开发；而 ChatGPT 插件开发者只需提供「能力」并定义 API（符合 ChatGPT 的交互模式），由 ChatGPT 在与用户交互中探索应用场景。
伴随「平台」与「插件」约束关系改变而被深刻改变的，是两者的权力结构。
传统插件模式下，平台定义具体游戏规则，用流量换取插件对其用户体验的承接，双方是一种共生关系。
而在 ChatGPT 开创的插件模式下，平台表面上放低姿态按插件的文档调用 API，像谦逊的领主，实则让后者沦为「谋士」的角色。
OpenAI 之所以引入这种权力关系极不平衡的插件模式，可能是基于以下两个原因：
1. 传统应用的交互形态与 ChatGPT 相去甚远，如果由插件承接下游的用户体验，可能会给用户带来体验劣化的感受。
2. 在 OpenAI 眼中，传统应用相比 ChatGPT 就像工具之于人类，心态上自然会蔑视其它应用并将其「物化」。