从 4 组企查查 MCP 专用接入 ，到 82 张连接器卡片

　　导读： 最初， 我们并没有打算再做一座 MCP 市场， 只想把企查查智能体数据平台的企业数据、

　　法律数据 、招标查查·标讯和智能文档解析四组能力， 统一接入 DeepSeek Harness 。可当 OAuth授权 、10 个 Server 、203 个工具 、旧插件迁移 、本地文件与 stdio 运行时同时出现时， 问题已经不再是 “ 写好四段 mcpServers 配置” 。本文沿真实开发时间线， 复盘开源插件 dsh-mcp-

　　connector 如何从企查查 MCP 专用接入走向通用连接器， 以及为什么插件市场里还可以再长出一个插件市场。

　　实践基线： 本文基于 DeepSeek Harness 开发者预览版 、 dsh-mcp-connector v0.2.21 与 2026年 8 月 25 日公共连接器目录（ Registry） 快照；后续版本与目录数量可能继续变化。

一 、起点不是一座市场， 而是四组真实的 MCP 产品

　　DeepSeek Harness （ 下文简称 DSH） 把 “ 一切皆插件 ” 写在首页： 模型 、工具 、技能 、会话 、存储 、循环和 UI， 都可以由插件组合 。MCP 则把外部数据和工具变成 Agent 可调用的标准服务。

　　两个方向相遇时， 我们手里已经有企业数据与法律数据两个企查查 OAuth 专用插件 。它们证明了企查查 MCP 可以在 DSH 中完成授权 、恢复连接并注册工具 。接下来的需求很自然：招标查查·标讯和智能文档解析也要进入同一个 Agent 工作环境。

　　企查查智能体数据平台目前提供 企业数据 MCP 、法律数据 MCP 、招标查查·标讯 MCP 、智能文档解析 MCP 四组能力 ，合计 10 个 Server 、203 个工具 。前三组提供专业数据查询， 智能文档解析还通过本地桥接处理用户电脑上的文件， 并支持长文档异步解析与结果查询。

　　这也是本项目最重要的起点：我们不是先画一张连接器市场的宏大蓝图， 再去寻找服务填满它， 而是先面对四组已经在生产中演进的 MCP 产品， 再从重复工程中找到通用边界。

　　图 1 · 四组 MCP 产品构成 10 个 Server 、203 个工具的真实起点

二 、第四个专用插件还没写， 我们先停了下来

　　如果沿用原来的路径， 企业数据 、法律数据 、标讯数据 、智能文档解析将各有一个 npm 包， 各自维护授权 、Token 刷新 、本机存储 、连接恢复 、断开 、错误提示和 UI 。产品越丰富， 重复工程越多。

　　在真正复制第三 、第四份代码之前， 我们把变化速度不同的三个对象拆开：

　　这个拆分把项目从 “企查查专用插件合集 ”推向了通用 MCP 连接器 。四组企查查 MCP 成为随包内置的首批 Descriptor， 但 OAuth 、API Key 、Loader（ 加载器）、Storage Domain（ 本机存储域）、连接验证与界面不再为某一项产品重写。

　　旧用户也不能被遗忘 。连接器对原企查查企业数据 、法律数据 OAuth 插件做只读发现和显式迁移：只有用户确认后才复制授权， 旧插件和旧凭据继续保留；在新连接验证可用之前， 不自动停用或删除任何旧配置。

　　图 2 · 从四个专用插件转向 “运行时 、描述 、Server”三层分工

三、真正推动抽象的，不是白板， 而是三个使用问题

　　通用连接器不是设计会议里一次想出来的 。它是在真实产品问题里一点点长出来的。

　　1. 功能能运行 ，入口却不一定在任务路径上

　　我们希望 “MCP 连接器 ” 紧跟在 “新会话 ” 下方， 位于工作区和会话列表上方 。它是 Agent 的能力入口，不应该藏在左下角设置区。

　　但 DSH 当时没有公开对应 Slot 。最后的做法是通过客户端插件与 React Portal， 把入口挂到稳定的 data-slot 结构； 目标位置暂时不可用时， 再回退到底部公开 Slot 。插件既尊重宿主 （ Host） 的结构， 也不因某个位置变化而完全失去入口 。

　　2. 连接了 185 个工具，用户却不知道先问什么

　　企业数据一组就有 6 个 Server 、185 个工具 。详情页如果先铺开工具名称， 用户看到的是技术目录， 而不是 “我可以完成什么任务”。

　　后来我们把信息顺序改成 Prompt 优先： 卡片先讲业务能力 ， 详情页先提供可直接体验的问题 ， Server 与工具默认收起； Prompt 被带入 DSH 原生新会话， 由用户确认后发送 。于是使用入口从 get_xxx_info 变成了 “核验某企业股东与实控人 ”“检索劳动合同解除相关法条和权威案例”“查找武汉近期智慧工地标讯”“把这份财报解析成 Markdown”。

　　3. 页面显示 “ 已连接”， 工具仍可能不可用

　　某远程调研类 MCP 接入时曾出现一个典型问题： 卡片显示已连接， 详情页读取工具却返回 HTTP 400 。凭据和 Header 都没有问题， 真正缺失的是有状态 MCP 服务要求的初始化链路：

　　修复后， 同一枚 Key 可以正常返回工具列表 。我们进一步把会话管理 、工具分页 、瞬时网络重试和错误分类沉淀到通用运行时。

　　图 3 · 从 “装上了”到 “Agent 真能调用 ”的完整验证链

　　四、第五张卡片 ，让 “通用 ”第一次接受外部检验

　　只用自家服务验证， 无法证明抽象真正通用 。

　　第五张卡片选择了一项外部法律检索 MCP 。它与企查查 OAuth 不同： 用户从服务方获取 Access Token， 通过 Bearer 访问多个 MCP Server 。 这迫使连接器支持 “ 一张卡片 、一次录入 、 多个Server 共享凭据”， 而不是只能处理企查查的授权流程。

　　随后， 我们又用金融数据 、基金研究 、外部调研等不同类型的 MCP 服务， 继续验证 API Key 、不同Header 和有状态初始化等差异 。每增加一个真实服务， 通用边界就被重新检验一次。

　　stdio 则让我们做了另一项重要取舍 。很多办公 、开发和本地数据类 MCP 通过本地进程启动， 但DSH 官方 @deepseek-ai/dsh-mcp-client 已经支持 stdio 。连接器没有再实现一套子进程管理和JSON-RPC， 而是在 Descriptor 与连接配置中放行 command / args / env / cwd ， 交给宿主的MCP Client 执行。

　　最终边界变得清楚：

　　连接器负责发现 、授权 、验证 、配置和生命周期；

　　DSH 宿主的 MCP Client 负责 HTTP、stdio、进程和工具注册；

　　Agent 继续在原有 Tool Registry 中选择和调用工具。

　　这也是 “ 一切皆插件 ” 给我们的第一个工程启发： 插件化不是重复实现 宿主能力 ， 而是通过稳定Service 组合已有能力 。

　　五、从 5 张到 82 张：代码和供给必须分开

　　如果每新增一个 MCP 都要修改插件 、发布 npm 、再要求所有用户升级， 市场不可能持续增长。

　　因此， 我们把连接器描述拆到独立开源的 dsh-mcp-connector-registry ：

　　插件包保留 4 张企查查相关内置卡片， 作为核心能力和离线基线；

　　公共 Registry 维护第三方连接器， 用户刷新即可获得目录更新；

　　企业可以把 catalogUrl 指向受控地址， 建设内部 MCP 目录；

　　远程 Registry 暂时不可用时， 插件回退到最近缓存或内置目录。

　　截至 2026 年 8 月 25 日 ， 公共 Registry 已发布 78 条连接器描述， 与 4 张独有内置企查查卡片合并去重后， 最新公开目录口径为 82 张卡片 ； 目录刷新后， 可按企业数据 、金融投资 、法律合规 、开发工具 、办公协作 、调研分析 、设计创意 、效率工具等 9 个分类浏览和连接 。当天的一次目录更新将 Registry 从 72 条扩展到 78 条， 也再次验证了目录供给可以独立更新， 无须重新发布插件。

　　但 “ 多 ” 不能等于 “ 把卡片堆上去 ” 。 Descriptor 虽然不含可执行代码， 也不保存密钥， 仍要校验Schema 、官方端点 、传输方式 、鉴权 、图标 、费用与写操作边界 。收录表示可发现与目录兼容， 不等于官方合作 、质量认证， 更不能把 “78 条描述” 写成 “78 个服务全部实测连接成功”。

　　从这个角度看， Registry 不只是目录， 也是对连接器描述 、安全和兼容性的持续治理。

　　图 4 · 稳定插件运行时与快速扩展的 Registry 如何共同形成 82 张市场卡片

　　六、插件之上再生插件：从 “一切皆插件”到 “三生万物”

　　项目接近收口时， 我们才看清这套结构最有意思的部分： DSH 的市场能力本身也是插件， 用户先从插件市场安装 dsh-mcp-connector ， 连接器启动后， 又提供一座面向 MCP 服务的市场。

　　市场中的 82 张卡片是声明式 Descriptor， 并非 82 个 npm 代码包 。用户连接服务时， Cordis Loader（ 插件加载器） 才为对应 MCP Server 创建运行时实例； 停用 、恢复或断开连接， 工具也随生命周期下线 、重新挂载或移除。

　　如果借用 “道生一， 一生二， 二生三， 三生万物”做一个工程隐喻， 而不是把经典原义机械套进代码，可以这样理解：

　　工程隐喻在本项目中的对应

　　道“一切皆插件” 的可组合原则

　　⼀Cordis Host（ 插件宿主） 提供统一的加载 、依赖 、启停和卸载机制

　　⼆DSH 插件市场与 MCP 连接器市场两级发现入口

　　三连接器宿主插件 、Descriptor 描述 、MCP Client 运行时实例

　　万物82 张卡片， 以及背后的 Server 、工具 、Prompt 和业务任务

　　这很像乐高积木 ： 插件市场是零件柜， MCP 连接器是转接底座， Descriptor 是装配说明， MCP Client 实例才是挂载到 Agent 的功能块 。补充可信描述并完成授权验证， 新能力就能按需接入， 无须修改 DSH 核心。

　　图 5 · “道 、一 、二 、三 、万物”对应的插件递归组合结构

　　七、回头看， 五条经验比某段代码更值得复用

　　1. 先有真实产品，再做通用抽象。 四组企查查 MCP 带来了多 Server 、OAuth 、大工具目录 、本地文件和旧用户迁移等真实约束。

　　2. 连接状态来自协议链路。 TCP 可达、 HTTP 200 或 OAuth 回调成功， 都不足以证明 MCP 工具真正可用 。

　　3. 把供给与运行时分开。 插件稳定运行， Descriptor 快速更新， MCP Server 独立提供专业能力 。

　　4. 优先组合宿主能力 。 复用 DSH 的生命周期 、存储 、Loader 与 MCP Client， 把精力放在发现、授权 、验证和管理上。

　　5. 市场增长靠信任。 凭据保存在用户本机， 鉴权 、费用 、写操作和数据处理边界必须明示。

　　八 、写在最后：统一的不是实现， 而是组合方式

　　从 4 组企查查 MCP 到 82 张连接器卡片， 项目从专用走向通用 。多 Server 、大工具目录 、OAuth、本地文件和旧插件迁移等真实约束， 也让连接器不能停留在 “填一个 URL” 的演示阶段。

　　统一的不是不同服务的实现， 而是它们被发现 、授权 、验证和管理的方式 。所谓 “三生万物”， 正是这套组合机制从四组真实产品走向开放连接器市场的过程。

　　dsh-mcp-connector 与 Connector Registry 均已开源 。DeepSeek Harness 用户可执行：

　　安装或升级后重启 DSH， 即可从 “MCP 连接器 ”入口按任务选择企业数据 、法律数据 、招标查查·标讯 、智能文档解析及其他 MCP 服务 。开发者也可以 Fork 插件或 Registry， 用于内部目录 、行业市场和二次开发。

　　连接器目录持续开放， 开发者和 MCP 服务商可通过 dsh-mcp-connector-registry提交连接器上架 PR；合并后即可进入公共目录， 无须重新发布插件 。82 张是当前公开目录口径，而非终点。

　　OAuth / API Key / HTTP / stdio / JSON接入 · Prompt 与工具发现 · 连接启停与恢复 · 凭据仅保存在本机

　　项目与使用说明： GitHub

　　npm 安装包：dsh-mcp-connector

　　参考资料

　　1. DeepSeek Harness：一切皆插件

　　2. DeepSeek Harness Architecture

　　3. Cordis Primer

　　4. dsh-mcp-connector

　　5. dsh-mcp-connector-registry

　　6. 企查查智能体数据平台

分享嘉宾

　　杜虎 ｜ 企查查科技股份有限公司 · 技术总监

　　负责企查查智能体数据平台的工程落地与产品能力建设， 持续推进企业数据 、法律数据 、标讯数据和智能文档解析能力进入 AI Agent 场景， 实践方向包括 MCP 协议 、Tool / Resources / SKILL 设计 、反幻觉 、可信数据链路与开源插件生态。

　　本文所述实践基于企查查智能体数据平台与开源 MCP 连接器项目的真实开发过程 。第三方连接器收录表示目录兼容与可发现，不构成企查查 、DeepSeek Harness 或相应服务商的官方背书 、质量认证或商业合作。