每日热评|从 ChatGPT Plugins 到 MCP 演进启示录:大模型工具调用协议的兴衰与重构

评测快照openai/plugins @ 1dc1958
项目定位:OpenAI 官方早期插件平台生态标准、鉴权清单与示例协议集
数据指标:Stars 6,535 | 主语言 JavaScript / Python | 协议 NOASSERTION
取材窗口:GitHub Trending Weekly (2026-09-13)
作者:Valhalla Matrix 治理实验室

在 2023 年初,OpenAI 轰轰烈烈推出 ChatGPT Plugins(插件生态),被技术界一度誉为“AI 时代的 App Store”。开发者们争相构建基于 ai-plugin.json 的清单,将航班预订、代码运行、文档解析等外部工具注入大模型。然而时至今日,随着 GPTs、Function Calling 以及近期由 Anthropic 牵头并获得广泛支持的 MCP (Model Context Protocol) 崛起,早期插件生态已逐渐退出舞台中央。

在本周 GitHub Weekly Trending 榜单上,openai/plugins 再次被开发者大量回顾与索引。为什么在技术快速迭代的今天,这个“古早”的官方插件仓库依然具备极高的工程研究价值?从 HTTP 端点映射到标准化上下文协议,大模型外部工具调用究竟跨越了怎样的技术鸿沟?


一、架构解析:ai-plugin.json 早期插件的解剖面

浅克隆 openai/plugins 仓库的核心源码,可以看到 OpenAI 早期对工具调用的经典三层抽象:

大模型对话上下文

Plugin Manifest: /.well-known/ai-plugin.json

API 描述契约: openapi.yaml

后端服务: REST Endpoints

用户鉴权: OAuth / User-Http / Service-Http

运行结果注入模型 Context

在插件模式下,模型扮演的是“API 调度路由者”:

  1. Manifest 清单:位于 /.well-known/ai-plugin.json,通过简短的 description_for_model 指引大模型判断在何种场景下激活此插件。
  2. OpenAPI 规范:大模型根据 openapi.yaml 中声明的参数类型、枚举和路径格式化 HTTP Payload。
  3. 鉴权代理:OpenAI 集中式网关负责管理用户 Token 并转发请求。

仓库在 plugins/codex-security/scripts/workbench_cli.py 和各插件目录中展示了这种经典交互契约:

# plugins/codex-security/scripts/workbench_cli.py 典型调用设计
def dispatch_tool_call(action_name: str, payload: dict) -> dict:
    manifest = load_manifest(".well-known/ai-plugin.json")
    if action_name not in manifest["actions"]:
        raise ValueError(f"Unregistered plugin action: {action_name}")
    return execute_remote_endpoint(manifest["api"]["url"], payload)

二、为什么早期插件会遭遇瓶颈?

通过实测仓库中的示例插件(如 data-analyticsgoogle-calendar 等),我们可以清晰总结出第一代插件模式的内在局限:

维度第一代 Plugins 模式现代方案 (MCP / Native Function)
网络拓扑必须拥有公网 HTTPS 域名与开放端点支持本地 stdio / 命名管道 / 本地 IPC 进程间通信
Token 消耗需完整装载 OpenAPI Spec,上下文极易膨胀动态按需注入工具元数据与精简 Schema
交互延迟多次 HTTP 往返,网络握手开销大本地直接调用,毫秒级响应
安全沙箱需向第三方 SaaS 暴露明文数据与凭据本地环境执行,敏感数据不离开受限沙箱

早期插件要求每一个小工具都必须部署为一个对外公开的 Web 接口,这对开发者和企业内网环境造成了极高的安全与合规门槛。


三、从 Plugins 到 MCP 的范式跃迁

今天,开发者之所以重新审视 openai/plugins,是因为行业已经明确了一个技术共识:大模型不仅需要调用公网 Web API,更需要深度控制本地文件系统、IDE 终端、浏览器和本地数据库。

openai/plugins 到现代 MCP 的核心进化包括:

  1. 传输层轻量化:从公网 REST/JSON 演进为本地标准输入输出(stdio)或 SSE(Server-Sent Events)。
  2. 资源与提示词原生支持:现代协议不仅支持 Tools(工具),还支持 Resources(文件/数据库状态只读订阅)和 Prompts(可复用交互模板)。
  3. 双向通知能力:插件支持从客户端向服务端的日志反向流式推送,而不是死板的单向 Request-Response。

四、工程落地建议与总结

  1. 历史包袱解耦:若现有生产系统仍在使用基于 ai-plugin.json 的外挂设计,建议尽快规划向 MCP 或原生 Tool Definition 迁移。
  2. 关注 Prompt 注入风险:在早期插件中,恶意第三方端点可能通过返回恶意的 JSON 响应触发 Prompt Injection。现代架构必须在模型与工具之间增加防御性防火墙(例如 Valhalla SafeNet 类的语义安全网关)。
  3. 总结openai/plugins 虽已成为历史资产,但它沉淀了人类探索大模型与物理世界交互的第一份完整协议草案。理解它的局限,才能真正理解下一代 Agent 架构设计的底层逻辑。
Logo

AtomGit AI 社区提供模型库、数据集、Agent、Token等资源

更多推荐