把公司自己的系统接进 AI：MCP 的最短路径和几条安全底线
不讲协议细节，只讲接什么、怎么接、以及接错了会漏什么
文章目录
共 8 节绝大多数公司用 AI 的方式，还停留在「人把数据复制进去，再把结果复制出来」。这一步不难，但它决定了一个上限：AI 永远只能处理你手动喂给它的那一小块。
MCP（Model Context Protocol）解决的就是这件事——让 AI 直接读你的系统、调你的接口，而不是等你贴。下面讲清楚它是什么、最短怎么接上、以及三条不遵守就会出事的底线。
一、它到底是个什么东西
一句话：一个让 AI 应用和外部系统对话的通用接口标准。
它借鉴的是编程编辑器那套思路——以前每个编辑器要为每种编程语言单独写支持，有了统一的语言服务协议之后，写一份服务，所有编辑器都能用。MCP 想干的是同一件事：你给自己的系统写一个 MCP 服务，所有支持 MCP 的 AI 应用都能接。
规范当前的版本日期是 2026-07-28。底层用的是 JSON-RPC 2.0 消息，三个角色：
- →Host：发起连接的 AI 应用（比如命令行编程工具、桌面客户端）
- →Client：Host 里面负责连接的那一层
- →Server：提供能力的服务——也就是你要写的那个东西
服务端能提供三类东西：
| 类型 | 是什么 | 举例 |
|---|---|---|
| Tools（工具） | 给模型执行的函数 | 查订单、发消息、创建工单 |
| Resources（资源） | 给用户或模型用的上下文和数据 | 一份产品手册、一张表的内容 |
| Prompts（提示） | 模板化的消息和工作流 | 「按标准格式生成周报」 |
客户端这边可以反过来提供一项能力：Elicitation——服务端在执行过程中向用户追问信息。比如你让它删一条记录，服务端可以回问「确认删除哪一条」。
核心协议之外还有几个可选扩展，都需要客户端和服务端双方明确支持、在初始化时协商：
- →Tasks：长时间运行的异步操作，支持轮询、中途补充输入、持久句柄。跑一个要十分钟的导出任务用得上。
- →Skills over MCP：把结构化的工作流指令通过 MCP 分发和发现。
- →MCP Apps：在对话里直接渲染交互式界面元素（图表、表单、播放器）。
二、两种连法，先搞清楚你该用哪种
规范里标准的传输方式有两种：
stdio：客户端启动一个子进程，消息以换行分隔的 JSON-RPC 走标准输入输出。跑在你自己机器上，适合本地工具、本地文件、本地数据库。
Streamable HTTP：每条消息是一个 HTTP POST 打到同一个端点，回复是一个 JSON 对象或者一条请求级别的流。跑在服务器上，适合云服务、团队共用、需要鉴权的场景。
选择很直接：
| 你的情况 | 用哪个 |
|---|---|
| 只有你自己用，数据在本机 | stdio |
| 团队共用、要鉴权、跑在服务器上 | Streamable HTTP |
| 接第三方现成服务（比如某 SaaS 官方给的） | 基本都是 HTTP |
三、最短路径：先接一个现成的，跑通再说
不要一上来就自己写服务端。先接一个现成的，把链路跑通，你才知道自己要写的那个长什么样。
在 Claude Code 里，加一个远程服务是一条命令：
带鉴权头的：
本地进程的：
管理命令是这几条：
claude mcp list 的健康状态有三种，这是排查问题的第一站：已连接、需要认证、连接失败。看到「需要认证」就去跑 claude mcp login，看到「连接失败」就是地址或网络的问题，别在别的地方绕。
四、三种作用域，选错了会出两类事故
加服务的时候有个 --scope 参数，三个取值，这一节比上面的命令重要：
| 作用域 | 在哪生效 / 会不会共享 | 存在哪 |
|---|---|---|
| local（默认） | 只在当前项目，不共享 | ~/.claude.json |
| project | 只在当前项目，会共享——跟着版本控制走 | 项目根目录的 .mcp.json |
| user | 你的所有项目，不共享 | ~/.claude.json |
两类事故都出在 project 这一档：
事故一：把带密钥的配置提交进了仓库。 .mcp.json 是要进版本控制的文件，它的意义就是团队共享。所以绝对不要把密钥明文写进去。正确做法是用环境变量占位：
这样仓库里只有变量名，值在每个人自己的环境里。需要更复杂的取值逻辑（比如临时令牌），可以配一个 headersHelper 指向一个脚本，让它每次现算。
事故二：团队里有人不知道自己加载了什么。 project 作用域的服务会在别人克隆仓库之后自动出现。好消息是有一道闸：项目级的服务在交互式会话里需要先经过批准才能用。别把这道闸当成多余的确认框，它是你唯一一次审阅「我要不要信这个服务」的机会。
五、三条安全底线
这一节是整篇里最该记住的。MCP 的本质是让 AI 能执行任意代码、访问任意数据，威力和风险是同一件事的两面。
底线一：工具的自我描述是不可信输入
规范里写得很直白：工具代表的是任意代码执行，必须谨慎对待；工具行为的描述（包括各类注解）应当被视为不可信，除非它来自一个你信任的服务端。
这句话的实际含义是：一个恶意服务可以把工具描述写成「这个工具只是查询天气」，实际干的是别的事。而这段描述会进到模型的上下文里，同时影响模型的行为。这就是提示注入在 MCP 语境下的具体形态。
Claude Code 的文档里有一句对应的警告：连接每一个服务之前，确认你信任它；会去抓外部内容的服务，会把你暴露在提示注入风险里。
底线二：连之前审，不是连上之后再说
判断一个服务能不能接，问三件事：
- 1这个服务是谁维护的？ 官方出的、开源且有人看的、还是某个人两周前发的？
- 2它能碰到什么？ 读文件？发网络请求？写数据库？能力范围越大，审得越细。
- 3它会不会把我的数据带出去？ 尤其是那种「帮你查资料」的服务，你的问题会原样发到它那边。
规范里把安全原则列成了三条：用户同意与控制（用户必须明确同意并理解所有的数据访问和操作）、数据隐私（Host 在把用户数据暴露给服务端之前必须取得明确同意，未经同意不得转发到别处）、工具安全（Host 在调用任何工具之前必须取得用户的明确同意）。
这三条协议本身是强制不了的，只能靠实现方和使用方自觉。所以审的责任在你。
底线三：别让 AI 工具的凭证流到远程服务去
这一条有工具层面的防护：Claude Code 会阻止 .mcp.json 把它自己的凭证或云厂商凭证发给远程服务。
但工具的防护只覆盖它认识的那几类。你自己的数据库密码、内部系统的令牌，还是得靠前面说的环境变量和作用域纪律。
一条实用的自查：打开你的 .mcp.json，搜一遍有没有任何看起来像密钥的字符串。 有就立刻挪走，然后去把那个密钥轮换掉——它已经在 git 历史里了。
六、什么时候值得自己写一个服务
接现成的跑通之后，你会开始想给自己的系统写一个。判断值不值，看两件事：
值得写的信号：
- →你每周都在手工从某个系统里导数据出来喂给 AI。导的次数越多越值得。
- →那个系统只有你们有（内部 CRM、自建的工单系统、某个行业软件）。外面不可能有现成的。
- →你要 AI 做的事需要「查了再决定」——单向导出满足不了，得让它能反复查。
先别写的信号：
- →需求还在变。接口定了又改，维护成本会吃掉全部收益。
- →那个系统已经有现成的 HTTP 接口，而且你的用法只是「调一次拿个结果」。这种情况直接让 AI 调接口就行，包一层 MCP 是多余的。
- →你还没跑通过任何一个现成的服务。没跑通就自己写，等于同时在调两个未知数。
真要写，从最小的开始：先只做一个工具，一个查询，返回一个 JSON。 跑通之后再加第二个。一次写十个工具，出问题的时候你不知道是哪个的事。
七、几个实际会遇到的细节
超时。默认的等待时间对慢接口不够用。每个服务可以单独配 timeout 字段（单位毫秒），也可以用 MCP_TIMEOUT 环境变量统一设。接内部系统尤其要调这个——内网接口在早高峰慢几秒是常态。
断线重连。远程服务掉线之后会按指数退避自动重连，不用自己写重试。但要知道这件事的存在——你看到的「怎么忽然又好了」通常就是它。
工具会变。MCP 服务可以在不重连的情况下更新可用的工具列表。所以「昨天还有这个工具今天没了」不一定是 bug，可能是服务端改了。
工具太多怎么办。接了五六个服务之后，工具总数可能到几十上百。这时候靠的是工具检索能力，让它按需发现和调用，而不是把所有工具定义一次性塞进上下文。不过还是那条老规矩：能不接的就别接，工具列表越长，选错的概率越高。
打包分发。如果你要把一套配置给团队里所有人用，插件可以把 MCP 服务的定义打包进去，装一次就都有了。
最后
MCP 值得花时间的理由只有一个：它把「AI 能碰到什么」这件事从手工喂养变成了系统接入。 在这之前，AI 的能力上限是你的复制粘贴速度。
但也正因为如此，它把安全边界推到了一个新位置——以前你贴什么它看什么，现在它能自己去看。接一个服务这个动作，等价于给一个你不完全了解的程序开一扇门。 这扇门开得值不值，只有你能判断，而且必须在开之前判断。