MCP 解析：给 AI 装上“万能充电口”，打通连接世界的“最后一公里”

导读：为什么 Cursor 能根据 PRD 写出 Midscene 测试用例，还能帮你校验、直接上传到 HAL-9000，而不是生成一堆「看起来对、平台跑不起来」的 YAML？

背后都是 MCP (Model Context Protocol) 在起作用------我们团队用 hal900-mcp 把这条链路真正接通了。

本文从前端开发者视角，先讲清 MCP 是什么、三大原语与传输协议如何选型，再展开 hal900-mcp 真实落地：把 PRD 变成可执行用例，用平台规则校验挡住 AI「瞎编 YAML」。
📌 前置阅读（不了解 HAL-9000 建议先看）

下文案例对接的是转转内部 HAL-9000 AI 测试平台：用 Midscene 描述 UI 操作，以 YAML 管理自动化用例，支持按需求组织、上传后在平台执行与回归。若你还没接触过 HAL，建议先读这篇平台介绍，再回来看 MCP 如何为它接上「万能充电口」：

👉 HAL-9000 是什么？平台能力一文读懂：mp.weixin.qq.com/s/UvQd4A-a6...

hal900-mcp 则是 HAL 的 MCP 桥接：不负责替代 HAL 本身，而是让 Cursor 等 AI 能读平台约定、校验 YAML、直接调用 HAL 的用例 API。

1 什么是 MCP？AI 界的"USB-C"时刻

2024 年 11 月，Anthropic 开源了一个名为 MCP（模型上下文协议） 的标准。它的目标极其宏大又简单：

让 AI 能够"插上接口"，就像给你的手机插上 USB-C 一样简单。

🎬 业务小剧场：测试同学的一天

想象你要把一份 PRD 变成 HAL 上可执行的 Midscene 用例：

没有 MCP 时：在 Cursor 里反复粘贴 Midscene 官方文档、HAL 平台约定，让 AI 生成 YAML，再手工登录 HAL 上传；换到 Claude Desktop，又要重来一套对接。
有了 hal900-mcp 后 ：同一套 Server 插进任意 MCP Host，AI 自动读 Resources、调 Tools，PRD → 校验 → 入库 一条链路走完。

后文整篇案例，就是在解决这个「最后一公里」。

🎯 曾经的噩梦：N×M 的集成地狱

在 MCP 出现之前，要把 AI 接到企业系统，往往是一场灾难。以我们的场景为例：

N 个 Host：Cursor、Claude Desktop、VS Code Copilot......每个都要单独接 HAL
M 类能力：HAL 用例 API、Midscene 语法文档、平台校验规则、需求管理......每类都要写一遍适配

若每个 Host 各写一套插件，就是 N×M 次重复造轮子：

❌ 每个 API 都要单独写适配代码
❌ 每个 AI 应用都要单独对接
❌ 文档和规则散落在 Prompt 里，一改就全废

这种碎片化，极大地限制了 AI 在测试场景落地的速度。

💡 MCP 的解法：N+M 的极简主义

MCP 就像 AI 世界的 USB-C 接口 。 实现一次 hal900-mcp ，在 Cursor 的 mcp.json 里配好启动命令，任何支持 MCP 的 Host 都能复用同一套 Resources 与 Tools，无需为每个 AI 应用重写 HAL 对接。

$N 个 AI+M 个工具=N+M 次集成\text{N 个 AI} + \text{M 个工具} = \text{N+M 次集成}$ N 个 AI+M 个工具=N+M 次集成

看似简单的数学变化，却从根本上改变了游戏规则。接下来两章，我们会用 hal900-mcp 拆开看：三大原语怎么分工 （Part 2）、为什么选 stdio（Part 3），再在 Part 4 进入完整实战。

2 核心原理：不止是"工具调用"

很多文章只讲了 Tools，但 MCP 的真正威力在于它的三大原语 和清晰架构 。下面先用通用定义建立直觉，再以 hal900-mcp 说明它们如何分工------这也是后文 Part 4 实战的「概念地图」。

1️⃣ 三大核心原语（Primitives）

MCP 不仅仅能"做事"，还能"读书"和"给模板"。

原语	定义	典型场景	你的选择
Resources 📖	只读的数据源	读取 Git 代码、飞书文档、数据库记录	需上下文时用
Tools 🛠️	可执行的操作	发送消息、执行 SQL、触发 CI/CD	需副作用时用
Prompts 📝	预定义的模板	"帮我分析 Bug"、"根据文档写周报"	需标准化流程时用

💡 决策建议：

只是读数据？用 Resources。
要改数据或发消息？用 Tools。
想固化一套工作流？用 Prompts。

🔗 hal900-mcp 里三大原语怎么分工？

Resources 📖：midscene://llms-full 提供 Midscene 官方语法；hal9000://yaml-conventions 固化 HAL 存储与命名约定------解决 AI「文档过时、瞎编平台规则」。
Tools 🛠️：hal_validate_yaml、hal_upload_case、hal_export_case 等------有副作用；上传/更新前强制校验，把业务门禁放在 Server 侧。
Prompts 📝：本项目暂未实现；PRD → 入库 由 AI 在对话中组合多个 Tool 完成（Server 不内置 LLM，模型能力留在 Host）。

2️⃣ 架构揭秘：三个角色的协作流转

很多人分不清 Cursor 和 hal900-mcp 的关系。看这张图就懂了：

scss 复制代码

┌─────────────────────────────────────────────────────────────┐
│ Host (宿主应用) │
│ 如：Claude Desktop / Cursor IDE │
│ 职责：管理 AI 模型、提供 UI、内置 Client │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ Client (客户端) │ │
│ │ 负责与 Server 握手、协商能力、发送请求 │ │
│ └───────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
 ↕ (stdio / HTTP/SSE)
┌─────────────────────────────────────────────────────────────┐
│ Server (服务端 - 你写的!) │
│ 职责：暴露 Tools/Resources/Prompts 能力 │
│ 如：HAL 测试平台桥接、本地文件系统、数据库查询 │
└─────────────────────────────────────────────────────────────┘

当你说「根据这份 PRD 生成用例并上传到 HAL」时，实际流转是：Host = Cursor （承载 AI）→ Client 拉起 hal900-mcp Server （stdio）→ Server 再调 HAL REST API（内网 HTTP）。MCP 管「AI 能调用什么」；HAL 管「用例存哪儿、怎么跑」。

🔄 完整调用时序：

Initialize（握手） ：Client 启动 hal900-mcp，Server 返回能力集------例如 3 个 Resources、6 个 Tools。
Discovery（发现） ：AI 获取工具列表，读懂 hal_validate_yaml「校验 YAML 结构」、hal_upload_case「上传到 HAL」等描述。
Execution（执行） ：用户给 PRD → AI 读 midscene://llms-full → 生成 YAML → 调 hal_validate_yaml → 调 hal_upload_case → Server 请求 HAL 入库。

一次真实请求的简化时序：

sequenceDiagram participant User participant Cursor as Host_Cursor participant Hal900 as hal900_mcp participant HAL as HAL9000_API User->>Cursor: PRD文本 Cursor->>Hal900: readResource_llmsFull Cursor->>Hal900: hal_validate_yaml Cursor->>Hal900: hal_upload_case Hal900->>HAL: POST_create_case

关键点 ：AI 不是靠硬编码路由选工具，而是靠语义理解 。例如看到「校验」「上传」等意图，会在 hal_validate_yaml 与 hal_upload_case 之间自动抉择------Tool 的 Description 写清楚，比写死 if-else 更可靠。Part 4 会展开完整代码与两条丝滑体验。

3 传输协议：stdio vs HTTP/SSE，怎么选？

这是部署时最关键的决策点。hal900-mcp 的结论是 ：MCP 传输层用 stdio ；业务数据走 内网 HTTP 调 HAL------「本地 MCP + 远程业务 API」的常见组合，Part 4 的架构图即基于此。

📍 方案 A：stdio（本地开发首选）------hal900 的选择

原理：Host 直接启动 Server 进程，通过标准输入输出（stdin/stdout）通信。

✅ 优点：极简、安全（MCP 进程数据不出本机）、零延迟、易调试。
❌ 缺点：仅限本地，Host 挂则 Server 挂。
hal900 为何适合 stdio ：
- 团队主要在 本地 Cursor 使用，无需把 MCP Server 暴露公网；
- Midscene 文档、HAL 约定经 Resources 本地缓存，读取快；
- 与 MCP Inspector 调试方式一致（node dist/index.js）。

配置示例（hal900-mcp）：

json 复制代码

{
  "mcpServers": {
    "hal900-mcp": {
      "command": "node",
      "args": ["/path/to/hal900Mcp/dist/index.js"],
      "env": {
        "HAL_API_BASE_URL": "http://127.0.0.1:7999/api",
        "HAL_MCP_USER_NAME": "your_name"
      }
    }
  }
}

HAL_API_BASE_URL 指向 HAL 业务 API；MCP 本身仍只通过 stdio 与 Cursor 对话。

🌐 方案 B：HTTP/SSE（远程服务首选）

原理：Server 作为独立 Web 服务运行，Client 通过 HTTP 请求 + SSE 推送交互。

✅ 优点：可远程访问、独立生命周期、支持负载均衡、适合 SaaS。
❌ 缺点：需处理网络、SSL、认证，复杂度较高。
适用：企业级服务、SaaS 集成、多用户场景。

hal900 当前为何不用 HTTP MCP？ HAL 本身已是 HTTP API；若再把 MCP 层也做成远程 HTTP 服务，会多一层网络、鉴权与运维。现阶段 stdio 连 Cursor + HTTP 连 HAL 足够；若未来要做「多团队共享一个远程 MCP 服务」，再考虑 HTTP/SSE + API Key。

🚦 选择决策树：

MCP Server 需要被远程多用户直接访问吗？

否（hal900 现状）→ 选 stdio。

是 → 选 HTTP/SSE。

hal900 的双层传输（分清两个问题）：

scss 复制代码

Cursor  --stdio-->  hal900-mcp  --HTTP(内网)-->  HAL-9000

问「MCP 要不要远程？」→ 否，用 stdio。
问「业务系统要不要远程？」→ 是，HAL 走内网 REST。

下一章进入完整实战：从痛点、代码到两条丝滑体验。

4 前端开发者实战：用 MCP 把 PRD 变成可执行测试用例

作为前端，你有天然优势：TypeScript + Node.js 是 MCP 的官方首选栈。下面是一个我们团队真实在用的项目------hal900-mcp ：通过 stdio 连接 Cursor，通过 HTTP 对接 HAL-9000 AI 测试平台（转转内部），把「PRD → Midscene YAML → 入库」整条链路接到 AI 上。

😫 痛点：AI 会写用例，但平台跑不起来

测试同学要把 PRD 手工写成 Midscene YAML，再登录 HAL 上传。若只靠 AI 生成 YAML，常见问题包括：

语法依据过时，和官方 Midscene 文档对不上；
违反 HAL 存储约定（如 jsonYaml.content 应只保留 tasks，URL 由用例集字段注入）；
上传类步骤违规（平台按子用例名自动注入 fixture，每个子用例最多 1 个上传步骤）。

hal900-mcp 的核心设计 ：Server 不内置 LLM 。AI 负责理解 PRD；MCP 负责注入「活文档」、执行平台门禁、调用 HAL API------即前文所述 Resources 读书、Tools 办事 的分工。

🏗️ 架构：stdio 本地桥接 + HTTP 业务 API

arduino 复制代码

┌─────────────────────────────────────────────────────────────┐
│  Host（Cursor）                                              │
│  AI 模型 ←→ MCP Client                                       │
└───────────────────────────┬─────────────────────────────────┘
                            │ stdio（本地进程）
┌───────────────────────────▼─────────────────────────────────┐
│  hal900-mcp Server                                           │
│  Resources ×3  │  Tools ×6                                   │
└───────────────────────────┬─────────────────────────────────┘
                            │ HTTP（内网 REST）
┌───────────────────────────▼─────────────────────────────────┐
│  HAL-9000 API（用例创建 / 导出 / 更新 / 需求管理）            │
└─────────────────────────────────────────────────────────────┘

如前所述，stdio 连 Cursor、HTTP 连 HAL ：MCP 进程不出本机，敏感操作经 HAL 白名单与 userName 鉴权完成。

📋 三大原语在本项目中的落地

原语	hal900-mcp 实现	作用
Resources 📖	`midscene://llms-full`、`hal9000://yaml-conventions`、`hal9000://api-spec`	只读「权威语法 + 平台约定 + API 摘要」
Tools 🛠️	`hal_validate_yaml`、`hal_upload_case`、`hal_export_case`、`hal_update_case`、`hal_list_requirements`、`hal_create_requirement`	校验与 CRUD；上传/更新前强制校验
Prompts 📝	暂未实现	由 AI 组合多 Tool 完成工作流

💻 关键代码：入口、资源与门禁

1. 注册 Resources 与 Tools，stdio 启动：

typescript 复制代码

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'

const server = new McpServer({
  name: 'hal900-mcp',
  version: '1.0.0',
  description: 'HAL-9000: Midscene YAML resources, validate and upload cases'
})

registerResourceHandlers(server)  // 3 个 Resource
registerValidateYamlTool(server)
registerUploadCaseTool(server)
registerExportCaseTool(server)
registerUpdateCaseTool(server)
registerRequirementTools(server)

const transport = new StdioServerTransport()
await server.connect(transport)

2. Resource URI：活文档，支持同步官方语法：

typescript 复制代码

export const RESOURCE_URIS = {
  llmsFull: 'midscene://llms-full',           // Midscene 官方 llms-full.txt
  conventions: 'hal9000://yaml-conventions', // HAL 平台 YAML 约定
  apiSpec: 'hal9000://api-spec'              // create-case / update 等 API 摘要
}
// 读取 midscene://llms-full?refresh=1 可重新拉取官方文档

3. 平台规则放在 Server 侧硬校验（而非只靠 Prompt）：

typescript 复制代码

const ALLOWED_TOP_KEYS = new Set(['tasks', 'web', 'android', 'ios', 'computer', 'agent'])
// ...校验 tasks 结构、子用例名一致性...
const uploadStepCount = countUploadStepsInYaml(content)
if (uploadStepCount > 1) {
  errors.push(`每个子用例最多 1 个上传步骤，当前 ${uploadStepCount} 个，请拆分子用例`)
}

完整实现见团队内 hal900-mcp 仓库（TypeScript + @modelcontextprotocol/sdk + axios）。

⚙️ 在 Cursor 里接上 hal900-mcp

在 ~/.cursor/mcp.json 的 mcpServers 中增加：

json 复制代码

"hal900-mcp": {
  "command": "node",
  "args": ["/path/to/hal900Mcp/dist/index.js"],
  "env": {
    "HAL_API_BASE_URL": "http://127.0.0.1:7999/api",
    "HAL_MCP_USER_NAME": "your_name"
  }
}

安装与构建：npm install && npm run sync-llms && npm run build。

🐞 调试神器 MCP Inspector

别再用 console.log 猜了！官方提供了专用调试器：

bash 复制代码

npx @modelcontextprotocol/inspector node dist/index.js

它会打开一个 UI 界面，让你：

🔍 查看暴露的所有 Tools/Resources
🧪 手动测试 hal_validate_yaml 等工具的输入输出
📊 查看完整的 JSON-RPC 日志

🚀 丝滑体验一：PRD 一句话变可执行用例

❌ 没有 MCP 时： 你："根据这份 PRD 写登录场景的 Midscene 用例。" AI：（编造了过时的 API，子用例名和 HAL 规则对不上，上传步骤写了 3 次）

✅ 有了 hal900-mcp 后： 你："根据 PRD 生成用例并上传到 HAL，需求 ID 是 xxx。"

AI 的内心活动（自动执行）：

读取 midscene://llms-full → 获取最新 Midscene 语法。
读取 hal9000://yaml-conventions → 确认 content 只含 tasks、命名规则等。
生成 YAML → 调用 hal_validate_yaml → 拦截结构错误与上传步骤违规。
调用 hal_upload_case → 用例进入 HAL，可直接在平台执行。

🚀 丝滑体验二：改存量用例的「导出 → 改 → 回写」

❌ 没有 MCP 时： 你：（登录 HAL 导出 JSON，手工改 jsonYaml，再粘贴上传，容易漏校验）

✅ 有了 hal900-mcp 后： 你："导出「订单列表筛选」用例集，给筛选子用例加一个分页断言，再更新回去。"

AI 的内心活动（自动执行）：

调用 hal_export_case(caseName: "订单列表筛选") → 拿到完整 jsonYaml。
修改对应子用例的 content。
再次 hal_validate_yaml → 调用 hal_update_case 回写。
生成结果：全程在 Cursor 完成，平台规则在 Server 侧兜底，不会出现「改完却跑不起来」的 YAML。

5 安全：不是妥协，是底线

企业级应用最容易忽略的一点。MCP 内置了多层防护：

🔐 权限最小化

只暴露必要的！

❌ 错误：暴露 execute_command（允许执行任意 shell 命令）或泛化的「任意 SQL / 任意文件写」。
✅ 正确：hal900-mcp 只暴露 hal_* 白名单 Tool（校验、上传、导出、更新、需求列表），业务规则在 Server 端硬编码。
⚠️ 特别提示 ：hal_upload_case / hal_update_case 调用前必经 hal_validate_yaml；HAL 侧靠 userName + 网络白名单鉴权，不把任意删除能力交给 AI。

🛡️ 认证机制

本地 stdio （hal900-mcp 当前形态）：依赖进程隔离，经 env 传 HAL_MCP_USER_NAME 等；MCP 进程不对外暴露 HTTP 端口。
远程 HTTP MCP 服务 （通用场景）：必须上 API Key 或 OAuth 2.1；hal900 的业务 API 则走内网 HTTP，与 MCP 传输层分离。

typescript 复制代码

// 简单的 API Key 中间件示例
app.use((req, res, next) => {
 if (req.headers['authorization'] !== `Bearer ${process.env.MCP_KEY}`) {
 return res.status(401).send('Unauthorized');
 }
 next();
});

🔒 数据隐私

远程通信强制 TLS 1.3 加密。
敏感字段（手机号等）在 Server 端自动脱敏。
所有操作留痕，方便审计。

6 未来已来：MCP 将如何改变一切？

截至 2026 年初，MCP 已从「新兴协议」快速成长为 Agent 生态的基础设施。据 MCP 官方博客（2025 年 12 月）：协议发布约一周年之际，Python + TypeScript SDK 月下载量已超 9700 万 ，活跃 Server 超 1 万 ；ChatGPT、Claude、Cursor、Gemini、Microsoft Copilot、VS Code 等均已提供一等公民客户端支持。据社区公开注册表统计，2025 年底可安装 Server 约 6800+ ，2026 年 Q1 仍保持约 每月 18% 量级的扩张。

关键时间线（简）： 2024 年 11 月 Anthropic 开源 → 2025 年 3 月 OpenAI 正式采纳 → 2025 年 12 月捐赠至 Linux 基金会旗下 Agentic AI Foundation（AAIF），与 Kubernetes、PyTorch 同级的中立治理。

🌍 趋势一：从「私有协议」到「行业标准」

MCP 已进入 AAIF（Agentic AI Foundation） ------由 Anthropic、Block、OpenAI 等共同发起、Linux 基金会托管的开源 Agent 生态基金。这意味着它不再是某一家模型的附属能力，而是全行业共用的 USB-C；hal900-mcp 这类「企业内系统 + stdio 桥接」的落地方式，也会越来越多地出现在各团队的工具链里。

🚀 趋势二：Tool-as-a-Service (TaaS)

未来，每个 SaaS 产品都会提供一个 「MCP 接入点」。开发者不再需要写复杂的集成代码，只需在 AI 配置里填一个 URL（或本地 stdio 命令），就能让 AI 拥有该 SaaS 的校验、读写与流程能力------正如 HAL 用例管理通过 hal900-mcp 接入 Cursor 一样。

🎨 趋势三：多模态与自动化

多模态：AI 不仅能读文本，还能通过 MCP 调用图像处理、语音识别、设备自动化（如 Midscene 驱动的 UI 测试）等服务。
自动化：结合 Prompts 或多 Tool 编排，将复杂工作流（如「PRD 解析 → 生成用例 → 校验 → 入库 → 通知」）固化为可重复的一键指令。

MCP 的本质，不是一种技术，而是一种 思维方式的变革。

它告诉我们：

未来的 AI 竞争，不在于谁的模型参数更大，而在于谁能更优雅、更安全、更丰富地连接世界。

USB-C 统一了电子设备的连接，MCP 正在统一 AI 与世界的连接。

而这一切，才刚刚开始。

📖 延伸阅读与资源：

HAL-9000 平台介绍（前置阅读）：mp.weixin.qq.com/s/UvQd4A-a6...
MCP 官网：modelcontextprotocol.io
GitHub 仓库：github.com/modelcontex...
官方 SDK (TS)：npm install @modelcontextprotocol/sdk
调试工具：npx @modelcontextprotocol/inspector

转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~