详解：采用Model Context Protocol（MCP）连接AI和应用系统

IT, Tech | AI AI时代老码农 | 作者： | | 发表评论

1) MCP 连接的“线缆”是什么：JSON-RPC + 两种传输

MCP 的核心是：AI 应用（MCP Client）和你的系统适配器（MCP Server）用 JSON-RPC 2.0 说同一种“工具语言”。协议本身明确了：消息用 JSON-RPC 编码、UTF-8；并定义了标准传输方式。 Model Context Protocol+1

两种最常见的传输方式
  • stdio（本地进程管道）：Client 启动一个本地 MCP Server 进程，通过 stdin/stdout 交换 JSON-RPC。适合“本机工具、IDE、桌面客户端”。 Model Context Protocol
  • Streamable HTTP（服务化/远程）：MCP Server 作为独立服务跑在某个地址，通过 HTTP POST/GET 通信，并支持流式/通知等更复杂交互；它是当前规范中的标准机制之一（并替代了早期“HTTP+SSE”的思路）。 Auth0+3 Model Context Protocol+3 Model Context Protocol+3

OpenAI 这边也已经把 MCP 作为“把 ChatGPT/Agents 接入外部工具与资源”的官方路径之一，文档里还专门强调了自定义 MCP 服务器的安全风险（提示注入、token 风险等）。 OpenAI Platform+2 OpenAI GitHub+2

2) 连接建立的“握手细节”：initialize → initialized

MCP 不是一上来就乱发 tools/list。它有明确生命周期：

  1. Client 发 initialize（带协议版本、客户端信息、自己支持哪些能力等）
  2. Server 回 initialize response（声明它提供哪些能力：tools/resources/prompts…）
  3. Client 必须再发一个 notifications/initialized，表示握手完成，进入正常工作态 Model Context Protocol+2 MCP Protocol+2

你能在抓包/日志里看到类似这样的“就绪通知”：

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

Model Context Protocol

3) 场景 A：用 stdio 把 AI 接到“本地日志/文件/配置”系统（最容易落地）

目标

用户问 AI：

“把今天产线 PLC 的报警日志按设备汇总，并指出最可能的前三个原因。”

你做的 MCP Server（本地进程）

你写一个 plc-log-mcp 小服务，暴露两个 Tools：

  • logs.search：按时间/关键字查日志
  • logs.summarize_by_asset：按设备编号聚合统计（返回结构化 JSON）

MCP 里 Tool 的关键不是“函数名”，而是它必须带参数 schema（让模型知道怎么填参数），以及返回内容的结构约定。规范里明确：Server 可以暴露 tools，工具有名字和 schema。 Model Context Protocol

Client 侧调用一般是固定套路：

  1. tools/list：发现工具
  2. tools/call：带参数调用工具
    （有些 Client 会缓存 tools 列表；工具变动时 Server 还可以通知 list_changed，这属于“更高级的动态能力”） GitHub+1

tools/list（示意）：

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list"
}

tools/call（示意）：

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "logs.search",
    "arguments": {
      "start": "2025-12-30T00:00:00+08:00",
      "end": "2025-12-30T23:59:59+08:00",
      "keyword": "ALARM"
    }
  }
}

这类 stdio 服务器的价值：你不需要把日志系统“开放上网”，AI/IDE 在本机就能查文件、读 SQLite、扫目录、解析 CSV，然后把结果以结构化方式喂给模型生成总结。

4) 场景 B：用 Streamable HTTP 把 AI 接到“SCADA/时序库/CMMS 工单系统”（生产级）

目标

用户对 AI 说：

“找出过去 2 小时振动 RMS 超阈值的设备，给每台设备在 CMMS 里建工单，并附上趋势截图链接。”

这通常需要两个 MCP Servers（或者一个 Server 里暴露两类工具）：

  • tsdb-mcp（读时序数据）：metrics.query, metrics.topN_anomalies
  • cmms-mcp（写工单）：workorder.create, workorder.attach_link

为什么用 Streamable HTTP：

  • 多客户端并发（多个 AI 会话、多个工程师）
  • 需要统一鉴权、审计、速率限制
  • 更适合部署在内网/零信任网关后面
    Streamable HTTP 是 MCP 的标准传输之一。 Model Context Protocol+1
关键技术细节 1：鉴权/授权

HTTP 形态天然要做 auth。MCP 规范把“Authorization”作为协议层的一部分；OpenAI 侧文档也强调自定义 MCP server 的安全与风险。 Model Context Protocol+2 OpenAI Platform+2

落地时常见做法：

  • Bearer Token / OAuth（谁能连、连上能干什么）
  • 工具级权限：同一个 server 里，metrics.query 可能所有人可用，但 workorder.create 需要更高权限
  • 审计日志：记录每次 tools/call 的请求参数摘要、操作者、返回状态
关键技术细节 2：强约束“写操作”

工业场景最怕模型乱写点位/乱下发指令。MCP 这边建议你把“能做什么”变成明确工具，并把参数 schema 设计得足够硬：

例如 workorder.create 参数 schema 强制：

  • asset_id 必填且必须匹配设备台账格式
  • priority 只能是枚举
  • description 限长并做注入清洗（见下一个安全点）
关键技术细节 3：提示注入与“工具输出不可信”

OpenAI 文档明确点名了：恶意输入可能通过工具/工单/邮件内容“注入”模型，让模型泄露 token 或执行不该做的事。 OpenAI Platform
所以你要做：

  • 把外部文本当不可信数据：工具返回里区分 data（结构化）和 raw_text（只给人看或严格引用）
  • 对“写操作工具”加人工审批/二次确认（很多 Agents SDK 支持“可选审批流”这类模式） OpenAI GitHub

5) 场景 C：MCP 的“资源 Resources + 提示 Prompts”怎么用于企业知识/流程固化

很多人只把 MCP 当“tool calling”，但 MCP 规范里，Server 还能暴露：

Resources：把“可读上下文”标准化

比如暴露：

  • resource://manuals/pump_A12（设备说明书片段）
  • resource://sop/vibration_alarm_response（振动告警 SOP）
    Client 可 resources/list / resources/read 获取内容；资源变化还可以通过通知机制推送（list_changed、updated、subscribe 等）。 Model Context Protocol+2 innoq.com+2

这在工业里很实用：让 AI 引用的是“受控知识源”，而不是让模型凭空编 SOP。

Prompts：把“标准作业提示模板”变成可发现的资产

例如在 prompts/list 里暴露：

  • prompt://shift_handover_report（交接班报告模板）
  • prompt://rca_vibration（振动问题 RCA 模板）
    客户端可以把这些 prompt 作为“可选工作流”，让用户点选执行。 Model Context Protocol+1

6) 一句话总结你真正要实现的“工程闭环”

用 MCP 连接 AI 与应用系统，本质是在做三件事：

  1. 把系统能力“工具化”（tools + schema），让 AI 只能在你允许的边界内操作 Model Context Protocol
  2. 把数据与流程“上下文化”（resources / prompts），让 AI 的依据来自受控来源 Model Context Protocol+1
  3. 把生产安全“协议化”（生命周期握手 + HTTP 鉴权 + 审批/审计 + 抗注入），让它可上线可治理 Model Context Protocol+2 OpenAI Platform+2

在 ChatGPT 里配置 MCP Server

一、先选对模式：你想让 ChatGPT 做什么？

A. 在聊天里直接调用你系统的工具（读/写都可能）

用 ChatGPT Developer mode（开发者模式）：它提供“完整 MCP client 支持”，能让 ChatGPT 调用你 MCP Server 暴露的 tools（包括写操作），但官方也强调它“强大但危险”，要防提示注入、写错数据等风险。 OpenAI Platform

B. 让 ChatGPT 把你数据当“连接器/检索源”，用于 Chat search / Deep research

按 OpenAI 的“连接器/深度研究”规范来做：你的 MCP Server 需要实现 search 和 fetch 两个工具，来给 ChatGPT 返回可引用的检索结果与原文片段。 OpenAI Platform

二、ChatGPT 侧怎么配：Developer mode + 创建 App（最常见做法）

这部分是“ChatGPT 与 MCP Server 连接”的核心配置。

0）准备条件（很关键）
  1. 你的 MCP Server 必须是“远程服务”（ChatGPT Developer mode 创建 app 时，支持的协议是 SSE 与 streaming HTTP / Streamable HTTP）。这意味着你要提供一个可被 ChatGPT 访问的 HTTPS 端点。 OpenAI Platform
  2. 你要决定认证方式：OAuth / 无认证 / 混合认证（Mixed）。 OpenAI Platform

说明：如果你打算用“本地 stdio 子进程”那种 MCP（在你电脑上起一个进程，通过 stdin/stdout 通信），这更像是 Codex CLI/你自己的客户端的能力范围；ChatGPT developer mode 的“创建 app”文档里列的就是 SSE/streaming HTTP 这两类远程协议。OpenAI Platform+1

1）打开 Developer mode 开关

Pro/Plus/Business/Enterprise/Edu（Beta）在网页端可用。 OpenAI Platform+1

  • 入口 1（官方写法之一）：Settings → Apps → Advanced settings → Developer mode OpenAI Platform
  • 入口 2（另一处官方说明提到）：Settings → Connectors → Advanced → Developer mode OpenAI Platform

如果你是 Workspace（Business/Enterprise/Edu）：

  • 可能需要管理员先在 Workspace Settings → Permissions & Roles → Connected Data → Developer mode / Create custom MCP connectors 打开权限。 OpenAI Help Center
2）在 ChatGPT 里创建一个“App”（指向你的 MCP Server）

在 Developer mode 开启后：

  1. 打开 ChatGPT Apps settings（设置里的 Apps 页面）
  2. 在 Advanced settings 旁边点 Create app（只有 Developer mode 开了才会显示）
  3. 填你的 MCP Server 信息，然后创建 OpenAI Platform+1

创建时你通常会看到/需要填写这些字段（不同版本 UI 字段名可能略有差异，但含义相同）：

  • Endpoint / URL：你的 MCP Server 基址（SSE 或 streamable/streaming HTTP）
  • Protocol：SSE 或 streaming HTTP（文档写的是这两个） OpenAI Platform
  • Authentication：
    • OAuth
    • No Authentication
    • Mixed Authentication（“初始化与列工具无需认证；具体 tool 是否走 OAuth/无认证，取决于 tool 元数据里的 security scheme”） OpenAI Platform

OAuth 的细节（常见踩坑点）：

  • OpenAI 提醒你确认 OAuth/OIDC 是否会发 refresh token；OIDC 场景常需要 offline_access scope 才能拿到 refresh token，从而保持长期连接。 OpenAI Help Center
  • Developer mode 文档还提到：OAuth 如果你提供“静态 client 凭证”就用静态的，否则会用动态 client 注册。 OpenAI Platform

创建后：

  • 你能在 app 设置里看到它以 Drafts 等形式出现，并且可以在 app 详情页里 toggle 某些工具启用/禁用、以及 refresh 拉取最新工具描述。 OpenAI Platform+1
3）在对话里启用并使用这个 App
  • 在对话里选择 Developer mode，并选择你刚创建的 app；之后 ChatGPT 就会把它当“工具集”来用。 OpenAI Platform
  • 一般 app/连接器在 ChatGPT 里也支持通过 @ 提及 或者点 + → More 把 app 加入当前对话可用工具（UI 可能随版本变化）。 OpenAI Help Center

三、如何验证“连通了”：从协议层看它应该发生什么

只要连通，ChatGPT（作为 MCP client）会走 MCP 的典型流程：

  1. initialize 握手
  2. tools/list 拉取工具列表
  3. 需要时 tools/call 调用工具

MCP 的架构说明里就明确讲了：client 会先 */list 做发现（例如 tools/list），再 tools/call 执行。 Model Context Protocol+1

你也可以在服务器日志里重点盯这两类请求：

  • 是否真的收到了 tools/list
  • tools/call 的参数是否符合你声明的 schema

四、最常见的“配置失败”原因排查清单

1）ChatGPT 侧显示“Unable to load tools / 工具加载失败”

优先检查：

  • URL 写错、路径不对（streamable HTTP 的 endpoint/base path 不一致）
  • 认证方式不匹配（你 server 要 OAuth，但你选了 No Auth；或反过来）
  • OAuth refresh token 没拿到导致过一段时间就断（OIDC 缺 offline_access 常见） OpenAI Help Center
2）你以为要“Bearer Token”，但 ChatGPT UI 没地方填

在 ChatGPT Developer mode 的“Create app”文档里，列出的认证类型是 OAuth / No Auth / Mixed，并没有把“静态 Bearer Token”当成一个独立选项明说。 OpenAI Platform
实践上通常用两种方式绕开：

  • 走 OAuth（最标准）
  • Mixed：把 tools/list/initialize 放开，具体敏感工具用 OAuth 保护（按 tool 元数据的 security scheme 决定） OpenAI Platform
3）“连接器/深度研究”用不了

如果你是想让它出现在 ChatGPT 的“连接器/深度研究”工作流里，你的 MCP Server 必须实现 search 与 fetch，并按规范返回可引用的结果（含 canonical URL 用于引用）。 OpenAI Platform

五、一个推荐的最小配置策略（更安全、也更容易一次成功）

  1. 先做只读：先只暴露查询类工具（例如 searchLogs, getAssetStatus），避免一开始就上写操作。Developer mode 官方明确提醒写操作风险。 OpenAI Platform
  2. 先 No Auth / Mixed 跑通 tools/list，再加 OAuth：这样你能快速分清是“协议/路径问题”还是“鉴权问题”。 OpenAI Platform
  3. 工具 schema 做强约束：枚举、必填字段、长度限制、asset_id 格式校验等，把“可控性”尽量前移到工具层。

相关文章：

  1. 面向ChatGPT编程
  2. >Happy 1024 Day_, 程序员节快乐
  3. 曾几何时，软件吞噬世界。现在，AI正在吞噬软件
  4. Python成为GitHub最受欢迎的编程语言
  5. Google在软件工程中AI应用的进展和未来方向
  6. AI辅助编程，需求尽量定义清楚
  7. 电路设计工具软件KiCad对接AI的MCP Server
  8. 关于AI辅助编程
  9. AI时代老码农日常-20250911
  10. AI时代老码农日常-20250912

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注