现在很多开发者在给 ChatGPT 接入企业内部数据或第三方工具时最大的痛点往往不是写提示词而是如何让模型稳定地连接到外部系统。MCP 协议的出现解决了“连接”的规范问题但真正落地到业务场景还需要连接器Connector和技能Skill这两层资产。Lensa 正是这样的一个开源项目它尝试把 ChatGPT 生态中的 MCP connectors 和 skills 打包成一套可复用、可扩展的解决方案让开发者开箱即用地接入各类能力而不是每次从零开始造轮子。本文会从 MCP、Connector、Skill 的基础概念讲起然后围绕 Lensa 这类开源项目的设计思路拆解一份完整的接入方案。为了让文章具备可操作性我会用一个类似 Lensa 风格的迷你连接器作为实战示例覆盖项目结构、核心代码、配置方式、运行验证和常见坑点。你可以把它当成一份从 0 到 1 的 MCP Connector Skill 落地笔记。1. 什么是 Lensa给 ChatGPT 的外部能力接入层Lensa 的名字听起来很像“Lens镜头”很容易让人联想到“让模型看清楚外部世界”。实际上从项目定位来看Lensa 是一个开源工具集合核心目标是为 ChatGPT 提供标准的 MCP connectors 和 skills。你可以把它理解成 ChatGPT 与外部系统之间的一层“能力适配层”。在过去如果想让 ChatGPT 操作 GitHub、查询数据库、读取工作流状态通常需要写很多定制化代码每次更换场景都要重复完成协议适配、认证处理、错误处理等工作。Lensa 这类项目的思路是把这些常见的外部连接抽象成可以直接复用的 MCP Connector同时通过 Skill 为模型提供“在什么场景下、用什么顺序、调用什么工具”的高层指令。所以Lensa 解决的不是“ChatGPT 能不能联网”的问题而是“如何让 ChatGPT 安全、稳定、可维护地接入不同数据源和工具”的问题。对于个人开发者、AI Agent 团队、企业内部 AI 平台建设者来说这种能力接入层非常有价值。在这类项目里通常可以看到两大模块connectors负责封装具体的外部系统访问逻辑例如 GitHub Connector、数据库 Connector、飞书/钉钉 Connector。skills负责把连接器暴露出来的工具组合成更符合业务场景的“技能包”告诉模型何时使用、如何编排、如何输出。如果将 Lensa 比作一个工具箱那么 Connector 是各种规格的转接头Skill 则是说明书和操作流程的合集。两者配合才能让模型真正完成复杂的真实任务。2. MCP、Connector、Skill 三者的关系很多读者看到“MCP connectors and skills”这个描述时会问MCP 和 Skill 到底有什么区别为什么还需要 Connector2.1 MCP 协议MCPModel Context Protocol是一种开放协议中文常翻译为“模型上下文协议”。它定义了一套标准的通信方式让 AI 应用能够发现并调用外部工具、数据源和资源。简单来说MCP 是“大模型应用”和“外部能力”之间的 USB-C 接口。在 MCP 的架构中一端是客户端比如 ChatGPT、Claude 桌面版、Codex CLI另一端是 MCP Server负责暴露工具、资源和指令。MCP 协议统一了请求和响应格式让模型不需要关心外部系统底层是 REST API 还是数据库驱动。2.2 Connector 与 MCP Server 的关系Connector 在字面上是“连接器”它通常作为一个 MCP Server 运行或者直接嵌入到 MCP Server 中。一个 Connector 会针对某个外部服务做专项适配例如对接 GitHub API把查询 Issue、创建 PR 等操作封装成工具。对接 PostgreSQL 数据库把安全查询封装成工具。对接内部研发平台把工单查询封装成工具。所以你可以把 Connector 理解为 MCP Server 的业务实现。MCP 是通信协议Connector 是业务适配层。Lensa 项目中的 connectors 目录本质上就是一批预先封装好的 MCP Server 实现开发者可以直接下载使用也可以基于示例进行二次开发。2.3 Skill 与 Prompt/工具的边界Skill 这个概念在 AI Agent 生态中越来越重要。它比普通的 Prompt 更结构化通常包含能力描述这个技能适合什么场景。运行规则模型在使用时应该遵循哪些步骤。依赖工具需要调用哪些 MCP Connector 暴露出来的工具。示例输出帮助模型理解期望的回答格式。所以MCP 解决的是“能连上什么”Skill 解决的是“怎么用得好”。MCP Connector 提供了工具Skill 则是工具之上的行为封装。如果一个 MCP Server 定义了query_user_info接口那么 Skill 可以进一步定义当用户问“这个人的联系方式”时应该先调用query_user_info再根据结果整理成标准格式回答。在 Lensa 这类开源项目中Connector 和 Skill 是分层设计的。这样做的好处是同一个连接器可以被多个 Skill 使用同一个 Skill 也可以切换不同的连接器实现只要工具接口保持一致。3. 环境准备与版本说明既然是实践型教程我们需要先准备好本地开发环境。Lensa 目前的具体依赖需要以项目 README 为准本文整理一套通用的环境准备步骤能覆盖大多数 MCP Connector Skill 的开发场景。3.1 运行环境建议准备以下基础环境操作系统macOS、Linux 或 Windows 均可。Windows 环境下需要注意 Python/Node 命令的 PATH 配置。Python 版本3.10 或更高版本。很多 MCP Python SDK 已经不再支持 3.8 以下的旧版本。Node.js如果你选择的 Connector 是基于 TypeScript 实现的需要 Node.js 18 以上。包管理工具Python 项目推荐使用uv或pipNode 项目推荐使用pnpm或npm。Git用于克隆 Lensa 仓库。版本需要根据你的实际项目情况调整本文示例以常见环境为例重点演示配置思路。3.2 获取 Lensa 项目假设你已经从开源社区找到了 Lensa 的仓库地址可以执行git clone https://github.com/your-name/lensa.git cd lensa如果你只是阅读源码不需要安装全部依赖。但如果你准备运行某个 Connector建议在对应目录下创建虚拟环境并安装依赖。以 Python Connector 为例cd connectors/example-connector python -m venv .venv source .venv/bin/activate # Windows 下使用 .venv\Scripts\activate pip install -r requirements.txt3.3 项目目录结构Lensa 这类项目通常会采用扁平化但职责清晰的结构。下面是一个典型目录布局便于理解后续示例lensa/ ├── connectors/ │ ├── github/ │ │ ├── server.py │ │ └── requirements.txt │ ├── postgres/ │ │ ├── server.ts │ │ └── package.json │ └── example-connector/ │ ├── server.py │ └── README.md ├── skills/ │ ├── github-issue-assistant/ │ │ ├── SKILL.md │ │ └── reference.py │ ├── database-query/ │ │ ├── SKILL.md │ │ └── examples.md │ └── weather-lookup/ │ ├── SKILL.md │ └── ... ├── config/ │ └── mcp.json └── README.mdconnectors目录存放 MCP Server 实现skills目录存放 Agent Skills 指令包config目录可以放客户端配置模板。项目之间通过标准 MCP 协议通信所以 Skill 不直接依赖 Connector 的代码而是依赖 Connector 暴露的工具名和参数结构。4. 核心设计思路连接器与技能解耦Lensa 这类项目最有价值的地方不在于某个具体的连接器实现而在于它强调的“连接器与技能解耦”设计。先说连接器。连接器应当只关注“如何从外部系统获取数据”和“如何把数据转换为工具返回值”。它不需要知道模型会不会用这个工具也不需要关心业务场景。例如一个 GitHub Connector只需要提供get_issue、create_issue、list_repos这样的原子工具。技能则相反它关注“模型怎么组合这些工具解决实际问题”。比如一个“每周 Issue 汇总”技能可能会依次调用list_repos、get_issue、format_markdown最终生成一份周报。这个编排逻辑放在 Skill 中而不是写死在 Connector 中。这样一来项目维护者可以单独更新连接器修复接口变化或新增字段而无需修改技能技能也可以不断叠加新的使用片段让模型在同样的一组工具之上获得更好的表现。对于团队协作来说这套模式的边界非常清晰后端开发维护 ConnectorAI 工程师维护 Skill业务人员只需要引用现成技能。实际上这也回答了一个常见困惑Agent Skill 和 MCP 有什么区别MCP 是“通道协议”Skill 是“能力编排”。你可以只有 MCP 没有 Skill模型也能调用工具但结果往往不够稳定你也可以只有 Skill 没有 MCP但 Skill 里描述得再详细模型也无法真正触发外部操作。两者是互补关系。5. 从零实现一个 Lensa 风格 MCP Connector光讲概念不够下面我们来动手实现一个极简的 MCP Connector。这个示例不会依赖 Lensa 仓库内部代码而是按照相同的设计思路演示如何把一个模拟天气查询服务封装成 MCP Server再交给 ChatGPT 类客户端使用。5.1 创建项目结构我们先创建一个项目目录mkdir lensa-demo cd lensa-demo mkdir -p connectors/example-connector mkdir -p skills/weather-lookup然后编写一个连接器。这里使用 Python 生态中的fastmcp库来做快速演示。fastmcp是对官方 MCP SDK 的更高层封装可以大幅减少样板代码。安装依赖pip install fastmcp5.2 编写 MCP Server创建文件connectors/example-connector/server.pyfrom fastmcp import FastMCP # 创建 MCP Server 实例名称为 lensa-weather mcp FastMCP(lensa-weather) # 模拟天气数据 WEATHER_DATA { 北京: 晴25°C空气质量良, 上海: 多云28°C空气质量优, 广州: 阵雨30°C空气质量良, } mcp.tool() def get_city_weather(city: str) - str: 查询城市天气返回温度与空气质量信息。 return WEATHER_DATA.get(city, 暂未收录该城市的天气数据) if __name__ __main__: # 以标准输入输出模式运行 MCP Server mcp.run()这段代码的核心逻辑并不复杂。FastMCP(lensa-weather)创建了一个 MCP Servermcp.tool()把get_city_weather注册成可供模型调用的工具。函数的 docstring 会作为工具描述提供给模型所以一定不要省略。在实际项目中你可以在函数内部请求真实天气 API并把 API Key 放在环境变量中。这里为了演示使用内存字典模拟外部服务重点突出 MCP 接入流程。5.3 配置 MCP 服务写好了 Server下一步是让 ChatGPT 类客户端能够发现它。不同的客户端配置方式略有不同但核心都是一个“MCP Server 列表”。这里以常见的mcp.json配置为例{ mcpServers: { lensa-weather: { command: python, args: [connectors/example-connector/server.py], env: {} } } }如果使用的是虚拟环境command可能需要写成虚拟环境中的 Python 绝对路径例如.venv/bin/python。在 Windows 上则可能是.venv\\Scripts\\python.exe。如果你在开发调试阶段也可以使用 MCP Inspector 来快速验证 Servernpx modelcontextprotocol/inspector python connectors/example-connector/server.pyMCP Inspector 会启动一个本地调试页面你可以在页面上查看工具列表、发送调用请求、观察返回结果。5.4 运行与验证启动 MCP Server 后客户端会通过 stdio 与它通信。你可以在终端手动运行 Server观察是否报错python connectors/example-connector/server.py如果程序正常运行没有输出错误说明 Server 已经进入等待客户端连接的状态。接下来在支持 MCP 的客户端中连接这个 Server。你会在工具列表中看到get_city_weather可以尝试向模型提问“北京现在天气怎么样”模型会调用该工具并返回北京晴25°C 空气质量良这里有一点需要提醒很多 MCP Server 的启动问题并不是代码错误而是 Python 环境不对。如果你在终端手动运行没问题但客户端连接时失败优先检查客户端进程能否找到正确的 Python 命令和依赖。6. 编写一个 Skill让 ChatGPT 学会使用连接器连接器已经接好了但模型可能还不知道什么时候该用这个工具以及如何把工具返回结果整理成用户友好的回答。这时候就需要 Skill 的介入。6.1 Skill 文件结构在 Lensa 项目中一个 Skill 通常是一个独立目录核心文件为SKILL.md。继续使用上面的天气场景我们创建skills/weather-lookup/ ├── SKILL.md └── examples.md6.2 声明能力编辑skills/weather-lookup/SKILL.md--- name: weather_lookup description: 查询城市天气适用于出行规划、活动安排、日常闲聊等场景。 --- # Weather Lookup Skill 当用户询问某个城市当前天气时使用此技能。 ## 使用步骤 1. 从用户消息中提取城市名称注意处理“北京天气怎么样”这类口语表达。 2. 调用 get_city_weather 工具参数 city 为标准化后的城市名。 3. 如果工具返回“暂未收录”如实告知用户暂不支持该城市。 4. 如果工具返回天气数据用简洁、友好的话术回复用户。 ## 注意事项 - 不要编造工具返回数据之外的天气信息。 - 不要回答天气趋势预测因为该工具只提供实时天气。 - 一次只查询一个城市如果用户询问多个城市可以循环调用。SKILL.md的 frontmatter 部分提供了技能的元信息正文部分则是给模型的行为指南。注意Skill 不应该重复描述 MCP Connector 的实现细节它只需要面向模型说清楚“做什么”和“怎么做”。6.3 加载到客户端不同客户端加载 Skill 的方式不同。以目前比较常见的 Agent Skills 目录模式为例你需要将weather-lookup整个目录放到客户端指定的 skills 目录中~/.codex/skills/ └── weather-lookup/ ├── SKILL.md └── examples.md或者放在项目目录的.agents/skills/下。具体路径需要参考你使用的客户端和版本。配置完成后重启对话会话然后向模型提问观察模型是否主动使用天气工具。这里有一个经验Skill 的name和目录名最好保持一致避免客户端加载时出现冲突。同时description要写得足够具体因为模型会根据描述来决定是否激活这个技能。如果你写得太模糊模型很可能在需要时“想不到”使用它。7. 集成到 ChatGPT 的注意事项很多读者关心的是Lensa 和 ChatGPT 怎么集成实际上MCP 生态正在逐步统一ChatGPT 桌面端、Codex CLI 等客户端已经在支持 MCP Server 配置。集成时最容易踩的坑是配置文件路径和 MCP Server 启动方式。下面几点需要特别注意。第一确认你的客户端支持 MCP。如果你的 ChatGPT 桌面端版本较旧可能还没有 MCP 配置入口需要升级到新版本。第二配置中的command必须是客户端进程可以访问到的命令。如果你使用的是 Python 虚拟环境不要写python而要写虚拟环境中的绝对路径否则客户端可能遇到 PATH 环境不一致的问题。第三MCP Server 的 stdout 不能输出业务日志。MCP 使用标准输入输出与客户端通信如果代码里随便执行print()就会污染协议通道导致连接失败。日志请输出到 stderr或者直接写入日志文件。第四如果你的连接器需要访问数据库或第三方 API认证信息建议通过env字段注入不要硬编码在代码中。例如{ mcpServers: { lensa-weather: { command: .venv/bin/python, args: [connectors/example-connector/server.py], env: { WEATHER_API_KEY: your-key-here } } } }第五不要忽略超时和错误处理。ChatGPT 调用 MCP 工具时如果连接器长时间不返回模型可能会重复尝试甚至直接报错。建议在 Connector 内部对第三方请求设置超时时间并在异常时返回结构化错误信息例如{ error: weather_api_timeout, message: 天气服务响应超时请稍后重试 }这样模型才能理解失败原因并向用户给出合理反馈。8. 常见问题与排查思路实战中MCP Connector 和 Skills 的报错信息五花八门。我整理了几个高频问题并给出排查思路。问题现象常见原因解决思路ChatGPT 启动时提示unable to locate the Codex CLI binary本地没有安装 Codex CLI或安装后未加入 PATH安装 Codex CLI重启终端或手动指定 CLI 路径客户端提示无法加载 config.toml例如 model 字段报错config.toml中 model 名称与当前客户端支持不一致检查 TOML 语法确认 model 名称与版本匹配MCP Server 启动后立刻退出Python 依赖缺失或 Python 路径不对在虚拟环境中安装 requirements.txt并使用绝对路径启动连接器工具列表为空Server 启动失败或工具注册代码未执行使用 MCP Inspector 手动启动并检查工具列表模型没有调用 Skill 描述的工具Skill 的 description 不够具体或 Skill 未被加载检查 Skill 目录和 frontmatter优化描述agent skill和mcp概念混淆不清楚两者定位MCP 是连接协议Skill 是能力编排两者配合使用还有一个小问题经常出现在 Windows 上。很多 MCP Server 使用uvx或npx启动但 Windows 下命令后缀可能是uvx.exe。如果你的配置在 macOS 上正常、在 Windows 上失败优先检查命令是否存在。排查问题时我建议按下面的顺序操作手动在终端运行 MCP Server确认代码本身没问题。使用 MCP Inspector 启动 Server检查工具列表和调用结果。检查客户端配置文件格式和路径。查看客户端日志确认 MCP Server 进程是否被正常拉起。如果日志不明确可以在 Connector 代码里临时增加 stderr 日志定位卡在哪个环节。这套排查顺序能覆盖大多数协议集成问题。不要一上来就怀疑模型能力先确认连接层是否稳定。9. 最佳实践与工程建议Lensa 这类开源项目可以给你一个很好的起点但真正落到生产环境时还是要遵循一些工程实践。第一每个 Connector 只做一件事。GitHub Connector 只管 GitHub数据库 Connector 只管数据库不要把业务编排逻辑塞进 Connector。这样后续更换实现、扩新场景都会容易很多。第二Skill 和 Connector 的版本要一起维护。如果连接器升级了接口参数旧的 Skill 可能会失效。建议在仓库中同时维护 Skill 的依赖说明例如在 Skill 目录中注明“需要 lensa-github-connector 0.2.0”。第三认证信息统一走环境变量或密钥管理服务。不要把 Token、密码写在配置文件和代码里。尤其开源项目公开到 GitHub 后密钥泄露是非常严重的安全事故。建议在.gitignore中忽略.env和本地配置文件。第四正确处理超时、限流和重试。MCP 工具调用模型侧通常有超时预期如果你的连接器需要访问较慢的外部 API可以考虑返回“任务已提交”并提供状态查询工具而不是让模型等待同步结果。第五日志和监控要独立于协议通道。所有标准输出都会被协议层消费所以业务日志只能输出到 stderr。生产环境建议把日志接入集中日志平台方便排查线上问题。第六为每个 Connector 写测试。最基础的测试是“启动后能注册预期的工具”更进一步是“给定合法参数能返回预期结构”。MCP Inspector 只能帮你调试不能替代自动化测试。第七命名规范要统一。连接器名建议采用lensa-service-capability的形式例如lensa-github-issue技能名建议采用简短的小写下划线命名例如weather_lookup。命名清晰能避免配置时的混乱。在安全边界方面尤其要注意如果你的 Connector 要操作数据库不要把原生 SQL 查询能力直接暴露给模型。更安全的做法是提前定义好一批白名单查询工具例如query_order_by_id、list_recent_orders而不是暴露一个execute_sql。模型并不能完全理解 SQL 注入和权限边界接口越窄越安全。同样对于删除、更新类操作建议在工具名和描述中明确标记风险并在实现层增加确认参数比如confirm: bool。这些细节在开源项目阶段可能看起来多余但一旦进入企业环境它们就是事故和灾难之间的分界线。10. 总结与学习路线到这里你应该对 Lensa 这类开源 MCP connectors and skills 项目有了比较完整的理解。它本质上是一条“能力接入流水线”MCP 提供协议标准Connector 负责连接外部系统Skill 负责教会模型如何高效使用这些连接能力。本文的实战示例虽然只是一个模拟天气查询但背后涉及的流程——创建 MCP Server、注册工具、配置客户端、编写 Skill、排查启动问题——是通用的。你可以照着这个思路把 GitHub、Jira、MySQL、内部运维平台等系统逐步接入到 ChatGPT 生态中。接下来我建议你按下面的路线继续深入先阅读 Lensa 项目的 README 和源码理解它的目录划分和既有 Connector 的实现方式。挑一个你日常工作中最常用的服务尝试用官方 MCP SDK 或 FastMCP 写一个最小 Connector。用 MCP Inspector 验证工具可用性再把它接到 ChatGPT 客户端中使用。写一个业务场景明确的小 Skill例如“每日工单汇总”“仓库健康度报告”观察模型是否会自动调用。最后再考虑权限、部署、多用户隔离等生产环境问题。MCP 生态还在快速发展Lensa 这类开源项目也会不断更新。不要局限于当前某个版本的配置写法更要理解 Connector 与 Skill 分层设计的思路。只有掌握了这套思路你才能在接入新系统时快速复用已有资产真正把 ChatGPT 变成能干活的工作伙伴。如果这篇文章对你有帮助可以先收藏备用。后续我也会继续整理 MCP Connector 的实战案例包括数据库安全接入、企业内部工具集成和 Skill 调优欢迎持续关注。