1. 本章要说的概念
MCP（模型上下文协议）、Plugin（插件）、Connector（连接器）和 Skill（技能包）。
2. 模拟任务：从一大堆邮件里找出真正值得跟进的客户
你是一个销售人员，Gmail 里挤满了询价、会议邀请、企业服务咨询、售后问题和自动通知。你白天跑客户，晚上还要逐封判断谁更重要、对方公司是什么情况、最近有没有融资、该怎样回复。一顿操作下来，销售还没做多少，先兼职当了半宿邮件分拣员。
于是你在 Codex 中建立“客户跟进”项目，并接入或准备三样东西：
| 你接入或准备的东西 | 在这个任务中负责什么 |
|---|---|
| Gmail Plugin | 让 Codex 能搜索、读取邮件并创建回复草稿 |
| 企查查官方 MCP | 让 Codex 查询目标企业的工商、经营和风险等资料 |
| 你自己做了一个客户邮件回复 Skill | 规定怎样判断邮件类型、怎样组织回复、哪些话不能擅自承诺 |
你给 Codex 下达了任务：
读取 Gmail 中最近一周的客户邮件，找出需要继续处理的事项。分步做以下工作：
根据邮件里的公司名称查询企查查，补充工商、经营和风险等资料。
把以上信息整理成“年月日-客户跟进表.xlsx”，表头依次为邮件时间、企业名称、是否归为重点客户、联系人、客户诉求、企业资料、近期动态、紧急程度和下一步建议。
按照“客户邮件回复”Skill，为每位客户生成回复草稿，只保存到 Gmail 草稿箱，不要发送。
没有查到的资料留空，不要猜。
于是 Codex 读取了 Gmail 邮件，再通过企查查官方 MCP 查询来信企业的公开资料。资料齐了以后，它生成客户跟进表，并按照 Skill 中保存的方法起草回复，存入 Gmail 草稿箱。
然后你就得到了一张可以继续筛选的客户表和一批待检查的回复草稿。
3. MCP（模型上下文协议）：Agent 接入外部服务的一套共同规则
MCP 全称 Model Context Protocol（模型上下文协议）。它规定 Agent 怎样得知外部服务能做什么、怎样提出请求，又怎样接收结果。
规则本身不会工作。真正接收请求并返回结果的程序叫 MCP Server。一个 MCP Server 主要做三件事：
告诉 Agent 自己能提供哪些资料或操作；
接收 Agent 按照 MCP 发来的请求；
查询资料或执行操作，再把结果交还给 Agent。
在本章任务中，企查查既是企业信息数据服务商，也是企查查官方 MCP Server 的提供者。你把这个 MCP Server 接入 Codex 后，Codex 就能按 MCP 的规则请求企业资料。
MCP（模型上下文协议）与 API（应用程序接口）到底是什么关系
API（应用程序接口）是一个比 MCP 早得多、也更普遍的概念。企查查开放 API，是为了让客户管理系统等其他软件能够查询企查查的数据；Gmail、地图和许多软件也都有各自的 API。
Agent 也可以使用 API，但通常需要开发人员先为这个 API 编写专门的接入程序。每换一家服务，接口格式、账号授权和返回结果都可能不同。
MCP 解决的是另一个问题：让支持 MCP 的 Agent 可以按照一套比较统一的规则接入不同服务。MCP 没有取代 API，MCP Server 的背后可以直接连接服务商自己的系统，也可以调用一个或多个 API。
例如，一家第三方销售情报平台可以买入企查查 API，再把企查查 API、地图 API 和自家 CRM API 接到一个 MCP Server 后面：
Codex → 第三方销售情报 MCP Server → 企查查 API、地图 API、CRM API
这里提供 MCP Server 的是第三方平台，企查查只是其中一个数据来源。它与企查查自己提供的官方 MCP Server 不是一回事。
因此，API 是某项服务开放给软件的接口；MCP 是 Agent 接入外部服务的共同规则；MCP Server 是实际按照这套规则接收请求、取得结果的程序。
为什么现在的 MCP（模型上下文协议）看起来有点乱
因为市场上都在说“MCP”，说的却可能不是同一种东西：
MCP：那套共同协议；
MCP Server：按协议向 Agent 提供操作能力或资料的程序；
MCP 平台：替用户接入、托管许多 API 和 MCP Server 的服务；
MCP 目录或市场：帮助用户查找 Server 的清单，本身不负责执行具体操作。
同一个服务的 MCP，可能由服务商自己发布，也可能来自第三方开发人员或集成平台。看到一个“企查查 MCP”，首先要问：它是企查查官方提供的，还是第三方通过企查查 API 做的？两者的数据来源可能相同，提供者、授权方式和可用范围却不一定相同。
4. Plugin（插件）和 Connector（连接器）：用户看到的接入口
Plugin（插件）是一个比 Agent 更早出现的概念。像浏览器里的扩展程序就是大家更熟悉的插件，安装好后为浏览器增加一些新的内容或能力，比如沉浸式翻译帮你翻译网页，ChatGPT 插件能在网页中直接和 ChatGPT 对话来分析内容。
而 Agent 产品里的 Plugin 也可能包含 Skill、操作页面、MCP Server 或其他扩展内容。
Connector（连接器）的目标通常更集中，将 Agent 与另一个外部服务或账号直接接通。例如，把 Codex 与 Gmail 或 Google Drive 连接起来以后，Codex 就可以在授权范围内访问其中的邮件或文件；与 GitHub 连接起来以后，就能让 Codex 直接在 GitHub 上搜索自己用得上的 Skill 或其他系统。
现在不少 Agent 并不太区分 Plugin 和 Connector，不用死记它们的边界，只要知道它们都能为 Agent 接入额外的内容、能力或服务，就足够了。
5. Skill（技能包）：把一类任务的做法保存下来
Skill（技能包）保存的是一类任务可以反复使用的规则、步骤和参考资料。它不负责连接 Gmail 或企查查，而是告诉 Codex：资料拿到以后应该怎样处理，最后交出什么结果。
模拟制作一个“客户邮件回复”Skill（技能包）
你可以授权 Codex 查看自己过去写得比较好的客户邮件；如果不方便开放整个邮箱，也可以挑选几类典型邮件，脱敏后放进项目文件夹，用 Codex 打开，然后对 Codex 说：
请根据我提供的历史邮件，为当前项目制作一个“客户邮件回复”Skill，供以后起草邮件时重复使用。
先判断客户邮件属于询价、会议邀请、竞标信息、企业服务咨询、投诉还是售后问题，并为每一类邮件整理处理规则和参考模板。
写回复时，先找出客户最关心的问题并作回答，再说明下一步动作和时间。文字要简洁、礼貌，不堆销售套话，不写“遥遥领先”一类夸张词。
没有依据时，不得承诺价格、交付日期、折扣或本公司服务能力。每次输出邮件标题和正文，只保存为 Gmail 草稿，不要直接发送。
请把以上要求制作成 Skill，并告诉我以后怎样调用和修改它。
这段话是一次 Prompt，作用是要求 Codex 制作 Skill。Codex 最后保存下来的适用场景、处理步骤、参考模板和输出要求，合在一起才是“客户邮件回复”Skill。
以后需要回复邮件时，你可以说：“调用客户邮件回复 Skill，处理今天收到的客户邮件。”公司规定有变化时，也可以直接要求 Codex 修改这个 Skill，不必每次从头交代全部要求。
用现成的 Skill（技能包），还是自己制作
GitHub 和一些 Skill 市场里可以找到别人公开的 Skill。许多 Agent 软件可以访问 GitHub 或读取下载到本地的项目，因此你可以让 Agent 帮你寻找和初步判断，但具体连接方式要看当前 Agent 软件是否支持。
现成 Skill 适合解决比较通用的任务。安装前，可以先让 Agent 说明它包含什么、是否符合你的需求；安装后先拿少量材料试用，效果合适再继续使用。
如果任务带有明显的个人风格或行业要求，更适合根据自己的旧作品制作专属 Skill。例如，你可以让 Agent 提炼自己常用的文风、结构和逻辑，以后根据新主题和新素材写一篇 500 字以内的寓言故事。
模型和 Agent 软件会变化，几个月前很好用的 Skill，后来也可能显得啰嗦或过时。因此没必要看到一个装一个。需要时再找，并随着实际使用不断删掉无效规则、补充新的要求，通常比囤一大堆 Skill 更有用。
6. 一句话释义
MCP 规定 Agent 怎样得知外部服务能做什么、怎样提出请求和接收结果
MCP Server 是按照这套规则接收请求并返回结果的程序
Plugin 为原有软件增加内容或能力
Connector 将 Agent 与外部服务或账号接通
Skill 保存一类任务可以反复使用的规则、步骤和参考资料