每日热评|从 ChatGPT Plugins 到 MCP 演进启示录:大模型工具调用协议的兴衰与重构
每日热评|从 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 早期对工具调用的经典三层抽象:
在插件模式下,模型扮演的是“API 调度路由者”:
- Manifest 清单:位于
/.well-known/ai-plugin.json,通过简短的description_for_model指引大模型判断在何种场景下激活此插件。 - OpenAPI 规范:大模型根据
openapi.yaml中声明的参数类型、枚举和路径格式化 HTTP Payload。 - 鉴权代理: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-analytics、google-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 的核心进化包括:
- 传输层轻量化:从公网 REST/JSON 演进为本地标准输入输出(
stdio)或 SSE(Server-Sent Events)。 - 资源与提示词原生支持:现代协议不仅支持 Tools(工具),还支持 Resources(文件/数据库状态只读订阅)和 Prompts(可复用交互模板)。
- 双向通知能力:插件支持从客户端向服务端的日志反向流式推送,而不是死板的单向 Request-Response。
四、工程落地建议与总结
- 历史包袱解耦:若现有生产系统仍在使用基于
ai-plugin.json的外挂设计,建议尽快规划向 MCP 或原生 Tool Definition 迁移。 - 关注 Prompt 注入风险:在早期插件中,恶意第三方端点可能通过返回恶意的 JSON 响应触发 Prompt Injection。现代架构必须在模型与工具之间增加防御性防火墙(例如 Valhalla SafeNet 类的语义安全网关)。
- 总结:
openai/plugins虽已成为历史资产,但它沉淀了人类探索大模型与物理世界交互的第一份完整协议草案。理解它的局限,才能真正理解下一代 Agent 架构设计的底层逻辑。
更多推荐




所有评论(0)